Re: How to not update package list through plasma discover ?

[Christian Hilberg]

Hi,

Am Dienstag, 11. Juni 2024, 17:55:50 CEST schrieb Erwan David:
> I'll be temporarily with a bad connexion. During this time I'd like 
> plasma-discover to not update the package list. How can I do this ?
> 
> There is no option in discover for this. I can remove the package but 
> that would be a bit harsh

Interesting, indeed. I was thinking about something along the lines of
adding a non-existent APT cache to /etc/apt/apt.conf, like

Acquire::http::Proxy "http://non.existent:/;;

but discover would of course still try to (and fail while at it) resolve
that host, but it cannot fetch package lists then.

Trying to resolve, however, would still generate traffic, and discover
still downloads the favourite lists etc.

So, in all, that hack is not that helpful I guess...

(Bye)²,

Christian

-- 
kernel concepts GmbH       Christian Hilberg
Hauptstrasse 16hilb...@kernelconcepts.de
D-57074 Siegen Tel: +49-271-771091-11
http://www.kernelconcepts.de/  Fax: +49 271-338857-29
HR Siegen, HR B 9613
Geschäftsführer: Ole Reinhardt


signature.asc
Description: This is a digitally signed message part.

Re: windows visual preferences messed up after log-in

[Christian Hilberg]

Am Mittwoch, 13. Januar 2021, 16:46:10 CET schrieb inkbottle:
> Hi all,

++

> Since an odd fortnight to a month, many default visual parameters are weird. 
> Let me be more specific:
> 
> Every times I open Kmail, the "list" part of the main window, "subject", 
> "senders", "date", are crammed to the left. Just to the point you can't read 
> anything meaningful. For instance all subjects are restricted to "Re:...".
> 
> But the main point is, mouse-sliding the column separators, works only until 
> you close the window: every time it is closed and then opened back again, the 
> modifications I made to the column width are lost, and everything is again in 
> its unreadable configuration.
> 
> Errata: I've just check: it's every times you log-out log-in again.

Same here, on an oldish version of Kmail (5.9.3 as packaged on Debian/Buster).
Seeing the effect for some time longer, I guess. Not fully clear as of
when, exactly.

If you want to double your trouble, try switching between starting Kmail as
Kmail and Kmail within Kontact. Seems to add an extra layer of
settings-forgetfulness.

Might be an issue with the settings store, since in Buster, there has not
been an upgrade to KMail, but the odd behaviour was not apparent from the
beginning, at least not that I remember.

I have not checked with current KMail in Sid, which is far more recent
and also sits on top of a far more recent Frameworks. Might not make much
sense to report a bug against Buster now.

> [...]

(Bye)²,

another Chris

-- 


signature.asc
Description: This is a digitally signed message part.

Re: Current status of KDE in Sid

[Christian Hilberg]

Hi all,

Am Dienstag, 10. November 2020, 00:29:14 CET schrieb Miguel A. Vallejo:
> Hello Hector.
> YES!
> Your proposal worked like a charm! Everything was updated without any problem.
> Thank you!

...just as a very gentle reminder of what I had a misconception about
in the past and have since learnt:

This is exactly what unstable/testing is all about: Sorting out these kinds
of things - neither unstable nor testing are some sort of rolling release
(as I was initially mistaking it for, at least in the case of testing).

Huge thanks to the team for all the effort, and huge thanks for the
daring to endeavour into testing new KDE packages! :-)

Best,

Christian

-- 



signature.asc
Description: This is a digitally signed message part.

Re: Akonadi 4:18.08.3-6 automatically resolves mutiple merge candidates errors

[Christian Hilberg]

Am Freitag, 30. August 2019, 10:22:42 CEST schrieb Andy G Wood:
> On Thursday, 29 August 2019 19:24:26 BST Martin Steigerwald wrote:
> [...]
> > My major issue still are the Web Engine related crashes of KMail. KMail
> > crashes several times a day during filtering here¹.
> > 
> > [1] kmail: Crash during/after filtering inbox, probably related to Qt
> > WebEngine integration
> > https://bugs.debian.org/921624
> 
> Me too, though not as frequent (a few times a week) and not related to 
> filtering.  Has been present for months but I have not got around to 
> debugging.  
> I am fairly certain it happens due to html content of certain emails (crashes 
> on opening or closing the email, but not predictable), which points the 
> finger 
> at Qt WebEngine?

It is at least probable.

Try

vblank_mode=0 __GL_SYNC_TO_VBLANK=0 /usr/bin/kontact


HTH,
Christian

-- 


signature.asc
Description: This is a digitally signed message part.

Re: Buster: Konqueror as File Manager

[Christian Hilberg]

Hi Robert,

Am Freitag, 23. August 2019, 03:45:00 CEST schrieb R.Lewis:
> Hello - 
> 
> I use Konqueror as a file manager in Debian Stretch, but I have noticed the 
> following changes to Konqueror in Buster that have affected the way it can be 
> used as a file manager:
> 
> .  I cannot open Konqueror with "kfmclient openProfile filemanagement"
> .  the profiles section is missing from the Settings drop-down menu
> . Load View Profile 
> . Save View Profile As ...
> . Configure View Profiles
> . also missing from the Settings drop-down menu is "Show Sidebar  F9"
> . F9 does not work, and I have not been able to find a way to display the 
> Sidebar

Had been using Konqueror for years as a file manager before the rise of Buster.

> Under Konqueror/Help/Konqueror Introduction/Introduction, it says:
> Konqueror makes working with and managing your files easy. You can browse 
> both local and networked folders while enjoying advanced features such as 
> the powerful sidebar and file previews.
> 
> I would appreciate any suggestions how to make Konqueror as a file manager 
> work the way it has in previous versions, especially having the sidebar.

When Dolphin appeared on stage, the Konqueror devs (iirc) said that they
would like to focus more on browser capabilities so they could reduce complexity
in Konqueror by removing non-browser stuff.

I've never found myself very fond of Dolphin, matter of taste. So I've fiddled
a while to get Konqueror back to how it used to be, but eventually gave up 
(though
it may still well be possible, but I did not have enough patience and time).
Konqueror of today is not what it used to be. All for good reasons.

In the end I've switched to Krusader (had been using the Norton Commander ages
ago, then Midnight Commander) and found it to be a good replacement for 
Konqueror.

> Thank you.
> 
> Regards,
> Robert

Just my 2 cent - though no answer to the question.

Christian

-- 


signature.asc
Description: This is a digitally signed message part.

Re: SDDM and Save dialogues slow

[Christian Hilberg]

Hi there,

Am Dienstag, 28. Mai 2019, 11:28:47 CEST schrieb Andreas v. Heydwolff:
> Hello,
> 
> I'm on Stretch with backports and a regular Stretch KDE installation on
> a ThinkPad X1 Yoga (Skylake CPU and graphics, self compiled  latest
> kernel 4.14, now .122; a stock kernel 4.9 or 4.19 doesn't help).
> 
> Since some update a few weeks ago resume does wake up the screensaver
> and mouse pointer, but the login box appears only after *half a minute*
> or more whereas previously it was there immediately. This somewhat
> defeats the purpose of Sleep and Resume. The battery no longer gets
> detected, and powerdevil freezes and/or shows no options for closing the
> lid.
> [...]

A few weeks before, I've upgraded several machines from Debian/Stretch (Kernel
4.9) to Debian/Buster (4.19, newer KDE/SDDM).

I'm also seeing the seemingly endless lag between (apparent) Resume at which
SDDM shows its wallpaper graphics and the moment when the password prompt
finally shows (sometimes it would not take input, disappear, then even later
re-appear and finally taking input).

I'm seeing this on exactly one of my machines, which is a sturdy old netbook
with a dualcore N450 Atom chip and Intel integrated graphics.

