Re: Cdbs Features

[duck]

Quack,

On 2019-05-14 11:24, Sean Whitton wrote:

Switching the entire Haskell ecosystem over to use dh would be a 
massive

amount of work, as the new dh_haskell would need a lot of testing etc.
So Haskell libraries and apps would probably have to be one of the
exceptions.


It took months to get somethings working for Python and Ruby and in the 
end years to polish all the things and migrate all packages, so it's 
clearly going to take quite some time.


I think one of the major feature of CDBS is the way stages are grouped 
in make rules and you can hook onto it or even override. Coupled with 
patsubst it makes some kind of loops you can use to iterate over groups 
of packages, which is very handy when you need to build for various 
versions of an interpreter. So unlike DH you can really add or override 
parts of these loops if your package requires it. But in the end all 
these rules are complex to read and maintain, and if they were very 
useful in the past they also pushed debhelper/dh into going forward with 
more bold features and I don't think CDBS adds much to the table 
nowadays.


I would also point out that the maintenance of CDBS has been on Jonas 
Smedegaard's shoulders for years now and it has been difficult having 
almost no backup (which I'm partly responsible of). I think I was mostly 
able to convince him we should work on a retirement plan but I've had no 
time to do anything about it. Bugs like #885407 and others are still 
around while we are close to release, thus I still think this is the 
best course of action.



On the more general topic, I believe there should be room for new tools 
to emerge and not-being-dh should never be a RC or even important bug. 
Nevertheless I think this tool has grown well and a strong 
recommendation would be fine. I believe as a project we could agree on 
major goals around deprecating tools that lost traction and proper 
maintenance, old versions of the tools, old patch formats and so on, and 
encouraging contribution around it. We could also agree on some practice 
to avoid like direct source patching (especially when not on a VCS). But 
this way you're still free to use the patching system that suits you or 
build your own and suggest it to the community; that's how many of our 
tools were built.


As for using NMU I think this is a bad idea. Even if we're supposed to 
care after a NMU, this is no long-term maintenance and a returning busy 
maintainer would not really appreciate this. I believe adoption, 
becoming co-maintainer or creating a team would be better if you want to 
make drastic changes on a package and your one-off patch lingers in the 
BTS.


\_o<

--
Marc Dequènes

Accepted iwd 0.18-1 (source) into experimental

[Andreas Henriksson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 15 May 2019 06:31:11 +0200
Source: iwd
Architecture: source
Version: 0.18-1
Distribution: experimental
Urgency: medium
Maintainer: Andreas Henriksson 
Changed-By: Andreas Henriksson 
Changes:
 iwd (0.18-1) experimental; urgency=medium
 .
   * New upstream release.
Checksums-Sha1:
 06b621426305d0a6f049964252205205c31d0509 1795 iwd_0.18-1.dsc
 088315c055fcd3dade49b6acc2b8f04bd676d53a 738168 iwd_0.18.orig.tar.xz
 8a917e137775f09cf9a633c5d74cade0b3c875a2 6368 iwd_0.18-1.debian.tar.xz
 66f9b15f8c3ef6f87935ba47efd2367a0fb03d1a 6561 iwd_0.18-1_amd64.buildinfo
Checksums-Sha256:
 f4df48509088b076a42fdea0369574636d59200bb01a22c806dc196a18648370 1795 
iwd_0.18-1.dsc
 2d70cc4889692ec1fb5e2cdbe7469d7d2b35cbecca0d293a78438fbb58e63d3a 738168 
iwd_0.18.orig.tar.xz
 e3ce4bc326c82bb5247f5887e124c29e8390abc41fa9b1b53d93c6c9649f3258 6368 
iwd_0.18-1.debian.tar.xz
 08922afd3c2a20e52ccaed213c1db284f0d27814d4bfffeac68932254b7a2af1 6561 
iwd_0.18-1_amd64.buildinfo
Files:
 871d409bf720df5666c4fb0d4df992b2 1795 net optional iwd_0.18-1.dsc
 c7aba9a6c3c9a720c53b8ad70222e6d3 738168 net optional iwd_0.18.orig.tar.xz
 282460740a8ef8b258422494e6d39e7c 6368 net optional iwd_0.18-1.debian.tar.xz
 47d574a6e80a18e784ef032de79b9197 6561 net optional iwd_0.18-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE+uHltkZSvnmOJ4zCC8R9xk0TUwYFAlzbl38RHGFuZHJlYXNA
ZmF0YWwuc2UACgkQC8R9xk0TUwaAYxAAmPqamqOA4jNk8qyEUpzODOqVJ/ofrsQq
4z5Y/4jV5rBdoMQnnhVYjFHTk8lx5hspHs3DgCtKOieh2cQj97lxU6xYUQyvqSAS
rIM2N8kY0ZEquDx4cPZ5UE1RLaDpUD6jVk+cBIA+R3JfpBvOql0r7b18L1/2Gury
PlzEixQEULyV5CbFP3d0etz4tGsbGk/hlAvTjFcqVWwRzvKVb95qCsN2ALTPPBUP
XIW8khpr21Yw1T+ftM4u1H3skwdEYpmfWi83/Z8VzAmqL+pcMVYmDm8aGyX1xS/P
d0dFrav4XHnugSROcmAOgORRl8D6Ql/4qjX+ky6JVWTE4J+oBmUjkVpoMuK/ZF1f
PnqD6ChDsiwufK2DOFAcklfwC/6l9/+Q+zx8deBi+vtfehHcsIQclu1+5cbXmJy2
CNtKXnUcbYwSv8Xbkcve8A39LM9FWTveV+DaI4Yfv7D38/bR1TWNttMVSCxkdOko
ae97xHGPoLzZseH2VYf+q1CMeu/ecdhgEZqlwwkGyGa+Un9kvT82FzmwcUk+OceK
ejQRaZ5FisTwDOZKLoFkV/bEhXneFzvJKiHGLRiAPEod+KEx1BCwJcbuq8oaOJsg
oUMhEtxlA79cR17EMLpryS76PrT+skD5/FPVRSuJu+UoE2rgtLiqLm9xH+1367dy
sCP+A3/Jfa0=
=3s/H
-END PGP SIGNATURE-

Accepted xfsprogs 5.0.0-1 (source amd64) into unstable

[Nathan Scott]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 03 May 2019 11:55:58 -0500
Source: xfsprogs
Binary: xfslibs-dev xfsprogs xfsprogs-dbgsym xfsprogs-udeb
Architecture: source amd64
Version: 5.0.0-1
Distribution: unstable
Urgency: low
Maintainer: XFS Development Team 
Changed-By: Nathan Scott 
Description:
 xfslibs-dev - XFS filesystem-specific static libraries and headers
 xfsprogs   - Utilities for managing the XFS filesystem
 xfsprogs-udeb - A stripped-down version of xfsprogs, for debian-installer 
(udeb)
Changes:
 xfsprogs (5.0.0-1) unstable; urgency=low
 .
   * New upstream release
Checksums-Sha1:
 37a274c42569d3128c840ee60db6d1381d60f208 2092 xfsprogs_5.0.0-1.dsc
 13ef72f9cbde99bd6b8d4980b3e8f37113eabf98 1802508 xfsprogs_5.0.0.orig.tar.gz
 4fc612ac00bae818a1cb83b6c2408dbc9510b287 9400 xfsprogs_5.0.0-1.debian.tar.xz
 abcc145c6c0428e976c0d4a728717b6cde1ffe9e 91520 xfslibs-dev_5.0.0-1_amd64.deb
 769a873fdd5f55105f100c45c2ef02dbfdc58627 63988 
xfsprogs-dbgsym_5.0.0-1_amd64.deb
 bacea0d036d06d5a184b7a8cbe841be7c2a154b7 129036 
xfsprogs-udeb_5.0.0-1_amd64.udeb
 e8d128a90511ed1fee017bedf3abbc8ce40b9ffc 7183 xfsprogs_5.0.0-1_amd64.buildinfo
 357ad2c9ac447edc805234aa1b9ca3c2fd1dd055 876736 xfsprogs_5.0.0-1_amd64.deb
Checksums-Sha256:
 e4b97eff74e4230be4d7c7d80cc6167ff8801d201185ac602986845d6fbb5ff1 2092 
xfsprogs_5.0.0-1.dsc
 a6c9a459452ec5ce4a41332c170bf2a2f6d23676321ba4eddfbbc079f5b4766c 1802508 
xfsprogs_5.0.0.orig.tar.gz
 9324dd880c1d4e3651c8b1f651873665fd1873c9e650c0f3bcc798d2d0c781e6 9400 
xfsprogs_5.0.0-1.debian.tar.xz
 7dba9755d88861a684f8be9fa556117c0714b6747e01a9db6e323b36722ea2bf 91520 
xfslibs-dev_5.0.0-1_amd64.deb
 9d3ba70cb4bf2cb3b5bf66f53aa67ba945fa444730ca90e31bb7aba7db97769a 63988 
xfsprogs-dbgsym_5.0.0-1_amd64.deb
 5ad29eefdb09210ccca466227ce218c6d557c8f5b9dc5792baf227fa47c7e630 129036 
xfsprogs-udeb_5.0.0-1_amd64.udeb
 61a18b481160a88ce6482ce556b2df36353657561b6f98acd7360d7dfbac0686 7183 
xfsprogs_5.0.0-1_amd64.buildinfo
 c7ef765d27f9961d8a97c7860bbb4a23fed8e84537e6427e2f735ff769eeaec8 876736 
xfsprogs_5.0.0-1_amd64.deb
Files:
 59e9323e944fd036c0633587cbfbee6c 2092 admin optional xfsprogs_5.0.0-1.dsc
 e640ea8e9ee2a15bed85b0fe2dc27cca 1802508 admin optional 
xfsprogs_5.0.0.orig.tar.gz
 5cdb94916a37f9c256bb536115d77198 9400 admin optional 
xfsprogs_5.0.0-1.debian.tar.xz
 dbdd4caa917b9bc82ba3080f3f913cd4 91520 libdevel extra 
xfslibs-dev_5.0.0-1_amd64.deb
 511e7b20f8a1f22519d95483628ca53c 63988 debug optional 
xfsprogs-dbgsym_5.0.0-1_amd64.deb
 0e0b8a85ef41930e15a9e2db275b6834 129036 debian-installer optional 
xfsprogs-udeb_5.0.0-1_amd64.udeb
 1bd6768bca37dd19123276812b7c854c 7183 admin optional 
xfsprogs_5.0.0-1_amd64.buildinfo
 bb85b5a75ead462d2adc845acf349b1e 876736 admin optional 
xfsprogs_5.0.0-1_amd64.deb
Package-Type: udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJc23HMAAoJEP4IQu423YwM8Y8P/3Oe6VK2RAe4gQCzuINQYOSq
junFvYAP+eBPRTdm2sOUJSI213DzNKvHo7gX8yIisnAx5YtxepFQlMwEAxRK8u0g
Rx+4lB77GG8Fpg3om5QbStp6ujv94GCCi8C6teVKk/4Jku129scyNcnPoZ4O6IRS
JeugqaXR+TahIbI1ut/XqIW54PQwEcjBDtEUoPHRlLH+HqdZaNQUqY4sRoPL+NxQ
OhbJkObgLeicEAqhIiBL4n1YG76L3CXp3s+zjkIO6byvMcQW44ZALK0jDu/sX9TL
thgNRnE5Heo6nOr+OYUdaeZcDMgEMMlFeWCkH1LlasFxI9beYjcc8Jdrd9kBLxB6
BgvLwGCkJ9KSDXjTncsZAq5psC+3u2g4ovS7bNuCSLzWm+aJ3lypux1MJZx032dr
GaJE253xcgWtJT0Zy+OoqnBZWzx6Goll0M4KBX1Jh2IBYyT4SdbqMZaGAUtErRjm
BniNjo3DhR9TF95dKp7CK4/Ef5Shxd7Og2aFcvr035m9AfBqDcqGNhpbP8XsgvMs
Nu5gU3+cUohsysfQcPSupj7ZoAxYgq9ciJRTKrpiImXeYx/Z1TYJJFSdHwzOTZ9L
pXrd9DuhynT3fygm7MVHz56KX0iv2wzfC57qncGHVGapTK3lUtpilWN34oWSWfdR
z0Q9d4omjRSwrQx3z1TM
=rJCf
-END PGP SIGNATURE-

Accepted intel-microcode 3.20190514.1 (source amd64) into unstable

[Henrique de Moraes Holschuh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 21:49:08 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 3.20190514.1
Distribution: unstable
Urgency: high
Maintainer: Henrique de Moraes Holschuh 
Changed-By: Henrique de Moraes Holschuh 
Description:
 intel-microcode - Processor microcode firmware for Intel CPUs
Changes:
 intel-microcode (3.20190514.1) unstable; urgency=high
 .
   * New upstream microcode datafile 20190514
   * SECURITY UPDATE
 Implements MDS mitigation (RIDL, Fallout, Zombieload), INTEL-SA-00223
 CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091
   * New Microcodes:
 sig 0x00030678, pf_mask 0x02, 2019-04-22, rev 0x0838, size 52224
 sig 0x00030678, pf_mask 0x0c, 2019-04-22, rev 0x0838, size 52224
 sig 0x00030679, pf_mask 0x0f, 2019-04-23, rev 0x090c, size 52224
 sig 0x000406c3, pf_mask 0x01, 2019-04-23, rev 0x0368, size 69632
 sig 0x000406c4, pf_mask 0x01, 2019-04-23, rev 0x0411, size 68608
 sig 0x00050657, pf_mask 0xbf, 2019-02-27, rev 0x521, size 47104
   * Updated Microcodes:
 sig 0x000206a7, pf_mask 0x12, 2019-02-17, rev 0x002f, size 12288
 sig 0x000306a9, pf_mask 0x12, 2019-02-13, rev 0x0021, size 14336
 sig 0x000306c3, pf_mask 0x32, 2019-02-26, rev 0x0027, size 23552
 sig 0x000306d4, pf_mask 0xc0, 2019-03-07, rev 0x002d, size 19456
 sig 0x000306e4, pf_mask 0xed, 2019-03-14, rev 0x042e, size 16384
 sig 0x000306e7, pf_mask 0xed, 2019-03-14, rev 0x0715, size 17408
 sig 0x000306f2, pf_mask 0x6f, 2019-03-01, rev 0x0043, size 34816
 sig 0x000306f4, pf_mask 0x80, 2019-03-01, rev 0x0014, size 18432
 sig 0x00040651, pf_mask 0x72, 2019-02-26, rev 0x0025, size 21504
 sig 0x00040661, pf_mask 0x32, 2019-02-26, rev 0x001b, size 25600
 sig 0x00040671, pf_mask 0x22, 2019-03-07, rev 0x0020, size 14336
 sig 0x000406e3, pf_mask 0xc0, 2019-04-01, rev 0x00cc, size 100352
 sig 0x000406f1, pf_mask 0xef, 2019-03-02, rev 0xb36, size 30720
 sig 0x00050654, pf_mask 0xb7, 2019-04-02, rev 0x25e, size 32768
 sig 0x00050662, pf_mask 0x10, 2019-03-23, rev 0x001a, size 32768
 sig 0x00050663, pf_mask 0x10, 2019-03-23, rev 0x717, size 24576
 sig 0x00050664, pf_mask 0x10, 2019-03-23, rev 0xf15, size 23552
 sig 0x00050665, pf_mask 0x10, 2019-03-23, rev 0xe0d, size 19456
 sig 0x000506c9, pf_mask 0x03, 2019-01-15, rev 0x0038, size 17408
 sig 0x000506ca, pf_mask 0x03, 2019-03-01, rev 0x0016, size 15360
 sig 0x000506e3, pf_mask 0x36, 2019-04-01, rev 0x00cc, size 100352
 sig 0x000506f1, pf_mask 0x01, 2019-03-21, rev 0x002e, size 11264
 sig 0x000706a1, pf_mask 0x01, 2019-01-02, rev 0x002e, size 73728
 sig 0x000806e9, pf_mask 0x10, 2019-04-01, rev 0x00b4, size 98304
 sig 0x000806e9, pf_mask 0xc0, 2019-04-01, rev 0x00b4, size 99328
 sig 0x000806ea, pf_mask 0xc0, 2019-04-01, rev 0x00b4, size 99328
 sig 0x000806eb, pf_mask 0xd0, 2019-03-30, rev 0x00b8, size 98304
 sig 0x000806ec, pf_mask 0x94, 2019-03-30, rev 0x00b8, size 97280
 sig 0x000906e9, pf_mask 0x2a, 2019-04-01, rev 0x00b4, size 99328
 sig 0x000906ea, pf_mask 0x22, 2019-04-01, rev 0x00b4, size 98304
 sig 0x000906eb, pf_mask 0x02, 2019-04-01, rev 0x00b4, size 99328
 sig 0x000906ec, pf_mask 0x22, 2019-02-14, rev 0x00ae, size 98304
 sig 0x000906ed, pf_mask 0x22, 2019-03-17, rev 0x00b8, size 97280
Checksums-Sha1:
 9d8eacce78890cb1945bc52fd2cab26b6ee011e3 1789 intel-microcode_3.20190514.1.dsc
 438904e2f3f82e690127dcc660333e246455e28b 2608708 
intel-microcode_3.20190514.1.tar.xz
 930608d175318427282bed3234c9ca90563219fa 5636 
intel-microcode_3.20190514.1_amd64.buildinfo
 5fcba328dd58369ebe93e7056b438bbae516f17a 1939160 
intel-microcode_3.20190514.1_amd64.deb
Checksums-Sha256:
 7f4b68090823f6fe9fbf406870dbba8e5b83f19892d0a27d1cd594dc1860599c 1789 
intel-microcode_3.20190514.1.dsc
 3bead7f29ce9619553e62db7d44438d9143c596cf68ad30ebdc1631af782e377 2608708 
intel-microcode_3.20190514.1.tar.xz
 1abfb725a1d34fbb45db794a193f6b0949c5c95f23caee585cdac9e20a45e108 5636 
intel-microcode_3.20190514.1_amd64.buildinfo
 177f8928b3cebd47b9b0a698e9c69ddfac213489f2432ea98dc60b848861ca9a 1939160 
intel-microcode_3.20190514.1_amd64.deb
Files:
 c9b8692c31755a7ffef443f9db2815e9 1789 non-free/admin standard 
intel-microcode_3.20190514.1.dsc
 cf33472e3b36349eaa56c0d4b04e6c08 2608708 non-free/admin standard 
intel-microcode_3.20190514.1.tar.xz
 ef1e66121ceea57ecf28baf983b3fda7 5636 non-free/admin standard 
intel-microcode_3.20190514.1_amd64.buildinfo
 89c8bb92858b1f51feea3689e34645dd 1939160 non-free/admin standard 
intel-microcode_3.20190514.1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEMr8sdJFqJgkTTH+qsZwaZk2P+bEFAlzbcz4ACgkQsZwaZk2P
+bE1bxAAkKZNioyAQYP4LgL1IMrDimM3Kqzq4ecNzNZ2OF+N4v8/0z0lRSun0ce3
wPtlcR4EuRj4bcxT54QdyLhiy1gUwODwcl/+IU3tQiXQPhcVl0v0HNdLeYilJQGC
ePafh1YuotH8vGmDhTGjvP/4Cef2C7ZzOA2YOne

Re: NMUs: Do we want to Require or Recommend DH

[Scott Kitterman]

On May 15, 2019 1:13:52 AM UTC, Paul Wise  wrote:
>On Wed, May 15, 2019 at 2:31 AM Sam Hartman wrote:
>
>> How do we feel about people making build system conversions when
>those
>> conversion make it easier to fix some other bug that they are fixing
>as
>> part of an NMU?
>
>If the maintainer is MIA enough to not express an opinion when asked
>if adding a dh conversion to the NMU is fine, probably the package
>should be orphaned/salvaged instead of NMUed, which would bring the dh
>conversion into scope.

I'd think the timeline for that would be longer than the week or two it takes 
to do an NMU.

Scott K

Re: NMUs: Do we want to Require or Recommend DH

[Paul Wise]

On Wed, May 15, 2019 at 2:31 AM Sam Hartman wrote:

> How do we feel about people making build system conversions when those
> conversion make it easier to fix some other bug that they are fixing as
> part of an NMU?

If the maintainer is MIA enough to not express an opinion when asked
if adding a dh conversion to the NMU is fine, probably the package
should be orphaned/salvaged instead of NMUed, which would bring the dh
conversion into scope.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted python3.8 3.8.0~a4-3 (source) into experimental

[Matthias Klose]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 15 May 2019 00:30:25 +0200
Source: python3.8
Architecture: source
Version: 3.8.0~a4-3
Distribution: experimental
Urgency: medium
Maintainer: Matthias Klose 
Changed-By: Matthias Klose 
Changes:
 python3.8 (3.8.0~a4-3) experimental; urgency=medium
 .
   * Update symbols files.
Checksums-Sha1:
 629faa15b940f08617390bbc148d6f8a2e11323a 3438 python3.8_3.8.0~a4-3.dsc
 5dd3c0e001c546b2b156d935600857e9e6dc96a1 578904 
python3.8_3.8.0~a4-3.debian.tar.xz
 e0b6b62f69c25416cc4aee31abbb0856231779eb 10162 
python3.8_3.8.0~a4-3_source.buildinfo
Checksums-Sha256:
 16a8c6f8c83bac401396aa6f7857ac2607900fdf423128539c4d6f4513110bea 3438 
python3.8_3.8.0~a4-3.dsc
 26a4960e1eb1078f84fca780748817c79a76127de8898d0a0aea765f7acae7df 578904 
python3.8_3.8.0~a4-3.debian.tar.xz
 ee3dc3b50ebc25599c5f0f6001a68b000af22209ead2b5781cb5fb6ca48b0359 10162 
python3.8_3.8.0~a4-3_source.buildinfo
Files:
 e6af69bf0c28a5b5f25d7ee663de7ae9 3438 python optional python3.8_3.8.0~a4-3.dsc
 243e988c0e4e139ef7a15086f8ca11ce 578904 python optional 
python3.8_3.8.0~a4-3.debian.tar.xz
 30e1927f6228b614251abe49145d97fd 10162 python optional 
python3.8_3.8.0~a4-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE1WVxuIqLuvFAv2PWvX6qYHePpvUFAlzbQZ0QHGRva29AZGVi
aWFuLm9yZwAKCRC9fqpgd4+m9fWhD/9Xa2/rDlhPk61lgDaeCMLM5VQIbT97+RLs
HcDw1LgcaKeLQ+jRt1SsgcB0Fng3vw6KG0vDhYEGYH03y29E1ek6vBpEjRJI8L1V
k4ANKjY7gCQT/sfOwpqMOOkjYRESNKwkMHjJc7AXREjIhCtfSR+ARxkQCvUkfepw
8XH+bdDgW4q2G0m0ctpH8vCEsSarVqKvj0r6Pw5kYh0DtB9v4wMw4ZsJUyLmHG9a
6pfJ0MKgL8vRexsrZE3LsUthvJr3P7og88+q5OLJLqA+NDBqW7U6MEPQed8MlmBF
5n0Fn1thEK/YuoI8GxLl19eJ9baB237QcBha9Ojw0Zd7coPN4P66dfo44vtnvJZI
5W5iSn5q/NSAc/aFW8w/IOPh9l2cTj2ye+ymP7FAoNpKDf9cuxDHjjFl2RrCRkNG
ft9UxeqSLW0bq4dmSqmwKJzw94QgjL0dN/V9CIRTn8iURGhHPRjjVaO0nBu2nM2w
mku2Tnjd9hUHrO9cXqJ0Pqb7iWKCGoIcjhenJNWsIKz9BAS5UiOXyv1Ir1vAdEcK
xF4OjKoyYXBxX4ILTJiinfayNXTr5bNJnuCYdi1PSVhFshdV2/f/JPbutDWW2PRH
wU+CnGcanKJDFMF63LzYw57TLxn8iz/UPpRKMtFzBgRPCKxbAAU7RtymMaUrWNOb
/zqPZmIOgQ==
=kzGR
-END PGP SIGNATURE-

Accepted note 1.3.26-3 (source) into unstable

[Emmanuel Arias]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 30 Jan 2019 01:31:36 +
Source: note
Architecture: source
Version: 1.3.26-3
Distribution: unstable
Urgency: medium
Maintainer: Emmanuel Arias 
Changed-By: Emmanuel Arias 
Changes:
 note (1.3.26-3) unstable; urgency=medium
 .
   * Update fix-spelling.patch.
Checksums-Sha1:
 83db1136ee72c3847db184ee4c61d326a5e1 1839 note_1.3.26-3.dsc
 6c436d57b15282826faa45fa07fa2650f3aec12c 8712 note_1.3.26-3.debian.tar.xz
Checksums-Sha256:
 0f00f2559ca44498c76cf8ea31a569fb6ec144cae761c0228579db33bd5f 1839 
note_1.3.26-3.dsc
 823fd81230fca89df5917a2f6c8e7543cbf1ae692ea8f021a020c07085c2d98c 8712 
note_1.3.26-3.debian.tar.xz
Files:
 a3d53ee04f2fedea56154fad5647b9ae 1839 utils optional note_1.3.26-3.dsc
 d51c702dd0b30924aa01dde2298063f3 8712 utils optional 
note_1.3.26-3.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEEZaEt9P4xrWusTXauM1X01jtYIcwFAlzbM98PHGJhcnRtQGtu
YXJzLmJlAAoJEDNV9NY7WCHMgpgP/is9nf2sZKQZAOh7A66b8r5Aywi8KovR8Rvv
UKz+ijvmDqLhxhbZoHbTIJyod946gnc+HTBdBI9mPBuyU36ue2wc2ktPUDP05I9y
bsrfGHIo8lYB8uY1z1k3S1DUZ8kbyhq1fP7Kewu0t05o/tnRopndxaER/gUf6oRD
ejHCSQ2o1gkLJyaOd67fUj7DFTzcnBu9XfM1PqkrjDlN8u+JhDSGH+I3v4iZegIS
7B6C37MBX1XScevNhlz4pLUXSqQ0zULwe2jxdvQnZyYb0jMQfZEvuL/arAxdEZ33
X1e/JDSXUIXPu/EY4CNRk6NWmJEAy6NRZwVxXc+fIs2Q5TY2egU3smAPj6QnBJnm
4F1XuIpkEHwSPnEPPWdfSs+yAbcXNQbg/vWvlNKI3tOMKl2xLiaPQus+tLkPkrIu
szZLLgQyPs//miM/ylWmrcCDQ28gEnv8P6OBbFNO8gJc8CEKe+ZiJr6lKQ+5nytG
PM8bm37FWRKpQ33KGLokmmcD40cxIHvUWUkbiNcSUGNuD7W2zw5QV/rs4H8ap1IX
MDClsF2IcX/2SGJNOsiaCg6xtJG4lXUEMymixHQZ+uEMQqRu/GsW/gtZ8g3edDnK
Tie7lox+gORAaSl/ZgUqdJ+1e3DL/5BflvbyGgpDZrmkR4BayPlpCtLnBAbe3/74
OEHT3xok
=nqPw
-END PGP SIGNATURE-

Accepted libreoffice 1:6.3.0~alpha1-1 (source) into experimental

[Rene Engelhard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 13 May 2019 20:00:56 +0200
Source: libreoffice
Architecture: source
Version: 1:6.3.0~alpha1-1
Distribution: experimental
Urgency: medium
Maintainer: Debian LibreOffice Maintainers 
Changed-By: Rene Engelhard 
Closes: 795929
Changes:
 libreoffice (1:6.3.0~alpha1-1) experimental; urgency=medium
 .
   * New upstream snapshot
 - now has ui prompt for printer authentication (closes: #795929)
 .
   * debian/rules:
 - export JAVA_{SOURCE,TARGET}_VER to 1.7 if building with Java >= 12
Checksums-Sha1:
 f4ec37e119f63cc41fd353ead33f970d5ab2abc1 27238 libreoffice_6.3.0~alpha1-1.dsc
 d3e0d675cbeb55e789c9508877d9472e15706a26 12581148 
libreoffice_6.3.0~alpha1.orig-helpcontent2.tar.xz
 89dfb009e8bdbea37c42ddb05e43038cbc065715 143818784 
libreoffice_6.3.0~alpha1.orig-translations.tar.xz
 57d7b874b0ad6691745e01ab79d3c31ef4ff41eb 217801336 
libreoffice_6.3.0~alpha1.orig.tar.xz
 52073917b73d87d63e0ab2d3f9c3c148bcbcdf45 833 
libreoffice_6.3.0~alpha1.orig.tar.xz.asc
 059aaa17a46aa1fd999c180138ccd67d686dfbf6 10650088 
libreoffice_6.3.0~alpha1-1.debian.tar.xz
 ea27d2da82179b50b7c6bdb554420f77adee3c9a 42345 
libreoffice_6.3.0~alpha1-1_source.buildinfo
Checksums-Sha256:
 4069ebe226877d076ccfa4a5957383c212dc0221252d77ab85dec3ef7d49c894 27238 
libreoffice_6.3.0~alpha1-1.dsc
 5f9bb953288b7b5ecf528ead5401bca86b513a2a51e3bb19dfea9e2ec3392ae7 12581148 
libreoffice_6.3.0~alpha1.orig-helpcontent2.tar.xz
 68573678abb592f94cb468535de87dbae656f2307427ce7b6d092472038350a4 143818784 
libreoffice_6.3.0~alpha1.orig-translations.tar.xz
 d6887012069224c6a7f2bf3f4b8917b3fd092c27b9d101742fdce83d9facdd7e 217801336 
libreoffice_6.3.0~alpha1.orig.tar.xz
 e866a6116db9357e8711d78b439db041ce2dea20fbc1ed9e53e11cddf0428fef 833 
libreoffice_6.3.0~alpha1.orig.tar.xz.asc
 f836b7776d872f7c833a57f41b5bdfd939ff18c4bb7bcc65184d4271338381d5 10650088 
libreoffice_6.3.0~alpha1-1.debian.tar.xz
 1aa02d4911bf762f19cb3e975000aa01382f2a0a19c7f363e6df540d8f55d588 42345 
libreoffice_6.3.0~alpha1-1_source.buildinfo
Files:
 8c0b52e81e4b55d0e312a2cc317fc826 27238 editors optional 
libreoffice_6.3.0~alpha1-1.dsc
 68b2245245752a069454d16621f9200e 12581148 editors optional 
libreoffice_6.3.0~alpha1.orig-helpcontent2.tar.xz
 44e01d33373494a5113d3c48e6112e8b 143818784 editors optional 
libreoffice_6.3.0~alpha1.orig-translations.tar.xz
 e8d0341985eb7248e13cdb3a109117de 217801336 editors optional 
libreoffice_6.3.0~alpha1.orig.tar.xz
 e5b316366e713b58fe4090c4ddac17d6 833 editors optional 
libreoffice_6.3.0~alpha1.orig.tar.xz.asc
 f9bd3a4eebff3a03310cfe2e62606c9a 10650088 editors optional 
libreoffice_6.3.0~alpha1-1.debian.tar.xz
 5500ad021498d3b06895816371e0b958 42345 editors optional 
libreoffice_6.3.0~alpha1-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEE4S3qRnUGcM+pYIAdCqBFcdA+PnAFAlzbMnAQHHJlbmVAZGVi
aWFuLm9yZwAKCRAKoEVx0D4+cOguD/wLO7tqg5HxNEtw0pz3snJwP/KR4oG9C7Os
tUO3p5Dht2SbE6wkKt4tq+M1dfJ0fX2jyEVfQETjcwEVR4tT3G1b7NjDU4IVF8Ml
lw1vvhmdTC8EBLOMNlFvo7I4CRpLoGBufyIk8VnNXl59ov53wZ1kMd9lwsOyyBWn
USxHdeRLwrtlG3E5hmWH+wio20r3YD8j3X68ZZOTYuVshPrxFxbJ/Sn64CCKP3yy
UkMCPrZaq4EwLSbQcAbUCHdnCmJ1iR0hihe+W4QjoQggYg8WMspgdrQt9FvQC0w7
89FbjM9ZDPgTdzWLtpvcWvfkL4sSPZiy9dYo0Q+o0I3ls6dM28qu3GYzhtRCdcOU
/EoOIhd1jZMBLMoQHfksmL0L70fuXeFKF2LcBGCe75SHpWK6+C/DHfQ4LmiCP9u4
/aX9QPmtYJuZcZY3Lg4FGjM10ZBPmXLqJYgp1spFqcQAPKltxFCVuvSkNViCR+zg
lVR9y0ab1SPVfuX0qBppwmVvxLSRH719c26VV9UaausMX2DarS9tNnOZKykb0zee
PidkjEUkmeUNNpKOxWdbIcoUrYtCTGRvtUyRUw63jAOQQnoJJkml/hcG08Ab8gve
91LvBvLyAuvtljXO+g4d/NPGGHmQMGGKCMmKbhz5DwAw4si2YpYtBwo8DLIKDOKB
05od1GV72Q==
=nWLK
-END PGP SIGNATURE-

Re: binutils security support (Re: fixing debian-security-support upgrades from stretch (for good))

[Moritz Mühlenhoff]

Holger Levsen  schrieb:
> (and yes, I also agree this is quite a desaster, just like
> kde4libs/khtml only is suitable for trusted content, which IOW means,
> one should not use konqueror or kmail on the interweb.)

That is the upstream status quo and not in any way specific to Debian,
we're just the only ones transparent about it instead of wiping it
under the carpet.

Cheers,
Moritz

Re: Do we want to Require or Recommend DH

[Moritz Mühlenhoff]

Simon McVittie  schrieb:
> Packages using dh also make it a lot more straightforward to do
> archive-wide changes - similar to the benefit of using debhelper, but
> for changes that affect the "shape" of the build system rather than the
> details of individual steps. As a concrete example,

Or e.g. the changes which were necessary to inject the hardening
build flags; I submitted a few hundred to the BTS when we got started
with it, which was very simple for anything using dh (where is was
enabled by default when using compat level 9) and needed more effort
for anything based on traditional debhelper and or even not using
debhelper at all.

Cheers,
Moritz

Bug#928999: ITP: puppet-module-magnum -- Puppet module for OpenStack Magnum

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-magnum
  Version : 14.4.0
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/puppet-magnum
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet module for OpenStack Magnum

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages both the installation and configuration of OpenStack
 Magnum.
 .
 Magnum is an OpenStack project which offers container orchestration engines
 for deploying and managing containers as first class resources in OpenStack.
 It features:
  * Abstractions for bays, containers, nodes, pods, replication controllers,
and services
  * Integration with Kubernetes and Docker for backend container technology
  * Integration with Keystone for multi-tenant security
  * Integration with Neutron for Kubernetes multi-tenancy network security

Accepted cohomcalg 0.32+ds-2 (source) into unstable

[Dylan Aïssi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 22:29:08 +0200
Source: cohomcalg
Architecture: source
Version: 0.32+ds-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Dylan Aïssi 
Closes: 928881
Changes:
 cohomcalg (0.32+ds-2) unstable; urgency=medium
 .
   * Team upload.
 .
   [ Helmut Grohne ]
   * Fix FTCBFS: Pass C++ compiler as LD. (Closes: #928881)
   * Fix arch-only FTBFS: don't run pdflatex. (Closes: #928881)
Checksums-Sha1:
 eac3cb1761392bc0db81ec2aa13c84aef91b5e27 2181 cohomcalg_0.32+ds-2.dsc
 34d11d5507f4fcdca638bff95853317a75cebd88 4772 cohomcalg_0.32+ds-2.debian.tar.xz
 5f58aabf41039a0dfd6cb6405035c3de5202de3b 8842 
cohomcalg_0.32+ds-2_amd64.buildinfo
Checksums-Sha256:
 447d8727de7a7e48876d8198a495507bdc9ab7406c64a315a5c3ad4be467e28a 2181 
cohomcalg_0.32+ds-2.dsc
 862672c5f15f1915b10dbf216b56355ea3c9e843ba6ea01d915454b6b429503b 4772 
cohomcalg_0.32+ds-2.debian.tar.xz
 80626377c55308baef057db324df89772d5931017a486a6121503a5511c093fb 8842 
cohomcalg_0.32+ds-2_amd64.buildinfo
Files:
 852b5808d6bab7d64af6de2f3fbaef74 2181 math optional cohomcalg_0.32+ds-2.dsc
 98f9bee7ef14ac4ebe9f9b600b2dd199 4772 math optional 
cohomcalg_0.32+ds-2.debian.tar.xz
 10b68d7bff5c11f9f642057f6c67bf80 8842 math optional 
cohomcalg_0.32+ds-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEmjwHvQbeL0FugTpdYS7xYT4FD1QFAlzbJt0SHGRhaXNzaUBk
ZWJpYW4ub3JnAAoJEGEu8WE+BQ9UU6wP/3JIHFmyhh7beV9RD0/XQUJ1BriMaLBJ
9h/qaLCCIGYS+RznrCw06DolrnkfrgMJh93tphneE4Levx6Mo/ShjxoXJAdh4NSV
2O8WUAFMbosXTkKf0QtZ6V892sG3txkNzo0WOJwKBnrHw/zmAIYsgFMnr5FwtKav
pPucGc36rg2c07vhs8iwacl3P1U4kx3fIeQvNGqlKRs69SnPl5KKJ3sXcQGvWhBx
YE2O7Q78B+8/ME6RaXl4BD1c0h8r/rEQ8zIAmAD3vvrF5hc6vx6vp40A1E/sDjh/
rGtcSlaI2ShO9H8gls6myG1HV7ilBy8tRl7BIcAHTL7YGTtO8QLvHcQ1JJwa9CVb
T6DmHH8oAvBj9CP6bw0/049s1shOzMnFajlC6uaMUEe/QZSzHetA2ITD0n/r3dcY
oMBt71R7buIDB7OASfmRQXK63uzUK3CGWIf9+mvHyil3/eKkkWDco4WB7WuIfwnb
3JmqCvtX4LKpTbVsWYoK1ul83EtkB4JYgCioSzbPEDL9y+jPQxhnUQEyZm4xTYcR
GKLlnZAWpvYxKAVzVZ/FZHQ1BSoBh+zaPmBhUnv9yabjVogfUvy4duXyLySxDsuW
bk0O6RfM9ig8XFuqnf5f4LgvpOH+HDnrPrUwDlmVLCfFcrO511q8+MEU1Rsxv4DC
YdX/gDyVJXJL
=ZiwL
-END PGP SIGNATURE-

Re: Do we want to Require or Recommend DH

[Bernd Zeimetz]

On 5/13/19 11:31 PM, Thomas Goirand wrote:
>> - it's also simpler to understand.
> 
> There, I don't agree. To fully understand how the dh sequencer works,
> one must first understand the 6 mandatory debian/rules targets, and how
> they are called.

You have to understand that in any case. Doesn't matter if its dh, cdbs
or old dh_* stuff.

> dh will hide everything. It isn't simpler, it *LOOKS*
> simpler, but it's a way more complex.

No idea where you think that dh hides something - make and dh both print
what they are doing.



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: NMUs: Do we want to Require or Recommend DH

[Adrian Bunk]

On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote:
>...
> How do we feel about people making build system conversions when those
> conversion make it easier to fix some other bug that they are fixing as
> part of an NMU?

What happens if the maintainer dislikes the change?

The maintainer clearly has the right to revert such an NMU,
and the opinion about the NMU expressed in the changelog or
elsewhere might not be friendly.

There might be cases where it is appropriate, but I wouldn't issue
a general recommendation to do build system conversions in NMUs.

> That is, imagine that a package is mishandling the combination of
> systemd units and an init script.  As someone preparing an NMU, is it
> reasonable to move to dh compat 12 from some other build system if I
> believe doing so will make it easier for me to fix the bug and verify 
> the fix?

Doing a build system conversion properly requires first understanding 
what the old build system did, and later verifying that the changes 
didn't break anything.

It might bring long-term benefits, but if anyone claims that for an NMU 
this is easier than a minimal fix I strongly suspect it is only easy due 
to lack of diligence.

> --Sam

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Accepted flameshot 0.6.0+git20190514-1~exp1 (source) into experimental

[Boyuan Yang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 14:51:12 -0400
Source: flameshot
Architecture: source
Version: 0.6.0+git20190514-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: Boyuan Yang 
Changed-By: Boyuan Yang 
Changes:
 flameshot (0.6.0+git20190514-1~exp1) experimental; urgency=medium
 .
   * New upstream snapshot (20190514).
   * debian/patches: Drop all backported patches.
Checksums-Sha1:
 237dd9654916859c67e1efa00cb945b9a0526118 2004 
flameshot_0.6.0+git20190514-1~exp1.dsc
 bee8c8cf1f7ee2146aa506259c452faad9f9ef8f 673193 
flameshot_0.6.0+git20190514.orig.tar.gz
 8cc06079e3334e063e2b22e21b19d2e26f86020b 9760 
flameshot_0.6.0+git20190514-1~exp1.debian.tar.xz
 cd1e75034605cd99c1c47c94b123f616c880b3b2 11092 
flameshot_0.6.0+git20190514-1~exp1_amd64.buildinfo
Checksums-Sha256:
 70dcf3e4003ddf6ea74a798dbb13221388b5838d54c8955f326c85d68108b7eb 2004 
flameshot_0.6.0+git20190514-1~exp1.dsc
 33eba23b74642c8a4372abe8e0d9dbfee0e68e8cec94dbac18cbf91197f56c74 673193 
flameshot_0.6.0+git20190514.orig.tar.gz
 6b74c0746ee06fc4ec5a1223b0775792fa3b4fc3e9d6bf6b9c428942bb5d63dc 9760 
flameshot_0.6.0+git20190514-1~exp1.debian.tar.xz
 831b6537eb2eba8edf7a15b1f42f9c65aeca69b09a62482b5caa32bbd206 11092 
flameshot_0.6.0+git20190514-1~exp1_amd64.buildinfo
Files:
 ffd8c5911b770c0b499c61a2de8292fd 2004 graphics optional 
flameshot_0.6.0+git20190514-1~exp1.dsc
 58599e5cd303715b71fb1c06a993a9d7 673193 graphics optional 
flameshot_0.6.0+git20190514.orig.tar.gz
 2caa3dd1cf0f2529d687f5562c864a7d 9760 graphics optional 
flameshot_0.6.0+git20190514-1~exp1.debian.tar.xz
 00df736ae6de4671c331286b891cd951 11092 graphics optional 
flameshot_0.6.0+git20190514-1~exp1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAlzbESUACgkQwpPntGGC
Ws5eXxAAoc/kbvF3+yjP/J5fS3se3cj+5J1UxSSQOtrQTcvWtut4gF7k7MK2ZG95
CT3c0b3jaVIHx7/+FwXykrRQ4POw9p9+v5OHx8N17pBuuNelT7QWBYX0x43yqT3M
zX9HOtWBhUDoPEQiXqoQhZTY+AT3DYpuKZa6BlwrPGq/0zjlIKl+gIfb69j6TeZI
eZStiWMfW/q7+Rz847rRQqJNHKcJQiPlgqwy1LCmwpG7yIdZEpsV7AMY5LKlZgRI
wjnM+n7gy1vpSWuQczcFyVbRxe1TB5MGx/3Kjm0hO35tIf3jveq+WgkXcP1Gs2mO
mn9St1JEG/YEuwcwz5u07ZvTl3jqBz5tFn1vtLud/hP0J7cxXjTJcVrkNEAdJBXy
i5tey9gL499GpUZp9l2CEHyWOtUrOzNz5JboKlr/1KenNozs96lQtSZOpL7pJock
ptk2JK4pFrK939MZww+l2Ji/y46G5fHMqX0bDlNuBLz3GKZHyr6ES3NVbBz92MwA
Ocs1u1EFo0XVjnmj35x13zm1XGNNf/7ExYnqosBYN7XgJX/iUcx8WWljMY/jhtqQ
L2F1Xf+JMsuBMO0GPcMAEPptuQdGF6FnBE9Ll0IxRL+VuKbtVdU3tbQg2t89pr3d
Xlv8N31y2svcY2Gxw+RmCAWfrFf3VvMhy5wUsj0OPpsFCTOx5kk=
=Rbb5
-END PGP SIGNATURE-

Re: QA expectations (Was: Do we want to Require or Recommend DH)

[Adrian Bunk]

On Tue, May 14, 2019 at 05:19:23PM +0200, Helmut Grohne wrote:
> Let me briefly hijack the discussion for a side note. ;)
> 
> On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> > NMUers should do debdiff - no matter what change was done.  And yes, it
> > happened also to me in the past once or twice that I uploaded an empty
> > package or package missing some files.  I do not remember whether it was
> > connected to a change to dh or not ... but mistakes happen.  The fact
> > that we might end up with broken NMUs is IMHO orthogonal to any cdbs to
> > dh change.
> 
> After a failure, we tend to bash uploaders:
>  * Why didn't they look at the debdiff?
>  * Why didn't they run piuparts?
>  * Why didn't they run lintian?

Not running lintian before uploading to unstable shouldn't happen.

>  * Why didn't they run autopkgtest?
>  * Why didn't they do an arch-only/indep-only build?
>  * Why didn't they test their package?
>  * ...
> 
> The things you have to remember before doing an upload are insane.
>...

"Check that your changes are working" is pretty basic and sane.

If the only change was fixing a missing dependency, check that the built 
binary package actually has the correct dependency added.

If you rewrote the whole build system, check that the built packages
still have the same contents and still work.

If you are trying to fix a build failure on an architecture,
make a testbuild on a porterbox instead of 10 uploads to unstable.

>...
> People shouldn't have to remember all the QA. QA should just work and 
> QA should tell people about the (unusual) failures.
>...

QA is good for finding some kinds of common problems.

But it is not a replacement for people being careful when making changes.

> Helmut

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: NMUs: Do we want to Require or Recommend DH

[Andreas Tille]

Hi Sam,

On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote:
> So, I think there is an emerging consensus against the idea of people
> NMUing a package simply to convert it to dh.
> 
> First, I'd like to explicitly call for any last comments from people who would
> like to see us permit NMUs simply to move packages toward dh.

I admit despite I'm in big favour of having the majority of packages
converted to dh I would not feel my time well spent to browse the
archive for packages that might be "smelling" like candidates.

> Are there
> any cases in which such an NMU should be permitted?

If a package has a RC bug or some important bug that annoys me for a
certain reason and fixing it would be easier by just doing a dh
conversion is a pretty good candidate for me.  Or if I need to touch
such a package and the conversion is obviously very simple I would like
to do so.  I will do so in case I'm a member of the team that maintains
the package without question - otherwise I'd give the maintainer a
warning and ask for permission (but will usually write something like
"If I do not hear from you in X days I assume you agree with this.")
 
> Finally, I'd like to focus discussion on an area where emerging
> consensus is much less clear.
> 
> How do we feel about people making build system conversions when those
> conversion make it easier to fix some other bug that they are fixing as
> part of an NMU?

That's one of the cases I mentioned above.

> That is, imagine that a package is mishandling the combination of
> systemd units and an init script.  As someone preparing an NMU, is it
> reasonable to move to dh compat 12 from some other build system if I
> believe doing so will make it easier for me to fix the bug and verify
> the fix?

Good example for a valid dh conversion.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Do we want to Require or Recommend DH

[gregor herrmann]

On Tue, 14 May 2019 11:11:46 +0300, Adrian Bunk wrote:

> On Mon, May 13, 2019 at 11:08:21PM +0200, gregor herrmann wrote:
> > On Mon, 13 May 2019 22:22:32 +0300, Adrian Bunk wrote:
> > > In my experience, keeping existing packages at exotic build systems or 
> > > ancient dh compat levels causes fewer problems than people trying to 
> > > change that just for the sake of it.
> > In my experience ancient debian/rules runes are also a cause for
> > repeated RC bugs and the need for NMUs.
> > Real life example:
> > https://tracker.debian.org/media/packages/libm/libmp3-info-perl/changelog-1.24-1.2
> How well are you testing such conversions?
> Based on work I've seen from you I'd guess your NMU would be better than 
> average. Unfortunately this is not generally true.

I hope I test them well enough :)
(And thanks for the kind feedback.)
 
> There is no perfect solution here and I also get your point,
> what should be taken into consideration is that there is a
> tradeoff between the benefits and the regressions of breaking
> changes like dh compat bumps or even conversions to dh.

Agreed; additional changes are additional chances for mistakes.

Still, I wanted to make the points that
- further adoption of dh(1) would make my life easier by creating
  fewer bugs of certain categories, and
- the possibility to switch a package to dh(1) (in cases where I know
  what that means, as in the example above with a typical perl
  module; not in complex cases like Marco's examples, and not just for
  the sake of it) would make bug fixing in NMUs easier for me and
  even prevent future bugs.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Rigmor Gustafsson: The Moon Is A Harsh Mistress


signature.asc
Description: Digital Signature

Accepted linux 4.19.37-2 (source) into unstable

[Ben Hutchings]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 17:34:37 +0100
Source: linux
Architecture: source
Version: 4.19.37-2
Distribution: unstable
Urgency: high
Maintainer: Debian Kernel Team 
Changed-By: Ben Hutchings 
Closes: 928618
Changes:
 linux (4.19.37-2) unstable; urgency=high
 .
   * debian/bin: Fix Python static checker regressions (Closes: #928618)
   * Clean up speculation mitigations:
 - Documentation/l1tf: Fix small spelling typo
 - x86/cpu: Sanitize FAM6_ATOM naming
 - kvm: x86: Report STIBP on GET_SUPPORTED_CPUID
 - x86/msr-index: Cleanup bit defines
 - x86/speculation: Consolidate CPU whitelists
 - Documentation: Move L1TF to separate directory
 - cpu/speculation: Add 'mitigations=' cmdline option
 - x86/speculation: Support 'mitigations=' cmdline option
 - powerpc/speculation: Support 'mitigations=' cmdline option
 - s390/speculation: Support 'mitigations=' cmdline option
 - x86/speculation/mds: Add 'mitigations=' support for MDS
   * [x86] Mitigate Microarchitectural Data Sampling (MDS) vulnerabilities
 (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091):
 - x86/speculation/mds: Add basic bug infrastructure for MDS
 - x86/speculation/mds: Add BUG_MSBDS_ONLY
 - x86/kvm: Expose X86_FEATURE_MD_CLEAR to guests
 - x86/speculation/mds: Add mds_clear_cpu_buffers()
 - x86/speculation/mds: Clear CPU buffers on exit to user
 - x86/kvm/vmx: Add MDS protection when L1D Flush is not active
 - x86/speculation/mds: Conditionally clear CPU buffers on idle entry
 - x86/speculation/mds: Add mitigation control for MDS
 - x86/speculation/mds: Add sysfs reporting for MDS
 - x86/speculation/mds: Add mitigation mode VMWERV
 - Documentation: Add MDS vulnerability documentation
 - x86/speculation/mds: Add mds=full,nosmt cmdline option
 - x86/speculation: Move arch_smt_update() call to after mitigation 
decisions
 - x86/speculation/mds: Add SMT warning message
 - x86/speculation/mds: Fix comment
 - x86/speculation/mds: Print SMT vulnerable on MSBDS with mitigations off
 - x86/mds: Add MDSUM variant to the MDS documentation
 - Documentation: Correct the possible MDS sysfs values
 - x86/speculation/mds: Fix documentation typo
   * [x86] linux-cpupower: Update CPPFLAGS for change in 
Checksums-Sha1:
 0f3898fb50eaf82ebcccffcea79b6af3ac83e58d 189124 linux_4.19.37-2.dsc
 e5d28f26074b82ba27ef5bf3ec470f52fae36224 1231028 linux_4.19.37-2.debian.tar.xz
 04d7e8722f9b410bc3d5b3f4b3b8ce9d5bb9745a 47334 linux_4.19.37-2_source.buildinfo
Checksums-Sha256:
 fa5e2bb6ecbfd13b0db17ace1e2b0edc8f860ad0c6e1c6054635f8bb93adaa46 189124 
linux_4.19.37-2.dsc
 758572eb0b6eaf20097cd3046e1ab35dfc01643db4c32669c5816489408ad12f 1231028 
linux_4.19.37-2.debian.tar.xz
 aa653914dfac9fedc580b6c5137525de46c53cb176a417d21971040554d7c07b 47334 
linux_4.19.37-2_source.buildinfo
Files:
 1acdf564916a6db0c9136dce0938afbc 189124 kernel optional linux_4.19.37-2.dsc
 2c2c39e74d5edbd524f445abec3afe96 1231028 kernel optional 
linux_4.19.37-2.debian.tar.xz
 7b9b8b9a0ddb1afa1a18f073880a4ccd 47334 kernel optional 
linux_4.19.37-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAlzbCwoACgkQ57/I7JWG
EQlJ3xAAvQgCCeyrcmW+NRRNq2u76aXDF9sJq2tIi6d1Pwh4yU3M2zAVq/O1IMoi
RCinxFUvkrx00XOtA9h2DCdVwLltXxv+fcMD6odiwHo5nPBVoi0LkoiR8jNNwZmL
sEP67Wc/ve2/HZq06NHhyK+/SHs5YdHizhsgw7eTN1PlUuXMIa9sIWtEAdSs/Yi0
uJ0SUmb7CVZwa6EQHz5iV1nLAqt5nI09kIulBLfCKtPlimrVTxiIxTvyDJzXcFEr
e+Q32LH63pWula/bjVwp24pL3b9ceejDucqsoYwaY7NjDhZfk8jKQheacsHBpAKG
HimB984q5DP3jzSmOQVZu+kWZ8kTGMSgcJhHSBzYrhYjmu4N3PQWxWOP5ymU+DCn
hki+UpSkbt8ngChpkVS0gWcOnwRA+T3sH5j1XSjjXd3a8Lyy5BoP/B4EIyP5z47V
sNtgVumh5TVt7ZSlKQbuMtFPkndbakS+7ZlEwjg2m8ly4frUk/U8WDclEFdXcBuu
bv3rj/yB3rbMGtKia5LN6maA0CWMBjr9ATT36fWw0DzWu9mN6lBEzRaoJOroha17
wgy429F6yf2xzkufdzKSwS3den0S2F2nh5hrURyGivctckEHMw8tV/mXtyxxp9yS
CqU42smMLB1/WMccmOs04XrArgOTzSgHL5K/3YIjFK4b/B33/AY=
=H8IY
-END PGP SIGNATURE-

Accepted nim 0.19.6-1 (source) into experimental

[Federico Ceratto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 18:22:09 +0100
Source: nim
Architecture: source
Version: 0.19.6-1
Distribution: experimental
Urgency: medium
Maintainer: Federico Ceratto 
Changed-By: Federico Ceratto 
Changes:
 nim (0.19.6-1) experimental; urgency=medium
 .
   * New upstream release
Checksums-Sha1:
 204b9507ee267263ade2dda317f01a5f237c324f 2120 nim_0.19.6-1.dsc
 e253394f46b65b90a904d02ccd1af73ea86068ce 33235376 nim_0.19.6.orig.tar.xz
 f20c35544ddc1f373f000b4e3e2db2c267eb3187 10376 nim_0.19.6-1.debian.tar.xz
 f81460bbaade233f8070721a31dec4be658a19c7 5807 nim_0.19.6-1_amd64.buildinfo
Checksums-Sha256:
 5d6b176d5a3ffdc306ad29ecce0bdc5acc9c9784873a097c28e5812e5e0824a1 2120 
nim_0.19.6-1.dsc
 46207bb26970963feba77e003ce56addc9f40ca5a25361ddd66d9b2ff9fea7ab 33235376 
nim_0.19.6.orig.tar.xz
 00010c016a13a8d9debbedfa846fefc4a750870c4c380250110cda7ea5af29c2 10376 
nim_0.19.6-1.debian.tar.xz
 83a5a488518fd5f01ec3c6c9978f50d82668b356ec9711a71322ca1a1575031e 5807 
nim_0.19.6-1_amd64.buildinfo
Files:
 ed6e0067225f651b8251434d0fea7cd9 2120 devel optional nim_0.19.6-1.dsc
 34e560ef6bfb713d2a0457c388d355bf 33235376 devel optional nim_0.19.6.orig.tar.xz
 386dd46d8f3bc64dcb6f7a6cd19eef34 10376 devel optional 
nim_0.19.6-1.debian.tar.xz
 6f9237070222f8ad42c3b7b1c6f6e810 5807 devel optional 
nim_0.19.6-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEfKfd+zM5IUCMbyuWbzG8RPUXfaoFAlzbAjEACgkQbzG8RPUX
fao1Fg/+MusAU/3IynsgGc04MSKO314YGuq5+pneBj1RuI1FB6Ie3TB99eo0DxkQ
wPgx76qkgxlpqAiJ5QhDmpLd2fQ3+eibCSHFEflVvQe0jez4qeW4b9asWcu3Dqnh
6aP/0fUQ3wnDJ1gcUWWkMpkE+q4uWASHsMqWg/56FudcIVu+u5URnotmy1ES1jn/
BRo6mPnug7Ty6k1MYARDqZ/vMebqRR2pbwVKEzSI9CX+Y5xPGcuTk4z05QbhbWkK
PkRmyFgkq9xyi8Y4z7Drsf8/XSvMcmB3/8QDBogV+dh5mN4TSEoOLcUf+6b84tTo
QuGHFfVSvwuN/HWQgVtlCLg6pW5o3lowMxtnwfmY6rnjxsyn1Ap9oOJXlios4LJ5
YEygyjhFOwR9LGZbS+sNncBgLDokxXx6XNGDFz1M4YB+P8EAYqDTJJAbTQBGL4c0
N6dcEoBookaoZts2N412nDesErzQlvpjkjjVvmInXhogYOnGoinXUwmfNl1zC3ST
PjWGwcrExHjexDSZDnBw29TxhrvZ+vq9FVNOtcRDICRN2w97xXXZCSU10419RpLW
FUyZWtnPgF3Yu3UwugJzOP6Nz49/ap0x0BY6b1UW4ys5VlDwUrnipEh6Aycg8FtI
j7rsccwjko+eVVylIX96bxEGS/Vno0EjF0o0j3sBTn6WhKXlD2w=
=ds3N
-END PGP SIGNATURE-

Re: NMUs: Do we want to Require or Recommend DH

[Sam Hartman]

I think there's a fairly clear consensus emerging that it's worth having
things to check when making a build system conversion.  Looking at
debdiff, ditherscope and reproducibility of the build all appear to be
important things to consider in such a case.

So, I think there is an emerging consensus against the idea of people
NMUing a package simply to convert it to dh.

First, I'd like to explicitly call for any last comments from people who would
like to see us permit NMUs simply to move packages toward dh.  Are there
any cases in which such an NMU should be permitted?

Finally, I'd like to focus discussion on an area where emerging
consensus is much less clear.

How do we feel about people making build system conversions when those
conversion make it easier to fix some other bug that they are fixing as
part of an NMU?
That is, imagine that a package is mishandling the combination of
systemd units and an init script.  As someone preparing an NMU, is it
reasonable to move to dh compat 12 from some other build system if I
believe doing so will make it easier for me to fix the bug and verify
the fix?

--Sam

Accepted samba 2:4.9.5+dfsg-4 (source amd64 all) into unstable

[Mathieu Parent]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 08 May 2019 21:53:16 +0200
Source: samba
Binary: ctdb ctdb-dbgsym libnss-winbind libnss-winbind-dbgsym libpam-winbind 
libpam-winbind-dbgsym libparse-pidl-perl libsmbclient libsmbclient-dbgsym 
libsmbclient-dev libwbclient-dev libwbclient0 libwbclient0-dbgsym python-samba 
python-samba-dbgsym registry-tools registry-tools-dbgsym samba samba-common 
samba-common-bin samba-common-bin-dbgsym samba-dbgsym samba-dev 
samba-dsdb-modules samba-dsdb-modules-dbgsym samba-libs samba-libs-dbgsym 
samba-testsuite samba-testsuite-dbgsym samba-vfs-modules 
samba-vfs-modules-dbgsym smbclient smbclient-dbgsym winbind winbind-dbgsym
Architecture: source amd64 all
Version: 2:4.9.5+dfsg-4
Distribution: unstable
Urgency: high
Maintainer: Debian Samba Maintainers 
Changed-By: Mathieu Parent 
Description:
 ctdb   - clustered database to store temporary data
 libnss-winbind - Samba nameservice integration plugins
 libpam-winbind - Windows domain authentication integration plugin
 libparse-pidl-perl - IDL compiler written in Perl
 libsmbclient - shared library for communication with SMB/CIFS servers
 libsmbclient-dev - development files for libsmbclient
 libwbclient-dev - Samba winbind client library - development files
 libwbclient0 - Samba winbind client library
 python-samba - Python bindings for Samba
 registry-tools - tools for viewing and manipulating the Windows registry
 samba  - SMB/CIFS file, print, and login server for Unix
 samba-common - common files used by both the Samba server and client
 samba-common-bin - Samba common files used by both the server and the client
 samba-dev  - tools for extending Samba
 samba-dsdb-modules - Samba Directory Services Database
 samba-libs - Samba core libraries
 samba-testsuite - test suite from Samba
 samba-vfs-modules - Samba Virtual FileSystem plugins
 smbclient  - command-line SMB/CIFS clients for Unix
 winbind- service to resolve user and group information from Windows NT ser
Changes:
 samba (2:4.9.5+dfsg-4) unstable; urgency=high
 .
   * This is a security release in order to address the following defect:
 - CVE-2018-16860 Heimdal KDC: Reject PA-S4U2Self with unkeyed checksum
Checksums-Sha1:
 2050e3770ea95076b3b1f8b997c1fba50ad77f4c 4158 samba_4.9.5+dfsg-4.dsc
 cbdad30db40289a6e48894ee34d42f9e38cd7d69 248092 
samba_4.9.5+dfsg-4.debian.tar.xz
 127c1dcf24798e3cbfae0d309b1c4047ba25cf90 2917160 
ctdb-dbgsym_4.9.5+dfsg-4_amd64.deb
 09ab36cf2e89b000f3e72b1b54be5e16d519628b 728604 ctdb_4.9.5+dfsg-4_amd64.deb
 3e61f7b6d793bfdae259bbf43cbb55d641b7f99a 31352 
libnss-winbind-dbgsym_4.9.5+dfsg-4_amd64.deb
 4c895299cbd13d535751b25e28a078dbda2ad779 114464 
libnss-winbind_4.9.5+dfsg-4_amd64.deb
 f5311a436a5f505a5986fd5325f86e03f6732085 51864 
libpam-winbind-dbgsym_4.9.5+dfsg-4_amd64.deb
 f34c79cabf908fcc15f0ecf81dc5e1f4830ef5a1 132684 
libpam-winbind_4.9.5+dfsg-4_amd64.deb
 00c07d832635c68eafebde90ea8585c52b64e6a3 198552 
libparse-pidl-perl_4.9.5+dfsg-4+really0.02_amd64.deb
 1e9e16429090468da2f304200769aa04fab2 195356 
libsmbclient-dbgsym_4.9.5+dfsg-4_amd64.deb
 ab7f09dbcf509605a4f5cfbebdb224d8c8a98a53 144976 
libsmbclient-dev_4.9.5+dfsg-4_amd64.deb
 b38afc20e30cdadf6fc038720b9b522f6426936d 159856 
libsmbclient_4.9.5+dfsg-4_amd64.deb
 8b477a9b0eb5ede2d955b3bbbefc7979d304306f 116240 
libwbclient-dev_4.9.5+dfsg-4_amd64.deb
 3570e8f412760d6e2f993e78a0950ddf7078d2f9 104892 
libwbclient0-dbgsym_4.9.5+dfsg-4_amd64.deb
 c8f9531bf9e066af5e2afe63cf0be67dd0569224 131200 
libwbclient0_4.9.5+dfsg-4_amd64.deb
 35585f90bff1868885c431c64d8608d4adf7d6e4 742 
python-samba-dbgsym_4.9.5+dfsg-4_amd64.deb
 4a121c983cf477e28374a69dce68cb4ffc1ac10f 2165872 
python-samba_4.9.5+dfsg-4_amd64.deb
 99e12bc47eddcdb7bfde38b2e65ad7e56b07a4ae 87276 
registry-tools-dbgsym_4.9.5+dfsg-4_amd64.deb
 139dd440d1ad882474c52cad6aeef26a1f9ff6b0 132944 
registry-tools_4.9.5+dfsg-4_amd64.deb
 ed523595966147a4f4ae32435168339e1e866ff2 1309144 
samba-common-bin-dbgsym_4.9.5+dfsg-4_amd64.deb
 1435316f1b8552549f11988c5e14896636933f2e 615348 
samba-common-bin_4.9.5+dfsg-4_amd64.deb
 293c1a39c4e4cad2a7f59d5a20d41b3e7a95b43e 169356 
samba-common_4.9.5+dfsg-4_all.deb
 2448f58da5fae0a63a0efd90bde89df5ce5a6456 2161612 
samba-dbgsym_4.9.5+dfsg-4_amd64.deb
 a7bd8b3113df8346986b57e0cfd89c4586ebdee0 334124 
samba-dev_4.9.5+dfsg-4_amd64.deb
 c6a2e16814d32a232010b1719ad878a58289df36 1135136 
samba-dsdb-modules-dbgsym_4.9.5+dfsg-4_amd64.deb
 5ce71b7e2f7a26a9f3c7110ec7ac0f28d16a83bb 379928 
samba-dsdb-modules_4.9.5+dfsg-4_amd64.deb
 2d0224cb78071a2776f8bca3de66143140ca54b1 22721292 
samba-libs-dbgsym_4.9.5+dfsg-4_amd64.deb
 bde98c819300daf82796bd0e98285f3c4eec2e6b 5561348 
samba-libs_4.9.5+dfsg-4_amd64.deb
 041667d1f750d7862b4d15112cbc6cb5c94ea159 6658828 
samba-testsuite-dbgsym_4.9.5+dfsg-4_amd64.deb
 736d29bb191d9142cb85de0a3337691e24b760e0 1909864 
samba-testsuite_4.9.5+dfsg-4_amd64.deb
 d5e5c1f93133e782ac618d48f4db5b3386789ecb 1575076 

Accepted libwww-perl 6.36-2 (source) into unstable

[gregor herrmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 18:55:26 CEST
Source: libwww-perl
Binary: 
Architecture: source
Version: 6.36-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Perl Group 
Changed-By: gregor herrmann 
Description: 
Closes: 914034
Changes:
 libwww-perl (6.36-2) unstable; urgency=medium
 .
   * Drop drop-non-blocking-socket.patch.
 The patch is not only not needed anymore, it also causes troubles with
 OpenSSL 1.1.1 (via IO::Socket::SSL).
 Thanks to Guilhem Moulin (on the Debian side) and Steffen Ullrich
 (IO::Socket::SSL upstream) for analysing the problem and tracking down the
 real culprit.
 (Closes: #914034)
Checksums-Sha256: 
 1417c4ecdecce34e1118a4feaf6a70128108ad4b7ff159705639cbb030256b7e 2716 
libwww-perl_6.36-2.dsc
 74c54891ef9b407b18a2eeedf51900cf9fd574cb74cb877f7b37f47d46231782 10620 
libwww-perl_6.36-2.debian.tar.xz
 e2820c5166ec29a31d582abac6223e996db19a4824f0b1af01aaad62db89ca68 6116 
libwww-perl_6.36-2_sourceonly.buildinfo
Checksums-Sha1: 
 a48666f54662cb910869160049feb3452f3823a6 2716 libwww-perl_6.36-2.dsc
 f41e4fe778bab61e1e68f51167c9d16c8733e31c 10620 libwww-perl_6.36-2.debian.tar.xz
 455ec5c8962880258125e22e30d80c23d72ad986 6116 
libwww-perl_6.36-2_sourceonly.buildinfo
Files: 
 25cf3e6d0e95d8fc0a416736357b81ac 2716 perl optional libwww-perl_6.36-2.dsc
 fa2f733c2ad582dd021c925ef8fa7961 10620 perl optional 
libwww-perl_6.36-2.debian.tar.xz
 baac2ac5507d9ab6d98201c1d0301274 6116 - - 
libwww-perl_6.36-2_sourceonly.buildinfo

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlza8v9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZZKQ/+K461WUXhZbTCOnTUkXSPHR1CDnhIxz4/y0bpIIiu7/q9N+SZM8Tt2Lqr
qbXsQkm1IU+Ctz1kXSKUNPu84d6R4m9jZeqgkJeugJuo1nzxcjGV+Os49PGQk2UN
gDKcgf0nLe+8VTX+lQAyip806dtLIAJtHHYzRhygpJ/Mrldm7Fe+BSz7yXUFxNzQ
eceMgpSy4oPMCx70WBZCJdEoXArPD0ynyKIZE30GhwH22stfyYVpjBC4Mf01w/za
wgoEZvipUhjwOrhBdWm7y7uW8uGc1aRjdjcx4LK7yMnY+B64ggLEMdMtSnDxPFs5
DjcsE9wh+mr91Sl/GLmBRiinxrqyRnVV0Xahx0gga5G6iqFON6QPJs2Zc32ZgI03
o+1295kKcNfHfmIGYQxp/79Fg9a8EyIdmf+WjWRTqlrexXLmJa4gd63vKvLbZt88
/a/xcvMywAFs9lrriFSTO+gItIfkTgkfdNggxFufhweQpD+vNPt43sxhU3ydXqLd
mS/UuCpOGeieM3b677JOLOZm8Ww63MHzUWvEuslh6ksyKj8LMcCQ5krHxku5yDrm
bSaZTu4vHQRqt7FlV7d32w3OFHu8cMt6Da/GDxKIUSuT036dJrvJbh52jEP4cYfv
+uCCZQpVCNl6JYkCLHWsABpRMDV9/Ah85ZgAW5/4yUcne4EjMjs=
=KUEV
-END PGP SIGNATURE-

Re: Cdbs Features

[Tobias Frost]

On Tue, May 14, 2019 at 05:35:21AM -0700, Mo Zhou wrote:
> Hi,
> 
> On 2019-05-14 07:59, IOhannes m zmölnig wrote:
> > i've migrated many of my packages from cdbs to dh, but there's one
> > feature which cdbs sports and which i miss strongly (at least: the last
> > time i checked) in dh (so much, that i haven't converted a couple of
> > packages): building of multiple "flavours".
> > that is: building the same code-base multiple times, with differing
> > configurations.
> 
> Could you please provide some examples about the case you mentioned?
> I need exactly the "multiple flavours" feature for at least 2 packages:

"check" is compiling 2 flavours with dh:
https://tracker.debian.org/media/packages/c/check/rules-0.12.0-0.1
> 

Accepted openjdk-11 11.0.4+2-1 (source) into unstable

[Matthias Klose]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 14 May 2019 17:42:59 +0200
Source: openjdk-11
Architecture: source
Version: 11.0.4+2-1
Distribution: unstable
Urgency: medium
Maintainer: OpenJDK Team 
Changed-By: Matthias Klose 
Closes: 914860 928369
Changes:
 openjdk-11 (11.0.4+2-1) unstable; urgency=medium
 .
   * OpenJDK 11.0.4+2 build.
   * Fix src.zip symlink. Closes: #928369.
   * Tighten dependency on ca-certificates-java. Closes: #914860.
   * Refresh patches.
Checksums-Sha1:
 d4cce3037789e5af600180a61bcb7ad5ed66bae3 4692 openjdk-11_11.0.4+2-1.dsc
 d5cc2490324daaa4ccf583bae8f714cc68057c08 75356352 
openjdk-11_11.0.4+2.orig.tar.xz
 b68becaea82401ed584c9ea48c0363d122c4 168492 
openjdk-11_11.0.4+2-1.debian.tar.xz
 8a473ce2a1750b535bcea57d15f7911ea214f678 17684 
openjdk-11_11.0.4+2-1_source.buildinfo
Checksums-Sha256:
 06a2b09a9d9d441d393820f87445434b8a2f66f25200cbacb57d69ca3ac0ba0c 4692 
openjdk-11_11.0.4+2-1.dsc
 4957b349174df485ed149121b2731d611677d8ad5d753c847e0706a6d41d945c 75356352 
openjdk-11_11.0.4+2.orig.tar.xz
 3ddbc6226b53601a5f9a74b70c61e95b096327ab2d657e8bd7241683c7893922 168492 
openjdk-11_11.0.4+2-1.debian.tar.xz
 b507ad5a32dc151bf5aff1a013179228981dfcfe16d2f4a484cf7b732db44ee3 17684 
openjdk-11_11.0.4+2-1_source.buildinfo
Files:
 f03ce1664781852031b68bc71dc10456 4692 java optional openjdk-11_11.0.4+2-1.dsc
 50e217b2abf338004d2adb180320f61e 75356352 java optional 
openjdk-11_11.0.4+2.orig.tar.xz
 deca48bf7e447a38106ff358fe6c7132 168492 java optional 
openjdk-11_11.0.4+2-1.debian.tar.xz
 ece8b005488bea6b6e2e09a5503a7e08 17684 java optional 
openjdk-11_11.0.4+2-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE1WVxuIqLuvFAv2PWvX6qYHePpvUFAlza6F0QHGRva29AdWJ1
bnR1LmNvbQAKCRC9fqpgd4+m9TH0D/sHqhYn6X/dX3rhMUOuBByeyPlpiFnK08p1
PRdnkcIHHZGfaRWYwOu6oIVBWxfrnF2X5erKUClO66YOqYxR64WP14ogG5YMaSCn
7eK2iDPat51KofoMf2mmuBnPEIcoPZRhRLOH7qS+lEVTgvIcduW6CRai+7LWefzp
P3ivsfp3nYNlOiCeYbCsBq7U1QLrgrVz+ntexjQsHEE/6pLEfKK8SMfzU8JB6EOw
iJZqxiFsNoajmkN3h9yU5zXU3G0UIR3/U4kh3bpEFm+eB2Rb4sJuR4Mgxjc4ETo7
5J2/yNLsFFbLkzoTHRY+KSzXxYsyTlyLZjVToI2hWY9vf4a0PwsBEurw/fozX+Fs
2AtjkKnWM/yVeQkpFXieCdrDdhtqG8sb5mFgHEeERm4pUeLB8OL5eSVrziIUefN+
H4teMeHk4ZAPLwm5cVehNeyDp3y+ZSnbWF+1cUFuxeZwmK8HRTwNSg/nN7ieCGzu
vNtmNqYZXjeKqJaxBJo1XkjoSxXpBU7/YYzzhVna7WPZEfde42PF/5m5IYyenDXT
dM8fUHTkyqoLFNBUmNr4lVc1soYjiiKHt+ilmHQl2btW5gIE5Enc2RnwgtQpgJqf
eKaxKkNQg9KdsBmjLAYYl1/Due2c7koxWp0v1Ja7STUeUkAXdVSoDp3kMQWu1m0W
iGWWXp4cXw==
=2iMg
-END PGP SIGNATURE-

Accepted mapserver 7.4.0-1~exp1 (source amd64 all) into experimental

[Bas Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 17:28:54 +0200
Source: mapserver
Binary: cgi-mapserver libmapscript-java libmapscript-java-dbgsym 
libmapscript-perl libmapscript-perl-dbgsym libmapserver-dev libmapserver2 
libmapserver2-dbgsym mapserver-bin mapserver-bin-dbgsym mapserver-doc 
php-mapscript php-mapscript-dbgsym php-mapscript-ng php-mapscript-ng-dbgsym 
python3-mapscript python3-mapscript-dbgsym
Architecture: source amd64 all
Version: 7.4.0-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: Debian GIS Project 
Changed-By: Bas Couwenberg 
Description:
 cgi-mapserver - CGI executable for MapServer
 libmapscript-java - Java library for MapServer
 libmapscript-perl - Perl MapServer module
 libmapserver-dev - Shared library development files for MapServer
 libmapserver2 - Shared library for MapServer
 mapserver-bin - MapServer utilities
 mapserver-doc - documentation for MapServer
 php-mapscript - php-cgi module for MapServer
 php-mapscript-ng - PHP MapServer module (SWIG)
 python3-mapscript - Python library for MapServer
Changes:
 mapserver (7.4.0-1~exp1) experimental; urgency=medium
 .
   * New upstream release.
   * Update 7.4.0~rc2 symbols for other architectures.
   * Update 7.4.0 symbols for amd64.
Checksums-Sha1:
 b8335bf7798dbddec6fdb88ec3331b21e93dfbe6 3267 mapserver_7.4.0-1~exp1.dsc
 1785fb57be25008b2482ecaecb8e873cfdd7fce9 2686054 mapserver_7.4.0.orig.tar.gz
 9a8132c9e6cd52551957f84dbc7177fa8f18b4d9 47004 
mapserver_7.4.0-1~exp1.debian.tar.xz
 30b05f192eabcc750a7595880330c500b7c58b00 79492 
cgi-mapserver_7.4.0-1~exp1_amd64.deb
 2aebee3d803c534d461c041ba257e6f34f3f5d65 570804 
libmapscript-java-dbgsym_7.4.0-1~exp1_amd64.deb
 8b150c8c01e4ae16a42329ab61d3e40d717d0020 280732 
libmapscript-java_7.4.0-1~exp1_amd64.deb
 1be2822b76fa6533ea26e54100cbbf75ccb11bf3 1053180 
libmapscript-perl-dbgsym_7.4.0-1~exp1_amd64.deb
 414a36ffdf67d1303e45c99ef657a9f1c66528bb 285404 
libmapscript-perl_7.4.0-1~exp1_amd64.deb
 6fb0ecd1a028c45e12d7062b703740e86bd55e0d 452132 
libmapserver-dev_7.4.0-1~exp1_amd64.deb
 8cae8da1cfc77410e7ba3b6f9e03d31450ceddda 3438636 
libmapserver2-dbgsym_7.4.0-1~exp1_amd64.deb
 3b5a2a68e1ee023b1c2b7a80e8b4d97d70fb73d6 1124868 
libmapserver2_7.4.0-1~exp1_amd64.deb
 c6cd2401b6e8c858058735ab4c94c133aeb8cd07 105392 
mapserver-bin-dbgsym_7.4.0-1~exp1_amd64.deb
 6ab1b04c5db2fa9b212ee52e7dfe76c96fef27e1 110268 
mapserver-bin_7.4.0-1~exp1_amd64.deb
 304936c3dd2f09c529870ed4fd8362edf437a7a7 91932 
mapserver-doc_7.4.0-1~exp1_all.deb
 0eae4dd5ae6c8e9f4de9df3b822181bec146d5ee 23072 
mapserver_7.4.0-1~exp1_amd64.buildinfo
 1e55daed342337f1de783c7233a504a5ccfad366 863384 
php-mapscript-dbgsym_7.4.0-1~exp1_amd64.deb
 b07b1c4d8f3899142f607e17cfdfb9d6d65a064c 511860 
php-mapscript-ng-dbgsym_7.4.0-1~exp1_amd64.deb
 78a782dae869f966a48754422a02ecc727b8987e 216324 
php-mapscript-ng_7.4.0-1~exp1_amd64.deb
 972a4b62bab45b0f300e980c355ad3c8fb0925fe 172016 
php-mapscript_7.4.0-1~exp1_amd64.deb
 31ee13bbc2fedc6c28c7ebc13988dd863aba2ec9 644620 
python3-mapscript-dbgsym_7.4.0-1~exp1_amd64.deb
 48cf32a100ff3fd6545b80b843909ed6d510b431 267840 
python3-mapscript_7.4.0-1~exp1_amd64.deb
Checksums-Sha256:
 1724ae02aa0955d1889f05742637b441dfecb6ce5d6df3ce84ce18c8281779fa 3267 
mapserver_7.4.0-1~exp1.dsc
 fc714f5836023fd39005296665c562022fa294348ecc244b93647b3ba1e361f5 2686054 
mapserver_7.4.0.orig.tar.gz
 4aec3b89c017f7c2757d41d533bb247e8c44d3a1215a0c953a8a13a01c3f105f 47004 
mapserver_7.4.0-1~exp1.debian.tar.xz
 c941ad16fc39bf1cabe8a68a7caa7e4fa10b8eec9cf495de555f073e12c4c982 79492 
cgi-mapserver_7.4.0-1~exp1_amd64.deb
 ad3e3e63a0bce8349e654059a8a5e944498ea6c3d265f27bc59fe16b7e6a329b 570804 
libmapscript-java-dbgsym_7.4.0-1~exp1_amd64.deb
 3e76048dce7903f4b0ab7ddeb9509bda84fdb922415ee5027a4c0a81096289ee 280732 
libmapscript-java_7.4.0-1~exp1_amd64.deb
 9efe1fe05e16bef1c18285f935d6579d7a836ced1cc20d3e1f49f11a2ef5bd47 1053180 
libmapscript-perl-dbgsym_7.4.0-1~exp1_amd64.deb
 e153b5b9b8493eaadfa236cb9ac9105a86d16bea55a682134704af9e0c019c8e 285404 
libmapscript-perl_7.4.0-1~exp1_amd64.deb
 005007b02581a62cb2bc875b695def890e311a5d3089f2157b8e4ae954ec053f 452132 
libmapserver-dev_7.4.0-1~exp1_amd64.deb
 ca4bbf33f86092673364b233f0bf6fedde903a2b2e7f99e166b388f6cacd2be8 3438636 
libmapserver2-dbgsym_7.4.0-1~exp1_amd64.deb
 c696788610ca82f86d6c5d096de54507338790ff4a4306a405114ffb6243cd9c 1124868 
libmapserver2_7.4.0-1~exp1_amd64.deb
 506a510c48c81e9b496fbe15ff0e6ba0c2bd90f50308fd0a8964c2515e23446b 105392 
mapserver-bin-dbgsym_7.4.0-1~exp1_amd64.deb
 9c2a02590a2a2935369031f09f3f699c07a81590e37e16fe754dd6fcf9b4e278 110268 
mapserver-bin_7.4.0-1~exp1_amd64.deb
 b89b5899821137855633959565190252ddd79653a70cadd548e2bfebcdc6731f 91932 
mapserver-doc_7.4.0-1~exp1_all.deb
 93f9aae6221ba734b40ba9c56b06be930e5058badce93a4ef0a337808567f84f 23072 
mapserver_7.4.0-1~exp1_amd64.buildinfo
 2c525031883ff7021e1b7469fb77f260253db899d8429145d94a6a950e45c8c5 863384 

Re: QA expectations (Was: Do we want to Require or Recommend DH)

[Johannes Schauer]

Quoting Holger Levsen (2019-05-14 17:38:15)
> > Now one can turn this argument upside down. One can say: unstable is the QA
> > area. Britney prevents testing migration on autopkgtest/piuparts/ missing
> > binaries. In that case, we should simply stop filing such things in the BTS
> > and stop doing manual QA on unstable. It should be ok to break unstable.
> > But this is not going to work with transitions. Thus I still think we're
> > doing it wrong and unstable isn't the place to do the QA we expect from
> > everyone.
> 
> have uploads go to unstable-proposed and then, after basic automatic QA
> checks, go to unstable? (and then testing as usual today...)

Doesn't a repository where all binary packages go before they are pushed into
unstable already exist?

deb http://incoming.debian.org/debian-buildd/ buildd-unstable main

So maybe instead of creating unstable-proposed, stuff should move from
buildd-unstable to unstable only after it successfully passed all kinds of
automatable QA tests?

Such an intermediate repository (be it unstable-proposed or buildd-unstable)
could highly improve the quality of unstable and make sure that whatever lands
in unstable will only have those bugs that are usually discovered by humans
only. It could also have other nice properties that currently only testing has,
like no Multi-Arch:same version skews because stuff could only move to unstable
after it has been built on all arches.

Thanks!

cheers, josch


signature.asc
Description: signature

Accepted openstack-cluster-installer 22 (source all) into experimental

[Thomas Goirand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 14 May 2019 17:18:44 +0200
Source: openstack-cluster-installer
Binary: openstack-cluster-installer openstack-cluster-installer-cli 
openstack-cluster-installer-poc puppet-module-oci
Architecture: source all
Version: 22
Distribution: experimental
Urgency: medium
Maintainer: Debian OpenStack 
Changed-By: Thomas Goirand 
Description:
 openstack-cluster-installer - automatic PXE and puppet-master installer for 
OpenStack
 openstack-cluster-installer-cli - automatic PXE and puppet-master installer 
for OpenStack - API cli
 openstack-cluster-installer-poc - automatic PXE and puppet-master installer 
for OpenStack - PoC
 puppet-module-oci - automatic PXE and puppet-master installer for OpenStack - 
puppet
Changes:
 openstack-cluster-installer (22) experimental; urgency=medium
 .
   [ Thomas Goirand ]
   * Add role-add, role-create, role-delete API and ocicli.
   * Add bash-completion script for ocicli.
   * Enhance ocicli network-list, add a network-set command.
   * Allow setting-up multiple external bridges for flat networks.
   * List all bridge setup with OCI in neutron's config, allowing a virtually
 unlimited number of bridges.
   * Fix service_credentials/cafile in ceilometer.
   * Add option to perform ipmitool settings in the target image when running on
 the slave image.
   * Add option to show the calculated IPMI console command.
   * Add some sysctl customization (low swappiness, higher conntrack, etc.).
   * Provision ssh public / private keypair between nova nodes in the
 /var/lib/nova/.ssh folder, to allow (live) migration using ssh / scp.
   * Switch to a db migration system with the schema saved in PHP format.
   * Add a cluster-show command.
   * Add the setup of chrony on all machines, with customization of time server
 host for the clock source.
   * Add the nf_conntrack module by default in /etc/modules.
   * Make sure python-keystonemiddleware is installed on swift-proxy nodes.
   * Firewall swift's container, account and object servers.
   * Empty DEFAULT/external_network_bridge by default, as this prevent using
 more than one external network.
   * Libvirt configuration on compute nodes (ie: /etc/default/libvirt-guests):
 - PARALLEL_SHUTDOWN=8
 - SHUTDOWN_TIMEOUT=120
 - START_DELAY=4
   * Add qemu monitor on port 550XX for each VMs in the PoC.
   * Copy swift_fstab_dev_list.sh when provisionning.
   * Set Neutron's global_physnet_mtu and ml2's path_mtu if the VM net network
 has mtu != 0, allowing to set (for example) mtu = 9000.
   * Use wget to install openstack-backports-archive-keyring_0.1_all.deb instead
 of using apt-get update / apt-get install --allow-unauthenticated (which
 method doesn't work anymore in Buster).
   * Set haproxy's nbproc to 4 by default for swiftproxy, compute and
 controller nodes.
   * Copy the backport repository key file inside the targets instead of using
 the openstack-backports-archive-keyring package, which doesn't work anymore
 if using Buster.
   * Also install gnupg2 in the installed machines of the cluster.
   * Add support for Stein's separated placement.
   * Adapt puppet manifests so that they also work with Stein's 
puppet-openstack.
   * Add the feature to setup any machine with software RAID.
   * Using system serial number, and not chassis anymore.
   * Fully working Octavia support.
 .
   [ Oliver Chaze ]
   * swift: do not log in syslog general logs
   * increase default haproxy server timeout
Checksums-Sha1:
 2762a1db4af0d90cba4716b296ecc3a8c0cf30a0 2101 
openstack-cluster-installer_22.dsc
 c355454276591f2bd7bd7380db338d05fe7f2731 160120 
openstack-cluster-installer_22.tar.xz
 fdc4998ae4aed3ae8540f1851bfa40ef36bc6687 12668 
openstack-cluster-installer-cli_22_all.deb
 a9fc56a7897d71c264478756d3806b25806e6d07 17904 
openstack-cluster-installer-poc_22_all.deb
 fbea3549ea6a0fc0c426f08d94f7a8486fb7966c 121612 
openstack-cluster-installer_22_all.deb
 63ec5f472afdf530d8843b92fa6cc83b2101cf20 6380 
openstack-cluster-installer_22_amd64.buildinfo
 fa7c10ee94d7e6679e694ee196321a0f9d8cd24b 32520 puppet-module-oci_22_all.deb
Checksums-Sha256:
 aeeed822e9f5474cb0ddccfd4329da4878f4f9f229715f44a43ab20da823f82e 2101 
openstack-cluster-installer_22.dsc
 62c9da818e4c962b60a2775faed8ae6a0c2c50401a2d2bb6a6a49080e70c5d4f 160120 
openstack-cluster-installer_22.tar.xz
 a30db46c8ecd3c3b547050e7d71da1c1e865ad04d6859c99568c066074f7400a 12668 
openstack-cluster-installer-cli_22_all.deb
 d37eda36ac124763d8672936d1d15a7bf0b7702aca81dd79625f509b99a26b56 17904 
openstack-cluster-installer-poc_22_all.deb
 4aad6c86ae7a2ca6b20c1c7f2934685183a4f235cb4632987e98e28ae4936356 121612 
openstack-cluster-installer_22_all.deb
 b008e44bb5fb68d48277daf532771662c6d80e49f807832e76aad58e7057c6da 6380 
openstack-cluster-installer_22_amd64.buildinfo
 59d287e463b28cd326d953062944fdfe8534ef1e6b1fc4daf3a78762044729ad 32520 
puppet-module-oci_22_all.deb
Files:
 

Re: QA expectations (Was: Do we want to Require or Recommend DH)

[Holger Levsen]

On Tue, May 14, 2019 at 05:19:23PM +0200, Helmut Grohne wrote:
> The things you have to remember before doing an upload are insane.
> Having humans remember all this crap is not a reasonable expectation. I
> think our upload process is a bit like classical debhelper: You remember
> to do all the things. We've seen the argument that the dh sequencer
> sheds light on the unusual aspects of a package. I argue that this
> should apply to QA as well. People shouldn't have to remember all the
> QA. QA should just work and QA should tell people about the (unusual)
> failures.

agreed.

> Now one can turn this argument upside down. One can say: unstable is the
> QA area. Britney prevents testing migration on autopkgtest/piuparts/
> missing binaries. In that case, we should simply stop filing such things
> in the BTS and stop doing manual QA on unstable. It should be ok to
> break unstable. But this is not going to work with transitions. Thus I
> still think we're doing it wrong and unstable isn't the place to do the
> QA we expect from everyone.

have uploads go to unstable-proposed and then, after basic automatic QA
checks, go to unstable? (and then testing as usual today...)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Accepted praat 6.0.52-2 (source) into experimental

[Rafael Laboissiere]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 12 May 2019 07:20:02 -0300
Source: praat
Binary: praat
Architecture: source
Version: 6.0.52-2
Distribution: experimental
Urgency: medium
Maintainer: Debian Med Packaging Team 

Changed-By: Rafael Laboissiere 
Description:
 praat  - program for speech analysis and synthesis
Changes:
 praat (6.0.52-2) experimental; urgency=medium
 .
   * d/t/run-tests: Exclude unit test test_Discriminant (fails on i386)
Checksums-Sha1:
 87fe7f8292a71baabd31423ffcb586418af2dea5 2278 praat_6.0.52-2.dsc
 d5cd7899c0dcdbd7d7e2527aac00b617b2602e89 26528 praat_6.0.52-2.debian.tar.xz
 19abc7a0d18392470ad24c782b9ba8b2c5a5b608 12834 praat_6.0.52-2_amd64.buildinfo
Checksums-Sha256:
 95c3fd764c858a1e0ad6b7ab86131797c757642682f9b945bd996dc4595a980c 2278 
praat_6.0.52-2.dsc
 edbe3710ab3052abdbeb84a0e22dbb3d27d5097b7a5d51fd7046fcc02f154014 26528 
praat_6.0.52-2.debian.tar.xz
 9f59a16f4b9c823b3331f6eea5289674d91ee2f21df8b3fd7565ed7bc59e7838 12834 
praat_6.0.52-2_amd64.buildinfo
Files:
 b658c617beff94f4b862a1013aeec554 2278 science optional praat_6.0.52-2.dsc
 22d4a3303e67effb097fe28fa928ab55 26528 science optional 
praat_6.0.52-2.debian.tar.xz
 172a1182215f6a2989b67f5cbf873b4a 12834 science optional 
praat_6.0.52-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEP0ZDkUmP6HS9tdmPISSqGYN4XJAFAlza2l8ACgkQISSqGYN4
XJBp2Q/9H5tklwf0VOEzCdcuLoQGhsBawlR2678MsU84lfiSYjy1XIFKn2fTantD
5M5sN4B3u0bPPbIEm3DfsUwBYRC4BTC8Y42uPHZPAAUxSs/acVlrGrygEULTZE2T
XAsgAmgJnphbOrL7HyTXSxkJ0zD0U4JooltVxvT2eHUah4bHWNX2ZNkXiGNm727d
qdfmD0PBGAMIeHWefoKnnjJ2go424i82nucwySrbvG9FOGpv4m5aouXUMXSnh1QC
qPqYhdzNONQ3/dGukBFn76hxJxA9XvzgeVUdSbnIbigMcxLLacchWd5EwrdLGMMT
vd7c9a+YpsBWWhUapJBX0iRqPFMMvchzNzR1oAaeVUtx26TV0mRhnCYI3fHkKgP3
GzPoDzcbDeZP80e+8pfbx2ZJQVlAwcPI+fy9Ic0BLj9gWqCCAFlzhvHQndJicF7u
wLZwF7ySK/VudIHVDkqsmdf6Mu2S6BfSaXuyN2CA/1YgzLbN1EYvEBKY/q0Zbxjh
Jyh2+O9ArASk/HrqpdfGAZZqSsTsR1bet6wJ+NGx4qdLB0/7ITC5zOt5oHXItbtY
YDTB3HYxHF9E9zLyoqP7g9fKurcxIrp9VGzNWa7ycMhWJJDT8NNcrKLS46w8hUkT
OB1TxQzoJUV+rztnP3/RYG27ZhF7AWuxbGNVhpIjJoWLTXgfuBY=
=K/lt
-END PGP SIGNATURE-

QA expectations (Was: Do we want to Require or Recommend DH)

[Helmut Grohne]

Let me briefly hijack the discussion for a side note. ;)

On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> NMUers should do debdiff - no matter what change was done.  And yes, it
> happened also to me in the past once or twice that I uploaded an empty
> package or package missing some files.  I do not remember whether it was
> connected to a change to dh or not ... but mistakes happen.  The fact
> that we might end up with broken NMUs is IMHO orthogonal to any cdbs to
> dh change.

After a failure, we tend to bash uploaders:
 * Why didn't they look at the debdiff?
 * Why didn't they run piuparts?
 * Why didn't they run lintian?
 * Why didn't they run autopkgtest?
 * Why didn't they do an arch-only/indep-only build?
 * Why didn't they test their package?
 * ...

The things you have to remember before doing an upload are insane.
Having humans remember all this crap is not a reasonable expectation. I
think our upload process is a bit like classical debhelper: You remember
to do all the things. We've seen the argument that the dh sequencer
sheds light on the unusual aspects of a package. I argue that this
should apply to QA as well. People shouldn't have to remember all the
QA. QA should just work and QA should tell people about the (unusual)
failures.

Now one can turn this argument upside down. One can say: unstable is the
QA area. Britney prevents testing migration on autopkgtest/piuparts/
missing binaries. In that case, we should simply stop filing such things
in the BTS and stop doing manual QA on unstable. It should be ok to
break unstable. But this is not going to work with transitions. Thus I
still think we're doing it wrong and unstable isn't the place to do the
QA we expect from everyone.

Now I wonder how to move forward with this (after the dh discussion).

Helmut

Accepted python3.8 3.8.0~a4-2 (source) into experimental

[Matthias Klose]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 14 May 2019 15:45:29 +0200
Source: python3.8
Architecture: source
Version: 3.8.0~a4-2
Distribution: experimental
Urgency: medium
Maintainer: Matthias Klose 
Changed-By: Matthias Klose 
Changes:
 python3.8 (3.8.0~a4-2) experimental; urgency=medium
 .
   * Update to 20190514 from the trunk.
   * Fix interpreter name in the -dbg autopkg tests.
   * Enable dtrace/USDT probe support (--with-dtrace) and build-dep on
 systemtap-sdt-dev (Trent Lloyd). LP: #1818778.
Checksums-Sha1:
 7e6416567957081fc56e4aaa25ec85fe6db2b972 3438 python3.8_3.8.0~a4-2.dsc
 6e7286305d18ef058a42ca961b5011cd87d27a26 578048 
python3.8_3.8.0~a4-2.debian.tar.xz
 b5e74690d66599089bd4315130205e731cbd4696 10162 
python3.8_3.8.0~a4-2_source.buildinfo
Checksums-Sha256:
 528893d41eee9b9ffe0b20366b71998fb04c76156b4da17489120c3c203b92ac 3438 
python3.8_3.8.0~a4-2.dsc
 2e410a3b5b78a912e70a972ab227a57fe07ee890ce0e56f823fe57a5db69816a 578048 
python3.8_3.8.0~a4-2.debian.tar.xz
 20810c6bb53714e8ef47011b27bafd2c0ebc1c9c92c056a0b83e45bf9b7d40a5 10162 
python3.8_3.8.0~a4-2_source.buildinfo
Files:
 5eabdeebeb8eb3d6fa1f307569f84724 3438 python optional python3.8_3.8.0~a4-2.dsc
 dea5499ec6a37b26e3c4ff7326abe4df 578048 python optional 
python3.8_3.8.0~a4-2.debian.tar.xz
 718e2c411dd852da656e34dc436b826c 10162 python optional 
python3.8_3.8.0~a4-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE1WVxuIqLuvFAv2PWvX6qYHePpvUFAlza0pAQHGRva29AZGVi
aWFuLm9yZwAKCRC9fqpgd4+m9fNmD/wJndKSeFA58Dvt5vw8kPm21UE7Be/pFRZr
PeQmOpmUvH9INIMStMBZJHtzAkM6EHJX+LEn8a11wCLZyMkLhv3l++giF3qNP139
/nim/cX2ZCNskg6xHAs1pA46itY+1yxG0rn3dCnqb1OF+ApasoWKAkC+WwKSL26q
pYw/3eZGGKITYlXFUqzodADs2rWHMeoD6RS7AEkes04FMPqJ5PUqV7Lo6i86ELHV
9H2EiviKfTuvvg+ikDo94KeKyBV0sT6d803n6zuLLzr9arHsaDTVsaH6tnRjaLvX
kuLEYX2QYsNVXxprn7pxV/dTVfr8mvjCepbV70J6g1knIMydEN8V/4rjKn/wQsyB
iQ6PSHLHYj8v5g1A981rIYY1R1zLDVuxH33xK8sp6YFVdy2J0Yc2LH3tj/KjJFNM
krAErWdblzv7CRTNZWCPoX6c57apu2+hZF+prEEtaqTvK+zuCa4j4YA34dfSZnzD
KuCkihBbr3O1fTHyzolzQMREYrrLly7sSsKGlSgMeKzJV52MXIxHJ+mP84UTB76/
D5/USYFze4zE4xeD13cb5FyLCUmAlKQapWDyZM9rm+81HU+jhYefIFjI1UIjw7xM
n5kJByKaaCoWxGwr/FZ9OcbuM1CkXjFvDc2TWeG9wtmLCstRf6psJZa3xSNcoLI4
iAwvGqEZhQ==
=GEIx
-END PGP SIGNATURE-

Re: Do we want to Require or Recommend DH

[Andreas Tille]

On Tue, May 14, 2019 at 03:11:23PM +0100, Ian Jackson wrote:
> 
> But my point is if you have a handwritten rules file it ends up so
> full of "obvious" boilerplate that it is difficult to see the trees
> for the wood, and there isn't anywhere obvious to put this kind of
> commentary.  I think both dh and cdbs make this easier.

That's another nice summary (and admittedly also true for cdbs).

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Re: Do we want to Require or Recommend DH

[Ian Jackson]

Holger Levsen writes ("Re: Do we want to Require or Recommend DH"):
> On Tue, May 14, 2019 at 12:30:02PM +0100, Ian Jackson wrote:
> > This provides an excellent
> > opportunity to leave a comment next to each weird thing explaining why
> > it's there.
> >   https://browse.dgit.debian.org/xen.git/tree/debian/rules#n111
> 
> wow, that's a *really* nicely documented rules file, kudos!

Thanks for the compliment.  This is there for my benefit as much as
anyone else's.  Having done all the digging to figure all these things
out, I definitely want so save my future self from doing it all again!

Also documenting things means both that everyone else is much less
likely to delete it or break it, and that if it goes wrong or becomes
obsolete, we will be able to fix it or drop it as applicable.

But my point is if you have a handwritten rules file it ends up so
full of "obvious" boilerplate that it is difficult to see the trees
for the wood, and there isn't anywhere obvious to put this kind of
commentary.  I think both dh and cdbs make this easier.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Cdbs Features [and 1 more messages]

[Ian Jackson]

Mo Zhou writes ("Re: Cdbs Features"):
> On 2019-05-14 07:59, IOhannes m zmölnig wrote:
> > that is: building the same code-base multiple times, with differing
> > configurations.
> 
> Could you please provide some examples about the case you mentioned?
> I need exactly the "multiple flavours" feature for at least 2 packages:
> 
> https://salsa.debian.org/science-team/blis/blob/master/debian/rules
> https://salsa.debian.org/science-team/openblas/blob/lumin/debian/rules
...
> I'm quite interested in taking a look at how cdbs deal with such case.

IOhannes m zmölnig (Debian/GNU) writes ("Re: Cdbs Features"):
> On 14.05.19 14:35, Mo Zhou wrote:
> > I'm quite interested in taking a look at how cdbs deal with such case.
> 
> https://salsa.debian.org/multimedia-team/snd/blob/master/debian/rules
> https://salsa.debian.org/multimedia-team/soundscaperenderer/blob/master/debian/rules

Wow.  This is like night and day.  My instinct is definitely that I
don't like cdbs but omg dh needs this feature.

I looked through the src:debhelper bugs and didn't see a request for
this.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Do we want to Require or Recommend DH

[Ben Hutchings]

On Tue, 2019-05-14 at 12:54 +0200, Andreas Tille wrote:
> On Tue, May 14, 2019 at 10:38:06AM +0100, Ben Hutchings wrote:
> > On Tue, 2019-05-14 at 11:07 +0200, Andreas Tille wrote:
> > > Can you give an example for a package that has a non-dh rules file
> > > "working for years" that gives as a result a package with no lintian
> > > warnings without changing this d/rules file?
> > 
> > linux is one.
> > 
> > I did a lot of work to address lintian warnings last year, and most of
> > that did not involve debian/rules*.
>  
> Please call me over-picky but without checking the history is your
> "most" not a sign that there is at least one change to d/rules which was
> needed to fix some lintian issue.

I can only see one change that dh would have handled for us.

> I do not want you to change linux
> d/rules file and I think it is pretty safe from beeing NMUed just to
> switch to dh.

Indeed.  There is definitely scope for simplification, but it takes a
lot of knowledge and time to do that.

Given what others have said, I doubt that dh in its current state could
handle the multiple configurations, which is a shame.

> My point was that I doubt that any "working for years"
> d/rules has no lintian issues.

If "working for years" also implies unchanged for years, yes I agree.

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.




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

Re: Do we want to Require or Recommend DH

[Thibaut Paumard]

Le 14/05/2019 à 11:07, Andreas Tille a écrit :
> Can you give an example for a package that has a non-dh rules file
> "working for years" that gives as a result a package with no lintian
> warnings without changing this d/rules file?

Turns out I can't... I was thinking of some packages that I didn't have
to touch for years, but I checked and I actually converted them to dh
that many years ago...

Regards, Thibaut.




signature.asc
Description: OpenPGP digital signature

Re: Cdbs Features

[Debian/GNU]

On 14.05.19 14:35, Mo Zhou wrote:
> I'm quite interested in taking a look at how cdbs deal with such case.


https://salsa.debian.org/multimedia-team/snd/blob/master/debian/rules
https://salsa.debian.org/multimedia-team/soundscaperenderer/blob/master/debian/rules

gfmdsrt
IOhannes

Accepted gcc-8 8.3.0-13 (source) into experimental

[Matthias Klose]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 14 May 2019 14:21:41 +0200
Source: gcc-8
Architecture: source
Version: 8.3.0-13
Distribution: experimental
Urgency: medium
Maintainer: Debian GCC Maintainers 
Changed-By: Matthias Klose 
Changes:
 gcc-8 (8.3.0-13) experimental; urgency=medium
 .
   * Update to SVN 20190514 (r2711166) from the gcc-8-branch.
 - Fix PR gcov-profile/90380, PR libstdc++/81266, PR libstdc++/89102
   (partial), PR libstdc++/88740, PR libstdc++/90165, PR libstdc++/90105,
   PR libstdc++/85965, PR libstdc++/89629, PR target/89424 (PPC),
   PR c++/88857, PR c++/89214, PR c++/89511, PR c++/89705, PR c++/89876.
   * Ignore any distro default flags for the hppa64 cross build.
Checksums-Sha1:
 5e0be5a87f0ddeb0d2782389066e8e667eeb25ee 21577 gcc-8_8.3.0-13.dsc
 59ae6a1104f4c5c7371e20c61e220e6180c7e1fb 778128 gcc-8_8.3.0-13.diff.gz
 75c944b322f9f4092e4746c63fe59e0ced66b86b 10043 gcc-8_8.3.0-13_source.buildinfo
Checksums-Sha256:
 36c09f080c873a181d2e37efbcd36511c15b97747c6ffb2a86157cdcceb00611 21577 
gcc-8_8.3.0-13.dsc
 a28cbc4a93fa286ad70543d3ae54e0d545cbfe60807941130f4eff03c189f859 778128 
gcc-8_8.3.0-13.diff.gz
 e3a4b22c4498f1fea326e02118d62e8a69ac11a13d05d62b0d0fa429223c3edf 10043 
gcc-8_8.3.0-13_source.buildinfo
Files:
 708130e1a41b8817c3115dad2cd726f5 21577 devel optional gcc-8_8.3.0-13.dsc
 31e36ae34f8df0414a5db488a7b11ff1 778128 devel optional gcc-8_8.3.0-13.diff.gz
 898abadbd83e3a27251ba619dfdf28c0 10043 devel optional 
gcc-8_8.3.0-13_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE1WVxuIqLuvFAv2PWvX6qYHePpvUFAlzas3QQHGRva29AZGVi
aWFuLm9yZwAKCRC9fqpgd4+m9QL3EACzty+fCzdgnFQMXlevfd8/mZLBBLD+YcLj
tIKlFeX28ePQirkqXjyZw6PJYvsrO+tewN8YErirTrun24S01suJ3qkl3U9C0utq
wTukRZqUtIlIB6xfNSWlmp8qZsV5boFvL72zfVj2MEcPjSAyARwuhPmcz/8GJ0Pv
StvjJOJgQy35PFJswohMYWM2o2QMLJRlF6i4ltMUdt0W43DE7WR1fyO+ml+R+pum
wq8ds8UXAdbOwo3xqyudkv8exZGFlS24X4zaQoIRA3g0m0iWMPJAElNkultUqQhQ
3VU8ukMr8tvd+rCsQitFrRvZhrCsVFnCmiTmkdD2tLHJynAYo/AfnRMPYStv90f8
Ir9Fga0PO8JZyiuB0ATXPU3A8NlChR0kB+7VYmcILKbRjuCSthgE9EBas2sTAk3R
azy6aflGiokEtoVRJqyBVmYedag6oH9yCNW5S9NkMtUKvNknL6GQOgMktHZrLjvR
yXMW20Qta065ZcCeBx94QBBvxFIWlOjlv8Hyf2DrPt1LtezFM7sls59XErobTPYF
I3/ejbdra7rK3uZS+Y2te5KD7ebqezzdI70FpvFAUJ4UpyYWhMtUeW42Bg4Su7Ej
9jtflXDTCtmkYQQ2w6pjeG8PVJSdoUS3Ej0SQrMLaz7A/ziok4W4Az4x8gOdpOOT
9iFizPrU2w==
=PAwy
-END PGP SIGNATURE-

Re: Cdbs Features

[Mo Zhou]

Hi,

On 2019-05-14 07:59, IOhannes m zmölnig wrote:
> i've migrated many of my packages from cdbs to dh, but there's one
> feature which cdbs sports and which i miss strongly (at least: the last
> time i checked) in dh (so much, that i haven't converted a couple of
> packages): building of multiple "flavours".
> that is: building the same code-base multiple times, with differing
> configurations.

Could you please provide some examples about the case you mentioned?
I need exactly the "multiple flavours" feature for at least 2 packages:

https://salsa.debian.org/science-team/blis/blob/master/debian/rules
https://salsa.debian.org/science-team/openblas/blob/lumin/debian/rules

On amd64 the two source packages will be compiled 6 times in order to
produce 6 different variants.

I'm quite interested in taking a look at how cdbs deal with such case.

Thanks.

Accepted postgrey 1.36-5.1 (source all) into unstable

[Peter Palfrader]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 09 May 2019 13:35:38 +0200
Source: postgrey
Binary: postgrey
Architecture: source all
Version: 1.36-5.1
Distribution: unstable
Urgency: medium
Maintainer: Antonio Radici 
Changed-By: Peter Palfrader 
Description:
 postgrey   - greylisting implementation for Postfix
Changes:
 postgrey (1.36-5.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Revert the 1.36-5 change due to a regression, discussed in #880047#.
 The same patch has also been included in 1.36-3+deb9u1 and reverted
 in 1.36-3+deb9u2.
 There is no point in creating a /var/run/postgrey/ to hold the pidfile
 as using /var/run/postgrey.pid seems to work just fine.
Checksums-Sha1:
 c97b53d17b95517941629586f1e29f56d81b980b 1592 postgrey_1.36-5.1.dsc
 f053fcf93685ee0a637926b941bdb7c5dba99401 23520 postgrey_1.36-5.1.debian.tar.xz
 a605714bc223a3a8a81d4c4ebd3895612b5e4146 57540 postgrey_1.36-5.1_all.deb
 8c22bb841ae81543fa1d843299b7db0a91903ba8 5758 postgrey_1.36-5.1_amd64.buildinfo
Checksums-Sha256:
 0ccbf1d4b18b921131f3d631885f1e1747fd219c51c9e9a9806e93b9da6f7621 1592 
postgrey_1.36-5.1.dsc
 4b655a305ca8a26c4968a5774376d7272fcf4cec0b8a10bd3fe87b0f47560948 23520 
postgrey_1.36-5.1.debian.tar.xz
 3c3800612c2c2d3230f08b1c15f4dbb9f50a85afe0370f5e11c574901ee4a3fa 57540 
postgrey_1.36-5.1_all.deb
 2a7acb180ab6017b66cf41d84765cf66b8109b483adae83c1f5173294910724e 5758 
postgrey_1.36-5.1_amd64.buildinfo
Files:
 1349a80a2e0d0e324f2351373157aa41 1592 mail optional postgrey_1.36-5.1.dsc
 72d2c6d392ca19c5a1f93a995005f806 23520 mail optional 
postgrey_1.36-5.1.debian.tar.xz
 5f92bcf83aed2b34541b3a585f57ac8a 57540 mail optional postgrey_1.36-5.1_all.deb
 8cf4a93ded4887f698f58271da351663 5758 mail optional 
postgrey_1.36-5.1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEs4PXhajJL968BgN2hgLIIDhyMx8FAlzUFNYACgkQhgLIIDhy
Mx8A1gf+LZAfwWlLsAF9t81nMPfdYdVks5pt5/K/bMAYw1AJERXEIRDnaX1IcoHs
chUOBCRoHg8uZWBH62aQxzrQi/v+6/aIjOg6PB2cdykf2kHUmgPYlfgXgeeaq6Da
apQtsS16LiM+3KHuXkumYI2jt1AfmeDPglY0BoKeHV0bgI3MraqZk7UEa7XOObm6
z/wOBALNMmbBcnJ78H3T3eDI5e2QXVnYF388vEmCBQmx2qw7NXWVQf2lb3XyXJhZ
WwRWDil2V567gJTvRjM9/KOci7DZfopI/mojrA/D6ZSK2/sJt9MkyM/abrNM4pOg
v5mz+NIqJZZqQDo5MY0IaBxgVkRcpg==
=vCXy
-END PGP SIGNATURE-

Accepted gcc-9 9.1.0-2 (source) into experimental

[Matthias Klose]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 14 May 2019 13:38:03 +0200
Source: gcc-9
Architecture: source
Version: 9.1.0-2
Distribution: experimental
Urgency: medium
Maintainer: Debian GCC Maintainers 
Changed-By: Matthias Klose 
Closes: 804190
Changes:
 gcc-9 (9.1.0-2) experimental; urgency=medium
 .
   * Update to SVN 20190514 (r271161) from the gcc-9-branch.
 - Fix PR target/89424 (PPC), PR sanitizer/90312, PR c++/90265,
   PR c++/90173, PR target/87835, PR libstdc++/81266, PR libstdc++/90397,
   PR libstdc++/90239, PR tree-optimization/90416, PR gcov-profile/90380,
   PR gcov-profile/90380, PR target/90357 (MIPS), PR target/89765 (PPC),
   PR c++/78010, PR c++/90265, PR c++/90173, PR fortran/90093,
   PR fortran/90352, PR fortran/90355, PR fortran/90351, PR fortran/90329,
   PR target/90379, PR bootstrap/89864.
   * Update the cross installation patch.
   * Enable Go on sh4.
   * Adjust some regex patterns used in the packaging for GCC 10.
   * Drop the build dependency on binutils-multiarch (libgo-9-dev is now split
 out into its own package). Closes: #804190.
   * Ignore any distro default flags for the hppa64 cross build.
Checksums-Sha1:
 fd9222bf43585a6b5394e7d2cb1692d770b75806 32461 gcc-9_9.1.0-2.dsc
 88b59dd131de778319a919572a174791c53d9a42 4866519 gcc-9_9.1.0-2.diff.gz
 68403f0513c9478231a02ea10c40934be9ba5ea0 11459 gcc-9_9.1.0-2_source.buildinfo
Checksums-Sha256:
 cbf53afc2cbc226d19fb724d3b75fc42b9df0ef3091af0899b262ae547cd80f4 32461 
gcc-9_9.1.0-2.dsc
 ba1a714f4cc9285660df444f83978a34c5bd96443047df0f20d795a84fba5b25 4866519 
gcc-9_9.1.0-2.diff.gz
 9a665a31b4827b7494ea5236debf44edfac6caa8a1a91b23992f31ab9f3117e0 11459 
gcc-9_9.1.0-2_source.buildinfo
Files:
 0c970d6da608ec648403b6fd35561475 32461 devel optional gcc-9_9.1.0-2.dsc
 b9f5d807d1013e26a2542cc29c0429fa 4866519 devel optional gcc-9_9.1.0-2.diff.gz
 7be54abcb264dcd2bc041384fb78f9f8 11459 devel optional 
gcc-9_9.1.0-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE1WVxuIqLuvFAv2PWvX6qYHePpvUFAlzarH8QHGRva29AZGVi
aWFuLm9yZwAKCRC9fqpgd4+m9YWgD/9p8/Kjj8R8uNdSoiRnjePtuLWL+Z8w+9a7
6hUcbIcNLn48UWanuU3axHOsLdESQdZzFrEAiyWTZC3AwxA9vrIKvoLM4VV63Ogz
nFjEdg1S5yTCucuABq2hDi6OCwgmvvK275kuqsVATcXb1cmKQkyu21BZaHchiRNx
w8XrnG0sSl1x3fRr9ojYOvdR+gForp1zY+xbC/bvudq3BaEn/yOkqz5eT+U6nhc8
ZXDUAxSsIdTslzO6IPJSDPrQ6qzvIX1GrsNaGmf7eSvLdfGfcoJ6CK0J3DGIYAwT
lVHfJCu+DMjB3HAjkwaaAPQvhZsIkHQDKIMZDC8Oi5Q853MYHvQFhX/MbV2E4k0s
O3I1KUYFSwelbPZLRnEl1SRqBi0seF0x/+UT7Eft1dC/JXqq3t67mxivu3lqvgB3
txJCoqD3FnvJww1yLuxhHZ8Y+SBsSYDQUKcy9JEkOjMM/vcwqNeVgVKJzHPyMicO
tMxOIgQnnaWwCIMK+ZuRXeLIS/BLwT5v+uJS67kSSPdGEr8ydye854VlU1OzSFDT
9UFYY9LLdzFgUWSx8LqvF243WwNeaDgdkRFfX/kBt8xDhKCRbgv4F3UIdYb2Y9L+
TnKS3PABXsCpBmnw/idUH5IknOaJ5DLmIsjS+5sM5Fvif4+aBtoMYn7pZmCMy3wT
rcOjYyOPSQ==
=XlJQ
-END PGP SIGNATURE-

Re: d-shlibs (Was: Do we want to Require or Recommend DH)

[Jonas Smedegaard]

Quoting Adrian Bunk (2019-05-14 13:47:02)
> On Tue, May 14, 2019 at 12:50:54PM +0200, Andreas Tille wrote:
> > On Tue, May 14, 2019 at 01:12:17PM +0300, Adrian Bunk wrote:
> > > On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> > > > On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> > > > > > >things simple for team mates.  I consider it a valid 
> > > > > > >request to every single maintainer to respect that other 
> > > > > > >people have good reasons to change her/his package.
> > > > > >...
> > > > > 
> > > > > Based on this rationale, Andreas should stop using d-shlibs.
> > > > > 
> > > > > Weird tools on top of dh are not that different from using a 
> > > > > weird buildsystem when debugging other peoples packages, and 
> > > > > d-shlibs is something I've seen involved in bugs more than 
> > > > > once.
> > > > 
> > > > Its the first time that I hear criticism about d-shlibs usage
> > > 
> > > It is fine in the current "maintainer can do anything" world.
> > 
> > Hmmm, I don't get it: I'm using dh and in addition I'm using a tool 
> > that enforces library packaging policy.
> >...
> 
> A tool nearly noone else uses or knows.
> 
> Spending time on trying to understand what such a tool does or why it 
> is needed in a specific package is not really different from spending 
> time trying to understand how a buildsystem works.
> 
> If it is generally useful it should be done by debhelper 
> automatically, otherwise it should not be used at all if the goal is 
> to make it easier for other people to make changes to your packages.

I like the smell of flexibility - e.g. debhelper offering a baseline on 
top of which can be sprinkled more exotic tweaks as needed.

I dislike the smell of monoculture - e.g. banning or merging into 
debhelper itself debhelper addon packages.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Do we want to Require or Recommend DH

[Holger Levsen]

On Tue, May 14, 2019 at 12:30:02PM +0100, Ian Jackson wrote:
> One thing that I found really good about dh is that you only have to
> write code about things that are unusual.  

indeed.

> This provides an excellent
> opportunity to leave a comment next to each weird thing explaining why
> it's there.
>   https://browse.dgit.debian.org/xen.git/tree/debian/rules#n111

wow, that's a *really* nicely documented rules file, kudos!


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: d-shlibs (Was: Do we want to Require or Recommend DH)

[Adrian Bunk]

On Tue, May 14, 2019 at 12:50:54PM +0200, Andreas Tille wrote:
> On Tue, May 14, 2019 at 01:12:17PM +0300, Adrian Bunk wrote:
> > On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> > > On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> > > > > >things simple for team mates.  I consider it a valid request to every
> > > > > >single maintainer to respect that other people have good reasons to
> > > > > >change her/his package.
> > > > >...
> > > > 
> > > > Based on this rationale, Andreas should stop using d-shlibs.
> > > > 
> > > > Weird tools on top of dh are not that different from using a weird 
> > > > buildsystem when debugging other peoples packages, and d-shlibs is 
> > > > something I've seen involved in bugs more than once.
> > > 
> > > Its the first time that I hear criticism about d-shlibs usage
> > 
> > It is fine in the current "maintainer can do anything" world.
> 
> Hmmm, I don't get it:  I'm using dh and in addition I'm using a tool
> that enforces library packaging policy.
>...

A tool nearly noone else uses or knows.

Spending time on trying to understand what such a tool does or why it is 
needed in a specific package is not really different from spending time 
trying to understand how a buildsystem works.

If it is generally useful it should be done by debhelper automatically,
otherwise it should not be used at all if the goal is to make it easier
for other people to make changes to your packages.

> Kind regards
> 
>   Andreas. 

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Do we want to Require or Recommend DH

[Ian Jackson]

Sean Whitton writes ("Re: Do we want to Require or Recommend DH"):
> I agree with Scott's emphasis on the distinction between new and
> existing packages.  Perhaps application of the distinction could be
> extended: perhaps there are other things that we could require of new
> packages, while creating no expectation that these requirements be met
> of older packages.
> 
> In general, if a policy requirement or convention should apply to new
> packages, then it should apply to existing packages, too.  But
> specifically where applying the requirement to an existing package is
> hugely more work than applying it to a new package, perhaps the
> requirement ought to be limited to new packages alone.

There is a big distinction between recommendations which directly
affect the functioning of the binary packages, and recommendations
which make future development easier.

For the latter - and use of dh is an example - it makes a lot of sense
to make the recomendations stronger for new packages.

I also think it would be very valuable for policy to recommend things
like this as the usual case, without mandating them.  If for any
reason the maintainer doesn't want to use dh, then they can leave a
wontfix bug open (or something) to document the reasons.

My own anecodote:

Last year I converted src:xen to dh from the previous baroque system
(which I think was based on a clone-and-hack of the machinery in
src:linux.)  The result is massively better.

But it was serious work to repeatedly debdiff the results, review each
individual weird thing and decide whether to keep it, try to reproduce
its effects with a dh override or whatever, etc.  This needed a high
level of familiarity with both the underlying software and Debian's
packaging practices.  Even so I caused a handful of regressions.

One thing that I found really good about dh is that you only have to
write code about things that are unusual.  This provides an excellent
opportunity to leave a comment next to each weird thing explaining why
it's there.
  https://browse.dgit.debian.org/xen.git/tree/debian/rules#n111

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

W sprawie zlecenia

[Agencja Interaktywna]

Dzień dobry,



zajmujemy się budową:
 profesjonalnych nowoczesnych 
dostosowujących się do urządzeń mobilnych
Stron i Sklepów internetowych.



Jeżeli chcieliby Państwo otrzymać bezpłatną propozycję dla Państwa firmy w tym 
zakresie prosimy o odpowiedź *_TAK_* na ten e-mail.

_ _ _ _
Z wyrazami szacunku
Agencja Interaktywna

Re: Do we want to Require or Recommend DH

[Andreas Tille]

On Tue, May 14, 2019 at 10:38:06AM +0100, Ben Hutchings wrote:
> On Tue, 2019-05-14 at 11:07 +0200, Andreas Tille wrote:
> > 
> > Can you give an example for a package that has a non-dh rules file
> > "working for years" that gives as a result a package with no lintian
> > warnings without changing this d/rules file?
> 
> linux is one.
> 
> I did a lot of work to address lintian warnings last year, and most of
> that did not involve debian/rules*.
 
Please call me over-picky but without checking the history is your
"most" not a sign that there is at least one change to d/rules which was
needed to fix some lintian issue.  I do not want you to change linux
d/rules file and I think it is pretty safe from beeing NMUed just to
switch to dh.  My point was that I doubt that any "working for years"
d/rules has no lintian issues.

Kind regards

 Andreas.

-- 
http://fam-tille.de

d-shlibs (Was: Do we want to Require or Recommend DH)

[Andreas Tille]

On Tue, May 14, 2019 at 01:12:17PM +0300, Adrian Bunk wrote:
> On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> > On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> > > > >things simple for team mates.  I consider it a valid request to every
> > > > >single maintainer to respect that other people have good reasons to
> > > > >change her/his package.
> > > >...
> > > 
> > > Based on this rationale, Andreas should stop using d-shlibs.
> > > 
> > > Weird tools on top of dh are not that different from using a weird 
> > > buildsystem when debugging other peoples packages, and d-shlibs is 
> > > something I've seen involved in bugs more than once.
> > 
> > Its the first time that I hear criticism about d-shlibs usage
> 
> It is fine in the current "maintainer can do anything" world.

Hmmm, I don't get it:  I'm using dh and in addition I'm using a tool
that enforces library packaging policy.
 
> > and I'm
> > fine with discussing this but I'd prefer not to spoil the current
> > thread.
> >...
> 
> It is actually part of it, due to:
> 
> >...
> > As far as I understood the point of the discussion is that we want to
> > get the whole archive more uniform to reduce the potential causes for
> > bugs *in* *the* *future*.
> >...
> 
> If this is the point, then weird tools on top of dh are part of the 
> problem just as weird buildsystems are.

d-shlibs is not really on top of dh.  Its invoked with override_*
and thus clearly separate from dh.
 
[Haskell-example snipped since I think this was discussed somewhere
 else.]

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Accepted virtualbox-ext-pack 6.0.6-2 (source) into unstable

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 14 May 2019 12:17:23 +0200
Source: virtualbox-ext-pack
Binary: virtualbox-ext-pack
Architecture: source
Version: 6.0.6-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Virtualbox Team 
Changed-By: Gianfranco Costamagna 
Description:
 virtualbox-ext-pack - extra capabilities for VirtualBox, downloader.
Closes: 928390
Changes:
 virtualbox-ext-pack (6.0.6-2) unstable; urgency=medium
 .
   * Try to not exit on some kind of errors during postinst/prerm,
 to avoid users being unable to recover a wrong installation.
 (Closes: #928390)
Checksums-Sha1:
 7ed3eb656012c7f2352b1d87a31bcfa5a3e3afc0 2116 virtualbox-ext-pack_6.0.6-2.dsc
 e03f55026757ad837b84e6f6f1ab5bb07f7f13e5 13488 
virtualbox-ext-pack_6.0.6-2.debian.tar.xz
 5822d1868a17f0d8d8f896f34694ce0a1370ad3c 6939 
virtualbox-ext-pack_6.0.6-2_source.buildinfo
Checksums-Sha256:
 c03cd8655908c1708b5c2c78c6ae6f118f8b64e186c90e81ec32d260abd9ddcc 2116 
virtualbox-ext-pack_6.0.6-2.dsc
 22900b039c25fd70c18d67f6e973715e9ecd22f5899fa279b0f8cf5bce8c1fe0 13488 
virtualbox-ext-pack_6.0.6-2.debian.tar.xz
 d7ad531f1ae0deda14020fbfe9f3c73a051ca65ec2c01ab36d297a68ae851d6f 6939 
virtualbox-ext-pack_6.0.6-2_source.buildinfo
Files:
 c258881814b465c698e589c610824954 2116 contrib/misc optional 
virtualbox-ext-pack_6.0.6-2.dsc
 4c4291e3ef55875fadbcb6da5e15bef6 13488 contrib/misc optional 
virtualbox-ext-pack_6.0.6-2.debian.tar.xz
 381f73f38194ec1d6ce768708bd234fe 6939 contrib/misc optional 
virtualbox-ext-pack_6.0.6-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAlzaltAACgkQ808JdE6f
Xdl1IQ/9GGBd3odiWi8Mq1G5N4mZ53Knl9HYxr7freYYZYT8JK89ZIFRLXWGiM56
YlRygTI6sgPhXRqDm/Rpyh39GW9gcDlxskzhsJBkB8YlYOk+oSW+VK+U9GcbIBk1
uu/By0ybJSpGgPCNGwsAeSSCMrKyPo3yVuZw3ODyfbQ8eUHkauR7pEuMtofJKPSG
b6DmhskY5+T2xFGSIEYBiBsoJlpD+dNEn57ny1aUR1OgNbdNhNgx9Ak1SG1UpY9F
KKEPABTUK4y7UccWpdGhsbobEcYvhAHb2MfpEuaYE9lx3edKuY0zcV/T42ke+8Ct
6fmU8DBydiBez+W9+1Y2SUbYmC9vicSJg4lKp8lHB49w9s0XIA2zthbqOBcSzxJj
YH6ifXIxNcKZ1iwcd8VVs8wKsOzj+E5qCTe51eU2VWrokHBsSDyYNinZXmo0u8qb
6kh8uSsqr4ChPPxAxPaKTAWZmRJJ4DkTg8tvK/t/DWXAm+9W956zD6rJyYGgmmpf
OkYYvsvs2z1SkxPRzIsKxqEG/fGmQazViHfMtAJzUiW65nwBpTqHDNtRbktG12MY
gdln0mmGyiRw94LHUhKu0T1hkegKUijl3Z4FWD4Jw0IJw7TmXCGTMTGw5CfhN+fX
jwpUprpQ8aYm2DPP0V95c7rwRdxyNl6NKSatLu9GcZ3hI527M90=
=pGxD
-END PGP SIGNATURE-

Re: Do we want to Require or Recommend DH

[Adrian Bunk]

On Tue, May 14, 2019 at 10:27:45AM +0200, Johannes Schauer wrote:
> Quoting Adrian Bunk (2019-05-14 10:11:46)
> > 
> > How well are you testing such conversions?
> > Based on work I've seen from you I'd guess your NMU would be better than 
> > average. Unfortunately this is not generally true.
> > 
> > Based on what enters the archive, "debdiff between old and new package" 
> > already seems to be something that many people are not doing - then
> > cleaning up after mass-NMUs would be much work.
> > 
> > I have even seen maintainers blindly replacing a complex old
> > debian/rules with the dh 3-liner, and all the bugfixes and
> > workarounds in the old one were bugs again.
> > 
> > To show the quantitative side of my argument:
> > 
> > The default change to parallel building in dh compat 10 alone has caused 
> > a three digit number of RC bugs, popping up at a pace of 1-2 RC bugs
> > per week for several years.
> > 
> > The problem is that anything that works for only 99% of all packages
> > results in such a high number of new bugs.
> > 
> > Parallel build bugs slipping through an upload can happen,
> > but maintainers not going through the upgrading checklist
> > and running debdiff between old and new packages as well
> > as testing them when doing dh compat bumps is harder to
> > excuse - and in practice this does happen.
> > 
> > There is no perfect solution here
> 
> What makes reproducible-builds not the perfect fit for this?
> 
> Whenever I converted a package to dh or bumped debhelper compat level, I 
> always
> checked whether the produced binaries were bit-by-bit identical to the ones
> before.

Don't assume everyone follows the same high standards as you do.

> Are there many errors that I would be missing by relying on reproducibility
> results?

The parallel build issues I mentioned might be missed,
but this is more exceptional.

dh compat 12 defaulting to dh_dwz might make the -dbgsym packages 
different, and other intentional differences might exist.

> Thanks!
> 
> cheers, josch

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Accepted debian-security-support 2019.05.14 (source) into unstable

[Holger Levsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 11:48:37 +0200
Source: debian-security-support
Architecture: source
Version: 2019.05.14
Distribution: unstable
Urgency: medium
Maintainer: Holger Levsen 
Changed-By: Holger Levsen 
Closes: 927450 928204
Changes:
 debian-security-support (2019.05.14) unstable; urgency=medium
 .
   * check-support-status.in: don't fail if security-support-ended.debX does
 not exist for the release d-s-s is running on. Closes: #927450.
   * postinst and check-support-status.hook: add code to create the d-s-s
 user's home directory if it doesn't exist, as schroot copies /etc/passwd
 from the host without creating the user home directories. Closes: #928204.
 Thanks to Santiago Vila.
   * d/control: set myself as maintainer to formally adopt the package and drop
 Christoph Biedl on his request. Many thanks for creating this package and
 maintaining it, Christoph!
Checksums-Sha1:
 90ee857b16f0561a5387e708effebe4a8ab25434 1857 
debian-security-support_2019.05.14.dsc
 cb1c968732d45b93c17477a5f9545b9890c05f4c 28572 
debian-security-support_2019.05.14.tar.xz
 7221a39398a23e72208468e801341d889d5f0dd6 6082 
debian-security-support_2019.05.14_source.buildinfo
Checksums-Sha256:
 f4b711ec35c09d575a604cdd41fe805e1d2987b73ec7fbfbc65e4d2a652acd26 1857 
debian-security-support_2019.05.14.dsc
 b46996790800af6c6eccd91d68f39ed83544d9b8e510cf36fbd8eafb64e7ebf2 28572 
debian-security-support_2019.05.14.tar.xz
 de9e9b5a7bcad343575302425ac368cf3de3aebcd1ffe0c4ab1f7c70d9bb0a7b 6082 
debian-security-support_2019.05.14_source.buildinfo
Files:
 d8a62da3a5f6f0174c9153adf2b60691 1857 admin optional 
debian-security-support_2019.05.14.dsc
 db7bb6bd2a4222160ed02679088eb6d5 28572 admin optional 
debian-security-support_2019.05.14.tar.xz
 b1c6482a1d9c2773f5c29f7d135ba3c1 6082 admin optional 
debian-security-support_2019.05.14_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAlzakhkACgkQCRq4Vgaa
qhyt9A//aRyrbwARHAkkbdtzGR8KbRX4PewxaXTwlwbXNwZD5xli6i8AqKbttkJY
AlCJleVBDTs53H6JuTjtXIkdNTZYSh6Du0AHJOVh3gtEKlD/vOC6qockO+nBBsqH
gX4W7qardFla2h9Sru14zrpnkIiviFpUQ2FXzQKFEzVFcrADO9WpNzQT4Kxwe8oU
twkWojX6AXW90K8fQkF891kA0R6B038ovJiZrlYNZYxXGJSn1LDN8wXTRmUpuLbl
SL9fsOf8paQsfIXGiV4/87PoGDSKpenJxgVJIitb/x3Af69E3r834PzPGxS4hsv1
i4PLCTVRD2Xib7md25othNiA4gkahjsD6LXAZD7SZPlbP8BJf/SssgWE9uOfVdwC
N2t/H9SqFuvKRUje3qHgxMmY2SbIcujqbIc9UPzqpNUBP7TXjjC6PWWFh26apjCg
UMXKvvj5bOsyBTI7HFVy7IIoGmaP93IgIDYPW7W2r9c04FGqPm7CHmS/AJq6cOr5
iSHLHe52n/5rNaQGJ7cx4yT821SvluWkBw+UNJJjnCVzAlx4rXl6g9La/pSczqzd
njiJbsXwqEvBdI0zNqJsM62qz3UFJU+VzWxlOIJit53mGOHUd1CeiNSDR7wZ4rIB
P3eocj8dAgdhu2117VFp6yeynZuDjo7DRGbsIsNvRmuf2mHfPPQ=
=sQM/
-END PGP SIGNATURE-

Re: Do we want to Require or Recommend DH

[Adrian Bunk]

On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> > On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote:
> > >...
> > > Andreas Tille's explanation (quoted below) is typical of what I've heard
> > > in this area.
> > >
> > > >To come back
> > > >to the question:  I'm positively convinced that we should strive to
> > > >unify our packaging as much as possible and in terms of d/rules file dh
> > > >is obviously the default we should pick.  I'd go that far that lintian
> > > >should issue some warning at "pedantic" level if there is no comment:
> > > >"I'm not using dh because ... ".  In other words:  Use dh in debian/rules
> > > >should make it into policy.
> > >
> > > >The rationale is that dh makes it extremely easy to understand other
> > > >d/rules files.  Specifically in freeze like now it is easy to touch
> > > >other peoples packages (just done this several times in the last weeks
> > > >and luckily close to all used dh).  Its the point of teamwork (and I
> > > >consider all people touching official Debian packages as a team) to make
> > > >things simple for team mates.  I consider it a valid request to every
> > > >single maintainer to respect that other people have good reasons to
> > > >change her/his package.
> > >...
> > 
> > Based on this rationale, Andreas should stop using d-shlibs.
> > 
> > Weird tools on top of dh are not that different from using a weird 
> > buildsystem when debugging other peoples packages, and d-shlibs is 
> > something I've seen involved in bugs more than once.
> 
> Its the first time that I hear criticism about d-shlibs usage

It is fine in the current "maintainer can do anything" world.

> and I'm
> fine with discussing this but I'd prefer not to spoil the current
> thread.
>...

It is actually part of it, due to:

>...
> As far as I understood the point of the discussion is that we want to
> get the whole archive more uniform to reduce the potential causes for
> bugs *in* *the* *future*.
>...

If this is the point, then weird tools on top of dh are part of the 
problem just as weird buildsystems are.

>...
> > When you debug for the first time a non-trivial problem in a complex
> > package like src:gcc-8 or in a package in an ecosystem like Haskell you
> > can easily spend hours just for figuring out what is actually going on
> > or how to pass additional flags. Whether or not the build machinery is
> > using dh is not a big difference when you have to understand what is
> > actually going on.
>
> I for myself prefer to debug code based on the same tool set.
>...

This is pretty much impossible.

dh is nice when it supports whatever you want to do,
but for everything else it is just another layer you
have to understand when debugging and fixing problems.

Imagine you want to make ghc pass an additional flag to gcc.

The layering is as follows:
Debian haskell scripts
upstream build system
ghc
gcc

You end up at questions:
How can I tell ghc to pass a parameter to gcc?
How can I tell the upstream build system to pass a parameter to ghc?
How can I tell the Debian haskell scripts to pass a parameter to the 
upstream build system?


debian/rules is already a 3-line
#!/usr/bin/make -f

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/hlibrary.mk


It wouldn't help you if that would be changed to a 3-line
#!/usr/bin/make -f

%:
dh $@ --with haskell


In either case there is a huge Haskell-specific build machinery you 
have to understand for making some kinds of debugging or changes.


> Kind regards
> 
>   Andreas.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Accepted gnome-shell-extension-desktop-icons 19.01.3-1 (source) into experimental

[Iain Lane]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 10:24:15 +0100
Source: gnome-shell-extension-desktop-icons
Architecture: source
Version: 19.01.3-1
Distribution: experimental
Urgency: medium
Maintainer: Debian GNOME Maintainers 

Changed-By: Iain Lane 
Changes:
 gnome-shell-extension-desktop-icons (19.01.3-1) experimental; urgency=medium
 .
   * New upstream release
   * Drop all patches, since they are included upstream
Checksums-Sha1:
 861d9d1323d6d0d30e52c02b2165655062c40a0b 2323 
gnome-shell-extension-desktop-icons_19.01.3-1.dsc
 2a79bda324ee81b0c233c9576b7bb87fc0e72dbd 47405 
gnome-shell-extension-desktop-icons_19.01.3.orig.tar.bz2
 e7c097cc8a24ce191f1be9cb739ec9d305d4b604 2504 
gnome-shell-extension-desktop-icons_19.01.3-1.debian.tar.xz
 ef613f968cdad6db89b248ca5865c939c8049077 11267 
gnome-shell-extension-desktop-icons_19.01.3-1_source.buildinfo
Checksums-Sha256:
 d4420aa4a28458dd2f7d8928e0e6166446e6c4bf73d6362580ee8f5d497178cc 2323 
gnome-shell-extension-desktop-icons_19.01.3-1.dsc
 c1025a8142365ec128f521ac7178645db9a70eeff4265d8a10479d94200a1fac 47405 
gnome-shell-extension-desktop-icons_19.01.3.orig.tar.bz2
 259f2f38ad87e9ad4c9730a38b74c7a23af634fc91ff50aa7c84f4af60fd62d8 2504 
gnome-shell-extension-desktop-icons_19.01.3-1.debian.tar.xz
 68831d9bb785a040231e178f63606fa11c65f162a155db1b3a2d7cb0ad444bf9 11267 
gnome-shell-extension-desktop-icons_19.01.3-1_source.buildinfo
Files:
 21297713484ec90af75b2998f894988b 2323 gnome optional 
gnome-shell-extension-desktop-icons_19.01.3-1.dsc
 0b2b05c256c2d55e7c7d3c2cf8b717d0 47405 gnome optional 
gnome-shell-extension-desktop-icons_19.01.3.orig.tar.bz2
 efd92def7e5996c15dd0334c8b8c4028 2504 gnome optional 
gnome-shell-extension-desktop-icons_19.01.3-1.debian.tar.xz
 16736785e94fc9f66f870f6df80d43e4 11267 gnome optional 
gnome-shell-extension-desktop-icons_19.01.3-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEPQ77lee1I38W6CJY41LVxRxQQdQFAlzaiY0ACgkQ41LVxRxQ
QdRtPhAAmCTXdS10cZTcoFFxDSJyYKFAEEj6XVYQxMMsL5ycpgM8fmjOeUMtdQiX
Un3coIwOm8QUeBlwmqOoewC4KuGI0ZsL0eMeNFTxxGIy/jtX3kkEMRTVy+p46xdd
ErcCG206Kw2MolWlpt2pM39wApZ3aHvvJOTMu4++7SsxAmg1jHKZZOgDEyPeu5+G
5cSITIT+jUh55yF+DIYI6SzIjGXZ/PgBsYK0yZ8YPs01czhPgN9T258w5gWrufdv
8FHOBCgchMB5dEAKBRjmoY73HiAe3ZPwWl5eseK6jKLurNJ1645GEy58trVk+hRq
FKeWWFqruiw/eMYRLSNeQsAJs9Yip3nIH4wWOcnmX1ue50MGRD4KVgRHT0dWbiXP
P8SfmWoOBGJv82BnD8dFG5JN3580OEpdhfxcL4YT0v9ej5UwW89eONHo9IjMe/NC
AoTxbwSxohf+d9H0ZTTOTNfAfG1hnNJ3AcusxvPClc46M21qnYDFQBnHsOijeCdy
kKT0ofx9r0aCvBhwX7AKAScbUODhPok68jTnVl+1/Y0i+MXmGqzXmia1wvAYssbP
QZmyub4oLP/DmyG+yCtP/j1UERD7vVpm+s4USCM8TnvyMDRRul0LGX9Ra59o4Ted
KWu2YREe6usxRqeQzhAQaNJgeQ6RTCxia6iikvAU/hQ/3AUo2h0=
=yk6F
-END PGP SIGNATURE-

Re: Do we want to Require or Recommend DH

[Ben Hutchings]

On Tue, 2019-05-14 at 11:07 +0200, Andreas Tille wrote:
> On Mon, May 13, 2019 at 04:22:49PM +0200, Thibaut Paumard wrote:
> > > Why Not Make this Change
> > > 
> > 
> > I would use dh for any new package and converting trivial packages is...
> > trivial. However converting a package with a more convoluted rules files
> > will take humanpower. While it may be justified to convert a mildly
> > complex rules file on a package that has some activity, I don't think I
> > would invest those resources to convert a package that's been working
> > for years without anyone touching it's rules files.
> 
> Can you give an example for a package that has a non-dh rules file
> "working for years" that gives as a result a package with no lintian
> warnings without changing this d/rules file?

linux is one.

I did a lot of work to address lintian warnings last year, and most of
that did not involve debian/rules*.

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.




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

Re: Do we want to Require or Recommend DH

[Andreas Tille]

On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote:
> >...
> > Andreas Tille's explanation (quoted below) is typical of what I've heard
> > in this area.
> >
> > >To come back
> > >to the question:  I'm positively convinced that we should strive to
> > >unify our packaging as much as possible and in terms of d/rules file dh
> > >is obviously the default we should pick.  I'd go that far that lintian
> > >should issue some warning at "pedantic" level if there is no comment:
> > >"I'm not using dh because ... ".  In other words:  Use dh in debian/rules
> > >should make it into policy.
> >
> > >The rationale is that dh makes it extremely easy to understand other
> > >d/rules files.  Specifically in freeze like now it is easy to touch
> > >other peoples packages (just done this several times in the last weeks
> > >and luckily close to all used dh).  Its the point of teamwork (and I
> > >consider all people touching official Debian packages as a team) to make
> > >things simple for team mates.  I consider it a valid request to every
> > >single maintainer to respect that other people have good reasons to
> > >change her/his package.
> >...
> 
> Based on this rationale, Andreas should stop using d-shlibs.
> 
> Weird tools on top of dh are not that different from using a weird 
> buildsystem when debugging other peoples packages, and d-shlibs is 
> something I've seen involved in bugs more than once.

Its the first time that I hear criticism about d-shlibs usage and I'm
fine with discussing this but I'd prefer not to spoil the current
thread.

 
> When you debug for the first time a non-trivial problem in a complex 
> package like src:gcc-8 or in a package in an ecosystem like Haskell you 
> can easily spend hours just for figuring out what is actually going on 
> or how to pass additional flags. Whether or not the build machinery is 
> using dh is not a big difference when you have to understand what is 
> actually going on.

I for myself prefer to debug code based on the same tool set.
 
> >...
> > And at some level I think we're asking whether it is appropriate to NMU
> > a package to convert it to dh.
> >...
> 
> Common causes of broken packages in the archive include:
> - dh compat level bumps
> - conversion of debhelper using packages to the short dh form
> - conversion from other build systems to dh

I agree that these are potential sources of bugs.  However, I do not see
much evidence that if an NMUer / team member does any edit on some
d/rules file would be different to the cases above.

> It is already a real problem when maintainers are bumping dh compat 
> levels without checking very thoroughly before uploading that this 
> didn't cause any regression - a dh compat level bump is a breaking 
> change and should not be done without due diligence.

+1
(But I do not see any argument against using dh here)
 
> And we do get broken packages packages uploaded where the NMU
> of a build system change (e.g. cdbs to dh) resulted in an empty
> package - whoever uploaded such a package clearly didn't even
> do basic checks.

NMUers should do debdiff - no matter what change was done.  And yes, it
happened also to me in the past once or twice that I uploaded an empty
package or package missing some files.  I do not remember whether it was
connected to a change to dh or not ... but mistakes happen.  The fact
that we might end up with broken NMUs is IMHO orthogonal to any cdbs to
dh change.

> In my experience, keeping existing packages at exotic build systems or 
> ancient dh compat levels causes fewer problems than people trying to 
> change that just for the sake of it.

As far as I understood the point of the discussion is that we want to
get the whole archive more uniform to reduce the potential causes for
bugs *in* *the* *future*.  This might come at the expense of some bugs
when doing so and IMHO the beginning of a release cycle (= after Buster
release) is a sensible point in time to do so.
 
BTW, Adrian, thanks for all your patience and bug fixing at an extremely
high rate.  It is really welcome and appreciated and I think its a good
chance to mention this explicitly here.
 
Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Do we want to Require or Recommend DH

[Andrey Rahmatullin]

On Tue, May 14, 2019 at 09:10:04AM +, Holger Levsen wrote:
> On Tue, May 14, 2019 at 02:07:11PM +0500, Andrey Rahmatullin wrote:
> > One can go further and say that people uploading broken packages are the
> > actual problem. After all, we have several classes of bugs caused by
> > people uploading .debs built in a broken env.
> > Not sure if we can fix this and how.
> 
> forbid binary uploads for everyone. allow binary uploads for some people
> for some packages sometimes.
People will find a way. Adrian was talking about uploading broken source
packages, I just provided a different example of the same problem.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Do we want to Require or Recommend DH

[Holger Levsen]

On Tue, May 14, 2019 at 02:07:11PM +0500, Andrey Rahmatullin wrote:
> One can go further and say that people uploading broken packages are the
> actual problem. After all, we have several classes of bugs caused by
> people uploading .debs built in a broken env.
> Not sure if we can fix this and how.

forbid binary uploads for everyone. allow binary uploads for some people
for some packages sometimes.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.


signature.asc
Description: PGP signature

Re: Do we want to Require or Recommend DH

[Andrey Rahmatullin]

On Tue, May 14, 2019 at 11:11:46AM +0300, Adrian Bunk wrote:
> How well are you testing such conversions?
> Based on work I've seen from you I'd guess your NMU would be better than 
> average. Unfortunately this is not generally true.
> 
> Based on what enters the archive, "debdiff between old and new package" 
> already seems to be something that many people are not doing - then
> cleaning up after mass-NMUs would be much work.
> 
> I have even seen maintainers blindly replacing a complex old
> debian/rules with the dh 3-liner, and all the bugfixes and
> workarounds in the old one were bugs again.
> 
> To show the quantitative side of my argument:
> 
> The default change to parallel building in dh compat 10 alone has caused 
> a three digit number of RC bugs, popping up at a pace of 1-2 RC bugs
> per week for several years.
> 
> The problem is that anything that works for only 99% of all packages
> results in such a high number of new bugs.
> 
> Parallel build bugs slipping through an upload can happen,
> but maintainers not going through the upgrading checklist
> and running debdiff between old and new packages as well
> as testing them when doing dh compat bumps is harder to
> excuse - and in practice this does happen.
One can go further and say that people uploading broken packages are the
actual problem. After all, we have several classes of bugs caused by
people uploading .debs built in a broken env.
Not sure if we can fix this and how.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Do we want to Require or Recommend DH

[Andreas Tille]

On Mon, May 13, 2019 at 04:22:49PM +0200, Thibaut Paumard wrote:
> > Why Not Make this Change
> > 
> 
> I would use dh for any new package and converting trivial packages is...
> trivial. However converting a package with a more convoluted rules files
> will take humanpower. While it may be justified to convert a mildly
> complex rules file on a package that has some activity, I don't think I
> would invest those resources to convert a package that's been working
> for years without anyone touching it's rules files.

Can you give an example for a package that has a non-dh rules file
"working for years" that gives as a result a package with no lintian
warnings without changing this d/rules file?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Cdbs Features

[Debian/GNU]

On 13.05.19 18:22, Sam Hartman wrote:
>> "Holger" == Holger Levsen  writes:
> Holger> - packages using cdbs. cdbs has features dh doesnt have and
> Holger> I dont think it's wrong to use cdbs. (
> 
> Just for my information, what are the big features cdbs has that dh does
> not?
> 

i've migrated many of my packages from cdbs to dh, but there's one
feature which cdbs sports and which i miss strongly (at least: the last
time i checked) in dh (so much, that i haven't converted a couple of
packages): building of multiple "flavours".
that is: building the same code-base multiple times, with differing
configurations.

while it is possible to do that with dh, it amounts to either a lot of
near-duplicate lines or quite some GNU make trickery, which i'd rather
not spread across multiple d/rules


fgamsdr
IOhannes

Re: Do we want to Require or Recommend DH

[Johannes Schauer]

Quoting Adrian Bunk (2019-05-14 10:11:46)
> On Mon, May 13, 2019 at 11:08:21PM +0200, gregor herrmann wrote:
> > On Mon, 13 May 2019 22:22:32 +0300, Adrian Bunk wrote:
> > 
> > > In my experience, keeping existing packages at exotic build systems or 
> > > ancient dh compat levels causes fewer problems than people trying to 
> > > change that just for the sake of it.
> > 
> > In my experience ancient debian/rules runes are also a cause for
> > repeated RC bugs and the need for NMUs.
> > 
> > Real life example:
> > https://tracker.debian.org/media/packages/libm/libmp3-info-perl/changelog-1.24-1.2
> > 
> > Both RC bugs wouldn't have happened with dh(1); and the second NMU
> > wouldn't have been necessary if I had switched to dh(1) in the first
> > one.
> 
> How well are you testing such conversions?
> Based on work I've seen from you I'd guess your NMU would be better than 
> average. Unfortunately this is not generally true.
> 
> Based on what enters the archive, "debdiff between old and new package" 
> already seems to be something that many people are not doing - then
> cleaning up after mass-NMUs would be much work.
> 
> I have even seen maintainers blindly replacing a complex old
> debian/rules with the dh 3-liner, and all the bugfixes and
> workarounds in the old one were bugs again.
> 
> To show the quantitative side of my argument:
> 
> The default change to parallel building in dh compat 10 alone has caused 
> a three digit number of RC bugs, popping up at a pace of 1-2 RC bugs
> per week for several years.
> 
> The problem is that anything that works for only 99% of all packages
> results in such a high number of new bugs.
> 
> Parallel build bugs slipping through an upload can happen,
> but maintainers not going through the upgrading checklist
> and running debdiff between old and new packages as well
> as testing them when doing dh compat bumps is harder to
> excuse - and in practice this does happen.
> 
> There is no perfect solution here

What makes reproducible-builds not the perfect fit for this?

Whenever I converted a package to dh or bumped debhelper compat level, I always
checked whether the produced binaries were bit-by-bit identical to the ones
before.

Are there many errors that I would be missing by relying on reproducibility
results?

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Do we want to Require or Recommend DH

[Adrian Bunk]

On Mon, May 13, 2019 at 11:08:21PM +0200, gregor herrmann wrote:
> On Mon, 13 May 2019 22:22:32 +0300, Adrian Bunk wrote:
> 
> > In my experience, keeping existing packages at exotic build systems or 
> > ancient dh compat levels causes fewer problems than people trying to 
> > change that just for the sake of it.
> 
> In my experience ancient debian/rules runes are also a cause for
> repeated RC bugs and the need for NMUs.
> 
> Real life example:
> https://tracker.debian.org/media/packages/libm/libmp3-info-perl/changelog-1.24-1.2
> 
> Both RC bugs wouldn't have happened with dh(1); and the second NMU
> wouldn't have been necessary if I had switched to dh(1) in the first
> one.

How well are you testing such conversions?
Based on work I've seen from you I'd guess your NMU would be better than 
average. Unfortunately this is not generally true.

Based on what enters the archive, "debdiff between old and new package" 
already seems to be something that many people are not doing - then
cleaning up after mass-NMUs would be much work.

I have even seen maintainers blindly replacing a complex old
debian/rules with the dh 3-liner, and all the bugfixes and
workarounds in the old one were bugs again.

To show the quantitative side of my argument:

The default change to parallel building in dh compat 10 alone has caused 
a three digit number of RC bugs, popping up at a pace of 1-2 RC bugs
per week for several years.

The problem is that anything that works for only 99% of all packages
results in such a high number of new bugs.

Parallel build bugs slipping through an upload can happen,
but maintainers not going through the upgrading checklist
and running debdiff between old and new packages as well
as testing them when doing dh compat bumps is harder to
excuse - and in practice this does happen.

There is no perfect solution here and I also get your point,
what should be taken into consideration is that there is a
tradeoff between the benefits and the regressions of breaking
changes like dh compat bumps or even conversions to dh.

In my experience people are already pushing too much towards 
"use dh with latest compat" in existing packages, and it would be
better to slow that down rather than accelerate it even further.

> Cheers,
> gregor

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Do we want to Require or Recommend DH

[Thomas Goirand]

On 5/13/19 11:42 PM, Iustin Pop wrote:
> Very side note: why is that package a binary package instead of
> arch-indep, if it contains only a man page?

Not only a man page, but a shell script that either creates a Qcow2
image for OpenStack or installs Debian on bare-metal.

With the way it works, it only makes sense on the listed architecture
where it has been tested. I wish there was a possibility to say "it's
arch all, but only works on these", but in Debian, we can't.

Cheers,

Thomas Goirand (zigo)

Accepted geoalchemy2 0.6.2-1 (source all) into unstable

[Edward Betts]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 07:05:27 +0100
Source: geoalchemy2
Binary: python3-geoalchemy2
Architecture: source all
Version: 0.6.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Modules Team 

Changed-By: Edward Betts 
Description:
 python3-geoalchemy2 - SQLAlchemy extension for spatial databases using PostGIS
Changes:
 geoalchemy2 (0.6.2-1) unstable; urgency=medium
 .
   * New upstream release
Checksums-Sha1:
 f7bcf1a9ef0b43878310b3599063c2ac02230d39 2369 geoalchemy2_0.6.2-1.dsc
 833e98f364130193e0221d56a1d0730442985d5b 10 geoalchemy2_0.6.2.orig.tar.gz
 0647ac42c6068a9fdfe911a90903e454611f9e9a 3564 geoalchemy2_0.6.2-1.debian.tar.xz
 bf3389e28d734fdf595cd0341fbc40d9293b8988 9833 
geoalchemy2_0.6.2-1_amd64.buildinfo
 4db2cf93510487831fc36409584c058f7ec8ae23 17812 
python3-geoalchemy2_0.6.2-1_all.deb
Checksums-Sha256:
 92ae52eab5a1f07082f2cb8f2115486884151a6a1b990efc1a6f12666a25f634 2369 
geoalchemy2_0.6.2-1.dsc
 287e8f11fdc241e8cb4a280bc16b5a5912038499819d8c47f5e482c35b5c9044 10 
geoalchemy2_0.6.2.orig.tar.gz
 f4f089e7de6a8cbbb8a3d9af82f135de2198d670888625390490dea9cb63ebd9 3564 
geoalchemy2_0.6.2-1.debian.tar.xz
 2a011b7b9ff5e2d096702368b9ba85021746536416b5182fede105f318414850 9833 
geoalchemy2_0.6.2-1_amd64.buildinfo
 ef5c62ac28e8494054313319b004179e2edea1e1b0215d6f37f2fc5921786897 17812 
python3-geoalchemy2_0.6.2-1_all.deb
Files:
 7788faabef15e15f8174076cf3c9f167 2369 python optional geoalchemy2_0.6.2-1.dsc
 580cf0c8a01d944e4d5f95502692950a 10 python optional 
geoalchemy2_0.6.2.orig.tar.gz
 333873988155dbd1ffb29d5a2c1b9127 3564 python optional 
geoalchemy2_0.6.2-1.debian.tar.xz
 b8b1cad26b6e71a25709b61602414e93 9833 python optional 
geoalchemy2_0.6.2-1_amd64.buildinfo
 439bd642f79ec5d9460d8c7f87719e92 17812 python optional 
python3-geoalchemy2_0.6.2-1_all.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+4rPp4xyYInDitAmlgWhCYxjuSoFAlzaXGQACgkQlgWhCYxj
uSofXA/+ON8pDTwYlE//mVF+SrJb5ep+FKkeCiHHmTgtf5QFOI3py1AGCoY1OQHg
zi5uSrKkSHC9L+KQJFnuVkTd6oW9+dg7JwUhGi3UahBlIotug7WXQ/9VVHeAbohz
QPtj0+CC2PANC5L1dSNrScAEJaPAiQCZ3TctSizpDP5f+AJQ31w5Seq440ATHIEn
mPupgF8TJgrsEJD913iVbIi7LIjwxiL6KtXAQCzbz5Q48dTu2vAHR6qvCGBjkRp6
NtLJOW+SfvBPKmfY0m/8dcc35QCLoe/+ScmtXJeb6HZrYT5x2NjSq6Z2w6s9cuV6
1lZl6yxxr/h5TWfR7qF2ZO7W7Ld3KAGiCQDKmdu11LcxVCFd4tcGgRcC7mBmmIVK
X1xuMFKrrzlADEq4uRgZuc/ZoJKPjg+p8CgYlYuSnZWEg26rLTOCybtMqbG9NGg1
+IpqBMUBuwE/SYFTt0OFtnTfzIrfEEVd9AukAT/SAvBd+acAmkrZYz+mF/Tw6TWd
6oCko0q8dVo36uHp9UKzxNx2cm/s4QSFv4RPur/zmpHsA0IOqKv4e5fMWSU4BtUa
YNboCcefaUBgB3kVeaEhpoiFo11IclYV0ypBTbnean7384MnZGIdfPxakXh/JLZF
H/tNqFIKWWGYFMyKrJ9SXjSXT+NqljFzLyBkVZpEiQf+za5cqmo=
=YHjw
-END PGP SIGNATURE-

Re: Do we want to Require or Recommend DH

[Paul Wise]

On Mon, May 13, 2019 at 8:34 PM Sam Hartman wrote:

> As promised, I'd like to start a discussion on whether we want to
> recommend using the dh command from debhelper as our preferred build
> system.

This is already the case AFAICT.

> But I think what we're really talking about is whether maintainers
> should be expected to apply well-written patches to convert a package to
> using dh.  That is, is not using dh a bug.
>
> And at some level I think we're asking whether it is appropriate to NMU
> a package to convert it to dh.
>
> Today at least I don't think we're talking about making not using dh an
> RC bug.  It would not make a lot of sense to me to start there.

I don't think these are appropriate.

I think conversion to dh should only be done when doing hostile
hijacking of packages, salvaging packages, adopting packages,
orphaning packages or team/maintainer uploads and only if the person
doing the conversion builds the package twice (with and without dh),
inspects the resulting changes to the binary packages with diffoscope
and is confident that each change is appropriate.

> Exceptions
> ==

I think we should allow the cdbs maintainer to use cdbs instead of dh
in their packages :)

> so, what do you think?

I don't think there is any way to require packages use dh, unless you
want to forcibly remove/orphan packages or remove maintainers that
won't use dh?

I think that we should encourage experimentation with better
alternatives to dh, such as if someone wanted to revive the efforts to
build Debian packages using Gentoo's ebuild framework.

http://penta.debconf.org/dc7_schedule/events/69.en.html

--
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted gnupg2 2.2.13-2 (source) into unstable

[Daniel Kahn Gillmor]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 02:08:47 -0400
Source: gnupg2
Architecture: source
Version: 2.2.13-2
Distribution: unstable
Urgency: medium
Maintainer: Debian GnuPG Maintainers 
Changed-By: Daniel Kahn Gillmor 
Closes: 918466 918586 927431 928963 928964
Changes:
 gnupg2 (2.2.13-2) unstable; urgency=medium
 .
   * Correct gpg-wks-server manpage (Closes: #927431) Thanks, ju xor!
   * Fix handling private keys with comments (Closes: #928963, #928964)
   * clean up logcheck rules for gpg-agent (Closes: #918466)
   * Update gpg-wks-client.1 (Closes: #918586)
   * cherry-pick more patches from upstream STABLE-BRANCH-2-2
Checksums-Sha1:
 fd73cfd1c8d97262dea164e7fcb517eedf7c000b 3136 gnupg2_2.2.13-2.dsc
 fdf9ca3ac945bd32beaca74023b6d2a56a539285 69624 gnupg2_2.2.13-2.debian.tar.xz
 f59129a854c557540f9d5c21d484954d5da2a2e4 19146 gnupg2_2.2.13-2_amd64.buildinfo
Checksums-Sha256:
 470e4d777fa6a9823cb2008f67bff962bae38601e69d8d06f6912d268a0968fb 3136 
gnupg2_2.2.13-2.dsc
 2d7be1b11190c64194e07f6d797692c8052e6476abe558de2079386220387cad 69624 
gnupg2_2.2.13-2.debian.tar.xz
 94d88901d436ff4fa81d8c1c6034a28e5f5ee0fc284e6459e07d4bb52db3c903 19146 
gnupg2_2.2.13-2_amd64.buildinfo
Files:
 0a8f4cc0c4c354e401c3cd72d2037678 3136 utils optional gnupg2_2.2.13-2.dsc
 d281a0608d9dfe2f4ae0280b84c69d2b 69624 utils optional 
gnupg2_2.2.13-2.debian.tar.xz
 a2dcea8f0e7ee2000f857fc2d8e6f717 19146 utils optional 
gnupg2_2.2.13-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXNpdSgAKCRB2GBllKa5f
+BpKAQC07t4pHC+O5dI8zboCAPinExJYrHyuRw/+I+DNL63fiAD9G2T3XsqcrvUT
zsDKJ37N5693lGBm1PYTB+0rQgsLtg8=
=nHkN
-END PGP SIGNATURE-