Bug 7677

Summary: rpmdrake fails to display packages in enabled additional local repo (urpmi works OK)
Product: Mageia Reporter: Barry Jackson <zen25000>
Component: RPM PackagesAssignee: Thierry Vignaud <thierry.vignaud>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: Normal Keywords: NEEDINFO
Version: Cauldron   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Source RPM: rpmdrake CVE:
Status comment:

Description Barry Jackson 2012-10-02 17:35:00 CEST
Description of problem:
Just recently I notice that packages available from my local iurt builds repo are not shown in rpmdrake.

Running rpmdrake from CLI:
[root@jackodesktop baz]# rpmdrake
getting lock on urpmi
examining synthesis file [/var/lib/urpmi/iurt64/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Core Release (zmrepo1)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Core Updates (zmrepo3)/synthesis.hdlist.cz]
-----------------snip----------------

The first one, iurt64 is correctly read, and is set up as update media.
Looking for harbour - only version 3.0.0.xx versions are visible which are on the mirrors.
Version 3.2.0 which is in my iurt64 repo is not shown.

If I use urpmi then:-
===============================================================
[root@jackodesktop baz]# urpmi harbour --test --debug
getting lock on urpmi
parsing: /etc/urpmi/mediacfg.d/Devel-2-x86_64
parsing: /etc/urpmi/mediacfg.d/Devel-3-x86_64
examining synthesis file [/var/lib/urpmi/iurt64/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Core Release (zmrepo1)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Core Updates (zmrepo3)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Nonfree Release (zmrepo11)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Nonfree Updates (zmrepo13)/synthesis.hdlist.cz]                                      
examining synthesis file [/var/lib/urpmi/Tainted Release (zmrepo21)/synthesis.hdlist.cz]                                      
examining synthesis file [/var/lib/urpmi/Tainted Updates (zmrepo23)/synthesis.hdlist.cz]                                      
examining synthesis file [/var/lib/urpmi/Core 32bit Release (zmrepo31)/synthesis.hdlist.cz]                                   
examining synthesis file [/var/lib/urpmi/Core 32bit Updates (zmrepo33)/synthesis.hdlist.cz]                                   
getting exclusive lock on rpm                                                                                                 
search_packages: found harbour-3.2.0-1.18106.mga3.x86_64 matching harbour                                                     
search_packages: found harbour-3.2.0-1.18182.10.mga3.x86_64 matching harbour
search_packages: found harbour-3.2.0-1.18184.10.mga3.x86_64 matching harbour
search_packages: found harbour-3.0.0-6.mga3.x86_64 matching harbour
search_packages: found harbour-3.2.0-1.18187.10.mga3.x86_64 matching harbour
search_packages: found harbour-3.0.0-6.mga3.x86_64 matching harbour
found package(s): harbour-3.2.0-1.18106.mga3.x86_64 harbour-3.2.0-1.18182.10.mga3.x86_64 harbour-3.2.0-1.18184.10.mga3.x86_64 harbour-3.0.0-6.mga3.x86_64 harbour-3.2.0-1.18187.10.mga3.x86_64 harbour-3.0.0-6.mga3.x86_64
opening rpmdb (root=, write=)
chosen harbour-3.2.0-1.18187.10.mga3.x86_64 for harbour|harbour|harbour|harbour|harbour|harbour
selecting harbour-3.2.0-1.18187.10.mga3.x86_64
requiring lib64harbour[== 3.2.0-1.18187.10.mga3],libharbour.so.3.2()(64bit) for harbour-3.2.0-1.18187.10.mga3.x86_64
chosen lib64harbour-3.2.0-1.18187.10.mga3.x86_64 for lib64harbour[== 3.2.0-1.18187.10.mga3]
selecting lib64harbour-3.2.0-1.18187.10.mga3.x86_64
chosen lib64harbour-3.2.0-1.18187.10.mga3.x86_64 for libharbour.so.3.2()(64bit)
harbour is not in potential orphans
To satisfy dependencies, the following packages are going to be installed:
(test only, installation will not be actually done)
  Package                        Version      Release       Arch    
(medium "iurt64")
  harbour                        3.2.0        1.18187.10.m> x86_64  
  lib64harbour                   3.2.0        1.18187.10.m> x86_64  
26MB of additional disk space will be used.
5.4MB of packages will be retrieved.
Proceed with the installation of the 2 packages? (Y/n) n
==============================================================

So something broke in rpmdrake ? This was working fine until yesterday, yet the last commit to rpmdrake was 10 days ago.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
Comment 1 Barry Jackson 2012-10-02 17:43:43 CEST
Has something changed related to signed package checking?

My test packages are unsigned and urpmi warns on installation, is rpmdrake blocking unsigned packages I wonder?
Barry Jackson 2012-10-02 17:45:57 CEST

Assignee: bugsquad => thierry.vignaud

Comment 2 Barry Jackson 2012-10-04 22:18:24 CEST
This appears to be fixed after updates today.

Closing

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