I'm *not* seeing this on Intel Core Duo, i-5, i-7 and Xeon machines. The 
password
prompt shows as quickly as it used to under Debian/Stretch.

Once I'm logged in, the oldish Atom is as quick as can be expected, but it
certainly *is* somewhat slower than under Stretch. That might indeed be
due to some processor bug mitigations.

However, it seems to me that the enormous lag at the SDDM login prompt
might have a cause which is not directly (or not entirely) due to Intel
microcode updates and Kernel mitigations.

Just 2 cent,

Christian

-- 


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM 18.08.3 for Buster

[Christian Hilberg]

Am Freitag, 15. März 2019, 12:39:55 CET schrieb Christian Hilberg:
> Hi,
> 
> Am Freitag, 15. März 2019, 12:02:42 CET schrieb Andy G Wood:
> > Hello,
> > 
> > I have also been suffering from infrequent kmail crashes in recent weeks.
> > It is not related to filtering, nor is it specific to nouveau (I use the
> > NVIDIA proprietary display driver).
> 
> I'm seeing the issue with both, nouveau and (legacy 390) nvidia blob.
> Currently running Kontact inside a VM instead, let's see what that does.

(1) KMail in a Buster VirtualBox VM did not show the issue

(2) Using nouveau, it showed that the crash path led through Qt WebEngine,
but ended in the nouveau DRI lib, which is a known issue [0], [1].
Got there through the bug I filed on bugs.kde.org [2].

