Bug#1076569: When called for dh-sequence-kf6 (or --with=kf6) CMAKE Qt6 should be enforced

[Nicholas D Steeves]

Package: pkg-kde-tools
Version: 0.17.4
Severity: serious

I just started working towards updating one of my packages to Qt6 and
KF6 and I was shocked to find that dh-sequence-kf6 doesn't append
"-DQT_MAJOR_VERSION=6" to cmake configure arguments.

KF6 + "-DQT_MAJOR_VERSION=5" is nonsensical, so the Qt6 variant should
be enforced.

Best,
Nicholas

Bug#1054919: kaccounts-providers: google authentication hang after username entry

[Nicholas D Steeves]

Hi Dmitry!

Dmitry Shachnev  writes:

> Hi everyone!
>
> Sorry for the late reply, but let me try to answer the questions which remain
> unanswered.

Thank you for finding the time to reply and to explain the Qt side of
things :)

> On Sun, Oct 29, 2023 at 07:43:51PM +0100, Alexis Murzeau wrote:
[snip background]
>
>> Qt 6 doesn't seem to have Qt webkit anymore, but QtWebEngine instead.
>> I guess signon-ui should move to QtWebEngine instead but sadly upstream
>> seems rather dead :(, the previous signon-ui release was more than 5
>> years ago.
>
> Yes, Qt WebKit does not support Qt 6, so the only choice is to migrate to
> Qt WebEngine which is supported much better. I would recommend doing that
> even if you stay on Qt 5.

I've filed #1055855 for this purpose, with a link to a breadcrumb trail
from SUSE.

> Unlike Qt WebKit which is based on Apple WebKit, Qt WebEngine is based on
> Chromium codebase.
>
> Qt WebEngine user agents will look the following:
>
> Qt 5.15:
> Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) 
> QtWebEngine/5.15.15 Chrome/87.0.4280.144 Safari/537.36

So if we backport signon-ui's future Webkit -> WebEngine fix to
bookworm, Google might still blacklist bookworm kaccounts users for
having a user agent string that advertises an ancient browser?
Chrome/87.0.4280.144 is pretty old.  That said, I assume there are
security reasons why we should use WebEngine and not Webkit in bookworm?


Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1055855: We need to switch to a version that uses Qt WebEngine

[Nicholas D Steeves]

Source: signon-ui
Version: 0.17+16.04.20151125-1
Severity: important
Control: tag -1 trixie

Continuing from Dmitry Shachnev (mitya57)'s message at the kaccounts-providers 
bug that is affected by this one:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054919#51

We need to switch to a signon-ui release that uses Qt WebEngine rather
than the dead Qt WebKit, and we need to do this before trixie.
Honestly, the sooner the better...

When I was searching for a living upstream for signon-ui, I found that
SUSE appears to use a version that has already switched to WebEngine:
  https://packagehub.suse.com/packages/signon-ui/0_17+20171022-bp155_3_16/

I didn't investigate more than that, but it looks like there is
already a resolution.  It might just be a question of switch to a more
alive upstream, and/or replicating a SUSE patch series (I didn't check).

Also, it might be a good idea import the changes as patches (whether
from upstream, new upstream, and/or SUSE) so that we can backport them
more easily to bookworm, because Google is not totally unreasonable to
experimented with blacklisting a web browser user agent string that
dates to 2016!

Regards,
Nicholas

Bug#1054919: kaccounts-providers: google authentication hang after username entry

[Nicholas D Steeves]

Hi,

I received a report from sney (in #debian-qt-kde on OFTC) that a
workaround is no longer necessary in either kaccounts-providers or
signon-ui.

Thus it sounds like this was a case #1 problem
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054919#24)

1. Google refuses to talk to Qt webkit/QtWebEngine that identifies
itself accurately.

and it appears that they've reverted the action that broke everyone's
access to their Google accounts.  This is the most correct solution and
the best possible outcome.

Alexis and Peter, would you please confirm that the workaround is no
longer necessary?  And please leave the bug open even if Google accounts
are working again, because the frequency of this breakage has been
mounting.

To everyone reading this: If user spoofing doesn't solve the next
incidence of breakage then that would indicate a separate issue, and
please file a separate bug in this case!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1054919: kaccounts-providers: google authentication hang after username entry

[Nicholas D Steeves]

Hi Alexis, and anyone else reading this,

Alexis Murzeau  writes:

> I'm not sure how Qt webkit works, but I guess it behaves like a old
> chrome browser. I don't know if it uses a different user agent, but
> maybe Google doesn't recognize that it doesn't support newer web stuff.

Exactly, that's what I'm wondering.  In terms of cases, the
possibilities I can think of are these cases (what you write above would
be case #3):

1. Google refuses to talk to Qt webkit/QtWebEngine that identifies
itself accurately.
   * Arguably the most correct thing to do here is for webkit and
   WebEngine to continue to accurate identify themselves, and only
   masquerade when absolutely necessary.  Qt doesn't seem like the right
   place to maintain a huge list, so kaccounts-providers would override
   it with a sufficiently old enough Firefox version whose features it
   actually and functionally supports for the purposes of
   authenticating.  Totally reasonable and with historical precedent.
   The ideal solution of course is a more open Web where Google stuff
   will continue to talk to non-Google, non-Apple, and non-Mozilla
   stuff.
2. Or Qt webkit self-identifies as a version of Firefox that is newer
than what it can actually support.
   * In this case, there is a bug in Qt webkit that needs to be fixed.
3. Or Qt webkit masquerades as an old nonLTS version of Chrome,
Chromium, or Firefox that Google has dropped support for.
   * As you note below, webkit appears dead upstream (replaced by
   QtWebEngine), and it would be wrong for it to masquerade as a browser
   whose features it can't actually support in the general case. Ie,
   probability of triggering bugs...  I really hope this isn't where we
   find ourselves, but if this is where we are, then I guess we use
   kaccounts-providers to masquerade as a browser that webkit actually
   can't support...and we hope it doesn't break for a while.  I believe
   that if we implement case #1 it will eventually become this case
   (#3).  This workaround is definitely a "sweep the problem under the
   rug" type of hack.  Yes, if it's the only solution then I think we'll
   have to implement it.

> Qt 6 doesn't seem to have Qt webkit anymore, but QtWebEngine instead.
> I guess signon-ui should move to QtWebEngine instead but sadly upstream
> seems rather dead :(, the previous signon-ui release was more than 5
> years ago.

Yeah, signon-ui looks undermaintained/abandoned upstream...  I'm adding
the upstream maintainer to CC for notification about this nascent issue
(Qt webkit removal), because it looks like signon-ui will break horribly
at that time.  As an aside, reading the copyright file makes it look
like signon-ui may have originally been a Nokia project.

> That's in fact why I've opened a report on this package, it seemed to be
> the more feasible and realistic solution.

Once again, thank you, much appreciated!  And yes, I think that you have
the right idea, and reported this bug in the right package.  By the way,
did you copy this solution from somewhere else (like Fedora's COPR or
somewhere in Arch Linux), or is 

> It is a chance that google signon can still work :)
>

For sure!  It's just a question of considering correctness as well as
the long-term plan :)

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1054919: kaccounts-providers: google authentication hang after username entry

[Nicholas D Steeves]

Version: 4:22.12.3-1
Control: tag -1 upstream confirmed

Hi,

Thank you for reporting this bug.

Alexis Murzeau  writes:

> To fix this, I've put this line in /etc/signon-ui/webkit-
> options.d/accounts.google.com.conf:
> UserAgent = Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101
> Firefox/77.0

I've tested this proposal, and it fixes Google signon for me.  This will
transitively fix things like kio-gdrive that are broken in bookworm; For
users of Google things, Bookworm's KDE is a poor user experience, or
"bad story", compared to GNOME.

> The webpage issue is maybe caused by the use of Qt webkit, using an older
> UserAgent probably causes Google to offer an older login page that works with
> Qt webkit.

That sounds plausible to me.  If that's the case then it seems like it
may be better to patch Qt webkit.  I wonder if this is a case where
whatever UserAgent Qt webkit validated is the one the package declares
(where it shouldn't be overridden for the general case), or if everybody
involved just forgot to update it?

> As the UserAgent is required to make the login work, can it be added to the
> package ?

Agreed, either Qt webkit should be fixed, or else kaccount-providers
should begin overriding UserAgent.  It's nice to see a Google issue that
we can fix on our side!

Best,
Nicholas


signature.asc
Description: PGP signature

Re: KDE Keysmith

[Nicholas D Steeves]

Hello Sahib,

Reply follows inline:

Sahib  writes:

> Hi Maintainers,
>
>
> Can you please package Keysmith
>
> https://apps.kde.org/keysmith/
>
> https://invent.kde.org/utilities/keysmith
>
>
> Thanks
>
> Sheik

Are you able to file a request for packaging?
https://wiki.debian.org/RFP

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#1037268: kwin-x11: resource leak: the number of threads increases over time, boundlessly

[Nicholas D Steeves]

Control: tag -1 confirmed

Julien Muchembled  writes:

> After 17 days, the number of threads of /usr/bin/kwin_x11 process has
> exceeded 2700 and it keeps increasing. At the beginning
> of a session, the process starts with 34 threads.

Interesting!  Mine starts with only 11 threads.  I wonder if this is
hardware dependent?

> I could find that such leak happens when viewing videos fullscreen e.g. with 
> mpv. Can anyone reproduce it ? More precisely:
> 1. start mpv without --fs -> thread count does not change
> 2. switch to fullscreen -> usually -2 threads
> 3. leaves fullscreen -> usually +17 threads
> 4. exit mpv -> thread count does not change

I was able to reproduce (with mpv 0.35.1-4), but going fullscreen didn't
increase the kwin thread count on my system; however, exiting fullscreen
consistently increased kwin's thread count by exactly two threads each
time mpv leaves fullscreen.  I would say "I'm horrified too!" but
couldn't this be a new feature that is designed to limit media
consumption? ;)

> Such a leak is at least a severe issue for anyone like me who set a nproc 
> limit to protect against fork-bombs, in particular because it causes 
> mysterious process crashes. I only understood the problem when I wanted to 
> build a software that spawned a lot of processes. It also makes nproc 
> limiting quite unusable without restarting KDE from time to time.

The good news is that one doesn't need to restart KDE.  Try this:

  kwin --replace&

> Version 4:5.27.2-2 was affected too. I previously had 4:5.24.4-1 and I'm 
> almost sure it had no leak.

That's not a terrible range to bisect, if it comes to that.

> A few notes that may be specific to my setup:
> - I do have a 4k intel display. And regularly, for less than 1s, the
> display is corrupted. I haven't tried Wayland yet and I hope it will
> fix it.

Oh, maybe this is why yours has more threads than mine?  Maybe it's
resolution dependent?  (I'm not familiar with kwin's source)

> - I use mpv from deb-multimedia.

For reference, please note that bugs must be reproducible with Debian
alone, otherwise they may be marked invalid.

> - mpv conf: vo = gpu

Here is the config I confirmed with:

  hwdec=vaapi
  vo=gpu
  profile=gpu-hq

> I couldn't find anything on bug.kde.org: should I forward ?

Yes please :)

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1034796: kio-gdrive: Does not work. Network account create does not propose gogle drive

[Nicholas D Steeves]

Eric Valette  writes:

> On 30/04/2023 00:48, Nicholas D Steeves wrote:
>> 
>> Justification: Package is not unusable for everyone.  See the following
>> for further info: https://www.debian.org/Bugs/Developer#severities
>
> It is hard to know if it is broken for you or for many others. As I saw 
> exactly the same reports on other distrib I assume this is a general 
> problem.

It may be that Google disconnected a bunch of people again...  This
happened to me sometime in the last three weeks, for no reason, and only
on my laptop.  Reauthenticating solved it.

>>> Using dolphin for network, you can select gdrive but it does not propose to 
>>> add
>>> a google account.
>>>
>> 
>> That's odd, mine shows a "New account" button.
>
>
> I tested on another computer with exactly the same setup unstable + 
> experimental, nearly same package set (well execpt I use a generic 
> debian kernel on this one). And there it kinda works:
>
> 1)I cannot access an old account,
> 2) but I can create a new one
> 3) and relaucching kdeinit5 I can even access the content,
>
> So this is probably incompatible left over in the .config or similar. I 
> will try to search for gdrive or kio there.
>

