both described issues are fixed after update for mga4 32bit. Don't know how to check backport management

CC: (none) => marc.lattemann
Whiteboard: (none) => MGA4-32-OK

same is true for mga4 64bit. Update can be validated after the advisory is uploaded.

Whiteboard: MGA4-32-OK => MGA4-32-OK, MGA4-64-OK

Thanks for your tests Marc. Before validating the update, I think we should make sure that bug #12766 is actually fixed. It's a major improvement since it makes it possible to open the backports repos, so we must be sure that rpmdrake behaves as expected.

CC: (none) => remi

Synergy is a package that I do not have installed and for which a backport is available in backports_testing:

Before upgrading rpmdrake, because of bug #12766, a search for synergy produces no result.

After upgrading to rpmdrake-6.10.2, a search for synergy correctly displays the packages in core/release and only those. Other searches also produce the expected results (backports_testing is ignored). Thus bug #12766 seems to be fixed.


Two additional behaviours were observed, neither of which IMHO should prevent the validation of this update:

1. yle-dl is a package that I have installed and for which a backport is available in backports_testing. When the "All updates" filter is selected the package in backports_testing is offered as an update. 

2. When the Backports filter is selected, all packages from backports_testing are displayed.

It would seem desirable, if possible, to restrict these displays to packages from backports and exclude those in backports_testing. 

My tests were on x86_64.

Created attachment 5219 [details]
exclude testing media

does it work better with this one?

Sorry i cannot test it atm, but are you sure that this patch does not prevent backport/testing to be presented also when it is enabled?

CC: (none) => anaselli