(3) Using NVidia 390xx legacy blob with vblank_mode=0 __GL_SYNC_TO_VBLANK=0
relaxed the situation for me, the error does not seem to occur
(at least after a few hours there's no crash yet)

(4) disabling vblank did _not_ resolve the issue when using the nouveau
driver

(5) I've seen reports where building Qt against OpenGL ES instead of GLX
resolved the issue (but made e.g. WebGL not working)

Just 2 cents.

[0] https://bugreports.qt.io/browse/QTBUG-41242
[1] https://bugreports.qt.io/browse/QTBUG-49243
[2] https://bugs.kde.org/show_bug.cgi?id=405491

> > Not currently reproducible ... and yes I need to install debug syms in
> > order to provide more than a "me too".  The impact may be wider than
> > kmail because I have also had one okular crash too.
> 
> Regarding wider impact, the traces I've seen so far point towards
> QtWebEngine, so any app integrating this might be affected.
> 
> > Andy.
> > 
> > On Friday, 15 March 2019 09:55:10 GMT Christian Hilberg wrote:
> > > Hi there,
> > > 
> > > Am Donnerstag, 7. Februar 2019, 13:20:00 CET schrieb Martin Steigerwald:
> > > > Sandro Knauß - 07.02.19, 00:33:
> > > > > Hey,
> > > > > 
> > > > > as Debian is already in freeze, the version of KDEPIM that will
> > > > > shipped with the next stable is 18.08.3. That was uploaded same days
> > > > > ago. There is no time to package 18.12.X sorry for that.
> > > > > So please test this version in more depth and report issues. If you
> > > > > also manage to point to existing bugfixes like done in #921535 it is
> > > > > very likely we can ship a that bugfix also for Buster.
> > > > 
> > > > The other issue I have since 18.08 packages is:
> > > > 
> > > > Debian #921624: kmail: Crash during/after filtering inbox, probably
> > > > related to Qt WebEngine integration
> > > > https://bugs.debian.org/921624
> > > > 
> > > > Crash during/after filtering inbox, probably related to Qt WebEngine
> > > > integration
> > > > https://bugs.kde.org/404052
> > > 
> > > Filed another one (since 18.08):
> > > 
> > > KMail (in Kontact) crashing upon start or shortly after
> > > https://bugs.kde.org/405491
> > > 
> > > It might be related (or even duplicate) to #404052,
> > > only that I do not need to have mails filtered for
> > > KMail to crash. Looks like a QtWebEngine thing.
> > > 
> > > Just like Martin, I missed out on debug syms. Got them
> > > installed now and trying to get another backtrace.
> > > 
> > > > I can add more backtraces to the upstream bug report. For some reason
> > > > DrKonqi shortened the second backtrace I had it generate after fully
> > > > upgrading to 18.08.3-1.
> > > > 
> > > > At least this one produces a crash, instead of just stalling… for
> > > > whatever reason.
> > > > 
> > > > Thanks,

(Bye)²,

Christian

-- 



signature.asc
Description: This is a digitally signed message part.

Re: Okular Trim Margin

[Christian Hilberg]

Hi,

Am Freitag, 15. März 2019, 17:23:28 CET schrieb inkbottle:
> If I download sample pdf http://www.xmlpdf.com/manualfiles/hello.pdf[1] ,
> open it in Okular and do View > Trim View > Trim Margin, well, nothing
> happens.
> 
> I am now using Okular 18.04 from experimental; I'm not ready to downgrade to
> Okular 17.12 from testing, because that version has too many annoying bugs
> (maybe mostly related to annotations, that I use a lot); anyway...
> 
> Anyway, Trim Margin hasn't worked for me for at least 2 years, so it is not
> something related to 18.04.
> 
> Actually, I've been induced to think, that it was a property of the
> documents I was opening... (like, all of them)
> 
> But a few days ago, it came to my attention that if you do the same
> manipulation with Qpdfview, with the document hello.pdf from above, the
> margin trimming thing is working, no issues whatsoever.
> 
> One possible explanation is that for 2 years or so, I've been consistently
> missing a key package.
> 
> Another, is that I'm the only one with a small screen nowadays, and
> therefore the only one observing that Trimming Margin is not working.
> 
> Hence my question: is Margin Trimming working alright for you on the above
> hello.pdf?

Works for me on Okular 1.3.2 (alias 17.12) from Debian/Buster. Have not tried
18.04, though.

> Thanks,
> Chris
> 
> 
> 
> [1] http://www.xmlpdf.com/manualfiles/hello.pdf

Cu,

Chris

-- 

Re: KDEPIM 18.08.3 for Buster

[Christian Hilberg]

Hi,

Am Freitag, 15. März 2019, 12:02:42 CET schrieb Andy G Wood:
> Hello,
> 
> I have also been suffering from infrequent kmail crashes in recent weeks. 
> It is not related to filtering, nor is it specific to nouveau (I use the
> NVIDIA proprietary display driver).

I'm seeing the issue with both, nouveau and (legacy 390) nvidia blob.
Currently running Kontact inside a VM instead, let's see what that does.

> Not currently reproducible ... and yes I need to install debug syms in order
> to provide more than a "me too".  The impact may be wider than kmail
> because I have also had one okular crash too.

Regarding wider impact, the traces I've seen so far point towards QtWebEngine,
so any app integrating this might be affected.

> Andy.
> 
> On Friday, 15 March 2019 09:55:10 GMT Christian Hilberg wrote:
> > Hi there,
> > 
> > Am Donnerstag, 7. Februar 2019, 13:20:00 CET schrieb Martin Steigerwald:
> > > Sandro Knauß - 07.02.19, 00:33:
> > > > Hey,
> > > > 
> > > > as Debian is already in freeze, the version of KDEPIM that will
> > > > shipped with the next stable is 18.08.3. That was uploaded same days
> > > > ago. There is no time to package 18.12.X sorry for that.
> > > > So please test this version in more depth and report issues. If you
> > > > also manage to point to existing bugfixes like done in #921535 it is
> > > > very likely we can ship a that bugfix also for Buster.
> > > 
> > > The other issue I have since 18.08 packages is:
> > > 
> > > Debian #921624: kmail: Crash during/after filtering inbox, probably
> > > related to Qt WebEngine integration
> > > https://bugs.debian.org/921624
> > > 
> > > Crash during/after filtering inbox, probably related to Qt WebEngine
> > > integration
> > > https://bugs.kde.org/404052
> > 
> > Filed another one (since 18.08):
> > 
> > KMail (in Kontact) crashing upon start or shortly after
> > https://bugs.kde.org/405491
> > 
> > It might be related (or even duplicate) to #404052,
> > only that I do not need to have mails filtered for
> > KMail to crash. Looks like a QtWebEngine thing.
> > 
> > Just like Martin, I missed out on debug syms. Got them
> > installed now and trying to get another backtrace.
> > 
> > > I can add more backtraces to the upstream bug report. For some reason
> > > DrKonqi shortened the second backtrace I had it generate after fully
> > > upgrading to 18.08.3-1.
> > > 
> > > At least this one produces a crash, instead of just stalling… for
> > > whatever reason.
> > > 
> > > Thanks,

(Bye)²,

Christian

-- 

Re: KDEPIM 18.08.3 for Buster

[Christian Hilberg]

Hi there,

Am Donnerstag, 7. Februar 2019, 13:20:00 CET schrieb Martin Steigerwald:
> Sandro Knauß - 07.02.19, 00:33:
> > Hey,
> > 
> > as Debian is already in freeze, the version of KDEPIM that will
> > shipped with the next stable is 18.08.3. That was uploaded same days
> > ago. There is no time to package 18.12.X sorry for that.
> > So please test this version in more depth and report issues. If you
> > also manage to point to existing bugfixes like done in #921535 it is
> > very likely we can ship a that bugfix also for Buster.
> 
> The other issue I have since 18.08 packages is:
> 
> Debian #921624: kmail: Crash during/after filtering inbox, probably
> related to Qt WebEngine integration
> https://bugs.debian.org/921624
> 
> Crash during/after filtering inbox, probably related to Qt WebEngine
> integration
> https://bugs.kde.org/404052

Filed another one (since 18.08):

KMail (in Kontact) crashing upon start or shortly after
https://bugs.kde.org/405491

It might be related (or even duplicate) to #404052,
only that I do not need to have mails filtered for
KMail to crash. Looks like a QtWebEngine thing.

Just like Martin, I missed out on debug syms. Got them
installed now and trying to get another backtrace.

> I can add more backtraces to the upstream bug report. For some reason
> DrKonqi shortened the second backtrace I had it generate after fully
> upgrading to 18.08.3-1.
> 
> At least this one produces a crash, instead of just stalling… for
> whatever reason.
> 
> Thanks,

(Bye)²,

Christian

-- 

Re: Issues Setting Up KDE Development Environment in Stretch

[Christian Hilberg]

Am Donnerstag, 1. März 2018, 10:23:25 CET schrieb Karsten Ladner:
> Thanks so much for the good feedback!
> 
> So I set up a chroot environment using debootstrap for sid. I have then
> used the tool schroot to access the chroot environment. I am wanting to
> work on Okular, so after installing all the dependencies for Okular with
> "sudo apt-get build-dep okular" I used cmake to prepare all the build
> files. Once that ran successfully, I used make to build Okular. However,
> when I ran "make test" all of the tests failed except one.
> 
> I am not sure why this is the case. I have included the output for "make
> test" in this paste bin: https://pastebin.com/M88cr1X3

I'm neither much into KDE development and their testing methods nor in schroot 
usage... did you make sure schroot mounts /proc, /sys, /dev and /dev/pts into 
the chroot environment? Also the tests might be integration tests which need 
more of Sid's KDE environment up and running for passing successfully. It 
*might* be easier to do the actual testing run within a Sid VM with your build 
directory mounted into it (building, however, for me is quicker within a 
chroot than within a VM).

HTH,

Christian

> I have also included the output for "ctest -R kimgiotest -VV" in this
> pastebin: https://pastebin.com/CE5Qgxue
> 
> Thanks
> 
> 
> On Wed, Feb 28, 2018 at 6:10 AM, Christian Hilberg <
> 
> hilb...@kernelconcepts.de> wrote:
> > Am Mittwoch, 28. Februar 2018, 10:18:16 CET schrieb Christian Hilberg:
> > > Am Dienstag, 27. Februar 2018, 23:33:09 CET schrieb Diederik de Haas:
> > > > On maandag 26 februari 2018 10:14:39 CET Christian Hilberg wrote:
> > > > > This even works with foreign architectures, as long as QEMU supports
> > > > > them. For the Raspi, I set up a Raspbian-Lite chroot, copy
> > > > > /usr/bin/qemu-arm-static into it, and am good to go for
> > > > > cross-development
> > > > > on my host.
> > > > 
> > > > Do you have some more details you can share about this? (i.e. precise
> > > > instructions)
> > > 
> > > On Debian/Stretch, the dance is as follows:
> > > [...]
> > 
> > Just for the record, here's another one detailing the procedure:
> > 
> > https://hblok.net/blog/posts/2014/02/06/chroot-to-arm/
> > 
> > (Bye)^2,
> > 
> > Christian
> > 
> > --

-- 

signature.asc
Description: This is a digitally signed message part.

Re: Issues Setting Up KDE Development Environment in Stretch

[Christian Hilberg]

Am Mittwoch, 28. Februar 2018, 10:18:16 CET schrieb Christian Hilberg:
> Am Dienstag, 27. Februar 2018, 23:33:09 CET schrieb Diederik de Haas:
> > On maandag 26 februari 2018 10:14:39 CET Christian Hilberg wrote:
> > > This even works with foreign architectures, as long as QEMU supports
> > > them. For the Raspi, I set up a Raspbian-Lite chroot, copy
> > > /usr/bin/qemu-arm-static into it, and am good to go for
> > > cross-development
> > > on my host.
> > 
> > Do you have some more details you can share about this? (i.e. precise
> > instructions)
> 
> On Debian/Stretch, the dance is as follows:
> [...]

Just for the record, here's another one detailing the procedure:

https://hblok.net/blog/posts/2014/02/06/chroot-to-arm/

(Bye)^2,

Christian

-- 


signature.asc
Description: This is a digitally signed message part.

Re: Issues Setting Up KDE Development Environment in Stretch

[Christian Hilberg]

Am Dienstag, 27. Februar 2018, 23:33:09 CET schrieb Diederik de Haas:
> On maandag 26 februari 2018 10:14:39 CET Christian Hilberg wrote:
> > This even works with foreign architectures, as long as QEMU supports
> > them. For the Raspi, I set up a Raspbian-Lite chroot, copy
> > /usr/bin/qemu-arm-static into it, and am good to go for cross-development
> > on my host.
> 
> Do you have some more details you can share about this? (i.e. precise
> instructions)

On Debian/Stretch, the dance is as follows:

* Install QEMU, especially qemu-user-static, and make sure your kernel
  supports ARM architecture format (we need /proc/sys/fs/binfmt_misc/qemu-arm)

* Setup the chroot environment via 'debootstrap', like in
  https://elinux.org/Raspbian (s/wheezy/stretch/g)
  This assumes you are on an ARM host, for cross-running we need some
  additional steps...

* Of course, you cannot just like that run arm binaries on your x86 host,
  so in the above manual, before chrooting into the Raspbian env, copy
  /usr/bin/qemu-arm-static (qemu-user-static package) from the host system
  into usr/bin/ of the chroot environment

* Before chrooting, I usually bind-mount /proc, /sys, /dev, /dev/pts from the
  host into the chroot env

* On Debian, you can now chroot into the Raspbian chroot and the binaries
  therein are run via QEMU and the kernel's foreign architectures support.
  On host systems like Arch, it might be necessary to do configuration work
  to get QEMU flying (just heard of it, never tried it)

HTH,

Christian

-- 
kernel concepts GmbH   Christian Hilberg
Hauptstrasse 16hilb...@kernelconcepts.de
D-57074 Siegen Tel: +49-271-771091-11
http://www.kernelconcepts.de/  Fax: +49 271-338857-29
HR Siegen, HR B 9613
Geschäftsführer: Ole Reinhardt


signature.asc
Description: This is a digitally signed message part.

Re: Plasma 5: no more KDEHOME?

[Christian Hilberg]

Am Montag, 26. Februar 2018, 14:35:05 CET schrieb Joao Roscoe:
> Nice, good to know.
> 
> Now, I suppose that in a few years, We'll be moving forward to a newer
> version of our distro of choice. Then we'll (again) face a transitory
> situation in which users will be able to login to different systems with
> different versions of KDE installed, what could result in some trouble, due
> to different versions of the desktop environment and applications messing
> around with configuration files. In the past, we dealt with this by
> tweaking kde so that it would use "~/.kde. to store kde
> related data, instead of plainly "~/.kde". So, looking at
> https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html,
> from now on, I guess I could have the same result by tweaking the systems
> to replace "~/.config" wit "~/.config.".

Don't forget about (at least, maybe there's more) ~/.cache/ and ~/.local/