Yes, that could be!

>> Are you able to reproduce this bug with a pure testing/bookworm or
>> sid/unstable system?  If so, please provide steps to reproduce, and
>> remove the moreinfo tag from this bug at that time.
>
> Well the package are now in testing I guess due to the hard freeze.

Yes, and my experience is that they work fine without the addition of
experimental packages.

> Thnaks for replying. More later when I can put my hands back on the 
> problematic config.

You're welcome!  I appreciate your efforts, and if there is a bug that
affects bookworm/testing, then we need to figure out how to reproduce
it, so we can fix up asap :)  Of course it would also be nice to fix
experimental and unstable, but bookworm has top priority.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1034796: kio-gdrive: Does not work. Network account create does not propose gogle drive

[Nicholas D Steeves]

Control: severity -1 important
Control: tag -1 moreinfo

Justification: Package is not unusable for everyone.  See the following
for further info: https://www.debian.org/Bugs/Developer#severities

Reply follows inline:

Eric Valette  writes:

> Using dolphin for network, you can select gdrive but it does not propose to 
> add
> a google account.
>

That's odd, mine shows a "New account" button.

> Using systemsettings, I have the same problem and using the command rpoposed 
> in the
> packahe readme.md gives:
> kioclient5 exec gdrive:/
> kf.service.services: KApplicationTrader: mimeType "x-scheme-handler/gdrive" 
> not found
> kf.kio.core: KIO::get didn't emit a mimetype! Please fix the KIO worker for 
> URL QUrl("gdrive:/")
>

Hmm, that sounds like the KIO worker wasn't registered properly.  I'll
assume you ran "kdeinit5 # or just [logout and] re-login" as stated in
the README.  Assuming this was the case indicates some kind of breakage
elsewhere.

> Kernel: Linux 5.15.108 (SMP w/8 CPU threads; PREEMPT)

Neat, I track this branch too :)

> Versions of packages kio-gdrive depends on:
> ii  kaccounts-integration  4:22.12.3-1
> ii  kio5.104.0-1

Are you able to reproduce this bug with a pure testing/bookworm or
sid/unstable system?  If so, please provide steps to reproduce, and
remove the moreinfo tag from this bug at that time.

Assuming the README was followed, it appears that the trigger condition
is kio (or another package) from experimental.  I wonder if the ABI was
silently broken by upstream again, and that's what's going on here?  If
you'd like to test this hypothesis, try downloading the source package
for kio-gdrive, install the *-dev packages for the versions of the
libraries you're using on this installation, then dpkg-buildpackage,
debuild, or similar, as you prefer.

Alternatively, I wonder if this is a wishlist bug expressing how
annoying it is to have to "kdeinit5 # or just [logout and] re-login"?  I
would totally relate, by the way, because I find that annoying too.


Regards,
Nicholas

Bug#1012878: marked as done (pyside2: autopkgtest regression)

[Nicholas D Steeves]

Hi Christian,

After three NMUs, what do you think about adding yourself to Uploaders
and making these changes directly? :) I'm part of the Qt/KDE Team, but
don't maintain this package, and I've been importing your diffs with gbp
import-dsc.

Vcs-Git: https://salsa.debian.org/qt-kde-team/qt/pyside2.git
Vcs-Browser: https://salsa.debian.org/qt-kde-team/qt/pyside2

Also, please note that Developer's Reference §7.4.3 states "always send
a patch as a unified context diff (diff -u) detailing their changes to
the Bug Tracking System".

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1008849: shiboken2 - shiboken_helpers.cmake breaks with every Python transition

[Nicholas D Steeves]

Control: retitle -1 shiboken2 - shiboken_helpers.cmake breaks with every Python 
transition

Disclaimer: I didn't check to see if upstream 5.15.3 fixed this issue.

Yuri D'Elia  writes:

> On Wed, Apr 13 2022, Nicholas D Steeves wrote:
>> I understand, and agree that the issue is real, and that a rebuild is
>> required.  A binNMU is the most expedient solution ;-)  Please read
>> "What are binNMUs?" at the link provided above...
>
> Yes, but I wouldn't call this "expedient", since ...
>

Expedient means fast.  [1. Optionally check what happens locally]
2. Schedule a binNMU.

Unfortunately it won't work in this case.  The pyside2 build currently
in unstable correctly iterated over supported Python versions, and both
libshiboken2-py3-5.15 and libshiboken2-dev contain both Python 3.9 and
3.10 variants...but that's not good enough, because
shiboken_helpers.cmake doesn't appear to support multiple Python
versions, and isn't choosing the right (ie: Debian's python3-default)
version.

Yuri, I see what you mean now, it seems the fastest way to resolve this
would be to statically declare a dependency on python3.10-dev everywhere
in the package, but by doing this the Debian pyside2 package would lose
early detection of FTBFS and failing unit tests with future Python
versions, which means upstream might not receive early enough
notification, which means pyside2 would risk being cut from the next
Debian release if a Python transition happens right before the freeze.
The backported py3.10 support patches already in the pyside2 package are
evidence that the existing approach has value.

[snip]

> Answering this for an hypothetical 3.11 transition, the answer would
> similarly be "likely doesn't matter - it's worth attempting a build and
> hope for the best, because the current version is broken".

And with the above context, your pragmatic point makes sense in a
"perfect is the enemy of the good" sense :-)

Unfortunately your proposed resolution won't solve what now appears to
be the root of the problem: shiboken_helpers.cmake doesn't appear to
support multiple installed Python versions, and will necessarily break
with every Python transition.  It seems to me that that cmake file
should be generated during pyside2's build to enable runtime detection
of the support for all Python versions that were compiled into the
pyside2 libraries.  Alternatively, as a less desirable option, that
cmake file could be modified in override_dh_auto_install (or somewhere
more appropriate) to exclusively support the current python3-default
version.  In both cases, I'm assuming that the compiled py39 and py310
libs are functional.

>> As a general principle, I worry that this would either reduce
>> functionality and/or debugging, or introduce regression potential, so
>> this is not a change I'm willing to make as a team member and not
>> as one of the primary maintainers/uploaders of pyside2.
>
> I understand this. And the documentation around this define is lacking
> as well. Looking at the sources, it does seem to reduce the number of
> exported methods, so it is fair to say we might have users that expect
> the full API to be available and would break if used...

Thank you for your help investigating this option!

Unfortunately I'm out of time for the near future, but if you'd like I
can upload an untested 5.15.3 package to experimental for you to test.
To be honest, I won't have time to make the cmake fix for what isn't
even one of my packages.  Sorry.

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#1008849: shiboken2 - Needs tighter dependency on python3

[Nicholas D Steeves]

Hi Yuri and Kurt,

Kurt, would you please read the following discussion, and comment if
it's possible to generate a tighter Python dependency at build time?

Yuri D'Elia  writes:

> On Tue, Apr 12 2022, Nicholas D Steeves wrote:
>>> This also requires that shiboken2 should be currently rebuilt.
>>>
>>
>> Agreed.
>>
>>> Either the python3 dependency should be tightened, or FORCE_LIMITED_API
>>> should be used.
>>
>> These are not the only available options.  Are you aware of binNMUs?
>>   https://wiki.debian.org/binNMU
>
> I'm using it for development, and not being able to work if the minor
> version changes is a bigger problem than it sounds: I cannot rebuild
> third-party software which is using shiboken/pyside unless I completely
> rebuild pyside in parallel.
>

I understand, and agree that the issue is real, and that a rebuild is
required.  A binNMU is the most expedient solution ;-)  Please read
"What are binNMUs?" at the link provided above...

> I remember I already had this issue with the 3.9 transition.
>

Yes, this is totally normal during transitions, and this is why
transitions are needed.  You can also see proof of past binNMUs here:

  https://snapshot.debian.org/binary/libshiboken2-py3-5.15/

Those "+b" versions are binNMUs.

> IMHO if shiboken2 is tied to the minor version, it should depend on the
> minor version as well so that the whole pyside/shiboken2 so that
> transitions and downstream dependencies will also be handled as part of
> the transitions?
>
> For example, the current situation is probably breaking packages which
> are currently build with shiboken.
>

Kurt, this is the point I'm wondering about, because it would be better
if the transition tracker would alert us of outstanding issues rather
than waiting for someone to report breakage.  If this isn't feasible,
could you document that fact in the source package?

> This makes shiboken2 completely useless if you have more than a one
> minor version of python installed (for example during transition
> periods). shiboken2 will work only for _one_ minor version.
>

This might be by design.  Kurt, do you know?  There's also the question
of if pyside2/shiboken2 is even py3.10-ready (I haven't tested yet).

> I actually don't use shiboken2 _directly_ myself, but is there any real
> drawback to build with FORCE_LIMITED_API ?

As a general principle, I worry that this would either reduce
functionality and/or debugging, or introduce regression potential, so
this is not a change I'm willing to make as a team member and not
as one of the primary maintainers/uploaders of pyside2.  I can however
test py3.10 compatibility and request a binNMU.

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#1008849: shiboken2 - Needs tighter dependency on python3

[Nicholas D Steeves]

Hi Yuri,

Yuri D'Elia  writes:
[snip]
>   Built with: '3.9' Detected: '3.10'
>
> due to python3 now defaulting to python3.10.
>

Thank you for reporting this bug :-)

[snip]
>
> This also requires that shiboken2 should be currently rebuilt.
>

Agreed.

> Either the python3 dependency should be tightened, or FORCE_LIMITED_API
> should be used.

These are not the only available options.  Are you aware of binNMUs?
  https://wiki.debian.org/binNMU

Regards,
Nicholas


signature.asc
Description: PGP signature

Re: Proposal: drop Salsa CI testing for now

[Nicholas D Steeves]

Hi,

Norbert Preining  writes:

> I would like to collect opinions concerning Salsa CI testing:
>
> I contemplate disabling the whole salsa-ci for now, since all tests
> always fail, and we only take a lot of computing power for tests
> that nobody looks into, and hundreds of emails.
>
> I have no intention to fix the salsa-ci stuff, so I would like to
> disable it.
>
> If someone wants to work on getting the CI testing working again, we can
> reenable it again.
>
> What do you think?
>

I agree 100% and second this motion.  It's also worth mentioning that
unused and unmaintained CI runs waste electricity, electricity has a
carbon footprint, and thus unused and unmaintained CI contributes
nothing--except to global warming and associated natural disasters.

It's also a problem if all tests need to be updated for every release,
because that means that uploads of new releases will stall until a
hypothetical volunteer for CI work fixes the tests...if we use CI as a
"ready for upload" indicator.  If we're not using it for that, then it's
a waste of electricity.

I'm also concerned that the situation is fundamentally wrong: If tests
need to be updated with every new release, something is wrong with the
tests, or the infrastructure...  Tests and infrastructure are supposed
to be the controls that enable meaningful results when testing for
correct functionality in the face of changes.  eg: Imho, changing the
tests or infrastructure for every new release is bad methodology that
does not provide meaningful results.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#987063: gwenview: looses image metadata on jpg rotation

[Nicholas D Steeves]

Control: tag -1 + patch
Control: severity -1 important
Justification: loss of exif metadata.  A photographer would say "grave 
severity"!

Hi Karsten,

Karsten Hilbert  writes:

