Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Fresh install of 64-bit Mgeia-5 (on real (nVidia) hardware) 2. Switch to Cauldron media 3. urpmi --auto-update --auto --test 4. See update failure log in 'URL' section above Reproducible: Steps to Reproduce:
CC: (none) => maurice
Created attachment 6941 [details] doc failures
CC: (none) => bittwister2
for comment #1: Is it better now ? for Comment #0: i can't read your link it is not "complete", i just can read: Preparing... ######################################################################################################## Installation failed: file /usr/share/doc
CC: (none) => mageia
Created attachment 6942 [details] Latest update --test
Comment on attachment 6942 [details] Latest update --test change to text
Attachment 6942 mime type: text/x-log => text/plain
Attachment 6941 is obsolete: 0 => 1
Please test with latest runtime ( kdebase4-runtime-15.08.0-3.mga6 )
Please wait for kdebase4-runtime-15.08.0-4.mga6, should fix the knetattach error
Created attachment 6944 [details] Latest update --test getting better.
Attachment 6942 is obsolete: 0 => 1
Created attachment 6945 [details] Urpmi log of 'urpmi --auto-update --auto --test on Cauldron Here is the text of the urpmi log originally pointed to above at 'URL' (and which I can read (with Mageia-5 Firefox) fully from the Dropbox URL!) Hope this helps.
> Please wait for kdebase4-runtime-15.08.0-4.mga6, should fix > the knetattach error When might this be available, please, Nicolas?
(In reply to Maurice Batey from comment #9) > Created attachment 6945 [details] > Urpmi log of 'urpmi --auto-update --auto --test on Cauldron > > Here is the text of the urpmi log originally pointed to above at 'URL' > (and which I can read (with Mageia-5 Firefox) fully from the Dropbox URL!) We can also read the attachment in itself fully, but you did not attach the full output of what should have been printed in the terminal. It is not normal that the log ends with: "Installation failed: file /usr/share/doc" All the relevant information should be right after that, just as in the logs from Bit Twister. (In reply to Maurice Batey from comment #10) > > Please wait for kdebase4-runtime-15.08.0-4.mga6, should fix > > the knetattach error > > When might this be available, please, Nicolas? It is available now in Core Release.
> It is not normal that the log ends with: > "Installation failed: file /usr/share/doc" In that case there's a bug in urpmi, because that log was one of the files in the output directory from urpmi's "--bug <directory>" option! Have made note to raise bug report... (The problem I've found with copying the console output is that it is impossible to scroll to the start so as to 'select all' for a copy. Considered using 'urpmi ..... >> urpmi=log', but then nothing would appear on screen, presumably? I'm sure there is a solution to that, which I would be happy to learn...)
(In reply to Maurice Batey from comment #12) > > It is not normal that the log ends with: > > "Installation failed: file /usr/share/doc" > > In that case there's a bug in urpmi, because that log was one of the files > in the output directory from urpmi's "--bug <directory>" option! > Have made note to raise bug report... Ah indeed that would be worth reporting if you can check that the console output with "--bug" has more info than the log produced by the --bug switch. > > (The problem I've found with copying the console output is that it is > impossible to scroll to the start so as to 'select all' for a copy. > Considered using 'urpmi ..... >> urpmi=log', but then nothing would appear > on screen, presumably? According to https://www.linuxquestions.org/questions/linux-software-2/bash-how-to-redirect-output-to-file-and-still-have-it-on-screen-412611/ you should be able to do this with: # urpmi ... | tee urpmi.log Haven't tried it yet though :)
Created attachment 6946 [details] Log of 'urpmi --auto-update --auto --test' on cauldron 14:10 21.8.2015 Herewith attachment of urpmi ...--test log, with --bug & also | tee <log> I.e. still no install...
(In reply to Maurice Batey from comment #14) > Created attachment 6946 [details] > Log of 'urpmi --auto-update --auto --test' on cauldron 14:10 21.8.2015 > > Herewith attachment of urpmi ...--test log, with --bug & also | tee <log> My pull_updates script uses screen -c "urpmi cmds here" pull_updates.log That scrolls output to screen and into pull_updates.log file. (In reply to Maurice Batey from comment #12) The problem I've found with copying the console output is that it is impossible to scroll to the start so as to 'select all' for a copy. Maybe you could use a larger history buffer. Mine is set with HISTSIZE=1000 in /etc/profile for all users. (In reply to Maurice Batey from comment #10) When might kdebase4-runtime-15.08.0-4.mga6 be available, please, Nicolas? Better question is when is it available on your selected mirror. I had to "ls /etc/urpmi/urpmi.cfg/kdebase4-runtime-15.08.0-4*" after each pull_updates run to know when I could re-test. That was after I saw it complete at http://pkgsubmit.mageia.org/
it is available on my mirror. ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/core/release/kdebase4-runtime-15.08.0-4.mga6.x86_64.rpm
> Maybe you could use a larger history buffer. Mine is set with HISTSIZE=1000 > in /etc/profile for all users. Same here - shall up it to e.g. 1500... > I had to "ls /etc/urpmi/urpmi.cfg/kdebase4-runtime-15.08.0-4*" after each > pull_updates run to know when I could re-test. Thanks - will give that a try!
> I had to "ls /etc/urpmi/urpmi.cfg/kdebase4-runtime-15.08.0-4*" after each > pull_updates run to know when I could re-test Your media setup seems to be different from mine, whose urpmi.cfg is of the form: ================================ } Core\ Release { key-ids: 80420f66 mirrorlist: http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list with-dir: media/core/release } Core\ Release\ Debug { ignore mirrorlist: http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list with-dir: media/debug/core/release } Core\ Updates { key-ids: 80420f66 mirrorlist: http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list update ...=================================
(In reply to Maurice Batey from comment #18) > > I had to "ls /etc/urpmi/urpmi.cfg/kdebase4-runtime-15.08.0-4*" after each > > pull_updates run to know when I could re-test > > Your media setup seems to be different from mine, whose urpmi.cfg is of > the form: Ooops, my bad, and I need to get some sleep. Should have been ls /var/cache/urpmi/rpms/kdebase4-runtime-15.08.0-4*
> Should have been > ls /var/cache/urpmi/rpms/kdebase4-runtime-15.08.0-4* Ah, yes - there it is! Anyway, because somehow the install got screwed up I had to re-install Mageia-5 and start again. This time I got a "Can install" conclusion from urpmi --test, but at the same time it said that: ------------------------------ Installation is possible While some packages may have been installed, there were failures. Some requested packages cannot be installed: libreoffice-pdfimport-5.0.0.2-5.mga6.x86_64 (due to unsatisfied libpoppler.so.52()(64bit)) telepathy-kde-accounts-kcm-15.07.90-2.mga6.x86_64 (due to unsatisfied telepathy-kde-auth-handler[== 15.07.90]) telepathy-kde-contact-list-15.08.0-1.mga6.x86_64 (due to unsatisfied telepathy-kde-accounts-kcm[== 15.08.0]) telepathy-kde-desktop-applets-15.08.0-1.mga6.x86_64 (due to unsatisfied telepathy-kde-contact-list-15.08.0-1.mga6.i586) --------------- So, is it wise to nevertheless go ahead with the install? (I did start that, but then it reported e.g.: "http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/tainted/release/media_info/20150820-232721-synthesis.hdlist.cz retrieval of [ftp://www.mirrorservice.org/sites/mageia.org/pub/mageia/distrib/cauldron/x86_64/media/tainted/release/media_info/synthesis.hdlist.cz] failed (md5sum mismatch) problem reading synthesis file of medium "Tainted Release"" - so aborted the update there. Will keep trying until there are no such reports...
(In reply to Maurice Batey from comment #20) > > ------------------------------ > Installation is possible > While some packages may have been installed, there were failures. > Some requested packages cannot be installed: > libreoffice-pdfimport-5.0.0.2-5.mga6.x86_64 (due to unsatisfied > libpoppler.so.52()(64bit)) > telepathy-kde-accounts-kcm-15.07.90-2.mga6.x86_64 (due to unsatisfied > telepathy-kde-auth-handler[== 15.07.90]) > telepathy-kde-contact-list-15.08.0-1.mga6.x86_64 (due to unsatisfied > telepathy-kde-accounts-kcm[== 15.08.0]) > telepathy-kde-desktop-applets-15.08.0-1.mga6.x86_64 (due to unsatisfied > telepathy-kde-contact-list-15.08.0-1.mga6.i586) > --------------- > > So, is it wise to nevertheless go ahead with the install? Feel free to go ahead, those packages will only not be updated, and they are not critical components. Those issues will be sorted out eventually and you will be able to update those packages too. > (I did start that, but then it reported e.g.: > > "http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: > media/tainted/release/media_info/20150820-232721-synthesis.hdlist.cz > retrieval of > [ftp://www.mirrorservice.org/sites/mageia.org/pub/mageia/distrib/cauldron/ > x86_64/media/tainted/release/media_info/synthesis.hdlist.cz] failed (md5sum > mismatch) > problem reading synthesis file of medium "Tainted Release"" Yeah that's a typical issue with Cauldron where mirror are sometimes badly synced due to the ever-changing primary mirrors. Try again later, or try another mirror, or both :)
(In reply to Maurice Batey from comment #20) > > Should have been > > ls /var/cache/urpmi/rpms/kdebase4-runtime-15.08.0-4* > > Ah, yes - there it is! > > Anyway, because somehow the install got screwed up I had to re-install > Mageia-5 and start again. Yep, I can recommend a VirtualBox install on your host, creating a mga5 guest, install updates, reboot, clone mga5 to mga6, change it to cauldron, pull down all updates, then clone mga6 to mga6_clone. Now you can run mga6_clone to test if mirror/packages are ready, and if updates are usable. Since I have a test bed box, I'll then test on real hardware. > (I did start install, but then it reported e.g.: > > [ftp://www.mirrorservice.org/sites/mageia.org/pub/mageia/distrib/cauldron/ > x86_64/media/tainted/release/media_info/synthesis.hdlist.cz] failed (md5sum > mismatch) > > Will keep trying until there are no such reports... What can happen is your mirror syncs during the time primary mirror is updating synthesis files and/or packages winding up with a bad copy. I am having the same problem and will have to wait another hour for the next mirror sync to see if I can proceed. Longest wait has been 3 hours when there is high activity on build system. Both my pull_updates and install_updates scripts runs the media update again, to verify all the synthesis.hdlist.cz are up to date before trying the pull/install. Code snippet: script -e -c "echo ' ' ; urpmi.update --wait-lock $_loader_args -a" $_exe_log _play_fault=$? fault_check if [ $_play_fault -ne 0 ] ; then /local/bin/play_fatal & exit 1 fi fault_check function checks for these fault/failure words: _faults='error|fail|mismatch|missing|invalid|problem|unsatisfied|conflicts'
Created attachment 6948 [details] 1st clean initial plasma update log! 22/8/2015 Finally - just after breakfast on a Saturday morning - my first complete initial plasma update (apart from the handful of packages that cannot yet be installed). However, after reboot, I'm still with apparently vanilla Mageia-5! I see that task-plasma5-minimal is installed, and suspect that it remains for me to 'start plasma'. How is that done, please (presumably as Root)?
Created attachment 6949 [details] Log of 2nd Cauldron update 23/8/2015 ('urpmi --test' = "Installation possible)"
Created attachment 6950 [details] Log of 3rd Cauldron update 23/8/2015 (urpmi...--test: Installation possible")
Created attachment 6951 [details] Log of 4th Cauldron update 23/8/2015 (urpmi..--test: "Installation possible")
Created attachment 6952 [details] Log of 5/5 Cauldron updates 23.8.2015 (urpmi..--test: "Installation possible") After the above 4 further Cauldron updates on Mageia-5, I am not only still without any sight of Plasma, but Yakuake now fails: ================= "Yakuake was unable to load the Konsole component. A Konsole installation is required to use Yakuake." $64 question still: How to get into Plasma5?! ======================= Also, how to get Akonadi to start so that KMail will work? (see next posting)
Created attachment 6953 [details] Log of starting Kmail in console session (Akonadi not available)
Created attachment 6954 [details] (From Kmail start failure w.r.t. Akonadi) Akonadi self-test report Above 2 attachments are w.r.t. to Akonadi failure at KMail start. So, the problems here are now: (1) No sign of Plasma5 (task-plasma5 is installed) (2) Kmail start immediately halts after Akonadi not starting (3) Yakuake no longer starts. N.B. I'm postponing installation of my other usual apps until Plasma5 is working. Happy to spend more time if it will help the general cause! ;-)
P.S. Note that the above attached 'plasma-update' logs all end up showing many different installation failures all starting with various forms of the same file spec: "/usr/share/locale/en_GB/LC_MESSAGES/kded_ktp_approver.mo from install of kde-l10n-en_GB-15.08.0-1.mga6.noarch conflicts with file from package telepathy-kde-approver-0.9.0-1.mga5.x86_64"
(In reply to Maurice Batey from comment #29) > Created attachment 6954 [details] > (From Kmail start failure w.r.t. Akonadi) Akonadi self-test report > > Above 2 attachments are w.r.t. to Akonadi failure at KMail start. > > So, the problems here are now: > > (1) No sign of Plasma5 (task-plasma5 is installed) > (2) Kmail start immediately halts after Akonadi not starting > (3) Yakuake no longer starts. > > N.B. I'm postponing installation of my other usual apps until Plasma5 is > working. > > Happy to spend more time if it will help the general cause! ;-) Please this is a bugreport about files conflicts do not mix several issues on the same bugreport.
> this is a bugreport about files conflicts That's what most of the logs I have attached demonstrate! I have not raised bug reports for Kmail or Yakuake, because I believe the problem is not *within* those apps, but in the way they are worked into the new framework, i.e. environment conflicts. As to getting into Plasma5, as no one here has volunteered to let me in on the secret, could you tell me where I might more successfully find out, please? :-)
you will be able to use Plasma when "all" needed rpms will install. Translations conflicts may be fixed with next kde-l10n
OK, will hold off until then, whenever that may be. Thank you for the clarification. (In the meantime I'll go and get the BBQ cleaned out; no more excuses. :-) )
any news of the tests ? :)
Created attachment 6962 [details] (bt) urpmi --downloader wget --auto --auto-update --test
Attachment 6944 is obsolete: 0 => 1
Created attachment 6974 [details] (MB) Log of cauldron update 27/8/15
Created attachment 6975 [details] (MB) Log of 'journalctl -xb' at system freeze after Plasma login + 1 app start
Today after '--test' run reported "Can install", did a 420-package Cauldron update ("urpmi --auto-update --auto"). Apart from the following package all went well, *and* after reboot I was able to login to Plasma (only other Login options: IceWM, Failsafe): --------------------------------------------------------------- While some packages may have been installed, there were failures. A requested package cannot be installed: libkexiv2_11-15.08.0-1.mga6.i586 (due to unsatisfied libkexiv2[== 2:15.08.0-1.mga6]) ---------------------------------------------------------------- On logging in to Plasma, I see the blue astronomy screen with the cauldron & bubbles, plus - in the panel along the foot of the screen - many of the icons for apps that the Mageia-5 /home clone had set. However, whatever icon I select, the result is a complete freeze. For example, if I select the /home icon on desktop (the only icon there, in fact), then before the freeze I see in the 'action' section of the panel the name of the app (e.g. "Dolphin" in the above case) - or "System Settings" if that had been selected - and 2 opposing arcs (which I imagine are suppose to rotate to signify 'hang on') [See above 2 attachments for logs of above situations.]
I'm very happy to report that - after a clean 109-package update today - I now the Plasma5 update of Mageia-5 is now working normally here (using a cloned Mageia-5 /home), on real (nVidia) hardware, and quite zippily! Basic apps check out OK, pan worked, and even system-config-printer installed my HP5520 1st time! Will later check on Dropbox, VirtualBox, Skype etc. Congratulations and many thanks to all who have made this possible. Very much appreciated...
> Basic apps check out OK But not kmail (from icon): "Sorry -Plasma KDEInit coud not launch /usr/bin/kmail" Kmail started fom terminal session: [mab@localhost ~]$ kmail kmail: symbol lookup error: /lib64/libKF5AkonadiSearchPIM.so.5: undefined symbol: _ZNK6Xapian13PostingSource9serialiseEv [root@localhost ~]# urpmi kmail Package kmail-15.07.90-1.mga6.x86_64 is already installed
VirtualBox, gparted, dolphin, Thunderbird (38.2) OK. Konqueror unusable; kwrite has diminished GUI. Although Dropbox installs, 'dropbox start -i' does not provide a 'live' icon to access the Dropbox folder (although 'dropbox puburl <file>' will yield Dropbox URL).
for kmail i am waiting for help for a build issue ( files conflicts ), when this will be solved we will be ableto build a new kmail. for dropbox see : http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/
Merci mille fois for the update on Kmail... Apps OK: + Yakuake, LibreOffice (Writer), MCC.
App's OK: + kompozer, vlc, gkrellm + skype (except that pavucontrol u/s) Problem app's: + xsane: Does not find e.g. HP5520 all-in-one + kalarm (same failure as kmail) $ kalarm kalarm: symbol lookup error: /lib64/libKF5AkonadiSearchPIM.so.5: undefined symbol: _ZNK6Xapian13PostingSource9serialiseEv + Okular (fails to open doc's > 1 page, and locks up for 30-40 seconds) + Pavucontrol not available: $ /usr/bin/pavucontrol Segmentation fault
> Although Dropbox installs, 'dropbox start -i' does not provide a 'live' icon > to access the Dropbox folder (although 'dropbox puburl <file>' will yield > Dropbox URL). Workround: nautilus ~/Dropbox (Assuming nautilus-dropbox has been installed) (Will await return of the systray...) Apps OK: + Google-Earth works (32-bit) + Kpat Apps broken: + kmahjongg urpmi kmahjongg A requested package cannot be installed: kmahjongg-4.14.3-1.mga5.x86_64 (due to unsatisfied libkmahjongglib.so.4() (64bit))
Created attachment 6991 [details] (bt) urpmi --downloader wget --auto --auto-update --test
Attachment 6962 is obsolete: 0 => 1
Re; Kwrite (& Kate) Current version not only short on GUI options (nor does R.mouse bring up Copy/Cut/Paste options), but there is an odd difference between starting empty and starting with a file. If started with no file argument, the toolbar etc. options respond immediately. However, if opened with even a modest-sized text file, it is totally unresponsive for almost a minute.
Puzzle with 64-bit Mageia-5 update to Cauldron on Samsung NC110 netbook: After installing 1,100+ packages and seeing "Packages are up to date" from 'urpmi --auto-update --auto --test', the reboot Login screen still does not offer 'Plasma' (shows 'KDE' instead, and after login all I see is a blank screen apart from the mouse pointer X). Next step?!
(In reply to Maurice Batey from comment #49) > Puzzle with 64-bit Mageia-5 update to Cauldron on Samsung NC110 netbook: > > After installing 1,100+ packages Just 1K+ packages, must be nice. My update hangs on disabled services. 444/2077: colord Bug report opened. While waiting for a reply, might I suggest marking any obsolete Attachments, obsolete to help save wasting someone's time looking at them. > and seeing "Packages are up to date" > from 'urpmi --auto-update --auto --test', the reboot Login screen still > does not offer 'Plasma' (shows 'KDE' instead, and after login all I see is a > blank screen apart from the mouse pointer X). > > Next step?! I would boot run level3, get to a root prompt, and see if running XFdrake picking defaults and reboot will help. If that fails, I would try again picking Xorg Vesa driver, reboot to see what happens. I would do both reboot attempts at run level 3 and after login, try startx to see if /var/log/Xorg.0.log or/and ~/.xsession-errors any anything useful.
Created attachment 7000 [details] 'journalctl -xb' after Cauldron boot on netbook shows blank user screen after login > (netbook) reboot Login screen still does not offer 'Plasma' (shows >'KDE' instead, and after login all I see is a blank screen apart from the > mouse pointer X). Just tried again, and noticed that not only did the screen briefly show "Yakuake installed F12" (from user startup init), but with a blank screen if P12 is pressed I get a Yakuake terminal session, from which I could run e.g. Dolphin. Herewith attached root's copy of 'journalctl -xb' for the Cauldron bootup (on fully updated Cauldron), though I cannot see any evidence of why Plasma5 was not offered at Login. Perhaps the netbook's limited resources failed some criteria?
> I suggest marking any obsolete Attachments, obsolete to help save wasting > someone's time looking at them. Not done so far in case they might still prove useful. (Doesn't seem to save space, as can still be browsed.) Could not find an 'obsolete' function, except when adding another attachment. Is the list shown then only of one's own attachments?
(In reply to Maurice Batey from comment #52) > > I suggest marking any obsolete Attachments, obsolete to help save wasting > > someone's time looking at them. > > Not done so far in case they might still prove useful. I do not see how obsolete failures that have been fixed is going to help. > (Doesn't seem to save space, as can still be browsed.) I was not arguing about disk space. Just a waste of dev/packagers time. Each clean full upgrade will still show failures in original list. > Could not find an 'obsolete' function, except when adding another > attachment. Is the list shown then only of one's own attachments? No. That is why I added my initials to my attachments. That way I would easily identify my attachments and obsolete my previous one. Now that you seem to be up to date on cauldron, I would think failures would be against packages instead of mga5 to mga6 upgrades.
>> Is the list shown then only of one's own attachments? > No. That is why I added my initials to my attachments. Have just checked that list against my own list, and it does, in fact, only list my own. But only when I next make an Attach can I obsolete the older ones.
> ...how to get Akonadi to start so that KMail will work? Noted in the Gentoo & Debian worlds: GENTOO: (Nov 2014) We cannot install both qt4 and qt5 versions of akonadi-server, so no kmail 4.x on Plasma 5, or anything else that uses kdepimlibs (kgpg for instance). (DEBIAN: 1/9/2015) So bye, bye kmail for a short time. kdepim-runtime already is installed. So there may only be a reworked kdepim package missing in order to have it installable in gcc 5 sid. Debian Qt/KDE team already works on this.
> Puzzle with 64-bit Mageia-5 update to Cauldron on Samsung NC110 netbook: Two other odds things noticed: (1) When booting, Cauldron momentarily shows "Starting 225" on top left of screen, whereas on the PC it shows "Starting 224". (2) On the Cauldron login screen, as well as not offering 'Plasma', the nationality flag shown is GB, whereas on PC it shows USA (perhaps because KDE not Plasma).
please do not make it a "garbage bugreport". sddm bugreport goes to a new bugreport. This is a bugreport not a mailing list.
The last information was more of a "might like to know" than a report of a bug, and I didn't see any bug reporting material there. Just trying to be helpful! Also I had mistakenly got the feeling that Cauldron was not yet a draft product of any sort, and that bug reports would not be welcome at such an early stage. For example, the non-appearance of Kmail, which I assume not to be a problem *within* Kmail, but rather in the plasmafication conversion process. Thank you for confirming I was wrong; I stand corrected and will launch some bug reports to keep on the 'straight & narrow'...
Created attachment 7006 [details] (MB) Log of Cauldron update 14/9/2015, after which no login to Plasma After several weeks of successful login to Plasma5, after the Cauldron update shown in this attachment a Plasma login attempt now gets me dumped into what appears to be IceWM, with no warning message. (This is on real h/w (nVidia).) Will keep on updating in hope normality is restored...
Attachment 6945 is obsolete: 0 => 1 Attachment 6946 is obsolete: 0 => 1 Attachment 6948 is obsolete: 0 => 1 Attachment 6949 is obsolete: 0 => 1 Attachment 6950 is obsolete: 0 => 1 Attachment 6952 is obsolete: 0 => 1 Attachment 6953 is obsolete: 0 => 1 Attachment 6954 is obsolete: 0 => 1 Attachment 6974 is obsolete: 0 => 1 Attachment 6975 is obsolete: 0 => 1
(In reply to Maurice Batey from comment #59) > After several weeks of successful login to Plasma5, after the Cauldron > update shown in this attachment a Plasma login attempt now gets me dumped > into what appears to be IceWM, with no warning message. (This is on real > h/w (nVidia).) Yes, about a week or so back, another clean mga5 install + mga6 updates did the same thing to my VirtualBox mga6 guest.
(In reply to Maurice Batey from comment #59) > Created attachment 7006 [details] > (MB) Log of Cauldron update 14/9/2015, after which no login to Plasma > > After several weeks of successful login to Plasma5, after the Cauldron > update shown in this attachment a Plasma login attempt now gets me dumped > into what appears to be IceWM, with no warning message. (This is on real > h/w (nVidia).) > > Will keep on updating in hope normality is restored... see https://bugs.mageia.org/show_bug.cgi?id=16725
> see https://bugs.mageia.org/show_bug.cgi?id=16725 That's about a Cauldron update on my netbook that has never before offered a 'plasma' login until that update, and has never successfully logged into Plasma5. At least yesterday's regression on PC did not freeze after Plasma login, just dropped me into a minimum DM. Either way, both are now dead in the water, apart from the ability to do more updates. (Not complaining!; just thought might be helpful to report....)
(In reply to Maurice Batey from comment #59) > After several weeks of successful login to Plasma5, after the Cauldron > update shown in this attachment a Plasma login attempt now gets me dumped > into what appears to be IceWM, with no warning message. (This is on real > h/w (nVidia).) > Exactly the same happened on my system. I noticed, however, that "Plasma" was now listed twice in the session selection drop-down. Selecting the second entry brought me back to the Plasma desktop. After the update my /usr/share/xsessions directory contains both the previous 02Plasma.desktop and a new plasma.desktop
02Plasma.desktop is the "old way" to add entries in the DM and plasma.desktop the new one.
> I noticed, however, that "Plasma" was now listed twice in the session > selection drop-down. Selecting the second entry brought me back to the Plasma > desktop. Hey, you're so right! Presumably need to delete the 02Plasma.desktop from /usr/share/xsessions? (Sadly, although the 2 Plasma's are also on the netbook's login menu, whichever is chosen the blank screen result still occurs.)
> skype (except that pavucontrol u/s) Pulseaudio now working under Skype!
> $ kalarm > kalarm: symbol lookup error: /lib64/libKF5AkonadiSearchPIM.so.5: > undefined symbol: _ZNK6Xapian13PostingSource9serialiseEv After today's Cauldron update, Kalarm now starts and appears to work normally. (However, it opened with an empty list, which I was, however, able to populate by importing from an existing saved list.
> system-config-printer installed my HP5520 1st time! But HPLIP shows a 'communication error' and cannot give status/supplies info. Also, Xsane cannot find the printer.
> Xsane cannot find the printer. Have added comment to https://bugs.mageia.org/show_bug.cgi?id=16253.
Created attachment 7054 [details] (MB) Log of Cauldron update today after which no Plasma login offered After that Cauldron update today, on reboot no Plasma login was offered (only IceWM). Will keep on updating (via Tty2) in hope it clears. (Also noted at start of Cauldron - before update - the whole Libreffice suite had disappeared; had to re-install it.)
Attachment 6951 is obsolete: 0 => 1 Attachment 6991 is obsolete: 0 => 1
Cauldron update yesterday ailed after installation of 8/345 packages: Preparing... ############################################# 1/345: dkms-minimal ############################################# 2/345: libncurses-devel ############################################# 3/345: kernel-desktop-devel-4.4.0-0.rc8.1.mga6 ############################################# 4/345: lib64oxygenstyleconfig5_5 ############################################# 5/345: oxygen ############################################# 6/345: plasma-workspace ############################################# 7/345: dkms ############################################# 8/345: x11-driver-video-nouveau ############################################# 1/6: removing dkms-2.0.19-34.mga5.noarch ############################################# 2/6: removing plasma-workspace-5.4.95-2.mga6.x86_64 ############################################# 3/6: removing dkms-minimal-2.0.19-34.mga5.noarch ############################################# 4/6: removing oxygen-5.4.95-1.mga6.x86_64 ############################################# 5/6: removing lib64oxygenstyleconfig5_5-5.4.95-1.mga6.x86_64 ############################################# 6/6: removing x11-driver-video-nouveau-1.0.11-10.20151008.8.mga6.x86_64 ############################################# The following packages have bad signatures: /var/cache/urpmi/rpms/apache-commons-logging-1.2-4.mga6.noarch.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/geronimo-jms-1.1.1-21.mga6.noarch.rpm: Missing signature (OK ((none)))
(In reply to Maurice Batey from comment #71) > Cauldron update yesterday ailed after installation of 8/345 packages: > > The following packages have bad signatures: > /var/cache/urpmi/rpms/apache-commons-logging-1.2-4.mga6.noarch.rpm: Missing > signature (OK ((none))) > /var/cache/urpmi/rpms/geronimo-jms-1.1.1-21.mga6.noarch.rpm: Missing > signature (OK ((none))) That's not a failure per se, as it should allow you to continue by ignoring the missing signatures. The issue is also tracked in bug 17434. This bug report has been quite useful to get some general feedback about issues upgrading from mga5 IMO, but now cauldron is in a relatively better state, so I'd propose to close it, and go with more specific bug reports for each issue from now on (maybe creating specific bugs from some of the things you reported here if they are still relevant). WDYT?
Status: NEW => RESOLVEDResolution: (none) => FIXED
(In reply to Rémi Verschelde from comment #72) > > That's not a failure per se, as it should allow you to continue by ignoring > the missing signatures. The issue is also tracked in bug 17434. > > > This bug report has been quite useful to get some general feedback about > issues upgrading from mga5 IMO, but now cauldron is in a relatively better > state, so I'd propose to close it, and go with more specific bug reports for > each issue from now on (maybe creating specific bugs from some of the things > you reported here if they are still relevant). WDYT? As for me I have no problem tracking specific problems. But, everyone doing triage needs to know about reverting to "normal bug reporting" if we are going specific. See bug 17435#c1
(In reply to Bit Twister from comment #73) > As for me I have no problem tracking specific problems. But, everyone doing > triage needs to know about reverting to "normal bug reporting" if we are > going specific. See bug 17435#c1 First, please don't take it personally when a bug report is closed as a duplicate. Eventually it's the call of the triage team to decide what should have its own issue and what should be just added to an existing issue. The triage team can of course be wrong, and you are welcome to make it known if that's your opinion. In the case of bug 17435, you reported two symptoms in two different bug reports. As a bug reporter, that's _exactly_ what you are expected to do, and that's great, keep doing that. And thanks for taking the time to do it :) Then the bug triagers have some knowledge of what's going on in cauldron, and they know that the java stack is currently an impressive mess, and that sysadmins had to build packages locally and move them to the BS to unbreak the stack, hence the missing signature. So all java packages with missing signature can be considered symptoms of the same bug. Same bug as they have the same resolution: mass rebuild of the java stack (or of the whole distro maybe). So marja renamed your first bug report to make it more general and related to the whole java stack, also adding a comment to explain her triage choice and that the bug is meant as a reminder. When the mass rebuild is done, this bug will be closed and all packages with missing signatures should be signed, so there is no risk that your duplicated issue will end up forgotten. But the rule for any bug reporter in any libre project is still the same: make simple, atomic bug reports that developers can fix hopefully with one change/set of changes, and not a long list of all bugs you found while testing. It can happen that all those bugs have the same cause, and if so knowledgeable developers or bug triagers will make them duplicates of the bug that best describes the root cause, but it can also happen that they are completely unrelated, or that some of them are unrelated.
(In reply to Rémi Verschelde from comment #74) > (In reply to Bit Twister from comment #73) > > As for me I have no problem tracking specific problems. But, everyone doing > > triage needs to know about reverting to "normal bug reporting" if we are > > going specific. See bug 17435#c1 > So marja renamed your first bug report to make it more general and related > to the whole java stack, also adding a comment to explain her triage choice > and that the bug is meant as a reminder. When the mass rebuild is done, this > bug will be closed and all packages with missing signatures should be > signed, so there is no risk that your duplicated issue will end up forgotten. I hear where you are coming from, but it is a critical problem to anyone attempting a clean network install. Those missing signatures defeat the install of the package. What would be ideal would be to have a cauldron program to fix the missing signature on the mirror. I am not worried about the issue being forgotten. I keep a file of all my bug reports with a status indicator. 17530 - mga6: plymouth-reboot is delaying reboots 14737 r 4: k3b not saving sub directory files. 14324 w 5a2: tuxmathscrabble Admin does not run 17382 d (17236) mga6: mcc fails to run from root command line
I've finally abandoned my attempt to achieve a Cauldron update of Mageia-5 on the netbook, and done a clean install of Mageia-6-dev1 instead. (Sadly, it did not offer a Plasma login, but eventually I was able to complete a 100-packge s/w update, so will check that out tomorrow, though so far the system has been running abysmally slowly (e.g. 3 minutes for Network Center to appear when started).