> Is that right?
> 
> Best regards,
> Joao
> 
> On Sat, Feb 24, 2018 at 11:42 AM, Sune Vuorela  wrote:
> > On 2018-02-22, Joao Roscoe  wrote:
> > > How could I avoid conflicts between different versions of kde from now
> > 
> > on?
> > 
> > all kde and qt applications follows the XDG spec for this, and the
> > related set of environment variables.
> > 
> > /Sune

Best,

Christian

-- 


signature.asc
Description: This is a digitally signed message part.

Re: Issues Setting Up KDE Development Environment in Stretch

[Christian Hilberg]

Am Montag, 26. Februar 2018, 09:26:53 CET schrieb Christian Hilberg:
>  [...]
> So what I'm doing is setting up a "chroot" env for the more peculiar
> targets, into which I do mount /proc, /sys, /dev and /dev/pts filesystems
> as well as the source directory from my host (bind-mount does the trick, no
> NFS needed).
> [...]

NB.: This even works with foreign architectures, as long as QEMU supports 
them. For the Raspi, I set up a Raspbian-Lite chroot, copy 
/usr/bin/qemu-arm-static into it, and am good to go for cross-development on 
my host.

(Bye)^2,

Christian

-- 


signature.asc
Description: This is a digitally signed message part.

Re: Issues Setting Up KDE Development Environment in Stretch

[Christian Hilberg]

Hi,

Am Sonntag, 25. Februar 2018, 22:44:26 CET schrieb Karsten Ladner:
> Hello everyone,
> 
> I am trying to set up a development environment for KDE running Stretch. I
> have been attempting to use the kdesrc-build tool to build okular but each
> time I run it cmake fails to build the package. When I looked into the
> cmake log file, I found that cmake fails because okular is requesting a qt
> config file for a qt version of at least 5.8.0 but my system has only
> 5.7.1. I looked some more into it and found that an updated version is
> found in the qtbase5-dev package from the testing repository.
> 
> Here is my question: How can I set up my system to develop KDE software
> without messing up my installation of Debian?
> 
> Thanks in advance

I've found myself in the same situation oftentimes. Not only different 
versions of KDE, but also different distributions for different targets, all 
with their own (and sometimes peculiar) libs.

I also do not like to mess up my host's installation.

So what I'm doing is setting up a "chroot" env for the more peculiar targets, 
into which I do mount /proc, /sys, /dev and /dev/pts filesystems as well as 
the source directory from my host (bind-mount does the trick, no NFS needed).

That way, I can edit stuff from my host, and for building, I chroot into the 
chroot-env and take it from there.

To me, this is a flexible approach, and it is typically faster than using a 
virtual machine with all of the overhead that comes with it (though it is even 
possible to mount the chroot with the build results into a VM for further 
testing, but most often, the chroot itself suffices).

Moreover, when upgrading my host machine, I can keep the chroot environments, 
thus keeping the build environment as it was before.


Just 2 cents,

Christian

-- 


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Christian Hilberg]

Am Dienstag, 19. Juli 2016, 15:56:41 CEST schrieb Christian Hilberg:
> Am Dienstag 19 Juli 2016, 11:14:30 schrieb Christian Hilberg:
> > Am Dienstag 19 Juli 2016, 11:01:21 schrieb Christian Hilberg:
> > > [...]
> > > While syncing the IMAP folders, the process got stuck at 100% at one
> > > folder[...] Trying to resolve this now...
> [...]

Well, allowed a second CPU core into my VM and the issue is gone...
That smells like timing/timeout issue. The missing feedback to the
user via the UI is already reported upstream, iirc.

Best,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
Geschäftsführer: Nils Faerber, Ole Reinhardt
HR Siegen, HR B 9613

Re: KDEPIM ready to be more broadly tested

[Christian Hilberg]

Am Dienstag 19 Juli 2016, 11:14:30 schrieb Christian Hilberg:
> Am Dienstag 19 Juli 2016, 11:01:21 schrieb Christian Hilberg:
> > [...]
> > While syncing the IMAP folders, the process got stuck at 100% at one 
> > folder[...]
> > Trying to resolve this now...
> 
> Funny, oftentimes, Akonadiconsole shows a several thousand percent
> of "completeness" for the IMAP resource when trying to "Synchronize all",
> before the connection to the Akonadi server fails. This happens for
> seemingly random folders, now this one, then that one.
> 
> The Akonadi debugger information view shows a message which translates
> to "Connection to the akonadi service cannot be established".
> 
> Many of the folders are biggish, some thousand messages. Maybe a timeout
> of some sort?

Reduced the guilty folder's size, still:

...
log_imapresource: Detected inconsistency in local cache, we're missing some 
messages. Server:  547  Local:  500
log_imapresource: Refetching complete mailbox.
QDBusObjectPath Akonadi::Server::NotificationManager::subscribe(const QString&, 
bool) Akonadi::Server::NotificationManager(0x1e64810) "kontact_6660_EbGSKI" 
false
Database "akonadi" opened using driver "QMYSQL"
New notification bus: "/subscriber/kontact_6660_EbGSKI"
akonadicore_log: Invalid command, the world is going to end!
QIODevice::read (QLocalSocket): device not open
akonadicore_log: "Cannot connect to the Akonadi service."
Shutting down "akonadi_imap_resource_0" ...
Database "akonadi" opened using driver "QMYSQL"
Invalid command: no such handler for Transaction
akonadicore_log: Socket error occurred: "QLocalSocket: Remote closed"
akonadicore_log: Error during ItemSync:  "Cannot connect to the Akonadi 
service."
Shutting down "0x2126a20" ...
...

The IMAP resource seems to crash need to restart Akonadi, otherwise
nothing will work with this resource after the logged fail.

Looks like [0], though it is claimed to have been fixed in 16.04.3 ...

Best,

Christian

[0] https://bugs.kde.org/show_bug.cgi?id=364045

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
Geschäftsführer: Nils Faerber, Ole Reinhardt
HR Siegen, HR B 9613

Re: KDEPIM ready to be more broadly tested

[Christian Hilberg]

Am Dienstag 19 Juli 2016, 11:01:21 schrieb Christian Hilberg:
> [...]
> While syncing the IMAP folders, the process got stuck at 100% at one 
> folder[...]
> Trying to resolve this now...

Funny, oftentimes, Akonadiconsole shows a several thousand percent
of "completeness" for the IMAP resource when trying to "Synchronize all",
before the connection to the Akonadi server fails. This happens for
seemingly random folders, now this one, then that one.

The Akonadi debugger information view shows a message which translates
to "Connection to the akonadi service cannot be established".

