kcollectd_0.11.0-1_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 23 Feb 2020 11:55:48 -0700
Source: kcollectd
Architecture: source
Version: 0.11.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian/Kubuntu Qt/KDE Maintainers 
Changed-By: Antonio Russo 
Changes:
 kcollectd (0.11.0-1) unstable; urgency=medium
 .
   * New upstream release 0.11.0.
 - Includes better handling of long paths.
   * Remove upstreamed patches.
   * Upstream changes to manual pages.
   * Add Rules-Requires-Root: no.
   * Update upstream website.
   * Refresh upstream signing key.
   * Update debian/watch.
Checksums-Sha1:
 fc93d0f24d91403e426bb070157d9f9acf8430ba 2289 kcollectd_0.11.0-1.dsc
 26cdc239f45a99ba0c99daaceb4fadf8cd0c30bc 90436 kcollectd_0.11.0.orig.tar.xz
 9f77c9e6ecc6296142c6505085d07c6dd249ad06 13112 kcollectd_0.11.0-1.debian.tar.xz
 804234fe218f395132089567466f5ccc7d9266ef 15639 
kcollectd_0.11.0-1_source.buildinfo
Checksums-Sha256:
 2019fa01b757d6ecb1d214f8a7e757c5bbf4ec94631a69a02facc31939cf8b42 2289 
kcollectd_0.11.0-1.dsc
 18c84e671ca1a04945042a169af92f619465cebf9856544985acc0960b52144e 90436 
kcollectd_0.11.0.orig.tar.xz
 6511dfdf278a420f2deaacca10234d610427cdd25d6d63c4539bdd26b1ddde7d 13112 
kcollectd_0.11.0-1.debian.tar.xz
 287ea1da34578bc8528dad99e0a765472963a060f15dfd29265fd8a8d1f63d7c 15639 
kcollectd_0.11.0-1_source.buildinfo
Files:
 1e2250e5cd19e1d3ccacfb5af8c366b3 2289 utils optional kcollectd_0.11.0-1.dsc
 bfbe627828f423c479637cf1567fe08c 90436 utils optional 
kcollectd_0.11.0.orig.tar.xz
 273f38cff326f253ae67d7a2d5d4ad79 13112 utils optional 
kcollectd_0.11.0-1.debian.tar.xz
 eaf357dc612dbca8eaa8018d23d0d471 15639 utils optional 
kcollectd_0.11.0-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEXyqfuC+mweEHcAcHLRkciEOxP00FAl5WC5EACgkQLRkciEOx
P00qZRAAsIx+dAL/8qJzLQIuOYS346edumepnExmq/FTgcVsjk2rdQMhbuzYacQR
5US6LY5XG/J9k40RsCwLpFNzZay4A65ZIUN6qChHZ9Elb63PKw5JG1sItZ190Qxu
2QYfrRCgSZOky3fZMFcqPycpSrairyffxhXH/a396ktcBa5Q+IrXx+znMlFoqniq
PDpr+Q6u3FMTWQSlmI9FCZEo1ajYTPEBeJxvPhbtpL6v0g+ZOFVLrzK5Ew1IC30N
BRl6xVca9S8e6Wp+RUVDeq6TOJucBKInWNt/AiHnvR7qHoBm01iPOsWcdP3bbaFn
wyqe9upATaPc9q3C0RpnZENbmpywMM8XiPlZrdGKH3elGNUAu2l2Vmcea4WbNGR1
Erc8FLpA17jtDLoT5eQ5QovdYqop/FDE98mjLZxhfLyxg2Y1kWxv6KiHnj2eWsA/
O5OlB1yV0fxhTfkskGu9rz+MbSG9g66JYSc2WY3gOAJwx/OgMniuGAoBxPtyhvkK
vnfmgGUBdiQo0uCSxBlYOTWbxaxTbICPZjVvXb3/5y4wVidmABj5+9rFtuW9Y54w
Ql61otdwbjUEdU3viXFA0atQ1YFOEE2DgIqp90ioaDhw+Y4VZWamwoS3JvdiMd+G
dMdjXN426tf55/GBmQH9cNuo6njD7j2rexK1SHJsG5NEn7IUGZQ=
=ksWJ
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Bug#902635: Closing due to lack of response.

[John Paul Adrian Glaubitz]

Control: reopen -1

On 2/26/20 1:09 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi! I'm closing this bug due to lack of response. Please feel free to
> reopen it or opening a new bug if you can provide us with more
> information as required.

The issue has not been fixed. Closing a bug without fixing the issue
behind it makes no sense. Bug reports are supposed to document issues,
closing reports means hiding issues.

The issue has not been properly addressed yet because it's fundamentally
difficult to fix. The bug is a result of an underlying design problem
which is a result of upstream ignoring that the upper 16 address bits
in a 64 bit physical address are reserved by Intel.

However, they have actually understood the problem now and they are
planning to address the problem in the near future since x86_64
and arm64 are expanding their virtual address spaces as well [1].

Thanks,
Adrian

> [1] https://bugreports.qt.io/browse/QTBUG-56264

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Processed: Re: Closing due to lack of response.

[Debian Bug Tracking System]

Processing control commands:

> reopen -1
Bug #902635 {Done: Lisandro Damián Nicanor Pérez Meyer } 
[src:qtscript-opensource-src] qtscript-opensource-src: Please include patch to 
workaround memory issues on sparc64
Bug reopened
Ignoring request to alter fixed versions of bug #902635 to the same values 
previously set

-- 
902635: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902635
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processing of kcollectd_0.11.0-1_source.changes

[Debian FTP Masters]

