Re: KDE Plasma LTS for Debian stable
On 10/12/2020 18:12, Joe McEntire wrote: > I don't know where this information is coming from, but 5.19.5 is in testing > right now. Experimental has 5.20 and there's talk of getting 5.20.5 in time > for the freeze, so we'll probably end up with some iteration of 5.20 in > stable > if I had to take a stab at it. I cannot imagine a world where Debian's KDE > team puts in all the work to get these newer versions in, just to roll back > to > something that is older than what is in current stable. Current stable > (Buster) uses 5.14! So rest easy, there's no way we're going to have 5.12 or > 5.8 in stable, it's just not a thing. > > https://tracker.debian.org/pkg/kwin > 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. [1] https://community.kde.org/Schedules/Plasma_5#LTS_releases
Re: Bottom bar not hiding after switching window
Dear Thom, It doesn't matter how I switch, it's the same behaviour whether I "alt-tab" or click with the mouse onto another window: Switch window, bar is shown (regardless of where my mouse is, also far away from the bar), then move my mouse to the bar and away from it (no clicking) and it stays hidden until I switch windows again (or move the mouse to the bottom). And there's nothing asking for attention as far as I can dicern - the "program indicators" are usual orange if that's the case and none are now. Cheers, Simon On 10/06/2020 18:14, Thom Castermans wrote: > Dear Simon, > > I also have my taskbar set to auto-hide, and did have some problems > with it in the past, but those have been resolved. What exactly do you > mean with switching windows? Are you switching using a keyboard > shortcut? AFAIK the taskbar is shown if and only if the mouse cursor > is close to the bottom of the screen. > > What *might* be happening is that one window asks for attention > (notification etc.). That causes the taskbar to remain visible. > > Cheers, > Thom > > > Op wo 10 jun. 2020 om 14:56 schreef Simon Frei : >> I more or less recently switched over from XFCE to KDE and must say, I >> am pretty impressed :) >> Thanks a lot for packaging this fine DE for debian! >> >> I am on debian testing. >> One quite annoying behaviour I observe is that the bottom bar (set to >> auto-hide) is not auto-hiding when switching windows. It does auto-hide >> when I move the mouse onto the bottom bar and away again. That's quite >> annoying especially on a small laptop screen when the open window has an >> input field at the bottom (like most messengers). >> Can anyone reproduce? I assume not, at least I couldn't find any info on >> anyone having the same problem online. >> Is there a cache/config file relevant to this behaviour I could check or >> move out of place to see if it's a misconfig? >> >> Thanks in advance for any help. >> >> Cheers, >> Simon >>
Bottom bar not hiding after switching window
I more or less recently switched over from XFCE to KDE and must say, I am pretty impressed :) Thanks a lot for packaging this fine DE for debian! I am on debian testing. One quite annoying behaviour I observe is that the bottom bar (set to auto-hide) is not auto-hiding when switching windows. It does auto-hide when I move the mouse onto the bottom bar and away again. That's quite annoying especially on a small laptop screen when the open window has an input field at the bottom (like most messengers). Can anyone reproduce? I assume not, at least I couldn't find any info on anyone having the same problem online. Is there a cache/config file relevant to this behaviour I could check or move out of place to see if it's a misconfig? Thanks in advance for any help. Cheers, Simon
Bug#919860: qtcreator: Probably missing clang dependency
I just ran into the same issue (long time since I used qtcreator last) and removing QtProject/ and QtProject.conf fixed the issue. However I also don't want to loose my settings so I started fiddling around, and it turns out for me the error goes away if I clear the list of recent projects and manually select the project again. Thereafter I can just select that project from recent projects without any problems. Does not seem like the real source of the problem to me, but anyway it worked for me and maybe it's useful to anyone else as well.
Re: Packaging exiv2 0.27
On 01/09/2019 17:49, Steve Robbins wrote: > > Two initial observations: > > 1. The version string is wrong; which I just noticed thanks to Salsa's > lintian > checks -- see the MR page referenced above That's on purpose to the best of my understanding of the processes (which comes from a bit of documentation skimming and looking at history): I can't upload so I'd expect whoever actually does that to change the changelog to the appropriate version, i.a. drop the trailing ~ which as far as I understand is to make the unreleased version older than any other by default. Of course if the team (anyone in the) is willing to go through the sponsorship process I'd be happy to do that :) > 2. Suggest to enable the unit tests and run them in the build > I thought about that too, but wanted to get ahead with this change first before throwing another iron into the fire.
Re: Packaging exiv2 0.27
I just filed an MR, as I guess it's simpler to access/review than just pointing to a branch on my fork: https://salsa.debian.org/qt-kde-team/extras/exiv2/merge_requests/1
Bug#873369: libqt5core5a: System-wide /etc/xdg/QtProject/qtlogging.ini disables debug messages
I just wasted a lot of time finding the cause for missing debug statements on a debug build of digikam. The build uses cmake and the following option to activate debug logging: -DCMAKE_BUILD_TYPE=debug For bug reporting, we are reliant on users to be able to run a debug version (appimage) and provide us a log. Asking the user to remove this config file adds another obstacle to get a useful report. What can we do at build time to get debug statements on the console no matter what? signature.asc Description: OpenPGP digital signature
Bug#803450: Still present in 4:15.08.3-1
This is still true in version 4:15.08.3-1 (detected during compilation of digikam).