Many of the folders are biggish, some thousand messages. Maybe a timeout
of some sort?

Regards,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
Geschäftsführer: Nils Faerber, Ole Reinhardt
HR Siegen, HR B 9613

Re: KDEPIM ready to be more broadly tested

[Christian Hilberg]

Am Montag 18 Juli 2016, 09:00:45 schrieb Lisandro Damián Nicanor Pérez Meyer:
> On domingo, 17 de julio de 2016 8:18:35 P. M. ART Lisandro Damián Nicanor 
> Pérez Meyer wrote:
> > As was posted [a couple of weeks ago], the latest version of KDE
> 
> This is of course KDEPIM :)

Of *course*. :-)

Updated my Sid box today, got KDEPIM and libs 16.04.3. Wanted to check whether
my favourite issue [0] had been fixed. =)

Created a fresh user on the box, logged in for the first time into Plasma5,
and started Kontact.

MySQL refused to start up properly (while tests 1..4 passed):

---8<---
Test 5:  ERROR


MySQL server log contains errors.
Details: The MySQL server error log file '/home/chris/.local/share/akonadi/db_data/mysql.err'
 contains errors.

File content of '/home/chris/.local/share/akonadi/db_data/mysql.err':
160719  9:09:39 [Note] Plugin 'FEDERATED' is disabled.
160719  9:09:39 InnoDB: The InnoDB memory heap is disabled
160719  9:09:39 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160719  9:09:39 InnoDB: Compressed tables use zlib 1.2.8
160719  9:09:39 InnoDB: Using Linux native AIO
160719  9:09:39 InnoDB: Initializing buffer pool, size = 80.0M
160719  9:09:39 InnoDB: Completed initialization of buffer pool
160719  9:09:39 InnoDB: highest supported file format is Barracuda.
160719  9:09:39  InnoDB: Waiting for the background threads to start
160719  9:09:40 InnoDB: 5.5.46 started; log sequence number 1622641
160719  9:09:40 [Warning] Can't open and lock time zone table: Table 
'mysql.time_zone_leap_second' doesn't exist trying to live without them
160719  9:09:40 [ERROR] Can't open and lock privilege tables: Table 
'mysql.servers' doesn't exist
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_current' has the wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_history' has the wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_history_long' has the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'setup_consumers' has 
the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'setup_instruments' 
has the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'setup_timers' has 
the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'performance_timers' 
has the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'threads' has the 
wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_summary_by_thread_by_event_name' has the 
wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_summary_by_instance' has the wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_summary_global_by_event_name' has the wrong 
structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'file_summary_by_event_name' has the wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'file_summary_by_instance' has the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'mutex_instances' has 
the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'rwlock_instances' 
has the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'cond_instances' has 
the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'file_instances' has 
the wrong structure
160719  9:09:40 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.46-0+deb8u1'  socket: '/tmp/akonadi-chris.raoZs2/mysql.socket'  
port: 0  (Debian)
160719  9:09:40 [Note] /usr/sbin/mysqld: Normal shutdown

160719  9:09:40  InnoDB: Starting shutdown...
160719  9:09:42  InnoDB: Shutdown completed; log sequence number 1622651
160719  9:09:42 [Note] /usr/sbin/mysqld: Shutdown complete
---8<---

>From what I found in the reports, this looks like [1].

I have checked that

* there is enough free disk space (~7GB free)
* the Akonadi directory structure under ~/.local/share/akonadi has the right 
permissions
  (this is not a migrated DB, but freshly created, as noted above)

So I thought this might be a wrong default setting with the table types, as 
Akonadi requires
InnoDB, as noted in [1]. But then, the log above shows that InnoDB is used.

As I am running the tests inside a virtual box, I assumed I might have had too 
little memory
reserved. Cleared the users' home, increased virtual machine mem from 4GB to 
8GB and started
over.

Alas, same thing happened. A migration might eat up truckloads of mem, but a 
fresh install
with no IMAP account yet -- just the MySQL DB -- I think 8GB of mem should 
suffice.

After quitting the email account wizard and Kontact alltogether, and starting 
Kontact anew,
no error dialog was shown. However, 'akonadictl status' keeps telling that the 
service is
down.

Trying the hint provided in [2] (deleting the db_data 

SDDM and sysvinit-core

[Christian Hilberg]

Hi all,

as can be seen in [0] and in [1], currently (at least in testing)
the combination of SDDM with sysvinit-core does not work properly.
Reboot and shutdown are not working in this combination.

The question which arises for me is: Is this combination even *supposed*
to work?

Being sort of an old fart, I would prefer sysvinit over systemd.
However, if the combination of SDDM and sysvinit is not something
the Debian KDE team considers as "ought to be working", then I
might as well kiss sysvinit good-bye, at least on my desktops.

So I'd like to know what the Debian KDE team's view on the
matter is. aTdHvAaNnKcSe for sharing your insights (or pointers
to them). :)

Regards,

Christian


[0] https://lists.debian.org/debian-kde/2015/08/msg00166.html
[1] https://lists.debian.org/debian-kde/2015/11/msg6.html

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Re: Cannot shutown from plasma or sddm

[Christian Hilberg]

Hi Marc,

Am Dienstag 03 November 2015, 09:13:12 schrieb Marc Bres Gil:
> Hello
> 
> since some update made by half september, I cannot shutdown my computer
> from the kmenu on plasma. When I choose the shutdown option, only logs off
> and shows me the sddm.
> When I try to shutdown from sddm it starts the countdown, but when reaches
> zero, continues counting with negative numbers.
> The /var/log/syslog shows the following:
> 
> Nov  3 09:02:01 fangorn dbus[2715]: [system] Activating service
> name='org.freedesktop.systemd1' (using servicehelper)
> Nov  3 09:02:01 fangorn kernel: [ 3618.266611] kactivitymanage[4103]:
> segfault at 7f8919e4acd0 ip 7f8919df4291 sp 7ffccd097278 error 4 in
> libQt5Sql.so.5.5.1[7f8919de+3f000]
> Nov  3 09:02:01 fangorn dbus[2715]: [system] Successfully activated service
> 'org.freedesktop.systemd1'
> Nov  3 09:02:01 fangorn acpid: client 2916[0:0] has disconnected
> Nov  3 09:02:01 fangorn acpid: client connected from 7791[0:0]
> Nov  3 09:02:01 fangorn acpid: 1 client rule loaded
> Nov  3 09:02:21 fangorn dbus[2715]: [system] Activating service
> name='org.freedesktop.systemd1' (using servicehelper)
> Nov  3 09:02:21 fangorn dbus[2715]: [system] Successfully activated service
> 'org.freedesktop.systemd1'
> 
> Previously to the last update, the segfault was given at
> libQt5Sql.so.5.4.2, i thought that with next update of this library it will
> be solved, but it is still giving the error.
> 
> Anybody else is having this problem?

I'm experiencing this since end of August, see [0]. Back then, only
SDDM would not reboot or shutdown, while both was possible from within
Plasma.

With the latest updates in stretch, though, shutting down the system
from within Plasma also does not work for me. Plasma throws me back to
SDDM, but no shutdown/reboot.

May I ask, which init system do you use? For me, it is sysvinit (but
with systemd-logind installed), maybe this is creating an issue here.


Regards,

Christian


[0] https://lists.debian.org/debian-kde/2015/08/msg00166.html

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Re: Cannot shutown from plasma or sddm

[Christian Hilberg]

Hi Marc,

Am Dienstag 03 November 2015, 12:05:04 schrieb Marc Bres Gil:
> Hello Christian,
> 
> I'm using sysvinit, I installed the system when jessie was the "testing"
> version, and now i'm on stretch.
> I thought it will have changed to systemd when the upgrade was done, but
> checking it now i've found it is sysvinit the system in use.

