Description of problem: Running 64-bit version on RHEL (4.5 kernel but redhat-release 4u4) with x86 version of firefox installed. System is registered to prod, which right now is running 416. up2date-4.4.69-25 firefox.1.5.0.9-0.1.el4 https://rhn.redhat.com/errata/RHSA-2007-0079.html, which is in prod, makes available firefox.1.5.0.10-0.1.el4. The rhn applet as well as the rhn webui indicate that this updated package is available. However, running up2date on the system indicates that firefox is already up2date. Also, scheduling the update to .10 via the webui seems to work, but once rhn_check is run on the system you get: 'The following packages you requested are already updated: firefox' 'rpm -qa --qf "%{name}-%{version}-%{release}.%{arch}\n" | grep fire' on the system returns firefox-1.5.0.9-0.1.el4.i386 on a system running 64-bit rhel with 64-bit firefox, 'up2date --arch=i386 firefox' results in 'The following packages you requested are already updated: and then lists firefox on the next line.' 'If I run just "up2date -u --arch=i386", it lists a ton of rpms and interestingly, firefox is not one of them.'
I fixed the --arch issue as a part of 4.5 in the following https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201092#c2 see case#2 in the above bug link. When --arch was specified up2date basically pulls the package based on name rather than name and arch and hence always says that package is already available even if one arch is available. Now if it does'nt exist it should say its not found or if its available it should pull up tha package with specified arch. I'm pasting the <snip> below from bz#201092: <snip> 2. for example on an x86_64 box if i try: $ up2date --arch=i386 emacs we get The following packages you requested are already updated: emacs which is wrong, as $ rpm -q emacs package emacs is not installed instead up2date should say package is not found as only x86_64 version of package is available. this is because it checks for the available updates only by name rather than check even for arch when --arch is specified, now with the fix, we should see: $up2date --arch=i386 emacs Fetching Obsoletes list for channel: rhel-x86_64-as-4... Fetching Obsoletes list for channel: rhn-tools-rhel-4-as-x86_64... Fetching rpm headers... ######################################## package to INSTALL [] Name Version Rel ---------------------------------------------------------- The following packages you requested were not found: emacs as expected. <snip/>
In this case, there is an i386 version of firefox available. (I believe.) While RHN is busy saying that a new version of firefox is available, firefox-1.5.0.10, both "up2date -u firefox" and "up2date -u --arch=i386 firefox" say that all packages are up to date even though firefox-1.5.0.9 is the installed version.
Hi Peter: hmm from the initial comments in the bug this is my understanding: - you have a i386 version of up2date install on your x86_64. - when you do an up2date it says yours is already updated.( this is probably because it looks for available only by name rather than arch as well, this is fixed in 4.5) - then when you do up2date --arch=i386 firefox it says its already updated - and when you do up2date -u --arch=i386, firefox is not one of the packages listed. from this it tells me that firefox 1.5.0.10-0.1.el4 update is not available for i386 version. Thats the bug i was mentioning to you in my previous comment as up2date --arch has an issue where it keeps should the packages is already updated when in reality the packages is not found in the available. I tried to reproduce the same on my x86_64 box registered to prod and i dont see an i386 version of firefox listed as available for update for me and hence my above suspicion. - does up2date --list show you firefox i386 version available for update? if not then you dont have an i386 available for update. - do you see the same behaviour the 4.5 beta released version as well? Most of the multilib issues where fixed as a part of 4.5(In beta state currently).
Let me see if I can answer these -- Yes, I have a i386 version of firefox installed on an x86_64 system. When I run "up2date -u", it tells me that all packages are up to date. When I run "up2date --arch=i386 firefox", it tells me that the following packages you requested were not found: firefox. When I run "up2date -u --arch=i386", firefox is indeed not listed. "up2date --list" shows no packages in the list. I don't understand the question about the 4.5 beta released version. The 4.5 beta released version of what? All this time though, the Red Hat Network Alert Notification Tool tells me that I have firefox-1.5.0.9-0.1.el4 installed and that firefox-1.5.0.10-0.1.el4:0 is available.
At one point, I thought that I saw/heard something about the errata for the i386 version of firefox-1.5.0.10 not being available for some reason. Do we know whether this is the case or not and whether this might cause a problem? It seems unlikely that a new version of firefox would be available for x86_64, but not available for i386.
Created attachment 150158 [details] if I search for firefox in list of available for install
Created attachment 150159 [details] shows x86_64 version of firefox and not i386
above attached are the screen shots of how the ui looks for a search on available packages for install (firefox in this case). In my above post 4.5 i meant, the new 4.5 beta version of up2date that was released. Most of the multilib issues were addressed as a part of this. So i was wondering if you were seeing the same behaviour on 4.5 as well. regarding errata for firefox, its definitely a possiblility to take into account. If we dont have a valid errata with available package up2date wont pick it up on the client. one other way to see if you have this packages in your subscribed channels is through the webui. try this: goto System - > pick your host -> software -> packages -> install and search for firefox. This will show you all available firefox packages for upgrade including various arches. mine looks as attached above, where it does'nt list i386 version for update.
Hi Prad, I sent Peter the up2date-4.5.5-1.el4.ia64.rpm version of up2date to upgrade to and I believe he still had the same issue. Is 4.5.5-1 the 4.5 beta version of up2date?
hi Máirín, yea that is the latest version of 4.5 beta package.
so with a 4.5 version: - does '$ up2date --arch=i386 firefox' say the package is already updated? or does it say the package is not found? If its not available in your subscribed channel it should give you a not found message. - If you goto System - > pick your host -> software -> packages -> install and search for firefox, doesit show i386 version as available package for install/update ? If we can confirm the first two: - possibility is the applet itself. I remember seeing a bug somewhere where applet lists the packages available for update based on name rather than taking into consideration the arch as well and lists package as available when its not in the available updates in first place. Probably we are hitting the same scenerio. I'll have to get in touch with shughes on ETA for applet issue.
*** Bug 231360 has been marked as a duplicate of this bug. ***
When I run "up2date --arch=i386 firefox", it says package was not found. I didn't exactly understand the System -> pick your host -> ..., but I don't think that it shows an i386 version of firefox. It just shows an x86_64 version.
(In reply to comment #14) > When I run "up2date --arch=i386 firefox", it says package was not found. > which tells me that up2date is doing what its suppose to,the package is not available for it to update in the available subscribed channels. A regular '$ up2date firefox' (without --arch) always checks for best arch package in this case as your system is x86_64(or not i386), checks if x86_64 is up to date else it will say not found. > I didn't exactly understand the System -> pick your host -> ..., > but I don't think that it shows an i386 version of firefox. It just > shows an x86_64 version. what i meant was: if a i386 version of firefox was available it would show up in the list of updates/install on the webui through that path. and yes you gave me the answer i was looking for that it lists only x86_64. So from up2date's perspective its doing whats expected. If the applet is showing firefox as available for update as you mentioned earlier, its an applet issue. I'll talk to shughes regarding the applet behaviour and get back as he owns it.
hi Peter: Could you give a little information of whats the applet behaviour you are seeing in this regard? - Does the applet show that firefox is available for update? I just want to know a little more on this before i open up a seperate bug on applet. Since the package is not available in any of subscribed channels(x86_64), A *work around* I tried was to : - create a custom channel on the ui and subscribe it to host. - grab the firefox.i386 updated package from one of i386 channels, where its available - push this package to your custom channel - and then try up2date --arch=i386 firefox on your host and it should now pull down the newer version of the package. As its now a part of the available package list.
Yes, the applet shows that firefox is available for update. I have a red ball with an exclamation point in it and when I click it, it tells me that there is a new version of firefox which is available. If I get desperate, I may try that workaround. For the moment though, I think that it would be good if the information being conveyed was consistent. If one tool says that an update is available, then another tool should not say that it is not. :-) Then, I will guess that I will have to find who to talk to to get the i386 version of firefox added to the collection of packages for x86_64.
(In reply to comment #17) > Yes, the applet shows that firefox is available for update. I have a red > ball with an exclamation point in it and when I click it, it tells me that > there is a new version of firefox which is available. > In either case, I think applet should'nt show up firefox in the available updates if you have a i386 version installed and available update is x86_64. I opened a bug bz#232654 and aligned it to rhn-applet. > If I get desperate, I may try that workaround. For the moment though, > I think that it would be good if the information being conveyed was > consistent. If one tool says that an update is available, then another > tool should not say that it is not. :-) > yep I totally agree :), comments same as above. > Then, I will guess that I will have to find who to talk to to get the > i386 version of firefox added to the collection of packages for x86_64. yea this is something to follow up as to why we dont have a i386 firefox in x86_64 channels when an erratum is release for the same.
at this point this depends on bz#232654 .. this is an applet issue as peter and I discussed. closing this as notabug for up2date