Description of problem: Version-Release number of selected component (if applicable): yakuake-3.0.0-0.git20150801.2.mga6.src.rpm How reproducible: Steps to Reproduce: 1. On above netbook, install 64-bit Mageia-5, do complete Cauldron update and install Yakuake. 2. After Plasma5 login, "Yakuake started" report appears, but: 3. Login then freezes; blank screen after (2) except for hollow 'X' mouse pointer N.B. (1) If Yakuake is then uninstalled, subsequent Plasma5 logins succeed. (2) This problem does not manifest itself in same situation on desktop PC. Reproducible: Steps to Reproduce:
CC: (none) => marja11Assignee: bugsquad => rverschelde
Sorry I couldn't investigate yet. Is this issue still valid Maurice? I plan to do a cauldron install with plasma5 soon so I should be able to test too.
Will install Yakuake today and report, Rémi.
Still valid, I'm afraid. :-( Only difference from before is that the 'Starting Yakuake' message does not appear. Uninstalling Yakuake restores normal operation...
> ... the 'Starting Yakuake' message does not appear. However, if - during the post-login freeze - I hit F12, Yakuake appears - and works!
I pushed a new snapshot of yakuake. I'm not sure it will improve things (it shouldn't worsen them either), but I'd gladly here about it once you've done the update. On my side I upgraded to Cauldron today, and yakuake does not cause freezes but does not start at all :/
Just done 332-package Cauldron update on netbook, and installed yakuake*. Same old story, I'm afraid: After Plasma login, screen stays blank - no info on yakuake -though as before if I hit F12 yakuake then opens. (* "Version 2.9.9+, Using KDE Frameworks 5.18.0, Qt 5.6.0 (built against 5.6.0), xcb windowing system"
Thanks; I still can't reproduce even though I've managed to get yakuake working in the end, but for now it doesn't seem to start automatically for me. Could you try to rename the yakuake config files, e.g. with: $ mv ~/.kde4/share/config/yakuakerc ~/.kde4/share/config/yakuakerc_old $ mv ~/.kde4/share/config/yakuake.notifyrc ~/.kde4/share/config/yakuake.notifyrc_old
After again uninstalling yakuake, all was well after Plasma login, and those two files were already renamed: $ ls -A ~/.kde4/share/config/yakuake* /home/mab/.kde4/share/config/yakuake-old.notifyrc /home/mab/.kde4/share/config/yakuakerc-old
Blocks: (none) => 17523
Everything seems to work fine on plasma5 in a new unix user account with startx - F12 hides/shows yakuake fine.
CC: (none) => shlomif
Again same old story, I'm afraid: After Plasma login, screen stays blank (apart from hollow 'X' mouse pointer) - no info on yakuake -though as before if I hit F12 yakuake then opens and is usable.
is it still valid ?
CC: (none) => mageia
Have been unable to get a Plasma login with latest 32-bit classic ISO, so cannot check!
I really can't reproduce this bug so I'd be tempted to close it as WORKSFORME. If you can still reproduce it Maurice, it's likely that something is behaving weirdly in your user's config.
Source RPM: yakuake-3.0.0-0.git20150801.2.mga6.src.rpm => yakuake-3.0.2-1.mga6
Still can't say about 32-bit, as still can't get Plasma login on netbook: https://bugs.mageia.org/show_bug.cgi?id=18022 - but on 64-bit Yakuake often does start (via ~/.config/autostart), though on the shaky Plasma** on 64-bit desktop it sometimes fails to appear... ** See https://bugs.mageia.org/show_bug.cgi?id=18023 (Real h/w in both cases, using copy of Mageia-5 /home.)
Having now installed 20/6 32-bit Mageia-6-sta1 on the Samsung NC110 netbook, I find that Yakuake still blocks a Plasma session - i.e. once Yakuake is started all I see on the screen is a hollow white 'X'. Uninstall Yakake and all is well with Plasma... N.B. This is the first time I have been offered a Plasma login on this machine. Interestingly, this install is the first one where the newsreader Pan works! (See https://bugs.mageia.org/show_bug.cgi?id=18010 )
N.B. I start Yakuake from a ~/.config/autostart .desktop filr containing the 'exec: yakuake'.
No problem with Yakuake on 64-bit Mageia-6-sta1 Plasma login on desktop.
Was your 6sta1 32-bit install from comment 15 also using the same /home folder as your Mageia 5 account, or was it using a new account?
It uses a cloned copy of my Mageia-5 account.
Problem still there with 32-bit Mageia-6-RC installed on real h/w non-EFI non-GPT Samsung NC110 netbook. Had to use TTy2 to uninstall Yakuake before rebooting.
Sadly there's something in your Mageia 5 user account that triggers this bug, and since you always reuse this /home folder, you'll likely always get the bug. I could never reproduce it on my end. Could you upload all yakuake-related files that you have in your /home? You should be able to locate them with (might take a minute or two to process): `find | grep yakuake` in your home folder. Here I have: ~/.config/autostart/org.kde.yakuake.desktop // configured myself else it does not autostart ~/.config/yakuakerc ~/.local/share/yakuake ~/.local/share/yakuake/Profile 1.profile
$ find | grep yakuake ./.config/yakuakerc ./.local/share/yakuake ./.local/share/yakuake/Profile 1.profile ./.kde4/share/config/yakuake.notifyrc ./.kde4/share/config/yakuakerc
Could you zip those files and attach them here, so that I can see if I reproduce the issue with your config?
Not being a Zip user, the required syntax is elusive! According to 'man zip' I suspect it is something like: find . -name "*yakuake*" -print | zip source -@ If you can verify that, I will give it a try when I've finished cooking lunch here by the seaside in Hampshire...
(In reply to Maurice Batey from comment #24) > Not being a Zip user, the required syntax is elusive! > > According to 'man zip' I suspect it is something like: > > find . -name "*yakuake*" -print | zip source -@ > > If you can verify that, I will give it a try when I've finished cooking > lunch here by the seaside in Hampshire... Try : zip -r source.zip `find . -name '*yakuake*' -print` Untested!
Created attachment 8226 [details] zip of all *yakuake* files in /home/user As requested.
Hi Maurice and sorry for the delay. I've had a look at your files and don't see much that could trigger this issue at a first glance. I'll try to replace my own files with yours and see if I can reproduce. In parallel, could you try renaming/removing all the yakuake-related files of your home listed above, and see if it fixes the bug or if you can still reproduce it? If you can still reproduce it, it would mean that something else without "yakuake" in its name would cause the issue.
Tried this: Hid ~/.config/yakuakerc (This file does not appear in my Mageia-5 installation - only ~/.kde4/share/config yakuakerc & yakuake.notifyrc, which are present in the cloned Mageia-5 /home given to Mageia-6.) After re-installing Yakuake, the result was that it created another ~/.config/yakuakerc file - but still caused the login sequence to then freeze. Finally, I repeated the above, but ALSO hid the above 2 ex-Mageia-5 files. RESULT: Login completed normally, Yakuake works normally, and Yakuake did NOT create new instances of those 2 files. CONCLUSION: No problem if ~/.kde4/share/config yakuakerc & yakuake.notifyrc are absent. [However, they ARE present in my 64-bit Mageia-6 on desktop, and have not caused yakuake to misbehave...]
Thanks Maurice, I'll try to get in touch with the upstream devs to see if it should be discussed further upstream as a compatibility issue.
(In reply to Rémi Verschelde from comment #29) > Thanks Maurice, I'll try to get in touch with the upstream devs to see if it > should be discussed further upstream as a compatibility issue. Still haven't done that, but I'll try to in the coming days.
Keywords: (none) => UPSTREAM
I've started a 1,440-package Cauldron update going on the netbook, and will check the situation after re-booting after that and report back. (The netbook is really struggling to cope with Plasma, so might eventually have to stay with Mageia-5 on it, for as long as possible, before replacing it.)
Just rebooted after the huge update: No change. As soon as Yakuake is started (via start.sh), it is usable but login startup does not continue beyond the startup of Yakuake, as before.
Comment 28 said: "CONCLUSION: No problem if ~/.kde4/share/config yakuakerc & yakuake.notifyrc are absent." - but this is no longer true! ============== After the Cauldron update yesterday I removed the above 2 files, but the problem persists - i.e. even then the login fails to continue after Yakuake is started. As before, if yakuake is uninstalled, after reboot the login continues normally.
No longer a problem!
Resolving.
Really resolving now - thanks!
Resolution: (none) => FIXEDStatus: NEW => RESOLVED