For fresh installs, systemd will be the default. When upgrading, I don't
think the installer will automatically change the previously-used init.
At least, the installer can be prevented from attempting this.

I've also updated from a sysvinit Jessie to Stretch, keeping sysvinit as
init-System. I've casually searched the web for hints, but so far, no luck.
Some posts point into the PAM direction, i.e. systemd-logind not doing the
entire PAM dance. But so far, that's guessing only.

> How can I check if systemd-logind is in use? I see that the systemd package
> is installed.

AFAIK, sddm relies in systemd-logind, i.e., when sddm is being used, so
is systemd-logind. At least, that is the default.

Regards,

Christian

> Thanks
> Marc Bres
> [...]

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Re: plasma desktop broken again :(

[Christian Hilberg]

Hi Carlos,

Am Freitag 30 Oktober 2015, 11:09:30 schrieb Carlos Kosloff:
> Thanks for answer, but I am in testing, anybody tried that, or should I 
> be the first to take the plunge?

I've just updated testing. My SDDM starts up properly again,
and I can log in / out / back in / out again into/from Plasma5.

This was on a VM, so not fully in real life.

> 
> On 10/30/2015 10:59 AM, Tim Ruehsen wrote:
> > On Friday 30 October 2015 10:28:45 Carlos Kosloff wrote:
> >> Apart from that, OK to run a full dist-upgrade now, unholding
> >> libqt5x11extras5?
> > I did it a few hours ago (on unstable), works smoothly so far.
> >
> > Tim

HTH,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Re: Plasma desktop unusable in stretch

[Christian Hilberg]

Am Donnerstag 03 September 2015, 16:37:09 schrieb Andrey Rahmatullin:
> On Thu, Sep 03, 2015 at 12:43:37PM +0200, Christian Hilberg wrote:
> > "It's all automatic" is the bit I missed. I was under the impression
> > that this would be true for experimental->unstable only
> experimental->unstable is fully manual (even requiring a new upload).
Thanks for clarifying.


signature.asc
Description: This is a digitally signed message part.

Re: Plasma desktop unusable in stretch

[Christian Hilberg]

Hi Brad,

thanks for clarifying matters. A few more bits inline.

Am Donnerstag 03 September 2015, 14:19:53 schrieb Brad Rogers:
> On Thu, 03 Sep 2015 12:43:37 +0200
> Christian Hilberg <hilb...@kernelconcepts.de> wrote:
> 
> Hello Christian,
> 
> >> You appear to expect somebody (well, several 
> >> somebodies) to stem the tide to avoid problems.  
> >"Expecting" is not what I meant to express, it is more like "being
> I wasn't sure, hence my writing "appear to..."  Having cleared up a
> misunderstanding about the unstable->testing migration, I can tell
> you're a lot less angry (I use the word cautiously; it may be too strong)
> about what's going on ATM.

No anger at all. Please excuse if my writings implied this.

What you call a misunderstanding about the package migration
between unstable and testing I think is better described by
the term "misconception on my side", something many may share
with me. So thanks again for taking time to explain.

> >Sure. Since there are the brave ones running unstable, I thought this
> >is where the biggest breakages were going to be caught and eliminated
> >before the packages entered testing.
> By and large, the biggest breakages _do_ occur in unstable.  The current
> situation is, in the time I've used testing (approx ten years),
> unprecedented.  I've seen the odd package or two migrate that couldn't
> be installed, but never on such a huge scale.

That's true. I'm a debian addict myself for more than 10 years
now, and haven't seen like this either. Although, I must admit,
I have not followed testing that much close.

> [...] 
> Much of the problem, AIUI, is caused by the change to GCC5 for
> Kf5/Plasma.  Just look at the number of packages held back from testing
> because of it;
> 
> Updating gcc-5 makes 408 depending packages uninstallable on amd64: 
>
> Note that that list refers to amd64 only.  It may differ on other
> architectures.  And that's just the _depending_ packages.  There's
> another 318 non-depending packages that are affected.

It might be helpful to have some mechanism handy which would allow
the release managers to easily hold off e.g. all of KDE from migrating
from unstable into testing while something like the GCC transition
is going on, and having testing just sit on the latest pre-GCCv5 version.
Once the transition is done, this "hold" flag would be removed and
the unstable packages (for KDE here) would start trickling into testing
again. But then, for something like this to work, the package dependencies
would need to already be correct... just thinking out loud, never mind. :-)

> https://release.debian.org/migration/testing.pl?package=gcc-5 has the
> full list.  It includes stuff like LibreOffice and all sort of Python
> stuff, not just KDE.

Thanks for the pointers.

> It's going to take a long time to sort it out, I'm sure.

I might bug you with some new bug reports in the meantime. :)

Kind regards,
Christian


signature.asc
Description: This is a digitally signed message part.

Re: Plasma desktop unusable in stretch

[Christian Hilberg]

Am Donnerstag 03 September 2015, 18:12:04 schrieb Martin Steigerwald:
> Am Mittwoch, 2. September 2015, 22:46:12 schrieb Matthias Bodenbinder:
> > Am 02.09.2015 um 19:50 schrieb Gary Dale:
> > [...]
> > > the brave souls who run sid do what they, not I, signed up for.
> > I 100% support that statement. On the debian wiki
> > (https://wiki.debian.org/DebianTesting) it says:
> > 
> > Packages from Debian Unstable enter the next-stable testing distribution
> > automatically, when a list of requirements is fulfilled: [...] The package
> > does not introduce new release critical bugs.
> 
> So and now *who* reports these?

If the packages should be allowed into testing only if not
introducing new RC bugs, then the bugs must be reported
(i.e., opened) by the users of unstable, if they should
prevent the package from trickling into testing.

Then again, since the packages actually /went/ into testing,
this means that there were no new RC bugs opened by the
users of unstable -- maybe the packages were working there
and only in conjunction with the package situation in testing
the issues show.

That seems to be a pretty funny puzzle to solve.

> Then rethink from there.

Trying to. =)

Regards,
Christian

signature.asc
Description: This is a digitally signed message part.

Re: Plasma desktop unusable in stretch

[Christian Hilberg]

Hi Brad,

Am Mittwoch 02 September 2015, 16:16:10 schrieb Brad Rogers:
> On Wed, 02 Sep 2015 10:21:47 -0400
> Gary Dale  wrote:
> 
> Hello Gary,
> 
> >Yesterday I rebooted my computer but when it came back up and I logged 
> >in, Plasma was no longer usable.
> 
> Come on Gary, you've been on this ML long enough to know that KDE is
> going through some *massive* changes ATM.  The path from KDE4 to
> KF5/Plasma is far from an easy one to tread.  Not least because of the
> change to GCC v5.  KF5/Plasma is very, /very/ different from KDE4.  It's
> not a huge surprise, to me at any rate, that some packages don't (yet)
> have their dependencies sorted out fully.
> 
> If one finds, when doing an update, it's necessary to remove large
> numbers of packages to get everything updated then one should pause and
> consider;  Do I really want to lose half of my software suite?  Usually
> the answer is "no".  In that case, see what can be updated without
> ripping the heart out of your system.
> 
> Testing sometimes has breakage.  Sometimes that breakage is big.  You
> just have to deal with it.  If you can't
> 
> there's always stable.

To me, that kind of breakage (due to the transitions KDE4->KF5 *and*
GCC4->GCC5 at the same time) is what we're used to see in unstable.
This is what unstable is for, imho.

By letting these transitions happen simultaneously in unstable as well
as testing, the ML became flooded with all-the-same-topic mails over
and over, because many people are using testing who do so because they
like to be more recent than stable while not daring enough to expedition
into unstable land.

I guess it might have been wiser to let the transitions happen in
unstable, since the massive breakage you mention was to be expected,
and have the smaller issues and oversights ironed out in testing.
This scheme worked out quite well in the past.

Kind regards,
Christian


signature.asc
Description: This is a digitally signed message part.

Re: Plasma desktop unusable in stretch

[Christian Hilberg]

Hi Brad,

Am Donnerstag 03 September 2015, 09:40:35 schrieb Brad Rogers:
> On Thu, 03 Sep 2015 10:12:52 +0200
> Christian Hilberg <hilb...@kernelconcepts.de> wrote:
> 
> Hello Christian,
> 
> >I guess it might have been wiser to let the transitions happen in
> >unstable, since the massive breakage you mention was to be expected,
> >and have the smaller issues and oversights ironed out in testing.
> >This scheme worked out quite well in the past.
> 
> Testing acquires packages from unstable when certain criteria are met.
> It's all automatic, except for when a freeze occurs. That is to say,
> nobody oversees it.  

"It's all automatic" is the bit I missed. I was under the impression
that this would be true for experimental->unstable only and that the
packages in testing would then be marked as "ready for testing" manually,
once the breakage reports cease.

> You appear to expect somebody (well, several 
> somebodies) to stem the tide to avoid problems.

"Expecting" is not what I meant to express, it is more like "being
under the [wrong, I know by now] impression that somebody does",
given the actually relatively low frequency of breakages in testing.

> Question is;  How do they know what's going to cause problems?  Answer;  They 
> don't/can't
> until the problem(s) actually arise.  By then it's too late to avoid
> them.

Sure. Since there are the brave ones running unstable, I thought this
is where the biggest breakages were going to be caught and eliminated
before the packages entered testing.

> What you'd like to happen is never going to happen.  So it comes down to
> three choices;
> 
> 1) deal with it yourself
> 2) use stable
> 3) use another distro
> 
> With snapshot.debian.org 1 is easy to do, 2 may require an install and
> 3 _will_ require an install.
> 
> 1 is probably the easiest.

3) is not at all an option, sorry. ;-))

What I'm doing is using stable on my production machines and running
testing in a VM to follow up on what's going on and report issues as
I find them. It is not too much I can do there, but I try to add my
2 cent.

What had me puzzled a little was that I did not experience the KDE
packaged in testing being in the state it lately has been -- so that
is what may have misled my "expectations".

Kind regards,
Christian


signature.asc
Description: This is a digitally signed message part.

stretch SDDM shutdown/restart issue

[Christian Hilberg]

Hi all,

I'm running stretch, updated from jessie, with sysvinit,
and just the unavoidable systemd bits. System has been
updated today. It runs inside a VirtualBox 5.0.2 on a
jessie host, just in case that should make a difference.

SDDM shows restart/shutdown buttons, but when clicked,
just the timer animation starts (and eventually counts
to negative numbers), without shutdown or restart being
carried out. This has been the case ever since I initially
dist-upgraded from jessie to stretch.

When logging in into KDE Plasma 5, both shutdown and restart
do work.

Also, if using LightDM with the KDE greeter, shutdown and
restart do work.

I've searched for existing bug reports but did not find
a good match. The report in [0] is somewhat close,
but refers to the respective buttons in KickOff, which
actually work for me (suspend not yet checked).

Maybe I am missing something here. How would I best
proceed to iron out the cause of the issue? Has anyone
else experienced this?

Hints and pointers appreciated.

Kind regards,

Christian


[0] https://github.com/sddm/sddm/issues/379

signature.asc
Description: This is a digitally signed message part.

Bug#792875: fixed in plasma-workspace 4:5.3.2-4

[Christian Hilberg]

On Thu, 20 Aug 2015 15:12:36 +0200 Christian Hilberg 
hilb...@kernelconcepts.de wrote:
 Hi,
 
 I'm seeing the same (or, at least, very similar) crash
 with plasma-workspace 5.3.2-4 as of stretch, dist-upgraded
 today from jessie. See attached GDB trace. Let me know whether
 you're missing debug symbols for one or the other package, I'll be
 happy to install the respective symbols and re-create the
 trace.
 [...]

Looks like a packaging issue. The dist-upgrade from jessie to stretch
did not install plasma-desktop for me.

Installing plasma-desktop and its dependencies fixed the issue for me.

Regards,
Christian


signature.asc
Description: This is a digitally signed message part.

Re: Plasma does not load after login

[Christian Hilberg]

Am Freitag 21 August 2015, 10:35:01 schrieb Richard Barmann:
 Is there a way to go back to 14.xx version? I cannot run 15,04 as plasma 
 stops.
 Dick Barmann

Quoting a reply to a previous posting also regarding plasma
not starting up:

Check the debian-kde ML archives (https://lists.debian.org/debian-kde/), there 
are various posts related to these problems.

...many of which are in August 2015, as I may add.

Regards,
Christian


signature.asc
Description: This is a digitally signed message part.

Re: Plasma 5 doesn't start after update on Stretch

[Christian Hilberg]

Am Mittwoch 19 August 2015, 15:41:35 schrieb Diederik de Haas:
 On Wednesday 19 August 2015 15:16:45 Francesco De Vita wrote:
  Is there someone else who experienced the same issue?
 
 Looks like it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796098

Might as well be this one:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792875

OP has plasma-workspace 5.3.2-2, supposedly fixed
in 5.3.2-4, but still hits me with the latter.

Neither by creating a fresh user nor by downgrading to snapshot
20150817T213310Z (as proposed elsewhere in this thread) have I
been able to get around this crash, which, for me, happens
inside libxcb.

Regards,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Re: Please test akonadi-server 1.13.0-3

[Christian Hilberg]

Am Donnerstag 02 Juli 2015, 12:49:05 schrieb Christian Hilberg:
 Hi there,
 
 currently testing akonadi-server 1.13.0-3 (with the mysql backend,
 that's the only one I use) from Debian/Sid on Debian/Jessie.
 
 My Jessie installation is somewhat tainted ;-) in that I pulled
 KDEPIM 4.14.2-2 from unstable before, in the hopes of getting
 a few issues fixed.
 
 Startup and a few actions on IMAP folders so far look good,
 for akonadi as well as KMail.

Having tested akonadi-server 1.13.0-3 for a few days now in a simple,
IMAP-only setup, I have not experienced any issues. No more duplicates
were created in ~/.local/share/akonadi/file_db_data, 'akonadictl fsck'
has no more work to do.

Looking fine for me.

Kind regards,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Re: Please test akonadi-server 1.13.0-3

[Christian Hilberg]

Hi there,

currently testing akonadi-server 1.13.0-3 (with the mysql backend,
that's the only one I use) from Debian/Sid on Debian/Jessie.

My Jessie installation is somewhat tainted ;-) in that I pulled
KDEPIM 4.14.2-2 from unstable before, in the hopes of getting
a few issues fixed.

Startup and a few actions on IMAP folders so far look good,
for akonadi as well as KMail.

Am Mittwoch 01 Juli 2015, 21:06:08 schrieb Martin Steigerwald:
 Hello!
 
 It contains a fix for bug that Akonadi leaks files in the file_db_data 
 filesystem cache[1]. So if you have the issue that you get more and more and 
 more files over time or even duplicates in there, please update akonadi-
 server.

 I recommend the following procedure:
 
 1) Upgrade to akonadi-server 1.13.0-3 from unstable.
 [...]
 2) akonadictl fsck
 3) Move ~/.local/share/akonadi/file_db-lost+found out of the way. According 
 to upstream developers you can safely rm the files in it.
 4) Use Akonadi, i.e. KMail and other PIM apps.