(In reply to Thierry Vignaud from comment #5)
> Created attachment 5219 [details]
> exclude testing media
> 
> does it work better with this one?

I tested this patch (I patched /usr/lib/perl5/vendor_perl/5.18.1/Rpmdrake/open_db.pm directly from the backport candidate) with the dkms_bbswitch package (0.4.2 in core/release, 0.8 in core/backports_testing):

- the backports_testing version is no longer listed in the "Backports" category (even when the backports_testing repo is enabled)

- it is however still listed in the "All" category if backports_testing is enabled (but one could say that it's the expected behaviour, and that only validated backports should be in the "Backports" category). It is not listed in "All" if backports_testing is disabled.

After some playing around with enabling/disabling backports and backports_testing repos, I ended up losing the "Backports" category in rpmdrake altogether.

Backport media should NOT be enabled.

If they're enabled, they're no more treated as backport medias, aka media from which we can cherry-pick packages. Once they're enabled, urpmi will treat them as regular media & eg urpmi --auto-select will happily install all of them as updates.

commit 1ba4f38306f439dcf6cb92a0ff071387a2bba278
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Sat Jun 28 11:16:37 2014 +0200

    do not treat Backport Testing as backport media (mga#13606)
---
 Commit Link:
   http://gitweb.mageia.org/software/rpmdrake/commit/?id=1ba4f38306f439dcf6cb92a0ff071387a2bba278

commit bca162bbde02cedd12d6845266ddc7e80be6c5f4
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Sat Jun 28 11:16:37 2014 +0200

    do not treat Backport Testing as backport media (mga#13606)
    
    Conflicts:
    	NEWS
---
 Commit Link:
   http://gitweb.mageia.org/software/rpmdrake/commit/?id=bca162bbde02cedd12d6845266ddc7e80be6c5f4

Updated Advisory:
=================
This update fixes several issue in rpmdrake:
- Backport packages management is now fixed (mga#12766).
- do not treat Backport Testing as backport media (mga#13606)

It also fixes several issues in edit-urpm-sources:
- fix crashing when canceling browsing custom media path (mga#13268)
- fix down arrow button not working (mga#13572)

Source RPM: rpmdrake-6.10.2 => rpmdrake-6 .10.3

(In reply to Thierry Vignaud from comment #8)
> Backport media should NOT be enabled.
> 
> If they're enabled, they're no more treated as backport medias, aka media
> from which we can cherry-pick packages. Once they're enabled, urpmi will
> treat them as regular media & eg urpmi --auto-select will happily install
> all of them as updates.

Then I fail to see how the whole backports business would work. The only way to install backports would be to go through rpmdrake and cherry-pick something from the "Backports" category?

How can one install a backport using urpmi without enabling the backports repos? And how can one install backport candidates from backports_testing?

I noticed that the "Security updates", "Bugfixes updates" and "General updates" categories are always empty, even though I have lots of updates in "All updates". I don't think this is related to this update candidate, but should I open a bug report about it? Would it be related to bug 2223?

Whiteboard: MGA4-32-OK, MGA4-64-OK => (none)

CLI users are expected to enable repo's that they want to use (and disable them when not required). As Thierry said, once a backport repo is enabled it is treated as any other repo. The purpose of the special treatment of backports in rpmdrake is to enable GUI users to install a selected backport without enabling the backport repo.

My testing confirms that this now seems to work as intended. I populated backports (I have my own local mirror) and the backports and All updates filters now offer only packages from backports and not those in backports_testing.

To install a package from backports_testing one needs to enable the backports_testing repo, just as with any other _testing repo. This also seems to work. If I enable backports_testing, then searching in rpmdrake will find the package in all enabled repo's including backports_testing.

Whiteboard: (none) => MGA4-32-OK, MGA4-64-OK

(In reply to James Kerr from comment #14)
> CLI users are expected to enable repo's that they want to use (and disable
> them when not required). As Thierry said, once a backport repo is enabled it
> is treated as any other repo. The purpose of the special treatment of
> backports in rpmdrake is to enable GUI users to install a selected backport
> without enabling the backport repo.
> 

Thanks, now I understand better. So backports repos are still normal repos (and one can decide to use them as updates repos to have cutting-edge version for all software), but rpmdrake has an additional functionality to make cherry-picking work.

Successfully tested that bugs 13268 and 13572 are fixed with the update candidate. The new patch also fixes the issue with backports_testing packages being listed in rpmdrake (with deactivated repos, as per comment 11).

The only thing I can't test is whether cherry-picking works for actual backports, since there are no validated backports yet in Mageia 4.

@James: Would you be able to test this functionality on both arches with your custom repo?
Some testcases that come to mind:
- package in /release + /backports
- package in /release + /backports_testing
- package in /release + /updates + /backports
- package in /backports
- package in /backports_testing
- package in /updates + /backports

(In reply to Rémi Verschelde from comment #16)
> Successfully tested that bugs 13268 and 13572 are fixed with the update
> candidate. The new patch also fixes the issue with backports_testing
> packages being listed in rpmdrake (with deactivated repos, as per comment
> 11).
This was on Mageia 4 x86_64.

(In reply to James Kerr from comment #14)
> CLI users are expected to enable repo's that they want to use (and disable
> them when not required). As Thierry said, once a backport repo is enabled it
> is treated as any other repo. The purpose of the special treatment of
> backports in rpmdrake is to enable GUI users to install a selected backport
> without enabling the backport repo.

with urpmi you dont even need to enable a media to get packages from it, just do:

urpmi.update "Core Backports"
(to update hdlists info)

urpmi --media "Core Backports" <package name>
(wich restricts it to pulling stuff only from selected media)

or if it has deps in other medias, do:

urpmi --search-media "Core Backports" <package name>

CC: (none) => tmb

(In reply to Rémi Verschelde from comment #16)

The only cases that I have not tested are those where there is an updates package (as well as release and backports)

I'm not sure that any of the packages in backports_testing have an available update also. If not, I may have to invent backports, perhaps by copying packages from cauldron. I'll have a go, perhaps later today, if not it will probably be Monday. (My earlier tests involved simply moving packages from backports_testing to backports and updating media_info.)

I don't have any i586 installations to test on. I thought that there would be no difference, since rpmdrake is noarch.

(In reply to James Kerr from comment #19)
> 
> I don't have any i586 installations to test on. I thought that there would
> be no difference, since rpmdrake is noarch.

And if everything worked as expected with both 64bit and 32bit sources on a x86_64 installation, then it would most likely work with 32bit only too on i586.

In order to test the situation where there is an update and a backport, I created a backport by adding apper from cauldron to backports_testing.

Before installing apper, a search offered both the official update and the release versions. 

After installing the release version of apper, a search 
found both the installed release version and the update version, which was also listed in the All updates filter. The package in backports_testing was ignored. 

I then moved the cauldron version of apper from backports_testing to backports.

Before installing apper, a search offered both the release and updates versions. The backport was listed under the Backports filter.

After installing the release version of apper, a search found both the installed release version and the updates version. The All updates filter offered both the official update and the backport. The Backports filter listed the backport.

So far as I can tell, backports are being handled correctly.


The only change in behaviour that I have observed is that a simple search for a package that is not installed now finds both the release version and the official update, instead of just the latest version. (IIRC this may have been the behaviour at some time in the past.) I'm not sure what the intended behaviour is - a case could be made for either.


As before all my tests were conducted using x86_64.

This is the wanted search behavior

Thanks for the thorough testing James!

As far as I'm concerned, the update can be validated, and backports can start being pushed to Mageia 4 (if everything is setup for it on the sysadmin side).

Validating update, advisory uploaded.

Please push rpmdrake to Mageia 4 core/updates.

Keywords: (none) => validated_update
Whiteboard: MGA4-32-OK, MGA4-64-OK => MGA4-32-OK MGA4-64-OK advisory
CC: (none) => sysadmin-bugs

Update pushed:
http://advisories.mageia.org/MGAA-2014-0144.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED