Bug#1070638: kde-spectacle: Build-depends on NBS libkcolorpicker-dev

[Scott Kitterman]

On Mon, 06 May 2024 10:33:54 -0400 Scott Kitterman  
wrote:
> Source: kde-spectacle
> Version: 22.12.3-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the 
past)
> 
> Once kcolorpicker is decrufted, this package will FTBFS.  Please update
> your build-depends.

Also libkimageannotator-dev needs updating.

Scott K

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

Bug#1070638: kde-spectacle: Build-depends on NBS libkcolorpicker-dev

[Scott Kitterman]

Source: kde-spectacle
Version: 22.12.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Once kcolorpicker is decrufted, this package will FTBFS.  Please update
your build-depends.

Scott K

Comments regarding flatpak-kcm_5.26.90-1_amd64.changes

[Scott Kitterman]

This is only a minor point, so I'm going to accept the package, but please
fix in your next upload.  In you build-depends for the package you have:

cmake (>= 3.16~)

That version constraint is satisfied in the current stable release, so there
is no need to specify it.  It (slightly) complicates apt's dependency
resolution process, so it's better to remove it when not needed.

Scott K

Re: okular_22.12.0-1_source.changes REJECTED

[Scott Kitterman]

On December 12, 2022 7:41:42 AM UTC, "Aurélien COUDERC"  
wrote:
>Dear FTP Masters,
>
>Le lundi 12 décembre 2022, 00:46:08 CET Debian FTP Masters a écrit :
>> 
>> okular source: lintian output: 'source-contains-prebuilt-ms-help-file 
>> generators/chm/autotests/data/test.chm', automatically rejected package.
>> okular source: If you have a good reason, you may override this lintian tag.
>
>I don’t understand this rejection.
>
>Okular has an appropriate lintian override that correctly gets picked up
>during local sbuild.
>This override was already present for the previous upload.
>
>The file detected by lintian is a test payload so I think it’s acceptable to
>override the lintian error in this situation.
>
First thing I would check is to verify the override is detected by the version 
of lintian in Stable.  That's the version that's used for this check.

Scott K

Bug#981515: kcoreaddons: please replace fam with gamin

[Scott Kitterman]

> Hi,
> 
> In data venerdì 20 agosto 2021 13:32:08 CEST, Chris Hofstaedtler ha scritto:
> > given we are now in the bookworm cycle - do you think kcoreaddons
> > could remove fam (or replace it with gamin if really needed)?
> 
> As I wrote a couple of times in this bug already: #510368 must be fixed
> first. It seems like I forgot to set this dependency, so I'm adding it
> now.
> 
> Also, considering that there is a huge queue of RM bugs on the
> FTP-masters side that have been attended so far a couple of times in
> this year (sigh), rushing this won't make any change, since the RM will
> be ignored for some time anyway.
> Also #2: considering that we are not even a week since the lift of the
> freeze and everybody and their dogs have already uploaded things of
> every sort of unstable, please give (me) some time for what is really
> not a priority.

FTP team is caught up on removals.  kcoreaddons is the last package keeping 
fam in the archive, so I would appreciate it if this could be resolved so we 
can just get rid of it.

Scott K

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

Comments regarding plasma-thunderbolt_5.17.5-1_amd64.changes

[Scott Kitterman]

It's not something worth rejecting the package over, so I won't, but the
package description is really short.  Please consider if there is more
information worth adding in a future upload.

Scott K

syndication_5.62.0-2_amd64.changes REJECTED

[Scott Kitterman]

Uploader request.

Scott K
 



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Comments regarding md4c_0.2.7+git17-gb9fcd47-1_amd64.changes

[Scott Kitterman]

Please note that md2html/cmdline.{c,h} are not listed in d/copyright and are
not under the Expat license.  Since there's no license violation for it being
missing, I'm going to go ahead and accept the package, but please clarify in
your next upload.

Scott K

Re: Security vulnerability in .desktop files

[Scott Kitterman]

On Thursday, August 8, 2019 5:19:51 AM EDT Oleg K. wrote:
> Hello, All.
> 
> I'm just a linux user  and do not know in details the support process in
> Debian and KDE teams.
> What can you say about .desktop arbitrary code execution when user opens a
> folder with "bad" file, which is found here -
> https://twitter.com/zer0pwn/status/1158433002239746048 ?
> What ticket should I follow and wait for being fixed ?
> 
> With Best Regards,
> Oleg K.

Updated packages have been released now, so it should be simply a matter of 
applying available updates.

Scott K

Bug#933278: kmail: Kmail printing Mails prints blank pages

[Scott Kitterman]

On July 28, 2019 6:00:28 PM UTC, "Michael Müller"  wrote:
>Package: kmail
>Version: 4:18.08.3-1
>Severity: normal
>
>Dear Maintainer,
>
>when printing mails, kmail only prints blank pages, also when printing
>to PDF or in the pre-view.
>
I have run into this problem too, but I hadn't gotten around to filing a bug.

Scott K


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

Bug#927940: [Windows Subsystem for Linux] Applications cannot find libQt5Core.so.5

[Scott Kitterman]

On April 26, 2019 2:10:36 AM UTC, Ryo IGARASHI  wrote:
>Hi, Bernhard,
>
>Thank you for the workaround. Now that I can launch QT application on
>my machine.
>
>As this issue only affects WSL environment, I don't think this is an
>RC bug, but I will
>let the maintainers set the proper severities.
>
>Maybe do we need a comment about this issue on the buster release
>notes?
>
>2019年4月26日(金) 1:37 Bernhard Übelacker :
>>
>> Control: retitle 927940 [Windows Subsystem for Linux] Applications
>cannot find libQt5Core.so.5

This isn't a Qt5 bug at all.  If you try and link Qt5 in a Sid chroot on an old 
enough Debian version, the same thing happens because of missing kernel 
functions.  It's a host kernel issue.

Since the kernel in this instance isn't Debian's I don't think it's a Debian 
bug either.

I'm not one of the Qt maintainers, so I'm not going to change the status of the 
bug, but I think the correct thing to do is to close it.  No Debian issue here.

Scott K

Bug#915319: Further triaging

[Scott Kitterman]

On March 30, 2019 6:10:40 PM UTC, Giovanni Mascellani  wrote:
>user debian-rele...@lists.debian.org
>
>usertags 915319 + bsp-2019-03-fr-paris
>tags 915319 + patch
>thank you
>
>Hi,
>
>I did some further diagnosis on this bug: the reason why CMake fails to
>discover libsmbclient is because CMake tries to compile a little
>program
>including libsmbclient.h using -std=c90, which is insufficient for
>libsmbclient.h. However libsmbclient.h works with more recent C
>standards, like the GCC default -std=gnu11.
>
>The attached patch should fix the problem. I can NMU if this is ok for
>you. Probably it is not the cleanest solution ever (if would be better
>to fix CMake files from kdelibs5-dev), but it seems to work.
>
>Thanks, Giovanni.


Is there anything left in the archive that uses this functionality?

Scott K

Bug#922000: src:kauth: Symbols file out of date

[Scott Kitterman]

Package: src:kauth
Version: 5.54.0-1
Severity: normal

Seen in the amd64 build logs for 5.54.0-1:

dpkg-gensymbols: warning: some libraries disappeared in the symbols file: 
kauth_backend_plugin.so kauth_helper_plugin.so
dpkg-gensymbols: warning: debian/libkf5auth5/DEBIAN/symbols doesn't match 
completely debian/libkf5auth5.symbols
--- debian/libkf5auth5.symbols (libkf5auth5_5.54.0-1_amd64)
+++ dpkg-gensymbolsUUn6iW   2019-01-18 12:55:12.883857964 +
@@ -1,9 +1,3 @@
-kauth_backend_plugin.so libkf5auth5 #MINVER#
- qt_plugin_instance@Base 5.0.0
- qt_plugin_query_metadata@Base 5.0.0
-kauth_helper_plugin.so libkf5auth5 #MINVER#
- qt_plugin_instance@Base 5.0.0
- qt_plugin_query_metadata@Base 5.0.0
 libKF5Auth.so.5 libkf5auth5 #MINVER#
  _ZN5KAuth10ExecuteJob11qt_metacallEN11QMetaObject4CallEiPPv@Base 4.96.0
  _ZN5KAuth10ExecuteJob11qt_metacastEPKc@Base 4.96.0

It seems like it should be updated, but I'm not sure the correct solution, so
not touching it for the security update.

Scott K

Bug#921995: kauth: Insecure handling of arguments in helpers

[Scott Kitterman]

Package: src:kauth
Version: 5.28.0-2
Severity: grave
Tags: security upstream patch
Justification: user security hole

See the KDE announce list [1].  It includes reference to a fix [2].  This is
CVE-2019-7443.

Scott K


[1] https://mail.kde.org/pipermail/kde-announce/2019-February/11.html
[2] 
https://cgit.kde.org/kauth.git/commit/?id=fc70fb0161c1b9144d26389434d34dd135cd3f4a

Bug#905697: Info received (Bug#905697: kdepimlibs: don't depend on libical)

[Scott Kitterman]

I think the only API change that's relevant might be:

is_utc to icaltime_is_utc() in icaltimetype

For anyonne with a non-trivial C++ knowledge (i.e. not me), I suspect this 
wouldn't be too hard.

Scott K

Bug#905697: kdepimlibs: don't depend on libical

[Scott Kitterman]

What about porting it to libical3?  That might be easier.  I tried to build it 
and it does need some changes, but I don't think keeping libical2 is feasible.  
See the attached for the error.

Scott K