> Package: gwenview
> Version: 4:20.12.3-1
> Severity: normal
> Tags: upstream
>
> This release started to drop metadata from JPEG files after rotating
> them. I do believe the following upstream commit is the culprit:
>
>   
> https://invent.kde.org/graphics/gwenview/commit/a401e66621bcffbdc75048d9eaded1a5f5a67137
>
> because it "unconditionally" saves JPEGs thereby overwriting them w/o
> carrying over metadata :(
>

Thank you very for filing this bug.  I agree, this is a nasty issue that
will compromise Debian's reputation for reliability and a reassuring
policy of no data-loss bugs in stable releases.  IMHO this bug is RC,
but strictly speaking metadata isn't data, which is why I chose
"important"...nevertheless, no one should be punished for viewing a
photo in Gwenview rather than Darktable!

The emergency quick fix is here:
https://invent.kde.org/graphics/gwenview/-/commit/7e59f65fb1f14c36fcf12683c6eacb5f658dc3fc

from the PR:
https://invent.kde.org/graphics/gwenview/-/merge_requests/57

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#981515: kcoreaddons: please replace fam with gamin

[Nicholas D Steeves]

Hi,

Glenn Strauss  writes:

> gamin provides libfam0.
>
> kcoreaddons should load just fine with libfam0 from gamin.
>
> I did the research in #510368 and #966273, reviewing the actual code
> and confidentally concluded that FAM can be removed from Bullseye.
>
> The safest choice is to have a single library (gamin) used in the
> distro, rather than having both FAM and gamin.
>

I don't think the removal of FAM is as clear-cut as it has been
presented to be.

AFAIK the following is still current: Gamin provides "No NFS support
based on specific RPC and server, instead gamin monitors only the state
as reported locally by the kernel, not that locally done changes on NFS
or AFS filesystems are reported on Linux which is the main criteria when
having user home directories on such filesystems."

  https://people.gnome.org/~veillard/gamin/differences.html

thus FAM covers a use case that gamin does not, and this case is: users
who want to receive inotify style events for files that have been
remotely created or modified on NFS mounts.

I can't speak to how widespread the need for this feature is, but if it
is non-zero then it seems to me that FAM should not be removed this late
in the Bullseye cycle.

Also, IIRC gamin depends on Linux-specific features such as inotify
where FAM provides fallbacks (eg: IIRC FAM is required on kfreebsd and
hurd); this might not be significant, but I felt it was worth mentioning
:-)

FreeBSD doesn't have inotify, so there is a need for FAM, and maybe
someone from their community has become the defacto upstream (via their
"ports" packaging system)?  Or maybe someone from their community would
be willing to officially become FAM's new upstream?


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#942078: [high quality bug] baloo crash, can't recover; forced reindex does not fix; unusable via dolphin C-f

[Nicholas D Steeves]

Hi Norbert,

Norbert Preining  writes:

> Control: tag -1 +unreproducible
>
> Hi Nicholas,
>
> to be clear, tagging this bug as "unreproducible" means that **we** the
> developer cannot reproduce it. So please don't change it. Thanks.
>
> Also, moreinfo is still needed, and you didn't provide it.
>

I did. The minimum dataset needed to trigger was with an extensive set
of exclusion patterns that result in 436767 indexed files, with the
following results returned for balooctl indexSize

Actual Size: 3.27 GiB
Expected Size: 2.12 GiB

   PostingDB: 424.52 MiB19.516 %
  PositionDB: 845.84 MiB38.884 %
DocTerms: 344.65 MiB15.844 %
DocFilenameTerms:  47.45 MiB 2.181 %
   DocXattrTerms:0 B 0.000 %
  IdTree:   7.64 MiB 0.351 %
  IdFileName:  35.77 MiB 1.645 %
 DocTime:  22.29 MiB 1.024 %
 DocData:  23.21 MiB 1.067 %
   ContentIndexingDB:0 B 0.000 %
 FailedIdsDB:0 B 0.000 %
 MTimeDB:   2.59 MiB 0.119 %

>> > Can you reproduce this with current frameworks 5.77 in unstable?
>
> Since you haven't answered this questions, that BTW is alread at 5.78,
> we cannot really do anything.
>
> You don't expect us to try to triage bugs that we cannot reproduce on a
> system that is not running the current version?
>

I will upgrade this system in mid to late February, and hope to be
pleasantly surprised that this bug was fixed upstream :-)  At that time,
how would you like me run baloo to generate a higher quality debugging
info?  It could take up to a month to reproduce this bug, and by then
the reply will be "ignore for bullseye".  This is a contributing factor
to why baloo is in perpetual beta (I'd argue alpha, but subjectivity ;-))

>> Has anyone on the team tried testing baloo with a large $HOME?  Mine is
>> 131GB, in 142460 mixed files and directories.  At the moment my
>> baloo_file process is consuming over a terabyte (!) of memory.  After
>> resetting baloo and forcing a full reindex it takes a couple of weeks
>> before it gets out of control again and crashes.
>
> Well, maybe you should disable the service since it obviously is not
> able to cope with the amount of data/files/size you are asking it to
> index.
>

Right, that's why I filed this bug.  With a non-toy dataset, baloo is
more often than not unusable.  Typical lore says to disable baloo and
use the more robust recoll.  I'm willing to conceded that it's possible
that there's something special about my data/files, and that they're
causing baloo to fail in a corner-case.  If that's the case, what data
do you need?  Other than all my files ;-)

>> Please don't sweep baloo bugs under the rug by tagging bugs containing
>> crashes with obvious misbehaviour as severity "normal", eg:
>
> Again, since it is not reproducible and nobody else has either reported
> this problem and none of us see this problem, it is normal, would you
> please kindly trust the decision of the maintainers?
> And thanks, you don't have to educate me about severities.
>

Important: "a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone."  It is
clear that this bug meets Debian criteria for "important".  If no one
else on the team (I'm a team member too) is testing baloo with a medium
size set of diverse file types than no one else one the team will be
able to reproduce it.

A politic of "normal + unreproducible" is a contributing factor to
why baloo is never fixed.  In other words, it's a politic of ignoring
problems in baloo.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#942078: [high quality bug] baloo crash, can't recover; forced reindex does not fix; unusable via dolphin C-f

[Nicholas D Steeves]

Control: tag -1 -unreproducible -moreinfo
Control: severity -1 important

Hi Norbert,

Norbert Preining  writes:

> Hi Nicholas,
>
> On Wed, 09 Oct 2019, Nicholas D Steeves wrote:
>> Version: 5.54.0-1
>> Severity: serious
>> Justification: poor experience will cause user to give up on baloo; worse 
>> than GNOME
>
> Can you reproduce this with current frameworks 5.77 in unstable?
>
> Does it always crash at the same file (jack_capture_90.mp3) or always in
> different files?
>

The crash is not specific to jack_capture_90.mp3; except for a period of
time a couple of weeks long leading up to the original bug.

Thank you for following up in this bug (finally someone did!)  It's
still too early in the freeze for me to upgrade this system to bullseye.

Has anyone on the team tried testing baloo with a large $HOME?  Mine is
131GB, in 142460 mixed files and directories.  At the moment my
baloo_file process is consuming over a terabyte (!) of memory.  After
resetting baloo and forcing a full reindex it takes a couple of weeks
before it gets out of control again and crashes.

Please don't sweep baloo bugs under the rug by tagging bugs containing
crashes with obvious misbehaviour as severity "normal", eg:

> id seems to have changed. Perhaps baloo was
> not running, and this file was deleted + re-created
> mdb.c:3124: Assertion 'pglast <= env->me_pglast' failed in
> mdb_freelist_save()

which is somewhere between important and serious
https://www.debian.org/Bugs/Developer#severities

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work

[Nicholas D Steeves]

Hi,

Adrian Bunk  writes:

> On Fri, Jul 10, 2020 at 07:48:31PM -0400, Nicholas D Steeves wrote:
>
>> it would still not be DFSG-free, because it
>> fails the "desert island test" for snail mail.  Were OmniTI Computer
>> Consulting would accept email, it would also fail the "dissident test".
>
> This is the first time I see someone claiming BSD-4-clause would not
> be distributable.
>

Well, BSD-4-clause isn't on the list of DFSG-approved licenses...

  https://wiki.debian.org/DFSGLicenses

>> Finally, BSD-4-clause is not an approved license in KDE projects
>>   https://community.kde.org/Policies/Licensing_Policy
>
> Policies for new source code added in KDE are not relevant in Debian.
>
>> Feel free to escalate this issue...I'm humble and am comfortable with
>> being shown the error of my ways, but I believe this is a genuine
>> problem.
>
> Yes, it would be good if other people from debian-legal would comment.
>

Agreed :-)


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work

[Nicholas D Steeves]

Hi Adrian,

Adrian Bunk  writes:

> On Fri, Jul 10, 2020 at 06:33:32PM -0400, Nicholas D Steeves wrote:
>> Adrian Bunk  writes:
>> > On Fri, Jul 10, 2020 at 03:38:57PM -0400, Nicholas D Steeves wrote:
>> >>...
>> >> * Neither name of the company nor the names of its contributors may be 
>> >> used to endorse or promote products derived from this software without 
>> >> specific prior written permission.
>> >> 
>> >> I'm not 100% certain that bundling dprof2calltree with kcachegrind 
>> >> constitutes a "product[s] derived from this software", because I'm also 
>> >> of the opinion that bundling != derivation, but it seems like a lawyer 
>> >> might argue the it does.  So kcachegrind and any distributions' package 
>> >> would also need written persmission from OmniTI Computer Consulting.
>> >>...
>> >
>> > You are arguing the 3-Clause BSD License would be non-free?
>> 
>> No, because dprof2calltree is modified 4-Clause BSD.
>
> dprof2calltree uses a verbatim copy of 4-Clause BSD
> (except for filling the company placeholders).
>
> This clause is one of the 3 clauses that are identical in 3-clause and 
> 4-clause BSD.
>

I'm aware of 4-clause to 3-clause BSD similarities and history.

>> > On Fri, Jul 10, 2020 at 03:53:48PM -0400, Nicholas D Steeves wrote:
>> 
>> It fails the "desert island test" because
>> 
>> 1. Any mention of the features or use of this software requires
>> user-facing display of the text "This product includes software
>> developed by OmniTI Computer Consulting".
>> 
>> 2. OmniTI Computer Consulting's name cannot be used to "without specific
>> prior written permission"
>> 
>> The desert island does not have the paper snailmail service required to
>> fulfil #2 (4th clause of the license).
>
> The 4-clause BSD license is around for 30 years, everyone else 
> (including the FSF[1]) does not interpret it the way you do
> that there would be a conflict between these two clauses.
>
> cu
> Adrian
>
> [1] https://www.gnu.org/licenses/license-list.html#OriginalBSD

Did you read the text at that link?  "it *does* cause practical
problems, including incompatibility with the GNU GPL [emphasis mine]"

Also here https://infogalactic.com/info/License_compatibility

Many of the most common free software licenses, especially the
permissive licenses, such as the original MIT/X license, BSD
licenses (in the three-clause and two-clause forms, *though not the
original four-clause form*), MPL 2.0, and LGPL, are
"GPL-compatible". That is, their code can be combined with a program
under the GPL without conflict and the new combination would have
the GPL applied to the whole (not the other license) [emphasis
mine].

Finally, the "desert island test" is a DFSG test, and not a DFSG test.
Were you to provide proof from a legal team that the BSD-4-clause was
somehow GPL-compatible, it would still not be DFSG-free, because it
fails the "desert island test" for snail mail.  Were OmniTI Computer
Consulting would accept email, it would also fail the "dissident test".

Finally, BSD-4-clause is not an approved license in KDE projects
  https://community.kde.org/Policies/Licensing_Policy

Feel free to escalate this issue...I'm humble and am comfortable with
being shown the error of my ways, but I believe this is a genuine
problem.


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work

[Nicholas D Steeves]

Hi Adrian,

Adrian Bunk  writes:

> On Fri, Jul 10, 2020 at 03:38:57PM -0400, Nicholas D Steeves wrote:
>>...
>> * Neither name of the company nor the names of its contributors may be used 
>> to endorse or promote products derived from this software without specific 
>> prior written permission.
>> 
>> I'm not 100% certain that bundling dprof2calltree with kcachegrind 
>> constitutes a "product[s] derived from this software", because I'm also of 
>> the opinion that bundling != derivation, but it seems like a lawyer might 
>> argue the it does.  So kcachegrind and any distributions' package would also 
>> need written persmission from OmniTI Computer Consulting.
>>...
>
> You are arguing the 3-Clause BSD License would be non-free?
>

No, because dprof2calltree is modified 4-Clause BSD.

