| Summary: | Mga5 RC upgrade from mga4 failed with scripts error and package conflicts | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Chris Denice <eatdirt> |
| Component: | RPM Packages | Assignee: | Thomas Spuhler <thomas> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | release_blocker | CC: | luigiwalser, thierry.vignaud |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | hylafax+ | CVE: | |
| Status comment: | |||
| Bug Depends on: | |||
| Bug Blocks: | 14069 | ||
| Attachments: |
dumped report file after first failure
dumped report file after second failure |
||
|
Description
Chris Denice
2015-04-27 17:38:44 CEST
Created attachment 6380 [details]
dumped report file after first failure
Created attachment 6381 [details]
dumped report file after second failure
Samuel Verschelde
2015-04-27 17:56:32 CEST
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 =>
thomas 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 =>
RESOLVED (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 =>
REOPENED OK, then the conflicts needs to be versioned. Should be actually fixed now in hylafax+-5.5.5-13.mga5. Status:
REOPENED =>
RESOLVED 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. |