On Friday, February 08, 2019 10:46:21 PM Sandro Knauß wrote:
> Hey,
> 
> for me it looks like we won't be able to get kdepimlibs without libical 2
> for buster.
> Keep in mind, that kdepimlibs is an old grufted lib set that we also would
> like to kill. But we also have other packages depending on it like:
> * basket
> * kopete (it has a QT5 version in experimental, but this is suitable as
> replacement yet).
>  and other that may can be killed.
> 
> extract libical 2 out of kdepimlibs is not that simple, as the whole
> interface will leak into akonadi-calendar, calcore, calutils,...
> 
> In short I won't have the time to do the work and test it in the near
> future.
> 
> I added pino to this bug report, as pino successfully extracted other parts
> of old kdelibs/kdepimlibs.
> 
> hefee
> 
> --
> 
> On Donnerstag, 17. Januar 2019 12:11:46 CET Emilio Pozuelo Monfort wrote:
> > On 11/01/2019 13:37, Emilio Pozuelo Monfort wrote:
> > > On 08/08/2018 10:38, Emilio Pozuelo Monfort wrote:
> > >> Source: kdepimlibs
> > >> Version: 4:4.14.10-10
> > >> Severity: serious
> > >> Control: block 884128 with -1
> > >> 
> > >> Hi,
> > >> 
> > >> libical2 from src:libical is superseded by libical3 (src:libical3).
> > >> 
> > >> Please either port kdepimlibs to libical3 or try to disable the
> > >> libical support, so that we can only ship src:libical3 in buster.
> > > 
> > > Could someone who knows kdepimlibs take a look at this? Can we disable
> > > libical support in kdepimlibs for buster? This is the last blocker for
> > > the libical 2 removal.
> > 
> > Hi Sandro,
> > 
> > Lisandro said you may be able to help with this. Do you know if libical
> > support could be disabled in kdepimlibs, or if the newer version libical3
> > could be used?
> > 
> > >From [1] it seems that libical is kind of optional, though I don't know
> > >if
> > >we
> > 
> > can disable the bits to drop that or if those bits have rdeps. Since
> > kdepimlibs is the last rdep of the old libical version, fixing this would
> > allow us to drop that one from buster. Otherwise the RC bugs that it has
> > will need to be fixed and we'll have to ship with two versions of the
> > library.
> > 
> > Thanks,
> > Emilio
> > 
> > [1]
> > https://sources.debian.org/src/kdepimlibs/4:4.14.10-10/CMakeLists.txt/#L81
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp: In static member function 
'static icaltimetype KCalCore::ICalFormatImpl::writeICalDate(const QDate&)':
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp:2304:7: error: 
'icaltimetype' {aka 'struct icaltimetype'} has no member named 'is_utc'; did 
you mean 'is_date'?
 t.is_utc = 0;
   ^~
   is_date
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp: In static member function 
'static icaltimetype KCalCore::ICalFormatImpl::writeICalDateTime(const 
KDateTime&)':
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp:2326:7: error: 
'icaltimetype' {aka 'struct icaltimetype'} has no member named 'is_utc'; did 
you mean 'is_date'?
 t.is_utc = datetime.isUtc() ? 1 : 0;
   ^~
   is_date
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp: In static member function 
'static icalproperty* 
KCalCore::ICalFormatImpl::writeICalDateTimeProperty(icalproperty_kind, const 
KDateTime&, KCalCore::ICalTimeZones*, KCalCore::ICalTimeZones*)':
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp:2401:12: error: 
'icaltimetype' {aka 'struct icaltimetype'} has no member named 'is_utc'; did 
you mean 'is_date'?
 if (!t.is_utc) {
^~
is_date
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp: In static member function 
'static KDateTime KCalCore::ICalFormatImpl::readICalDateTime(icalproperty*, 
const icaltimetype&, KCalCore::ICalTimeZones*, bool)':
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp:2434:11: error: 'const 
icaltimetype' {aka 'const struct icaltimetype'} has no member named 'is_utc'; 
did you mean 'is_date'?
 if (t.is_utc  ||  t.zone == icaltimezone_get_utc_timezone()) {
   ^~
   is_date

Re: Bug#784479: [kde4libs] Qt4's WebKit removal

[Scott Kitterman]

On Tuesday, January 15, 2019 11:03:33 AM Scott Kitterman wrote:
> On January 15, 2019 7:17:36 AM UTC, Pino Toscano  wrote:
> >In data lunedì 14 gennaio 2019 12:22:52 CET, Scott Kitterman ha
> >
> >scritto:
> >> On Thu, 01 Nov 2018 14:04:12 -0300 Lisandro
> >> =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer
> >
> > wrote:
> >> > On Wed, 17 Oct 2018 15:57:25 +0200 Ivo De Decker 
> >
> >wrote:
> >> > > Hi,
> >> > > 
> >> > > On Fri, Nov 24, 2017 at 04:59:58PM -0300, Lisandro Damián Nicanor
> >
> >Pérez
> >
> >> > Meyer wrote:
> >> > > > Control: tag -1 patch
> >> > > > 
> >> > > > There is patch available for this at
> >> 
> >> <https://git.archlinux.org/svntogit/
> >
> >packages.git/tree/trunk/kdelibs-no-kdewebkit.patch?h=packages/kdelibs>
> >
> >> > > > We might want to wait for the last tandem of KF5 apps though.
> >> > > 
> >> > > Is there anything still blocking this?
> >> > 
> >> > Yes, at least one co maintainer believes the kde-runtime patch is
> >
> >not
> >
> >> > appropriate.
> >> 
> >> That patch no longer seems to be available, so I made my own.
> >
> >Patches for
> >
> >> kde4libs and kde-runtime attached.  I looked at the KDE4 packages
> >
> >still in
> >
> >> Buster and I don't believe this interferes with anything.  This also
> >
> >fixes the
> >
> >> FTBFS with Samba 4.9 by dropping the KDE4 kio_smb.
> >
> >The samba compatibility issue is a different story, and it can be fixed
> >by just disabling kio_smb (in case it requires non-trivial work to make
> >it work again).
> >
> >> I think we should move forward on these (or some improved version if
> >
> >someone
> >
> >> has suggestions).
> >> 
> >> Even though there are separate bugs for kde-runtime, since the patch
> >
> >for it
> >
> >> was already discussed in this bug, I thought we might as well keep
> >
> >them
> >
> >> together.
> >
> >Did you check that all the packages using kde4libs still build fine?
> >
> >The removal of kio_thumbnail from kde-runtime is definitely not
> >appropriate, since it will break the thunbnail support for any
> >kdelibs 4.x application.
> >
> >Again: something worth to mention, since apparently it is not clear:
> >removing bits from either kde4libs or kde-runtime has consequences,
> >either build time or runtime ones. Randomly chopping pieces without
> >checking what changes, and potentially what breaks, is generally a
> >big no-no from me. I do not see how "remove qtwebkit" is an excuse to
> >start messing up with packages, just for the sake of package removal.
> 
> I didn't do rebuild tests, but I did search using codesearch to see if any
> of the dropped headers or functions are used.  I didn't find anything.
> 
> I think rebuilding the rdepends is a reasonable next step.  I'll try that
> and see if anything is affected.
> 
> I understand your concern, but I don't think realeasing with a known pile of
> security vulnerabilities such as Qt4's WebKit is doing anyone any favors if
> it can be avoided.
> 
> Scott K

My plan now is to upload to experimental with a ~exp1 revision so it can just 
vanish from history and not leave any gaps if we decide this is a no go.

Scott K

Bug#784479: [kde4libs] Qt4's WebKit removal

[Scott Kitterman]

On January 15, 2019 7:17:36 AM UTC, Pino Toscano  wrote:
>In data lunedì 14 gennaio 2019 12:22:52 CET, Scott Kitterman ha
>scritto:
>> On Thu, 01 Nov 2018 14:04:12 -0300 Lisandro 
>> =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer
> wrote:
>> > On Wed, 17 Oct 2018 15:57:25 +0200 Ivo De Decker 
>wrote:
>> > > Hi,
>> > > 
>> > > On Fri, Nov 24, 2017 at 04:59:58PM -0300, Lisandro Damián Nicanor
>Pérez 
>> > Meyer wrote:
>> > > > Control: tag -1 patch
>> > > > 
>> > > > There is patch available for this at 
>> <https://git.archlinux.org/svntogit/
>> > > >
>packages.git/tree/trunk/kdelibs-no-kdewebkit.patch?h=packages/kdelibs>
>> > > > 
>> > > > We might want to wait for the last tandem of KF5 apps though.
>> > > 
>> > > Is there anything still blocking this?
>> > 
>> > Yes, at least one co maintainer believes the kde-runtime patch is
>not 
>> > appropriate.
>> 
>> That patch no longer seems to be available, so I made my own. 
>Patches for 
>> kde4libs and kde-runtime attached.  I looked at the KDE4 packages
>still in 
>> Buster and I don't believe this interferes with anything.  This also
>fixes the 
>> FTBFS with Samba 4.9 by dropping the KDE4 kio_smb.
>
>The samba compatibility issue is a different story, and it can be fixed
>by just disabling kio_smb (in case it requires non-trivial work to make
>it work again).
>
>> I think we should move forward on these (or some improved version if
>someone 
>> has suggestions).
>> 
>> Even though there are separate bugs for kde-runtime, since the patch
>for it 
>> was already discussed in this bug, I thought we might as well keep
>them 
>> together.
>
>Did you check that all the packages using kde4libs still build fine?
>
>The removal of kio_thumbnail from kde-runtime is definitely not
>appropriate, since it will break the thunbnail support for any
>kdelibs 4.x application.
>
>Again: something worth to mention, since apparently it is not clear:
>removing bits from either kde4libs or kde-runtime has consequences,
>either build time or runtime ones. Randomly chopping pieces without
>checking what changes, and potentially what breaks, is generally a
>big no-no from me. I do not see how "remove qtwebkit" is an excuse to
>start messing up with packages, just for the sake of package removal.

I didn't do rebuild tests, but I did search using codesearch to see if any of 
the dropped headers or functions are used.  I didn't find anything.

I think rebuilding the rdepends is a reasonable next step.  I'll try that and 
see if anything is affected.

I understand your concern, but I don't think realeasing with a known pile of 
security vulnerabilities such as Qt4's WebKit is doing anyone any favors if it 
can be avoided.

Scott K

Bug#919334: kde-standard: Please add kleopatra to Depends

[Scott Kitterman]

Package: kde-standard
Version: 5:102
Severity: normal

Debian ought to be making barriers to using encryption as low as we reasonably
can.  If you attempt to set a preferred gpg key in kmail without kleopatra
installed, it fails with a very unhelpful error message.

Rather than improve the error message in kmail, let's just make it work by
adding kleopatra to kde-standard.

Scott K

Bug#784479: [kde4libs] Qt4's WebKit removal

[Scott Kitterman]

On Thu, 01 Nov 2018 14:04:12 -0300 Lisandro 
=?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer  wrote:
> On Wed, 17 Oct 2018 15:57:25 +0200 Ivo De Decker  wrote:
> > Hi,
> > 
> > On Fri, Nov 24, 2017 at 04:59:58PM -0300, Lisandro Damián Nicanor Pérez 
> Meyer wrote:
> > > Control: tag -1 patch
> > > 
> > > There is patch available for this at 
<https://git.archlinux.org/svntogit/
> > > packages.git/tree/trunk/kdelibs-no-kdewebkit.patch?h=packages/kdelibs>
> > > 
> > > We might want to wait for the last tandem of KF5 apps though.
> > 
> > Is there anything still blocking this?
> 
> Yes, at least one co maintainer believes the kde-runtime patch is not 
> appropriate.

That patch no longer seems to be available, so I made my own.  Patches for 
kde4libs and kde-runtime attached.  I looked at the KDE4 packages still in 
Buster and I don't believe this interferes with anything.  This also fixes the 
FTBFS with Samba 4.9 by dropping the KDE4 kio_smb.

I think we should move forward on these (or some improved version if someone 
has suggestions).

Even though there are separate bugs for kde-runtime, since the patch for it 
was already discussed in this bug, I thought we might as well keep them 
together.

Scott Kdiff -Nru kde4libs-4.14.38/debian/changelog kde4libs-4.14.38/debian/changelog
--- kde4libs-4.14.38/debian/changelog	2018-12-01 08:29:23.0 -0500
+++ kde4libs-4.14.38/debian/changelog	2019-01-14 06:15:38.0 -0500
@@ -1,3 +1,17 @@
+kde4libs (4:4.14.38-4) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Drop support for Qt4 WebKit (Closes: #784479)
+- Drop build-depends
+- Add d/p/no_kdewebkit.patch to patch out building kdewebkit, kdewebkit
+  widgets, private/animablegraphicswebview, and widgets/webview
+- Drop libkdewebkit5 binary package
+- Build plasma3 without webkit
+- Update install files (verified header files that are no longer shipped
+  are not used elsewhere in Debian) 
+
+ -- Scott Kitterman   Mon, 14 Jan 2019 02:14:35 -0500
+
 kde4libs (4:4.14.38-3) unstable; urgency=medium
 
   * Team upload
diff -Nru kde4libs-4.14.38/debian/control kde4libs-4.14.38/debian/control
--- kde4libs-4.14.38/debian/control	2018-12-01 08:29:07.0 -0500
+++ kde4libs-4.14.38/debian/control	2019-01-14 06:11:58.0 -0500
@@ -37,7 +37,6 @@
libqca2-dev (>= 2.0.0),
libqt4-dev (>= 4:4.8.0),
libqt4-opengl-dev (>= 4:4.8.0),
-   libqtwebkit-dev,
libsm-dev,
libssl-dev (>= 1.1),
libudev-dev [linux-any],
@@ -374,14 +372,6 @@
  .
  This library is part of the KDE Development Platform libraries module.
 
-Package: libkdewebkit5
-Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}
-Description: KDE WebKit Library
- This library provides KDE integration of the QtWebKit library.
- .
- This package is part of the KDE Development Platform libraries module.
-
 Package: libkcmutils4
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
diff -Nru kde4libs-4.14.38/debian/kdelibs5-dev.install kde4libs-4.14.38/debian/kdelibs5-dev.install
--- kde4libs-4.14.38/debian/kdelibs5-dev.install	2018-12-01 04:19:39.0 -0500
+++ kde4libs-4.14.38/debian/kdelibs5-dev.install	2019-01-14 05:32:55.0 -0500
@@ -1175,7 +1175,6 @@
 usr/include/kdeui_export.h
 usr/include/kdeversion.h
 usr/include/kdevicelistmodel.h
-usr/include/kdewebkit_export.h
 usr/include/kdialog.h
 usr/include/kdialogbuttonbox.h
 usr/include/kdialogjobuidelegate.h
@@ -1246,7 +1245,6 @@
 usr/include/kglobalsettings.h
 usr/include/kglobalshortcutinfo.h
 usr/include/kglobalshortcutinfo_p.h
-usr/include/kgraphicswebview.h
 usr/include/kguiitem.h
 usr/include/khbox.h
 usr/include/khelpmenu.h
@@ -1640,10 +1638,6 @@
 usr/include/kviewstatemaintainer.h
 usr/include/kviewstatesaver.h
 usr/include/kwallet.h
-usr/include/kwebpage.h
-usr/include/kwebpluginfactory.h
-usr/include/kwebview.h
-usr/include/kwebwallet.h
 usr/include/kwidgetitemdelegate.h
 usr/include/kwidgetjobtracker.h
 usr/include/kwindowinfo.h
@@ -1748,7 +1742,6 @@
 usr/include/plasma/widgets/toolbutton.h
 usr/include/plasma/widgets/treeview.h
 usr/include/plasma/widgets/videowidget.h
-usr/include/plasma/widgets/webview.h
 usr/include/plasma/windoweffects.h
 usr/include/predicateproperties.h
 usr/include/qtest_kde.h
@@ -1816,7 +1809,6 @@
 usr/lib/libkdefakes.so
 usr/lib/libkdesu.so
 usr/lib/libkdeui.so
-usr/lib/libkdewebkit.so
 usr/lib/libkdnssd.so
 usr/lib/libkemoticons.so
 usr/lib/libkfile.so
diff -Nru kde4libs-4.14.38/debian/kdelibs5-plugins.install kde4libs-4.14.38/debian/kdelibs5-plugins.install
--- kde4libs-4.14.38/debian/kdelibs5-plugins.install	2018-12-01 04:19:39.0 -0500
+++ kde4libs-4.14.38/debian/kdelibs5-plugins.install	2019-01-14 05:29:54.0 -0500
@@ -1,6 +1,5 @@
 usr/lib/*/qt4/plugins/designer/kde3s

Re: Bug#631769: [Debconf-devel] Bug#631769: New Kde frontend based on debconf-kde-helper

[Scott Kitterman]

On Wednesday, July 25, 2018 09:46:45 AM Colin Watson wrote:
> On Wed, Jul 25, 2018 at 10:23:49AM +0800, Matthias Klumpp wrote:
> > 2018-07-25 5:51 GMT+08:00 Lisandro Damián Nicanor Pérez Meyer
> > 
> > :
> > > On Thu, 19 Jul 2018 at 14:04, Colin Watson  wrote:
> > >> Simple enough: once you've installed the new version, "dpkg-reconfigure
> > >> debconf" and select the "Kde" frontend.  You can then install/remove
> > >> packages that do debconf interaction, using apt or aptitude or a
> > >> graphical frontend or whatever, and see if you get reasonable prompts.
> > > 
> > > Works like a charm. I will keep testing it, but I think we can
> > > deprecate the Qt4 version right now.
> > 
> > This is really cool, thank you a lot for working on it! The KDE
> > frontend will also be much easier to maintain with debconf-kde-helper,
> > porting it to Qt 6 when it arrives should be very easy.
> > This change may also help with a current effort to improve the way
> > debconf is handled when packages are installed via PackageKit (by
> > potentially making it possible to get rid of KDE special-casing).
> 
> Great, thanks a lot to you both.  I've uploaded debconf 1.5.69 now to
> remove the old Qt frontend.

I've filed the rm bugs for qt4-perl and smokeqt.  This was the last thing 
preventing their removal.

Scott K

Bug#887687: libsmokeqt4-dev: broken symlinks and causes qt4-perl FTBFS

[Scott Kitterman]

I had hoped to work on this this week.  It hasn't happened and it's not going 
to.

In the end, I the Qt4 stuff has to go, so I wouldn't wait on this for the 
transition.

Scott K

On June 28, 2018 1:23:31 PM UTC, "Lisandro Damián Nicanor Pérez Meyer" 
 wrote:
>El miércoles, 27 de junio de 2018 16:25:23 -03 Niko Tyni escribió:
>> On Tue, Jun 19, 2018 at 10:05:09AM -0300, Lisandro Damián Nicanor
>Pérez 
>Meyer wrote:
>[snip] 
>> > > Copying the debconf maintainers as well.
>> > 
>> > Hi! I have just pinged the rest of the Qt/KDE team for thoughts, as
>I have
>> > never used this myself so I might not have a good view on the
>issue.
>> > 
>> > I'll try to follow up soon, but please ping me again (IRC is valid
>too) if
>> > I don't cam up with a reply in, let's say, 5 to 7 days.
>> 
>> Hi, any news here? FWIW Perl 5.28.0 final was released recently and
>is
>> now in experimental. It would be great to get this issue moving
>forward
>> one way or another.
>
>For what I know Scott (CCed) was waiting on a reply from someone wrt
>this. 
>That's all I could gather I'm afraid.

Comments regarding kio-gdrive_1.2.2-1_amd64.changes

[Scott Kitterman]

The included cmake module is GPL-3+, but there's no GPL-3+ COPYING file
included.  This is not strictly a rejection issue, so I am going to accept
the pacakge, but you should ask upstream to include a full copy of the license
in future releases.

Scott K

Comments regarding qt5ct_0.34-1_amd64.changes

[Scott Kitterman]

I am going to accept the package, but please address the following issues in
your next upload:

Do not ship the AUTHORS file in docs.  Anyone who holds copyright on item in
the package has to be listed in debian/copyright (policy 2.3), which does not
seem to be the case here.  As such, it's just package bloat.

Come up with a solution for environment variable setting other than manual
user edits. (policy 9.9)

Scott K

qtdeclarative-opensource-src_5.10.0-1_amd64.changes REJECTED

[Scott Kitterman]

These files are described as public domain internally.  This should be
mentioned in debian/copyright:

examples/quick/demos/photosurface/resources/icon.png
src/quick/doc/images/touchpoint-metrics.png


These files are BSD-2-Clause.  The copyright holders are not in debian/
copyright (or in the case of Apple, not for the file in question):

src/3rdparty/masm/disassembler/Mips32Disassembler.cpp: * Copyright (C) 2015 
Cisco Systems, Inc. All rights reserved.
src/3rdparty/masm/disassembler/mips32/Mips32Opcode.cpp: * Copyright (C) 2015 
Cisco Systems, Inc. All rights reserved.
src/3rdparty/masm/disassembler/mips32/Mips32Opcode.h: * Copyright (C) 2015 
Cisco Systems, Inc. All rights reserved.
src/3rdparty/masm/disassembler/udis86/udis86.c: * Copyright (c) 2002-2009 Vivek 
Thampi
src/3rdparty/masm/disassembler/udis86/udis86_syn.c: * Copyright (c) 2002-2009 
Vivek Thampi
src/3rdparty/masm/disassembler/udis86/ud_opcode.py:# Copyright (c) 2009 Vivek 
Thampi
src/3rdparty/masm/disassembler/udis86/udis86_input.h: * Copyright (c) 2002-2009 
Vivek Thampi
src/3rdparty/masm/disassembler/udis86/udis86_extern.h: * Copyright (c) 
2002-2009 Vivek Thampi
src/3rdparty/masm/disassembler/udis86/udis86_input.c: * Copyright (c) 2002-2009 
Vivek Thampi
src/3rdparty/masm/disassembler/udis86/udis86.h: * Copyright (c) 2002-2009 Vivek 
Thampi
src/3rdparty/masm/disassembler/udis86/udis86_syn.h: * Copyright (c) 2002-2009
src/3rdparty/masm/disassembler/udis86/ud_optable.py:# Copyright (c) 2009 Vivek 
Thampi
src/3rdparty/masm/disassembler/udis86/udis86_itab_holder.c: * Copyright (C) 
2012 Apple Inc. All rights reserved.
src/3rdparty/masm/disassembler/udis86/udis86_syn-att.c: * Copyright (c) 
2002-2009 Vivek Thampi
src/3rdparty/masm/disassembler/udis86/udis86_types.h: * Copyright (c) 2002-2009 
Vivek Thampi
src/3rdparty/masm/disassembler/udis86/udis86_decode.h: * Copyright (c) 
2002-2009 Vivek Thampi
src/3rdparty/masm/disassembler/udis86/udis86_decode.c: * Copyright (c) 
2002-2009 Vivek Thampi
src/3rdparty/masm/disassembler/udis86/udis86_syn-intel.c: * Copyright (c) 
2002-2009 Vivek Thampi
src/3rdparty/masm/disassembler/udis86/itab.py:# Copyright (c) 2009 Vivek Thampi

There are many others.

The BSD-2 variant in tests/auto/qml/ecmascripttests/test262/LICENSE is enough
different than the standard license that I believe it should be listed in
debian/copyright.

Unfortunately, I am going to have to reject this package.  Please give the
licenses and copyright statements a good scrub and re-upload.

Scott K




===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Comments regarding qttools-opensource-src_5.9.2-5_amd64.changes

[Scott Kitterman]

Copyright statements for The Qt Company Ltd in the package are 2016 and 2017
vice 2015 and 2016 as listed in debian/copyright.  Please update this for
your next upload.

Scott K

Re: Cannot build OpenGL application on Qt5 on armel/hf

[Scott Kitterman]

That's the intended behavior.  There isn't a reasonable way around it.  You'll 
either need to port it to use GL ES or disable it on these archs.

Scott K

On September 18, 2017 5:50:24 PM EDT, John Paul Adrian Glaubitz 
 wrote:
>Hi!
>
>I have uploaded a new version of virtualjaguar today which uses Qt5 by
>default
>[1]. Unfortunately, this brought a regression on armel and armhf in the
>form
>of an FTBFS [2]:
>
>g++ -c -pipe `sdl-config --cflags` -O2 -Wdate-time -D_FORTIFY_SOURCE=2
>-ffast-math -fomit-frame-pointer -Wall -W -D_REENTRANT -fPIC
>-D__GCCUNIX__ -DQT_NO_DEBUG
>-DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -Isrc
>-Isrc/gui -isystem /usr/include/arm-linux-gnueabi/qt5 -isystem
>/usr/include/arm-linux-gnueabi/qt5/QtOpenGL -isystem
>/usr/include/arm-linux-gnueabi/qt5/QtWidgets -isystem
>/usr/include/arm-linux-gnueabi/qt5/QtGui -isystem
>/usr/include/arm-linux-gnueabi/qt5/QtCore -Iobj
>-I/usr/lib/arm-linux-gnueabi/qt5/mkspecs/linux-g++ -o obj/glwidget.o
>src/gui/glwidget.cpp
>src/gui/glwidget.cpp: In member function 'virtual void
>GLWidget::initializeGL()':
>src/gui/glwidget.cpp:49:12: error: 'GL_ALPHA_TEST' was not declared in
>this scope
>  glDisable(GL_ALPHA_TEST);
>^
>src/gui/glwidget.cpp:49:12: note: suggested alternative:
>'GL_ALPHA8_OES'
>  glDisable(GL_ALPHA_TEST);
>^
>GL_ALPHA8_OES
>src/gui/glwidget.cpp:52:12: error: 'GL_POLYGON_SMOOTH' was not declared
>in this scope
>  glDisable(GL_POLYGON_SMOOTH);
>^
>(...)
>
>Looking at the rules file of qtbase-opensource-src, it's obvious where
>this
>regression comes from, namely from the fact that qtbase-opensource-src
>is
>configured to use OpenGL ES instead of proper desktop OpenGL on armel
>and armhf [3].
>
>Does anyone know whether there is a way to address this issue on
>armel/hf
>or do I have to disable virtualjaguar on these architectures?
>
>CC'ing debian-arm@l.d.o in case someone there knows about a possible
>workaround.
>
>Adrian
>
>> [1]
>https://packages.qa.debian.org/v/virtualjaguar/news/20170918T181332Z.html
>> [2]
>https://buildd.debian.org/status/fetch.php?pkg=virtualjaguar=armel=2.1.3-1=1505760397=0
>> [3]
>https://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/tree/debian/rules#n29

Bug#864967: parley: Recommends python-kde4 which is to be removed for Buster

[Scott Kitterman]

On Sun, 18 Jun 2017 01:33:55 -0400 Scott Kitterman <deb...@kitterman.com> 
wrote:
> Package: parley
> Version: 4:16.08.3-1
> Severity: important
> 
> Dear Maintainer,
> 
> During the Buster development cycle Qt4 is going to be removed.  As a
> result, PyQt4 and PyKDE4 will be removed as well.  This package
> recommends python-kde4.  If you want it to be part of the Buster release,
> it will have to be ported to Qt5 (Kf5 Python bindings are not available
> yet, but they are expected to be packaged early in the Buster
> development cycle).

The current release of parley is Kf5, so updating the package to the current 
version should be enough to resolve this.  There is a legacy test.py file in 
the tarball, but it's for the KDE4 version of Parley, so can be safely 
ignored.  When updating Parley to the new version, just drop this Recommends.

Scott K

Bug#875153: [qtruby] Future Qt4 removal from Buster

[Scott Kitterman]

On Saturday, September 09, 2017 11:08:15 PM Lisandro Damián Nicanor Pérez 
Meyer wrote:
> Source: qtruby
> Version: 4:4.14.3-1
> Severity: wishlist
> User: debian-qt-kde@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced]
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support]
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there
> are suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version
> 
> = Porting =
> 
> Some of us where involved in various Qt4 to Qt5 migrations [migration] and
> we know for sure that porting stuff from Qt4 to Qt5 is much much easier and
> less painful than it was from Qt3 to Qt4.
> 
> We also understand that there is still a lot of software still using Qt4.
> 
> Don't forget to take a look at the C++ API changes page [apichanges]
> whenever you start porting your application.
> 
> [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> 
> For any questions and issues, do not hesitate to contact the Debian Qt/KDE
> team at debian-qt-kde@lists.debian.org
> 
> The removal is being tracked in 
> 
> Lisandro,
> on behalf of the Qt4 maintainers

No rdepends, so went ahead and requested removal.

Scott K

Bug#874983: [konsole4] Future Qt4 removal from Buster

[Scott Kitterman]

On Sat, 9 Sep 2017 21:32:11 +0200 Lisandro 
=?iso-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer  wrote:
> Source: konsole4
> Version: 4:4.14.2-4
> Severity: wishlist
> User: debian-qt-kde@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there 
are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version
> 
> = Porting =
> 
> Some of us where involved in various Qt4 to Qt5 migrations [migration] and 
we
> know for sure that porting stuff from Qt4 to Qt5 is much much easier and 
less
> painful than it was from Qt3 to Qt4.
> 
> We also understand that there is still a lot of software still using Qt4.
> 
> Don't forget to take a look at the C++ API changes page [apichanges] 
whenever
> you start porting your application.
> 
> [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> 
> For any questions and issues, do not hesitate to contact the Debian Qt/KDE
> team at debian-qt-kde@lists.debian.org
> 
> The removal is being tracked in 
> 
> Lisandro,
> on behalf of the Qt4 maintainers

Can be removed one the new kile is released/packaged.

Scott K

Bug#784511: [pykde4] Qt4's WebKit removal

[Scott Kitterman]

On Wed, 6 May 2015 15:26:52 +0200 Ana Guerrero Lopez  wrote:
> Source: pykde4
> Version: 4:4.14.0-1
> Severity: wishlist
> User: debian-qt-kde@lists.debian.org
> Usertags: qt4webkit-removal
> 
> Dear Debian Qt/KDE Maintainers ,
> 
> As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
> as announced in [announce].
> 
> [announce] 
> 
> 
> Basically we are about to get the latest Qt4 point release and upstream is
> migrating from WebKit to Bing in the Qt5 series, so we won't have much 
upstream
> support for maintaining Qt4's WebKit.
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4's WebKit library have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
Fixed in 4:4.14.3-3

Re: breeze-icons_5.36.0-1_amd64.changes is NEW

[Scott Kitterman]

On Thursday, July 13, 2017 09:33:21 PM Pino Toscano wrote:
...
> When uploading something, I push the "upload to $SUITE" commits, and
> the tag of that upload only *after* I get the "ACCEPTED" email for that
> upload. Since it was stuck in NEW, then that stuff stays in my local
> clone until the upload gets out of NEW. This is not an arbitrary whim,
> but I do that because the upload could be rejected for whatever
> reasons, and thus that commit & the tag would be totally invalid.
...

I really don't want to get in the middle of the 'discussion' the two of you 
are having (I end up doing enough conflict resolution at work - I'm not doing 
it for fun), but I want to make sure I understand what you are asking here, 
because if I understand you correctly (which is why I'm checking), then I 
suspect we could have a collision in the future as well.

What I read that as asking of your fellow team members is to check the New 
queue every single time before they do a package upload.  Is that correct?

If so, I don't think that's the best approach.

I completely understand not wanting to tag until the package is accepted, but 
by not pushing your commit, you leave all your team members in the dark about 
the work you've done.  I don't think this is good.

Commits can be amended, so I don't think it's correct to say a rejection from 
New makes a commit 'totally invalid'.  I think it would be much better if you  
would push your commits when you upload to New and then either tag on accept 
or amend, push, and reupload on reject.  That would make the git repository 
the single place to look for the current status of the package.

I hope I misunderstood because I don't think 'everyone check New before every 
upload' is a reasonable request.

Would you please clarify?

Scott K


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

Bug#865861: python-kde4: Qtwebkit not available breaks importing plasma module

[Scott Kitterman]

On June 25, 2017 7:24:58 AM EDT, ZevenOS  wrote:
>
>Package: python-kde4
>Version: 4:4.14.3-2
>Severity: grave
>Justification: renders package unusable
>
>Dear Maintainer,
>
>   * What led up to the situation?
>Importing Plasma in python scripts throws an error
>
>   * What exactly did you do (or not do) that was effective (or
> ineffective)?
>from PyKDE4.plasma import *
>fails

I think the error here is not removing PyKDE4.plasma from the package entirely. 
 Since Stretch ships Qt5 based Plasma, the Qt4 based PyKDE4 will never work 
with it.

The WebKit removal was intentional due to lack of upstream support and known 
security vulnerabilities.

Scott K

Comments regarding qtdeclarative-opensource-src_5.9.0-1_amd64.changes

[Scott Kitterman]

I am going to accept your package, but I did notice one small (non-fatal)
error in debian/copyright.  The copyright year for
tests/auto/qml/qqmlxmlhttprequest/data/send_patch.qml is now listed as 2017
vice 2016.  Please update your debian/copyright for the next upload.

Scott K

Bug#864967: parley: Recommends python-kde4 which is to be removed for Buster

[Scott Kitterman]

Package: parley
Version: 4:16.08.3-1
Severity: important

Dear Maintainer,

During the Buster development cycle Qt4 is going to be removed.  As a
result, PyQt4 and PyKDE4 will be removed as well.  This package
recommends python-kde4.  If you want it to be part of the Buster release,
it will have to be ported to Qt5 (Kf5 Python bindings are not available
yet, but they are expected to be packaged early in the Buster
development cycle).

Scott K

Bug#864965: kajongg: Depends on python-kde4 which is to be removed for Buster

[Scott Kitterman]

Package: kajongg
Version: 4:16.08.3-1
Severity: important

Dear Maintainer,

During the Buster development cycle Qt4 is going to be removed.  As a
result, PyQt4 and PyKDE4 will be removed as well.  This package depends
on python-kde4.  If you want it to be part of the Buster release, it
will have to be ported to Qt5 (Kf5 Python bindings are not available
yet, but they are expected to be packaged early in the Buster
development cycle).

Scott K

Bug#856004: khtml: please build-depen on libssl1.0-dev for Stretch

[Scott Kitterman]

On February 26, 2017 2:15:25 PM EST, John Paul Adrian Glaubitz 
 wrote:
>On 02/26/2017 07:48 PM, Sebastian Andrzej Siewior wrote:
>> I don't insist on anything. I noticed that this package does not
>depend on
>> libssl after building and that is why I took a look.
>
>Interesting. So, I guess the best option would actually to drop the B-D
>on
>libssl-dev completely. I have checked it myself and indeed libkf5khtml5
>does
>not depend on libssl at all. Plus, the package also builds fine with
>the
>build dependency on libssl-dev completely removed.
>
>Lisandro, maybe just dropping the build dependency on libssl-dev would
>be
>the best option if it's actually not used at all?

We shouldn't be changing the way a package builds during freeze.  It was last 
built with openssl 1.0, so that's what we should have for now.

Scott K

Bug#856004: khtml: please build-depen on libssl1.0-dev for Stretch

[Scott Kitterman]

On Saturday, February 25, 2017 12:29:31 PM Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On sábado, 25 de febrero de 2017 14:03:31 ART John Paul Adrian Glaubitz 
wrote:
> > Hi Sebastian!
> > 
> > I just gave it a try and khtml builds fine as is.
> > 
> > Are there any additional tests you'd suggest for testing whether khtml
> > works fine with libssl1.1? Attached is the build log of a successful
> > test build of the current khtml package.
> 
> I think the issue here is if it will work or not at runtime.
> 
> Sebastian: have you seen it crash due to this?

Kf5 (including khtml) need to use the same version of openssl as Qt5, which is 
1.0 for this cycle.  Whether crashes have been seen or not, trying to mix 
openssl 1.0 and 1.1 in the same stack seems foolhardy.

Scott K

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

Re: Help needed: KDE partition manager

[Scott Kitterman]

On Saturday, December 24, 2016 11:19:35 PM Jonathan Carter wrote:
> Hi Scott
> 
> On 24/12/2016 23:06, Jonathan Carter (highvoltage) wrote:
> > On 24/12/2016 23:04, Scott Kitterman wrote:
> >> Did you test if it actually works correctly?  That's been the key
> > 
> > sticking
> > 
> >> point, IIRC.
> > 
> > It at least detects my drives, I didn't want to mess around too much
> > directly on my desktop. I'll fire it up in a VM now and let you know...
> 
> I can create new partition tables, create new ext4, vfat and ntfs
> partitions, resize partitions and destroy them. Seems to be doing
> exactly what you'd want a partition manager to do :)

OK.  The package failed to build without a build-depends on libkpmcore4-dev.  
I've uploaded kpmcore and once it's out of New, I'll upload partitionmanager.

kpmcore was technically fine, but the debian/copyright file was incomplete.  
As that one is going to New and will be reviewed by the FTP team, that would 
be bad.  I fixed it before uploading.

I have partionmanager ready to go.  It had more serious debian/copyright 
problems, which I fixed.  I also switched it to dh and cleaned up build-
depends while I was at it.

Scott K

Re: Help needed: KDE partition manager

[Scott Kitterman]

On Saturday, December 24, 2016 11:01:30 PM Jonathan Carter wrote:
> Hi Debian Qt/KDE Maintainers!
> (cc Scott and Gianfranco)
> 
> I made quite a few changes in update partitionmanager from version 1 to 3.
> 
> https://mentors.debian.net/package/partitionmanager
> 
> Changes:
> """
>   * Update to new upstream version (Closes: #794438, #709474, LP: #1635756)
>   * Update standards version to 3.9.8
>   * Remove patches (no longer needed)
>   * Update compat to level 10
>   * Fix watch file (Closes: #788701)
>   * Replace ntfsprogs dependency with ntfs-3g (Closes: #731957)
>   * Replace partion typo with partition in control (Closes: 745290)
>   * New build-deps: extra-cmake-modules, qtbase5-dev,
> libkf5widgetsaddons-dev, libkf5xmlgui-dev, libkf5kiocore5,
> libkf5config-dev, libkf5crash-dev, libkf5doctools-dev,
> libkf5jobwidgets-dev, libkf5kio-dev, libkpmcore4-dev,
> libatasmart-dev
>   * wrap-and-sort
>   * Update homepage to new location on kde.org
>   * Update copyright file to machine readable format
>   * Add hardening export to debian/rules
>   * Remove 3 lintian-overrides (no longer needed)
>   * Add lintian override for insecure VCS URI
>   * Remove maintainer scripts (no longer needed)
>   * Add myself as uploader
> """
> 
> It builds fine installs and upgrades fine and even runs fine.
> 
> I have one problem left that I'm not sure what the best way to fix it is:
> 
> """
> I: partitionmanager: arch-dep-package-has-big-usr-share 3855kB 84%
> N:
> N:The package has a significant amount of architecture-independent data
> N:(over 4MB, or over 2MB and more than 50% of the package) in /usr/share
> N:but is an architecture-dependent package. This is wasteful of mirror
> N:space and bandwidth since it means distributing multiple copies of
> this
> N:data, one for each architecture.
> N:
> N:If the data in /usr/share is not architecture-independent, this is a
> N:Policy violation that should be fixed by moving the data elsewhere
> N:(usually /usr/lib).
> N:
> N:Refer to Debian Developer's Reference section 6.7.5
> N:(Architecture-independent data) for details.
> N:
> N:Severity: wishlist, Certainty: certain
> N:
> N:Check: huge-usr-share, Type: binary
> """
> 
> That's caused by the documents in /usr/share/doc. The package uses both
> some cdbs and some kde scripts I'm not completely familiar with. If I
> create a seperate -doc package, what's the best way to specify that
> those packages should only be installed in the -doc package?
> 
> Other than that, if you'd like to build this locally for now, you'll
> need to install kpmcore version 3.0.0
> (https://mentors.debian.net/package/kpmcore) in your build root. Freeze
> time is really close (5 January) and I'll likely already have to request
> a freeze exception to get these in, so any help would be appreciated!
> 
> Also, is it possible that I can get SVN access? My username on alioth is
> highvoltage-guest.
> 
> Any other feedback also welcome!
> 
> -Jonathan

Did you test if it actually works correctly?  That's been the key sticking 
point, IIRC.

Scott K

Comments regarding qbs_1.7.0+dfsg-1_amd64.changes

[Scott Kitterman]

I am going to accept your package, but there is one debian/copyright issue
that should be fixed in the next upload.  In tests/auto/blackbox/
tst_clangdb.cpp, the copyright attribution for Christian Gagneraud is missing.
Please add that for your next upload.

Scott K

qtwebengine-opensource-src_5.7.1~20161021+dfsg-1_amd64.changes REJECTED

[Scott Kitterman]

The debian/copyright looks pretty good.  I can tell a lot of effort went into
this package and it's a beast.  Unfortunately, I am going to have to reject it
due to sourceless javascript:

N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
examples/webenginewidgets/contentmanipulation/jquery.min.js
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
examples/webenginewidgets/markdowneditor/resources/marked.min.js
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/analytics/google-analytics-bundle.js line 
length is 525 characters (>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/chaijs/chai.js line length is 844 characters 
(>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/v8/benchmarks/regexp.js line length is 2305 characters 
(>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/blanketjs/src/blanket.js line length is 4238 
characters (>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/pyelftools/examples/sample_exe64.elf
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/web-animations-js/sources/web-animations-next-lite.min.js
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/web-animations-js/sources/web-animations-next.min.js
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/web-animations-js/sources/web-animations.min.js
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/dom_distiller_js/dist/js/domdistiller.js line 
length is 564 characters (>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/dom_distiller_js/dist/js/domdistiller_wrapped.js
 line length is 564 characters (>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/pycoverage/coverage/htmlfiles/jquery.min.js
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/pycoverage/coverage/htmlfiles/jquery.tablesorter.min.js
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/ui/accessibility/extensions/highcontrast/highcontrast.js 
line length is 3045 characters (>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/ui/webui/resources/js/jstemplate_compiled.js
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/WebKit/Source/devtools/front_end/acorn/acorn.js
 line length is 845 characters (>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/WebKit/Source/devtools/front_end/cm_modes/clojure.js
 line length is 536 characters (>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/WebKit/Source/devtools/front_end/cm_modes/php.js
 line length is 7403 characters (>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/WebKit/Source/devtools/front_end/cm_modes/stylus.js
 line length is 860 characters (>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/WebKit/Source/devtools/front_end/diff/diff_match_patch.js
 line length is 536 characters (>512)
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/skia/platform_tools/android/bin/linux/perfhost
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/WebKit/Tools/Scripts/webkitpy/thirdparty/coverage/htmlfiles/jquery-1.4.3.min.js
N: Not used
O: qtwebengine-opensource-src source: source-is-missing 
src/3rdparty/chromium/third_party/WebKit/Tools/Scripts/webkitpy/thirdparty/coverage/htmlfiles/jquery.tablesorter.min.js

I didn't check all these, but "not used" is not 100% correct.  The sourceless
javascript in the examples directory is shipped, but it doesn't matter.  The
source has to be in the source package to make the source package DFSG free.

In some cases, it seems these might be the preferred form of modification.  I
found:

https://github.com/GoogleChrome/chrome-platform-analytics/blob/master/google-analytics-bundle.js

If these are truly not used, just remove them from the tarball and re-upload.

Scott K



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Bug#805612: akonadi-backend-mysql: It should depend on mysql-server-core but not mysql-client-core

[Scott Kitterman]

It says fix, not remove.  This should probably be default-mysql-client-core 
(unless this is through shlibs depends, in which case it will be
mariadb-client-core-10.0, when built against default-libmysqlclient-dev).

Scott K

On November 22, 2016 12:16:22 PM EST, "Sandro Knauß"  
wrote:
>Hey,
>
>can you please explain, why you think, we can remove the
>mysql-client-core 
>dependency? akonadi is starting a server by it self and also connects
>to it, 
>so for me it makes sense, that akonadi also needs mysql-client-core to
>work. 
>Have you tested a system without mysql-client-core?
>
>Best Regards,
>
>sandro
>
>
>Am Freitag, 20. November 2015, 16:24:03 CET schrieb Zhang Jingqiang:
>> Package: akonadi-backend-mysql
>> Version: 15.08.2-1
>> Severity: important
>> 
>> Hello,
>>  Please fix the dependency.
>> 
>> Thanks
>> 
>> -- System Information:
>> Debian Release: stretch/sid
>>   APT prefers unstable
>>   APT policy: (990, 'unstable'), (500, 'work'), (500,
>'testing-updates'),
>> (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>> 
>> Kernel: Linux 4.3.0-trunk-amd64 (SMP w/2 CPU cores)
>> Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> 
>> Versions of packages akonadi-backend-mysql depends on:
>> ii  libqt5sql5-mysql   5.5.1+dfsg-8
>> ii  mysql-client-core-5.6 [virtual-mysql-client-core]  5.6.27-2
>> 
>> Versions of packages akonadi-backend-mysql recommends:
>> ii  akonadi-server  15.08.2-1+b1
>> 
>> akonadi-backend-mysql suggests no packages.
>> 
>> -- no debconf information

syntax-highlighting_5.27.0~git20161015-1_amd64.changes REJECTED

[Scott Kitterman]

Source package renamed to ksyntax-highlighting since syntax-highlighting
seemed to generic.



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Bug#828363: kde4libs: FTBFS with openssl 1.1.0

[Scott Kitterman]

On November 18, 2016 7:37:31 PM EST, John Paul Adrian Glaubitz 
 wrote:
>Hi!
>
>Would it be possible to change the build dependency from libssl-dev to
>libssl1.0-dev for the time being to temporarily resolve this issue?
>
>It's rather ugly to have a library as central as kde4libs FTBFS because
>it blocks archive rebuilds or the bootstrapping of new architectures.

I think we should wait and see what the release team has to say about the 
transition first.  They are apparently cooking something up.

Scott K

Bug#838734: fixed in plasma-discover 5.8.3-1

[Scott Kitterman]

This is currently blocked from migrating to Testing by the Qt5.7.1 transition.  
Eventually, we'll get there.

Scott K

Comments regarding prison-kf5_5.27.0~git20160918-1_amd64.changes

[Scott Kitterman]

It's not a problem from an FTP team perspective, but you might mention to
upstream that cmake/COPYING-CMAKE-SCRIPTS isn't needed in the upstream tarball
since both of the CMake scripts have the license in the individual file (which
I understand is the preferred method for KDE projects now).

Scott K

Bug#840546: Stable Debdiff For CVE-2016-7966/kdepimlibs

[Scott Kitterman]

On Wednesday, October 12, 2016 09:36:13 PM Salvatore Bonaccorso wrote:
> Hi Scott,
> 
> On Wed, Oct 12, 2016 at 02:56:06PM -0400, Scott Kitterman wrote:
> > Proposed update attached.  It is the exact upstream commit that resolved
> > this issue upstream (relevant code is unchanged from stable) and I have
> > the fix running locally.  I do not have an example of the exploit to
> > verify the adequacy of the fix, but it does appear to be regression free.
> > 
> > I have an upload for jessie-security prepared.
> 
> Thanks, please do upload in this case. Remember to build with -sa,
> since it's the first upload dak on security-master seens for
> kdepimlibs.

Uploaded.

Scott K

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

Bug#840546: KMail: HTML injection in plain text viewer

[Scott Kitterman]

Package: kdepimlibs
Version: 4:4.4.5-2
Severity: grave
Tags: security patch upstream
Justification: user security hole

KDE Project Security Advisory
=

Title:  KMail: HTML injection in plain text viewer
Risk Rating:Important
CVE:CVE-2016-7966
Platforms:  All
Versions:   kmail >= 4.4.0
Author: Andre Heinecke 
Date:   6 October 2016

Overview


Through a malicious URL that contained a quote character it
was possible to inject HTML code in KMail's plain text viewer.
Due to the parser used on the URL it was not possible to include
the equal sign (=) or a space into the injected HTML, which greatly
reduces the available HTML functionality. Although it is possible
to include an HTML comment indicator to hide content.

Impact
==

An unauthenticated attacker can send out mails with malicious content
that breaks KMail's plain text HTML escape logic. Due to the limitations
of the provided HTML in itself it might not be serious. But as a way
to break out of KMail's restricted Plain text mode this might open
the way to the exploitation of other vulnerabilities in the HTML viewer
code, which is disabled by default.

Workaround
==

None.

Solution


For KDE Frameworks based releases of KMail apply the following patch to
kcoreaddons:
https://quickgit.kde.org/?p=kcoreaddons.git=commitdiff=96e562d9138c100498da38e4c5b4091a226dde12

For kdelibs4 based releases apply the following patch:
https://quickgit.kde.org/?p=kdepimlibs.git=commitdiff=176fee25ca79145ab5c8e2275d248f1a46a8d8cf

Credits
===

Thanks to Roland Tapken for reporting this issue, Andre Heinecke from
Intevation GmbH for analysing the problems and Laurent Montel for
fixing this issue.
From: Montel Laurent 
Date: Fri, 30 Sep 2016 13:55:35 +
Subject: Backport avoid to transform as a url when we have a quote
X-Git-Url: http://quickgit.kde.org/?p=kdepimlibs.git=commitdiff=176fee25ca79145ab5c8e2275d248f1a46a8d8cf
---
Backport avoid to transform as a url when we have a quote
---


--- a/kpimutils/linklocator.cpp
+++ b/kpimutils/linklocator.cpp
@@ -94,6 +94,12 @@
 }
 
 QString LinkLocator::getUrl()
+{
+return getUrlAndCheckValidHref();
+}
+
+
+QString LinkLocator::getUrlAndCheckValidHref(bool *badurl)
 {
   QString url;
   if ( atUrl() ) {
@@ -129,13 +135,26 @@
 
 url.reserve( maxUrlLen() );  // avoid allocs
 int start = mPos;
+bool previousCharIsADoubleQuote = false;
 while ( ( mPos < (int)mText.length() ) &&
 ( mText[mPos].isPrint() || mText[mPos].isSpace() ) &&
 ( ( afterUrl.isNull() && !mText[mPos].isSpace() ) ||
   ( !afterUrl.isNull() && mText[mPos] != afterUrl ) ) ) {
   if ( !mText[mPos].isSpace() ) {   // skip whitespace
-url.append( mText[mPos] );
-if ( url.length() > maxUrlLen() ) {
+  if (mText[mPos] == QLatin1Char('>') && previousCharIsADoubleQuote) {
+  //it's an invalid url
+  if (badurl) {
+  *badurl = true;
+  }
+  return QString();
+  }
+  if (mText[mPos] == QLatin1Char('"')) {
+  previousCharIsADoubleQuote = true;
+  } else {
+  previousCharIsADoubleQuote = false;
+  }
+  url.append( mText[mPos] );
+  if ( url.length() > maxUrlLen() ) {
   break;
 }
   }
@@ -367,7 +386,12 @@
 } else {
   const int start = locator.mPos;
   if ( !( flags & IgnoreUrls ) ) {
-str = locator.getUrl();
+bool badUrl = false;
+str = locator.getUrlAndCheckValidHref();
+if (badUrl) {
+return locator.mText;
+}
+
 if ( !str.isEmpty() ) {
   QString hyperlink;
   if ( str.left( 4 ) == QLatin1String("www.") ) {

--- a/kpimutils/linklocator.h
+++ b/kpimutils/linklocator.h
@@ -107,6 +107,7 @@
   @return The URL at the current scan position, or an empty string.
 */
 QString getUrl();
+QString getUrlAndCheckValidHref(bool *badurl = 0);
 
 /**
   Attempts to grab an email address. If there is an @ symbol at the
@@ -155,7 +156,7 @@
 */
 static QString pngToDataUrl( const QString & iconPath );
 
-  protected:
+protected:
 /**
   The plaintext string being scanned for URLs and email addresses.
 */

Re: calligra-l10n_2.9.11-1_amd64.changes is NEW

[Scott Kitterman]

On Monday, October 10, 2016 11:42:13 PM Pino Toscano wrote:
> In data sabato 17 settembre 2016 16:29:13 CEST, Debian FTP Masters ha 
scritto:
> > binary:calligra-l10n-tr is NEW.
> > 
> > Your package has been put into the NEW queue, which requires manual action
> > from the ftpteam to process. The upload was otherwise valid (it had a good
> > OpenPGP signature and file hashes are valid), so please be patient.
> > 
> > Packages are routinely processed through to the archive, and do feel
> > free to browse the NEW queue[1].
> > 
> > If there is an issue with the upload, you will receive an email from a
> > member of the ftpteam.
> > 
> > If you have any questions, you may reply to this email.
> 
> Ping? This is a very simple source, data-only (= translation), and the
> only NEW package is the addition of Turkish translations.
> 
> Why is such a simple source held in NEW for three weeks already?
> Was it simply forgotten, or is there any actual issue with it?
> 
> Thanks,

There's no note indicating someone reviewed it an believed there was a 
problem.

Personally, much of the time I've had recently (admittedly not a lot) to work 
on FTP matters has been absorbed by distractions such as maintainers whining 
to the Tech Committee rather than just getting on with doing the work that 
needs to be done.  See [1] if you're curious.  Spending time on things like 
that materially decreases the time the FTP team has to work on things like 
New.

Scott K

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

Comments regarding kwin_5.8.0-1_amd64.changes

[Scott Kitterman]

I am going to accept your package, but the following copyright attribution is
missing from debian/copyright.  Please fix this in your next upload.

$ grep -ir copyright *|grep Gilg
plugins/platforms/drm/drm_object.h:Copyright (C) 2016 Roman Gilg 

plugins/platforms/drm/drm_object_connector.cpp:Copyright (C) 2016 Roman Gilg 

plugins/platforms/drm/drm_object_connector.h:Copyright (C) 2016 Roman Gilg 

plugins/platforms/drm/drm_object_crtc.cpp:Copyright (C) 2016 Roman Gilg 

plugins/platforms/drm/drm_object.cpp:Copyright (C) 2016 Roman Gilg 

plugins/platforms/drm/drm_object_plane.cpp:Copyright (C) 2016 Roman Gilg 

plugins/platforms/drm/drm_object_crtc.h:Copyright (C) 2016 Roman Gilg 

plugins/platforms/drm/drm_object_plane.h:Copyright (C) 2016 Roman Gilg 


Scott K

Bug#838734: [plasma-discover] plasma-discover uninstalls packages during upgrades without asking for confirmation

[Scott Kitterman]

Thanks.

Another scenario to consider is a user that doesn't know any better enables a 
poorly maintained third party repository that contains conflicting packages 
that cause large numbers of removals.

This can happen post-release and is a scenario the user base you're targeting 
is particularly vulnerable to.

Scott K

On September 25, 2016 2:28:37 PM EDT, Matthias Klumpp  
wrote:
>Discover is for end-users with no technical knowledge. Showing extra
>dialog boxes with crazy text won't help and just be visual clitter,
>since people will press "Yes" anyway. Also, Discover isn't really to
>blame for the underlying problem, which is a busted archive, something
>that never happens in any stable distribution.
>However, it would be nice if Discover handled this situation better on
>unstable development versions of a distro.
>
>I see the following possible solutions:
>
>1) Have Discover detect an unstable distribution, and if it finds one,
>show an extra confirmation box if changes that cause the removal of a
>package are detected.
>
>2) Just display removals as seperate items in the updates list
>unconditionally - people on unstable distros would just need to read
>the information then.
>
>3) Show a "This update is potentially disruptive if you are using an
>unstable distribution" or any other meaningful message when big
>changes are detected (e.g. > 10 packages being removed)
>
>Since even on stable distros sometimes transitions happen and stuff
>gets removed, adding an unconditional dialog seems like a bad idea,
>simply because it's meaningless for average users.
>
>I'll talk to the usability people about the different options, and
>hopefully we can land one of them before Plasma 5.8 is released.
>
>Cheers,
>Matthias