> On Fri, Jul 10, 2020 at 03:53:48PM -0400, Nicholas D Steeves wrote:
>>...
>> At the very least, it appears that the advertising clauses make
>> dprof2calltree not DFSG-free,
>
> It does not:
> https://www.debian.org/legal/licenses/
>
>> because they fail the "desert island test".
>>...
>
> It does not.
>
> If you choose to advertise the use of this software on your desert 
> island, you have to include the acknowledgement in your advertisement.
>

It fails the "desert island test" because

1. Any mention of the features or use of this software requires
user-facing display of the text "This product includes software
developed by OmniTI Computer Consulting".

2. OmniTI Computer Consulting's name cannot be used to "without specific
prior written permission"

The desert island does not have the paper snailmail service required to
fulfil #2 (4th clause of the license).


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work

[Nicholas D Steeves]

At the very least, it appears that the advertising clauses make
dprof2calltree not DFSG-free, because they fail the "desert island
test".

Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work

[Nicholas D Steeves]

Package: kcachegrind-converters
Version: 4:17.08.3-2
Severity: serious
Tags: upstream
Forwarded: https://bugs.kde.org/show_bug.cgi?id=424078

While preparing to import the new upstream release 
(https://salsa.debian.org/qt-kde-team/kde/kcachegrind/-/merge_requests/3) I did 
a copyright review, and during that review I discovered 
converters/dprof2calltree © 2004 OmniTI Computer Consulting with a problematic 
advertising clause.  Here is a copy of what I filed upstream:

converters/dprof2calltree is © 2004 OmniTI Computer Consulting

Unfortunately its BSD-4-like (with problematic advertising clause) has the 
following issue:

* All advertising materials mentioning features or use of this software must 
display the following acknowledgement: This product includes software developed 
by OmniTI Computer Consulting.

* Neither name of the company nor the names of its contributors may be used to 
endorse or promote products derived from this software without specific prior 
written permission.

I'm not 100% certain that bundling dprof2calltree with kcachegrind constitutes 
a "product[s] derived from this software", because I'm also of the opinion that 
bundling != derivation, but it seems like a lawyer might argue the it does.  So 
kcachegrind and any distributions' package would also need written persmission 
from OmniTI Computer Consulting.

Metadata, such as a package description (deb, rpm, etc.) or possibly even 
converters/README can be argued to be advertising materials.  If the package 
description appears in an "App store" like Discover then I think it would be 
considered advertising.

Thus, mentioning features provided by dprof2calltree in any user-facing way 
appears to require written permission from OmniTI Computer Consulting.

Given how this requirements is more restrictive than the GPL-2, it looks like 
dprof2calltree cannot be distributed with a GPL-2 work.

Disclaimer, this is not legal advice, but legal advice should be sought if 
kcachegrind is to continue to distribute dprof2calltree.

Thanks,
Nicholas

Bug#936783: kcachegrind: Python2 removal in sid/bullseye

[Nicholas D Steeves]

Control: tag -1 patch

Hi,

John Scott  writes:

> Python 3 doesn't include hotshot, so the hotshot2calltree script should be 
> dropped. Upstream still includes it but it doesn't appear to have seen any 
> maintenance:
> https://invent.kde.org/sdk/kcachegrind/-/tree/master/converters

I've filed an MR to fix this bug immediately

  https://salsa.debian.org/qt-kde-team/kde/kcachegrind/-/merge_requests/2

and have filed one that includes all of !2, but that additionally
updates to the latest upstream version, and have confirmed it builds
with currently available Qt and KF5

  https://salsa.debian.org/qt-kde-team/kde/kcachegrind/-/merge_requests/3


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#962780: kaccounts-integration: [ABI break] 20.04 and 20.04.1 have renamed symbols and needs an upstream ABI bump

[Nicholas D Steeves]

Hi Pino,

On Sun, Jun 21, 2020 at 12:01:32PM +0200, Pino Toscano wrote:
> In data giovedì 18 giugno 2020 12:51:59 CEST, Nicholas D Steeves ha scritto:
> > It just occurred to me that I thought we were waiting for upstream to
> > make a new release (now that would be ≥20.04.3), because from the
> > little I've learned about ABI updates "libkaccounts1" will also need
> > to be updated.  Is that supposition correct?
> 
> I'm not sure I understand what you are saying.
>

I mean, do we upload libkaccounts1abi1, or wait for libkaccounts2 in a
future upstream release (probably 20.04.3 at this point), or cherry
pick the ABI break commit?

> For sure we will need to bump the SONAME of the libkaccounts library,
> because it is a public library and it had an ABI break. Ideally it
> should be done upstream, so we don't do it twice... assuming they
> answer.
>
> If upstream does not answer or does not care, we must apply our system,
> i.e. the ABI manager.

I did this (new SONAME is libkaccounts1abi1) at:
  
https://salsa.debian.org/qt-kde-team/kde/kaccounts-integration/-/merge_requests/3

and I'd appreciate if it was merged, because I think it's important to
have proof in the repo that we (as a team) are working to unblock
issues that are preventing the latest stable upstream versions of
KDE/Plasma from being imported into Debian (a topic of a recent
debian-kde thread)

Upstream now has a fix waiting for a merge:

  https://invent.kde.org/network/kaccounts-integration/-/merge_requests/2

After that commit is officially merged I can cherry pick it as a quilt
patch and add the libkaccounts2 to my MR.

For future reference, after filing an upstream issue for an undeclared
ABI break, what is a reasonable amount of time to wait before doing a
foo1abi1 upload?  Assuming it takes one month for src:foo with
bin:foo1abi1 to clean NEW, it seems like two weeks would be the
cutoff, because otherwise we'd be closer to the next quarterly
release.

Thanks again for taking the time to train me, and please let me know
if there's anything I need to fix.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#962780: kaccounts-integration: [ABI break] 20.04 and 20.04.1 have renamed symbols and needs an upstream ABI bump

[Nicholas D Steeves]

Hi Pino,

It just occurred to me that I thought we were waiting for upstream to
make a new release (now that would be ≥20.04.3), because from the
little I've learned about ABI updates "libkaccounts1" will also need
to be updated.  Is that supposition correct?

If not, I've downloaded the patch, completed the DEP3 headers, and can
commit, build, test, and push to the existing MR for symbol updates.

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#948853: Fixed upstream with kaccounts-providers 19.12.2

[Nicholas D Steeves]

Control: block -1 by 962780

Hi Marcos,

Marcos Raúl Carot  writes:

> As per message #20:
>
> https://bugs.kde.org/show_bug.cgi?id=415089#c20
>
> Could you please upload a new version to Debian?
>

I believe kaccounts-providers is blocked by the named bug, because
kaccounts-providers has a build-dep on bin:libkaccounts-dev and that
package is from src:kaccounts-integration.  'hope to see that issue
resolved upstream soon.  P.S. I'm about to ask a senior team member to
confirm if waiting for the next upstream release is indeed the correct
approach.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#962780: kaccounts-integration: [ABI break] 20.04 and 20.04.1 have renamed symbols and needs an upstream ABI bump

[Nicholas D Steeves]

Package: kaccounts-integration
Severity: normal
Tags: upstream
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=422191

Hi,

I'm filing this bug so there's a record on the Debian-side.  The
existence of this bug emerged while discussing a yet-unmerged MR with
hefee.

  
https://salsa.debian.org/qt-kde-team/kde/kaccounts-integration/-/merge_requests/3

Pino, I've CCed you because we've collaborated upstream before,
because you've uploaded kio-gdrive, because kio-gdrive depends on
kaccounts, and thus it seems like you might be interested in resolving
this upstream issue.

Regards,
Nicholas

[Nicholas D Steeves] Re: KDEPIM 20.04 and KDE Frameworks 5.70 coming to unstable now

[Nicholas D Steeves]

Also replying to debian-qt-kde, in case some team members are not
following debian-kde.

Hi!

Martin Steigerwald  writes:

> Martin Steigerwald - 27.05.20, 08:53:42 CEST:
>> Woooho=E2=80=A6 it's all coming now!
>>

:-D  Thanks to everyone who worked on this; it's a tonne of work!

>> As usual wait till complete.
>
> As Sandro told, some packages need to be recompiled. Here the list he=20
> posted:
>
> digikam
> kgpg
> kio-gdrive
> kjots
> kmymoney
> kraft
> zanshin
>
> So if you rely on any of these these, you may need to wait a little bit=20
> longer than the building of KDEPIM 20.04 and KDE Framework 5.70=20
> packages.
>

Kio-gdrive has a new upstream version in git.  IIRC it is also
implicated by a bug where Google broke app authentication, and IIRC the
fix for this is in kaccounts-integration and/or kaccounts-providers.
I'm working on updating both of these packages.

Hefee has been teaching me about symbol files and working with me on an
MR for kaccounts-integration.  At this time we're discussing whether now
is the time to introduce DebianABIManager to this package.

If anyone would like to upload kio-gdrive, kaccounts-integration, or
kaccounts-providers, please check with me first.

If this work isn't complete when hefee runs out of free time, would
someone please volunteer to guide me through the final steps?

Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

[Nicholas D Steeves]

Hi Lisandro,

Lisandro Damián Nicanor Pérez Meyer  writes:

> Hi!
>
> On Wed, 4 Mar 2020 at 20:40, Nicholas D Steeves  wrote:
>>
>> Hi Lisandro,
>>
>> Out of curiosity, could this be solved for a Debian (and derivatives)
>> context by changing the Recommends on clang and clang-tidy to their
>> versioned package names (eg: clang-8 and clang-tidy-8)?
>
> No, this is not a versioning problem.
>

I agree, ideally it should be solved upstream, but a side-effect of
installing Recommends s/clang/clang-8/ is that it pulls in a dependency
on libclang-common-8-dev, and

Alexis Murzeau  writes:

> Install `qtcreator` but not the `libclang-common-8-dev` package
> Note: Installing `clang` package will install `clang-9` and not `clang-8`.
>
[snip]
>
> When installing the `libclang-common-8-dev` package, the clang code
> model error goes away and no error is reported anymore.
>
[snip]
>
> I expect the clang code model to work out of the box with all depends
> and recommends dependencies of `qtcreator`.
> As of now, `libclang-common-8-dev` seems required by the clang code
> model to work correctly, but that package is not a direct or indirect
> dependency of `qtcreator`.
>
> The simplest solution (if it is the right one) is to add
> `libclang-common-8-dev` as depends or recommends dependency to qtcreator.
> Or maybe it should be a dependency of `libclang1-8` instead (which
> qtcreator depends on).
>

My proposal would solve the Debian (and derivatives) case and is easy to
update/maintain with a sed regex.  Is our team categorically opposed to
working around upstream issues using Debian packaging facilities?

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

[Nicholas D Steeves]

Hi Lisandro,

Out of curiosity, could this be solved for a Debian (and derivatives)
context by changing the Recommends on clang and clang-tidy to their
versioned package names (eg: clang-8 and clang-tidy-8)?


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#950614: libqt5core5a conflicts with libqtcore4

[Nicholas D Steeves]

Hi Yuri,

Yuri D'Elia  writes:

> This makes libqt5core5a uninstallable for me. I have several programs
> which still depend on libqtcore4. I also still develop on qt4.

FYI https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
and https://wiki.debian.org/Qt4Removal

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#900710: a man page should be provided for kdeconnect-cli

[Nicholas D Steeves]

Control: retitle -1 a man page should be provided for kdeconnect-cli

Hi Pino,

On Mon, Nov 12, 2018 at 08:45:10AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the kdeconnect package:
> 
> #900710: very out of date manpage
> 
> It has been closed by Pino Toscano .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Pino Toscano 
>  by
> replying to this email.
> 
> 
> -- 
> 900710: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900710
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Mon, 12 Nov 2018 08:41:46 +
> From: Pino Toscano 
> To: 900710-cl...@bugs.debian.org
> Subject: Bug#900710: fixed in kdeconnect 1.3.3-1
> 
> Source: kdeconnect
> Source-Version: 1.3.3-1
>
[snip]
>  kdeconnect (1.3.3-1) unstable; urgency=medium
[snip]
>* Drop the Debian-provided kdeconnect-cli man page: very outdated, not
>  touched in the last 4 years, and thus not useful. (Closes: #900710)

This bug was closed in error at a time I was swamped with work, and I
didn't notice until now.  Please consult Policy §12.1 for why it was
wrong to close it.  tldr;

If no manual page is available, this is considered as a bug and
should be reported to the Debian Bug Tracking System (the
maintainer of the package is allowed to write this bug report
themselves, if they so desire). Do not close the bug report until
a proper man page is available.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#948207: Fixed in 19.12.2...

[Nicholas D Steeves]

Hi Eric,

Eric Valette  writes:

> On 19/01/2020 21:25, Eric Valette wrote:
>> The Google block will be fixed with kaccounts-providers 19.12.2.
>> 
>> 
>> --eric
> Fix is here:
>
> https://cgit.kde.org/kaccounts-providers.git/patch/?id=f26e97cfc9308bcc70a3b0b29a5fd9a4b9c42da2
>
> --eric

This is documented at Bug #948853, against kaccounts-providers.

To any team members reading this: please do not close this kio-gdrive
bug unless a buster update for kaccounts-providers is uploaded and
resolves the issue in stable.  I expect that buster is affected and
anticipate that a user with a new buster installation will file a "me
too" update to this bug sometime in the next six months.

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#948853: kaccounts-providers: Broken Google authentication in "Accounts"

[Nicholas D Steeves]

Package: kaccounts-providers
Version: 4:17.08.3-1
Severity: normal
Control: blocks 948207 by -1

Various applications were broken when KDE's Google API key was revoked, 
including but not limited to KMail, Akonadi, and kio-gdrive.

Thanks to helios21 in #debian-qt-kde for providing the link to this
proposed fix:

https://mail.kde.org/pipermail/distributions/2020-January/000341.html

Regards,
Nicholas

Bug#948207: kio-gdrive: No more work because google temoprarilly supressed the access

[Nicholas D Steeves]

Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=415089
Control: severity -1 important
Justification: kio-gdrive is not unusable for everyone

Hi Eric,

Thank you for reporting this bug, and especially for providing a link to
the upstream bug :-)

I've reduced the severity to important, because the package remains
usable for anyone who already has already authorised kio-gdrive and who
did not fall victim to Google's manipulation--the narrative you've
provided is remarkably similar to a phishing attack in the sense that an
email requested user action, the user took action, and consequently the
user lost access to their files.  I agree that it's a severe issue that
has greatly inconvenienced you, but we need to abide by official
severity definitions:
  https://www.debian.org/Bugs/Developer#severities

It is my position that this is a user-hostile action by Google and not a
bug in kio-gdrive, and I expect that existing kio-gdrive versions will
begin to work again without maintainer action as soon as Google
reauthorises kio-gdrive's application API key.  While it only affects a
minority of users (eg: not on Windows or MacOS), it's a really bad PR
move (like Dropbox dropping non-ext4 support) that ought to drive users
away from their proprietary services towards freedom-respecting
solutions like Syncthing and OwnCloud/NextCloud.  If maintainer action
is required, then I will also provide a stable update for buster users.

It's 10 or 11 months early for the decision about whether this package
should be cut from bullseye (Debian 11) due to this issue.  At that time
it may be appropriate to raise this bug's severity to RC, with the
practical "for all intents and purposes unusable for new users"
rationale you provided.  It will be interesting to see what Ubuntu will
do for their 20.04 LTS release!

With respect to the "Accounts" interface, Plasma will activate whatever
it can use, as will GNOME.  The former has checkboxes and the later has
toggle switches to limit which services are activated.

https://bugs.kde.org/show_bug.cgi?id=415089#c15
  * From what you wrote it sounds like there's also a bug (or evil
misfeature) in Google's authorisation interface/infrastructure,
because deauthaurising calendar or mail should not have disabled
access to GDrive.

