Hi there, I tried to upgrade an mga4 distribution to mga5 RC on real hardware. The mga4 version was sync to latest updates just before. I used a network install based in boot-nonfree.iso. After a while, the installer failed due to some conflicts in various packages and some failed scripts. I have attached report_1.bug at that point. The messages concerning the scripts were: "ERROR: script failed for mtink-1.0.16-10.mga4" "ERROR: script failed for get-skype-4.3.0.37.mga5.nonfree" Next, I clicked on OK. At that point, the installer restarts from point 0 at which it asks to select the medias. I unselected everything possible (but not core as it is untickable). The installer failed again, but with less conflicts. At that point, I dumped report_2.bug. Clicking OK again, the installer does loop from failures to select medias etc... In addition to fix the package issues, I think the installer should at some point stops looping; or explaining that something went wrong and allows to exit the loop. I had to reset hard the computer. Cheers.
Created attachment 6380 [details] dumped report file after first failure
Created attachment 6381 [details] dumped report file after second failure
Blocks: (none) => 14069
I have just rebooted into my uncompleted upgraded mga4->mga5. Doing urpmi --auto-update reproduces the conflicting packages. It seems to be all triggered by the upgrade from hylafax mga4 to hylafax mga5. Installation failed: file /usr/sbin/faxsetup from install of hylafax+-client-5.5.5-11.mga5.x86_64 conflicts with file from package hylafax-1:5.5.0-6.mga4.x86_64 file /usr/sbin/faxsetup.linux from install of hylafax+-client-5.5.5-11.mga5.x86_64 conf licts with file from package hylafax-1:5.5.0-6.mga4.x86_64 It looks like there is an epoch number in mga4 hylafax, plus de conflict due to that file being moved from one package to the other. By removing "by hand" the mga4 hylafax package; urpmi --auto-update works without anymore conflict. I am not a guru of epoch number and obsolete; that would be nice if someone could have a look how to fix hylafax package (own by nobody). For get-skype, maybe we should ban that package for being upgraded? cheers.
The epoch shouldn't be an issue here. Seems hylafax+ is meant to replace hylafax, but there must be something wrong in the obsoletes.
Assigning to maintainer. Thomas, upgrade from hylafax to hylafax+ breaks upgrade from mga4 to mga5.
Assignee: bugsquad => thomasSource RPM: (none) => hylafax+
Chris, can you see if there exists a bug report for get-skype already and open a specific bug report for it if needed?
Thanks. For get-skype; trying the package now works fine. I have opened a bug report there: https://bugs.mageia.org/show_bug.cgi?id=15782 but if this is really the skype website domain transiently failing; the package itself may not be faulty; that's why a safe option could be to just omit it; or maybe to move the package to update? Don't know.
(In reply to Chris Denice from comment #3) > I have just rebooted into my uncompleted upgraded mga4->mga5. > > Doing urpmi --auto-update reproduces the conflicting packages. It seems to > be all triggered by the upgrade from hylafax mga4 to hylafax mga5. > > Installation failed: > file /usr/sbin/faxsetup from install of > hylafax+-client-5.5.5-11.mga5.x86_64 conflicts > with file from package hylafax-1:5.5.0-6.mga4.x86_64 > file /usr/sbin/faxsetup.linux from install of > hylafax+-client-5.5.5-11.mga5.x86_64 conf > licts with file from package hylafax-1:5.5.0-6.mga4.x86_64 > > It looks like there is an epoch number in mga4 hylafax, plus de conflict due > to that file being moved from one package to the other. > > By removing "by hand" the mga4 hylafax package; urpmi --auto-update works > without anymore conflict. > > I am not a guru of epoch number and obsolete; that would be nice if someone > could have a look how to fix hylafax package (own by nobody). > > For get-skype, maybe we should ban that package for being upgraded? > > cheers. I will have a look later today. I need a mga4 with Hylafax on a VBOX
hylafax+ just needs to conflict with older hylafax Same for hylafax+-client. Just done in SVN. Please test
CC: (none) => thierry.vignaud
BTW this is not an installer issue but a packaging one
Component: Installer => RPM Packages
(In reply to Thierry Vignaud from comment #9) > hylafax+ just needs to conflict with older hylafax > Same for hylafax+-client. > > Just done in SVN. > Please test /usr/sbin/faxsetup and /usr/sbin/faxsetup.linux have been moved from hylafax to hylafax+-client. Shouldn't hylafax+-client conflict with older hylafax too?
Yes. Please do.
(In reply to Samuel VERSCHELDE from comment #11) > (In reply to Thierry Vignaud from comment #9) > > hylafax+ just needs to conflict with older hylafax > > Same for hylafax+-client. > > > > Just done in SVN. > > Please test > > /usr/sbin/faxsetup and /usr/sbin/faxsetup.linux have been moved from hylafax > to hylafax+-client. Shouldn't hylafax+-client conflict with older hylafax > too? I've added this conflicts and removed the ones tv added which shouldn't have been needed as there was already obsoletes for those. It should be good now. There's a pending freeze push request on the mailing list.
The hylafax issue should be fixed now in hylafax+-5.5.5-12.mga5. As for the mtink mga4 scriplet failure, I looked at it and see no apparent reason for that failure. It may possibly be related to Bug 15382 (which needs to be fixed in systemd). If that particular failure is still reproducible, please file a new bug for it.
Status: NEW => RESOLVEDResolution: (none) => FIXED
(In reply to David Walser from comment #14) > The hylafax issue should be fixed now in hylafax+-5.5.5-12.mga5. > > As for the mtink mga4 scriplet failure, I looked at it and see no apparent > reason for that failure. It may possibly be related to Bug 15382 (which > needs to be fixed in systemd). If that particular failure is still > reproducible, please file a new bug for it. Unfortunately not. The Conflicts: hylafax in hylafax+-client doesn't work as we say in halafax+ Provides: hylafax. I see if I can fix it today. I am not able to work on it tomorrow.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
OK, then the conflicts needs to be versioned.
Should be actually fixed now in hylafax+-5.5.5-13.mga5.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
Has someone actually tested it?
Hopefully someone will. Please reopen if it's not fixed. With the proper conflicts now correctly added, it should work.
CC: (none) => luigiwalser
Yep, and we would need someone doing a network install from a "dense" mga4 distro triggering as many possible package upgrades!
Well for this particular bug one just needs hylafax and hylafax-client installed. In general, yes, testing upgrades with as many packages as possible is useful.
(In reply to Samuel VERSCHELDE from comment #18) > Has someone actually tested it? I did an upgrade (urpmi --auto-update) from mga4 and it actually updated hylafax+ in the second round. But this isn't uncommon and there were a few other packages that upgraded the second round. What doesn't is bacula.
What do you mean second round? If something didn't upgrade properly, can you give proper logs so that we can try to identify the issue(s)?
(In reply to David Walser from comment #23) > What do you mean second round? If something didn't upgrade properly, can > you give proper logs so that we can try to identify the issue(s)? Tell me which log? I am glad to provide it. What I mean, sometimes you have to go a second round. This has been the case since the Mandriva days. For exemple mageia-gfxboot-theme-4.5.6.3-1.mga5 doesn't upgrade right now because some other, unrelated packages don't. See this: # urpmi --auto-select To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release (distrib1)") bacula-bat 7.0.5 13.mga5 x86_64 bacula-common 7.0.5 13.mga5 x86_64 bacula-console 7.0.5 13.mga5 x86_64 bacula-dir 7.0.5 13.mga5 x86_64 bacula-fd 7.0.5 13.mga5 x86_64 bacula-sd 7.0.5 13.mga5 x86_64 lib64bacula-sql7 7.0.5 13.mga5 x86_64 mageia-gfxboot-theme 4.5.6.3 1.mga5 x86_64 220KB of additional disk space will be used. 1.8MB of packages will be retrieved. Proceed with the installation of the 8 packages? (Y/n) rsync://mirrors.kernel.org/mageia/distrib/5/x86_64/media/core/release/mageia-gfxboot-theme-4.5.6.3-1.mga5.x86_64.rpm installing bacula-common-7.0.5-13.mga5.x86_64.rpm bacula-dir-7.0.5-13.mga5.x86_64.rpm bacula-bat-7.0.5-13.mga5.x86_64.rpm bacula-console-7.0.5-13.mga5.x86_64.rpm mageia-gfxboot-theme-4.5.6.3-1.mga5.x86_64.rpm bacula-fd-7.0.5-13.mga5.x86_64.rpm bacula-sd-7.0.5-13.mga5.x86_64.rpm lib64bacula-sql7-7.0.5-13.mga5.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ######################################################################################################### Installation failed: file /usr/lib64/libbaccats-mysql.so from install of lib64bacula-sql7-1:7.0.5-13.mga5.x86_64 conflicts with file from package lib64baccats-mysql5-1:5.2.13-3.4.mga4.x86_64
Please open another bug against bacula.
(In reply to Thomas Spuhler from comment #24) > Tell me which log? I am glad to provide it. If you upgraded with urpmi, there's an example on our wiki of how to do this using the tee command to copy the urpmi output to a log file. If you use the installer to do the upgrade, it creates some log files in /root/drakx which will show the urpmi errors. > What I mean, sometimes you have to go a second round. This has been the case > since the Mandriva days. Ideally, this should *never* be the case. If it is, it indicates a packaging bug that we need to fix, such as the issues we've just found with hylafax and now bacula. I believe hylafax is fixed now, hopefully bacula will be once it's freeze pushed. Your change looks good to me. It appears that the mysql5 subpackage has been renamed to sql7, so obsoletes would be correct.
(In reply to Thierry Vignaud from comment #25) > Please open another bug against bacula. Fixed by now.
(In reply to David Walser from comment #26) > (In reply to Thomas Spuhler from comment #24) > > Tell me which log? I am glad to provide it. > > If you upgraded with urpmi, there's an example on our wiki of how to do this > using the tee command to copy the urpmi output to a log file. I had to turn it off the virtual last night. My box doesn't have the resources to run the Virtual and all on services on the base system If you use > the installer to do the upgrade, it creates some log files in /root/drakx > which will show the urpmi errors. > > > What I mean, sometimes you have to go a second round. This has been the case > > since the Mandriva days. > > Ideally, this should *never* be the case. If it is, it indicates a > packaging bug that we need to fix, such as the issues we've just found with > hylafax and now bacula. I believe hylafax is fixed now, hopefully bacula > will be once it's freeze pushed. Your change looks good to me. It appears > that the mysql5 subpackage has been renamed to sql7, so obsoletes would be > correct.