Bug#838734: [plasma-discover] plasma-discover uninstalls packages during upgrades without asking for confirmation

[Scott Kitterman]

On September 24, 2016 3:02:28 PM EDT, Diederik de Haas  
wrote:
>Control: reopen -1
>
>On Sat, 24 Sep 2016 15:52:33 +0100 Chris Lamb  wrote:
>> > [plasma-discover] plasma-discover uninstalls packages during
>upgrades
>> > without asking for confirmation> 
>> This is due to the ongoing Perl migration. There was a mail sent to
>> debian-devel-announce but I believe it was unfortunately blocked.
>> 
>> I'm closing your bug as this is not an issue that can be resolved by
>> plasma-discover, alas. :(
>
>From my #debian-qt-kde logs:
>[27.08 01:43]  plasma-discover is a giant piece of junk and
>imo 
>should be removed from every meta package
>[27.08 01:43]   /rant
>[27.08 01:45]  for a change I used it's function and did
>happily 
>uninstall plasma-desktop, plasma-workspace, sddm and a number of other 
>essential programs
>[27.08 01:45]  without any warning that is. Trying to fix it
>with 
>aptitude seems to be a no go as it's not able to resolve conflicts
>[27.08 01:45]  I have _never_ seen/happen that before
>
>So this happened on 24th of August and then the perl migration wasn't 
>happening, thus reopening the bug.

In any case, the message about the Perl migration said not to file bugs about 
package uninstallability.  That's not what this bug is about.

This bug is about lack of user visibility when discover removes packages and 
the consequent risk of inappropriate removals causing system problems.

I do agree that as long as this is the case it's questionable is it's suitable 
for the default KDE install.  I'm not completely convinced it's suitable to be 
in the archive at all.

Scott K

Bug#838734: [plasma-discover] plasma-discover uninstalls packages during upgrades without asking for confirmation

[Scott Kitterman]

On September 24, 2016 1:00:21 PM EDT, Matthias Klumpp  
wrote:
>2016-09-24 18:36 GMT+02:00 Ximo Baldó :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> No. Precisely, the bug I'm reporting is that  the package manager,
>plasma-discover, does not warn user about his intention to do that
>removing operation. So,  the user never has notice about these changes
>and as far I know this situation can be considered as grave bug as it
>can lead to an unusable system.
>
>Discover is meant for users who have no idea what a "package" is, so
>prompting them with questions they don't understand will highly likely
>not happen (they would just klick "yes" anyway). I wonder though if we
>could add some safeguard, like "ask for re-confirmation if more than
>50 packages are going to be removed".
>In any case, this is not a grave bug since it only ever happens on
>development suites, which no end-user sees. It's normal/important at
>max.

Developers are users too.  If your position is that Discover isn't suitable for 
use in testing/unstable then what that means is Discover gets released 
untested.  That's not a recipe for success.

If it breaks a system without warning, that's a grave bug.  Nothing about bug 
severities says that they only apply to stable.

What I think you want is for developers and advanced users to use Discover, at 
least occasionally, during development so we know it's well integrated with 
Debian prior to release.  That's not going to happen if it silently breaks 
systems.

Scott K

Bug#829265: ark: Fix RAR-related dependencies

[Scott Kitterman]

On Friday, July 01, 2016 04:59:55 PM Alex Henry wrote:
> Package: ark
> Version: 4:16.04.2-1
> Severity: normal
> 
> Hi, I opened a bug on Ark's bug tracker today about not opening
> RAR files and it is now clear that the dependencies for this
> package are outdated. Please see the developer's reply on the bug
> report for more information:
> 
> https://bugs.kde.org/show_bug.cgi?id=364976

Thanks for the great bug report.  The fix is committed to our packaging 
repository for the next upload.

Scott K

Bug#829220: kdelibs5-dev: FindQCA2 does not detect libqca-qt5

[Scott Kitterman]

On July 1, 2016 10:19:56 AM EDT, Gregor Riepl  wrote:
>Package: kdelibs5-dev
>Version: 4:4.14.21-1
>Severity: normal
>Tags: patch
>
>Dear Maintainer,
>
>The cmake script FindQCA2.cmake does not detect the Qt5 version of
>libqca2.
>
>This patch (against a different package, but the content is the same,
>AFAICT)
>should fix this:
>https://raw.githubusercontent.com/UkrainianFedora/leechcraft-azoth/master/007
>-find-qca-qt5.patch
>
>Another possible fix would be to provide a separate FindQCA2-QT5.cmake
>script.

kdelibs5-dev is a Qt4 based package.  Why would it need to find the Qt5 version 
of qca2?

Scott K

qtbase-opensource-src_5.7.0+dfsg-1_amd64.changes REJECTED

[Scott Kitterman]

Technically, the new binary looks fine, but debian/copyright is in serious
need of update for this new release.  Intel's copyrights cover many more files
than listed.  There are many new copyright holders, most notably for several
new platforms.  Please review the licenses in the new files and update debian/
copyright.

Scott K

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Re: Kopete & libmsn

[Scott Kitterman]

On Monday, June 20, 2016 12:43:57 AM Pau Garcia i Quiles wrote:
> Hello,
> 
> The libmsn library used to provide access to the MSN Network, which was
> shut down in October 2014.
> 
> To this day, Kopete still depends on libmsn, which is providing absolutely
> no service whatsoever.
> 
> I would like to request the removal of the dependency, so that I can also
> remove libmsn from the archive.

I've pushed the change to git for the next upload.

Scott K

Bug#797389: calligra: FTBFS, multiple issues.

[Scott Kitterman]

On Tuesday, June 14, 2016 01:21:26 AM peter green wrote:
> Martin Michlmayr wrote (as bug 818395)
> 
> > calligra fails to build.  I don't see any obvious errors (but I didn't
> > look
> 
> > through the 22 MB of logs) but it ends with:
> I already mentioned this in my posts to 797389. It seems that marble no
> longer supports qt4. The fix I applied for raspbian was to disable the
> map functionality in calligra, not great but IMO better than losing the
> package completely.
> 
> I wrote (in bug 797389)
> 
> > In addition to this debdiff during the most recent binnmu of calligra in
> > raspbian stretch I found I needed to fix pstoedit. See
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813316  for details.
> 
> pstoedit has now been fixed.
> 
> I've just done a new upload of calligra in Raspbian that on top of
> previous fixes removes the dependency on which no longer exists. Debdiff at
> 
> I am reluctant to NMU this In Debian myself because I don't use calligra
> personally and I have not had any feedback from anyone on the patched
> package.

