Bug#1013896: qtbase-opensource-src: Use KDE Qt as upstream instead of qt.io
On Wed, 13 Jul 2022 21:02:02 +0300 Dmitry Shachnev wrote: > > I expect users to complain if something doesn't work. > > Also note that now we get releases from Qt every couple of months, so sooner > or later we will get most of the patches this way (and it will be easier to > deal with the remaining ones). > Eventually yeah, but it can be a long while because a bunch of these patches are backports from Qt 6 by the KDE team and upstream Qt doesn't bother to backport to 5.x. Shmerl.
Re: Re: Status of Plasma 5.18/5.19?
On Mon, 27 Jul 2020 12:48:32 +0200 Marco Valli wrote: > but since Sid is not a rolling release the debian kde > team can avoid to works with m*r*ns. Seriously, without anything constructive to contribute to the discussion, such comments aren't useful to anyone. This list shouldn't be a place for flamewars. Debian unstable / testing are used as semi-rolling distros by a lot of users. So packages which are out of date means far from ideal situation. Lack of resources can cause it, but it's not a norm. Outdated Plasma is just another incentive for people not to use Debian, so it's surely something those who care about Debian should try to avoid. Shmerl.
Bug#903919: plasma-browser-integration: Description shouldn't be limited to chromium
Package: plasma-browser-integration Version: 5.13.1-1 Severity: normal Currently the description says: "Chromium integration for Plasma" It's intended to be used with multiple browsers, including Firefox, so the description should be more generic. Something like: "Web browsers integration for the Plasma desktop". See: https://github.com/KDE/plasma-browser-integration https://community.kde.org/Plasma/Browser_Integration -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plasma-browser-integration depends on: ii kio 5.47.0-1 ii kpackagetool5 5.47.0-1 ii libc6 2.27-3 ii libgcc1 1:8.1.0-9 ii libkf5activities5 5.47.0-1 ii libkf5completion5 5.47.0-1 ii libkf5configcore5 5.47.0-1 ii libkf5coreaddons5 5.47.0-1 ii libkf5dbusaddons5 5.47.0-1 ii libkf5i18n5 5.47.0-1 ii libkf5jobwidgets5 5.47.0-1 ii libkf5kiocore55.47.0-1 ii libkf5kiowidgets5 5.47.0-1 ii libkf5notifications5 5.47.0-1 ii libkf5package55.47.0-1 ii libkf5plasma5 5.47.0-1 ii libkf5runner5 5.47.0-1 ii libkf5service-bin 5.47.0-1 ii libkf5service55.47.0-1 ii libkf5widgetsaddons5 5.47.0-1 ii libkf5windowsystem5 5.47.0-1 ii libqt5concurrent5 5.10.1+dfsg-7 ii libqt5core5a 5.10.1+dfsg-7 ii libqt5dbus5 5.10.1+dfsg-7 ii libqt5gui55.10.1+dfsg-7 ii libqt5network55.10.1+dfsg-7 ii libqt5widgets55.10.1+dfsg-7 ii libstdc++68.1.0-9 plasma-browser-integration recommends no packages. plasma-browser-integration suggests no packages. -- no debconf information
Firefox scrolling is broken in Plasma 5.10.5?
After upgrading to Plasma 5.10.5 in Debian testing, I noticed that Firefox (56.0b8 in my case) is not reacting on scrolling or any mouse action like middle clicks on the left most edge, when it's maximized. I'm not sure whether it's Plasma or Firefox issue. Did anyone notice it? For now I opened Firefox bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1396445[1] But it as well can be KDE bug really. Hillel. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1396445
Re: Plasma 5.10
I just installed in Debian testing it and it's working well! The most awaited thing for me was support for openconnect VPN in the network manager UI. With all the freezes and delays it took forever, but it works! Though the horrendously slow startup time (after log-in) is still here. I was holding off filing bugs, since I thought it could be fixed in newer Plasma, but apparently it's not. I'll file a KDE bug about it, Hillel.
Re: Plasma 5.10
On Fri, 1 Sep 2017 11:46:30 +0200, newbeewan wrote: > I just update my laptop to plasma 5.10 in experimental. > As far I test it, everything is working very well, Thank you for all the work > ! What is the good way to install it from experimental to Debian testing? Is there some meta package which will pull in all needed dependencies? Or you install it all manually piece by piece? I know that to do it in general for testing, I need to enable both unstable and experimental sources (otherwise some mismatch can creep in). But without meta package it looks rather complicated. Same question can be applied to unstable really, without the extra complicating testing part. I.e. what's the recommended meta package for installing plasma update with all needed frameworks and etc.? Thanks, Hillel.
Re: Plasmashell start late
On Tue, 21 Mar 2017 12:54:36 +0100, MERLIN Philippe wrote: > Why when opening a session Kde by sddm plasmashell is launched last so that on > the screen all applications that were active at the closing of the previous > session > are already started without that neither the background screen or the task > bar. Which > gives an unfinished aspect to Kde nor professional. Yeah, I have the same issue. It happens when you don't use an SSD, and heavy I/O bogs PlasmaShell down. Please report it to KDE bug tracker though. It's not something Debian specific. Regards, Hillel Lubman.
Re: kde 5.7
On Sat, 09 Jul 2016 18:46:43 +0200 Martin Steigerwald wrote: > I meanwhile sent a mail to upstream distribution mailinglist exactly asking > about upstream recommendations about this. I intend to forward an answer to > debian-qt-kde mailing list and ping the team on IRC about it, cause it really > is no user support issue and so discussing it here leaves it to pure chance > whether one of the packagers picks it up. Thanks Martin, that is very helpful, especially if you think that Debian Qt/KDE packaging team isn't reading this list (I wasn't aware of this). As Diederik said, it's happening fairly regularly now, that mixed combination of frameworks causes breakage, so if Debian migrations method can ensure that frameworks packages enter testing all at once, it sounds like a good approach and will provide improvement for testing in both testability and bug reporting and actual usability. And from what I understood, if upstream developers already view frameworks as related set of packages that shouldn't be mixed, it should translate into related transitions naturally. And while you might hold that testing is not supposed to be used a day to day distro, and is purely for testing, I'm sure you are aware there are other opinions, and there is no uniform position on this even amongst Debian developers, let alone amongst actual Debian users. Just because there is a disagreement, doesn't mean things can't be improved in a way that benefits everyone in the end :) Regards, Hillel.
Re: kde 5.7
On Fri, 08 Jul 2016 20:41:08 +0200, Martin Steigerwald wrote: > If you don´t want to wait: Use unstable and be prepared that there also > breakups and issues can happen. Its called unstable or sid for a reason. That > said, I think for following Qt/KDE packaging development in Debian it may be > more suitable than testing. > > If you don´t want to deal with development issues like this, use stable. > > And if you want to have a new stable version each 6 months, help making this > a > reality or switch to a different distro. All of those are far from ideal solutions, and translate into: "KDE isn't really normally usable in Debian testing". The better answer would be how it can potentially be improved. We are all here interested in improving Debian, not in saying "switch to another distro or use a broken option". > That said, I intend to train myself in not even responding to complaints like > this any more cause that is not where I want to spend my energy. Not sure where you saw any complaints. I was asking about what the advised approach is for users of testing. Especially when some frameworks packages are stuck like this for weeks, while others enter and introduce breaking incompatibilities. Since frameworks release cycle is around one month, when package is stuck for weeks it basically messes the whole frameworks entry in testing (and then next upload cycle begins and things to add to the previous issues). The way I see it, improvement can be achieved by providing some relation between packages. I.e. making sure they enter testing all at once, and if one is stuck, other related ones wouldn't enter. This would ensure that frameworks all enter at once, and users of testing would be able to continue rolling the rest of their system, even if frameworks are stalled. Do you think it's a feasible solution, or it doens't fit into Debian methodology? Or you think frameworks shouldn't be seen as one related set of packages? Again, to be clear this is not a complaint or rant, but discussion about how to improve usability of testing rather than dismissing it as a non issue. Regards, Hillel.
Re: kde 5.7
On Fri, 08 Jul 2016 16:38:15 +0200, Martin Steigerwald wrote: > Yep, further packages coming. Maxy started uploading Plasma 5.7. What about frameworks packages? They still appear to be stuck and not moving to testing. For example: https://tracker.debian.org/pkg/baloo-kf5[1] Will testing users need to wait until next frameworks version? In general, when such hold up happens, what are Debian testing users recommended to do? Regards, Hillel Lubman. [1] https://tracker.debian.org/pkg/baloo-kf5
Re: Krunner stopped finding and running anything in Debian testing
On Tue, 05 Jul 2016 22:50:11 +0200, Martin Steigerwald <mar...@lichtvoll.de> wrote: > Maybe inconsistent versions in testing currently. > > I use Debian Sid and krunner works just fine here, so I suggest you wait a bit > and then upgrade again. I usually don't like doing it, but this time I enabled unstable in /etc/apt/sources.list.d and run this script: http://pastie.org/10899748 to make sure all frameworks packages packages are at 5.23. Quite a number of new frameworks packages were installed in the process. Then I disabled unstable again. Now my desktop is back to usable state. It becomes a real pain to update testing. Frameworks come out every month, and updating them consistently is a mess as you can see. Can anything be done to improve this situation? Is there a way to mandate from the repo side, that frameworks packages should be only pushed out together, so if one is stuck, others shouldn't enter testing either? I suspect a similar thing should be applied to the related versioned set of plasma packages. Regards, Hillel Lubman.
Re: Krunner stopped finding and running anything in Debian testing
It's possibly caused by some KDE frameworks packages being stuck in 5.22 and not migrating from unstable to testing (while others already being 5.23). I was lax and allowed this mix this time, and again it shows that it should never be done until all of the frameworks packages are the same version (same applies to Plasma packages I suppose). Example of stuck packages (looks like they fail to build on some archs): https://tracker.debian.org/pkg/baloo-kf5 https://tracker.debian.org/pkg/ki18n Regards, Hillel Lubman.
Krunner stopped finding and running anything in Debian testing
After today's dist-upgrade in Debian testing, Krunner (Alt+F2) doesn't find anything, and can't even launch anything when I type some existing binary in it. Same thing happens now with application dashboard (i.e. launcher menu). It can't find anything when I type things there. Is it some broken update, or something got broken randomly on my system? Thanks, Hillel Lubman.
Re: Recommended way of updating Debian testing when new KDE frameworks rolls in?
On Thu, 2 Jun 2016 10:53:44 +0200 Andrej Kacian <sand...@kacian.sk> wrote: > I tried to do that as well, but I still get most of the bugs from the > incomplete upgrade, including the huge titlebars. Perhaps package name > wildcards in pin are incomplete? I use: > Package: libkf5* plasma* kde-plasma* libplasama* I'm not sure, I simply reverted all packages using in /etc/apt/preferences.d/ this in addition to snapshot repo: Package: * Pin: origin "snapshot.debian.org" Pin-Priority: 1001 That seems like most straightforward way. Regards, Hillel Lubman.
Recommended way of updating Debian testing when new KDE frameworks rolls in?
Recently, I noticed that KDE Frameworks packages (such as libkf5*) started updating from 5.16.0 to 5.22.0. I suspected that partial update of those packages can cause instability, but decided to experiment, and yes, it caused a major mess with fullscreen applications like games hanging the desktop and other bugs happening. So I reverted Debian to previously usable state (20160523T045008Z snapshot) where I keep it now and periodically check changes like this: aptitude search -F"%p %v %V %d" libkf5 | grep -v none | grep -v 5\.22 I wait until that list goes down and all 5.16 → 5.22 transitions are exhausted. In general, is it always recommended to wait until all likf5* reach the same version before updating? Or they are supposed to be interoperable in the mixed installation and my case was a bug which shouldn't have happened? And what else in KDE requires synchronized update to avoid problems? Thanks! Hillel Lubman.
KDE Plasma 5.5.3 in Debian?
Hi. Is there some plan to add the newest KDE Plasma desktop (5.5.3) to unstable / testing (current one is still 5.4.3) or there are some issues with it that delay it? Thanks, Hillel Lubman.
Re: baloofilerc file created in two different places
I think $HOME/.config/baloofilerc is used by baloo-kf5, while $HOME/.kde/share/config/baloofilerc was used by older baloo (so if you switched to baloo-kf5 you can remove the second one). In general, I noticed that quite a number of KDE related config files moved to $HOME/.config from $HOME/.kde/share/config. Regards, Hillel Lubman.
Re: baloofilerc file created in two different places
Actually you are right, I just noticed that file in $HOME/.kde/share/config is created again, even after I deleted it. I'm not sure if it's supposed to be that way - you should probably file a bug for KDE: https://bugs.kde.org (for Baloo component). Regards, Hillel Lubman. On Thursday, October 15, 2015 02:55:47 advocatux wrote: > > El 14/10/15 a las 16:21, Hillel Lubman escribió: > > I think $HOME/.config/baloofilerc is used by baloo-kf5, while > > $HOME/.kde/share/config/baloofilerc was used by older baloo [-] > > Thank you for your reply. > > What you said is what I thought but what confuses me is both files were > created at the same time. So the question is why a baloofilerc file is > also created in an "old" file path? > > Have you experienced that same behavior? > > Regards > > -- > advocatux
Re: Re: Plasma desktop unusable in stretch
On Thu, 3 Sep 2015 21:21:52 +0500 Andrey Rahmatullin wrote: > That's the main misunderstanding. > We had several tries to design and/or create a rolling Debian distro but > there is nothing currently existing AFAIK. > And it takes a lot more effort than is currently spent on unstable and > testing (which is already a lot). So what happened to these efforts to make always usable / always releasable testing? I remember such proposals, for example: https://lwn.net/Articles/406301/ https://lwn.net/Articles/550032/ I always viewed testing as intended at desktop usage which ideally should suit causal non technical users too, but at the same time I know that such goals weren't yet reached and things can break seriously (so using snapshots to avoid major issues like recent Plasma 5 breakage is something every user of testing should learn). That's why I'm still hesitant to recommend testing for those who aren't ready to deal with such issues. So are there still any plans to change that like above, or they were stalled because it requires too much resources to implement and maintain? Regards, Hillel Lubman.
Re: Re: Plasma 5 doesn't start after update on Stretch
On Wed, 19 Aug 2015 19:50:22 Jimmy Johnson wrote: I downloaded libkdecorations2-5_5.3.2-1_amd64.deb and libkdecorations2private5_5.3.2-1_amd64.deb from https://mirrors.ocf.berkeley.edu/debian/pool/main/k/kdecoration/ to my /home/jimmy and installed them one at a time using 'dpkg i libkdecorations2-5_5.3.2-1_amd64.deb' and 'dpkg i libkdecorations2private5_5.3.2-1_amd64.deb' and was able to downgrade with no problems, all other packages have been upgraded, rebooting and login with no problem. I hope this helps anyone who got hit by the bug. I was hit by the same bug in Debian testing and was able to downgrade those packages using snaphot.debian.org. Here is what I did for the reference: Created /etc/apt/preferences.d/snapshots like this: Package: * Pin: origin snapshot.debian.org Pin-Priority: 1001 Then created /etc/apt/sources.list.d/snapshots.list like this: deb http://snapshot.debian.org/archive/debian/20150817T213310Z/ testing main contrib non-free deb-src http://snapshot.debian.org/archive/debian/20150817T213310Z/ testing main contrib non-free And then run: sudo apt-get update sudo apt-get dist-upgrade and it downgraded those packages to the working set. Don't forget to comment out or remove that preference and apt source after you downgrade the packages. Regards, Hillel Lubman.
Bug#794419: sddm doesn't source /etc/profile and $HOME/.profile
I see that sddm contains /usr/share/sddm/scripts/Xsession with those includes, but apparently in my case it didn't help including /etc/profile and $HOME/.profile (my shell is bash, and I have $HOME/.profile and no $HOME/.bash_profile). I tested, and sddm does include $HOME/.xsessionrc however. -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2781524.m1BSmMgG83@shtub-cm
sddm doesn't source /etc/profile and $HOME/.profile
Hi. I stumbled upon the issue that sddm doesn't source $HOME/.profile and /etc/profile, which broke some PATH settings for me and some other env variables which I put in $HOME/.profile. In particular, I noticed that packaged minetest game doesn't start with the Debian provided launcher, because it relies on /usr/games being in the PATH, which was set in /etc/profile, and sddm ignores it. With kdm it all worked. I filed a bug to sddm (https://github.com/sddm/sddm/issues/448[1]) but they replied that it's an expected behavior. It probably means that Debian should change something to accommodate this difference. Should I file a bug for sddm in Debian or for something else? Regards, Hillel Lubman. [1] https://github.com/sddm/sddm/issues/448
Bug#794419: sddm doesn't source /etc/profile and $HOME/.profile
Package: sddm Version: 0.11.0-3 Severity: important Dear Maintainer, After upgrading Debian testing to KDE Plasma 5, things which rely on /etc/profile being sourced became broken because sddm doesn't source it unlike kdm did (it also doesn't source $HOME/.profile unlike kdm, so if anything relied on that it would be broken too). For example, /etc/profile adds /usr/games to the PATH, and minetest and a number of other Debian games rely on this. With sddm + Plasma 5 their launchers became broken in Debian. I filed the bug upstream: https://github.com/sddm/sddm/issues/448 and sddm developers commented that profiles aren't supposed to be sourced by the display manager, so there should be some other way of handling this in such case. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sddm depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.57 ii libc6 2.19-19 ii libgcc1 1:5.1.1-14 ii libpam0g1.1.8-3.1 ii libqt5core5a5.4.2+dfsg-5 ii libqt5dbus5 5.4.2+dfsg-5 ii libqt5gui5 5.4.2+dfsg-5 ii libqt5network5 5.4.2+dfsg-5 ii libqt5qml5 5.4.2-4 ii libqt5quick55.4.2-4 ii libstdc++6 5.1.1-14 ii libsystemd0 222-2 ii libxcb-xkb1 1.10-3+b1 ii libxcb1 1.10-3+b1 ii qml-module-qtquick2 5.4.2-4 ii sddm-theme-breeze [sddm-theme] 4:5.3.2-4 sddm recommends no packages. sddm suggests no packages. -- debconf information: * shared/default-x-display-manager: sddm sddm/daemon_name: /usr/bin/sddm -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150802201414.12267.42015.reportbug@shtub-cm
Re: Plasma/KF5 : Situation in testing
On Tue, 28 Jul 2015 17:19:35 +0200 Jeremy Lainé wrote: We are working on getting plasma-desktop to transition to testing as soon as possible (hopefully in 2 days time), which will resolve both those issues. In the meantime, it might be best to refrain from updating your boxes running testing. I decided to pause updates in testing for a while (after reverting the broken plasma-nm using Debian snapshots). Now I see that plasma-workspace entered testing, but plasma-desktop is stuck because it breaks kde-full which depends on kdeplasma-addons which depends on the removed libgee-dev: https://release.debian.org/migration/testing.pl?package=plasma-desktop https://release.debian.org/migration/testing.pl?package=kde-full https://release.debian.org/migration/testing.pl?package=kdeplasma-addons https://tracker.debian.org/pkg/libgee So is it still recommended to wait, or there is some proper way to install Plasma 5 in testing now? Regards, Hillel Lubman.
Re: Re: Which packages for Plasma 5?
On Friday, 17 Jul 2015 21:01:20 Martin Steigerwald wrote: And yes, some metapackages kde-full and kde-standard will have to go for now. The update is not atomic. I bet they can be installed at a later time or may even be replaced by something like plasma-full and plasma-standard. Remember you are using unstable. And the Debian Qt/KDE team is quite small. Give it some time till completion. Or help. Hi. I'm a user of Debian testing (and KDE). How would this switch to Plasma 5 affect testing? Will it be not atomic either and it's recommended to pause updates for testing now to avoid semi-broken state, or in testing this should normally happen in more consistent fashion? And if the former, what would be an indicator that accumulated update is consistent enough? Thanks! Hillel Lubman.