kcollectd_0.11.0-1_source.changes uploaded successfully to localhost
along with the files:
  kcollectd_0.11.0-1.dsc
  kcollectd_0.11.0.orig.tar.xz
  kcollectd_0.11.0-1.debian.tar.xz
  kcollectd_0.11.0-1_source.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

pyside2 is marked for autoremoval from testing

[Debian testing autoremoval watch]

pyside2 5.13.2-2.2 is marked for autoremoval from testing on 2020-03-13

It is affected by these RC bugs:
950127: pyside2: pyside2 fails all autopkg tests
950129: pyside2: pyside2 ftbfs in unstable

qtscript-opensource-src_5.14.1+dfsg-1_source.changes ACCEPTED into experimental

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 25 Feb 2020 21:25:08 -0300
Source: qtscript-opensource-src
Architecture: source
Version: 5.14.1+dfsg-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Qt/KDE Maintainers 
Changed-By: Lisandro Damián Nicanor Pérez Meyer 
Changes:
 qtscript-opensource-src (5.14.1+dfsg-1) experimental; urgency=medium
 .
   * New upstream release.
 - Bump Qt build dependencies.
   * Update Standards-Version to 4.5.0, no changes required.
   * Switch to debhelper compat 12, using debhelper-compat as a build ependency.
   * Replace renamed lintian override insane-line-length-in-source-file to
 very-long-line-length-in-source-file.
   * Set Rules-Requires-Root: no.
   * Make qtscript-dev dependency on qtbase5-dev conditional with
 qtbase5-gles-dev.
   * Update symbols files with current build log.
Checksums-Sha1:
 577d8b53c6dc132ce2174ae352be7ee9dd362262 2810 
qtscript-opensource-src_5.14.1+dfsg-1.dsc
 c9308f7790b384866df1bd968d9e8f1e8bfecde6 2434020 
qtscript-opensource-src_5.14.1+dfsg.orig.tar.xz
 f0022ec98562d16b86a31311b5f35058bfeb4bf1 16384 
qtscript-opensource-src_5.14.1+dfsg-1.debian.tar.xz
 c4a8dfba9dfacfba8e695a7b1d85877d4dae6a94 11590 
qtscript-opensource-src_5.14.1+dfsg-1_source.buildinfo
Checksums-Sha256:
 b8a4a1f8c7f2d5a0adea1383f4654a7cee0b95af9a1420f325902c114b1e00a4 2810 
qtscript-opensource-src_5.14.1+dfsg-1.dsc
 a8f7c1e34b88206e2099c9c9accc5f4e68e2761fd4a15c99d9fe79f7f121ed41 2434020 
qtscript-opensource-src_5.14.1+dfsg.orig.tar.xz
 a71253ae8b61d17eb59f513f3d75bd98619c31c131a1eb8e485280977861892c 16384 
qtscript-opensource-src_5.14.1+dfsg-1.debian.tar.xz
 7ebd5bb8df41cb0eb5968a120987136fb3be24c57faef0f4ab242cb85cbfeba9 11590 
qtscript-opensource-src_5.14.1+dfsg-1_source.buildinfo
Files:
 d562203894c6b4686a84bab85708f325 2810 libs optional 
qtscript-opensource-src_5.14.1+dfsg-1.dsc
 d265dc6a5f361d24617bd93ad6f3b6ae 2434020 libs optional 
qtscript-opensource-src_5.14.1+dfsg.orig.tar.xz
 e9db40546da22afe41cd70be164c4a3a 16384 libs optional 
qtscript-opensource-src_5.14.1+dfsg-1.debian.tar.xz
 04d1301d56803ec86c2b00daf38468f3 11590 libs optional 
qtscript-opensource-src_5.14.1+dfsg-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJIBAEBCAAyFiEEEt36hKwjsrvwSzE8q2RfQGKGp9AFAl5Vux0UHGxpc2FuZHJv
QGRlYmlhbi5vcmcACgkQq2RfQGKGp9BTHQ/+L+nstdCfWVR97XNBz0ck27PS3ZVn
WqoB+SvZ22OqusehEIUHJQR60JwyyWGGDIh4OIp51m1zZHirz0d2tOhjjXL92CPG
sX20bHwWv1qQK/LryvWtX86+M82rjU6SXSNauSf106bUNfu6RSLpwAsOYxszUcwx
194cNOxFhjDM9ddA5OwPoiULUYCw80eLJUysgzURs3DbFYqzcj8Hd17Jw/h04BYf
9Iy0u1n4fwLpuZLkThDpl8bX8kiCm1HKMRdhfcLZrWZ12aibVKWxp3qFdNrGxGbI
AQB9J9B2PHHIQSKd0MzNLIzbbR4l2BHcbmPchxHyWYFxZP8iyuwSro2z2ytk3PlL
IwO6R4yqou+klfVhxbGr2jq36SfLTcVCPwPHRwKrhc8zh7oIZB4hFvGtbszvB9+n
hs142iv3BXjON4viZng0avwcXKsoRA7G9LZPZL4+zN8jbBcGRQWGKNS97YJFDEfB
a5fnqNNjwpETpsv6DY8IIBgZyogANHQvOuayDuA1aqBo9pIUj/gO3iMob0kMaWYy
uEQko/0ZMNPIvINxT5cZ5s/N+KSqJ65JCnEL+d01KtO9ZmnF7ktI8PejwUwXlcsz
Xb1ghgrJTO7QCEbPGkhvRWR2xkledMlu95nYunLGef6y64NVV736iasEhgIguam3
OcVvwXwqk3KTWF4=
=n6PS
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of qtscript-opensource-src_5.14.1+dfsg-1_source.changes