Thanks again for taking the time to file this bug and for drawing
attention to a real-life problem that demonstrates how we shouldn't
trust our data to corporations who hold all the locks and keys...and I
say this as someone who took the time to package kio-gdrive for Debian,
because it's better to have it than to not, but best not to use it at
all.

Sincerely,
Nicholas


signature.asc
Description: PGP signature

[RFC] advice about an upstream library that seems like a namespace grab

[Nicholas D Steeves]

Dear Team,

I've been struggling to figure out how to name the following package.
It's a dependency of SyncthingTray, which--despite my slow progress--I'm
very dedicated to packaging, because it's the best freedom-respecting
alternative I've found to Dropbox and Google Drive that doesn't require
an OwnCloud server.

https://github.com/Martchus/cpp-utilities

IIRC it produces symbols named c++utilities, which is why it feels like
a namespace grab.  It seems to me that it should be prefixed under the
"martchus" namespace, eg: martchus-c++utilities, or
martchus-cpputilities.  Do we need/want the martchus prefix in Debian,
or would you bless this namespace grab?

Ideally this could be solved upstream...but worse case scenario we would
have to rename the library for Debian use, patch it to use the new
public symbol names (with the prefix), and also patch any software in
Debian to check for the new name--probably in addition to the old name,
to avoid the situation where software written for Debian doesn't work
anywhere else.  If we need to make Debian-only modifications I'll need
pointers to documentation about how to do this properly, without
creating a nightmare maintenance burden.


Looking forward to your replies!
Thanks,
Nicholas

P.S. @Lisandro, this is the dependency I mentioned I'd need advice about
in our other thread.


signature.asc
Description: PGP signature

Bug#931676: [baloo-kf5] suspend doesn't work

[Nicholas D Steeves]

On Tue, Jul 09, 2019 at 12:05:23PM +0500, Alex Volkov wrote:
> Package: baloo-kf5
> Version: 5.54.0-1
> Severity: normal
> 
> --- Please enter the report below this line. ---
> 
> When trying to suspend indexing process with either 'balooctl suspend' or 
> with 
> the button in KInfocentre, it says "File Indexing suspended", 
> 'baloo_file_extractor' gets killed and the button turns to "Resume", but in a 
> second or so 'baloo_file_extractor' spawns back and the indexing resumes 
> again 
> (the button turns to "Suspend"). However f*cked up its developers are, I 
> doubt 
> this is intended behavior.
> 

I can confirm this.  It's a major battery drainer and needs to be
fixed.  I've been manually using balooctl stop to work around the
issue in the meantime.  Also, due to another bug I sometimes need to
killall baloo_file_extractor, which unfortunately doesn't handle
-SIGTERM properly--so I don't think this can honestly be recommended
as a mitigation.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#942078: [high quality bug] baloo crash, can't recover; forced reindex does not fix; unusable via dolphin C-f

[Nicholas D Steeves]

Package: baloo-kf5
Version: 5.54.0-1
Severity: serious
Justification: poor experience will cause user to give up on baloo; worse than 
GNOME

Hi,

Recently baloo has been crashing whenever I log in.  Today I decided it
was a persistent and serious enough problem that a serious bug was
warranted.  I've attached the backtrace produced by drkonqi.  Here is
some additional info that I hope will help quickly resolve this bug.

$ balooctl start
QCoreApplication::arguments: Please instantiate the QApplication object first
QCoreApplication::applicationDirPath: Please instantiate the QApplication 
object first
This process needs a QCoreApplication instance in order to use KCrash
"/home/sten/jack_capture_90.mp3" id seems to have changed. Perhaps baloo was 
not running, and this file was deleted + re-created
mdb.c:3124: Assertion 'pglast <= env->me_pglast' failed in mdb_freelist_save()
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = baloo_file_extractor path = /usr/bin pid = 15575
KCrash: Arguments: /usr/bin/baloo_file_extractor 
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from 
kdeinit
QSocketNotifier: Invalid socket 9 and type 'Read', disabling...
QSocketNotifier: Invalid socket 18 and type 'Read', disabling...
QSocketNotifier: Invalid socket 10 and type 'Read', disabling...

$ balooctl clear /home/sten/jack_capture_90.mp3
Skipping: /home/sten/jack_capture_90.mp3 Reason: Not yet indexed
File(s) cleared

$ balooctl index /home/sten/jack_capture_90.mp3
Indexing /home/sten/jack_capture_90.mp3
mdb.c:3124: Assertion 'pglast <= env->me_pglast' failed in mdb_freelist_save()
Aborted

$ balooctl status
Baloo File Indexer is running
Indexer state: Indexing file content
Indexed 57061 / 57062 files
Current size of index is 703.08 MiB

$ balooctl  indexSize
Actual Size: 703.08 MiB
Expected Size: 456.43 MiB

   PostingDB: 111.95 MiB24.527 %
  PositionDB: 189.31 MiB41.476 %
DocTerms:  58.71 MiB12.862 %
DocFilenameTerms:   6.20 MiB 1.357 %
   DocXattrTerms:0 B 0.000 %
  IdTree: 996.00 KiB 0.213 %
  IdFileName:   4.65 MiB 1.019 %
 DocTime:   2.57 MiB 0.563 %
 DocData:   3.51 MiB 0.769 %
   ContentIndexingDB:   4.00 KiB 0.001 %
 FailedIdsDB:0 B 0.000 %
 MTimeDB:   1.20 MiB 0.263 %

...wait a while, then

$ balooctl stop

...wait a while.  Baloo fails to stop.

$ ps xa | grep /usr/bin/baloo_file
$ gdb -p $THAT_PID
$ kill $THAT_PID

Result: no backtrace

$ gdb /usr/bin/baloo_file

Starting program: /usr/bin/baloo_file 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x72c7e700 (LWP 17185)]
[New Thread 0x7215b700 (LWP 17186)]
[Detaching after fork from child process 17187]
QCoreApplication::arguments: Please instantiate the QApplication object first
QCoreApplication::applicationDirPath: Please instantiate the QApplication 
object first
This process needs a QCoreApplication instance in order to use KCrash
"/home/sten/jack_capture_90.mp3" id seems to have changed. Perhaps baloo was 
not running, and this file was deleted + re-created
mdb.c:3124: Assertion 'pglast <= env->me_pglast' failed in mdb_freelist_save()
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = baloo_file_extractor path = /usr/bin pid = 17187
KCrash: Arguments: /usr/bin/baloo_file_extractor 
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from 
kdeinit
QSocketNotifier: Invalid socket 9 and type 'Read', disabling...
QSocketNotifier: Invalid socket 18 and type 'Read', disabling...
QSocketNotifier: Invalid socket 10 and type 'Read', disabling...

Result: CRASH.  Drkonqi provides a bt for baloo_file_extractor.  I've attached 
that one too.


Regards,
Nicholas

-- System Information:
Debian Release: 10.1
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.72-rt25 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages baloo-kf5 depends on:
ii  kio  5.54.1-1
ii  libc62.28-10
ii  libkf5baloo5 5.54.0-1
ii  libkf5balooengine5   5.54.0-1
ii  libkf5configcore55.54.0-1+deb10u1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5filemetadata3  5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5idletime5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5solid5 5.54.0-1
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5dbus5  5.11.3+dfsg1-1
ii  libqt5gui5   

Bug#939586: gwenview should provide a /usr/lib/mime/packages/gwenview file

[Nicholas D Steeves]

On Fri, Sep 06, 2019 at 05:57:27PM +0200, Erwan David wrote:
> Package: gwenview
> Version: 4:18.04.0-1.1+b1
> Severity: minor
> 
> since there is no /usr/lib/mime/packages/gwenview, we cannot use gwenview as
> default image viewer for non KDE applications. Such a file would be useful.
> 

+1 !  I was just about to file a bug on this topic, because I've
finally gotten fed up about this.  Steps to reproduce:

1. Install Debian with KDE Desktop
2. "see foo.png" opens with gwenview
3. Install calibre (installs ImageMagick as a dependency)
4. "see foo.png" now opens in Imagemagick :-(

The only workaround I'm aware of is /etc/mailcap.order.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#936033: ITP: pyprof2calltree -- visualise Python cProfile data with this kcachegrind converter

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 

Package name: pyprof2calltree
Version : 1.4.4
Upstream Author : Peter Waller 
URL : https://github.com/pwaller/pyprof2calltree
License : Expat, MIT, or custom-permissive (needs verification)
Programming Lang: Python
Description : visualise Python cProfile data with this kcachegrind converter

 Pyprof2calltree converts cProfile data into a format that is
 consumable by kcachegrind and qcachegrind for graphical calltree
 analysis.  This combination provides similar capabilities to Snakeviz
 or RunSnakeRun.
 .
 Pyprof2calltree is an adaptation of lsprofcalltree.py, by David
 Allouche, Jp Calderone, Itamar Shtull-Trauring, and Johan Dahlin.  It
 has been adapted to behave more like scripts in the
 kcachegrind-converters package.  One of the authors' objectives is
 for pyprof2calltree to become part of the official upstream kdesdk
 package.
 .
 This package installs the library for Python 3.

I am packaging this because of the cProfile visualisers Elpy (Emacs
IDE for Python) supports: one displays in a browser, RunSnakeRune is
Python 2 only, which leaves this package.  IMHO it's the most
desirable, but I have a KDE bias.

As I'm already on the QT/KDE Team and upstream intents to eventually
merge it into kdesdk, I believe the KDE Extras project is probably the
most appropriate place for it.  I will need a sponsor for the initial
upload.


Regards,
Nicholas

Bug#935914: kinit: Signal: Segmentation fault (11) after rebooting

[Nicholas D Steeves]

I'm still not sure how to reliably reproduce this bug, but the
kdeinit5 crashes have continued to occur every ~30min today (within a
single session).

The memory usage spike I mentioned in a previous message seems to be
caused by baloosearch.so ... which didn't have this issue in stretch.
The backtrace seems to support a possible baloo<->kdeinit5
malinteraction.

P.S. I'm blacklisting most directories, because Baloo has always
choked when fed too much data.


signature.asc
Description: PGP signature

Bug#935914: kinit: Signal: Segmentation fault (11) after rebooting

[Nicholas D Steeves]

Wow, it was harder than expected to get the dbsym packages without a
security-debug suite.  Thanks to adsb and ansgar on #debian-qt-kde for
the help (adds additional steps to my easy useful backtraces for end
users plan).  Here it is:

Application: kdeinit5 (kdeinit5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[KCrash Handler]
#6  0x7f966bfb6465 in QVector::reallocData 
(this=this@entry=0x5630f066f3a8, asize=268435452, aalloc=, 
options=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qarraydata.h:218
#7  0x7f966bfba78e in QVector::append (t=: , this=0x5630f066f3a8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:102
#8  QVector::operator<< (t=: , this=0x5630f066f3a8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h:283
#9  IdTreePostingIterator::next (this=0x5630f066f380) at 
./src/engine/idtreedb.cpp:128
#10 0x7f966bfa9444 in Baloo::AndPostingIterator::next (this=0x5630f0662de0) 
at ./src/engine/andpostingiterator.cpp:42
#11 Baloo::AndPostingIterator::next (this=0x5630f0662de0) at 
./src/engine/andpostingiterator.cpp:45
#12 0x7f966c18c4c1 in Baloo::SearchStore::exec 
(this=this@entry=0x7ffe684bfcb0, term=..., offset=, 
limit=, sortResults=) at 
./src/lib/searchstore.cpp:127
#13 0x7f966c17b190 in Baloo::Query::exec (this=this@entry=0x7ffe684bfd40) 
at ./src/lib/query.cpp:210
#14 0x7f967332f519 in Baloo::SearchProtocol::listDir (this=0x7ffe684bffa0, 
url=...) at ./src/kioslaves/search/kio_search.cpp:120
#15 0x7f966e512f36 in KIO::SlaveBase::dispatch (this=0x7ffe684bffa0, 
command=71, data=...) at ./src/core/slavebase.cpp:1176
#16 0x7f966e513876 in KIO::SlaveBase::dispatchLoop 
(this=this@entry=0x7ffe684bffa0) at ./src/core/slavebase.cpp:325
#17 0x7f967332fd07 in kdemain (argc=, argv=) 
at ./src/kioslaves/search/kio_search.cpp:218
#18 0x5630f0593e1c in launch (argc=4, _name=0x5630f0641248 
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/baloosearch.so", args=, cwd=, envc=0, envs=, reset_env=false, 
tty=0x0, avoid_loops=false, startup_id_str=0x5630f0597187 "0") at 
./src/kdeinit/kinit.cpp:706
#19 0x5630f0594eea in handle_launcher_request (sock=8, who=) 
at ./src/kdeinit/kinit.cpp:1146
#20 0x5630f05958fb in handle_requests (waitForPid=0) at 
./src/kdeinit/kinit.cpp:1339
#21 0x5630f0590645 in main (argc=5, argv=) at 
./src/kdeinit/kinit.cpp:1785
[Inferior 1 (process 2571) detached]


signature.asc
Description: PGP signature

Bug#935914: kinit: Signal: Segmentation fault (11) after rebooting

[Nicholas D Steeves]

Package: kinit
Version: 5.54.0-1
Severity: important

Hi,

I haven't been able to reproduce this 100% of the time, but it happens
some of the time after logging in after rebooting.  I have a system
load monitor and have noticed that memory balloons and system
responsiveness drops right before the crash occurs.  Sorry for the
partially incomplete backtrace; libkf5configcore5-dbgsym wasn't
updated to 5.54.0-1+deb10u1 for some reason and is uninstallable.

Application: kdeinit5 (kdeinit5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[KCrash Handler]
#6  0x7f966bfb6465 in QVector::reallocData 
(this=this@entry=0x5630f066f3a8, asize=268435452, aalloc=, 
options=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qarraydata.h:218
#7  0x7f966bfba78e in QVector::append (t=: , this=0x5630f066f3a8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:102
#8  QVector::operator<< (t=: , this=0x5630f066f3a8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h:283
#9  IdTreePostingIterator::next (this=0x5630f066f380) at 
./src/engine/idtreedb.cpp:128
#10 0x7f966bfa9444 in Baloo::AndPostingIterator::next (this=0x5630f0662de0) 
at ./src/engine/andpostingiterator.cpp:42
#11 Baloo::AndPostingIterator::next (this=0x5630f0662de0) at 
./src/engine/andpostingiterator.cpp:45
#12 0x7f966c18c4c1 in ?? () from /usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5
#13 0x7f966c17b190 in Baloo::Query::exec() () from 
/usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5
#14 0x7f967332f519 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/baloosearch.so
#15 0x7f966e512f36 in KIO::SlaveBase::dispatch (this=0x7ffe684bffa0, 
command=71, data=...) at ./src/core/slavebase.cpp:1176
#16 0x7f966e513876 in KIO::SlaveBase::dispatchLoop (this=0x7ffe684bffa0) at 
./src/core/slavebase.cpp:325
#17 0x7f967332fd07 in kdemain () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/baloosearch.so
#18 0x5630f0593e1c in launch (argc=4, _name=0x5630f0641248 
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/baloosearch.so", args=, cwd=, envc=0, envs=, reset_env=false, 
tty=0x0, avoid_loops=false, startup_id_str=0x5630f0597187 "0") at 
./src/kdeinit/kinit.cpp:706
#19 0x5630f0594eea in handle_launcher_request (sock=8, who=) 
at ./src/kdeinit/kinit.cpp:1146
#20 0x5630f05958fb in handle_requests (waitForPid=0) at 
./src/kdeinit/kinit.cpp:1339
#21 0x5630f0590645 in main (argc=5, argv=) at 
./src/kdeinit/kinit.cpp:1785
[Inferior 1 (process 2571) detached]


-- System Information:
Debian Release: 10.0
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.68 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kinit depends on:
ii  kio  5.54.1-1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcap2-bin  1:2.25-2
ii  libkf5configcore55.54.0-1+deb10u1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5dbus5  5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libstdc++6   8.3.0-6
ii  libx11-6 2:1.6.7-1
ii  libxcb1  1.13.1-2

kinit recommends no packages.

kinit suggests no packages.

-- no debconf information

Bug#911844: Severity 911844 normal

[Nicholas D Steeves]

Hi Brian and Andrew,

On Mon, Apr 15, 2019 at 08:02:46PM +0100, Brian Potkin wrote:
> On Fri 05 Apr 2019 at 16:44:31 +0100, Brian Potkin wrote:
> 
> > On Sun 10 Mar 2019 at 14:09:27 +, Andrew M.A. Cater wrote:
> > 
> > > Severity 911844 normal
> > 
> > It would be useful to know the reason why the severity has been reduced
> > to normal. I would have thought a confidential document should not end
> > up on a machine it was not intended for.
>

My guess would be that it's because a work environment where with
multiple departments and printers should have its network partitioned
such that this type of confidentiality breach could not occur. eg: in
a workplace where confidentiality is important, systems from different
departments can only communicate to each other through restricted
channels, and cannot even ping each other--let alone each others'
printers.

> Being accorded the courtesy of a reply is not, it seems, on the horizon.
> And one wonders why Debian is sometimes not seen as an OS responsive to
> a reasonable request.
>

Debian is people, and most of us are volunteers.  I'm guessing Andrew
is busy with work, end of scholastic year, etc.  P.S. An alarmist tone
will not motivate anyone to fix a bug faster ;-)

> Never mind. If the intention is to dissuade from questioning, the lack
> of response has made its point. The motto appears to be - it's a secret:
> don't ask!

No, that's not true...  Debian is developed in the open.  Also, our
community is substantially more responsive to bug reports than those
from other three big free distributions.  It's one of the primary
reasons I chose to work on Debian vs alternatives :-)

Personally I think this is an important bug, but not because of
confidentiality.  Eg: If there is an expensive colour printer, and a
normal monochrome one, bulk jobs shouldn't randomly be routed to the
expensive printer when they are intended for the affordable one.  It's
a problem if a 200 page report is printed on a photo printer.  Thank
you for filing it, that's an important contribution imho.

Andrew, please comment soon.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#923663: partitionmanager: does not start, permission denied

[Nicholas D Steeves]

Strange, I expected this to fail on my system, but it works perfectly
here (squeeze->wheezy->jessie->buster), with kdesudo config purged.
It also worked without kdesudo purged.  I'm using the standard Xorg
session rather than Wayland, on an up-to-date buster system as of
Fri, 29 Mar 2019 21:27:51 -0400

The commands triggered by the menu entry are:

 7789 ?Sl 0:00 /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu -c 
KDE_FULL_SESSION=true XDG_RUNTIME_DIR=/run/user/1000 
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /usr/bin/partitionmanager 
--dontsu
 7793 pts/35   Ss+0:00 /usr/bin/sudo -u root 
/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu_stub -

If I were to guess, maybe the su support is broken but sudo support is
intact?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#919081: kio-gdrive: Unable to create io-slave. klauncher said: error loading gdrive.so

[Nicholas D Steeves]

Control: tags -1 unreproducible moreinfo
Control: severity -1 important

Hi Benoît!

On Sat, Jan 12, 2019 at 03:45:30PM +0100, Benoît Merlet wrote:
> 
> Dear Maintainer,
> 
> After installing kio-gdrive and configuring a Google account in 
> systemsettings5,
> I cannot connect to my Google Drive:
> 
> $ LANG=C kioclient5 exec gdrive:/
> kf5.kio.core: couldn't create slave: "klauncher said: Error loading « 
> /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/gdrive.so »."
> kf5.kio.widgets: KRun(0xa1c13a10) ERROR 173 "Unable to create io-slave. 
> klauncher said: Error loading « 
> /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/gdrive.so »."
> 
> I am not sure how to further debug the problem, but as you can see the
> package is quite unusable.
> 
> Best regards,
> Benoît
> 

I just did the following:

1. Installed buster
2. Logged in and installed kio-gdrive
3. Logged out and logged in again
4. Configured a Google user under "Online Accounts"
5. Opened dolphin -> Network -> Google Drive -> u...@gmail.com

Success.  See attached screenshot.  Because of this, I've downgraded
the severity of this bug to important, according to 
https://www.debian.org/Bugs/Developer#severities

This success was with en_CA.UTF-8.  I wonder if it's possible #915496
is contributing to the issue you're experiencing?  Would you please
confirm the following:

a) Have you tried logging out and logging back in?
b) Is kwallet enabled or disabled and/or was its configuration skipped?

Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#915496: kio-gdrive: missing translations [was Bug#915242: RFS: kio-gdrive/1.2.5-1]

[Nicholas D Steeves]

Alternatively I could diff the existing orig tarball against the one
upstream intended for release, carry it as a temporary quilt patch,
and that could become 1.2.5-2.


signature.asc
Description: PGP signature

Bug#915496: kio-gdrive: missing translations [was Bug#915242: RFS: kio-gdrive/1.2.5-1]

[Nicholas D Steeves]

Hi Luigi,

On Tue, Dec 04, 2018 at 10:46:41AM +0100, Luigi Toscano wrote:
> On Tue, 4 Dec 2018 00:21:43 -0500 Nicholas D Steeves  
> wrote:
> 
> > 
> > Sorry, I didn't notice that the non-English HTML docs had been dropped
> > while the English ones remained...thank you for holding me
> > accountable!  Restoring non-English support is definitely something I
> > will prioritise, but sadly very little free time at the moment, so
> > please ping me if I seem to be taking too long.
> 
> It's not an upstream issue: the orig tarballs used for this package is not
> the tarball available on download.kde.org, which contains all the
> translations:
> https://download.kde.org/stable/kio-gdrive/1.2.5/src/
> 
> I suspect that the orig tarball was generated from the git tag - if it's the
> case, please never use do that. Translations of projects by KDE are injected
> in the tarballs when they are created.

sha256sum of upstream released tarball:
1523c87f3f679cecbef0a2158a133f84379a0b276000c0233c34041b9c14d605  
kio-gdrive-1.2.5.tar.xz

sha256sum of the orig tarball for my upload:
41b836e268131dcb7e63ca5241fcc57b6c15fbcf0b72f7b65c44adbe9f8b8a9b  
kio-gdrive_1.2.5.orig.tar.xz

Indeed, this was my mistake.  Sorry, I'm still struggling with
adapting to building from a packaging-only git repository--cherry
picking and rebasing patches is particularly awkward.  I also failed
to notice that gbp generated the orig tarball from the upstream tag
instead of from the uscan downloaded tarball.  I've made the necessary
changes in my devel repo to insure this won't happen again.

Is this a case where the fix is an upload of 1.2.5.1~really1.2.5-1,
where the new orig tarball will have a version of
'1.2.5.1~really1.2.5', and which a hypothetical 1.2.5.1-1 will
necessarily supersede (next release will probably be 1.2.6)?  I've
confirmed everything is as it should be when upstream release tarball
with injected translations is used.


Thank you!
Nicholas

P.S. I thought those post-tag autogenerated KDE translation commits
were strange...now I know why...thank you for sharing this info, I
didn't realise KDE project tags were non-authoritative milestones on
a devel branch rather than releases.


signature.asc
Description: PGP signature

Bug#915496: kio-gdrive: missing translations [was Bug#915242: RFS: kio-gdrive/1.2.5-1]

[Nicholas D Steeves]

Package: kio-gdrive
Version: 1.2.5-1

Dear Adam and QT/KDE Team,

On Sun, Dec 02, 2018 at 02:03:04AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the sponsorship-requests package:
[snip]
>
> > kio-gdrive (1.2.5-1) unstable; urgency=medium
> >
> >   * New upstream version.
> >   * Drop patches that were merged into this upstream release:
> > - 0001-appstream-don-t-use-hyphen-in-the-component-id.patch
> > - 0002-Add-screenshot-to-gdrive.appdata.xml.patch
> >   * debian/copyright: Update Elvis Angelaccio's email address to reflect
> > updates that were made upstream.
>
> Uploaded.

Thank you for sponsoring :-)

> Note that this version drops all translations: both docs and messages.
> As the change comes from the upstream tarball, I assumed this is intentional
> -- if it's not, please bring us a fixed version.

I might have to file an upstream issue about this, and have opened
this tracking/reminder bug in the meantime.  I assumed that the
following (from the build log) indicated translations were
coalesced into a single file during the build:

  -- Found Intltool: /usr/bin/intltool-extract (found version "0.51.0")
  Merging translations into 
/<>/obj-x86_64-linux-gnu/kaccounts/google-drive.service.
  CREATED /<>/obj-x86_64-linux-gnu/kaccounts/google-drive.service