Considering it doesn't build at all and the binaries have been removed from 
Testing and Unstable, I think the chance of you making it worse is nil.  If 
you can get it building again, then I wouldn't wait.

Scott K

kdepim-addons_16.04.1-1_amd64.changes REJECTED

[Scott Kitterman]

As with libkf5incidenceeditor, this is pointed at unstable in the changes file
instead of experimental where it clearly belongs.  Please reupload to
experimental.  It's not otherwise been reviewed yet.

Scott K

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

libkf5incidenceeditor_16.04.1-1_amd64.changes REJECTED

[Scott Kitterman]

Unfortunately, I am going to have to reject your package since it depends/
build-depends on unavailable packages.

Despite debian/changelog saying experimental, the changes said unstable and
it looks like experimental is where this needs to go since many of the depends
and build-depends are only available in experimental.

Otherwise, it's fine, so please re-upload to experimental.

Scott K

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Comments regarding kf5-messagelib_16.04.1-1_amd64.changes

[Scott Kitterman]

In cmake/modules there are multiple references to:

# Redistribution and use is allowed according to the terms of the BSD license.
# For details see the accompanying COPYING-CMAKE-SCRIPTS file.

but there is no COPYING-CMAKE-SCRIPTS file accompanying.  I am not rejecting
the upload as, based on what's in other KDE related packages I'm convinced you
have documented this correctly in debian/copyright, but it should still be
fixed upstream for the next release.  I believe the current KDE standard is to
include the appropriate license text directly in each file to avoid problems
like this the future.