[Debian FTP Masters]

qtscript-opensource-src_5.14.1+dfsg-1_source.changes uploaded successfully to 
localhost
along with the files:
  qtscript-opensource-src_5.14.1+dfsg-1.dsc
  qtscript-opensource-src_5.14.1+dfsg.orig.tar.xz
  qtscript-opensource-src_5.14.1+dfsg-1.debian.tar.xz
  qtscript-opensource-src_5.14.1+dfsg-1_source.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Bug#902635: marked as done (qtscript-opensource-src: Please include patch to workaround memory issues on sparc64)

[Debian Bug Tracking System]

Your message dated Tue, 25 Feb 2020 21:09:35 -0300
with message-id 

and subject line Closing due to lack of response.
has caused the Debian Bug report #902635,
regarding qtscript-opensource-src: Please include patch to workaround memory 
issues on sparc64
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
902635: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902635
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: qtscript-opensource-src
Version: 5.10.1+dfsg-2
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

I just noticed there is an easy workaround to address the Javascript crashes on
sparc64 [1]. JavaScriptCore allows one to use a 32-bit JSValue - even on 64-bit
systems. In fact, this is done on PPC64 for some reason.

I have tried this for sparc64 as well and it seems that the Javascript engine
works correctly with that change.

Attaching a patch, please include in the next upload.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Use 32-bit JSValue on sparc64
 sparc64 has a very large virtual address space such that 64-bit tagged
 pointers can become corrupted. Workaround this problem by limiting
 JSValue to 32 bits.
 .
Author: John Paul Adrian Glaubitz 
Last-Update: 2018-06-28

--- 
qtscript-opensource-src-5.10.1+dfsg.orig/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h
+++ 
qtscript-opensource-src-5.10.1+dfsg/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h
@@ -960,9 +960,9 @@
 #endif
 
 #if !defined(WTF_USE_JSVALUE64) && !defined(WTF_USE_JSVALUE32) && 
!defined(WTF_USE_JSVALUE32_64)
-#if (CPU(X86_64) && !CPU(X32) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || 
OS(HPUX))) || (CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) || 
CPU(SPARC64) || CPU(MIPS64) || CPU(AARCH64) || CPU(S390X)
+#if (CPU(X86_64) && !CPU(X32) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || 
OS(HPUX))) || (CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) || 
CPU(MIPS64) || CPU(AARCH64) || CPU(S390X)
 #define WTF_USE_JSVALUE64 1
