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.
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?
Assignee: bugsquad => thierry.vignaud
This appears to be fixed after updates today. Closing
Status: NEW => RESOLVEDResolution: (none) => FIXED
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 => REOPENEDResolution: FIXED => (none)
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
Mail sent - subject 'bug 7677'
Indeed, I can reproduced with rpmdrake --env=bug7677 --search=geda-devel
Status: REOPENED => ASSIGNED
I'm not sure I can still reproduce this bug as of rpmdrake-5.45. Can you?
(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 :)
Closing then
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
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.
New bug7677.tar.xz is here (2.3MB) : http://mtf.no-ip.co.uk/pub/linux/barjac/soft/bug7677.tar.xz
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
The above is in Cauldron with: rpmdrake-5.49-1.mga3 urpmi-7.27.2-2.mga4
Seems to now be fixed in Mga5 Cauldron. Closing.
Status: REOPENED => RESOLVEDResolution: (none) => WORKSFORME