Comment 3 Barry Jackson 2012-10-08 02:13:34 CEST
It seems that if a package exists in core, then it is given priority over the same package with a later release in other custom media.

I just built the latest release of munin locally before it hit my local mirror.
It has a new sub-package that did not previously exist.
Typing 'munin' in the search box in rpmdrake showed the old versions of all pre-existing packages (rel 3) already on the mirror and also showed the new (rel 4) sub-package from my custom media.
It should have shown all the new (rel 4) packages.
The fact that it was showing the new sub-package rules out any possible issue with my media.

Similarly I repeated the test with another new build of another package where rpmdrake showed only the packages on the mirror. urpmi immediately wanted to install my new build.

There is a bug in rpmdrake that does not affect urpmi.  

My local build setup uses iurt, uploads to my media and runs genhdlist2 in the appropriate branch.
I then run urpmi.update -a before attempting to install with rpmdrake or urpmi.

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

Comment 4 Thierry Vignaud 2012-12-06 10:36:46 CET
If you can reproduce, please sent to me by email the bug7677.tar.xz file resulting from running the following commands:
yes n|urpmi --auto-select --bug=bug7677
tar cfa bug7677{.tar.xz,}

Keywords: (none) => NEEDINFO

Comment 5 Barry Jackson 2012-12-07 00:58:02 CET
Mail sent - subject 'bug 7677'
Comment 6 Thierry Vignaud 2012-12-07 13:54:53 CET
Indeed, I can reproduced with rpmdrake --env=bug7677 --search=geda-devel

Status: REOPENED => ASSIGNED

Comment 7 Thierry Vignaud 2013-03-24 14:41:20 CET
I'm not sure I can still reproduce this bug as of rpmdrake-5.45.
Can you?
Comment 8 Barry Jackson 2013-03-24 15:42:09 CET
(In reply to Thierry Vignaud from comment #7)
> I'm not sure I can still reproduce this bug as of rpmdrake-5.45.
> Can you?

Nope - I thought I had noticed a change, and a test confirms it.

I just installed opencpn without it's suggested plugin from core.
I then enabled my local test repo that has an updated version and rpmdrake showed the new suggested plugin and also that there was an update for the installed base package.

Great - looks fixed to me :)
Comment 9 Thierry Vignaud 2013-03-24 19:26:57 CET
Closing then

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

Comment 10 Barry Jackson 2013-04-09 15:30:53 CEST
I seem to be hitting this issue again in a clean net-install in a vm.

I have an extra repo set up in urpmi-proxy that has zanshin.

Urpmi handles this correctly:

[root@localhost baz]# urpmi --test zanshin
To satisfy dependencies, the following packages are going to be installed:
(test only, installation will not be actually done)
  Package                        Version      Release       Arch    
(medium "extra")
  lib64akonadi-kde4              4.10.2       2.mga3        x86_64  
  lib64akonadiprotocolinternals1 1.9.1        2.mga3        x86_64  
  lib64kcalcore4                 4.10.2       2.mga3        x86_64  
  lib64kontactinterface4         4.10.2       2.mga3        x86_64  
  zanshin                        0.2.1        3.mga3        x86_64  
(medium "Core Release")
  lib64ical0                     0.48         2.mga3        x86_64  
  lib64icalss0                   0.48         2.mga3        x86_64  
5MB of additional disk space will be used.
1.4MB of packages will be retrieved.

Note the zanshin-0.2.1-3.mga3

Using rpmdrake only zanshin-0.2.1-2.mga3 from core is offered.

I will attempt to upload a new bug7677.tar.xz from the vm system.

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

Comment 11 Barry Jackson 2013-04-09 16:07:57 CEST
New bug7677.tar.xz is here (2.3MB) :
http://mtf.no-ip.co.uk/pub/linux/barjac/soft/bug7677.tar.xz
Comment 12 Barry Jackson 2013-05-30 11:48:11 CEST
This is still occuring with gurpmi-7.27.2-2.mga4

Searching for bristol finds only the debuginfo mga4 package from my 'zm-proxy-extra' media. The only other rpms shown are mga3 versions.

Howerver urpmi correctly offers to install the mga4 versions:

[root@jackodesktop baz]# urpmi bristol
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "zm-proxy-extra")
  bristol                        0.60.11      1.mga4        x86_64  
  lib64bristolmidi0              0.60.11      1.mga4        x86_64  
6MB of additional disk space will be used.
3MB of packages will be retrieved.
Proceed with the installation of the 2 packages? (Y/n)

Corresponding bug7677a.tar.xz is here:
http://mtf.no-ip.co.uk/pub/linux/barjac/tests/bug7677a.tar.xz
Comment 13 Barry Jackson 2013-05-30 12:31:16 CEST
The above is in Cauldron with:
rpmdrake-5.49-1.mga3
urpmi-7.27.2-2.mga4
Comment 14 Barry Jackson 2014-03-23 17:29:36 CET
Seems to now be fixed in Mga5 Cauldron.

Closing.

Status: REOPENED => RESOLVED
Resolution: (none) => WORKSFORME