Scott K

Re: Bug#825354: mudlet: FTBFS on armel/armhf: glu development package not found

[Scott Kitterman]

On Saturday, June 04, 2016 03:59:49 PM Emilio Pozuelo Monfort wrote:
> On 26/05/16 14:49, Craig Small wrote:
> > On Thu, May 26, 2016 at 8:57 PM Emilio Pozuelo Monfort  > 
> > > wrote:
> > Project ERROR: glu development package not found
> > 
> > That library is part of libglu1-mesa-dev which is a dependency for
> > qtbase5-dev.
> > 
> > Except for armel which, for some reason, qtbase5-dev does not include it.
> > 
> > Architecture: amd64
> > Depends: libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev,
> > 
> > Architecture: armel
> > Depends: libgles2-mesa-dev | libgles2-dev,
> > 
> > I think it should be just a matter of adding libglu1-mesa-dev to the build
> > dependencies and we're done.
> 
> Maybe this ought to get reassigned to qtbase5-dev?

Qt (both Qt4 and Qt5) only support GLES on armel.  The absence is intentional.  
Packages that need Qt and GL either need to adapt to using GLES or be removed.  
Please don't reassign.

Scott K

Comments regarding libkf5pimcommon_16.04.1-1_amd64.changes

[Scott Kitterman]