-#elif CPU(ARM) || CPU(PPC64)
+#elif CPU(ARM) || CPU(PPC64) || CPU(SPARC64)
 #define WTF_USE_JSVALUE32 1
 #elif OS(WINDOWS) && COMPILER(MINGW)
 /* Using JSVALUE32_64 causes padding/alignement issues for JITStubArg
--- End Message ---
--- Begin Message ---
Hi! I'm closing this bug due to lack of response. Please feel free to
reopen it or opening a new bug if you can provide us with more
information as required.

Thanks!

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/--- End Message ---

Bug#934110: marked as done (qtscript5-examples: examples fail to compile - w/solution)

[Debian Bug Tracking System]

Your message dated Tue, 25 Feb 2020 21:07:22 -0300
with message-id 

and subject line Examples packages are not meant to be ready to compile
has caused the Debian Bug report #934110,
regarding qtscript5-examples: examples fail to compile - w/solution
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
934110: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934110
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: qtscript5-examples
Version: 5.11.3+dfsg-3
Severity: important
Tags: patch

Several dependencies are missing from qtscript5-examples.  Here is
how to fix it.

(1) Add the following miscellaneous dependencies:
  qt5-default c++-compiler make qtscript5-dev

--Mike

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages qtscript5-examples depends on:
ii  dpkg1.19.7
ii  libc6   2.28-10
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5script5   5.11.3+dfsg-3
ii  libqt5scripttools5  5.11.3+dfsg-3
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libstdc++6  8.3.0-6

qtscript5-examples recommends no packages.

qtscript5-examples suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Hi Mike! The examples packages provide the compiled examples and their
source code, but they are not meant to be installed and then ready to
get compiled.

I'm so closing this bug.

--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/--- End Message ---

Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault

[Pino Toscano]

In data martedì 25 febbraio 2020 22:05:21 CET, Paul Gevers ha scritto:
> On 25-02-2020 20:41, Pino Toscano wrote:
> > The test is not flaky.
> 
> I can see why you say that now, but from my PoV (the release team) it is.

As I wrote, the conditions for this test to fail in the way it was
reported in bug are not definitely how a release is:

| Putting all the pieces together: why the autopkgtest can fail?
| The answer is simple: the version of src:llvm-defaults in the
| environment of the test is different than the one used to build clazy.

This is either:
- temporary, like what happens with the src:llvm-defaults bump to a
  newer LLVM version with rebuilds related to that (including clazy)
- a big problem for the Debian release altogether, because it would mean
  that src:llvm-defaults is stuck in unstable for any reason, while
  things built with it migrate happily to testing

> > Although, as I said, the issue "fixed itself" until the next
> > src:llvm-defaults switch, this is slightly less problematic.
> 
> llvm-defaults and gcc-10 were blocked for some days by the clazy
> regression on arm64. Can you explain why gcc-10 wasn't blocked by this
> issue on amd64? Also, the failures on arm64 started before the
> llvm-defaults upload [1] blocking glibc for some days. Do you also
> understand that?
> 
> [1]
> https://ci.debian.net/data/autopkgtest/testing/arm64/c/clazy/4223149/log.gz

Let's check this:

[FAIL] old-style-connect (Failed to build test. Check 
old-style-connect/namespaces.cpp.out for details)
---
Contents of old-style-connect/namespaces.cpp.out:
In file included from old-style-connect/namespaces.cpp:2:
old-style-connect/namespaces.h:22:9: warning: Old Style Connect 
[-Wclazy-old-style-connect]
connect(obj, SIGNAL(signal1()), obj1, SIGNAL(signal1()));
^~~
 ::Bar::signal1   ::Bar::signal1
old-style-connect/namespaces.cpp:32:5: warning: Old Style Connect 
[-Wclazy-old-style-connect]
QObject::connect(o1, SIGNAL(signal1()), o1, SLOT(slot1())); // Warning
^~  ~
 ::signal1::slot1
old-style-connect/namespaces.cpp:33:5: warning: Old Style Connect 
[-Wclazy-old-style-connect]
QObject::connect(o1, SIGNAL(signal1()), o2, SLOT(separateNSSlot())); // 
Warning
^~  ~~
 ::signal1::separateNSSlot
old-style-connect/namespaces.cpp:42:5: warning: Old Style Connect 
[-Wclazy-old-style-connect]
QObject::connect(o1, SIGNAL(signal1()), o1, SLOT(slot1())); // Warning
^~  ~
 ::MyObj::signal1   ::MyObj::slot1
old-style-connect/namespaces.cpp:43:5: warning: Old Style Connect 
[-Wclazy-old-style-connect]
QObject::connect(o1, SIGNAL(signal1()), o2, SLOT(separateNSSlot())); // 
Warning
^~  ~~
 ::MyObj::signal1   ::MyObj2::separateNSSlot
5 warnings generated.
/usr/bin/ld: cannot find -lgcc_s
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This looks to me like bug #951086 of src:gcc-10, which was indeed a
legit bug in gcc-10. Also, this is a totally different case than the
build log posted when opening this bug.

-- 
Pino Toscano

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

Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault

[Paul Gevers]

Hi Pino,

Thanks for the well written response.

On 25-02-2020 20:41, Pino Toscano wrote:
> The test is not flaky.

I can see why you say that now, but from my PoV (the release team) it is.

>> With a recent upload of gcc-10 to unstable, the autopkgtest of clazy
>> failed on arm64 in testing when that autopkgtest was run with the binary
>> packages of gcc-10 from unstable.
> 
> The failures have nothing to do with gcc-10.

Sorry if it wasn't more clear from the next line that I didn't imply that.

> Although, as I said, the issue "fixed itself" until the next
> src:llvm-defaults switch, this is slightly less problematic.

llvm-defaults and gcc-10 were blocked for some days by the clazy
regression on arm64. Can you explain why gcc-10 wasn't blocked by this
issue on amd64? Also, the failures on arm64 started before the
llvm-defaults upload [1] blocking glibc for some days. Do you also
understand that?

> In the meanwhile: because of what I said above, I'm demoting the
> severity of this bug to important. Also, Paul, please re-enable the
> autopkgtest of clazy on ci.debian.net, as they will pass now.

I didn't disable the autopkgtest on ci.d.n. I told our migration
software (britney) to ignore the regression on arm64. I have removed
that hint.

Paul

[1]
https://ci.debian.net/data/autopkgtest/testing/arm64/c/clazy/4223149/log.gz



signature.asc
Description: OpenPGP digital signature

Re: kde-l10n breaks/replaces for dh --with kf5

[Pino Toscano]

Hi,

please use the team ML, i.e. pkg-kde-t...@lists.alioth.debian.org for
these discussions.

In data domenica 23 febbraio 2020 21:53:51 CET, Aurélien COUDERC ha scritto:
> Dear team,
> 
> disclaimer: I’m no dh or even makefile expert.
> 
> I wanted to convert a package (juk) from dhmk to dh --with kf5, but I don’t 
> understand how to / if I can keep the automated breaks / replaces injection 
> that dhmk was doing with l10n-packages.mk and l10npkgs_firstversion_ok.
> 
> I tried the following debian/rules to no avail :
> 
> l10npkgs_firstversion_ok := 4:17.08.3-4~
> 
> include /usr/share/pkg-kde-tools/qt-kde-team/2/l10n-packages.mk
> 
> %:
> dh $@ --with kf5
> 
> 
> dpkg-gencontrol complains that:
> substitution variable ${kde-l10n:all} used, but is not defined

The kf5 dh addon has no knowledge of the kde-l10n breaks; however you
can integrate the makefile snippets with it. See for example
src:plasma-desktop, src:kstars.

HTH,
-- 
Pino Toscano

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

Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault

[Pino Toscano]

severity 952464 important
thanks

In data lunedì 24 febbraio 2020 21:10:53 CET, Paul Gevers ha scritto:
> Source: clazy
> Version: 1.6-2
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: flaky

The test is not flaky.

> Dear maintainer(s),
> 
> With a recent upload of gcc-10 to unstable, the autopkgtest of clazy
> failed on arm64 in testing when that autopkgtest was run with the binary
> packages of gcc-10 from unstable.

The failures have nothing to do with gcc-10.

> I looked into the history of your autopkgtest and it fails very often.

Err, not really, no need to exagerate things that are not like that.

The situation is more complex than that, and it needs a longer
explanation. No TL;DR is provided.

clazy is a clang plugin to detect more issues in Qt-based software,
and because of that it uses (and links to) the LLVM/clang libraries.
What is shipped is the following:

(1) /usr/bin/clazy
(2) /usr/bin/clazy-standalone
(3) /usr/lib/MULTI-ARCH/ClazyPlugin.so

(3) is the actual plugin, which is used like:
  $ clang -Xclang -load -Xclang ClazyPlugin.so -Xclang \
  -add-plugin -Xclang clazy [etc...]
This is links to the LLVM and clang libraries.

(2) is a similar version of (1), made as standalone executable rather
than a compiler plugin. It is used as compiler, so e.g.:
  $ clazy [...]

(1) is a shells script that wraps the usage of (3), with extra
parameters for version/help, and list the actual checks available.

clazy supports various LLVM versions (clazy 1.6 requires LLVM >= 5),
and it is generally updated whenever a new LLVM version is released.
For this reason, I let it built with the default LLVM version (that is
src:llvm-defaults), so using the unversioned llvm/clang -dev packages.
OTOH, (1) as shipped upstream calls the unversioned "clang++"
executable: because of this, we have local changes that record the path
to the clang++ tool of the clang version used during the built (i.e.
the Debian default one). It is easy to check this:

  $ dpkg -l | grep clazy
  ii  clazy   1.6-2+b1  amd64Clang 
plugin for additional warnings
  $ grep CLANGXX /usr/bin/clazy
  ${CLANGXX:-/usr/lib/llvm-9/bin/clang++} --version | head -1 | awk 
'{printf("clang version: %s\n",$3)}'
${CLANGXX:-/usr/lib/llvm-9/bin/clang++} -Qunused-arguments -Xclang -load 
-Xclang $ClazyPluginLib -Xclang -add-plugin -Xclang clazy $ExtraClangOptions 
"$@"

In addition to that, the clang-X package used is recorded as dependency:

  $ apt-cache show clazy | grep Depends
  Depends: libc6 (>= 2.14), libllvm9 (>= 1:9~svn298832-1~), libstdc++6 (>= 9), 
clang-9

So clazy pulls whichever version of clang it was built with, and thus
(1) works OOTB.

Now let's take a look at the autopkgtest structure:

  $ cat debian/tests/control 
  Tests: run-tests
  Depends: @, clang, clang-tools, python3, qtbase5-dev, qtdeclarative5-dev
  Restrictions: rw-build-tree, allow-stderr

  $ cat debian/tests/run-tests 
  #!/bin/sh
  
  set -e
  
  # show some facts about clang/clang++, so it is easier to debug issues
  clang -E -x c - -v < /dev/null
  clang++ -E -x c++ - -v < /dev/null
  
  cd tests
  ./run_tests.py --verbose

The upstream tests/run_tests.py executable executes the tests twice:
with (2) and (3). We can understand easily that the tests with (2) work
fine in all the cases, and indeed they pass flawlessy. The tests with
(3) use "clang++" as compiler name by default, and as such it is the
Debian default.

Putting all the pieces together: why the autopkgtest can fail?
The answer is simple: the version of src:llvm-defaults in the
environment of the test is different than the one used to build clazy.

In this particular case: clazy was rebuilt when src:llvm-defaults was
switched from 8 to 9, and because LLVM 9 was already in testing, the
binNMU migrated instantly to testing. However, src:llvm-defaults took
its 5 days to migrate to testing, so "clang" was still 8.
I see src:llvm-defaults migrated to testing today: this means that the
failures "disappear", since in both suites the versions of
(a) src:llvm-defaults used when building clazy
(b) src:llvm-defaults present
are the same.

What I will not do: switch away from the unversioned llvm version.
This means manually changing the used llvm version, which is a PITA,
and generally not needed for what clazy needs.

It seems like run_tests.py allows changing the "clang" executable used
with the CLANGXX environment variable. This seems a promising move,
however detecting what was the clang version used to build clazy only
by looking at the installed clazy seems hard. I will try to come up
with something in the next days to allow testing with the right
version. Although, as I said, the issue "fixed itself" until the next
src:llvm-defaults switch, this is slightly less problematic.

In the meanwhile: because of what I said above, I'm demoting the
severity of this bug to important. Also, 

Processed: Re: Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 952464 important
Bug #952464 [src:clazy] clazy: flaky arm64 autopkgtest: unable to execute 
command: Segmentation fault
Severity set to 'important' from 'serious'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
952464: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952464
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault

[Lisandro Damián Nicanor Pérez Meyer]

On 20/02/25 01:46, Lisandro Damián Nicanor Pérez Meyer wrote:
> On 20/02/24 09:10, Paul Gevers wrote:
> > Source: clazy
> > Version: 1.6-2
> > Severity: serious
> > Tags: sid bullseye
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: flaky
> > 
> > Dear maintainer(s),
> 
> Hi Paul, thanks for the bug report.
>  
> > With a recent upload of gcc-10 to unstable, the autopkgtest of clazy
> > failed on arm64 in testing when that autopkgtest was run with the binary
> > packages of gcc-10 from unstable. I looked into the history of your
> > autopkgtest and it fails very often.
> 
> I'm not the direct uploader of this package, but I'll try to fix this.
> This seems to be a failure in llvm/clang though.
> 
> Team members: I'm currently looming at 
> 

I *think* the bug is related to the clang/llvm version used, as I think they
mismatched in the autopkgtests. Maybe both debian/control and
debian/test/control should depend upon a specific clang version, and we should
try to rebuild clazy with each new version as possible, as we do with
qt creator.

Bug#948940: Merge requests for FTBFS in Qt/KDE packages

[John Scott]

I have now prepared merge requests for fixing ktp-common-internals, 
ktp-accounts-kcm,
and kaccounts-providers respectively [1] [2] [3]. These issues are all fixed in
new upstream releases, but I am not comfortable with such an undertaking and
hope these fixes will suffice in the meantime.

[1] 
https://salsa.debian.org/qt-kde-team/kde/ktp-common-internals/-/merge_requests/1
[2] 
https://salsa.debian.org/qt-kde-team/kde/kaccounts-providers/-/merge_requests/2
[3] https://salsa.debian.org/qt-kde-team/kde/ktp-accounts-kcm/-/merge_requests/1

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

Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault

[Lisandro Damián Nicanor Pérez Meyer]

On 20/02/24 09:10, Paul Gevers wrote:
> Source: clazy
> Version: 1.6-2
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: flaky
> 
> Dear maintainer(s),

Hi Paul, thanks for the bug report.
 
> With a recent upload of gcc-10 to unstable, the autopkgtest of clazy
> failed on arm64 in testing when that autopkgtest was run with the binary
> packages of gcc-10 from unstable. I looked into the history of your
> autopkgtest and it fails very often.

I'm not the direct uploader of this package, but I'll try to fix this.
This seems to be a failure in llvm/clang though.

Team members: I'm currently looming at 


Cheers, Lisandro.

Processed: Bug#944031 marked as pending in qtsensors-opensource-src

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #944031 [src:qtsensors-opensource-src] qtsensors-opensource-src: FTBFS on 
!linux
Ignoring request to alter tags of bug #944031 to the same tags previously set

-- 
944031: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944031
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

qtwebsockets-opensource-src_5.14.1-1_source.changes ACCEPTED into experimental

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 25 Feb 2020 17:29:44 +0300
Source: qtwebsockets-opensource-src
Architecture: source
Version: 5.14.1-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Qt/KDE Maintainers 
Changed-By: Dmitry Shachnev 
Changes:
 qtwebsockets-opensource-src (5.14.1-1) experimental; urgency=medium
 .
   * New upstream release.
   * Bump Qt build-dependencies to 5.14.1.
   * Update to debhelper compat level 12, use the new syntax.
   * Add some new symbols to debian/libqt5websockets5.symbols.
   * Bump Standards-Version to 4.5.0, no changes needed.
Checksums-Sha1:
 fb323e684877e56e16fb24ae69a52b7f58d2254e 3130 
qtwebsockets-opensource-src_5.14.1-1.dsc
 7b24385c93b75fcac9ffd7f1d1e43ae12c11c6b1 252616 
qtwebsockets-opensource-src_5.14.1.orig.tar.xz
 b936b86372b7f00c74e1372c2ba9572401544d3b 9056 
qtwebsockets-opensource-src_5.14.1-1.debian.tar.xz
 accceb4497d15d07acd548d7dd2279aae7e9ac7e 12533 
qtwebsockets-opensource-src_5.14.1-1_source.buildinfo
Checksums-Sha256:
 3ad6850d75ffa4325fa37730f3aa575cd4cee23c797e0325587da902ca5fea23 3130 
qtwebsockets-opensource-src_5.14.1-1.dsc
 742fb3d39043728ca4fc1533e9a1e3b701bc5bf4e27cba316077e9f0df0b3fef 252616 
qtwebsockets-opensource-src_5.14.1.orig.tar.xz
 71080d9df4d828c4a081cea9d841c184d6a63804347a79153e973d08c8b6c4ed 9056 
qtwebsockets-opensource-src_5.14.1-1.debian.tar.xz
 0f08e4c5553c0a4c68f4f5570f83c0f1bef4a3f4b6adad9e6fc8aa572f9268f3 12533 
qtwebsockets-opensource-src_5.14.1-1_source.buildinfo
Files:
 d2eb8c8b7e6c863f8c79864acbf349f2 3130 libs optional 
qtwebsockets-opensource-src_5.14.1-1.dsc
 bdfb60688373a49a40525195de5215e9 252616 libs optional 
qtwebsockets-opensource-src_5.14.1.orig.tar.xz
 ff6d9681f12473794f1a03a29ad9d634 9056 libs optional 
qtwebsockets-opensource-src_5.14.1-1.debian.tar.xz
 4b96108bca325f9ed5df107f3132f9b4 12533 libs optional 
qtwebsockets-opensource-src_5.14.1-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE5688gqe4PSusUZcLZkYmW1hrg8sFAl5VME8THG1pdHlhNTdA
ZGViaWFuLm9yZwAKCRBmRiZbWGuDy7fHD/4vuc9xMgEWMga9rJY41lzEdoBAOAbJ
QAH7eeLvT4qM88VTdQ0YQkFxheoFKEFAwzKTCQz0cecxyshIUU7x7SeRmHCGnjj4
omTZ5rJnuaAKuL/UhXLm293x07um8NTL5qOLLRCArNjNcF/a1OcTC/UQDK51e7NZ
gDMyjI2O3djSN7HCgD2z8Wz7QEzREQ6nLuMOLiDjreDFQplS44FML4dobDb+l76a
X+e+i/a+7sFxoKkJNoQCJ4qemzjj8S+Q9VbbcgOm25qnvXJxfRlKVZ+gqLzFam0E
hdN7z/Sg4TFmECpB5JT+vSsiIjORhOXbL8kzVNC/BKZZ2QriUGa32hQNnRNDTLOr
j7+Sc8q3YGTgwNBeBkxqWxwD6jowxKPGAvixP4pwlpdgKBqxN4dAhBeKGl229+hr
PtKNJvkrOa2cFtnTK1gkIWNNKLz6aWO8U+7kM7tNck1dyMDpE4vyBmfupocKrAeF
srOFCZI35MDqmpB01JE+cXV8G09PgR34kiWjpK3n0YSeW7T931MnxQigNu22yoRv
4l3z4pUCeyP/kK+F9pIbUUI7JBZrQn1lh4q1oEvqRSnnkbHe+uNYPav0TsI1a3Zf
4Yz+CsiF4wJRnVmjxUMqZrlnALIjEWWNf52cIWurWuRUJxiov/dyOzPC6dQt+EJ2
4UQwOmxn1nljIQ==
=R6sR
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of qtwebsockets-opensource-src_5.14.1-1_source.changes

[Debian FTP Masters]

qtwebsockets-opensource-src_5.14.1-1_source.changes uploaded successfully to 
localhost
along with the files:
  qtwebsockets-opensource-src_5.14.1-1.dsc
  qtwebsockets-opensource-src_5.14.1.orig.tar.xz
  qtwebsockets-opensource-src_5.14.1-1.debian.tar.xz
  qtwebsockets-opensource-src_5.14.1-1_source.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Re: Packaging resources

[Luc Castermans]

Hi Sandro,

I started my question from pure engineering background and interest, as I
like to understand the situation.

Your answer triggered 2 questions/observations:
- ratio of #packages / #packagers
- what is KDE?

Answering the last: for me KDE is Qt, Frameworks and Plasma.Krita, etc.
I'd exclude from it.
But only Qt, Frameworks and Plasma consists of 300+ packages (I counted
using https://kdesrc-build.kde.org/ ) and
next indeed the ratio #packages / #packagers  compared to other packages
could show the effort involved
for KDE compared to other packages.

Give the above ratio for KDE I wonder if/how further automation could help
to reduce manual effort. Another alternative I could see is to change
upstream to release Debian packages straight away.  But I guess this idea
is not new.

Regards,

Luc




Op ma 24 feb. 2020 om 00:40 schreef Sandro Knauß :

> Hey,
>
> > >  While I am studying Debian packaging I like to understand why KDE
> > >  packaging needs so much effort. For example the LibreOffice
> package
> > >  seems almost instantly available as soon as an up-stream release
> > >  became
> > >  available. Does LibreOffice need less Debian packaging effort?
> > >
> > >Well, it depends. On one side I think kde stuff is composed of many
> > >more
> > >source packages.
> >
> > Yes, having only one source package helps for testbuilding and
> > -installing massively.
> >
> > >On the other side Rene, the LO maintainer, has been doing a
> wonderful
> > >job
> > >in keeping it up to date. Now that this does not means we in the
> Qt/KDE
> >
> > Which also involves following upstream and doing packaging changes as
> > they are needed so I can just prepare an upload when it's time to do so
> > (actcually in many cases for final releases days in advance and at'ed
> > for the release time.) and by following every alpha,beta,rc etc.
>
> Well please don't forget KDE has much more software to package, that have
> very
> different needs and dependency chains. E.g. calligra a complete office
> suite
> (like libreoffice), Kontact an email client (like thunderbird), krita a
> image
> manipulation program (gimp),...
> That's why it is not fair to compare on application against something more
> than 100 applications and the KDE team is round about 5 core people. So
> the
> maintainer/package ratio inside the KDE team is not great.
> Packaging KDE stuff is NOT harder than other packaging, but it is about
> the
> amount to package and the people doing this work that makes it slow.
>
> hefee



-- 
Luc Castermans
mailto:luc.casterm...@gmail.com

Bestätigung der E-Mail-Adresse

[Immolovo]

Bitte bestätigen Sie Ihre E-Mail-Adresse, um unseren Newsletter zu erhalten
Besuchen Sie hier die 
[Webversion](https://smoton.com/y9clmgo3-n2ssu4bb-8kxpj807-5x).

[Recherche Service](https://smoton.com/y9clmgo3-n2ssu4bb-deuf6p6v-url "Immolovo 
Recherche Service")
=

Sehr geehrte Damen und Herren,
wir suchen für Sie mit einer aufwändigen Medienrecherche die privaten 
Immobilienverkäufer in Ihrer Region aus.
Für die Anmeldung zum Newsletter von Immolovo Recherche Service
bitten wir Sie um Bestätigung Ihrer Registrierung, indem Sie diesen 
[Link](https://smoton.com/y9clmgo3-n2ssu4bb-fnp9yfo2-neo) besuchen.

Sollten Sie diese E-Mail Adresse nicht registriert haben oder wollen Sie den 
Newsletter doch nicht erhalten, betrachten Sie diese E-Mail bitte als 
gegenstandslos.

Besten Dank und freundliche Grüße

Ihr Immolovo Team 

Impressum:
[Immolovo](https://smoton.com/y9clmgo3-n2ssu4bb-kh4ea3yq-89l "Impressum")
Hattwichstrasse 4
16548 Glienicke 

kirigami-gallery_19.08.3-1_amd64.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 25 Feb 2020 08:29:43 +0100
Source: kirigami-gallery
Architecture: source
Version: 19.08.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian/Kubuntu Qt/KDE Maintainers 
Changed-By: Aurélien COUDERC 
Changes:
 kirigami-gallery (19.08.3-1) unstable; urgency=medium
 .
   * Team upload.
 .
   [ Scarlett Moore ]
   * New upstream version.
   * Refresh copyright file.
- Use new format for KDEeV copyright agreed upon
 after much discussion.
- Add missing CC0-1.0 copyright information.
   * Move away from dhmk.
- Drop pkg-kde-tools include and use dh addon kf5.
- Add export to link --as-needed
   * Update build dependencies from cmake.
   * Switch to debhelper-compat.
 - Replace debhelper with the new debhelper-compat dependency.
 - drop compat file.
   * Update salsa-ci configuration to include reprotest options.
   * Add missing qttools5-dev needed by ECM to generate
 translations.
   * Fix salsa-ci yaml.
   * Add new rules-requires-root field in control to reduce
 fakeroot overhead.
 - Add entry and select no. It does not require root.
   * Update the spelling error lintian override with verbose details
 as to why is allowed to remain mispspelled.
   * Remove debian/files brought in by original neon packaging.
   * Update Standards to 4.5.0; No changes needed.
 .
   [ Aurélien COUDERC ]
   * Switch debian/watch to new KDE release service URL.
   * Add lintian override for missing manpage.
Checksums-Sha1:
 68187ff54b2a46120b68abadda20954926fa34b8 2532 kirigami-gallery_19.08.3-1.dsc
 9d32feab37d475a9391a7d55333d72bbaeba779b 276724 
kirigami-gallery_19.08.3.orig.tar.xz
 01b888dc0fc5642e17508a50d218c0524ad5b16e 488 
kirigami-gallery_19.08.3.orig.tar.xz.asc
 9a51c524e9c2ec898113b1f2d876d0db1c63bbce 5844 
kirigami-gallery_19.08.3-1.debian.tar.xz
 805f8c23c690964009ccea40348ebae9a3d3fbc3 12857 
kirigami-gallery_19.08.3-1_amd64.buildinfo
Checksums-Sha256:
 b19179b62ea7d08685103d7d16855cbe3ac94ccd5ec6176d165ac077f571ab2f 2532 
kirigami-gallery_19.08.3-1.dsc
 4ceeb854aa95902effb99cb2e5956a2f237ac3880f5b5d8e22849ed7887288df 276724 
kirigami-gallery_19.08.3.orig.tar.xz
 cad238c947097ff1b202ecc16defed5210e97e35d825b1c20fe5963ededda879 488 
kirigami-gallery_19.08.3.orig.tar.xz.asc
 5c8d7578b8ed12924b0f75b3bd38aa2d96d530bfa9805d0073457d057c5e244b 5844 
kirigami-gallery_19.08.3-1.debian.tar.xz
 fa9d11a99aca6acd52d3846ae5aa62b359aad69d48c5e3997b9ba3a981447d63 12857 
kirigami-gallery_19.08.3-1_amd64.buildinfo
Files:
 30baef919e54d3d6885deb11e421a3b0 2532 kde optional 
kirigami-gallery_19.08.3-1.dsc
 8b500842534559204b608adc14586369 276724 kde optional 
kirigami-gallery_19.08.3.orig.tar.xz
 72c883c625cc678f4b13699dcbb717ee 488 kde optional 
kirigami-gallery_19.08.3.orig.tar.xz.asc
 dd3a74fa901393063216b2c3d33f3cba 5844 kde optional 
kirigami-gallery_19.08.3-1.debian.tar.xz
 8d89f4d26d01035d3870a8c5d659cf5c 12857 kde optional 
kirigami-gallery_19.08.3-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEEIW//QAAaDgcOKDsfcaflM/KRoyQFAl5UzRsTHGNvdWNvdWZA
ZGViaWFuLm9yZwAKCRBxp+Uz8pGjJOI9EAClE2NrOT81urbcl0RzyjmT8/OH602/
ClPGekFqr0/CRjB/Dq/bIVRbCujKTEOOid0I/SsTm+zW0Kkb682ZtlkoNqO+/Miw
p55rPSnY1JbgqpnpAkgPtDC03jcH1jrJpzyH6Du6ugZCrHrD6XAtZShJZjjl6elY
7/ll10pnTsdiZt6GoFCzUQRv4wPvU+uNJ9wpJ0Zh8sjkY1ieBiRwm+swxS3TwVq5
zzwfEkNKr52eM88B7NaKoPgkWypR7Zwx4IPrbH0te9bsKswyW5Y/DujYmLni6Gfh
CxdXv8HEGRljf8t7FnFErfH0WB0AE/A3VuB5/hrjGS52p6bDbUrUTXRtwRTZiZV/
6Hd268eA/xGT/j27YLJuPi++NmMdmVkKKmc1Hc7wqbv/IA81HKCtb12hHqfWPwz/
Lh5iZTXmdO1iAa5dMiNbkluNthu5j68Gi64JxTmE4WNQgYQtT6pX/L/o+5jPqtN0
ZlqiOUBzjp+jp76lR3NiewbeXnOEg8uLGZ4iNX29v1NyzIDzyNl7/AdYQiTqJSLA
YcYIOSbMZ2TYvbMw45ab/aOnx+2I/Y8dOdS7SfPKfT6K2oATokeuiqSjJZiK2Y20
ueIeu24mmcEXV03XLOi6ge0gbeG0zrWcQOiG/6bmKP+3mxfRKAdKQXJ+PXAIG/57
F2ZXkaYCAQc/dg==
=5lNf
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of kirigami-gallery_19.08.3-1_amd64.changes

[Debian FTP Masters]

kirigami-gallery_19.08.3-1_amd64.changes uploaded successfully to localhost
along with the files:
  kirigami-gallery_19.08.3-1.dsc
  kirigami-gallery_19.08.3.orig.tar.xz
  kirigami-gallery_19.08.3.orig.tar.xz.asc
  kirigami-gallery_19.08.3-1.debian.tar.xz
  kirigami-gallery_19.08.3-1_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)