My procedure was slightly different. While on akonadi-server 1.13.0-2, I
followed the procedure outlined in [1]. This means, by the time I've installed
1.13.0-3, 'akonadictl fsck' had already been run and the file_db-lost+found/
directory cleared.

Another run of 'akonadictl fsck' does not seem to find anything new, albeit
a number of fdupes left in file_db_data (which seems to be normal).

 5) Check periodically whether you still get any duplicates or still get files 
 endlessly piling up in file_db_data

Will do and report back if I find something unusual.

By the way, removing duplicate email messages via the corresponding
KMail menu entry, which was a NOP for me previously, seems to be working
again after following the instructions in [1]. There's a bug report
for that, which I'm going to update accordingly.

 If testing goes well, this might be a candidate fix for Debian stable.

Let's hope for the best. =)

 [1] [Akonadi] [Bug 341884] dozens of duplicate mails in 
 ~/.local/share/akonadi/file_db_data
 https://bugs.kde.org/show_bug.cgi?id=341884
 
 Thank you,

Kind regards,

Christian
-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Re: Please test akonadi-server 1.13.0-3

[Christian Hilberg]

Am Donnerstag 02 Juli 2015, 12:49:05 schrieb Christian Hilberg:
 [...]
 By the way, removing duplicate email messages via the corresponding
 KMail menu entry, which was a NOP for me previously, seems to be working
 again after following the instructions in [1]. There's a bug report
 for that, which I'm going to update accordingly.
 [...]

[x] done, https://bugs.kde.org/show_bug.cgi?id=340759

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Re: kdepim to connect mobile core prime galaxi

[Christian Hilberg]

Hi,

Am Sonntag 14 Juni 2015, 00:27:32 schrieb BasaBuru:
 Hello
 There are some program that lets you connect to samsung galaxi
 prime core with kdepim. I have the contacts and the calendar
 in the phone and in kdepim

Sounds like a scenario best handled by some groupware solution.

If you want to host the groupware yourself (i.e., if you do not 
want to handover your PIM data to any of the well-known 
commercial data monsters as a free giveaway to mess with), you 
might want to try something like the Kolab groupware [0]. Once 
installed, which can be a little bit of a bumpy ride, it works 
quite well for me.

Other groupwares like eGroupware, Zimbra, Owncloud and the likes 
may work equally well. Just I don't know how good their 
integration with KDEPIM is.

HTH,
Christian

[0] http://kolab.org/

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Re: Newer KDEPIM for Jessie

[Christian Hilberg]

Hi Sandro,

Am Mittwoch 13 Mai 2015, 16:58:48 schrieb Sandro Knauß:
 Hi,
 
   (No kidding: the Kolab people do package their own
   enterprise
   version of KDE, and they *do* ship KDEPIM 3.5.10 with
   it...).
 
 well as one of the kdepim/kolab devs i can say: you are wrong!
 
 There is a enterprise version of kontact (4.13.0.X) [0]. As you
 can see from the version number this is based on 4.13.0. Well
 actually the feauteres+bugfixes will go directly into the
 upcomming kf5 version. But for sure we don't ship kdepim 3.X
 anymore.

Hum, since I was out for deb packages for Jessie, some digging 
turned up [1], which I parsed as Enterprise 3.5.10 (a.k.a E35), 
recently built for Jessie. I guess this then means is 
available, as opposed to gets shipped as enterprise version, 
right? At least, my searches did not turn up any deb packages for 
4.14.7, other than that rogue PPA I found.

 There are also packages built:
 https://obs.kolabsys.com/project/show/Kontact:4.13:Development

Okay, there's the sources and the DSC files etc... I guess my 
search was too specific. And to be honest, really, I had no idea 
searching for 4.13. :)

 but because we release 4.13.0.X version, you have to make a
 downgrade, what is a little bit tricky.

I guess so. :-) Searching for success stories, most of the 
related postings mention KDE 4.14 and Akonadi 1.13 (which is also 
true for the OP's initial writings in [2]). So I think I would 
not have gone for Akonadi 1.12.42.1, which is what I can find on 
OBS (following your link), if you had not mentioned it.

Considering the numerous bits  bytes I've gathered about the 
issue, I think I need to meditate and see how to proceed from 
here.

 regards,
 sandro

Kind regards,

Christian

 [0] https://git.kolab.org/diffusion/KP/kdepim.git branch
 kolab/integration/4.13.0 and you need also others packages:
 kdepimlibs, kdepim-runtime, akonadi.

[1] 
https://ftp.kolab.org/apt/releases/dists/jessie/experimental/binary-amd64/kdepim/

[2] https://lists.debian.org/debian-kde/2015/03/msg9.html

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Re: Re: Newer KDEPIM for Jessie

[Christian Hilberg]

Hi all,

seeking for a less-painful-than-self-compile way to get KDEPIM 
4.14.7 into Debian/Jessie (for much the same reasons as pointed 
out by the OP), I stumbled across

http://kdebian.org/ppa/

While this repo seems to have all of the packages I'm after, I do 
not really know to make heads or tails of it.

There site does not mention any maintainer. The owner of the 
domain hides behind some privacy service. There seems to be some 
connection to a live.ru account, but that does not necessarily 
mean anything.

Other than being referred to from some blog posts, I did not find 
any information as to whether or not this PPA can be trusted. I 
for one do *not* trust, because of missing information about 
who's behind that PPA, but maybe there is some info about this 
site I missed?

Anyway, the DSC files from that repo might be worth a look when 
trying to set up some trustworthy alternative to it, which would 
surely be of a great relief to Debian/Jessie KDEPIM users.

Kind regards,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Re: Newer KDEPIM for Jessie

[Christian Hilberg]

Hi Jimmy,

Am Dienstag 12 Mai 2015, 07:53:12 schrieb Jimmy Johnson:
 [...] 
 Christian this is what I get after running the upgrade:
 jimmy# upgrade-system
 1) Updating package lists:
 I: Package lists updated.
 2) Checking for upgradable packages:
 I: Installing upgradable packages...
 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 Calculating upgrade... The following packages were
 automatically installed and are no longer required:
 [...]
 plasma-scriptengine-ruby ruby-kde4 ruby-plasma ruby-qt4
ruby-qt4-webkit
 Use 'apt-get autoremove' to remove them.
 Done
 The following packages will be REMOVED:
libmarblewidget19* libnepomuk4* libnepomukquery4a*
 libnepomukutils4* The following NEW packages will be
 installed:
baloo-utils baloo4 libakonadi-socialutils4 libatasmart-bin
 [...]
 191 upgraded, 12 newly installed, 4 to remove and 0 not
 upgraded. Need to get 249 MB of archives.
 After this operation, 14.4 MB of additional disk space will be
 used. Do you want to continue? [Y/n]
 
 I was a little concerned with ruby being removed so I did not
 complete the upgrade.

Check the output of APT closely, it reveals what will actually 
happen:

There's The following packages will be REMOVED section, which 
lists packages which will indeed be removed if you choose to 
continue the upgrade.

Then, there's The following packages were automatically 
installed and are no longer required, which lists packages to 
which, after the upgrade, no dependencies could be found. Under 
this category, some Ruby packages are listed. They will not be 
automatically removed. APT tells you how to get rid of them, if 
you choose to. Moreover, it is not Ruby itself, but some KDE 
packages with ruby stuff. These are no longer needed after the 
upgrade, either since the newer KDE does not make use of Ruby any 
more, or since there's some optional support for some stuff in 
KDE which needs Ruby, but which the package creator did not 
switch on.

HTH,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.

Bug#750818: Upstream Report

[Christian Hilberg]

There's another upstream report for this at

https://bugs.kde.org/show_bug.cgi?id=283682

As far as Debian packaging goes, this bug affects
4.12.1 (Jessie) as well as 4.12.2 (Sid).

Regards,
Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.