Needs a COPYING file like the other recent kdepim packages.  Please
address upstream.

Scott K

Comments regarding libkf5mailimporter_16.04.1-1_amd64.changes

[Scott Kitterman]

Please have upstream add the appropriate COPYING file for the next release.
This seems to be a common problem when KDE is splitting packages.

Scott K

Comments regarding libkf5libkdepim_16.04.1-1_amd64.changes

[Scott Kitterman]

The appropriate copying files were not added to this package when it was
split out from the old kdepim suite packages.  Please have upstream address
this in the next release.

Scott K

Comments regarding kf5-kdepimlibs_16.04.1-2_amd64.changes

[Scott Kitterman]

While it's not reject worthy on it's own, I note that the copyright file is
out of date.  There are many instances of:

Copyright (C) 2016 eyeOS S.L.U., a Telefonica company, sa...@eyeos.com
Copyright (C) 2016 Laurent Montel 

Laurent Montel's copyright statement hasn't been updated for the current year
and eyeOS S.L.U isn't mentioned at all.  Please check debian/copything and
update it for the next upload.

Scott K

Bug#815030: artikulate: cannot download any courses

[Scott Kitterman]

On Sunday, May 29, 2016 03:07:35 PM Paul Wise wrote:
> On Sun, 2016-05-29 at 03:00 -0400, Scott Kitterman wrote:
> > Does it still work if you remove kinit ... ?
> 
> Yes it looks like only kio is needed.

Thanks,

Scott K

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

Bug#815030: artikulate: cannot download any courses

[Scott Kitterman]

On Sunday, May 29, 2016 02:39:22 PM Paul Wise wrote:
> On Sun, 2016-05-29 at 01:52 -0400, Scott Kitterman wrote:
> > Do you have kinit and/or kio installed?
> 
> I have only the kio libraries installed (running GNOME):
> 
> libkio5 libkf5kiocore5 libkf5kiowidgets5
> 
> > I'd appreciate it if you'd see if installing one or the other helps.
> 
> I installed both and downloading works now.

Thanks.  Does it still work if you remove kinit or do you actually need both?

Scott K

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

Bug#815030: artikulate: cannot download any courses

[Scott Kitterman]

