Re: Plasma 6 in Debian?
Hi. Shmerl - 25.04.24, 23:05:06 CEST: > Now that the 64-bit time_t transition is mostly unblocked, will we see > Plasma 6 packaged soon? Mostly unblocked? While there are quite some transitions at 100% more are scheduled and there are still uninstallable / not upgradeable packages¹. The churn of what might be the biggest and longest "we break everything and then some for the greater good" transformation of Debian I remember is still not fully settled. Members of the Debian Qt/KDE team are working on packages and uploading to experimental since quite a while already. Most of them KF6 related. Due to new names most, if not all, of them need to go through NEW. Those appear to get accepted by ftpmasters quite smoothly at the moment, but it still needs additional time. Also AFAIR there an updated set of KF5 packages needs to go to unstable first. I think it was due to some packages need to be provided as 5 and 6 versions and some missing features in the older KF5 packages currently in Debian preventing that, but I am not sure I got the exact explanation right. To summarize all of this in a short way: From what I have read it is to early to predict when Plasma 6 will hit Debian unstable. At the moment as far as I have seen KF6 is not yet completed. Then you need Plasma 6 and enough of KDE Gear 6 for it to make sense. Unfortunately asking "when it may be" does not speed up the process. If you can offer some help, I'd recommend to drop by in their chat and ask where you could help most efficiently. I answered this to the best of my knowledge from what I have seen in IRC chat of the team and in Debian's devel-changes mailing list. Hopefully this will save team members some time for answering here that they can spend on packaging work or for recreational purposes – it is understandable that someone does not choose to use 100% of their free time for packaging work :). They are all doing it in their spare time and writing an explanatory mail like this also takes time. Please correct if any of the above is not accurate. [1] https://release.debian.org/transitions/ Best, -- Martin
Re: If you are on Sid, just don't update at the moment (not Plasma/KDE related)
Martin Steigerwald - 22.07.23, 15:30:43 CEST: > libgudev-1.0-0 is broken in sid due to missing versioned udev > dependency. Which means no keyboard on X11, maybe Wayland too, no > fwupdmgr and I bet also crashes in xdg-desktop-portal file requester > when changing to external disk. > > Version 237-2 is fine. > > Broken due to missed udev dependencies > > https://bugs.debian.org/1041703 This bug is likely related to eudev not advertising a new enough udev version yet. libudev1 in Sid instead should be recent enough, so in case you use regular udev you likely won't see the issue. Best, -- Martin
Re: If you are on Sid, just don't update at the moment (not Plasma/KDE related)
Martin Steigerwald - 22.07.23, 15:30:43 CEST: > libgudev-1.0-0 is broken in sid due to missing versioned udev > dependency. Which means no keyboard on X11, maybe Wayland too, no > fwupdmgr and I bet also crashes in xdg-desktop-portal file requester > when changing to external disk. > > Version 237-2 is fine. In case you updated, and did not reboot yet, I recommend you grab yourself a copy of 237-2 and install that, *before* rebooting. Unless you happen to prefer a non working keyboard and mouse input in sddm. wget https://ftp.debian.org/debian/pool/main/libg/libgudev/ libgudev-1.0-0_237-2_amd64.deb Best, -- Martin
If you are on Sid, just don't update at the moment (not Plasma/KDE related)
Hi! libgudev-1.0-0 is broken in sid due to missing versioned udev dependency. Which means no keyboard on X11, maybe Wayland too, no fwupdmgr and I bet also crashes in xdg-desktop-portal file requester when changing to external disk. Version 237-2 is fine. Broken due to missed udev dependencies https://bugs.debian.org/1041703 Best, -- Martin
Re: Question about Plasma 5.27.5 and Frameworks 5.106
Hi, Aurélien COUDERC - 19.05.23, 14:41:44 CEST: > Le 19 mai 2023 13:11:01 GMT+02:00, Luc Castermans a écrit : > >Dear > > > >I just upgraded the machine which was messed up earlier, fixed later, > >using: > > > >aptitude install -t experimental '~i ~V5\.27\.2' > >aptitude install -t experimental '~i ~V5\.103\.0' > > You probably meant 104 for the second command otherwise I don't see > the point. The version you specify is the version you like to upgrade to experimental. So 103 is about right. I will postpone upgrading to 5.104 a bit longer. So far all is fine and Plasma 5.27.5 works nicely. Thanks, -- Martin
Re: Question about Plasma 5.27.5 and Frameworks 5.106
Sedat Dilek - 19.05.23, 11:24:18 CEST: > In my email-client: > Reply: Martin Steigerwald > Reply-all: Martin Steigerwald + ML <--- My default (dropping you each > time is extra-time for me as well) Well it is easy: I provided support. I did not ask for support. In case I decide to limit my time in providing support I will first drop answering to mails that are in copy to me. I.e. your mails. It is simple as that, cause I decide how I spend my time. And I may limit it, especially in case I feel a lack of respect for the time I use to help others along. There can be reasons for CC to make someone aware of a mail one may otherwise miss. I don't need that. Especially I don't need that for a low volume mailing list like this. For each CC'd mail I receive two copies of the mail with mailing lists for the Debian community – mailing lists for the KDE community are set up differently. In case I reply to the wrong one, I break the thread. And it just happened with that thread already. I simply do not like to deal with this kind of hassle by default. Also please look at this Code of Conduct for Debian mailing lists: "When replying to messages on the mailing list, do not send a carbon copy (CC) to the original poster unless they explicitly request to be copied." https://www.debian.org/MailingLists/#codeofconduct Now you either respect my wish, or you don't. And I decide what I do with that. Best, -- Martin
Re: Question about Plasma 5.27.5 and Frameworks 5.106
Dear Aurélien Aurélien COUDERC - 19.05.23, 10:09:56 CEST: > But please don't contact the release team directly nor comment on the > unblock bug report about bit, it would only add noise and make our > case more difficult. Thanks for your clarification. I thought so as well as an aftermath of my mail and recommended not to send anything to the unblock bug report in another mail. Also thanks for your confirmation regarding KF. Best, -- Martin
Re: Question about Plasma 5.27.5 and Frameworks 5.106
Luc Castermans - 19.05.23, 09:38:23 CEST: > On one machine I performed a > > apt upgrade -t experimental Without limiting the set of packages to upgrade? If so, you likely have installed all packages from experimental, possibly including some that are really experimental. One may argue whether experimental is the right place for bug fix updates during the release cycle, but it is used that way. However outside of release cycle it is used for test versions of software. So you may have installed all kinds of funny and really unstable stuff on your system. Don't do that! I'd never ever do that. I posted the exact aptitude call for a reason. However maybe I am going to refrain from posting the exact commands again, so that people need to figure it out themselves and learn about the possible consequences. Anyway, you get you keep the pieces if anything breaks. > After which I needed to make few corrections on non-KDE related > packages. The machine is running fine!! As far as you can see after just a few minutes. Best, -- Martin
Re: Question about Plasma 5.27.5 and Frameworks 5.106
No need to copy me directly. Actually I prefer that you do not. Creates extra work for me. Sedat Dilek - 19.05.23, 09:28:46 CEST: > Did you install and test KDE/Frameworks version 5.104? No. I am not aware of any plans to get KDE Frameworks 5.104 or later into Bookworm. AFAIK Frameworks consists of a lot more packages than Plasma. I don't see how KDE Frameworks 5.104 or later can still enter Bookworm before the release. So I'd rather test with 5.103 for now. If that works well I intend to give a feedback there. Then I may still decide to upgrade KF to 5.104. I wonder whether it might be a good idea to allow for an update during the stable cycle. Ciao, -- Martin
Re: Question about Plasma 5.27.5 and Frameworks 5.106
Martin Steigerwald - 19.05.23, 09:19:31 CEST: > I recommend against posting to the bug report, the Qt/KDE team is > doing a marvelous job at arguing in favor of having at least the > packages with changes or at least with non-cosmetic changes from > 5.27.5 in Bookworm. Please let them do their job. […] Or in favor of having all of Plasma 5.27.5 in a point release for Bookworm. For me both approaches would work well. The point is to get those bug fixes into stable. For my machines it does not matter, I am following unstable anyway. However for some machines I administrate for others it makes a difference. Ciao, -- Martin
Re: Question about Plasma 5.27.5 and Frameworks 5.106
Hi, Martin Steigerwald - 19.05.23, 09:00:37 CEST: > Luc Castermans - 16.05.23, 07:11:33 CEST: > > On top and for the record. > > > > I installed all of KDE, plasma 5.25.5 etc. from Experimental > > yesterday. The upgrade went smooth, all worked well. > > Installing as well. > > I don't know whether it helps if some users "vote" for its stability? > But I am willing to do so if after a few days of test there is no > regression compared to the current state. Please keep in mind that the release team raised valid concerns. And on any account it is important to treat them with respect. They are doing a challenging job on a challenging time frame. You know Debian Stable is called stable for a reason! To ensure that it requires excellent cooperation between the package developers and the release time. Please respect that. I recommend against posting to the bug report, the Qt/KDE team is doing a marvelous job at arguing in favor of having at least the packages with changes or at least with non-cosmetic changes from 5.27.5 in Bookworm. Please let them do their job. In case you installed 5.27.5 from experimental, tested it and like to vote on its stability, please do so here. And for not on the bug report. Someone from the Qt/KDE team can point to the thread with the votes if need be. Plasma 5.27.5 installed here. % aptitude install -t experimental '~i ~V5\.27\.2' % dpkg -l | grep "5\.27\.2" [… no output …] I bet there is a variant for this for "apt" as well, but I never looked it up. Please only do so if you are willing to help testing and are careful about reading apt/aptitude output and about aborting the process in case it likes to remove packages you'd rather want to keep. Here I had no issues with upgrading, but that does not mean that it works on your system as well. Best, -- Martin
Re: Question about Plasma 5.27.5 and Frameworks 5.106
Hi Luc. Luc Castermans - 16.05.23, 07:11:33 CEST: > On top and for the record. > > I installed all of KDE, plasma 5.25.5 etc. from Experimental > yesterday. The upgrade went smooth, all worked well. Installing as well. I don't know whether it helps if some users "vote" for its stability? But I am willing to do so if after a few days of test there is no regression compared to the current state. Ciao, -- Martin
Re: Question about Plasma 5.27.5 and Frameworks 5.106
Hi Merlin, Merlin Cooper - 15.05.23, 16:35:59 CEST: > Are there any plans to upload Plasma 5.27.5 and Frameworks 5.106 to > Unstable and unblock them for inclusion in Testing? The Full Freeze > is coming up soon, and Unstable / Testing are still stuck on Plasma > 5.27.2 and Frameworks 5.103. The newer versions fix tons of bugs > (including many Wayland bugs), so their inclusion in Debian 12 would > be supremely appreciated by Debian KDE users. Please see bug #1035056 [pre-approval] plasma-desktop 5.27.X https://bugs.debian.org/1035056 As well as IRC channel #debian-qt-kde Best, -- Martin
Re: Postpone update
Lisandro Damián Nicanor Pérez Meyer - 13.04.23, 01:30:20 CEST: > I have just uploaded qtbase-opensource-src again, this time with a > fixed patch. It should be accepted in some minutes and you will > probably have the binaries in the mirrors in a few hours. I have > tested the changes myself on my main system and everything looks good, > but please chime if something odd happens. > > Thanks for your patience, we are dealing with a a11y (accessibility) > issue when Qt applications are being run as root. 5.15.8+dfsg-7 works well for me. KRunner works. Screen can be locked and unlocked again. Note, not all Qt related packages are at this version number. I looked at version number of libqt5gui5 and a sane output of apt full-upgrade to determine whether it would be safe to update with the current state of the mirror I use. Thank you. Best, -- Martin
Re: Postpone update
Hi Lisandro! Lisandro Damián Nicanor Pérez Meyer - 13.04.23, 01:30:20 CEST: > I have just uploaded qtbase-opensource-src again, this time with a > fixed patch. It should be accepted in some minutes and you will > probably have the binaries in the mirrors in a few hours. I have > tested the changes myself on my main system and everything looks good, > but please chime if something odd happens. Thanks dearly for the timely fix! > Thanks for your patience, we are dealing with a a11y (accessibility) > issue when Qt applications are being run as root. Yeah, I noticed the repeated uploads of Qt. Seems this has been quite challenging to get right! Thank you all from the Debian/Kubuntu Qt/KDE team! I appreciate your work! Best, -- Martin
Postpone update
Hi! If you have not yet updated to most recent Qt 5.15.8+dfsg-6 and are still on 5.15.8+dfsg-3 or something like that, I suggest you postpone the upgrade. There are issues with Plasma with most recent Qt 5.15.8+dfsg-6. I am aware of the following two: 1) Screen cannot be locked. After locking screen desktop is basically frozen but still shown. 2) Krunner segfaults, thus neither Alt-Space and in case still configure Alt-F2 will work. There may be other issues. Debian Qt/KDE Team is aware of it. No need to report it. I do not know any further details and the version number for the last working version above is just a rough bet. Thanks, -- Martin
Re: Plasma with Wayland: No ssh-agent started automatically?
Shmerl - 19.02.23, 04:21:16 CET: > I've been using KDE Wayland session for a while, but I also switched > to systemd boot for KDE, may be that helped with ssh-agent. > > Here are some details: > https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/ > > > To enable it: > > kwriteconfig5 --file startkderc --group General --key systemdBoot true > > Not sure about kick-off issues, I'm using fullscreen Aplication > Dashboard, and it works fine. Haha, no systemd running here. But good tip that is could be related to the way Plasma is starting up. > If you have some problems with Wayland session - better report bugs, > so they wouldn't get lost. I've reported a bunch in the past, and > they were fixed. Sure. Just currently not much time for that, so much other stuff. Best, -- Martin
Re: Plasma with Wayland: No ssh-agent started automatically?
Martin Steigerwald - 14.02.23, 22:27:16 CET: > Do I really need to start ssh-agent by hand with Plasma (Wayland) > session type? Never mind. That is not the only issue. Kick off menu with scaling 150% spanning the whole 1920x1080 laptop screen and artifacts while typing in Konsole are other issues with Wayland. That still does not appear to be ready for me. Maybe some day. Thanks, -- Martin
Plasma with Wayland: No ssh-agent started automatically?
Hi! I just switched the session type from Plasma (X11) to Plasma (Wayland). No ssh-agent is started automatically anymore. There is an older forum post about this: ssh-agent not started in Wayland https://forum.kde.org/viewtopic.php?t=153769 Do I really need to start ssh-agent by hand with Plasma (Wayland) session type? Thanks, -- Martin
Re: Runit with KDE Plasma: krunner current working directory /
Reinhard Karcher - 10.02.23, 15:20:49 CET: > I have a different system: Debian SID/Testing with usrmerge, systemd > and bash, and I see the expected behavior: cwd linked to /home/USER. > So I suspect, that it is not caused by KDE/QT. Just for the record: Sometimes the truth is not that digital. It appears to be that there is a relation with an upstream change that affects anything except Systemd. krunner starts applications with cwd "/" with init system other than systemd (openrc, runit, ...) https://bugs.kde.org/432975 Plasma appears to use different code paths for systemd and non systemd startup: https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/ Will be looking with upstream and/or Debian's other init team whether a solution can be found or… apply a work-around. Best, Martin > Am Freitag, 10. Februar 2023, 14:39 schrieb Martin Steigerwald: > > Hi! > > > > This puzzled me for a long time and I have no idea where to report > > this: > > > > …proc# ls -ld $(pidof krunner)/cwd > > lrwxrwxrwx 1 USER USER 0 10. Feb 14:26 15116/cwd -> / > > …proc# ls -ld $(pidof plasmashell)/cwd > > lrwxrwxrwx 1 USER USER 0 10. Feb 14:27 9191/cwd -> /home/USER > > > > This is with /bin/sh pointing to Dash, the user shell is Z-Shell, > > but I have also seen this on systems where the user shell is Bash. > > No usrmerge. (I hope to avoid it as long as possible.) > > > > According to pstree krunner's parent process is runit which of > > course > > has current working directory pointing to /. > > > > Plasmashell instead is going like this > > > > ├─runsv(2066)─┬─sddm(2116)─┬ > > > > ─sddm-helper(8989)───startplasma-x11(8994)─┬─plasma_session(9056)─┬ > > > > I bet through SDDM its working directory is set to the actual home > > directory of the user. > > > > Is this a bug with runit? Is this an upstream bug? > > > > Any idea how to find the root cause for this and determine what > > needs to be fixed? > > > > I tried to work around this by doing "cd $HOME" in my zshrc. However > > this makes open new tabs in Konsole always start at $HOME even when > > I > > open them with a tab active which has a different cwd. Yeah, I got > > only do "cd $HOME" if current working directory is /, but I'd > > rather see this fixed. However, I do not even know where to report > > this issue. > > > > Any insight greatly appreciated. -- Martin
Re: Runit with KDE Plasma: krunner current working directory /
Reinhard Karcher - 10.02.23, 15:20:49 CET: > I have a different system: Debian SID/Testing with usrmerge, systemd > and bash, and I see the expected behavior: cwd linked to /home/USER. > So I suspect, that it is not caused by KDE/QT. Just for the record: Sometimes the truth is not that digital. It appears to be that there is a relation with an upstream change that affects anything except Systemd. krunner starts applications with cwd "/" with init system other than systemd (openrc, runit, ...) https://bugs.kde.org/432975 Plasma appears to use different code paths for systemd and non systemd startup: https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/ Will be looking with upstream and/or Debian's other init team whether a solution can be found or… apply a work-around. Best, Martin > Am Freitag, 10. Februar 2023, 14:39 schrieb Martin Steigerwald: > > Hi! > > > > This puzzled me for a long time and I have no idea where to report > > this: > > > > …proc# ls -ld $(pidof krunner)/cwd > > lrwxrwxrwx 1 USER USER 0 10. Feb 14:26 15116/cwd -> / > > …proc# ls -ld $(pidof plasmashell)/cwd > > lrwxrwxrwx 1 USER USER 0 10. Feb 14:27 9191/cwd -> /home/USER > > > > This is with /bin/sh pointing to Dash, the user shell is Z-Shell, > > but I have also seen this on systems where the user shell is Bash. > > No usrmerge. (I hope to avoid it as long as possible.) > > > > According to pstree krunner's parent process is runit which of > > course > > has current working directory pointing to /. > > > > Plasmashell instead is going like this > > > > ├─runsv(2066)─┬─sddm(2116)─┬ > > > > ─sddm-helper(8989)───startplasma-x11(8994)─┬─plasma_session(9056)─┬ > > > > I bet through SDDM its working directory is set to the actual home > > directory of the user. > > > > Is this a bug with runit? Is this an upstream bug? > > > > Any idea how to find the root cause for this and determine what > > needs to be fixed? > > > > I tried to work around this by doing "cd $HOME" in my zshrc. However > > this makes open new tabs in Konsole always start at $HOME even when > > I > > open them with a tab active which has a different cwd. Yeah, I got > > only do "cd $HOME" if current working directory is /, but I'd > > rather see this fixed. However, I do not even know where to report > > this issue. > > > > Any insight greatly appreciated. -- Martin
Runit with KDE Plasma: krunner current working directory /
Hi! This puzzled me for a long time and I have no idea where to report this: …proc# ls -ld $(pidof krunner)/cwd lrwxrwxrwx 1 USER USER 0 10. Feb 14:26 15116/cwd -> / …proc# ls -ld $(pidof plasmashell)/cwd lrwxrwxrwx 1 USER USER 0 10. Feb 14:27 9191/cwd -> /home/USER This is with /bin/sh pointing to Dash, the user shell is Z-Shell, but I have also seen this on systems where the user shell is Bash. No usrmerge. (I hope to avoid it as long as possible.) According to pstree krunner's parent process is runit which of course has current working directory pointing to /. Plasmashell instead is going like this ├─runsv(2066)─┬─sddm(2116)─┬ ─sddm-helper(8989)───startplasma-x11(8994)─┬─plasma_session(9056)─┬ I bet through SDDM its working directory is set to the actual home directory of the user. Is this a bug with runit? Is this an upstream bug? Any idea how to find the root cause for this and determine what needs to be fixed? I tried to work around this by doing "cd $HOME" in my zshrc. However this makes open new tabs in Konsole always start at $HOME even when I open them with a tab active which has a different cwd. Yeah, I got only do "cd $HOME" if current working directory is /, but I'd rather see this fixed. However, I do not even know where to report this issue. Any insight greatly appreciated. Best, -- Martin
Re: Bookworm upgrade to 5.26.90 resulted in a huge App Launcher icon size
Timothy M Butterworth - 01.02.23, 09:10:11 CET: > I'm on 5.26.90 and mine looks normal. Have you tried creating a new > user account to see if it works properly? It may depend whether control panel is horizontal or vertical. I believe vertical ones to be affected. -- Martin
Re: Bookworm upgrade to 5.26.90 resulted in a huge App Launcher icon size
Hi. local10 - 01.02.23, 07:40:47 CET: > The latest Bookworm upgrade to 5.26.90 [1] resulted in the Application > Launcher widget's icon becoming a huge, ridiculous size[2]. It's now > about 10 times larger than what it used to be before the upgrade and, > respectively, takes 10x times more space on the task bar. AFAIR there was some upstream change regarding the application launcher widget icon. I believe I have read about it in some Plasma update blog posts from Nate Graham¹. It became larger here too, not 10 times, but visibly, especially the space around it. There is a needless large space around it. > Any ideas? Thanks I suggest you to look for an upstream bug report at https://bugs.kde.org and if there is not one already reported, report it. In case upstream fixes this timely, it probably can be patched in the Debian package for Bookworm still. [1] https://pointieststick.com Best, -- Martin
Re: Plasma 5.27 beta (5.26.90) coming to unstable
Aurélien COUDERC - 25.01.23, 18:43:35 CET: > Le 25 janvier 2023 17:07:14 GMT+01:00, Martin Steigerwald > a écrit : > >Aurélien COUDERC - 25.01.23, 11:21:01 CET: > >> >Could you check with the lxqt that they do the rebuild quickly > >> >enough that we don't break more things ? > >> > >> Actually don't, there are more packages involved, I'm handling this > >> with the release team to fix the situation. > >> > >> Thank for raising the issue. > > > >Thanks, Aurélien. > > > >I am not in a hurry. Basically I just installed lxqt to have some > >desktop at hand in case Plasma would not start up for some reason. > > When is the last time this actually happens? Long time ago actually. Maybe time to drop that old habit :) I still remember that an even longer time ago I needed to install some GTK based desktop, cause Qt was completely broke. But that is really a long long long time ago. Ciao, -- Martin
Re: Plasma 5.27 beta (5.26.90) coming to unstable
Aurélien COUDERC - 25.01.23, 11:21:01 CET: > >Could you check with the lxqt that they do the rebuild quickly enough > >that we don't break more things ? > Actually don't, there are more packages involved, I'm handling this > with the release team to fix the situation. > > Thank for raising the issue. Thanks, Aurélien. I am not in a hurry. Basically I just installed lxqt to have some desktop at hand in case Plasma would not start up for some reason. But maybe I better use simple GTK based desktop for that :) Ciao, -- Martin
Re: Plasma 5.27 beta (5.26.90) coming to unstable
Martin Steigerwald - 25.01.23, 08:23:53 CET: > > FWIW: kscreen version 4:5.26.90-1 (now) depends on libkf5screen8 > > That is key as I found out this morning before reading your mail :) > > lxqt packages were blocking the upgrade to libkf5screen8. > > Now explicitly installed libkf5screen8 which triggered the removal of > some lxqt packages. So it seems there needs to be a binary rebuild of > some lxqt packages. I don't get why aptitude did not offer this as a solution. -- Martin
Re: Plasma 5.27 beta (5.26.90) coming to unstable
Diederik de Haas - 24.01.23, 14:53:29 CET: > On Tuesday, 24 January 2023 11:58:25 CET Martin Steigerwald wrote: > > Ah, held back due to libkf5screen7 still at 4:5.26.5-1 > > FWIW: kscreen version 4:5.26.90-1 (now) depends on libkf5screen8 That is key as I found out this morning before reading your mail :) lxqt packages were blocking the upgrade to libkf5screen8. Now explicitly installed libkf5screen8 which triggered the removal of some lxqt packages. So it seems there needs to be a binary rebuild of some lxqt packages. > I did not have libkf5screen7 installed, even though I do have kscreen > installed. What seems odd is that kscreen is now at version > 4:5.26.90-1, but libkf5screen8 is not installed or available ... > while it is a depends (>= 4:5.26.90) ?!? libkf5screen8 is available here as version 4:5.26.90-2. > So far everything seems to be working fine here \o/ Will report back. Best, -- Martin
Re: Plasma 5.27 beta (5.26.90) coming to unstable
Miguel A. Vallejo - 24.01.23, 22:09:49 CET: > My apt only finds version 5.26.90-1 That is 5.27 beta. Thanks, -- Martin
Re: Plasma 5.27 beta (5.26.90) coming to unstable
Martin Steigerwald - 24.01.23, 12:00:52 CET: > Martin Steigerwald - 24.01.23, 11:58:25 CET: > > Yep that is version mismatch between plasma-workspace-date (5.27 > > beta) and plasma-workspace (5.26 although beta is available in repo > > already). > > > > Ah, held back due to libkf5screen7 still at 4:5.26.5-1 > > I bet that is the cause for missing backdrop images as well. Cause > they are remembered and set in configuration. But the backdrop image > is not yet loaded. So likely will be okay again once I upgrade > libkf5screen7 to 5.27 beta. > > So better wait even if "apt upgrade" would update parts of Plasma > already, wait till it updates all of Plasma. Yap, downgrading plasma-workspace-data to 5.26 fixed both the calender issue and the wallpaper not loaded issue. So in case you run into it, make sure plasma-workspace and plasma- workspace-data versions agree with one another. -- Martin
Re: Plasma 5.27 beta (5.26.90) coming to unstable
Martin Steigerwald - 24.01.23, 11:58:25 CET: > Yep that is version mismatch between plasma-workspace-date (5.27 beta) > and plasma-workspace (5.26 although beta is available in repo > already). > > Ah, held back due to libkf5screen7 still at 4:5.26.5-1 I bet that is the cause for missing backdrop images as well. Cause they are remembered and set in configuration. But the backdrop image is not yet loaded. So likely will be okay again once I upgrade libkf5screen7 to 5.27 beta. So better wait even if "apt upgrade" would update parts of Plasma already, wait till it updates all of Plasma. -- Martin
Re: Plasma 5.27 beta (5.26.90) coming to unstable
Martin Steigerwald - 24.01.23, 11:51:44 CET: > Martin Steigerwald - 24.01.23, 09:18:53 CET: > > Already updated what I could with "apt upgrade". Will try again > > later today. […] > Haha, probably better wait, but could also be a fallout from the multi > monitor changes: All backdrop images from my activities are gone. I > will configure for some activities again, so see whether they are > remembered then. The other containments settings are remembered. So control panels I configured are still there. Another little issue is: Calendar in systray does not open, but I bet this is a temporary issue due to partial update: file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ ui/main.qml:80:34: Type CalendarView unavailable file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ ui/CalendarView.qml:604:13: Cannot assign to non-existent property "eventButton" Yep that is version mismatch between plasma-workspace-date (5.27 beta) and plasma-workspace (5.26 although beta is available in repo already). Ah, held back due to libkf5screen7 still at 4:5.26.5-1 My recommendation: Wait still all packages are at 5.27. As far as I understand later meta packages are upgrade to require 5.27 as minimum version, so that should be a temporary issue. Ciao, -- Martin
Re: Plasma 5.27 beta (5.26.90) coming to unstable
Martin Steigerwald - 24.01.23, 09:18:53 CET: > Already updated what I could with "apt upgrade". Will try again later > today. > > kde-config-screenlocker kscreen kwin-common kwin-data kwin-wayland > kwin-x11 libkf5screen-bin libkf5screen-data libkscreenlocker5 > libkwineffects14 libkwinglutils14 libreoffice libreoffice-base > libreoffice-base-core libreoffice-base-drivers libreoffice-calc > libreoffice-common libreoffice-core libreoffice-draw > libreoffice-gtk3 libreoffice-help-common libreoffice-help-de > libreoffice-help-en-us libreoffice-impress libreoffice-kf5 > libreoffice-l10n-de > libreoffice-math libreoffice-plasma libreoffice-qt5 > libreoffice-writer python3-uno Haha, probably better wait, but could also be a fallout from the multi monitor changes: All backdrop images from my activities are gone. I will configure for some activities again, so see whether they are remembered then. Will wait till all packages are upgraded, no point opening a bug report with a mixed Plasma 5.26/5.27 beta setup. Probably not even reporting in case the issue remains with full 5.27, maybe just needs to be configured once again, cause the monitor assignment / ordering stuff has changed. On the other hand, the primary display, the notebook screens are also affected. In cast that backdrop image configuration loss is due the multi monitor changes and not due to my partial update, it might make sense to mention something in Debian release notes. Well let's see whether others on this list run into this issue. However, better wait till no KDE related packages are held back anymore. > (This Libreoffice stuff is held back since days already, did not yet > look into it closer. Might have to do with Breeze style.) This is known: libreoffice-common: breaks libreoffice-core from the same version https://bugs.debian.org/1029534 Thanks, -- Martin
Re: Plasma 5.27 beta (5.26.90) coming to unstable
Dear Aurélien, first off to you and all the other members of the Debian/Kubuntu Qt/KDE team: You are awesome! I greatly appreciate your efforts to bring the greatest and latest of KDE into Debian right before the freeze! *Thank you*! Aurélien COUDERC - 24.01.23, 01:16:27 CET: > I've just uploaded Plasma 5.27 beta to *unstable*. > > We usually keep beta versions in experimental but this one is our > target for bookworm and I want to give it maximum exposure with the > bookworm freeze starting already. > > I've been using it for a couple of days without major issue by YMMV of > course, it's beta software still. > > Feel free to not update or hold Plasma packages if you don't want to > use the beta. I'll upload the final 5.27.0 as soon as it's released, > so on Feb 14. or close to that. Already updated what I could with "apt upgrade". Will try again later today. kde-config-screenlocker kscreen kwin-common kwin-data kwin-wayland kwin-x11 libkf5screen-bin libkf5screen-data libkscreenlocker5 libkwineffects14 libkwinglutils14 libreoffice libreoffice-base libreoffice-base-core libreoffice-base-drivers libreoffice-calc libreoffice-common libreoffice-core libreoffice-draw libreoffice-gtk3 libreoffice-help-common libreoffice-help-de libreoffice-help-en-us libreoffice-impress libreoffice-kf5 libreoffice-l10n-de libreoffice-math libreoffice-plasma libreoffice-qt5 libreoffice-writer python3-uno (This Libreoffice stuff is held back since days already, did not yet look into it closer. Might have to do with Breeze style.) Will report on any problems. > Also if you have time, now would be a good time testing bullseye -> > bookworm upgrades with the Plasma desktop installed and report > anything broken (on spare machines / VMs obviously, NOT on systems > you need to rely on). What spare machines? My Devuan desktop machines are all running on Ceres which translates to Devuan Sid. :) If I manage to take the time I will try on VM, but will wait a few days probably for the package updates to fully settle so that "apt full- upgrade" runs through without removing anything important. Ciao, -- Martin
Re: Is 5.27 expected before freeze?
Steven Robbins - 08.01.23, 22:32:00 CET: > Thus, I'm wondering whether there's an easier way for me to try 5.27 > packages. I'm completely intimidated by the set of KDE packages in > Debian. So I'm curious whether there is any thought that 5.27 might > be uploaded anytime soon. Review my post "Thank for your the ambitious plan for Bookworm" or go directly to: https://wiki.debian.org/PkgQtKde/BookwormReleasePlans -- Martin
Re: plasmashell crashes
Erwan David - 08.01.23, 12:58:56 CET: > > Apper is somewhat similar to Discover, but I am not sure whether it > > is even maintained by upstream anymore. > > However it is apper which used to display in systray when upgrades or > security upgrades were available. Hmmm, I thought I would still be getting update notifications even without apper. At least I still have an "Updates" entry in systray configuration. Need to check whether those update available messages still popup. I do not care much about those, as I use apt on command line often enough to upgrade the machine and there is something new daily in unstable anyway. At least when I click the "Updates" icon it opens Discover. But right now nothing to update here, so… no idea whether it pops up by itself currently. But I thought it was. For what it is worth, both Apper and Discover depend on Packagekit which AFAIK does the heavy lifting underneath. I thought Discover could fully replace Apper. And when I look at the git commit history of Apper, I get the impression it is not really maintained anymore since at least 2019 or even longer: https://invent.kde.org/system/apper/-/commits/master Except for some build failure and crash bug fixes. Anyway, if Plasmashell currently crashes with it, I will not have it on my system. Simple as that. Best, -- Martin
Re: plasmashell crashes
piorunz - 08.01.23, 12:46:35 CET: > On 08/01/2023 11:43, Martin Steigerwald wrote: > > piorunz - 08.01.23, 12:33:06 CET: > >> Debian Testing is experiencing high volume of plasmashell and kded5 > >> crashes. Just caught clean crash of plasmashell with full > >> backtrace, I was clicking nothing on the desktop with focus on > >> another program, and plasmashell just crashed. But this time it > >> restarted itself and desktop was usable again immediately, so I > >> didn't wasted my work. X11, Radeon card, AMD64 machine with ECC > >> RAM and RAID1 storage. Bug report: > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028197 > > > > No crashes here on Unstable. > > > > ThinkPad T14 AMD Gen 1 with integrated AMD Renoir Vega 7 graphics. > > > > Don't have Apper installed. > > I have apper installed. "KDE package management tool using > PackageKit". What is it for, can I uninstall it without consequence? > I don't use Discover or other KDE tools too much to install software, > and can live without it, if it comes to that. >From what I read from this whole thread, I'd recommend to remove it. Apper is somewhat similar to Discover, but I am not sure whether it is even maintained by upstream anymore. -- Martin
Re: plasmashell crashes
piorunz - 08.01.23, 12:33:06 CET: > Debian Testing is experiencing high volume of plasmashell and kded5 > crashes. Just caught clean crash of plasmashell with full backtrace, I > was clicking nothing on the desktop with focus on another program, > and plasmashell just crashed. But this time it restarted itself and > desktop was usable again immediately, so I didn't wasted my work. > X11, Radeon card, AMD64 machine with ECC RAM and RAID1 storage. > Bug report: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028197 No crashes here on Unstable. ThinkPad T14 AMD Gen 1 with integrated AMD Renoir Vega 7 graphics. Don't have Apper installed. Ciao, -- Martin
Re: KDEPIM transition
Martin Steigerwald - 08.01.23, 12:24:53 CET: > Martin Steigerwald - 05.01.23, 11:32:17 CET: > > As you may have already noticed as Patrick uploaded the packages to > > unstable yesterday. > > Update to KDEPIM 22.12 and new Plasma 5.26.5 and quite some other new > KDE Application packages 22.12.1 went through just fine on AMD64. > Digikam, KMyMoney and others have been rebuilt. This is on Unstable. Testing will take longer. -- Martin
Re: KDEPIM transition
Martin Steigerwald - 05.01.23, 11:32:17 CET: > As you may have already noticed as Patrick uploaded the packages to > unstable yesterday. Update to KDEPIM 22.12 and new Plasma 5.26.5 and quite some other new KDE Application packages 22.12.1 went through just fine on AMD64. Digikam, KMyMoney and others have been rebuilt. Best, -- Martin
Re: Krunner : how to choose order of plugins
Hi Erwan. Erwan David - 05.01.23, 11:44:21 CET: > In krunner I get the folers/files before the applications. But I use > it moire pften to start an apllication than to look for a file. I did > not find a way to specify I want the applications before he files in > kruner menu. Is it possible ? Not yet AFAIK. Please review upstream bug report please add possibility to sort results returned by krunner by type https://bugs.kde.org/340283 for further details. Best, -- Martin
KDEPIM transition
Hi! As you may have already noticed as Patrick uploaded the packages to unstable yesterday. See here for status: https://release.debian.org/transitions/html/kdepim-22.12.html Thank you very much for updated KDEPIM packages to Patrick and the whole Debian/Kubuntu Qt/KDE team! Best, -- Martin
Re: Dragging icons at desktop
Miguel A. Vallejo - 24.12.22, 02:15:20 CET: > El lun, 28 nov 2022 a las 23:34, Martin Steigerwald > > () escribió: > > Miguel A. Vallejo - 28.11.22, 23:26:52 CET: > > > Recently I noticed when I drag an icon in the desktop (fully > > > updated > > > Sid), the icon lags behind the mouse cursor instead of following > > > the > > > mouse cursor under it as it always did. > > After almost a month of usage I can't get used to this "feature", it > makes the desktop feel sluggish and unresponsive. > > But I still haven't found where to disable it, so should I open a > bug? Against what package? At Debian or KDE? I’d file an upstream bug report if there is not already one. Please share bug number afterwards. Merry and harmonious Christmas or year-end-time to all of you. Best, -- Martin
Re: [X1 Tablet] How does it work with Plasma and Debian
chris - 22.12.22, 20:57:34 CET: > On Thursday, 22 December 2022 09:16:50 CET Martin Steigerwald wrote: > > I made an interesting experience regarding the current Qt > > transition: I updated a ThinkPad X1 Gen 1 Tablet with "apt upgrade" > > yesterday. > Did you manage to have your tablet fully functional in keyboard free > mode? I've experimented with an old Portege Tablet and many > applications couldn't be used without a keyboard or a mouse. I want > to use the tablet as a reader and Okular couldn't be used without > "mouse right click" or "keyboard control keys" which Maliit doesn't > (didn't) have. Example: you can go to full screen mode but you can't > leave it, because it would require a right click which I couldn't > manage neither by touch nor by stylus. No. Already LUKS encryption password at boot requires a keyboard. AFAIR I briefly researched whether that could be done with an on screen keyboard, but quickly gave up on it. Additionally after replacing the internal battery with a new lithium polymer replacement battery and a full hardware reset the time was gone and the UEFI firmware asked to hit F1 to continue. The firmware menu can be used by touch, however the engineers seem to have forgotten about that "no time is set" error. I made sure I have a working attachable ThinkPad X1 tablet keyboard. I can comfortably read PDFs on the tablet without keyboard, but for special functions in Okular, I am not so sure. However there is a "okular-mobile" package in Debian. So that might help. > On the hardware side, everything was fully functional with pure > Wayland install. I use GDM3 instead of SDDM because the latter still > rely on X11/Xorg, when GDM3 can do without. > > Touch screen and stylus (plain Wacom) fully functional. This tablet is still an experiment at getting a fully functional tablet with Linux. It is not that we have a plethora of options here. There are several rough edges. Trackpoint on keyboard does not work after boot, you need to detach and attach the keyboard once or hibernate the machine. I am using Wayland and some times the display just hung for whatever reason. Thing is, that then I can not just hit the power button long enough for a hard power off. That does not work on the tablet. Instead I have to stick a straightened paper clip into the emergency reset role. So I made sure I always have one of those with me when I am using the tablet somewhere. Once I had a HID related boot time kernel oops and was not able to enter the LUKS password. That also required that paper clip procedure to recover from. > But the applications were not ready to be used with tablet mode, > specially Maliit, imo, which is fine to insert text but doesn't do > keyboard shortcuts at all, which could atone for absence or right > click. Touchscreen longpress-is- rightclick is on a per application > basis, so you (did) have it with Dolphin, but not with Okular. Same > goes for stylus button configuration. I installed Maliit and tried it out, however I did not try to enter keyboard shortcuts with it. > It was a few month ago so I'd be happy to hear how you solved it or if > you stick with the physical keyboard. The later. I use the physical keyboard. > Note, integrated Firefox pdf reader, and FF generally, was what was > best tuned for pure tablet mode use, but it was both not very stable > at the time, and it was killing my fanless "Y"-series i5. I really like to look into okular-mobile. Also… I think for some other applications there are mobile alternatives in the Debian repository. Like for example kalender as a replacement for Okular. Meanwhile there are also some tablet form factor related settings in Plasma's system settings. Additionally I wonder whether it might be good to switch Plasma to a different form factor mode. I think I tried around with it, but then went back to regular desktop mode. > I've tried Phosh: couldn't insert my password. Gnome: no better. > Actually I did find some (old) extension of some Gnome keyboard that > did provide control keys, but maybe it was not working with all > applications, and also it was getting all Rube Goldberg, so I gave it > back to the cupboard. I did not dig into Phosh or GNOME. > But I'm still interested in an open source e-reader working with plain > device as the portege, and I don't want to use outdated technologies > like X11/Xorg, unmaintained for years when Wayland is doing great. I think this tablet currently is the only device that I run with Wayland these times. With my main laptop I often enough tried and then switched back due to various issues I do not remember at the moment. On my music laptop I had it for a while but then there was a strange issue as well that I do not remember. Maybe I try again when Plasma 5.27
Re: Careful with dist-upgrade in unstable at the moment
Diederik de Haas - 22.12.22, 13:26:47 CET: > On Thursday, 22 December 2022 09:16:50 CET Martin Steigerwald wrote: > > > I find it way easier to have apt reduce the problem riskless > > > first. > > > It's a shorter list of actions to review. > > > > Good argument. My argument is that in the usual situation trying > > "apt > > full-upgrade" first will save me one command. With "apt upgrade" I > > often enough would have to use "apt full-upgrade" afterwards. > > IMO that indicates that the 'state' of your packages could be > improved. I *rarely* have to do a full-upgrade to get things fully > upgraded. And when not all packages get upgraded, that usually means > something 'special' is going on, like now with the Qt transition. Well, I still thought about the "apt-get upgrade" scenario even though I use "apt upgrade" meanwhile. Often enough there are new packages to install. I did not really test how often I would have to use "apt full- upgrade" instead of "apt upgrade". It might be considerably less often due to apt installing new packages automatically. > On Wednesday, 21 December 2022 11:42:17 CET Diederik de Haas wrote: > > I think they above quoted script is absolutely horrific. > > I made that statement for 2 reasons: > 1) It tries do a dist-upgrade 'at all cost' (imo ofc) > 2) `dpkg --set-selection` completely messes up APT's 'database' wrt > manually and automatically installed packages ... which in turn > causes the need to full-/dist-upgrade. I made no statement at all about this script. So in case you were assuming that I somehow intended to justify it, I was not. Actually I did not even carefully read through it to see what it does. My statement was just about "upgrade" versus "full-upgrade". Best, -- Martin
Re: Careful with dist-upgrade in unstable at the moment
Martin Steigerwald - 22.12.22, 11:48:59 CET: > I did not do much on the tablet. But I am working with my main laptop > just as usual and did not see any issues so far. And for what I did on the tablet: no issues. Systray, KRunner fully available again. -- Martin
Re: Careful with dist-upgrade in unstable at the moment
Sedat Dilek - 22.12.22, 11:10:47 CET: > On Thu, Dec 22, 2022 at 10:53 AM Martin Steigerwald wrote: > > Martin Steigerwald - 22.12.22, 09:16:50 CET: […] > > > So I will just wait until a "full-upgrade" can run through fully > > > on this tablet and probably stay away from a "upgrade" on my > > > laptop as well for a few days. However I used "apt upgrade" to > > > upgrade my > > > > Well, which was possible today already. All issues I found are fixed > > by today's update. > > > > I also fully upgraded on my main laptop. All fine there as well. […] > Can you boot into KDE version 5.26.4 with QT version 5.15.7 packages > upgraded as of today? > > Do the KDE applications work as (you) expected? With "All fine there as well" I meant exactly that. I did not do much on the tablet. But I am working with my main laptop just as usual and did not see any issues so far. This is no guarantee whether it works all fine for your set of packages and your use case, but for mine it does so far. Thanks to the Qt/KDE package maintainers for the update!!! Best, -- Martin
Re: Careful with dist-upgrade in unstable at the moment
Martin Steigerwald - 22.12.22, 09:16:50 CET: > I made an interesting experience regarding the current Qt transition: > I updated a ThinkPad X1 Gen 1 Tablet with "apt upgrade" yesterday. > > Parts of the Plasma desktop are still broken. Some part of systray > misses some QML files, KRunner shows up as an empty pane without > anything, the lock screen is not usable and several other issues. So > it can still happen with just "apt upgrade" that you have an only > partly usable system afterwards. Of course I'd argue that this is an > issue with missing versioned dependencies. However it appears to me > that it is quite different to completely get this right with a > software stack of this complexity. > > So I will just wait until a "full-upgrade" can run through fully on > this tablet and probably stay away from a "upgrade" on my laptop as > well for a few days. However I used "apt upgrade" to upgrade my Well, which was possible today already. All issues I found are fixed by today's update. I also fully upgraded on my main laptop. All fine there as well. So at least for the sets of packages I use, the update goes through smoothly now. According to https://release.debian.org/transitions/html/qtbase-abi-5-15-7.html almost all packages are built for AMD64 already. > laptop earlier on the same day and have seen no such updates. The > tablet has not been updated for a longer time, but that should not > really make much of a difference. And that might have made *the* difference. Some KF5 related packages were still at 5.90 on this tablet after the "apt upgrade" yesterday. Of course these were more current version on my main laptop. Ciao, -- Martin
Re: Careful with dist-upgrade in unstable at the moment
Aurélien COUDERC - 21.12.22, 23:10:14 CET: > I’d like to recommend using « apt upgrade » which has a slightly > different behaviour than apt-get : it will upgrade already installed > packages but also install new packages where necessary (which apt-get > upgrade won’t do). > > This will leave full-upgrade with less things to do and for me to > review. The only remaining packages should have a note in their > changelog about doing a split, replacing another package or adding a > Breaks/Replace condition. I regularly check this when I see non > obvious removals (and by obvious I really only mean libfooN+1 > replacing libfooN). Interesting. I did not know this difference in behavior between "apt" and "apt-get". Thank you, Aurélien Ciao, -- Martin
Re: Careful with dist-upgrade in unstable at the moment
Marc Haber - 21.12.22, 21:37:45 CET: > On Wed, Dec 21, 2022 at 12:50:45PM +0100, Martin Steigerwald wrote: > > Marc Haber - 21.12.22, 12:00:39 CET: > > > > Stop using *dist-*upgrade by DEFAULT. > > > > > > *AMEN* to that. > > > > I usually do "dist-upgrade", but then look carefully what it is > > about to do. If I don't like that, I only to "upgrade". > > > > Of course one can argue it is safer to do it the other way around. > > I find it way easier to have apt reduce the problem riskless first. > It's a shorter list of actions to review. Good argument. My argument is that in the usual situation trying "apt full-upgrade" first will save me one command. With "apt upgrade" I often enough would have to use "apt full-upgrade" afterwards. But more often "apt full-upgrade" just does its job. Even in Debian Unstable (or Devuan Ceres). I made an interesting experience regarding the current Qt transition: I updated a ThinkPad X1 Gen 1 Tablet with "apt upgrade" yesterday. Parts of the Plasma desktop are still broken. Some part of systray misses some QML files, KRunner shows up as an empty pane without anything, the lock screen is not usable and several other issues. So it can still happen with just "apt upgrade" that you have an only partly usable system afterwards. Of course I'd argue that this is an issue with missing versioned dependencies. However it appears to me that it is quite different to completely get this right with a software stack of this complexity. So I will just wait until a "full-upgrade" can run through fully on this tablet and probably stay away from a "upgrade" on my laptop as well for a few days. However I used "apt upgrade" to upgrade my laptop earlier on the same day and have seen no such updates. The tablet has not been updated for a longer time, but that should not really make much of a difference. Anyway, Qt transitions had been painful in the past. I still remember having not been able to login to a Plasma desktop for days to come. I installed MATE back then I think in order to have a working desktop. > P.S. dist-upgrade is as deprecated as it could be, it's not even in > the man page any more I know about full-upgrade. But actually do not care all that much as long as the other one still works. Habits. But right, publicly it would be better to write "full-upgrade". Ciao, -- Martin
Re: Careful with dist-upgrade in unstable at the moment
Marc Haber - 21.12.22, 12:00:39 CET: > > Stop using *dist-*upgrade by DEFAULT. > > *AMEN* to that. I usually do "dist-upgrade", but then look carefully what it is about to do. If I don't like that, I only to "upgrade". Of course one can argue it is safer to do it the other way around. Ciao, -- Martin
Careful with dist-upgrade in unstable at the moment
Hi! Qt Transition ongoing. AFAIK that will be the intended version for next stable. On my system it would remove most of Plasma on a dist-upgrade. So give it some time if its similar on your setup. Best, -- Martin
Re: Copy bug in Dolphin 22.12.0
Dear Aurélien. Aurélien COUDERC - 12.12.22, 12:05:54 CET: > there’s an embarassing bug in Dolphin 22.12.0 that was raised > following my upload to unstable. [0] [1] So if you’re running > unstable and this is an issue for you, you may want to hold the > previous version for now. Thanks for letting us know! Best, -- Martin
Re: Dragging icons at desktop
Miguel A. Vallejo - 28.11.22, 23:26:52 CET: > Recently I noticed when I drag an icon in the desktop (fully updated > Sid), the icon lags behind the mouse cursor instead of following the > mouse cursor under it as it always did. I can confirm this. > I have searched in Preferences but I do not see anything about "drag > animations" or any related effect. > > Anyone know how to disable it and go back to the old behaviour? Yeah, would be nice to know. I am not yet sure whether I like to get used to this behavior. Best, -- Martin
Thank for your the ambitious plan for Bookworm
Dear Debian/Kubuntu Qt/KDE team developers, thank you dearly for the ambitious plan you set out in: https://wiki.debian.org/PkgQtKde/BookwormReleasePlans And best of success! In case you'd like some of us to test something from experimental at some time, just let us know. While I do not mind as much as I am using Debian Sid (well actually Devuan Ceres with Runit) and thus do not rely on versions in stable releases, it is great to see that stable users are looking forward to recent versions. Even in case some of your plan does not work out, its still quite recent. Have a great weekend! -- Martin
Re: Versions mismatch and upload methodology for KDE applications
Luigi Toscano - 04.11.22, 21:58:58 CET: > Shmerl ha scritto: > > I noticed that versions of KDE applications in Debian repos are > > all over the place. Examples: > > > > kmail: 22.08.2 > > konsole: 22.08.1 > > okular: 22.04.3 > > and etc. > > > > So method of uploading them seems random or ad hoc. > > > > Why aren't KDE maintainers uploading the whole suite of > > applications at once for all of them to have the same version? > > I can't speak for the maintainers, but please consider that those > programs are part of KDE Gear, which is just a collection of software > which is released together, but it doesn't automatically imply a > dependency between the various applications. There may be some (for > example, all bits which mades KDE PIM) but that's not the general > rule, so they can be updated separately. Additionally the version numbers of all apps are updated on each KDE Gear release, no matter whether there have been changes to them. That written for Okular for example I expect changes on every major KDE Gear release. Also it can happen that for some reason a package needs to go through NEW again and approved by ftpmasters. Thanks, -- Martin
Plasma 5.26 coming to unstable - Thank you!
Hi! Read here about it: https://kde.org/announcements/plasma/5/5.26.0/ As usually wait for it to be complete and be careful with dist-upgrade during that time. Same was true for Qt transition that at least on my systems appears to be completed. Thank you to Aurélien and Rik Mills. And to everyone else who helps with packaging Plasma, KDE Frameworks, the applications and Qt! I am very happy about the current state of those in Debian. Thank you. Best, -- Martin
Many thanks for KDEPIM 22.08!
Hi! Many thanks for KDEPIM 22.08 packages. Still need to wait a bit here with dist-upgrade, but I bet it will be soon enough! Ciao, -- Martin
Thank you!
Hi! A huge thanks to the Debian Qt/KDE maintainer team for the continued work on Qt/KDE related packages. Thank you to Pino, Patrick, Aurélien and of course all the others for tirelessly packaging newest versions of Qt, including Qt 6 which KDE will switch to at some time, Plasma, KDE Frameworks, KDE Gear, KDEPIM and all the other applications from KDE, including new ones like the Korganizer alternative Kalendar. I bet in total that could easily be about one thousand packages, maybe even more. It is a huge effort to pull this off! While not all of this is available within unstable yet, at least not in most recent versions, most of it is and the state of the art in unstable regarding KDE related packages is very decent. Thank you for this continued effort to all of you, of course also to those who I did not mention specifically including those long term team members who advice newcomers to the team on packaging questions and those who contributed a lot previously. I appreciate your effort! Best, -- Martin
Re: Akonadi using 100% CPU resources
piorunz - 15.04.22, 11:56:28 CEST: > > Which processes of Akonadi are using up the CPU? In case it is just > > a > > certain process like "akonadi_indexing_agent", well what I did with > > this one is: > > > > chmod 000 /usr/bin/akonadi_indexing_agent > > > > It works. > > All of them. > Screenshot: > https://imgur.com/vJFrPPR > > Thank you, I will try to block all executables so they never run > again. Wow! This is ridiculous. I think I never had it this bad. -- Martin
Re: Akonadi using 100% CPU resources
piorunz - 15.04.22, 11:58:17 CEST:
> On 15/04/2022 09:37, Martin Steigerwald wrote:
> > Well on those systems where I do not use Akonadi and switch to
> > SQLite3.
> >
> > Please do not do this without having a good reason to do it, in case
> > you actually use Akonadi.
> >
> > There is potential data loss – i.e. loosing mails, appointments,
> > contacts – in there, since Akonadi is unfortunately not just a read
> > cache, but a time-limited – or unlimited in case of a certain
> > conditation – write cache where things may end to be stored just in
> > the database for a limited or even an unlimited time ("item without
> > RID" message in akonadictl fsck).
>
> I never ever used Akonadi database AFAIK. I don't use KDE contacts,
> KMail, or any of that.
> I use "Plasma Search" in KRunner, is that in Akonadi, or something
> separate?
Search for files should be based on Baloo. This is separate from Akonadi.
Some systray applet or KRunner module my trigger starting Akonadi,
depending on their settings. But it should be possible to disable this.
--
Martin
Re: Akonadi using 100% CPU resources
Martin Steigerwald - 15.04.22, 10:31:15 CEST:
> What I do on systems where I do not use Akonadi – it may even work
> well on systems where it is used – is to replace
> "akonadi-backend-mysql" by "akonadi-backend-sqlite". That way I get
> rid of an additional full blown database process.
>
> I usually also stop Akonadi with
>
> akonadictl stop
>
> And then do
>
> rm -r ~/.local/share/akonadi
>
> rm -r ~/.config/akonadi
Well on those systems where I do not use Akonadi and switch to SQLite3.
Please do not do this without having a good reason to do it, in case you
actually use Akonadi.
There is potential data loss – i.e. loosing mails, appointments,
contacts – in there, since Akonadi is unfortunately not just a read
cache, but a time-limited – or unlimited in case of a certain
conditation – write cache where things may end to be stored just in the
database for a limited or even an unlimited time ("item without RID"
message in akonadictl fsck).
--
Martin
Re: Akonadi using 100% CPU resources
piorunz - 15.04.22, 02:18:38 CEST:
> I noticed that akonadi services are using 100% of 16-core CPU
> resources on my machine. I don't even use Kmail, I use Thunderbird.
I am not happy with Akonadi, but that can do such things even in case an
user does not use it – that is new to me.
> I'm not even sure what akonadi is for. I have following packages
> installed:
>
> $ dpkg -l | grep akonadi | awk {'print $2'}
> akonadi-backend-mysql
[…]
> System is Debian Testing.
>
> How can I get rid of that akonadi, or disable it?
>
> I can't uninstall akonadi-server, because it wants to uninstall with
> it: akonadi-server* kaddressbook* kde-standard* kdepim-runtime*
> kmail* knotes* korganizer* task-kde-desktop*
Which processes of Akonadi are using up the CPU? In case it is just a
certain process like "akonadi_indexing_agent", well what I did with this
one is:
chmod 000 /usr/bin/akonadi_indexing_agent
It works.
Also you can try
akonadictl stop
and see whether it stops the processes that are consuming the CPU. Often
enough it did stop all the processes except MariaDB "mysql" processes
that was still running at full speed for minutes or longer. Especially
in case the indexing agent was involved. Indexing agent is perfectly
capable to drive any database against a wall. It is really that bad.
Do you really not use it? Look at
du -sch ~/.local/share/akonadi/* | sort -rh
If you really do you use it, this should be almost empty beside some
MariaDB journal files.
Note: In case you store contacts in KAdressbook or use a calender with
KOrganizer, you actually *use* Akonadi. Akonadi is not just about
storing mails for KMail.
What I do on systems where I do not use Akonadi – it may even work well
on systems where it is used – is to replace "akonadi-backend-mysql" by
"akonadi-backend-sqlite". That way I get rid of an additional full blown
database process.
I usually also stop Akonadi with
akonadictl stop
And then do
rm -r ~/.local/share/akonadi
rm -r ~/.config/akonadi
Again! Only if you really do not use it, if unsure rather use:
mv ~/.local/share/akonadi ~/.local/share/akonadi-2022-04-nn
mv ~/.config/akonadi ~/.config/akonadi-2022-04-nn
This firstly helps with switching the database, although for that there
are less drastic options like just removing old database and changing
the database driver in ~/.config/akonadi/akonadiserverc or deleting just
that file.
Secondly in addition to getting rid of the external database process it
restores Akonadi to a state where before it was first started – well
except for some other configuration files that are in a different locally,
but I suppose would not matter in this case – so that the condition that
triggered the erratic behavior of Akonadi likely is done way with.
And now: Wow!
I still believe the end user should not have to do with any of this.
Akonadi is something that drags down the overall good Plasma / KDE
experience unfortunately since more than a decade. I defended it earlier
on. Meanwhile I think it is better to completely replace it.
For example by something like Evolution from GNOME uses. I use Evolution
at work and it has none of the issues that Akonadi brings into those
very nice KDEPIM applications like KMail.
Best,
--
Martin
Re: Plasma 5.24 coming to unstable
bruno zanetti - 28.02.22, 15:15:14 CET: > Il giorno lun 28 feb 2022 alle ore 14:50 Miguel A. Vallejo > > ha scritto: > > The question is: > > > > Why is APT not smart enough to see that the proposed upgrade will > > fail? > > > > It always starts to install packages and at some point fails because > > some package needs another package with a specific version. Why does > > it not detect these cases after starting upgrading packages? It > > knows > > the versions available for every package so it should prevent these > > problems. > > > > Is it a bug or a missing APT feature? > > I think the problem in which you incurred is not related to an APT > bug or (missing) feature but rather a packaging bug ( > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006538) that has > been catched (and fixed) in sid. > After all this is just the purpose of sid. Yes. And really, to everyone who is complaining: Debian Sid is also called Debian Unstable. For a reason! Either be prepared to handle the occasional glitch – in this case the glitch could be handled by using the appropriate dpkg force option. Or don't use it. It is really as simple as that. Best. -- Martin
Re: KDE Frameworks 5.90 coming to unstable
Aurélien COUDERC - 12.02.22, 13:11:19 CET: > Le 12 février 2022 12:44:21 GMT+01:00, "Aurélien COUDERC" a écrit : > >Le 12 février 2022 12:02:24 GMT+01:00, Sami Erjomaa a écrit : > >>> It appears to me that it is complete already. > >> > >>Frameworkintegration hasn't been built since it depends on knewstuff > >>that's in the "NEW" queue. > > > >I'll post some workarounds later today but I wouldn't recommend to > >upgrade only parts of frameworks. No one tested this, neither > >upstream nor myself. > So it turns out knewstuff cleared the NEW queue really quick thanks to > FTP masters, so please just wait for everything to build in the > coming hours and update once everything is available as 5.90. Great, thanks for the update about the NEW queue. Good to read that it worked out nicely. Best, -- Martin
Re: KDE Frameworks 5.90 coming to unstable
Martin Steigerwald - 12.02.22, 11:27:20 CET: > As usual wait for it to build completely and be careful about "apt > dist- upgrade". It appears to me that it is complete already. Best, -- Martin
KDE Frameworks 5.90 coming to unstable
Hi! Aurélien just uploaded it. Thank you very much, Aurélien and everyone else who helped to make this happen! As usual wait for it to build completely and be careful about "apt dist- upgrade". Best, -- Martin
Re: The future of KDE in Debian?
Allan Sandfeld Jensen - 28.01.22, 16:24:07 CET: > On Montag, 24. Januar 2022 21:20:11 CET Marco Valli wrote: > > O-h m-y g-o-d... > > > > https://www.phoronix.com/scan.php?page=news_item=Qt-Digital-Adver > > tising-1 .0 > > > > Regards > > Maybe I am missing something, what is the problem with a company > releasing a new product for paying customers. A new product that has > nothing to with Debian, KDE or what we use of Qt? > > I mean it will likely make the products of those paying customers > objectively worse, but we can just choose not to use those products, > which aren't Open Source anyway. No, you are not missing anything here. There is nothing to see here. Even if you do not agree with this move by The Qt Company. As long as KDE developers stay their current course, there is nothing to worry about. Best, -- Martin
Re: Future of KDE packages in Debian
Dear Aurélien. Aurélien COUDERC - 23.01.22, 23:17:32 CET: > please consider that events being commented here have already > happened, had consequences and it’s not like you can go back in time. > > Debian like most human groups has rules on how to become and stay a > member of the community. If you’re interested in them you can find > pointers at : https://wiki.debian.org/DAManager > The discussions on this have long passed usefulness and are more and > more offtopic for a Debian mailing list for KDE users. I think when Debian account managers remove Debian developer status from someone who contributed a lot to KDE packages in Debian, it is fair enough for users to express their frustration with that. Muting discussion is a pattern I have seen so often in Debian that I meanwhile unsubscribed from various development related mailing lists of Debian. Also cause it hurt reading what I read there. I am not a Debian developer and this in part is cause as my motivation increased to become one I saw more and more that Debian at least in part has become a toxic environment. I do not like to be involved with the kind of politics I have seen in Debian in the last years. In my perception it certainly did not get better. That written, I don't know what it was this time. I cannot say for sure whether it was justified or not. I could try to dig it all up, but most likely after I try to read the mails related to this I would have more question marks than before. I would not be surprised if there would not at least be two sides of the story. Both perfectly valid. And the solution would have been to talk *with* one another in a constructive way. I am not (yet) ready to jump ship at the moment. Well in part I did by moving to Devuan cause of the utter failure within Debian to resolve the conflict regarding the introduction of Systemd, however, I understand perfectly well that without the activity of the Debian Qt/KDE team there would be no KDE Plasma and Co in Devuan. I am grateful for that. But at the same time I feel it is fair enough for users of KDE software in Debian to express their frustration with what happened in a *respectful* way. From what I have seen happening within Debian within the last years, I am not likely to increase my formal engagement with the project unless there would be an in-depth transformation process of the culture regarding how to handle conflict within the project. I am just not ready to deal with the amount of toxicity I have seen within the last years. There is a culture within Debian to stifle conflict instead of moving through and then resolving it, and that clearly doesn't work. Conflicts are a natural part of human relationships. It is sad, cause on the other hand I usually got along well with members of the Qt/KDE team and at least helped a bit here and there, not with packaging, but with communication with users, bug triaging and things like that. Fortunately enough KDE project mostly appears to be a much more welcoming place. It is sad to see what is happening from within Debian to Debian, but I see myself not in a position to do much about it. Best, -- Martin
Re: Future of "his" packages in Debian
Hi. piorunz - 20.01.22, 23:09:30 CET: > On 20/01/2022 18:17, Marco Valli wrote: > >> by Norbert Preining · 2022/01/14 > >> > >> After having been (again) demoted (blah) > >> based on flimsy arguments, I have been forced to rethink the level > >> of contribution I want to do for Debian. Blah blah blah blah > >> After about 20 years in Debian, blah blah blah > >> blah > >> KDE/Plasma, frameworks, Gears, and related packages: > >> blah > >> All these packages are group maintained, so there is not much to > >> worry about. > >> Furthermore, a few new faces have joined the team and > >> are actively working on the packages, although mostly on Qt6. I > >> guess > >> that with me not taking action, frameworks, gears, and plasma > >> will fall back over time > > > > Admittedly, this guy doesn't have much faith in the the Debian/Kde > > team. Regards > > Who is this clown again? I respect Norbert for the work he did on Plasma/KF/Application packages. I do not think it is fair to speak of him (or anyone else) as clown. From what I have perceived he contributed a lot to make timely releases of packages happen. I don't know what is going on here… what this demotion thing about, so I do not comment directly on it. I never had any issues with Norbert. Generally speaking more and more I have the impression that in Debian political arguments became more important than actually getting work done in the recent years. I bet that is part of the reason why I switched to Devuan for all my private systems. Ciao, -- Martin
Re: Plasma 5.23 25th Annivery Release coming to unstable
Andrey Rahmatullin - 15.10.21, 12:36:10 CEST: > On Fri, Oct 15, 2021 at 12:31:55PM +0200, Eric Valette wrote: > > > IME it's *rarely* needed. > > > Normally aptitude safe-upgrade installs and removes packages as > > > needed.> > > I beg to disagree. Here you speak about *aptitude* which is a tool > > that is not the plain apt tool itself. You could also say things > > for dselect, synaptic, discover... > > > > With apt-get, you have to use dist-upgrade quite often because as > > other have pointed out, you cannot add or remove packages without > > dist-upgrade. > > > > Clearly to install libkdecorations2-5v5, you will need apt-get > > dist-upgrade. And the libkdecorations2-5v5 that was wrongly put in > > experimental does break the unstable version... > > apt upgrade, as opposed to apt-get upgrade, can install new packages. Interesting information. I was not aware of that. Thanks, -- Martin
Re: Plasma 5.23 25th Annivery Release coming to unstable
Dear Patrick. Patrick Franz - 15.10.21, 05:37:18 CEST: > please do not upgrade Plasma to 5.23 for the time being. > > Unfortunately, the upload is not complete and upgrading only half of > the packages can leave Plasma in an unusable state. > If you already have upgraded some packages, please downgrade them to > the version in testing (5.21.5) or whatever version you were using > before. > > We are sorry for this. Thank you for notifying. No problem for me. Its called Debian unstable and things like that can happen. Thank you very much for your work! Best, -- Martin
Re: Plasma 5.23 25th Annivery Release coming to unstable
Diederik de Haas - 14.10.21, 17:55:26 CEST: > On Thursday, 14 October 2021 17:15:00 CEST Martin Steigerwald wrote: > > As usually take care with "apt dist-upgrade". Wait until the builds > > are complete. > > The best way to do that is not using *dist*-upgrade but the > normal/safe- upgrade method ... Sometimes dist upgrade might be necessary as new packages are introduced or old ones are removed. Trying dist upgrade also often gives a good indication whether the builds are complete. On the other hand the dependencies of the packages should make sure they are all in a consistent version, I think. Best, -- Martin
Plasma 5.23 25th Annivery Release coming to unstable
Hi! Just that. Norbert uploaded it to unstable. As I learned in #debian-qt-kde IRC channel, KDecoration went to experimental, instead of unstable, so you may need to get it from there until Norbert or someone else uploads it to unstable. As usually take care with "apt dist-upgrade". Wait until the builds are complete. Best, -- Martin
Re: Able to write to read-only pdf files
Adriano Vilela Barbosa - 14.08.21, 20:19:38 CEST: > I understand this mechanism, but I think this is quite controversial > and problematic. I mean, as an end user I don't care what the editor > is doing behind the scenes; it just shouldn't be able to modify a file > marked as read-only. Welcome to the world of Unix permissions. :) Whether the application should take extra caution is another question. I think for many applications it is a sane thing to give at least a hint to the user. > This is the first time I came across this behavior. No text editor I > ever used does this; LibreOffice doesn't do it either (rather, it > shows a message saying the document is open in read-only and shows an > "Edit Document" button, which allows you to edit the document and then > save it under a different name). vim for example sets read only mode and only saves with an "!" after the write command. I see you filed an upstream bug report. And it got resolved in upstream version already. Thank you! Best, -- Martin
Re: KDEPIM 21.08: blank settings window in KMail
Dietz Proepper - 28.08.21, 14:31:45 CEST: > Am Mittwoch, 25. August 2021, 09:50:16 CEST schrieb Martin Steigerwald: > > Hi. > > > > KDEPIM upgrade to 21.08 in Debian Unstable should be possible, > > unless > > you rely on Digikam. digikam-private-libs still needs a rebuilt. > > > > Did anyone update? Do you also see a blank settings window in KMail? > > As a quick workaround, if I use kmail from within Kontact, I can > access all kmail settings via the Kontact setup dialog. Thanks, that is a really nice work-around. I did not think of trying this! Best, -- Martin
Re: Digikam and 4:21
MERLIN Philippe - 27.08.21, 16:36:01 CEST: > the update from Kde 4:20 to 4:21 removes the digikam > software, > in my case blocks the installation of this new version. > My question is the following: is there a foreseeable date > of an update of digikam compatible with the 4:21? Norbert requested a binNMU, i.e. a rebuilt, see bug #992948. Once the release team gets to it and the builds are through it should be installable again. Just wait a bit more. Best, -- Martin
Re: KDEPIM 21.08: blank settings window in KMail
Diederik de Haas - 26.08.21, 15:44:00 CEST: > On donderdag 26 augustus 2021 14:35:08 CEST Martin Steigerwald wrote: > > > Can those of you who see this problem, please try the kmail > > > package > > > https://download.opensuse.org/repositories/home:/npreining:/ > > > debian-kde:/apps2108/Debian_Unstable/amd64/ > > > kmail_21.08.0-1~np1_amd64.deb (for > > > Debian_Unstable, for testing use Debian_Testing) > > > It should be installable as is. > > > > Not with Debian Unstable packages: > > > > LANG=en dpkg -i kmail_21.08.0-1~np1_amd64.deb > > (Reading database ... 417884 files and directories currently > > installed.) Preparing to unpack kmail_21.08.0-1~np1_amd64.deb ... > > Unpacking kmail (4:21.08.0-1~np1) over (4:21.08.0-1~np1) ... > > dpkg: dependency problems prevent configuration of kmail: > > kmail depends on libkf5coreaddons5 (>= 5.84.0); however: > > Version of libkf5coreaddons5:amd64 on system is 5.83.0-2. > > kmail depends on libkf5kcmutils5 (>= 5.85.0-1~np1); however: > > Version of libkf5kcmutils5:amd64 on system is 5.83.0-2. > > kmail depends on libkf5xmlgui5 (>= 5.85.0-1~np1); however: > > Version of libkf5xmlgui5:amd64 on system is 5.83.0-2. > > I first upgraded my version 5.83 packages to the ones in unstable: > aptitude safe-upgrade ~i~V5.83.0 -t experimental In Experimental. > Started KMail and settings window still didn't work. I did it without > logging out or anything, so there's a reasonable chance the 5.83 > versions were still in use. Hmm, here KMail after installation as above just didn't start as it didn't find some library symbols. But it could be that this was related to the library mentioned above, so yeah, could be that some other 5.83 libraries were in use. Ciao, -- Martin
Re: KDEPIM 21.08: blank settings window in KMail
Norbert Preining - 26.08.21, 13:21:33 CEST: > > Did anyone update? Do you also see a blank settings window in KMail? > > I did some experiments: > > * frameworks 5.85 (OBS) with kmail from sid (compiled against > frameworks 5.83) > black windows > * installed kmail from my OBS (downgrade to -1~np1) which is compiled > against frameworks 5.85 and running against 5.85 > settings window shows up fine > > > Can those of you who see this problem, please try the kmail package > https://download.opensuse.org/repositories/home:/npreining:/ > debian-kde:/apps2108/Debian_Unstable/amd64/ > kmail_21.08.0-1~np1_amd64.deb (for > Debian_Unstable, for testing use Debian_Testing) > It should be installable as is. Not with Debian Unstable packages: LANG=en dpkg -i kmail_21.08.0-1~np1_amd64.deb (Reading database ... 417884 files and directories currently installed.) Preparing to unpack kmail_21.08.0-1~np1_amd64.deb ... Unpacking kmail (4:21.08.0-1~np1) over (4:21.08.0-1~np1) ... dpkg: dependency problems prevent configuration of kmail: kmail depends on libkf5coreaddons5 (>= 5.84.0); however: Version of libkf5coreaddons5:amd64 on system is 5.83.0-2. kmail depends on libkf5kcmutils5 (>= 5.85.0-1~np1); however: Version of libkf5kcmutils5:amd64 on system is 5.83.0-2. kmail depends on libkf5xmlgui5 (>= 5.85.0-1~np1); however: Version of libkf5xmlgui5:amd64 on system is 5.83.0-2. dpkg: error processing package kmail (--install): dependency problems - leaving unconfigured Processing triggers for libc-bin (2.31-17) ... Processing triggers for mailcap (3.70) ... Processing triggers for desktop-file-utils (0.26-1) ... Processing triggers for hicolor-icon-theme (0.17-2) ... Errors were encountered while processing: kmail Thanks, -- Martin
KDEPIM 21.08: blank settings window in KMail
Hi. KDEPIM upgrade to 21.08 in Debian Unstable should be possible, unless you rely on Digikam. digikam-private-libs still needs a rebuilt. Did anyone update? Do you also see a blank settings window in KMail? If so you can help by researching whether there is an upstream bug report at https://bugs.kde.org. Also you can try to gather debug output with kdebugdialog5 and running KMail on console, if you have the time. I may look closer into this as well, but at a later time. So if you have time to preempt me, please go ahead. Please report for findings here for now. The settings windows of KOrganizer, KAddressbook and Akregator open just fine… it appears to me that there is a visual change. The menu to select the section of configuration is on a white background now and looks a bit more modern in a way. I see part of that white background in KMail settings window, so maybe the positions are off. Best, -- Martin
KDEPIM 21.08 coming to unstable
Hi! KDE Gear already mostly went through, except a few applications and KDEPIM. Norbert is uploading KDEPIM / Akonadi 21.08. Please wait for builds to complete their work. In generally be careful. Unstable is much more unstable again, also for other reasons like breaking changes in debianutils. So I strongly recommend to install apt-listbugs, it will warn you in case someone else stumbled upon an issue of a certain severity and reported it already. Anyway, breakage can happen especially in the first weeks after a stable release. You may choose to stay on stable for a month or two and then switch to unstable or testing again. In case you are prepared for a potentially more bumpy ride: Have fun. Best, -- Martin
KDE Gear 21.04 coming to experimental
Hi! Norbert is uploading it currently. I do not expect issues, but as always only use packages from experimental if you are confident that you can fix apt / aptitude errors and if you in case that you need help are willing to provide sufficient information. I suggest to report bugs here first as they may turn out to be caused by partial updates, although I believe with KDE Gear – yeah, they changed the name again – this is not too much of an issue. Best, -- Martin
Re: KDE Plasma v5.21.2
Dear Sedat. Sedat Dilek - 04.03.21, 10:10:54 CET: > No comment, see attachment. I appreciate your enjoyment about the new version. However I suggest not to post an image with a screenshot of the version number every time a patch release of Plasma is released. In my point of view it is needless internet traffic relayed to quite some mail boxes. If you like to share some nice information you can post the release announcement. It may contain useful information for some users: https://kde.org/announcements/plasma/5/5.21.2/ Of course, for all who want to review the changes of the major version, see here: https://kde.org/announcements/plasma/5/5.21.0/ By the way, I do have: Explanation: Automatically update experimental packages Package: * Pin: release a=experimental Pin-Priority: 200 in my /etc/apt/preferences. I do not recommend this for all users! You need to be careful to watch the output of apt / aptitude dist-upgrade in case you have experimental packages installed – an experimental package may have been built against other experimental packages and this can cause unwanted upgrades or breakages. For my use case of just installing Plasma and KDE Frameworks from experimental I expect this to be working fine. By all means keep the pin priority below 500! So or so… this is for experienced users who are willing to look carefully and also are willing to keep the pieces in case something breaks, in other words who are willing to accept that it is their responsibility to fix it up again then. Of course, you can ask here, and people may help. Ciao, -- Martin
Re: Plasma 5.21.1 in Experimental
Hi Reinhard, Reinhard Karcher - 26.02.21, 13:31:09 CET: > Am Freitag, 26. Februar 2021, 13:11 schrieb Norbert Preining: […] > > > Any aptitude / apt foo magic recommendation? Otherwise I try to > > > come up with something myself. > > > > Many options, I usually do > > > > aptitude -t experimental > > > > and then select all the plasma etc related packages, that normally > > works nicely. > > I use the command: > aptitude install '~i ~V5\.21\.1' -t experimental > for Version 5.21.1. > apt should work with the same options, but I didn't test it. Thanks, Luc, Norbert and Reinhard! I went with this one. It worked out of the box. So far 5.21.1 appears to be working just fine. I wondered about having to specify from which version to which version to upgrade, but I see now, if the version number is unique enough I can get away with just specifying the target version. I like that approach. Of course its still important to watch the output for any package that should not be in there. Have a great weekend, -- Martin
Re: Plasma 5.21.1 in Experimental
Hi Luc, Luc Castermans - 26.02.21, 12:12:48 CET: > Upstream Plasma 5.21.1 was released Feb 23, yesterday I installed it > from Experimental.A big wow and even a bigger thanks to all who > made this possible. I am tempted to mention names, don´t do that in > order not to disappoint people. Thank you community! Thanks for letting us know. What exact command did you use? I already installed KDE Frameworks 5.79 from Experimental on top of Devuan Ceres – which is basically very similar to Debian Sid, just without Systemd by default without having to deal with some… uncooperative Debian maintainers (none from the Debian Qt/KDE team, midn you). However… I am certainly do not like to use the approach Sedat used initially, which is: RELEASE="experimental" ; LC_ALL=C apt-get dist-upgrade -V -t $RELEASE Cause it would upgrade too much. I instead did so with meta packages for Plasma, yet it still pulled libglib from experimental and things did not work as expected, maybe due to a partial upgrade of Plasma packages. Back then I downgraded everything to 5.20 again and reverted all the other package upgrades to Debian experimental as well. So I would like to just install Plasma 5.21.1 from experimental, but that complete, without upgrading unrelated packages to experimental as well. Any aptitude / apt foo magic recommendation? Otherwise I try to come up with something myself. Best, -- Martin
KF 5.78 coming to unstable
Hi! I expect it to be a smooth upgrade, using the version in experimental already. Please wait for packages to be completely build and be careful with dist-upgrade during the time required for building everything. You can help by reporting bugs if any. Please refer to my previous mail for details. Best, -- Martin
Bug#974860: Forwarded to upstream
Silvério Santos - 24.12.20, 14:18:18 CET: > forwarded -1 https://bugs.kde.org/show_bug.cgi?id=430787 Please retest once you upgraded to Plasma 5.20 and KF 5.77. They should appear in testing soon. Have a Merry Christmas if you celebrate it, have a quiet and peaceful time, -- Martin
Re: Dolphin search does not work
Miguel A. Vallejo - 24.12.20, 14:26:02 CET:
> Indexing the content of files is nice when you have only a few dozen
> files. When you have thousands and thousands of PDF files content
> indexing is just a nightmare, a big cpu/memory/disk waste and does not
> work at all. Baloo should be completely optional and never be
Oh, it works here on dual SSD BTRFS RAID 1:
% LANG=en balooctl status
Baloo File Indexer is running
Indexer state: Idle
Total files indexed: 395,505
Files waiting for content indexing: 0
Files failed to index: 0
Current size of index is 3.89 GiB
And it is very nice in combination with Alt-Space for invoking KRunner.
I added some exclude folders though to reduce the amount of files a bit –
from '.config/baloofilerc'
exclude filters=[…],*.ytdl
exclude folders[$e]=$HOME/.cache/,$HOME/.local/,[… some backup and
archival folders…]
I reported *.ydtl for youtube-dl and AFAIR it has been added upstream as
a filter.
> activated by default. Same thing for Akonadi. My only gripe with KDE
> is it is full of "utilities" and "features" enabled by default that
> produce more problems than benefits. One you disable / uninstall all
> of them, KDE works like a charm.
Well actually I removed the executable permission from
akonadi_indexing_agent again. Cause here I indeed I'd say it does not
really work very well, at least not with lots of mail. Why?
Mostly cause it blocks out foreground activity like I click on a mail in
KMail and like to see its contents. But also cause the whole indexing
traffic goes through the database, be it MariaDB or PostgreSQL. Basically
I have seen the laptop at limits with I/O to SSDs for minutes and more.
Here I can confirm that it bogs down other workloads. When during an
Akonadi upgrade akonadi_indexing_agent is replaced with a new version
and thus is executable again, I usually notice it cause at some time
when the indexing kicks in the laptop becomes so slow, that I usually
kick the akonadi_indexing_agent process, but then also stop Akonadi,
cause the database would otherwise continue to do lots of I/O for
minutes.
Anyway to cut a long story short: The issues are known. Daniel Vrátil
was working on it ("make indexing great again") but while he completed
parts of the work there is still a piece missing.
> Of course it is just my opinion.
Of course your mileage may vary, especially in case you have still files
on a hard disk.
Ciao,
--
Martin
Re: Dolphin search does not work
Norbert Preining - 24.12.20, 01:43:38 CET: > > Do you have Baloo activated? > > and, in addition, is baloo currently indexing files? It seems that > when baloo is activated, and indexing hasn't been finished, searches > in dolphin simply terminate with "not found" > > https://bugs.kde.org/show_bug.cgi?id=420172 > > That would explain the case on my computer, where I turned it on just > recently and it has to index a few million files. Search works just fine here with Baloo activated! I did not try during indexing however. During the package builds there has been a time where Baloo and Kinit was still at 5.74 while other stuff was at 5.77. At this time I installed Baloo KF packages from experimental, yet it did not start. I had some hint in ~/.xsession-errors that a library could not be found but it referred to kinit. After everything was at 5.77 from unstable, Baloo worked fine. I did a "balooctl purge" do re-index everything cause I read in various updates by Nate Graham or on KDE web page that there have been significant changes in how it stores things into the Xapian database that make is more efficient. Norbert, Baloo is KDE's take on desktop search. These days it mostly works for me. I think there is still and issue with BTRFS RAID 1 that it can think at some time that the filesystem has changed and thus is would index files as new it already knows. But in case you don't use that it should just be fine. I use BTRFS RAID 1 for /home and / and will observe whether that still happens. Merry Christmas to everyone who celebrates it, a quiet and peaceful time to everyone anyway, Best, -- Martin
Wohooo! Plasma 5.20 and KF 5.77 coming to unstable
Hi! If you celebrate it, feel free to see it as a Christmas present, otherwise you can of course also rejoice about it: Just in time for the upcoming freeze Norbert uploaded Plasma 5.20 and KF 5.77 packages to unstable. Beware from apt dist-upgrading too quickly. Packages are being built right now and if you upgrade too quickly, apt may remove some packages. So as usual *always* check the output of apt before confirming it. If apt likes to remove half of your desktop, better cancel the operation. That said I have tested Plasma 5.20 from experimental and I am really happy about it. I did not have yet a chance to test KF 5.77 from experimental, but I bet everything will be fine. As usual before reporting a bug to the Debian bug tracker, please make the upgrade is complete. Also in case it is a clear upstream bug, you can help by reporting on https://bugs.kde.org first and then mention the URL to the upstream bug report in your Debian bug report. If unsure about whether to report or not, please ask here. I'd like to thank everyone who worked together so nicely in the last months to help to provide up-to-date Qt, Plasma, KDE applications including KDEPIM and KDE Frameworks for Debian. I think Debian Bullseye is well set regarding Qt, KDE and Plasma stuff. Now if you are using Unstable you can soon help to test. For Testing you need to wait a bit longer. Have a Merry Christmas, if you celebrate it, and a peaceful and quiet time to relax, -- Martin
Re: KMail: segfault on trying to send GPG encrypted mail
Hey Sandro. Sandro Knauß - 11.12.20, 23:25:54 CET: > > Do you want me to file a bug report? If so, against which package? > > > >From the backtrace you see that it is messagecomposer, that is inside > >the > messagelib package. But no need to file a bug, there is already a > patch prepared for the next upload: > > https://salsa.debian.org/qt-kde-team/kde/messagelib/-/blob/master/ debian/patches/upstream-FIX-messagecomposer-cryptocomposertests-Use- EncryptJ.patch Thank you very much. I just updated to KDEPIM 20.08.3 and can confirm that encryption and signing works nicely again! Best, -- Martin
Re: You can help: Test Plasma 5.20.4 and test applications 20.12
Hi Marco. Marco Valli - 14.12.20, 11:23:18 CET: > klipper plasmoid (plasma-workspace-data) claim > qml-module-org-kde-prison (barcode API) to be installed to work. > Seems that this package don't exist in Debian so i had need to modify > the file Thanks for this one. Good as a work-around till the fix the missing packages are available. Ciao, -- Martin
Re: You can help: Test Plasma 5.20.4 and test applications 20.12
Martin Steigerwald - 12.12.20, 19:37:16 CET: > But beware currently Qt 5.15.2 is entering into Sid. It may need a day > or two to complete. Be extra careful during that time. I was able to upgrade to Qt 5.15.2 successfully now. -- Martin
Re: KMail: segfault on trying to send GPG encrypted mail
Hi Sandro. Sandro Knauß - 11.12.20, 23:25:54 CET: > > Do you want me to file a bug report? If so, against which package? > From the backtrace you see that it is messagecomposer, that is > inside the messagelib package. But no need to file a bug, there is > already a patch prepared for the next upload: Great! Thank you a lot, Sandro! Best, -- Martin
You can help: Test Plasma 5.20.4 and test applications 20.12
Hi! If you are feeling adventurous and are using Sid, then you can help by testing Plasma 5.20.4 from experimental. I installed it using apt install -t experimental plasma-base "plasma-base" is a new package to keep the versions of all Plasma packages in lock step. But beware currently Qt 5.15.2 is entering into Sid. It may need a day or two to complete. Be extra careful during that time. Also you can help test new application 20.12 packages as they enter unstable. Use them and report any issues you find with them. Please do this only if you feel up to it and are willing to keep the pieces in case something breaks. Of course you can always ask for help here, but it would be good if you are willing to do your best to resolve and diagnose issues on your own first and then if need be report with as much detail as possible. If unsure whether it is really a Debian bug or you like to learn about which package to report the bug for, feel free to ask here first. So far I am very happy with Plasma 5.20.4 and those KDE application packages I upgraded. I thank Norbert, Aurélien, Sandro who is in the process to upgrade KDEPIM packages to 20.08.3, Dmitry and everyone else who is involved with upgrading the packages or helps testing them. Thank you, -- Martin
Re: KDE Plasma LTS for Debian stable
Simon Frei - 10.12.20, 18:46:16 CET: > I understand the question as why is debian targeting 5.20 for the next > stable instead of 5.18 LTS. The answer is simple: LTS means 1.5 year > of support, maybe more [1]. That's not long enough for the debian > release cycle: 5.18 was at the beginning of this year. That means > support will end at about the time or shortly after the next debian > stable will be released. Basically as far as I am aware Debian Qt/KDE team never actually cared about that a Plasma LTS release would be used. In the end, critical fixes could be forward- or backported from an LTS release to whatever version Debian stable will have. And after end of LTS, a forward- or backport of a fix would be needed anyway. Also AFAIR this has been discussed here or on another Debian KDE related mailing list before. Best, -- Martin
Re: KMail: segfault on trying to send GPG encrypted mail
Hi Sandro. Sandro Knauß - 21.11.20, 17:29:32 CET: > I can reproduce this issue and also have an idea what is wrong in the > code. Encrypt uses the async method of gnupg and sign+encrypt till > using the old non-async method. It seems like gnupg has changed > something in the last version(s) and the async method breaks somehow. > I've seen this issue also for other parts. I'll try to create a patch > the next weeks. Thank you very much. Do you want me to file a bug report? If so, against which package? Best, Martin > > > I found out yesterday that trying to send a GPG encrypted mail > > > gives > > > > > > KMail got signal 11 (Exiting) > > > > > > after confirming the encryption related dialog windows. > > > > Same here on an up-to-date Sid. > > > > A trivial workaround is to also sign the message. > > > > @++ -- Martin
Re: Upgrade partially some packages (Plasma 5.19. 5 - 3) on testing broke plasma.
Gary Dale - 19.11.20, 12:39:52 CET: > > What I did was switch to Windows for the 3 day interval so I could > > work whilst Debian sorted itself out. That worked for me. Other > > things worked for other people. I'm cool with that. > > That's a terrible solution. While I don't particularly care for Gnome, > it's far better than Windows. I could continue to work while looking > for a solution. Far better than giving up all that Linux offers that > Windows can't touch. > > Moreover, the workarounds only stopped me from using Plasma for a > short period - not 3 days. It was an annoyance, not a tragedy. I still remember a hefty Qt transition from a longer time ago. As far as I remember I used MATE temporarily. As long as Qt is operational one could also use LxQt. Since it is pretty small and in part uses the same libraries from KDE Frameworks I have installed it in addition to Plasma. The most important thing is: Sid is still unstable, testing is still testing. As much as I bet many users would like to: Both are not the same as rolling distributions for regular end users. They may be similar and it is a good idea to do what is reasonably possible to ensure smooth transitions, but they are still not the same as rolling distributions which are intended for regular end users. Users of Debian Testing and Unstable are still beta testers. Also in such a case where I do not announce when a huger update comes to Sid on this mailing list. Users who are not comfortable with finding workarounds like installing a different desktop environment IMHO should use Debian stable or one of the Debian derivatives that aim for a rolling release model for end users. That written, I only had to install a different DE in very rare cases. Users who expect Debian Sid or Debian Testing to be stable at all times are very likely to be disappointed at some time. That are at least my thoughts on this. I use Debian Sid on my production machine since ages. But I usually know how to fix things up when they break or when to defer an update. Ciao, -- Martin
Re: Kde window rules dialogue
Joe McEntire - 10.11.20, 18:12:01 CET: > Does anyone else have issues getting the edit dialogue to come up in > kde 5.19 or higher? Basically if you go to system settings, then to > window management, then window rules and add a new rule, then finally > click the pencil icon to edit the rule, nothing happens. This is also > true if you right click the titlebar of a window and then go to more > actions, then configure special window setting or special application > settings, nothing happens. I'm curious if this is a kde bug, that > hopefully gets fixed before the Debian freeze, or if I'm simply > missing a package or something. There was a missing dependency which I wrote in my post Plasma 5.19.5 and Qt 5.15 in unstable already. After installing qml-module-org-kde-kitemmodels the window rules editor worked for me. CIao, -- Martin
KMail: segfault on trying to send GPG encrypted mail
Hi! On Debian Sid, as of yesterday I think. But had new Plasma with experimental packages before. I found out yesterday that trying to send a GPG encrypted mail gives KMail got signal 11 (Exiting) after confirming the encryption related dialog windows. Before I dig deeper into it: Anyone else with this issue? Anyone any clue what this might be? It worked before, so I bet it may have to do with some less than optimal version mix or so. 'dpkg -l | grep 5.17' shows no result however. Best, -- Martin