but that doesn't account for the missing 
/usr/share/doc/HTML/$LANG/kioslave5/gdrive/*

Sorry, I didn't notice that the non-English HTML docs had been dropped
while the English ones remained...thank you for holding me
accountable!  Restoring non-English support is definitely something I
will prioritise, but sadly very little free time at the moment, so
please ping me if I seem to be taking too long.


Sincerely,
Nicholas


signature.asc
Description: PGP signature

bogus or real appstream error on appstream.debian.org?

[Nicholas D Steeves]

Hi,

I'm not sure whether or not the following is a real issue:
https://appstream.debian.org/sid/main/issues/kio-gdrive.html

Has anyone encountered an appstream "missing-desktop-file" before?
From what I can tell the following is due to kio-gdrive's ID being
different than gdrive-network.desktop (upstream issue from what I can
tell)

Please advise how to proceed and I'll fix it for the next upload (New
upstream release).

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#877807: kdeconnectd is not listen port using IPV4

[Nicholas D Steeves]

Dear Rabia,

On Thu, Oct 05, 2017 at 11:06:18PM +0200, Rabia Chebah wrote:
> Package: kdeconnect
> Version: 1.0.1-1+b2
> Severity: important
> 
> Dear Maintainer,
> 
> The kdeconnectd port is listening only in IPV6. Please add the support for 
> IPV4 also well.
> Olds Android phones are still using IPV4. 
> 
> Many thanks !
> 
> -- System Information:
> Debian Release: 9.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

Thank you for taking the time to file this report!

Here is a thread of found which sounds similar similar to issue you've
reported:
https://www.mail-archive.com/kde-bugs-dist@kde.org/msg103840.html

Lisandro, it might be appropriate to mark this bug as forwarded to
the following URL:
https://bugs.kde.org/show_bug.cgi?id=371539

Cheers,
Nicholas

Bug#841762: kdeconnectd dies as soon as mobile device tries to connect

[Nicholas D Steeves]

Dear Peter,

On Sun, Oct 23, 2016 at 11:58:00AM +0200, Peter Marschall wrote:
> Package: kdeconnect
> Version: 1.0.1-1
> Severity: important
> 
> Hi,
> 
> I have installed the current kdeconnect app from the Google Play Store
> and current kdeconnect on my computers
> However I am not able to get a connection between mobile and computers.
> 
> The issue appeared with kdeconnect 1.0.1-1 on all my computers.
> With the previous version 0.9g-1, I was able to get a connection.
> 
> Actions tried:
> - upgrade KDE / QT apps & libs from testing to unstable -> no change
> - stop of firewall -> no change
> - removal of kdeconnect config below ~/.kde/ and ~/.config/ -> no change
> - restart of machine -> no change
> 
> Starting /usr/lib/x86_64-linux-gnu/libexec/kdeconnectd manually after a
> crash
> yields this output:
> 
>   kdeconnect.core: KdeConnect daemon starting
>   kdeconnect.core: onStart
>   kdeconnect.core: KdeConnect daemon started
>   kdeconnect.core: Preventing duplicate broadcasts
>   kdeconnect.core: Broadcasting identity packet
>   kdeconnect.core: Fallback (1), try reverse connection (send udp
> packet)
>   "Network unreachable"
>   KCrash: crashing... crashRecursionCounter = 2
>   KCrash: Application Name = kdeconnectd path =
>   /usr/lib/x86_64-linux-gnu/libexec pid = 4589
>   KCrash: Arguments: /usr/lib/x86_64-linux-gnu/libexec/kdeconnectd 
>   KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
>   from kdeinit
>   sock_file=/run/user/1000/kdeinit5__0
> 
>   [1]+  Stopped/usr/lib/x86_64-linux-gnu/libexec/kdeconnectd
> 
> Kcrash report attached
> 
> 
> Thanks for KDE in Debian
> Peter

Are you able to confirm if this bug is present in Stretch
(kdeconnect/1.0.1-1+b2)?  Failing that, is it present in whatever
version you are now using (presumably 1.3.1-1 if tracking sid).

Thanks!
Nicholas


signature.asc
Description: PGP signature

Bug#824970: "Send file via KDE Connect service" does not appear on file context menu despite being enabled in dolphin

[Nicholas D Steeves]

Control: fixed -1 kdeconnect/1.0.3-1

Hi Lisandro,

On Sat, May 21, 2016 at 08:06:30PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Package: kdeconnect
> Version: 0.9g-1
> Severity: normal
> Tags: upstream patch
> Forwarded: https://bugs.kde.org/show_bug.cgi?id=362684
> 
> Please see the upstream bug report.
> 

If I had to guess I'd guess that this bug was fixed in either
kdeconnect/1.0.1-1, 1.0.1-1+b2, or 1.0.3-1.  In particular it would be
good to know if it was fixed in 1.0.1-1+b2 (version in Stretch),
because if not then the fix should be cherry picked from 1.0.3-1.  My
Stretch system is using a local backport of 1.0.3-1, which I can
confirm has a working "Send to 'device name' via KDE Connect".

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#900710: very out of date manpage

[Nicholas D Steeves]

Control: owner -1 !

On Mon, Jun 04, 2018 at 12:08:44AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
>El dom., 3 de jun. de 2018 17:21, Nicholas D Steeves
><[1]nstee...@gmail.com> escribió:
> 
>  Package: kdeconnect
>  Version: 1.3.1-1
>  Severity: normal
> 
>  Hi,
> 
>  It seems debian/kdeconnect-cli.1 hasn't been updated since 2014-07-01.
>  I can confirm that the manpage definitely does not reflect the output
>  of 'kdeconnect-cli --help'.  If upstream does not yet provide a
>  mechanism to generate a manpage from the same source as
>  'kdeconnect-cli --help' then we should either ask for this
>  functionality or provide a patch.
> 
>  Feel free to set me as the owner of this bug if you'd like me to take
>  care of it.
> 
>Just go ahead ;-)

Ok, I've added this bug to my queue :-) If upstream doesn't generate
localised manpages.  Do you know of a HOWTO-format (or Debian)
document about doing this?  So far the best I've been able to find is
the documentation that comes with po4a, but it's going to take me a
while to get up to speed...

Thanks!
Nicholas


signature.asc
Description: PGP signature

Bug#900710: very out of date manpage

[Nicholas D Steeves]

Package: kdeconnect
Version: 1.3.1-1
Severity: normal

Hi,

It seems debian/kdeconnect-cli.1 hasn't been updated since 2014-07-01.
I can confirm that the manpage definitely does not reflect the output
of 'kdeconnect-cli --help'.  If upstream does not yet provide a
mechanism to generate a manpage from the same source as
'kdeconnect-cli --help' then we should either ask for this
functionality or provide a patch.

Feel free to set me as the owner of this bug if you'd like me to take
care of it.

Cheers!
Nicholas

Bug#895706: Please add the full GPL-3 COPYING text for Valama's cmake module

[Nicholas D Steeves]

Package: kio-gdrive
Version: 1.2.2-1
Severity: normal
Tags: upstream

Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=393148

This bug tracks the upstream status of Scott K's (FTP Master) request
for full license text for a GPL-3 cmake module in kio-gdrive's GPL-2
source package.

Bug#876415: Bugfix release v1.2.1

[Nicholas D Steeves]

Control: fixed -1 kdeconnect/1.3.0-1


signature.asc
Description: PGP signature

Bug#879901: kded5 mem ballooning consumes over 6520.81MB of RAM!

[Nicholas D Steeves]

Package: kded5
Version: 5.28.0-1
Followup-For: Bug #879901
Control: severity -1 grave

Raising severity because 6520.81MB is enough to make the OOM killer
kill a browser on a laptop with less than 8GB of RAM, when the user is
running without swap (possibly also with zswap) because he/she is
using an SSD, or to make the system swap so hard that it becomes
unusable.  Please see #879898 for Simon McVittie's analysis about how
this issue also causes the user's session's dbus-daemon memory to also
balloon.

Please let me know what I can do to help debug this further, because
I'd like to help solve this asap.  This time I triggered the issue on
my desktop.  Please note that while my desktop is running a custom
kernel, my laptop is running linux-4.9 shipped in Debian Stretch.  I'm
sticking with 4.4 on my Desktop, because linux-4.9 has a couple of
btrfs regressions that haven't yet been patched...I don't take risks
with my primary system.

Relevant output from top:
19242 sten  20   0 6916852 5.320g956 S   0.0 36.5   6:12.07 kded5
 2673 sten  20   0 2029908 1.584g264 S   0.0 10.9   4:38.57 dbus-daemon

Full backtrace is attached, created with:
file /usr/bin/kded5
thread apply all backtrace no-filters full


Sincerely,
Nicholas

-- System Information:
Debian Release: 9.1
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.102.20171125 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kded5 depends on:
ii  libc6  2.24-11+deb9u1
ii  libkf5configcore5  5.28.0-2
ii  libkf5coreaddons5  5.28.0-2
ii  libkf5crash5   5.28.0-1
ii  libkf5dbusaddons5  5.28.0-1
ii  libkf5service-bin  5.28.0-1
ii  libkf5service5 5.28.0-1
ii  libqt5core5a   5.7.1+dfsg-3+b1
ii  libqt5dbus55.7.1+dfsg-3+b1
ii  libqt5gui5 5.7.1+dfsg-3+b1
ii  libqt5widgets5 5.7.1+dfsg-3+b1
ii  libstdc++6 6.3.0-18

kded5 recommends no packages.

kded5 suggests no packages.

-- no debconf information

Reading symbols from /usr/bin/kded5...Reading symbols from 
/usr/lib/debug/.build-id/dc/e41958ff786e956693484065979e08e08734c2.debug...done.
done.
Attaching to program: /usr/bin/kded5, process 19242
[New LWP 19243]
[New LWP 19244]
[New LWP 19249]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38  ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory.

Thread 4 (Thread 0x7f7fde833700 (LWP 19249)):
#0  0x7f8000f827d7 in bind () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1  0x7f8000f9b7bf in __netlink_open (h=h@entry=0x7f7fde831cc0)
at ../sysdeps/unix/sysv/linux/ifaddrs.c:264
nladdr = {nl_family = 16, nl_pad = 0, nl_pid = 0, nl_groups = 0}
addr_len = 3733134480
#2  0x7f8000f9b867 in getifaddrs_internal (ifap=ifap@entry=0x7f7fde831d88)
at ../sysdeps/unix/sysv/linux/ifaddrs.c:332
nh = {fd = 14, pid = 0, seq = 0, nlm_list = 0x0, end_ptr = 0x0}
nlp = 
ifas = 
i = 
newlink = 
newaddr = 
newaddr_idx = 
map_newlink_data = 
ifa_data_size = 0
ifa_data_ptr = 
result = 0
__PRETTY_FUNCTION__ = "getifaddrs_internal"
#3  0x7f8000f9c510 in __getifaddrs (ifap=0x7f7fde831d88) at 
../sysdeps/unix/sysv/linux/ifaddrs.c:831
res = 0
#4  0x7f7ff0d158bb in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Network.so.5
No symbol table info available.
#5  0x7f7ff0d10975 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Network.so.5
No symbol table info available.
#6  0x7f7ff0d11445 in QNetworkInterface::allInterfaces() ()
   from /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
No symbol table info available.
#7  0x7f800148e9a6 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/bearer/libqgenericbearer.so
No symbol table info available.
#8  0x7f7fff4ffb2e in QMetaMethod::invoke (this=this@entry=0x7f7fde832398, 
object=object@entry=
0x55bd466827b0, connectionType=Qt::DirectConnection, 
connectionType@entry=3733136416, 
returnValue=..., val0=..., val1=..., val2=..., val3=..., val4=..., 
val5=..., val6=..., val7=..., 
val8=..., val9=...) at kernel/qmetaobject.cpp:
typeNames = {0x0 }
paramCount = 
currentThread = 0x55bd466706a0
objectThread = 0x55bd466706a0
param = {0x0 }
idx_offset = 10
callFunction = 0x7f8001499a60
#9  0x7f7fff50558a in QMetaObject::invokeMethod (obj=0x55bd466827b0, 
member=0x7f7ff0d77d71 "requestUpdate", type=3733136416, ret=..., val0=..., 
val1=..., val2=..., 
val3=..., val4=..., val5=..., val6=..., val7=..., val8=..., val9=...) at 

Bug#866996: kde-style-breeze: [fixed upstream] dark themes lowlight active tab instead of highlighting

[Nicholas D Steeves]

Control: affects -1 kwin-style-breeze
Control: tags -1 patch

Attached are patches for the Debian packaging.  I've have tested them
with both light and dark themes and can confirm that it closes this
bug.

Also, I've marked this bug as also affecting kwin-style-breeze because
this patch has another very welcome effect!  It fixes annoying
behaviour where the active window title bar is lowlighted and all
inactive windows are highlighted; I can imagine would be really
annoying for people who do window management with a mouse rather than
keyboard.

Cheers,
Nicholas
From 1a215d224f280e5ee374455d496296c9cb062993 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves <nstee...@gmail.com>
Date: Tue, 4 Jul 2017 19:43:51 -0400
Subject: [PATCH 1/2] Import upstream patch that fixes highlighting of active
 tab (Closes: #866996)

---
 ...e-Shadow-instead-of-QPalette-Text-to-dark.patch | 22 ++
 debian/patches/series  |  1 +
 2 files changed, 23 insertions(+)
 create mode 100644 debian/patches/0001-Use-QPalette-Shadow-instead-of-QPalette-Text-to-dark.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/0001-Use-QPalette-Shadow-instead-of-QPalette-Text-to-dark.patch b/debian/patches/0001-Use-QPalette-Shadow-instead-of-QPalette-Text-to-dark.patch
new file mode 100644
index 000..3dc2ce6
--- /dev/null
+++ b/debian/patches/0001-Use-QPalette-Shadow-instead-of-QPalette-Text-to-dark.patch
@@ -0,0 +1,22 @@
+From: Hugo Pereira Da Costa <hugo.pereira.da.co...@gmail.com>
+Date: Tue, 21 Feb 2017 10:30:18 +0100
+Subject: Use QPalette::Shadow instead of QPalette::Text to darken inactive
+ tabs BUG:373088
+
+---
+ kstyle/breezestyle.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kstyle/breezestyle.cpp b/kstyle/breezestyle.cpp
+index d3f6d46..b687c3f 100644
+--- a/kstyle/breezestyle.cpp
 b/kstyle/breezestyle.cpp
+@@ -5549,7 +5549,7 @@ namespace Breeze
+ 
+ } else {
+ 
+-const QColor normal( _helper->alphaColor( palette.color( QPalette::WindowText ), 0.2 ) );
++const QColor normal( _helper->alphaColor( palette.color( QPalette::Shadow ), 0.2 ) );
+ const QColor hover( _helper->alphaColor( _helper->hoverColor( palette ), 0.2 ) );
+ if( animated ) color = KColorUtils::mix( normal, hover, opacity );
+ else if( mouseOver ) color = hover;
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..0d04457
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-Use-QPalette-Shadow-instead-of-QPalette-Text-to-dark.patch
-- 
2.11.0

From a773e69bd8fd98595d99e354739fe65ef3c7a69f Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves <nstee...@gmail.com>
Date: Tue, 4 Jul 2017 19:45:42 -0400
Subject: [PATCH 2/2] Update changelog

---
 debian/changelog | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index a0df2f7..5885074 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+breeze (4:5.8.5-2+debu9u1) UNRELEASED; urgency=medium
+
+  [ Nicholas D Steeves ]
+  * Import upstream patch that fixes highlighting of active tab. (Closes:
+    #866996)
+
+ -- Nicholas D Steeves <nstee...@gmail.com>  Tue, 04 Jul 2017 19:44:41 -0400
+
 breeze (4:5.8.5-2) unstable; urgency=medium
 
   * Release to unstable.
-- 
2.11.0



signature.asc
Description: Digital signature

Bug#866996: kde-style-breeze: [fixed upstream] dark themes lowlight active tab instead of highlighting

[Nicholas D Steeves]

Package: kde-style-breeze
Version: 4:5.8.5-2
Severity: normal
Tags: upstream fixed-upstream
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=373088

Steps to reproduce: Install or upgrade to KDE5, enable dark theme,
suffer cognitive dissonance as all tabs appear to be active with the
exception of the tab that is actually active.  Konsole is a perfect
example.

The fix a single line patch, but this problem is annoying enough that
I am considering giving up Konsole!

The commit to cherry pick from upstream's breeze.git is:
13c049c6fba95cf58de9bcc3f61df56153b7c54f

https://cgit.kde.org/breeze.git/commit/?id=13c049c6fba95cf58de9bcc3f61df56153b7c54f

Sincerely,
Nicholas

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kde-style-breeze depends on:
ii  libc6 2.24-11+deb9u1
ii  libkf5configcore5 5.28.0-2
ii  libkf5configgui5  5.28.0-2
ii  libkf5configwidgets5  5.28.0-2
ii  libkf5coreaddons5 5.28.0-2
ii  libkf5guiaddons5  5.28.0-1
ii  libkf5i18n5   5.28.0-2
ii  libkf5style5  5.28.0-1
ii  libkf5windowsystem5   5.28.0-2
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5dbus5   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libqt5x11extras5  5.7.1~20161021-2
ii  libstdc++66.3.0-18
ii  libxcb1   1.12-1

kde-style-breeze recommends no packages.

kde-style-breeze suggests no packages.

-- no debconf information

Bug#858749: Default of "Apply colors to non-Qt applications" causes invisible text

[Nicholas D Steeves]

Package: libkf5style5
Version: 5.28.0-1
Control: affects -1 kde-style-breeze emacs inkscape x11-apps

Dear KDE Team,

Thank you for your hard work.  I hope that I'm filing this against the
right package...  It might actually be Qt problem.

Steps to reproduce invisible text, from a fresh Stretch installation
where KDE is installed

1. Go to Look and Feel.
2. Select Breeze Dark or Breeze High Contrast (or Breeze light for Inkscape)
3. Black on black text in emacs modeline, even when running in
konsole, without any .emacs.el or .emacs.d/* configuration.
4. Green on green text in tooltips from menubar in Inkscape (This was
tested with Breeze (light, not dark).
5. Almost illegible black on dark grey xclock.

Hypothesis: KDE is using a method similar to Xresources to apply
colour scheme without testing for combinations which will produce
illegible text.

Workaround: go to System Settings -> colors -> uncheck apply colors to
non-Qt applications; then make sure that kde-config-gtk-style and
gtk3-engines-breeze are installed; go to System Settings -> GNOME
Application Style (GTK) and insure that Breeze Dark is selected
wherever possible.

Caveat: With this workaround Tk and other toolkits will look out of place

Conclusion: If it is not possible to fix libkf5style5,
kde-style-breeze, or Qt, please disable "apply colors to non-Qt
applications", and use kde-config-gtk-style and gtk3-engines-breeze
for continuity between GTK and KDE applications.

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Re: Plasma 5.8 LTS in debian 9(Stretch)

[Nicholas D Steeves]

On 4 October 2016 at 16:40, Simon Quigley  wrote:
> On 10/04/2016 03:16 PM, Bradley Robert Baago wrote:
>> Hello,
>>
>> Quick question. Will the new plasma LTS release make it into the next stable?
>> I think it would be a mistake if it did not.
>>
> Looping in the related people.
>
> AFAIR from discussions on IRC, yes.
>

Yay! :-D  I've also been wondering this.  Are there any relevant
trackers/pages in addition to the following:

http://pkg-kde.alioth.debian.org/ (unmaintained?)
https://qa.debian.org/developer.php?login=debian-qt-kde@lists.debian.org
https://qa.debian.org/developer.php?login=pkg-kde-ext...@lists.alioth.debian.org

Cheers,
Nicholas