On Thu, 18 Feb 2016 10:15:05 +0800 Paul Wise  wrote:
> Package: artikulate
> Version: 4:15.12.1-1
> Severity: serious
> 
> I cannot download any courses with artikulate and it isn't useful without 
them.
> 
> I get this error in the download courses dialog:
> 
> Loading of providers from 
file: http://edu.kde.org/artikulate/downloads/providers.xml fail
> 
> The URL in that message works, as does the URL mentioned in providers.xml.
> 
> I see these messages in the terminal where I launched artikulate:
> 
> knewstuff: Initializing KNS3::Engine from ' "artikulate.knsrc" '
> No frame loaded
> No frame loaded
> No frame loaded
> knewstuff: Loading KNewStuff3 config:Â Â "artikulate.knsrc"
> knewstuff: Categories:Â Â ()
> knewstuff: Using registry 
file:Â Â "/home/pabs/.local/share/knewstuff3/artikulate.knsregistry"
> knewstuff: Loading KNS2 registry of files for the component:Â Â "artikulate"
> knewstuff: Cache read... entries:Â Â 0
> knewstuff: loading providers 
from  "http://edu.kde.org/artikulate/downloads/providers.xml;
> knewstuff: XmlLoader::load(): 
url:Â Â QUrl("http://edu.kde.org/artikulate/downloads/providers.xml;)
> klauncher not running... launching kdeinit
> klauncher not running... launching kdeinit
> couldn't create slave: "Cannot talk to klauncher: The name 
org.kde.klauncher5 was not provided by any .service files"

Do you have kinit and/or kio installed?  If not, I'd appreciate it if you'd 
see if installing one or the other helps.

Scott K

Bug#815029: artikulate: segfaults due to missing dependencies: qml-module-org-kde-kquickcontrolsaddons qml-module-qtqml-models2

[Scott Kitterman]

On Thu, 18 Feb 2016 10:08:40 +0800 Paul Wise  wrote:
> Package: artikulate
> Version: 4:15.12.1-1
> Severity: serious
> 
> There are two missing dependencies without which artikulate just
> segfaults on startup:
> 
> qml-module-org-kde-kquickcontrolsaddons
> qml-module-qtqml-models2

This bug has been partially addressed:

artikulate (4:16.04.1-2) unstable; urgency=medium

  * Add missing runtime dependency (qml-module-qtqml-models2)
Thanks to Andreas Cord-Landwehr for the fix

 -- Maximiliano Curia   Fri, 27 May 2016 18:14:17 +0200

I'll take care of the rest now.

Scott K

Comments regarding kwin_5.6.4-1_amd64.changes

[Scott Kitterman]

As with akonadi, the debian/copyright file needs at least minor updates. It
isn't sufficient for a reject, but please fix for the next upload.

Scott K

Comments regarding akonadi_16.04.1-1_amd64.changes

[Scott Kitterman]

I am accepting the package as I didn't find anything serious enought to
warrant rejection, but it is clear that debian/copyright was not updated
for this release.  If you grep -ir copyright *|grep 2016 over the source
that will show you a couple of examples of missing copyright holders.

Please update for the next upload.

Scott K

kholidays_16.04.1-1_amd64.changes REJECTED

[Scott Kitterman]

The package looks good except for one thing.  The license of
src/parsers/plan2/FlexLexer.h is BSD 2 Clause which isn't listed in debian/
copyright.  Additionally, the license requires the copyright notice be
included and it's not.

Please fix and upload again. Other than that, I think it's ready to go.

Scott K

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Re: looking at incoming, package kdeplasma-addons-data for experimental does not seem to have ever been build

[Scott Kitterman]

On Thursday, May 12, 2016 11:32:19 PM Eric Valette wrote:
> I have got dependency failure for a few days on
> plasma-wallpapers-addons, and others plasma-*-addons because
> kdeplasma-addons-data is not build although the packages and sources
> have been sitting in incoming for several days and packages for amd64
> have already been moved to experimental
> 
> http://incoming.debian.org/debian-buildd/pool/main/k/kdeplasma-addons/
> 
> Am I missing something?

The architecture all part of the last upload failed to build because not all 
the dependencies for it were built yet.  It's been given back now and 
hopefully it'll turn out better this time.  You can see the status at [1].

Scott K

[1] 
https://buildd.debian.org/status/package.php?p=kdeplasma-addons=experimental

Bug#810436: libindi: please switch to libusb 1.0

[Scott Kitterman]

On February 6, 2016 2:31:02 PM EST, Diederik de Haas  
wrote:
>On Fri, 5 Feb 2016 12:23:27 +0100 Maximiliano Curia
> 
>wrote:
>> Version: 0.9.8-4
>> 
>> On 08/01/16 19:37, Aurelien Jarno wrote:
>> > Package: libindi
>> > Version: 0.9.7-1
>> > Severity: wishlist
>> >
>> > libindi has a build-depends on libusb-dev. A few years ago upstream
>> > has released a new major version libusb 1.0 with a different API
>which
>> > aims to fix design deficiencies with USB 2.0 and 3.0 in mind.
>> This was changed some time ago, the 0.9.8.1-4  version was uploaded
>in
>> 2014-07-18, is there any remaining part of libindi 0.9.7 hidden
>somewhere?
>
>Maybe the 'issue' is that libindi is the source package name?
>Another explanation could be that there is a version 0.9.7-1 for
>libindi0b and 
>libindi-dev on hurd-i386.

That would do it.  You might want to file a architecture specific RM bug to 
clear it up.

Scott K

Re: Which package to file plasma startup bugreport against?

[Scott Kitterman]

On Wednesday, January 20, 2016 10:03:45 PM Peter Pöschl wrote:
> Hi Scott,
> 
> thanks for your prompt response.
> 
> On Sunday, January 10, 2016, 16:01:56 Scott Kitterman wrote:
> > On Saturday, January 09, 2016 01:44:09 PM Peter Pöschl wrote:
> > > what is the proper package to file a burgreport regarding the plasma
> > > desktop startup?
> > > 
> > > On an amd64 system running Testing, when I hit Enter on the password
> > > entry
> > > 
> > > of the sddm login screen (Elarun theme) one of 3 things happen:
> > >  1) probability about 50 %:
> > > * login screen stays, progress bar goes to 100 %.
> > > * login screen fades into a black screen, i.e. *no working desktop*.
> > > 
> > >   On this screen, a krusader window is running, started via
> > >   Autostart.
> > >   I can start a separate konsole window from krusader and
> > >   other GUI-programs, e.g. iceweasel, from the shell.
> > > 
> > > * Alt-Ctrl-Del gives me a popup to logout.
> > > * re-login then usually works, but I had one case where I had to
> > > 
> > >   repeat the logout/login again.
> > >  
> > >  2) probability about 50 %:
> > > * screen turns completely black.
> > > * login screen re-appears, progress bar now at 100 %.
> > > * login screen fades into desktop screen, everything works fine.
> > >  
> > >  3) probability small:
> > > * login screen stays, progress bar goes to 100 %.
> > > * login screen fades into desktop screen, everything works fine.
> > > 
> > > What additional data should I add to provide a meaningful bugreport?
> > > 
> > > P.S.: Please keep me on CC, as I am not subscribed on the list.
> > 
> > Make sure you have sddm 0.13 which recently transitioned to testing
> > installed. It also brings a Recommends on libpam-systemd (for systemd
> > users
> > - that being the default) which you also want.  Those two together are
> > expected to resolve some issue that had symptoms similar to yours.
> 
> I have now updated to
>ii  cgmanager   0.39-2   amd64
>ii  libpam-systemd:amd64228-4amd64
>ii  sddm0.13.0-1 amd64
>ii  sddm-theme-elarun   0.13.0-1 all
>ii  systemd 228-4amd64
> 
> The probability of 3) may have risen, but today I have seen 1) again.
> 
> - 'journalctl -xe' has this
> Jan 20 20:04:01 Gehenna kernel: [   15.206227] Adjusting tsc more than 11%
> (5285504 vs 5285151)
> Jan 20 20:04:14 Gehenna org.freedesktop.systemd1[1745]: ** (process:1778):
> WARNING **: Could not connect to cgmanager: Could not connect: No such file
> or directory

To answer your original question, based on this being the first error, I'd file 
it against cgmanager.

Scott K

P.S. I'm subscribed to the list, so no need to CC me directly

Bug#811156: FTBFS: undefined reference to `vtable for CategoryTypeComboBox'

[Scott Kitterman]

On Saturday, January 16, 2016 12:10:09 AM Martin Michlmayr wrote:
> Package: kdebugsettings
> Version: 15.08.3-1
> Severity: serious
> 
> kdebugsettings fails to build in unstable:
> > sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux
> 
> ...
> 
> > [ 51%] Building CXX object
> > src/CMakeFiles/kdebugsettings.dir/kdebugsettings_automoc.cpp.o
> > CMakeFiles/categorytypecomboboxtest.dir/__/src/categorytypecombobox.cpp.o
> > : In function `CategoryTypeComboBox::CategoryTypeComboBox(QWidget*)':
> > /<>/src/categorytypecombobox.cpp:25: undefined reference to
> > `vtable for CategoryTypeComboBox'
> > CMakeFiles/categorytypecomboboxtest.dir/__/src/categorytypecombobox.cpp.o
> > : In function `CategoryTypeComboBox::~CategoryTypeComboBox()':
> > /<>/src/categorytypecombobox.cpp:33: undefined reference to
> > `vtable for CategoryTypeComboBox' collect2: error: ld returned 1 exit
> > status
> 
> ...
> 
> > FY_SOURCE=2  -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align
> > -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith
> > -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type  
> > -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -fPIC -o
> > CMakeFiles/configurecustomsettingwidgettest.dir/configurecustomsettingwid
> > gettest_automoc.cpp.o -c
> > /<>/obj-x86_64-linux-gnu/autotests/configurecustomsettingwid
> > gettest_automoc.cpp
> > CMakeFiles/configurecustomsettingdialogtest.dir/__/src/categorytypecombob
> > ox.cpp.o: In function
> > `CategoryTypeComboBox::CategoryTypeComboBox(QWidget*)':
> > /<>/src/categorytypecombobox.cpp:25: undefined reference to
> > `vtable for CategoryTypeComboBox'
> > CMakeFiles/configurecustomsettingdialogtest.dir/__/src/categorytypecombob
> > ox.cpp.o: In function `CategoryTypeComboBox::~CategoryTypeComboBox()':
> > /<>/src/categorytypecombobox.cpp:33: undefined reference to
> > `vtable for CategoryTypeComboBox' collect2: error: ld returned 1 exit
> > status

I can't reproduce this.  I just rebuilt the package on amd64 successfully in 
an up to date Sid chroot.  How did you get the failure (what architecture, how 
did you build the package, etc)?

Scott K

Bug#810750: kdevelop-python: FTBFS with python3.5 and no python3.4 installed

[Scott Kitterman]

Package: kdevelop-python
Version: 1.7.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Here's the actual failure during configure:

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.1", 
minimum required is "3.0") 
-- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.5m.so (found 
suitable version "3.5.1+", minimum required is "3.4") 
CMake Error at parser/CMakeLists.txt:18 (message):
  Python 3.4 with --enable-shared is required to build kdev-python

Full build log can be found at [1].

Scott K

[1] 
https://buildd.debian.org/status/fetch.php?pkg=kdevelop-python=arm64=1.7.0-1%2Bb1=1452552042

Bug#810750: Acknowledgement (kdevelop-python: FTBFS with python3.5 and no python3.4 installed)

[Scott Kitterman]

The relevant test has been updated in git, so it may take a git snapshot to 
work with python3.5:

https://projects.kde.org/projects/extragear/kdevelop/plugins/kdev-python/repository/revisions/master/entry/parser/CMakeLists.txt

Re: Which package to file plasma startup bugreport against?

[Scott Kitterman]

On Saturday, January 09, 2016 01:44:09 PM Peter Pöschl wrote:
> Hi list,
> 
> what is the proper package to file a burgreport regarding the plasma desktop
> startup?
> 
> On an amd64 system running Testing, when I hit Enter on the password entry
> of the sddm login screen (Elarun theme) one of 3 things happen:
> 
>  1) probability about 50 %:
> * login screen stays, progress bar goes to 100 %.
> * login screen fades into a black screen, i.e. *no working desktop*.
>   On this screen, a krusader window is running, started via Autostart.
>   I can start a separate konsole window from krusader and
>   other GUI-programs, e.g. iceweasel, from the shell.
> * Alt-Ctrl-Del gives me a popup to logout.
> * re-login then usually works, but I had one case where I had to
>   repeat the logout/login again.
> 
>  2) probability about 50 %:
> * screen turns completely black.
> * login screen re-appears, progress bar now at 100 %.
> * login screen fades into desktop screen, everything works fine.
> 
>  3) probability small:
> * login screen stays, progress bar goes to 100 %.
> * login screen fades into desktop screen, everything works fine.
> 
> What additional data should I add to provide a meaningful bugreport?
> 
> 
> Thanks in advance,
> 
>Peter Pöschl
> 
> 
> P.S.: Please keep me on CC, as I am not subscribed on the list.

Make sure you have sddm 0.13 which recently transitioned to testing installed.  
It also brings a Recommends on libpam-systemd (for systemd users - that being 
the default) which you also want.  Those two together are expected to resolve 
some issue that had symptoms similar to yours.

Scott K

Bug#809000: kget: completely useless, no plugin to handle "http" protocol

[Scott Kitterman]

