Remi requested feedback from MGA5-MGA6 upgrades. I did one from a fresh install of MGA5 in a VBox VM and an upgrade to MGA6 in the same VM. There were 65 failed transactions. There were two sets of logs, ddebug.log/1 and install.log/1 as well as report.bug.xz. I'll attach them all. I'll keep the VM disk in case you want anything else.
Created attachment 9277 [details] ddebug.log
Created attachment 9278 [details] ddebug.log1
Created attachment 9279 [details] install.log
Created attachment 9280 [details] install.log1
Created attachment 9281 [details] report.bug
Comment on attachment 9278 [details] ddebug.log1 Thanks, Frank. report.bug, install.log1 and ddebug.log1 are from the Mga5 install, install.log and ddebug.log are from the upgrade. I'll obsolete the Mga5 logs.
CC: (none) => marja11 Attachment 9278 is obsolete: 0 => 1
Attachment 9280 is obsolete: 0 => 1
Attachment 9281 is obsolete: 0 => 1
Sorry, the logs drive me crazy, I don't know how to handle them. Assigning to the mageiatools maintainers, even if drakx-installer-stage2 isn't the culprit, because people like Thierry (btw, congrats with your newborn!) will be capable of extracting the needed information from the logs, and tell which packages are to blame.
Assignee: bugsquad => mageiatools
The attachment in Comment 3 shows conflicts in some KDE packages (plasma-desktop-handbook and plasma-workspace-handbook with kde-l10n-handbooks-*). That's the only thing that looks like a legitimate packaging error. The rest looks like urpmi being silly.
CC: (none) => kde
(In reply to David Walser from comment #8) > The attachment in Comment 3 shows conflicts in some KDE packages > (plasma-desktop-handbook and plasma-workspace-handbook with > kde-l10n-handbooks-*). That's the only thing that looks like a legitimate > packaging error. The rest looks like urpmi being silly. thx, David. Re-assigning
Assignee: mageiatools => kdePriority: Normal => release_blocker
Please test new plasma-desktop and plasma-workspace
CC: (none) => mageia
Please reopen if still valid with new rpms
Status: NEW => RESOLVEDResolution: (none) => FIXED
Probably not the same plasma rpms, feel free to reassign...
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
i need debugs infos.
Created attachment 9297 [details] ddebug.log
Attachment 9277 is obsolete: 0 => 1
Created attachment 9298 [details] install.log install.log and ddebug.log from current test
Attachment 9279 is obsolete: 0 => 1
Agggh. Please disregard. I attached the logs from the wrong system. Correcting now...
Created attachment 9299 [details] ddebug.log
Attachment 9297 is obsolete: 0 => 1
Created attachment 9300 [details] install.log
Attachment 9298 is obsolete: 0 => 1
Installation failed: file /usr/share/doc/HTML/de/kfontview/index.docbook from install of plasma-desktop-handbook-5.8.6-7.mga6.noarch conflicts with file from package kde-l10n-handbooks-de-4.14.3-1.mga5.noarch file /usr/share/doc/HTML/de/knetattach/index.docbook from install of plasma-desktop-handbook-5.8.6-7.mga6.noarch conflicts with file from package kde-l10n-handbooks-de-4.14.3-1.mga5.noarch file /usr/share/doc/HTML/de/plasma-desktop/index.docbook from install of plasma-desktop-handbook-5.8.6-7.mga6.noarch conflicts with file from package kde-l10n-handbooks-de-4.14.3-1.mga5.noarch file /usr/share/doc/HTML/de/kfontview/index.cache.bz2 from install of plasma-desktop-handbook-5.8.6-7.mga6.noarch conflicts with file from package kde-l10n-handbooks-de-4.14.3-1.mga5.noarch file /usr/share/doc/HTML/de/knetattach/index.cache.bz2 from install of plasma-desktop-handbook-5.8.6-7.mga6.noarch conflicts with file from package kde-l10n-handbooks-de-4.14.3-1.mga5.noarch file /usr/share/doc/HTML/de/plasma-desktop/index.cache.bz2 from install of plasma-desktop-handbook-5.8.6-7.mga6.noarch conflicts with file from package kde-l10n-handbooks-de-4.14.3-1.mga5.noarch file /usr/share/doc/HTML/it/plasma-desktop/index.docbook from install of plasma-desktop-handbook-5.8.6-7.mga6.noarch conflicts with file from package kde-l10n-handbooks-it-4.14.3-1.mga5.noarch file /usr/share/doc/HTML/it/plasma-desktop/index.cache.bz2 from install of plasma-desktop-handbook-5.8.6-7.mga6.noarch conflicts with file from package kde-l10n-handbooks-it-4.14.3-1.mga5.noarch file /usr/share/doc/HTML/de/klipper/index.docbook from install of plasma-workspace-handbook-5.8.6-8.mga6.noarch conflicts with file from package kde-l10n-handbooks-de-4.14.3-1.mga5.noarch file /usr/share/doc/HTML/de/klipper/index.cache.bz2 from install of plasma-workspace-handbook-5.8.6-8.mga6.noarch conflicts with file from package kde-l10n-handbooks-de-4.14.3-1.mga5.noarch The fixed packages are: plasma-workspace-handbook-5.8.6-9.mga6.noarch and plasma-desktop-5.8.6-8.mga6 Please reopen if still valid with them.
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED
Created attachment 9304 [details] ddebug.log
Attachment 9299 is obsolete: 0 => 1
Created attachment 9305 [details] install.log
Attachment 9300 is obsolete: 0 => 1
Still the same number of conflicts (65).
I'm redoing the MGA5 VBox install and copying off the .vdi file so that I can rerun this test by doing a dd copy and MGA6 upgrade (which fails fairly soon after starting) instead of waiting for the MGA5 install (which takes several hours). Is 65 some kind of magic urpmi or install number ? Could there be thousands of these conflicts and the install quits after finding 65 ? If so, we could be cycling through these tests for quite awhile.
The transaction size for urpmi is set 'All' or 50 whichever is less. If there are 50 or less rpms which need to be installed they will all be done in 1 transaction. If there are more than 50 rpms which need to be installed they will be installed in multiple transactions of 50 until all are installed. Because of this if there is any issues in Requires|Provides|Conflicts|Obsoletes Or in the order with which each rpm is installed, it can easily cause the transaction to fail. It is the same issue you saw Sat. with the Caulron gdb dnf-utils maven updates.
CC: (none) => cae
So what is the path forward on this ? Should the transaction size in install urpmi be expanded to All ? Why is it not to begin with ? This is really starting to get ridiculous. Initially, I would have to use --split-level=1 --split-length=1 just to force installation of packages which had nothing to do with failing packages but just happened to be bundled into transaction sets that included failing packages for no better reason than they were next up. Now I have to abandon --auto-select because urpmi can't figure out dependencies unless I specify a subset of packages by name ?
You still have the old versions of the packages Nicolas fixed in comment 19: Installation failed: file /usr/share/doc/HTML/de/kfontview/index.docbook from install of plasma-desktop-handbook-5.8.6-7.mga6.noarch conflicts with file from package kde-l10n-handbooks-de-4.14.3-1.mga5.noarch file /usr/share/doc/HTML/de/klipper/index.docbook from install of plasma-workspace-handbook-5.8.6-8.mga6.noarch conflicts with file from package kde-l10n-handbooks-de-4.14.3-1.mga5.noarch So it's expected that it would still fail. If you are upgrading using the DVD, you need to make sure to enable update mirrors to get the latest packages. If using urpmi, check that your mirrors are up-to-date and have the right versions of those packages.
Created attachment 9308 [details] ddebug.log
Attachment 9304 is obsolete: 0 => 1
Created attachment 9309 [details] install.log
Attachment 9305 is obsolete: 0 => 1
Looks like I uploaded the wrong files last time around. But I checked manually in my cauldron mirror for the packages Nicholas named, and redid the install. Still getting a failure of 65 packages, but slightly different names.
I've noticed some plasma updates go by; should I try this again ?
Please yes
Created attachment 9336 [details] ddebug.log
Attachment 9308 is obsolete: 0 => 1
Created attachment 9337 [details] install.log
Attachment 9309 is obsolete: 0 => 1
Unfortunately, similar result. This time the number of errors shown was 68. I have to repurpose this machine for about a week starting this evening, so I won't be able to retest until then. But the reproducible case is pretty simple (if time-consuming).
should be OK now. Please reopen if still valid for you
Well done ! I reran the upgrade today, and not a single error.