On December 25, 2015 5:12:41 PM CST, Salvo Tomaselli  
wrote:
>Package: kget
>Version: 4:15.08.0+dfsg-1
>Severity: grave
>Justification: renders package unusable
>
>Dear Maintainer,
>
>upon trying to add links to kget, I get a notification saying that the
>protocol
>is not supported.
>
>Protocol in question is http://
>
>On the terminal I have lines like this:
>
>> kget(21025) KGet::createTransfers: Warning! No plugin found to handle
>KUrl("http://mydomain/myfile;) 
>

Do you have kio installed? If not, does installing it help?

Scott K

Re: [Pkg-kde-extras] Just lost my digikam -- no longer installable :-(

[Scott Kitterman]

On December 15, 2015 7:32:49 AM EST, Eric Valette  wrote:
>On 12/15/2015 07:29 AM, Steve M. Robbins wrote:
>
>> Anyway, despite Eric V's advice to jump to digikam 5, I went ahead
>and did a
>> local rebuild of digikam 4.14 and it seems to run fine.
>
>What's the benefice of taking this path? Developpers are now focussed
>on 
>digikam 5 and the beta2 is already working fine.
>
>Anyway I do not care as I now have digikam 5.0.0-beta2 working on my 
>system...

It would get a working Digikam back, which I think is a great idea.

Scott K

Bug#748533: Processed: Re: still unable to print

[Scott Kitterman]

On November 4, 2015 11:48:17 PM EST, Jameson Graef Rollins 
 wrote:
>On Wed, Nov 04 2015, Maximiliano Curia  wrote:
>> Please avoid reopening old bugs, it's better to ask in the debian-kde
>users
>> list or in the #debian-kde irc channel, if that wouldn't help then
>open a new
>> one. The issue that was reported here was fixed: cups-bsd was added
>as a
>> recommends.
>
>Hi, Max.  Thanks for the response.
>
>I don't see the problem with re-opening old bugs if that is what is
>called for.  If the problem persists, then clearly the problem was not
>fully addressed, which is the situation here.  I was experiencing a
>failure to print from okular.  I did due diligence in searching for an
>existing bug that addressed the issue, rather than blindly filing a new
>report.  I found the bug that I referenced, and since the closing of
>that report didn't describe how the problem was fixed I reopened it as
>not fixed.  I think that was all completely justified.
>
>> Also, when you send a message to control your mail is not shown in
>the bug,
>> you need to cc the bug for that.
>
>I tried cc'ing the bug, but the message was bounced because the bug had
>been archived.
>
>> okular uses the lpr from cups, if you have a different lpr it needs
>to accept
>> the same parameters. You could try:
>> apt install cups-bsd lpr- lprng- gnuspool-
>
>This might be a fix, but I don't think it's actually a suitable
>solution
>to the overall problem.  Without cups-bsd installed, okular just
>silently fails to print.  There is no notification to the user other
>than a cryptic message to the terminal that would only ever be seen if
>you were to launch okular from the terminal (which certainly most
>people
>don't do).  It seems like a better solution could be devised.

Okular already Recommends cups-bsd, so reopening the bug that suggests it be 
added makes no sense.

Scott K

Bug#748533: Processed: Re: still unable to print

[Scott Kitterman]

On Wednesday, November 04, 2015 09:43:25 PM Jameson Graef Rollins wrote:
> On Wed, Nov 04 2015, Scott Kitterman <deb...@kitterman.com> wrote:
> > Okular already Recommends cups-bsd, so reopening the bug that suggests it
> > be added makes no sense.
> Hi, Scott.  I appreciate the response, but I still think we're missing
> the point.  The real question is, if the bug was fixed, why am I still
> suffering from it?  Just saying "install cups-bsd" is not actually a
> good solution to the problem.  If for whatever reason the user doesn't
> have cups-bsd installed, they have no way to know that the problem is
> the lack of that package.  In the interest of user it would be a lot
> more generous to provide a notification that printing is not possible
> without the cups-bsd package installed.

If you don't have cups-bsd installed, it's presumably because you have 
installation of recommend disabled.  If that's the case, then it's not at all 
surprising things don't work.

What you're asking for is not generally how Debian packages work.

Scott K

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

Re: gl/gles on arm and qwtplot3d

[Scott Kitterman]

On Sunday, October 11, 2015 11:41:49 PM Gudjon I. Gudjonsson wrote:
> Hi list
> 
> My package qwtplot3d fails to compile on the arm architecture with the
> following error message:
> /usr/include/GL/glext.h:468:19: error: conflicting declaration 'typedef
> ptrdiff_t GLsizeiptr'
>  typedef ptrdiff_t GLsizeiptr;
> 
> The full buildlog can be found at:
> https://buildd.debian.org/status/fetch.php?pkg=qwtplot3d=armel=0.2.
> 7%2Bsvn191-9=1443154695
> 
> I guess I have to compile the package against gles instead of gl on arm but
> as far as I know that is difficult.
> 
> Does anyone know a solution to this or shall I exclude arm from the list of
> architectures?

The solution, as you suggest, is to use GLES.

Scott K

Comments regarding libkdegames_15.08.0-1_amd64.changes

[Scott Kitterman]

Also there are a number of files that are License: LGPL-2+ in the package,
there is no copy of the LGPL included.  Please work with upstream to add a
COPYING.LIB file to the package that includes LGPL-2, since that's the
version that's referenced specifically.

Scott K

Bug#800083: libkf5emoticons5: Missing dependency on libkf5emoticons-bin causes crash in KDE systemsettings5

[Scott Kitterman]

On September 26, 2015 10:05:58 AM CDT, Debianuser  wrote:
>Package: libkf5emoticons5
>Version: 5.14.0-1
>Severity: normal
>
>Dear Maintainer,
>
>- I use Debian sid in the most recent version.
>- I have configured aptitude not to install recommended packages by
>default.
>- due to this configuration, via dependencies, libkf5emoticons5 was
>installed,
>but libkf5emoticons-bin not (only recommended)
>- Opening systemsettings5 and accessing Appearance -> Icons ->
>Emoticons causes
>a crash in KDE.
>- after manually installing libkf5emoticons-bin, everything works as
>expected.
>
>-> libkf5emoticons5 should have a "Depends", not a "Recommends" to
>libkf5emoticons-bin

The reason it isn't a Depends is to avoid a dependency loop.  We can adjust the 
symbols file of libkf5emoticons5 so that anything that Depends on it will also 
Depend on libkf5emoticons-bin to avoid this problem without causing a loop.

We recently resolved similar issues in kwallet and kservice using this approach.

Scott K

Bug#800050: sddm: Please use sensible dependencies for sddm

[Scott Kitterman]

On Sat, 26 Sep 2015 02:53:54 +0200 Alf Gaida  wrote:
> Source: sddm
> Severity: normal
> 
> Defaulting to  sddm-theme-breeze | sddm-theme isn't sensible, please 
consider to use not a kde centric theme as default

>From the perspective of the maintainers, it's quite a sensible default.  It's 
certainly trivial for someone who wants something else to install it.

Scot K

Bug#799951: marked as done (ark does not start)

[Scott Kitterman]

ark (and other packages) will need to be rebuilt against the updated kservice 
before this is really fixed everywhere, but this is the only explicit packaging 
change needed.

Scott K

Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'

[Scott Kitterman]

On September 25, 2015 11:29:20 AM CDT, "Martin Steghöfer" 
 wrote:
>Dear kdelibs5-dev maintainers,
>
>One package I worked on is affected by this problem, too. That's why I 
>started investigating this issue and found out that there is a whole 
>bunch of packages that are currently (or were recently) FTBFS'ing 
>because of this problem. Some maintainers employed the workaround of 
>adding a build dependency to "libsoprano-dev" because that's the only 
>way they can fix the FTBFS themselves. But it sure feels like a hack, 
>which is why I'd prefer not to have to do this.
>
>What's the reason for this odd behaviour? I couldn't really see this 
>from this bug report, just that it had something to do with "the 
>transition from nepomuk to the new baloo package".
>
>Is this going to be fixed properly at some point? I consider adding 
>"libsoprano-dev" to the Build-Depends of all dependant packages just a 
>temporary workaround.
>
>Could we keep this bug open as a reminder that this still needs a
>proper 
>fix?
>
>To me it feels really wrong to add a build dependency to a library that
>
>is never even mentioned in any of the CMakeLists.txt files, nor is used
>
>directly by any of the code (there is even a warning telling me that I 
>shouldn't have linked against it). Or is there any justification for 
>seeing libsoprano-dev as a "real" build dependency of packages of that 
>kind, and I'm just not seeing it? Or a way to get rid of the
>"dependency"?

If there's a warning not to link against it, isn't the solution not to do that?

Scott K

Bug#799951: ark does not start

[Scott Kitterman]

On Thursday, September 24, 2015 06:17:41 PM Christoph Pfister wrote:
> Package: ark
> Version: 4:15.08.1-1
> 
> This is on a freshly bootstrapped amd64 unstable system:
> 
> lxuser@debian:~$ ark
> ark.main: Error loading Ark KPart.
> lxuser@debian:~$
> 
> (screenshot of the popup is attached).
> 
> Likely, this has something to do with the kpart infrastructure, but
> you guys know that better than I do.
> 
> Note that this is on a Xfce system, so just in case that there are
> dependency issues, I've attached the list of installed packages.

If you install libkf5parts-plugins does it work better?

Scott K

Comments regarding signon-ui_0.17+15.10.20150810-1_amd64.changes

[Scott Kitterman]

Not all of the copyright years for Nokia and Canonical are mentioned in
debian/copyright.  Please review and update for your next upload.

Scott K

Bug#797886: muon-notifier: no update notifications from icon in KDE system tray

[Scott Kitterman]

On September 22, 2015 2:58:04 AM CDT, MAG4 Piemonte  wrote:
>Hi, we also have the same problem with version 4:5.4.1-1 ...

This is currently known not to work.  I'm trying to sort out what needs doing 
to get it working on Debian.

In the meantime, a totally unsupported work-around is to grab the 
update-notifier-common package from Ubuntu and use that.

Scott K

Bug#799542: Gwenview lost editing capabilities

[Scott Kitterman]

On Saturday, September 19, 2015 11:47:29 PM Carlos Kosloff wrote:
> Package: gwenview
> Version: 4:15.08.0-3
> Severity: important
... 
> Dear maintainer,
> 
> I did not do anything special, just tried to edit an image and noticed
> that all the edition capabilties: crop, resize, etc., were gone.
> Upgraded to latest version in stretch and same behavior.
> Please consider fixing these issues.

The U/I is somewhat more hidden, but it's there.  Look at the tabs across the 
bottom of the left side of the gwenview window and check operations.  All the 
edit choices are there and I tested cropping and it works just fine.

Scott K

Bug#799450: soprano: Causing FTBFS in reverse Build-Depends? ("No rule to make target '/usr/lib/libsoprano.so')

[Scott Kitterman]

On September 19, 2015 12:25:32 PM EDT, Chris Lamb  wrote:
>Hi Scott,
> 
>> Please unmerge the bugs and close this one.  The solution is for the
>> other packages to add the build-dep.
>
>How come the transitive Build-Depends was dropped? So, there's at least
>33 packages FTBFS due to this issue so I just want to double-check this
>it's the right thing to do before mass bug filing.
>
>.. as well as to subtly point out that pre-filing bugs against these
>packages would have been the better plan in hindsight ;)

It wasn't my change, so I don't know the details.  I do know it wasn't 
accidental.

You might ask in #debian-qt-kde.

Scott K

Bug#799450: soprano: Causing FTBFS in reverse Build-Depends? ("No rule to make target '/usr/lib/libsoprano.so')

[Scott Kitterman]

On September 19, 2015 6:09:37 AM EDT, Chris Lamb  wrote:
>Source: soprano
>Version: 2.9.4+dfsg-3+b1
>Severity: serious
>Justification: breaks other packages
>
>Hi,
>
>I'm not sure of the underlying cause and it maybe elsewhere in the
>toolchain but soprano appears to be causing a FTBFS in most (?) of its
>Build-Depends with messages such as:
>
> No rule to make target '/usr/lib/libsoprano.so'
>
>For example:
> 
>  * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799362
>  * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799360
>
>Filing this here so others (and myself!) can find it centrally.
>
This is nothing to do with the soprano package.  The other packages are missing 
a build-dep on libsoprano-dev that used to be pulled in transitively.

Please unmerge the bugs and close this one.  The solution is for the other 
packages to add the build-dep.

Scott K

Bug#798906: sddm crashes on boot

[Scott Kitterman]

Now that the sddm service is in a failed state (so the log claims), I think you 
will also need to reset-failed for it.  See  
http://www.freedesktop.org/software/systemd/man/systemctl.html.

Scott K

Bug#794055: Affects yakuake

[Scott Kitterman]

On Monday, September 14, 2015 06:21:01 PM Diederik de Haas wrote:
> affects 794055 yakuake
> thanks
> 
> I believe this bug is also the reason that yakuake doesn't retain it's width
> setting. With me it always reverts back to 80%

I think this is unlikely since yakuake is KDE 4 and konsole is Kf5.

Scott K

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

Re: calligra: working towards accurate "copyright" coverage

[Scott Kitterman]

On September 14, 2015 12:19:52 PM EDT, Adrien Grellier  wrote:
>Hi,
>
>Why I updated the copyright ?
>
>Calligra is nearly ready to be uploaded to sid. I am just like you :
>not much 
>time to dedicate to calligra. So I just take the current procedure to
>update 
>the copyright file, et voila. Users are asking for calligra in sid, and
>with 
>the GCC-5 transition, we better upload a new version soon.
>
>As I said before, I like to have a clean, reproducible procedure, and
>well 
>documented. That's why I created the README.source. I like it because I
>
>usually can't remember how to do all the stuff, and it's much simpler
>for 
>newcomer to understand the packaging. 
>
>If you want to improve the procedure, just like we all have done
>before, 
>you're totally welcome to do it!
>
>But for now, I have seen you trashing all our work, without discussing
>it 
>before. You replace it by your work, unfinished, without document it.
>It's not 
>a way of working together! So please document precisely your way of
>creating 
>and updating the copyright, so we can reproduce it quickly, and then we
>may 
>discuss it, to balance the pros and cons.
>
>You proposed to mix GPL and LGPL license in one paragraph. I am not
>sure it's 
>a good idea. If someone wants to take only the LGPL parts, for instance
>to 
>integrate non free modifications in it, he cannot use the copyright
>file for 
>it. 
>But I am not sure about the goal of the debian/copyright file: is it
>mean to 
>be readable by a human ? or only by scripts ?
>
>I agree that grouping the versions of a same license together is a good
>idea.
>
>And what the others in the team are thinking about it ?

The purpose of debian/copyright is to make Debian in compliance with the 
licenses used by upstream.  These generally require inclusion of the licenses 
and copyright notices.

While automation can sometimes produce a decent first approximation, I've yet 
to see a nontrivial case it gets right.  As a member of the FTP Team, I see a 
wide variety of things from throughout Debian and I think Dmitry is on the 
right track.

Debian/copyright is for humans (to answer one part of your question).

If not all of the third party packages are used, you might try Copyright format 
1.0 and Files-Excluded to easily keep them out of the tarball.  That way 
there's that much less to document.

Scott K