Accepted tuxpaint-config 0.0.13-2 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 22 Jan 2017 01:48:06 +0200
Source: tuxpaint-config
Binary: tuxpaint-config
Architecture: source
Version: 0.0.13-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 tuxpaint-config - Configuration tool for Tux Paint
Closes: 834780
Changes:
 tuxpaint-config (0.0.13-2) unstable; urgency=medium
 .
   * QA upload.
   * Set maintainer to Debian QA Group. (see #848989)
   * Add patch from Chris Lamb to make the build reproducible.
 (Closes:  #834780)
Checksums-Sha1:
 bd277c58b12d88081c6d60fe855df51d351d8ce8 1805 tuxpaint-config_0.0.13-2.dsc
 45e00991db94f9b64fabec9bd3adcaa1861a1ab1 3796 
tuxpaint-config_0.0.13-2.debian.tar.xz
Checksums-Sha256:
 b72a0a233e97665de2f2cafe4501bc8ed5c9140c9362a66269a9e9e170141dda 1805 
tuxpaint-config_0.0.13-2.dsc
 b118b2be24916dcb906090e6dc093e73bf6e88f4abe20832108078f2bb2438de 3796 
tuxpaint-config_0.0.13-2.debian.tar.xz
Files:
 aa5d58fa6b7bf960ae53b727dba61eaf 1805 graphics optional 
tuxpaint-config_0.0.13-2.dsc
 ec2dbbe35fb3821c12a44813ac6dc500 3796 graphics optional 
tuxpaint-config_0.0.13-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliD8/EACgkQiNJCh6LY
mLFwog/7BedGNOz0DuokASnBEGaPLnNMdf8gc2Twm2AysNB/LMjx83DUZutoDB9k
+TtjPzjXEXymfMb9ou9dHOHf/dznrostFd/tVeNMOJ+ZNq7ZN52GVHySx0C40bwX
/Z7koDQ3RYlZCPJW2kyiPk1CNzh8LjlLN6hb+M3puxP++sKkOog7LFzLEoWnAkOY
2lZKbC5hCljJy11TbQWzfrb3yxzaxJXxl0aPmsSXy0ZhltkYrC21ba9p1LYxLC9a
XU2bMp2IAqr4RnO9sQP++tny/gY649A2lTffnylhiiEPYWCHVSAQ/SgD73OAUJ2d
UAJ6XszXr4WRxMIaK1q5H14ruRQRKydvnr1h1TpD/ON6OwX7e7ZVRL9wgt6Po7JQ
C93zwk0ckfVeWS0js8GsBPMMI4VuXfZC3HsD8R0mcGSepbY58ZnQ9U3UL4mbOq40
yNuW1uHXbC4CtXVzdqKjZr0YIlq3dzoGZZcjvT3yKIFhCCC/x7yjTP2QnTDHLD1D
0fMagF5DA/re2qajzRoGWR9sBeIf+oPqI/7OZ5zvIub4mFNVbCQKkKkchwJ14S2m
bWzduu9IU4X4HSIx2/v98JG1PhtJVOAxGQVGBL9vDopyskIUsTnewoHJbqYNVq4+
Ec9Fiwx9GDvSEOO+AlkrmJ+Xm3YN3aWrJBEpsL4b3bD+3d5SVhA=
=BYPm
-END PGP SIGNATURE-

Accepted smstools 3.1.15-2 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 22 Jan 2017 01:39:26 +0200
Source: smstools
Binary: smstools
Architecture: source
Version: 3.1.15-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 smstools   - SMS server tools for GSM modems
Closes: 766196
Changes:
 smstools (3.1.15-2) unstable; urgency=medium
 .
   * QA upload.
   * Set maintainer to Debian QA Group. (see #839973)
   * Add the lsb-base dependency required for the init script.
   * Add Dutch debconf template translation from Frans Spiesschaert.
 (Closes: #766196)
Checksums-Sha1:
 9c96f339e095c2e0b68df2ed5d75850fe5bf0bbf 1723 smstools_3.1.15-2.dsc
 8406ddf4fb1c96059b33b7b7d6c5760641dcb33c 35291 smstools_3.1.15-2.diff.gz
Checksums-Sha256:
 2f79f19e7414a7a69a51d77dd17a3f63b1780182334089fce1a56909adb30ac7 1723 
smstools_3.1.15-2.dsc
 6ffb4d8885ade93c389c0cd50c1e617011eac2b42e7cfb5d2bb6b9ac8dfc2ef8 35291 
smstools_3.1.15-2.diff.gz
Files:
 6d7aa72a93bc0bdb58788bde67530b25 1723 comm optional smstools_3.1.15-2.dsc
 c2016a2fdfd7ad91a17cee657318df9e 35291 comm optional smstools_3.1.15-2.diff.gz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliD8mEACgkQiNJCh6LY
mLGvuBAAh0saDpTGjz+C/SjryIm/evysKWQv9ybNSeR0ydK5mpwVw3YaIJu59HnC
Zj6H5aU582UXQBAV71T/6H98NlCjDcMhsnaKJVzSAWaBMPXSoM78hrS72oNIxZ4k
cVhpGNybSbTGnBBH1IgExEfqg0aYVa/orm2URArS9sPeYBDzv2ssSc2LpXDokzt8
jyfC5wkC9e337zNVDIx1/4ICve2+2axDtP32OJNAUOEu76r9U5E9feeDQ9Cy0i7e
JiTJVyvDP/W4uKzCrImYqgUGDxfn5Ejc8vBRkPRLiBDrEuNosyMAyqIUIGOQF3dk
lUg/5gf0UglaE1Uk+govFCOQZ8kWRHU3wAkbopdZKeDNwfUExqEKoq2/uMpjhF4b
ViQIew34N8+tQuBUW2oCzCoGg+ijcCI5oJd12aQVMJsNT+yljMwRWW5W9+POtZK8
JXSlnnJZzW4MMlk4GeTPh7J857AEbVdeHEpC+j8zdgzP3UqPmeVsZscMn9LggvZA
rC+5gE23T87zRGNbhSb9ol8nNdt01PTVhgWz33Ixs5amLrCM7o3gtNVxnt9CD9b2
fnVaKMm8Z/iHFKTskcNzknWAMUYbbyYi9XvE6WeuM8WM5RWX2GTDdcmhmbJbG5p5
2YRn1E6w05KGhlfF+MJk8BRrt4wIuaQs/rBaAtY/btGJP28ZztY=
=4HJ4
-END PGP SIGNATURE-

Accepted snappea 3.0d3-24 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 20 Jan 2017 23:10:45 +0200
Source: snappea
Binary: snappea snappea-dev
Architecture: source
Version: 3.0d3-24
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 snappea- program for creating and studying hyperbolic 3-manifolds
 snappea-dev - development files for SnapPea hyperbolic 3-manifold tool
Closes: 375773
Changes:
 snappea (3.0d3-24) unstable; urgency=medium
 .
   * QA upload.
   * Add the missing dh-python build dependency.
   * Add .desktop file from Vassilis Pandis. (Closes: #375773)
Checksums-Sha1:
 dc96349f6862c3347b2ea09e7071cd31aa5e1d88 1755 snappea_3.0d3-24.dsc
 7e5ba522525981aafddbf2581995aaa7df0a7bed 632262 snappea_3.0d3-24.diff.gz
Checksums-Sha256:
 b7593cd4d7e489bae373146ee1365fc52dd19bb6404ea7506aa3a9f9ccfb0b47 1755 
snappea_3.0d3-24.dsc
 6ebdb9478f046d184d6e7edbf505ed137ee30b0a4184d9314012f82d6beb3b0c 632262 
snappea_3.0d3-24.diff.gz
Files:
 0a60ba451c60afa135e3b099b6f8c2d1 1755 math extra snappea_3.0d3-24.dsc
 cd53204e6183cd29b02ece456381e070 632262 math extra snappea_3.0d3-24.diff.gz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliCgpwACgkQiNJCh6LY
mLF51A/+Il9IFrKvAn5ipql5gs74k34smr6qYus7qSnVKFxmU/po/1h0kMVg8+52
MVcS9PycquT135tRYFTXlEVj0Dg5QHfufEZVN6KeXHzQgMGSGyeSIKo0S/+o2G6s
DHd6tpsPZxCE7xUz6un3ay8WXyq9ZmwRM6/W/zEQsQzkt7DQ9GtjwJ8UiMoYsrqz
6szEHBIRAV22xqZzxT3WDg8+2+dYsMjJkaOCyp9Lapn5fSievFclO+cmoxDsp5r0
+eEhBxs5ZWiFOkzh05qqnmL94yuatn7tpUs4+mkjEfweGtirh6QSM+Q8J7PsXWft
+mGaOc2hlEImAbxEZCQveQJDEBMpHYjx0m5SzPxMeo8lAcuzobAh19YFWFkKNuWV
7pF5UiVKABLEukUpbfs4yNvsElq/uGC3uXSBail51/7IsnGFwNMW8SGKRnfxqTNZ
OzmFgy/apOw3Rx/HwVRZIbS8kFpFafA0DNile9mFLI2OlZNu9j7mTy0SergUwfCi
trnxTOpiV2+q2mBziHCMWbzn0pfNVUL7Wyb4ATYcwTxPb8pko7Y3uGWWxMt5E+4O
QUiWLeOo0jVJ2hsgBKJXagnZZRkk7kURThPfzTIamUnXYI/Rvqzhc0qbuT24hNr5
iLxTEFa15frbzckaJuNYdP6oihlhYvyy5T95m00fwyJ1GZ1Stkk=
=2BKf
-END PGP SIGNATURE-

Accepted maelstrom 1.4.3-L3.0.6+main-8 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 20 Jan 2017 23:38:49 +0200
Source: maelstrom
Binary: maelstrom
Architecture: source
Version: 1.4.3-L3.0.6+main-8
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 maelstrom  - Arcade-style game resembling Asteroids
Changes:
 maelstrom (1.4.3-L3.0.6+main-8) unstable; urgency=medium
 .
   * QA upload.
   * Include header to fix implicit pointer conversion
 in Maelstrom-netd.c, patch by Logan Rosen.
Checksums-Sha1:
 de70cb995bcccb9f3c3cd656bb8057878b4ba07d 1866 maelstrom_1.4.3-L3.0.6+main-8.dsc
 4ba2022d9b77330a8570744807f0514f92c2cd29 22752 
maelstrom_1.4.3-L3.0.6+main-8.debian.tar.xz
Checksums-Sha256:
 0f5644fa95d716a948cbe24f6aca80b07bd0c56c24095896165a2497de6aef9c 1866 
maelstrom_1.4.3-L3.0.6+main-8.dsc
 ff1b47c70e159e086967becde79ab81ea88d16724daa5bfe12cb2b0a835bf5e3 22752 
maelstrom_1.4.3-L3.0.6+main-8.debian.tar.xz
Files:
 f3f585fe55e57823294e57dfcd9afee8 1866 games optional 
maelstrom_1.4.3-L3.0.6+main-8.dsc
 4da46293dd2776c0af24fe267a7698e0 22752 games optional 
maelstrom_1.4.3-L3.0.6+main-8.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliChcEACgkQiNJCh6LY
mLENYQ//Zg2ahkTBvftdzWNk7U7sbEFBVh4wo95S40DWdc2vOrkWMGYfaNOs5VHb
5tdBg0nwKdY8V5H6j7GPzMhd350xfSOgRHIawzAadUB5pXvIpR+7FzE3qLaOnVcd
nOghLPvy1U/6Rl+oTAdZorhZAtO4qhsT1GmfVGC/LGqAJjyDUnCwwRj8cn73YcLA
PVwsfl6hsnFtKsVooESBlh3Z3dGK5ikTzRm+24vaP71N7aW79gd94m53Zr/7BkOM
RkFryr/vksRBg1HOT5vOWO4YD7yv8qxBkhaMUnWmneVViNb+EE/Y3Idupl+A2Ksw
b1ZmF1iOFxoEbt8wIin+SfLrw7uPUjy6s5xo91BGi3DhzSYbqQW7p7R7MWG2qCHp
Xe/SiHNDwfucdSCv+p115RU9IibaePjY65Qb7pBaEMgJibrapb3IaUQPx7y3iDXY
tws5F1+q5EhSyxtsvI0TRxkrvUU0HnSIxww72MdxeoGXUH8xiDRK46q3OYsrL6xh
+kXskHkZBF/RVs/QB/8IDGnWb9bYJtrFn3QJVwApNV+VGpXr9w8klkHJMZXGvz2J
jZAO92DkLf+s2VUcCkRjh3WHMxU2DumREjuqicUxFo0i6a6eZABO439u5q7II9sU
5MZZ78UaF47G4B+iC8Uydb4qLDtI89sgFix8kzmdetBj7zeHdjI=
=EpXl
-END PGP SIGNATURE-

Accepted tuxpaint 1:0.9.22-3 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 22 Jan 2017 12:03:47 +0200
Source: tuxpaint
Binary: tuxpaint tuxpaint-plugins-default tuxpaint-dev tuxpaint-data
Architecture: source
Version: 1:0.9.22-3
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 tuxpaint   - Paint program for young children
 tuxpaint-data - Data files for Tux Paint, a paint program for children
 tuxpaint-dev - Development files for Tux Paint
 tuxpaint-plugins-default - Magic tool plugins for Tux Paint
Closes: 834109
Changes:
 tuxpaint (1:0.9.22-3) unstable; urgency=medium
 .
   * QA upload.
   * Set maintainer to Debian QA Group. (see #848988)
   * Apply patch from Chris Lamb to make the build reproducible.
 (Closes: #834109)
Checksums-Sha1:
 9b95076fbf9043179e8012bfa90898d66f596b70 2127 tuxpaint_0.9.22-3.dsc
 b16a39e4da28dffab8dc367a0748b618c594512d 10060 tuxpaint_0.9.22-3.debian.tar.xz
Checksums-Sha256:
 56ba6992e6bba5ca821fff1c06d21883a62f6b33d1b693d4a2863a9ba161ecc8 2127 
tuxpaint_0.9.22-3.dsc
 1c50ce1bce5b9179f29e39a8c31d7909cb9829f6bed69d554ddd08f2d6b29ccf 10060 
tuxpaint_0.9.22-3.debian.tar.xz
Files:
 5b194a04984a8b8a3cf1d68f0e8988cb 2127 graphics optional tuxpaint_0.9.22-3.dsc
 40cdb3eb6551af8a69f36ac79619af5f 10060 graphics optional 
tuxpaint_0.9.22-3.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliEhRcACgkQiNJCh6LY
mLFUaQ//ZeJgBnFzQhlkJoggRe8NUJFcGjCiDxD2HlXPMoc0aQmiuY2Av4aLI6JF
ggvs+1Fkb+N3NXOBd9vEWyn4l62c64r8msJ8uOPS6khSIwPjdScF9GtuAr76IP4G
pA+hauFIAc3lf8u/txoeoVwCX1CdnkjqbQhXbq9j8Qb/7BYJTTIbmcODGUzg6aZ2
sQYPFxD8x2ScADYPGJL3hQpwgeHeb5cq4gOKDOHW56ZTDsAtXXLmHUfW+NUpttUD
FlOs0PW5byxGogAzKDN0JWo3TIlqRgnklC1Ja1Be7I7YLNT+IHcs3yN1CL5AqEsZ
0WSUokceKcM2dsb8zXSG6vBw5iuqSfUWTShlY56rn6dp5HBbKrrZX8kGNt64InIR
5/z8Dr2tADYIuOvH/Wl0TXdUWhBPT5Z1GPppJP3e7Dg3N+eJO+aPeLvYw0vRw4Fa
Tc1QQ+sI8LzhPd9xf1OOumNHn8lJyv8PTcKyAUgrXYskEB1vR67iTSd/sFy25dPU
mwD8Fi0+GgRXqOlX2v39tq+zZPiphF4ZXABnaUcJFW/GCmM4osE391L5BTnDu/23
9Dfq8rBF2oJ7UY442OTMcIAeirrqltbhmuUZYld6aGBTO4RBHIf7YQ4aASwkdBc8
XlbdhplBGYNYQfpMS2RSVbyDJ6ZFzYx1Kc1igAqazuasWua5D8Y=
=oKeS
-END PGP SIGNATURE-

Accepted transfermii 1:0.6.1-3 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 22 Jan 2017 15:01:40 +0200
Source: transfermii
Binary: transfermii transfermii-gui
Architecture: source
Version: 1:0.6.1-3
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 transfermii - transfer your mii from and to your wiimotes
 transfermii-gui - transfer your mii from and to your wiimotes -- GUI
Closes: 557852 557853
Changes:
 transfermii (1:0.6.1-3) unstable; urgency=medium
 .
   * QA upload.
   * Set maintainer to Debian QA Group. (see #810996)
   * Fix spelling error in the package descriptions.
 (Closes: #557852, #557853)
Checksums-Sha1:
 73f8bb07a80d54153242e6b83945e55eaae887dd 1810 transfermii_0.6.1-3.dsc
 f1732447e0b8d48ea3b026755aedbc73dbd5 13397 transfermii_0.6.1-3.diff.gz
Checksums-Sha256:
 05d9e0994f8e3f7ed3bff70f62b03de964e265cbf88666e5766f65690a7df333 1810 
transfermii_0.6.1-3.dsc
 33a047a0e14c72f3fb445b8206313077491a8b473fc329a2010a5817d1f31f08 13397 
transfermii_0.6.1-3.diff.gz
Files:
 0a328fb31db21e52e1f3a383a438b31d 1810 utils extra transfermii_0.6.1-3.dsc
 c0e662e68409cba7d9b6866f5a17ec25 13397 utils extra transfermii_0.6.1-3.diff.gz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliErkUACgkQiNJCh6LY
mLGXnhAAydBW82jU1jFoL/P/frvo1KxTEdF1iXiwSPm99OrxUye/Vak+ia2mpzRj
Wcwp/+zpMV9yWSzi64nDu66acF/zTfFwQhwFDwZlBFW6cSbrXugvLNffqFEQN12b
PIzhoQp4anCgFo/cHvZ9fbq9bNVMZ2CI3RskPqN3QNNzAHV5v1YrO0r/Sm64bjTQ
MWfKKCzf8t+D0WRKIXzZJa2FjRQkjbvtXPepsBvUWueEn5uNia0Io9xgY8Z7uVih
ug4dYv8fAhUFP1r9H5f9Ehpcmmm0x03UHzHmPYpQIBzbHMFwaISmr4VS/aFaWHyv
FyaKn46DkMWDwcotizIB7FGXUy2cVMm1fL93ZgcTrvArSCci04hjAM5h0LEukQPJ
CUlqkGmx3J5I0xKoVsqPAd0JKLRh4GlKQWpiHZpDs1FvVWQDC9eavAlQcxTq3jPX
RaGIIeGkqtCVnWlSHUVMqALkjzsVGFplmoEnEaXhDkbvULTK6xVAK0S9SiOm+pw5
6VsIT55/a4aMp4dfFRhufDgRFaBVNzD8HKJQtQf3R9ZoRbJqFl1aLe13F/TBOAIs
RtNywC5+RcxaDFeHmLf7SzwJkctRVtDkkk5duvCBXU6HSLUEOdN4f5O8UrGm/jbY
U4Af1G59nBQqW36TxazPFKl760ytXWxGnxgpx0rbwVnEF8expg0=
=Lywd
-END PGP SIGNATURE-

Accepted xmldiff 0.6.10-3 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 25 Jan 2017 21:25:02 +0200
Source: xmldiff
Binary: xmldiff xmldiff-xmlrev
Architecture: source
Version: 0.6.10-3
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 xmldiff- tree to tree correction between xml documents
 xmldiff-xmlrev - xmldiff output formatter
Closes: 833327
Changes:
 xmldiff (0.6.10-3) unstable; urgency=medium
 .
   * QA upload.
   * Set maintainer to Debian QA Group. (see #852629) (Closes: #833327)
Checksums-Sha1:
 b9b43ed7f1dd983da2f3d788bec152f264e5f829 1811 xmldiff_0.6.10-3.dsc
 77d8c2cadce4576c79b366d0979ab8274072647f 4643 xmldiff_0.6.10-3.diff.gz
Checksums-Sha256:
 f3e4e2f8c93f092b78e724c56becc1e1190ebd3a00773ea373ecadef53ab4854 1811 
xmldiff_0.6.10-3.dsc
 2c7d6b85d548ce454672339631884f931c80fda7bb9e02b0499b8e593ece2028 4643 
xmldiff_0.6.10-3.diff.gz
Files:
 ea7fc33d7f38f6998de92bf266f93e9a 1811 misc optional xmldiff_0.6.10-3.dsc
 4c7ea052a248594da2c7aa5d5cfcd9d5 4643 misc optional xmldiff_0.6.10-3.diff.gz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliI/csACgkQiNJCh6LY
mLEDHg/6A2L/MYTQvtaavcN0G7hBcXUcBh376gMW3KMs7a2NnavHvAZ0Hjy24g2b
irUe1lGYpYp/JxjKdUx6U+xmW6G+/4ZbOXwIwjEfRhq7YSwARE+YLbZhzaixrmdK
q4rt+PP5P/B66f/Rw+YxsyNSMvovbdtYxDZarAA0hEHHaO/vFQafg+EAhTn2V4Ru
PH31KgO5a84/nIWEkFkqB5ULTOJ4Dml1N7WWjBWY6+VRpRmTMDT4E66cEhKPRLKZ
Vc53JOUZpEaZtzIQ4We46JyYqsKStqNDmq25M/YG2AXlvm9UqfELXKpmedASou1P
n0NTYFX5aR2+6xsqqTAPpzIyLatfPF2krbZ2MNhUcBAy1XDYj5q6PTx+JAtZrGe1
WtySEu7Bh55SK/RWLhRNt+eiA8gdaFZ1hwr0OrnTu5CaKBiILBwFu3bIWlw2iI5X
l9okNy3mj3QbNw4yRRWats+UxF2IPSnWFs+RkLCEVprlsNI6n2uwmvqD3wy51/mk
01IbUehhTOJWHnnR60jPPi7VLaUUwxXLK9zl9p6VrF51d/xnR+onbpsimO/x3xxt
m1VgKUzXb8+B4lLy8lyc9dmtvrHwQNUgqtREUptnEYUAaLttoeYlQtlDLd8TfZyZ
1cn1slE8ULfmTgH2q25S9hKUlsVIm8E3261jDLaaTQ9ey/+7hrw=
=UltL
-END PGP SIGNATURE-

Accepted kstars-data-extra-tycho2 1.1r1-9.1 (source all) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 24 Feb 2017 05:03:46 +0200
Source: kstars-data-extra-tycho2
Binary: kstars-data-extra-tycho2
Architecture: source all
Version: 1.1r1-9.1
Distribution: unstable
Urgency: medium
Maintainer: Noel David Torres Taño <env...@rolamasao.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 kstars-data-extra-tycho2 - Tycho-2 star catalog for KStars
Closes: 757490 854008
Changes:
 kstars-data-extra-tycho2 (1.1r1-9.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Move data file to /usr/share/kstars where kstars expects it.
 (Closes: #854008)
   * Add Turkish debconf template translation from Mert Dirik.
 (Closes: #757490)
Checksums-Sha1:
 149408a154515bf987f394e4d1ace36e20bd3bab 1865 
kstars-data-extra-tycho2_1.1r1-9.1.dsc
 57cd332f10c899333bfd57c22a6e10cc7a145cac 16428 
kstars-data-extra-tycho2_1.1r1-9.1.debian.tar.xz
 2084446ba880e5702c68c61bb9b65c808205036e 29081214 
kstars-data-extra-tycho2_1.1r1-9.1_all.deb
 965f95772a31737acd4bcdf643b0ded57d6e0fca 4676 
kstars-data-extra-tycho2_1.1r1-9.1_amd64.buildinfo
Checksums-Sha256:
 91f72edb13f59207ec0cd973efb69412b6a5efd8de7950a79637439cf2d33745 1865 
kstars-data-extra-tycho2_1.1r1-9.1.dsc
 a8b64e9bc52ace144951c2eacfd5982a3b1fba97b52ad02f76c645b842814b31 16428 
kstars-data-extra-tycho2_1.1r1-9.1.debian.tar.xz
 b336057eb063f572d07dd9c26830a0d4e3798cf78444819b28c499dac5bb1c8e 29081214 
kstars-data-extra-tycho2_1.1r1-9.1_all.deb
 56c4c7f3c4a2c40bcb1e37a5606075862430e283411577542d1a37ae51bb39f8 4676 
kstars-data-extra-tycho2_1.1r1-9.1_amd64.buildinfo
Files:
 a5ae2850e0b3fd00fa47f7badf7b12e4 1865 non-free/science extra 
kstars-data-extra-tycho2_1.1r1-9.1.dsc
 945dc916fd032efb43248898d5d891e9 16428 non-free/science extra 
kstars-data-extra-tycho2_1.1r1-9.1.debian.tar.xz
 5afc4c19833c2e1cac86fdc9f80917cd 29081214 non-free/science extra 
kstars-data-extra-tycho2_1.1r1-9.1_all.deb
 b7d3543762e78a71303e5d3cc57155d6 4676 non-free/science extra 
kstars-data-extra-tycho2_1.1r1-9.1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlivpocACgkQiNJCh6LY
mLHfsg//e7PvAVtYAjHWXcyxnt/xI940Ahszsaxq8OKnFx4YQfsD/XC9I5P3mOuH
P/nfVh0nbiRtOOy9RXPaUiT2e9Mhb8FkMXLaimEUrgqPZ2sKn6lHZ2s6xxYoxEyF
kNnNsNZCNZ7GvlQNJm+h6NKl6nUZAjfpRnyvERhZstUrC/XaCsPzhPgrnUCTtiie
ja2gQRWq14xKx5sgSiWnD45S6DrpJUjSmWLUz6VViujskLNa/ISg2UnhkZpbGAM1
aH5vqr1002xezZNbPkLTDHD/hgxcSD1BiBIHzWw4kXtwYMcNQkYeUKhvqLhfTQ0h
5/dJsPpZ8WddNbZGwi1Zz7eOFzMVhBJJcXZ6o7GmxSRC7ScHYgMkb5I4d3skKPbQ
/JTaaCUhblVHWfRYauH3jTyxofa3JXx2CBThfvbcw3ty16KI6r2+SC3/NFJ/JYIG
4XT13LF65GyhmNdeMADcFpLMHVXEh37f9+iUEbiUMn//xNOSbomlX5vn3Brq/DrU
GfXXyzV8seDE3Nxnz0AEK2GQlk688JeVTmRbDC5MZ3h60l4azpm3My+lOAvZ+Wap
T9dKycZOg7kFEsS/64D6ssiMKQIJ8OM2pNEXIxLTaRiAlV6nZGCxlS19Rr/8Qh7e
hx3oDH7A5rZpvIDAGjpVWW6vm20U7k5rXfGNvDkXTeHvufq0Nvw=
=3wgo
-END PGP SIGNATURE-

Accepted ekg 1:1.9~pre+r2855-5 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 23 Feb 2017 16:37:45 +0200
Source: ekg
Binary: ekg ekg-gtk
Architecture: source
Version: 1:1.9~pre+r2855-5
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 ekg- console Gadu-Gadu client for UNIX systems - ncurses UI
 ekg-gtk- Gadu-Gadu client for UNIX systems - GTK+ UI
Closes: 811234
Changes:
 ekg (1:1.9~pre+r2855-5) unstable; urgency=medium
 .
   * QA upload.
   * Disable parallel building to work around a FTBFS.
 (Closes: #811234)
Checksums-Sha1:
 9757a37b0654821642733066f7d194e9da5426e5 2048 ekg_1.9~pre+r2855-5.dsc
 48369ec501c4ec771ae5df8011d357ed879eda7f 14268 
ekg_1.9~pre+r2855-5.debian.tar.xz
 83a52de6e39140ae64219d568af077523c194d37 10926 
ekg_1.9~pre+r2855-5_amd64.buildinfo
Checksums-Sha256:
 2857c8bfe62348549dc220628b59280be54a74ff269b6347eb375b63a8e6345b 2048 
ekg_1.9~pre+r2855-5.dsc
 85b896b1b8c169439b365f3a88dc754b6ceb75391707b8e3953532724d4ac078 14268 
ekg_1.9~pre+r2855-5.debian.tar.xz
 ea24850b4b0683a2115b71540e54dc25031bac454a4803a4c4dc9f1e7257c324 10926 
ekg_1.9~pre+r2855-5_amd64.buildinfo
Files:
 a87e04b99a986026965aedd45831dcae 2048 net optional ekg_1.9~pre+r2855-5.dsc
 0bf834ccd3b1da7caa6e2b9b5776046f 14268 net optional 
ekg_1.9~pre+r2855-5.debian.tar.xz
 c779ab0d9f8f8aac5ae20a813eca8433 10926 net optional 
ekg_1.9~pre+r2855-5_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliu9XQACgkQiNJCh6LY
mLE+DA//du0lRb6kBfGDg/FDDs0/UhFNOS5fm4lYiFHlJv9kwnF7mcFuQMIXRb1K
ouVkkfZswDYE+Sotc9oQ6xCaNBulehB+bpkQbn2gx4nUpSDDS3d6ifdJBMdPEKwI
IansJYjaHBO/U0ysj4G3kv0aQQDU3/n7APl/Pm2alGkGNQi7fQU9kw4MhpJjuKTU
hgofISP1bytZ/efpymefRGA459H48l3yW9JShX0WiXDw33J1OOX5H2P0N9ocGSv2
bRTuUmA/dHZ0+DleyWnyJlEFPLhixradC2AIOIYe3P8U4+5lr3+hYnm7lLrKlb64
A9OGpRpybtv6RXH/AWbG/NJHItF5lbZYeGvM6YctcO93J3NHuJxPo7h85m4pRUvj
IED818PNT57rxiEpUatmBjOj9N39mF/oAitIm8JfLiUcd1EGdv/e/O3KYBG6vNcb
hZkEzZq+/OLMDEZ+zKUVvPN3LqK8y15xVsQug/vW+RxpxERMRwaf25A2B77gwLVP
R1Ln4a5B3MAMEk3I878prGOb1QnSV2H4H025TbbmZLc63InH79DY+xtt8YmcyP9F
epH3cbsPSxT70fhrjQQqktbqnamT0LB6a5+Zw68eF6VKqP3BtX0RRWkJgPE2ZeHg
Feb59fXYdbb16kEBOOTjn590j8Yd45M3LiwsUhxnXApn5XxiXuo=
=ZiDx
-END PGP SIGNATURE-

Accepted transcalc 0.14-6 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 22 Jan 2017 15:08:05 +0200
Source: transcalc
Binary: transcalc
Architecture: source
Version: 0.14-6
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 transcalc  - microwave and RF transmission line calculator
Closes: 559201
Changes:
 transcalc (0.14-6) unstable; urgency=medium
 .
   * QA upload.
   * Set maintainer to Debian QA Group. (see #846811)
   * Apply patch from Ubuntu to use autotools_dev. (Closes: #559201)
Checksums-Sha1:
 5ffac5162659d72e374d0035cf0b1526c8f10a8e 1778 transcalc_0.14-6.dsc
 f23f646421e594c4814c867027bad1cd3d385dd9 3891 transcalc_0.14-6.diff.gz
Checksums-Sha256:
 553cb0a0cba3dad8fc02a58e418339569591c9011bfa6feb86b089b2756eabd0 1778 
transcalc_0.14-6.dsc
 4fab5761035989302a865d89bc190a7fa11ab6600206a4cc38e7a1149a371772 3891 
transcalc_0.14-6.diff.gz
Files:
 77312cbcad8ca88278d17ba2ca15b129 1778 science optional transcalc_0.14-6.dsc
 092c98d5e05b1718a8c509707c477c53 3891 science optional transcalc_0.14-6.diff.gz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliEsGIACgkQiNJCh6LY
mLGy/xAAwssK1pdLE6gUS4GjiFNjSV0b2JPoF8woeDPW2XBpcOvpFeACiyRIkoQ/
zA821HKd7gdMsn2n3Csto9urIwARiszyVIBALdSAbsMuDUFGZdXVQJdYjdgAaQ6q
zVIWMrmoHtKiDgqClZfK6l4woBILnqkWOkgA14eIXcvDdhTyQIZiqj+qNlEFYFTQ
OXBa0qV1a+UEnVPgVSw9TtN1q9XU8W/8KAAm/NBFBS1MQMkurKS9WLfT1tn6Unyz
G6PFkYBONQlrl7JBNqJVOPA+T/1+W5IPfvhdoGmnozCiZprzHzfsZIAkF2hoPF5f
v82NQSsBffnLFtYHVdF0TY2fVlOKHgBJtuX2/OIMTNh/B26ddwj/sh8k+XPROtkM
LXMNJrbmalWiy3aZKd+jEizOrsY21MsBbujstl+T7EpatVLZ0fa5z7go/UNqFY/Q
W9fJCv0eO76fGKIsKR/Gt3jr/n0PoR8sXkiLWE4bnjhRV4/IaZMVnpYdxuyqnkHs
qE/ANONRXN+9ymoKjxs4WJ9JSneCvCh4rR5GFg5PchdFBKFgMIDOVUDs4P+1XLxY
fR1GxoE+Flw0+S9h/l21f5Uv9F1l95e4hXVmDXr0SZVSqS4bjshQYRRBcKGMPOBs
HSbComGrgHzfrjUQjILoFH92SwHmguM49lJqE3FFPBlAg2OfW0k=
=kQ6Y
-END PGP SIGNATURE-

Accepted cvsps 2.1-8 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 19 Jan 2017 11:54:45 +0200
Source: cvsps
Binary: cvsps
Architecture: source
Version: 2.1-8
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 cvsps  - Tool to generate CVS patch set information
Closes: 775883
Changes:
 cvsps (2.1-8) unstable; urgency=medium
 .
   * QA upload.
   * Apply patch from Richard Hansen to stop cvsps from choking on
 servers that print more than one "M" response to "version" command.
 (Closes: #775883)
Checksums-Sha1:
 9ea0ef2a3c852126a0863658915af4bd84fa719c 1676 cvsps_2.1-8.dsc
 ca9f2b5c6c8dddf3f7fde67305f4b433b1448478 5940 cvsps_2.1-8.debian.tar.xz
Checksums-Sha256:
 17c4846b63501ae8102a61a50e5bb6e768154c62d8ddd29b5aff202d1452d9c1 1676 
cvsps_2.1-8.dsc
 e343d4186d439c91b6f51b6c0e44e5995b9e9fe6ab6fa6adc0e94f26fa5121b7 5940 
cvsps_2.1-8.debian.tar.xz
Files:
 54d37bd67ed430be2082bfdd72f05e9c 1676 devel optional cvsps_2.1-8.dsc
 8a3694e9a66205a56d7ee1fc25509c46 5940 devel optional cvsps_2.1-8.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliAjysACgkQiNJCh6LY
mLELihAAuX1ec7spF7ap+YvT537dpzPFpMjeY28uDzDdbF63ObYagAIish8NmiB6
wBZ3C504FF5U+6Ri37418CeRcKoKoIoi/FgUgRNrhon/V3Z4JBvTrS6AHH4pjtZZ
B1XSdB3NuMjRPAjYikhzbBDGrfzr1/k0xE43cqBQwWadbd/nhu3druiZeMPYhjfN
GWknI17OmzyfqF3jq7/JkTMjVAjK1IjyU8KgScrBZkOqvW0RQqpWRns60qnKUR7E
aY4NqJ6jGlZBh0lYCQTqhn7KZdA35m9H7IHlVy4q7e2FSiH5GU3f7cdvNZo7M86j
q4vnV/qfwVF9hS553PAOMgK7Hbji561HfI82259ZpSPmfLmiNwGucCKWfoqfN0po
pm9Rzj30vLWiAr8KsknBNuxeQhA6cvJoUgJ5KE8idWLFO+33EKhS7gdgs95nIq6A
HvBH8fH4NnQnIbg0HNzzyyf4L1BeJu7Ekaz3+R5udfGvE/rN5EcKWv8Sav6oHeL3
zfZV04mqli/YCCDL48MVdh3wrvzBvXnqZYRDxq58YuRzrubdogdENBNCqr8EFH17
rm1UzA3nBvG5a075My6sGc9jsY+4hRuvDVPI5PuQvWATNHj9wW6lvu4yClvWYppU
JecGvAjpkpi8slJYDJS+Q6ab+KR9mnU4Q/WjyKcOfpnwhBJ0doU=
=7Z2A
-END PGP SIGNATURE-

Re: [RFC] The PIE unholy mess

[Adrian Bunk]

On Wed, Jan 18, 2017 at 04:34:24AM +0100, Guillem Jover wrote:
>...
> At about the same time this was being considered, I realized that dpkg
> could enable this "safely" by using gcc specs files. But this is in
> any case also required to be able to disable PIE when it is implicitly
> enabled by default in gcc. So we'll need specs files no matter what,
> at least for now.

-no-pie is how PIE has been disabled in the packages where it was 
required, and this was already nearly finished before dpkg started
with the specs.

>...
> So, I'd like to know how people feel about the requested interface
> (i.e. not enabling PIE globally from dpkg-buildflags). If there's
> consensus that porters and maintainers want that, I'll just change
> dpkg-buildflags to do this, even though I think it's a very
> suboptiomal behavior.

The mess is that gcc and dpkg both try to set policy on PIE.
This should be done in one place.

Both gcc and dpkg would be options for being the one place.
gcc also covers the many packages that are not yet properly
passing flags from dpkg to the compiler, and this default
is working fine for 3 months now.

The number of packages requiring -no-pie was so low that I do not
think any support from dpkg is required for dis/enabling PIE when
gcc enables it by default.

> Alternatively, porters could as well request PIE be enabled by default
> in gcc on their port, which could make this also globally enabled.

This is a very good suggestion.

When PIE works without problems on a port, a porter should request that 
it gets enabled by default for that port in gcc.

When PIE does not work without problems on a port, nothing should 
enable it on that port.

> Thanks,
> Guillem

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 fauhdlc 20130704-1.1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 17 Jan 2017 17:35:42 +0200
Source: fauhdlc
Binary: fauhdlc libfauhdli-dev
Architecture: source
Version: 20130704-1.1
Distribution: unstable
Urgency: medium
Maintainer: FAUmachine Team <faumach...@potyra.de>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 fauhdlc- experimental VHDL compiler and interpreter
 libfauhdli-dev - interpreter library and development files for fauhdli
Closes: 835106 846422
Changes:
 fauhdlc (20130704-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Switch to working maintainer address.
   * Remove the obsolete DM-Upload-Allowed.
   * Add libfl-dev to the build dependencies. (Closes: #846422)
   * Add FTBFS fix from Stefan Potyra. (Closes: #835106)
Checksums-Sha1:
 90f600ebcc5fadc2155d078706c80e7718ba6c5f 1928 fauhdlc_20130704-1.1.dsc
 6f9b495854fa8688a605bafd5e53ed61967dc5eb 4192 
fauhdlc_20130704-1.1.debian.tar.xz
Checksums-Sha256:
 9f6bcdd0a787695e43bed94da9ccf60993c2ae463d063bda1078a2b80044c3b3 1928 
fauhdlc_20130704-1.1.dsc
 ca9820bd973153856f10b6dfffe254132090b1e84e16fca669cb33ed7724285f 4192 
fauhdlc_20130704-1.1.debian.tar.xz
Files:
 0c7dd31a801ad82cf9924ab1b04e 1928 devel optional fauhdlc_20130704-1.1.dsc
 44d26813661d2028b0acdd5253d12f33 4192 devel optional 
fauhdlc_20130704-1.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh+O2sACgkQiNJCh6LY
mLFm9A//VGuqogrvqMcdZZ/4mggMGRmBhmsVmOaVj2XOpdgqUw9sRlVK5LRTWYqx
G96QEvk1+DdSOAMByrgfpPaKWtECvafQEIMK6QL7bmWFE4b7BgpYWyJ2z4fyOwgp
9mRl96DxBTEfTU2/QygqatThNTcSAjyq20WL8O3J11W0sYTBwG7ewY2HE8+l174/
SAb3Ra0ln+IylvNRmpDs7ssxGNrOFlGFa6SLyxeAXLM32hmmbKxSQtowgs1bRUuL
Ev2cfICYsL99xYJIR/gPDQPfemMKSTovoC3IKqNZQ+Zbb5jcycZxf2SUt4sbslU/
Uk3Vp9VoVXpZNXXvz1xlDqJw0CPQFYumxzwaWLfyoejtQ4E0VZrfx2SxG/tqLIBw
imvSZgQ7ogaOExj6nH9LNdxGjKZfasKF9uZTfvXAp0IaunlqBuaNnQLlfpzPLyRb
b2DqZK9Xm44l9Xd0uE6+D+dmipfkamZq1tDs9NrpUciTlHs1SG5Cy4zy9NLQXHzD
Sd5vqiVUv9VT7Qx8ZfKtQQPqqMU3VqWn2meRdnHFmRmd38NHHY1OUeDUXC9mZvT2
GfRXTUrvYN6jzeROCRWWwPI0EB7JNeSLMxb8Opd0i4Yhfapwq9bKrOd+MHVJhOOO
Uy+UjkZANL44YaLMN3jwMSyxYSSc1Y7QIUwTzrK547vAMYxkaOs=
=N5Ri
-END PGP SIGNATURE-

Accepted util-vserver 0.30.216-pre3120-1.4 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 17 Jan 2017 16:03:26 +0200
Source: util-vserver
Binary: util-vserver
Architecture: source
Version: 0.30.216-pre3120-1.4
Distribution: unstable
Urgency: medium
Maintainer: Carlos Alberto Lopez Perez <clo...@igalia.com>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 util-vserver - user-space tools for Linux-VServer virtual private servers
Closes: 770362 850765
Changes:
 util-vserver (0.30.216-pre3120-1.4) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix postrm failure introduced in the previous upload.
 (Closes: #850765)
   * Add Brazilian Portuguese debconf translation
 from Adriano Rafael Gomes. (Closes: #770362)
Checksums-Sha1:
 3e4fc4b542dffee930b93080b2aea99b50381d0f 2258 
util-vserver_0.30.216-pre3120-1.4.dsc
 876d52769e5733fd2cf7201475cfaf7a0611e231 44584 
util-vserver_0.30.216-pre3120-1.4.debian.tar.xz
Checksums-Sha256:
 43cd994ab991d352f68f4f9fb87fd8186539e36e38ee25285dea8d80a4e5f05b 2258 
util-vserver_0.30.216-pre3120-1.4.dsc
 096191dccb9192a09d263c5ce6afb985d4d9eca4fd844f56d8d716c4bea9447c 44584 
util-vserver_0.30.216-pre3120-1.4.debian.tar.xz
Files:
 9da75c6bcdc2d0976c324d6cfd7643c8 2258 net optional 
util-vserver_0.30.216-pre3120-1.4.dsc
 3956ef7af2e21fa99e7581229da31b89 44584 net optional 
util-vserver_0.30.216-pre3120-1.4.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh+JpUACgkQiNJCh6LY
mLE+Hw//S+aUdNXJHLS/fAKf9K3yL7WSeQ2bw/hMkO4TQcGErivv5TxG0qXI60Mg
dK5gmALXShFNyiOCL3Q12zkA+lszGxZXzkJIbqBPdfflyruacxp3e9Kp8N2RYV4Z
SlfyMEqAvLEBgDXuQX7wGYpjh64ItydtEd68ijFBpx5Iga9Fi7Wb6stIF48s3VRE
9UtOHgzqZG3XoS0xdAknlix6mtnXN4tHayDLClKMNqwT6az87M67so1sQL2uTb3Y
lM9sTkwKRsLSe2tkUE5fEP6Mw8rG/hKAr9qgWD5g0/mbpuHUyCxZQJ3Uld/eE2xU
1wUSQCQyNWwA/Blct3ptv0l59lxcqQMn7QhciX9nEOmxWFOAmpRWlOhP94H07sl0
D+/q0gFgxxSUmL0BrwHG+p7x4uRc1saNgRz7MKxdpfHvOcqT1oUZ0kDcyvbYLuxK
nq8NlTCUJKPzK8MMM9bplmZosZ2Tgt8GxnmIYGoFD2/j0Kj08TEElcjkkTRwNSOj
wDq/onL9G7rRTtye+Dhr7MqoskUygrqtI+VX/+BoSe5yIdXeUqmJmckYbHggChrS
4K4EjEMjBXVqayCo0SNP9U5mD15vGiVo3acKtVtdfTJqlxiiA4CMlntrECEx0fW+
UNw/V7SrMGdyxtN/FU4yHyGxQdONRiq2uclLBapB7jtOLHj2UxM=
=zz8n
-END PGP SIGNATURE-

Accepted sdb 1.2-1.1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 16 Jan 2017 01:14:02 +0200
Source: sdb
Binary: sdb
Architecture: source
Version: 1.2-1.1
Distribution: unstable
Urgency: medium
Maintainer: Jo Shields <direct...@apebox.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 sdb- a command line client for Mono's soft debugger
Closes: 849069
Changes:
 sdb (1.2-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Switch to libreadline7. (Closes: #849069)
Checksums-Sha1:
 b84cbfe7f2e51877da2faacd6100474d8485d4fe 1986 sdb_1.2-1.1.dsc
 00472c0ec4fab7b2aaf2077025383a51a5324e8c 2856 sdb_1.2-1.1.debian.tar.xz
Checksums-Sha256:
 59bccd8acd91e297c41237dc31b16f321546df00e466cf4c08d3186dca8c0659 1986 
sdb_1.2-1.1.dsc
 75517929295ed1d150655ba51429c2668c9d79532064eb10b1c54f04827e786f 2856 
sdb_1.2-1.1.debian.tar.xz
Files:
 4075a4e77bc81090a19faf808dc8678f 1986 cli-mono extra sdb_1.2-1.1.dsc
 352cab2df7eb42acffae410bd66caf56 2856 cli-mono extra sdb_1.2-1.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh8A6QACgkQiNJCh6LY
mLF1iBAAhkdT6tSNQYqdm8ADd6tkeVuT6ljeqrXm7Gi1fsTrULW/+cxU12TDI13J
NTHBE465std08SGmzuOk9nHDnz4+CxdS+CnCEk9UfINTlrRfzQW8ZiOyQ+OZiMu0
dRb+0UFntY8Qb+/iQwjWJR8zNNuxNkllaNelSlBjp7SC1kVed8Jmca5UylEHZ2J/
dg2G3l3nR7FGCzpWLoikkgqKBwCCkBzsnqTY4aL89tuhTyc2nJ/istYqKriprHc6
hz6x8XXVD5bUMYFfSvVBFXHYree6YGue22QnJR8ZfWkuUlRkc/vYMX0MiUVjQFKT
08h3S7kWPjQwNNXst3huky9CARGUCsdbOkQHaecsbrHV5thamQ13JDJ1FRbtElrO
WHz8NvgNm6PuGOkFy0E3GdT1R41KbxPNf3ULQ5XWosv8LftubRueLfLGI6el5TTz
IWwOyOyw1BTSZhAPlgeC6UTRYuwj8c2E7nbQfIRIJy/EohhPLoDuQrgc7uCwQJbV
UasKEu+j3GbDgorU4fETGNHMPuDiZ6Gh85/tsr0dfUJ9Fmd5iSEX+luPDAPgWjbK
PTZ/GE0kbdnOV/fqNsx4DeQZPnUtkjdmrBLnart4bdDmtqV0P7bHEWD4AhCAcirL
FGW2sQQQ+C1WiyX1T1YoejpGKrOoTTuh+8Q3Conlx6oSxvVZzQI=
=5Xuk
-END PGP SIGNATURE-

Accepted ocrad 0.25-2 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 17 Jan 2017 19:36:35 +0200
Source: ocrad
Binary: ocrad libocrad-dev
Architecture: source
Version: 0.25-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 libocrad-dev - optical character recognition library
 ocrad  - optical character recognition program
Changes:
 ocrad (0.25-2) unstable; urgency=medium
 .
   * QA upload.
   * Standards-Version: 3.9.8 (no changes)
Checksums-Sha1:
 e16e94bd28e74eb5110e8898c1d4a224f6764e60 1962 ocrad_0.25-2.dsc
 67b25d82e10ed1ee7727d88687556f17bb11aa94 7552 ocrad_0.25-2.debian.tar.xz
Checksums-Sha256:
 0dc141b90168a4c1332bf34d98c3f67dd301c56093edb0e79f2beb14bdfbf6cf 1962 
ocrad_0.25-2.dsc
 9086b4a8add7d585c1725fe71f1c14be0fd7ba869b227e11656a9680f96c7fe0 7552 
ocrad_0.25-2.debian.tar.xz
Files:
 cf43fa6bb9c1ab5b66ae24749b47033e 1962 graphics optional ocrad_0.25-2.dsc
 3ec2254f44f2e9afbf87cb3eaaa7d6ac 7552 graphics optional 
ocrad_0.25-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh+VuMACgkQiNJCh6LY
mLHQyw/9Gd5lbN1yKFrHQx8hs8mFC/fzBtBSeC5mdOt8lnOyYtB4tbhma90vW9Vp
b/eq7ib9VhumAvvOD1Km+jL1Gc8r+a0Um4bNtrOnjb4891sOHLNinMKRyLFzgH1c
8G4DwlPPmrBSLma2gbQwuacYFdofO9JKjAwt853jB6c2TBqGCHdASRZMMHupN2BX
BNlvCLliyXScBN0pceuilTThcDCR0k+0q8Uz3FAjSnMQkZAmJHwNwblv7AqBZV28
fnbPD54CRKgf0HKQ3BeoRnO2sXW1NYrTqhDTLjFsr1zf73gHHud8XXQ6OXMweAen
GLGxrYNfmX+/kWkzUlfn8NYO4HargHTx5quvP97hIJ56j/8/SaDfGdz1h+btzoAm
IyEVMASlXEI+dH5lR4X9+i/JOZpPILGryF/chG5opdFCez/arOgS15xlvGaY94n/
2FIrhUmYkK9hcFUg0hON2wn/L4MXfwi5Ytb4t1DFhiybvA2Y4ym4Jn2wAV6wjdkv
XSKAmv96/G8hj4lvCDF0JH584VpZ3/txTYaY0CoVeU4RWk8GbdggSTfB3dxPNEh8
vo0sJAxPsOGoM/xJFWnNQfYjQrpXXqDbbkVf1sSORpjqofnTDRdUFnndAM6Yfgg6
KRWShrGggmcW1xYOWLIQig8Ojv5ozRpDmA6qbolHpfzo8qc4LLQ=
=I8d8
-END PGP SIGNATURE-

no-strong-digests-in-dsc MBF

[Adrian Bunk]

Hi,

I want to do a MBF for all packages without a SHA256 checksum field 
in the .dsc [1] - only SHA1 as hash would not be good in stretch.

This is quite easy to fix in a package - all that is required is a 
sourceful upload (but a binNMU would not be sufficient).

The steps will be:
1. QA uploads for all orphaned packages in that list [2]
2. send RC bugs against the ~ 100 other packages
3. after 1 week, I will NMU still open RC bugs in packages that are 
   in stretch [3]

Despite ~ 100 new RC bugs, this should avoid any impact of this MBF
on the release schedule.

Any objections?

cu
Adrian

[1] https://lintian.debian.org/tags/no-strong-digests-in-dsc.html
[2] there are several that are orphaned but the maintainer field
has not yet been updated to the Debian QA Group
[3] many of the maintainers of these packages will also be in my next 
list of potentially MIA people to the MIA team



A Lee 
   ko.tex-extra-hlfont

Adam Cécile (Le_Vert) 
   stymulator

Adam Sloboda 
   gkrellm-thinkbat
   gkrellm-xkb

Alan Bain 
   ratfor

Alberto Gonzalez Iniesta 
   netkit-bootparamd

Andrea Tacchetti 
   juke

Anibal Monsalve Salazar 
   bootpc

Antoine Jacquet 
   fapg

Ari Pollak 
   gav
   trackballs-music

Arjan Oosting 
   pidgin-extprefs

Armin Berres 
   apparix

Arnaud Cornet 
   gurgitate-mail

Arne Goetje 
   libsnmp-multi-perl

Arthur Loiret 
   gcc-m68hc1x

Asheesh Laroia 
   cue2toc

Atsushi KAMOSHIDA 
   libjcode-pm-perl

C. Chad Wallace 
   liblingua-en-namecase-perl

Carl Fürstenberg 
   tapecalc

Carlos Laviola 
   bplay

Chris Lawrence 
   rnc-mode

Christian Marillat 
   sawfish-merlin-ugliness

CJ van den Berg 
   paman

César Gómez Martín 
   libtut

Daniel Ruoso 
   cvs-autoreleasedeb

Dave Holland 
   biff

Debian Common Lisp Team 
   cl-postoffice
   cl-rsm-mod
   cl-salza

Debian Games Team 
   scottfree

Debian GNOME Maintainers 
   gnome-mime-data

Debian Hebrew Packaging Team 
   culmus-fancy

Debian Multimedia Team 
   stops

Debian Perl Group 
   libmath-numbercruncher-perl
   libnet-imap-simple-ssl-perl
   libnetxap-perl
   libset-nestedgroups-perl
   libsyntax-highlight-perl-improved-perl
   libtest-www-mechanize-cgiapp-perl

Debian TeX maintainers 
   context-nonfree

Debian VoIP team 
   asterisk-prompt-fr-armelle
   asterisk-prompt-fr-proformatique

Debian XML/SGML Group 
   libxmltok

Debichem Team 
   garlic-doc

Debootloaders miBoot Maintainers Team 

   rsrce

Deepak Tripathi 
   debian-builder
   libperlmenu-perl

Devin Carraway 
   gaim-librvp

Dmitry E. Oboukhov 
   iat

Dominic Hargreaves 
   libtemplate-plugin-gd-perl
   libtemplate-plugin-xml-perl

Drew Parsons 
   meschach

Eduard Bloch 
   cpipe

Eugene Krivdyuk 
   liblogfile-rotate-perl

Faidon Liambotis 
   hostap-utils

Felipe Augusto van de Wiel (faw) 
   translate-docformat

FingerForce Team 
   aes2501-wy

Florian Hinzmann 
   dlint

Frederic Peters 
   tcs

Free Ekanayaka 
   gnome-icon-theme-yasis

Gerrit Pape 
   freecdb
   integrit
   socklog

Guido Guenther 
   dvhtool

Henrique de Moraes Holschuh 
   freepats

Joachim Breitner 
   customdeb
   metainit

Joe Baldwin 
   eancheck

Joe Nahmias 
   efp

John Wright 
   bibcursed

Jose Parrella 
   onesixtyone

Jose Parrella 
   libbiblio-isis-perl

Josselin Mouette 
   stardict-xmlittre

Juan Cespedes 
   genromfs

Juan Esteban Monsalve Tobon 
   libjama
   libtnt

Kapil Hari Paranjape 
   par

Kari Pahula 
   crossfire-maps-small
   webserver-package

Kevin Coyner 

Accepted integrit 4.1-1.1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 18 Jan 2017 16:50:19 +0200
Source: integrit
Binary: integrit
Architecture: source
Version: 4.1-1.1
Distribution: unstable
Urgency: medium
Maintainer: Gerrit Pape <p...@smarden.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 integrit   - A file integrity verification program
Closes: 776973 846891 847577
Changes:
 integrit (4.1-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Apply change from Andreas Henriksson to add a Built-Using field.
 (Closes: #847577)
   * Apply changes from Chris Lamb and Valerie R Young to make the
 build reproducible. (Closes: #776973, #846891)
Checksums-Sha1:
 e938a2c7b915c5aa81e6e2dcb4057449776bcb61 1704 integrit_4.1-1.1.dsc
 0e1c559e5447b26e3f33697794480007dd1095ee 9875 integrit_4.1-1.1.diff.gz
Checksums-Sha256:
 e19dae338df5f9185e9e0d922a5ca2669f9e6fc44dfa213a12fd24400f7ee41d 1704 
integrit_4.1-1.1.dsc
 84751076a8c967367cc69212f458f867c4f84d6550356ea146334a6e5e2c54de 9875 
integrit_4.1-1.1.diff.gz
Files:
 e26441418b3bd66cec0acaf0bb78d209 1704 admin optional integrit_4.1-1.1.dsc
 8e156807b45ba4feb15f877744566cb4 9875 admin optional integrit_4.1-1.1.diff.gz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh/mXsACgkQiNJCh6LY
mLHOJxAAoe7zFNuk9Qn4HzPTJm+yTN5bYVEntK0AJmR+iUw7NaVwT/6wFZOCdloy
AJw82oy4TvhAczrAS9maZwQX97vrJGt5aV0JzL3ICbIsx6wkxjh3VBMOHB75TTnZ
Iby9GJ6IUIdHYFo7sgCsA6118dLzgapHo1/KK7XiMW1eEExTWXgDp/TGkZFzjiPV
PFoabPnxYh7jgQ0ikWOCpFaQnedcwYYcTxYaL6P9RgtEfDHrX80OyEQL4eEuF1eQ
jaWLcQS1sSQalaIf/KlBik5H2LHu20wtar5H1rT/v4L9js+g0EUrJrjlGFQCh+UI
yCQr3zEbJqmPFEOlP2bpoNIdyeZck9SWZfeKZ3kdYvtvP9c5dxbRjSvYk0CrW5k2
D7b+qveLfO5gmD9lujKvbma8FbcyLdGrbOd6BrGgSuAcoUmfF2Vuq8K/xXf2JEfa
+1Gg4GF7CPf3e3kHBO2PY2NjR5gNvA/JdTKDOfKPltQNAyFE3Ne5jJmn7IGWBosU
iEgT4lXbLT7WqMf/eUfZwj6Oqc49em0irE+PUpP83FWGKvuoVHaodPF1z+I6JkRT
iAA0ERdyIEECJPv9N+QDi9aZHrkziTt3lBKEwmlyBg6ZmhabwyGUiIqXng5WfQmp
+dcE1se8XUJGc1wN6HUwW0ckpB4QL0O7TfVO5E49IYkW7DZ8SgU=
=JOaE
-END PGP SIGNATURE-

Accepted openhpi 3.6.1-2.1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 18 Jan 2017 21:45:48 +0200
Source: openhpi
Binary: libopenhpi3 libopenhpi-dev openhpid openhpi-clients 
openhpi-plugin-ilo2-ribcl openhpi-plugin-ipmi openhpi-plugin-ipmidirect 
openhpi-plugin-oa-soap openhpi-plugin-slave openhpi-plugin-test-agent 
openhpi-plugin-snmp-bc openhpi-plugin-sysfs openhpi-plugin-watchdog 
openhpi-plugin-simulator openhpi-plugin-dynamic-simulator openhpi 
libopenhpi3-dbgsym openhpid-dbgsym openhpi-clients-dbgsym 
openhpi-plugin-ilo2-ribcl-dbgsym openhpi-plugin-ipmi-dbgsym 
openhpi-plugin-ipmidirect-dbgsym openhpi-plugin-oa-soap-dbgsym 
openhpi-plugin-slave-dbgsym openhpi-plugin-test-agent-dbgsym 
openhpi-plugin-snmp-bc-dbgsym openhpi-plugin-sysfs-dbgsym 
openhpi-plugin-watchdog-dbgsym openhpi-plugin-simulator-dbgsym 
openhpi-plugin-dynamic-simulator-dbgsym
Architecture: source
Version: 3.6.1-2.1
Distribution: unstable
Urgency: medium
Maintainer: Bryan Sutula <bryan.sut...@hpe.com>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 libopenhpi-dev - OpenHPI libraries (development files)
 libopenhpi3 - OpenHPI libraries (runtime and support files)
 libopenhpi3-dbgsym - Debug symbols for libopenhpi3 library
 openhpi- SAF's HPI: Abstracted interface for managing computer hardware
 openhpi-clients - OpenHPI example client programs
 openhpi-clients-dbgsym - Debug symbols for OpenHPI example client programs
 openhpi-plugin-dynamic-simulator - OpenHPI plugin module for a dynamic 
simulator
 openhpi-plugin-dynamic-simulator-dbgsym - Debug symbols for 
openhpi-plugin-dynamic-simulator plugin module
 openhpi-plugin-ilo2-ribcl - OpenHPI plugin module for HP's ProLiant rackmount 
servers
 openhpi-plugin-ilo2-ribcl-dbgsym - Debug symbols for openhpi-plugin-ilo2-ribcl 
plugin module
 openhpi-plugin-ipmi - OpenHPI plugin module for OpenIPMI
 openhpi-plugin-ipmi-dbgsym - Debug symbols for openhpi-plugin-ipmi plugin 
module
 openhpi-plugin-ipmidirect - OpenHPI plugin module for direct IPMI over LAN 
(RMCP) or SMI
 openhpi-plugin-ipmidirect-dbgsym - Debug symbols for openhpi-plugin-ipmidirect 
plugin module
 openhpi-plugin-oa-soap - OpenHPI plugin module for HP's BladeSystem c-Class
 openhpi-plugin-oa-soap-dbgsym - Debug symbols for openhpi-plugin-oa-soap 
plugin module
 openhpi-plugin-simulator - OpenHPI plugin module for a simulator that works 
without hardware
 openhpi-plugin-simulator-dbgsym - Debug symbols for openhpi-plugin-simulator 
plugin module
 openhpi-plugin-slave - OpenHPI plugin module for slave plugin
 openhpi-plugin-slave-dbgsym - Debug symbols for openhpi-plugin-slave plugin 
module
 openhpi-plugin-snmp-bc - OpenHPI plugin module for IBM's BladeCenter or RSA 
over SNMP
 openhpi-plugin-snmp-bc-dbgsym - Debug symbols for openhpi-plugin-snmp-bc 
plugin module
 openhpi-plugin-sysfs - OpenHPI plugin module for the sysfs filesystem
 openhpi-plugin-sysfs-dbgsym - Debug symbols for openhpi-plugin-sysfs plugin 
module
 openhpi-plugin-test-agent - OpenHPI plugin module for test agent plugin
 openhpi-plugin-test-agent-dbgsym - Debug symbols for openhpi-plugin-test-agent 
plugin module
 openhpi-plugin-watchdog - OpenHPI plugin module for the Linux watchdog 
interface
 openhpi-plugin-watchdog-dbgsym - Debug symbols for openhpi-plugin-watchdog 
plugin module
 openhpid   - OpenHPI daemon, supports gathering of manageability information
 openhpid-dbgsym - Debug symbols package for OpenHPI daemon
Closes: 828468
Changes:
 openhpi (3.6.1-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix FTBFS by using OpenSSL 1.0.2. (Closes: #828468)
Checksums-Sha1:
 fb524a54929a7acfa2cdf91c2a6b03751124ba1c 4359 openhpi_3.6.1-2.1.dsc
 39a15134be13481d0ef6f8500b07a33146338cb5 14784 openhpi_3.6.1-2.1.debian.tar.xz
Checksums-Sha256:
 ab4250bed937996c70d667e5fcc3bc74ab116d7399cb431c61bfddfd2709b8e3 4359 
openhpi_3.6.1-2.1.dsc
 5ef0ea706fce4a56ab024bf381758baf24a06b155cf9e9170b1dd5235604dd94 14784 
openhpi_3.6.1-2.1.debian.tar.xz
Files:
 1f91f71b7a2ac0b82ee3ba8aa918d664 4359 admin optional openhpi_3.6.1-2.1.dsc
 246662f2266bbfe324a6115d655d3ca7 14784 admin optional 
openhpi_3.6.1-2.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh/0LAACgkQiNJCh6LY
mLGTkA/8DDOyzbB2VONAfUhM3ZBw0i8uyf+WrNbJJMG52QP0H7ziijnl4K6ES9so
7uPb5w4YlHg8LBKpaaNt6J8M/KXDmuMuE808peLT4GH/d2yeDg4RNhFSJaBu82dx
k5YvQGe5x6SKqk62WS1IMh9Nvo/tmwiMEjXwHn+a+Dp0TLkXy/hYdcIAr+cuixfF
/e59yFa/BeMXIsp1/GJXfqJHjEOTykfjDM+mwr/7wAjZFvQ/QdYxEmoOeMPjdpi9
NKKaFHGc5lWoMBW9Zp+LKL6m9Pnd6zDgxc4zvCoYk6bMhRHWgySUnBMCtjtIdoOq
po9GkXnqc0uuyWtT0DqW6bnIondnmjtEyhrxWso+GMJxpzpavPVJYMQTlzi8w5T2
Y/llvOHb+b97ShK3CobGn39sjl6kPOiV7+Oc+VjvakrTsPTlAnYh4YvpOAqv3aoD
nSAc5HyBYD84fkAWSNXrkBdO46yWUoJjqhbePSPYFVgBXON3BWGksytzqYGGNjSS
Y4GChxnyiVyVwQq/9VKw/6EvN8bk1bnmHVzNaBtuX6Totvl+9gyP7g3LZw97P6Nf
st4dImL27p1uQdnPymh/fXGs4GEjkO/VUb/q3TRpBEjZvOSqHqyRpowPPhN6+RvK
VxIqTv58q9TanI+r9WYHTavqiiGP8vIFHei2mrkE63J6u3pjiXg=
=yXkY
-END PGP SIGNATURE-

Accepted vmtk 1.3+dfsg-2.1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 18 Jan 2017 23:36:18 +0200
Source: vmtk
Binary: libvmtk1.3 python-vmtk libvmtk-dev vmtk
Architecture: source
Version: 1.3+dfsg-2.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Team 
<debian-science-maintain...@lists.alioth.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 libvmtk-dev - shared links and header files for vmtk
 libvmtk1.3 - runtime libraries for vmtk
 python-vmtk - Python interface for vmtk
 vmtk   - the Vascular Modeling Toolkit
Closes: 850026
Changes:
 vmtk (1.3+dfsg-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix FTBFS by using OpenSSL 1.0.2. (Closes: #850026)
Checksums-Sha1:
 b1ef52c662c1fe1107cae9cdc6742336e220e537 2417 vmtk_1.3+dfsg-2.1.dsc
 ace7d8bb899a412b2a05c86ab5185b27b02843b5 15372 vmtk_1.3+dfsg-2.1.debian.tar.xz
Checksums-Sha256:
 7f6d4239c325d613af43810ad392d2eb7639bc8df2a96a0b90ba15f3801a7dc6 2417 
vmtk_1.3+dfsg-2.1.dsc
 61065848f6b92e5650e25cf1ba728fbfad8c3bd1b7953f53096250ecdafbd782 15372 
vmtk_1.3+dfsg-2.1.debian.tar.xz
Files:
 b1fdb960923be08a4252e932f941ee47 2417 non-free/science optional 
vmtk_1.3+dfsg-2.1.dsc
 963e640d4d95442cd78282aaacfb5373 15372 non-free/science optional 
vmtk_1.3+dfsg-2.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh/4nwACgkQiNJCh6LY
mLH2oA//dhUT7zgRteID9dajOwt8sN3xvLcXmOsOZkm1AAZ2AjVBp1SLUe+VDrXF
LrcR1T1RlltTecsGXS9FZuDqHjeTHep/0YuiM82hPawDa40phZl7x9E9OxOCaKLg
MuaoxYeol3eu6wvlwnv9vILqdpWvQzGB5dyxNblXjm1EwNcvN86WmcQE0BhKagEP
ZSlap11eAFXbKMKqIbAWemDwTRoeEtblNMAi4q/WQ/eSYDwfk0gb0OoSfIG5lo5k
TrURwWNG2M1NVDQltwc1ECWI9mlZR+SIShvUQHip1LhGWJyHYQdMoJvw019Rh8BO
GohLrTlFoJ1aQplipfWwV8BVZwipRzWaD+3q3VOXWdGw7ZvpK8ZolGbkyLhh/+S2
dBEf7f/4wyzZl9pwtba8Smtmc+yc01YkN1a08CuWp4yV+incxqgdBQowIJ6b2ukA
vYzHVcltsIvkLx3Px7hZywoW2Y9sbTL+1v7z8m4BJlob5XqKfOzB0SMEJvGd4SqX
lbMTlMWQ0BzuQwPYrfAX0H+ueygl8yMAZBKZYIlqj7z+3FK7WvRDqpcVnizIKz2A
cjASPIVhQUvnqmyJwMfHHq6bcr92zjO41StvMIEPHNWQJsieJMFlgHcgMC8/IZkx
g/Q1F77wjYZKYR6+mY8gtJSUL/CKFnMwVJSwXv107Saxihe/2bA=
=/vbM
-END PGP SIGNATURE-

Accepted emacspeak-ss 1.12.1-6 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 19 Jan 2017 15:43:43 +0200
Source: emacspeak-ss
Binary: emacspeak-ss
Architecture: source
Version: 1.12.1-6
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 emacspeak-ss - Emacspeak speech servers for several synthesizers
Closes: 844671
Changes:
 emacspeak-ss (1.12.1-6) unstable; urgency=medium
 .
   * QA upload.
   * Add Brazilian Portuguese debconf template translation
 from Adriano Rafael Gomes. (Closes: #844671)
Checksums-Sha1:
 a38e3a08a54f9e4e40fb0374001bda5e9f1e763a 1904 emacspeak-ss_1.12.1-6.dsc
 4c34ccf39ed4da4c617423da6b69968b774c9b30 26176 
emacspeak-ss_1.12.1-6.debian.tar.xz
Checksums-Sha256:
 e2ce152a2018714f50d66062a2b71130d12de3e07f8741d8e7438d6c8c58e6fb 1904 
emacspeak-ss_1.12.1-6.dsc
 12682cb8b8db3f706e06268e2c70b612e138d5146ca83f22b95a8b82542ccd48 26176 
emacspeak-ss_1.12.1-6.debian.tar.xz
Files:
 0d967d64662083550c72b87f21114dea 1904 editors extra emacspeak-ss_1.12.1-6.dsc
 db02effd457e889e9ab6180ad893fed9 26176 editors extra 
emacspeak-ss_1.12.1-6.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliA/7QACgkQiNJCh6LY
mLF4chAAoL7dBlpqf4HdTJjTZthfZXXKMRVnTnu/vIsh+8KiF1FHomEI5blA5C0K
5VXcQliegYfYq30diD7M3pFQ4VGrA8NFXPpa/M0mn2bQYxbJJRIlEqtEq3JauqxW
eSs5f+3ffy85z78ykZuAFO+znLrrGP8RfTiJ7xyoweg/ejbhdW1V6iV2ordwPq5j
juBo2nPQ9tIfULhm8RxIvXZ/6Tge7FogUgWn5wrC6PmJhCldUf+nVIvWOzsUN8Ke
07cbS49u2zdrhUIv4oNA7AvC57I/dqJvK4vVFQf2p+RShwEnFX++bm/hS2fbkZRI
btFdvrZWweu/qMNTnbcPd/IAS7XZchY3LEYPYwTgZV1JV8+ByK2DnDuVIw0kK0Vi
dTegi/80S25DaZ/ioErb4TGq06nh1jO8T3FvL3wxnoDUriiCRr6k8YBxDdDDMuNU
3xRZ0X7qg7JTwGYt5HfxFbuZdwVMnmXvfNW6SgeaomxsRFvfoo1TG7sD5TqLnqSw
PpO3uy3qnf6VLnMYZ2IcKobguQk9GlPLMx0x4EvCamXvXLo95qj2jC1n59E1ak7A
VQydIWL8a3b0fIB5+hi6ceHjHBTd8IsJB1KhZxYNW/XqFoYHLz1rEeCwnTB1JdQF
HN/nXqD1mqKPsAIbNMPJM1fkDkz9PZiUNGXg76BSYeRnm3xSIQU=
=oV+s
-END PGP SIGNATURE-

Accepted irda-utils 0.9.18-15 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 20 Jan 2017 17:42:40 +0200
Source: irda-utils
Binary: irda-utils
Architecture: source
Version: 0.9.18-15
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 irda-utils - IrDA management and handling utilities
Closes: 816944
Changes:
 irda-utils (0.9.18-15) unstable; urgency=medium
 .
   * QA upload.
   * Add Brazilian Portuguese debconf templates translation
 from Adriano Rafael Gomes. (Closes: #816944)
   * Drop obsolete NEWS.Debian
   * Fix spelling error in README.Debian
Checksums-Sha1:
 82d94b2b38101fa78478f38003649e27d77208e0 1767 irda-utils_0.9.18-15.dsc
 ecc62cc94fce5fe591e76bb1c57a83961697183b 33664 
irda-utils_0.9.18-15.debian.tar.xz
Checksums-Sha256:
 b6c43395aa69fa7770a1e3c3c27edbc04fcd208484c44696b767eee285390740 1767 
irda-utils_0.9.18-15.dsc
 67ecf919d8e5706197bf6caab3154e1ab5c1da5cff825e915f05df5c917ffc2a 33664 
irda-utils_0.9.18-15.debian.tar.xz
Files:
 b73f31bd5b496ee358a212c7f36b796f 1767 utils optional irda-utils_0.9.18-15.dsc
 9ce107888aedbd38939224c98f3da0cb 33664 utils optional 
irda-utils_0.9.18-15.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliCMZ4ACgkQiNJCh6LY
mLFC3RAApfaZ833A8udJZEfOWe1cwDN4Por12uhpLoLEWcCHLv3/MFNxJYlYGjFe
dT5ATZmD1k/3gje7tC2S5JfGs+vQ3ihViR7W6IiFH8RqDAaMZmA2r6Uz4w3xdYyz
Zg34H6cpbvzLiTl1yVLPLCLSrnxqWswowYlI9KtOaNqcyc+dxkdp1fHHa4Q5XUP4
//Ei0ysdXSBbD164QTTeXsQ337aBpfMhje3nveN4Vr99XjESiNHmfmcj+TKM+pvc
smvIyQ7okN3AZskMhJ8Zl4bJQ9fCX2IV1atJlp5hq3UGgruwQ6o/WuhaL+NifdzJ
56wlSphIQajQiknxEN6IJUxtzXvgZy7jX1JClFR1TmEiEWmlhE2nfVKoqNoED4Og
EnyFas1lSZeLnoLXXG1H0klnrs1ADQCIB/W6v5JdXTV2WTbK6nhPk7vBAzK/wO7J
m3sHmGB3fymaJUJCvSs2Z62XNH3V2oe6A1Xmwz20anJP0PK3NRK/8iQHWNBAcsG2
NkdfcifCTgERMISmMHfBHZ5UHcrWq2abvTkUUdAa0Jbflbq02uifjPUKblG7oX+k
8NjACknaq/Nag44HulTXjdop1u4nNBbiqdmq4G/b/m7hArvFhCyPG/JcXtmRAhnL
cE8KroyLyUpBww5lZVbhCcOX5fYvTjii0zBYqgYy5LihvU7PnVo=
=tF40
-END PGP SIGNATURE-

Accepted tpb 0.6.4-11 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 20 Jan 2017 18:02:20 +0200
Source: tpb
Binary: tpb
Architecture: source
Version: 0.6.4-11
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 tpb- program to use the IBM ThinkPad(tm) special keys
Closes: 770452
Changes:
 tpb (0.6.4-11) unstable; urgency=medium
 .
   * QA upload.
   * Add Brazilian Portuguese debconf templates translation
 from Adriano Rafael Gomes. (Closes: #770452)
Checksums-Sha1:
 4858f7c3e67abb77c66818fb171b2883e03e114d 1933 tpb_0.6.4-11.dsc
 d6e65e307014e974e57ddad9dc3d195a8664afb3 17352 tpb_0.6.4-11.debian.tar.xz
Checksums-Sha256:
 b184afc83d9ad75849e042098b0d2e246693f8843e1714154cfca40defb9d719 1933 
tpb_0.6.4-11.dsc
 808455888fcaa935f873d92ce7c87df772a787aaea13b64ab82c41661fb59f11 17352 
tpb_0.6.4-11.debian.tar.xz
Files:
 9bb7579e4815f00074a40a91d2a601ce 1933 utils extra tpb_0.6.4-11.dsc
 5a1b6b9975bee65ca7ac59a34b591a69 17352 utils extra tpb_0.6.4-11.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliCNQsACgkQiNJCh6LY
mLFIYBAAslIoMAlERP8GBCg7m8hVj1LCDPAVK+wSm5tbp9kquZHJ7ZMsbdK0BbRA
lWqlYaKbmAwHTzw3C0w6mJcQWSwVoHWKMSDJTk15eMI2MQvL5uEQ6P2HPmrTu0oW
cVsNZGZTRpNPJtC1i6YlaZcGEM68Z008dwXYlUFokUrpKvw2yFMleFZWhBUtjMdA
fJu4Egrlugj/JnN70eGovqDnPtkuRva0pG30ScZ+UpJ2owAbakDiX7EWa3bh+LpY
yA/Q4ol7JJw3Wld+vV9fGok6AGND2M07ivEw+UalAHvsVWTFlIlXeiNdaXho+9Kq
wOMW8QCoL+zVD+Hc+ri8KHJK7TGlV/H2JTOJTyIyS/Lg5OpaCblV85LdOSHL1kBM
ch0dEXSRO0nAP7gaymKDZ2lXEk9jR6G7TmYzBSQe4Rf27qUmF0mKhie9KjVn/6wS
XLhMhV2klzov36R/5YJ0WGp9SKvBk63Ee6v46NmWl5k3KdLqGl46r4g0V3Ci76mm
4b9T1bPaDAWSiEJHbT6+uJHRpMsFb9seYVQlO9IVFiO8c3iJgb8AcrXmevfZyzpx
DuHsAygxoGy0kQeLhmTzDRzm5R+crQgRDbIJbg3UlBVXzxTbSHneHRNQj2lDtkZg
bj6fX6JL4EfdJ+hoi9ClW0aUXR5HtPvf9QWfvYTC9aC3Yb4VeWo=
=sZUH
-END PGP SIGNATURE-

Accepted vbrfix 0.24+dfsg-1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 26 Feb 2017 13:07:11 +0200
Source: vbrfix
Binary: vbrfix
Architecture: source
Version: 0.24+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 vbrfix - corrects MP3 files that have incorrect VBR information
Closes: 856199
Changes:
 vbrfix (0.24+dfsg-1) unstable; urgency=medium
 .
   * QA upload.
   * Set maintainer to Debian QA Group. (see #646384)
   * Repackage the upstream tarball without the vbrfixc/vbrfixc binary.
   * Fix FTBFS on armhf. (Closes: #856199)
   * autoreconf for the FTBFS fix.
Checksums-Sha1:
 f96d8030260afa76eabe9f4fe9f77444b9b22e05 1832 vbrfix_0.24+dfsg-1.dsc
 dd5da1d4ef224eafb12c6204d4dee6801b7fc5d0 228896 vbrfix_0.24+dfsg.orig.tar.xz
 5f73d5a37184c94216d6683dfc9784456b76c41b 5804 vbrfix_0.24+dfsg-1.debian.tar.xz
 e762670b4b1e47576f758e067bd1d40c176da357 4644 
vbrfix_0.24+dfsg-1_amd64.buildinfo
Checksums-Sha256:
 de304f7580ef2f27e0558e3013ee36fbe38fbf134d64c2fe892a948aaead8810 1832 
vbrfix_0.24+dfsg-1.dsc
 11c24c246da232a5ad73c37fcfab89dedb820ddc76167395411df4a836ce3a29 228896 
vbrfix_0.24+dfsg.orig.tar.xz
 3f50f7ab50310b9cabdf6c8a43ee2753edb078f8531a453ae50dd49dd3d0dbc5 5804 
vbrfix_0.24+dfsg-1.debian.tar.xz
 1a4a3b96efd706e0f3bab57113ab81e333aa2ea88abc028cbf8d94ff87aedf44 4644 
vbrfix_0.24+dfsg-1_amd64.buildinfo
Files:
 b4f44218a248512e28c55f0eecc4e3c6 1832 sound optional vbrfix_0.24+dfsg-1.dsc
 27ee9a38a5dac9344b9256bf6d06ab4e 228896 sound optional 
vbrfix_0.24+dfsg.orig.tar.xz
 46c22b29ce5d593fb884757e10332b48 5804 sound optional 
vbrfix_0.24+dfsg-1.debian.tar.xz
 a38d53e12dd1364c8ce10429b1efa9ff 4644 sound optional 
vbrfix_0.24+dfsg-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliy1hQACgkQiNJCh6LY
mLHn3RAAmeZ6JnEpLTReRSNN3x3jk5soZEpDAfIgHMmjyFD4fKKT9bZLjXZ7YS4s
ubsxDKogVJa8LNA3+/7Ddij8axTLNoCPZsafPJSdINFqeUiaH7K7v72WBdcUzVcD
dh8/tQFYtAYUIdeSFoABOxe2ixT5Y4Bz8kH/pXGyNqczRaRjfeGfWpgDZMj+DJD1
Oq+qTP5u8UBGXUhFDfQM0myMmLGFS8JpueWzr2q0Q1WjX1tW9WstKr2Jh3yVzEnw
6fpA1iiYp1A4ABbCZ+V81w8oUwZ6GGXBZjQIYr3CYUuowWB2Hdg03UsFinXYi8sx
fgvg3VtqQtAdKLzYcWTUZvwCe+jJjRwqSKjV6NRpsMFa20CnhH8Y6x+RYOGYXTYK
GGn5z/p0aCBL+peE1CC+/sEXVc+HFLbTjHW40z6MgpoAtTONB/0s/See23OSCLL6
ihVLjZ5VqXRD9dj4ymMHUCkIsVKVSuDdXeMe8tTt7cyy8pNDoVrBedQBxpMz58LB
E+w3pmoFFmt0WamFJbZ0BoI/PEQWtYCisNbDDG3i5jIFdOUkWzRxaKRg8jV3ubPX
TXAnoOvKxN/5pkLB7Y91gylb8Bm8zCzNpfDdq4IlS6Gmw8kngSWuN9MefMm1ZK5u
F5QtjF8zJ1/i+q6CXMi2bQOif85Eos1B4QV1PsCgpCk+QWRc1SQ=
=aUQC
-END PGP SIGNATURE-

Accepted inotify-tools 3.14-2 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 28 Feb 2017 11:33:27 +0200
Source: inotify-tools
Binary: libinotifytools0 libinotifytools0-dev inotify-tools
Architecture: source
Version: 3.14-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 inotify-tools - command-line programs providing a simple interface to inotify
 libinotifytools0 - utility wrapper around inotify
 libinotifytools0-dev - Development library and header files for 
libinotifytools0
Closes: 727902 745204
Changes:
 inotify-tools (3.14-2) unstable; urgency=medium
 .
   * QA upload.
   * Set maintainer to Debian QA Group. (see #856293)
   * Set architecture to linux-any to not even try building on other
 architectures. (Closes: #745204)
   * Run dh-autoreconf to fix FTBFS on arm64. (Closes: #727902)
Checksums-Sha1:
 5a8d601aad5e98220a84314a6dc52015c33d30b3 2172 inotify-tools_3.14-2.dsc
 090f325f1781d3b7b2ff4e38c75ce0f8098003e8 6200 
inotify-tools_3.14-2.debian.tar.xz
 0a273fe31d26c1e4dba6eabacf2eaa09f2da1254 5673 
inotify-tools_3.14-2_amd64.buildinfo
Checksums-Sha256:
 f06ba4b1bffb116e71ef8c5eb61269b3bbb72d763b1bfe04c2e73cf68dcc8261 2172 
inotify-tools_3.14-2.dsc
 b2894c5731558c63bb419103d47991c8fed97c66900ab3d273c0d7e6328c57d3 6200 
inotify-tools_3.14-2.debian.tar.xz
 6221f7d4a3bded51270656744bfc5c3ee6741bf313128c3f64baf35c0d5d563c 5673 
inotify-tools_3.14-2_amd64.buildinfo
Files:
 73a60c36438894633c80c549cadd 2172 misc optional inotify-tools_3.14-2.dsc
 3fc1706868ae4326771e99e5194f5db6 6200 misc optional 
inotify-tools_3.14-2.debian.tar.xz
 f9bda7c84e3594cb94c3cba4e96355b4 5673 misc optional 
inotify-tools_3.14-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAli1SLsACgkQiNJCh6LY
mLGsWw/8CrOcRJhg2KiMMiQ5lO2UgiGM0/ojN/pMdG37WmzkQt+t8B2LiCSZrHAp
l42TI4q4Bm4R+4NgBX9YCpqpMnlf3VX8rMR7UYQHT/ZBr3ltpE/GM8ZHDaWUYBm2
yWZSr8hERXjV7PKJKCefNIUmSXuCRwXzfy9ApROIM/WTfUkDTsn91TujUwc8yEME
We8MB5gyzkWzpX1THjpAlgC67kjukKyeGVStJfUVDKhA25PR5ess2+pE7j4wj9sY
EimvOdd+3ww5m5ooBUeizy9v6qN/ttlCJM7kkE7+QM7srYG6rTPa44NpTOVTOxjB
DrA/mHy1xP3zkPZ15SuvCYTpWybIE/JRj22XHyJVgwpg87Y/6LhWBkny0EVZ+7uq
iYQXuXHJ9P5I72tbsZ/ZW6lhcGGc/JnwKnKrOoDlUIuSO64Zukq2EIDK555kPzhq
r/gjhzJWFlPck6+Cg9OCLeLHLpNPTgncx1tlRyU8sC0HVCI5xKTUR9NV/kbIg2+X
/wYCABKqFmVVhzuCgk2Z3KAPeRSrf2a8btgsB2oDNWpLNrCpPFhNLqdl65rFWuV2
fCBF3hZl3uEONKki55NyztgOp3HkgFoBOHYDNvtpF9KqeRZb+RgimQ1Cab3hkku0
8/67/XnOgLdDGiRX62ICindXEeLmTxw5JN8GT6gFxe27wVE/xwY=
=XpVL
-END PGP SIGNATURE-

Accepted libprelude 1.0.0-11.9 (source amd64) into unstable, unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 23 Feb 2017 12:50:44 +0200
Source: libprelude
Binary: libprelude-dev libprelude2 libpreludecpp0 libprelude-perl python-prelude
Architecture: source amd64
Version: 1.0.0-11.9
Distribution: unstable
Urgency: medium
Maintainer: Pierre Chifflier <pol...@debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 libprelude-dev - Security Information Management System [ Development files ]
 libprelude-perl - Security Information Management System [ Base library ]
 libprelude2 - Security Information Management System [ Base library ]
 libpreludecpp0 - Security Information Management System [ C++ library ]
 python-prelude - Security Information Management System [ Base library ]
Closes: 797161 844897
Changes:
 libprelude (1.0.0-11.9) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Backport upstream fix for FTBFS with recent SWIG.
 (Closes: #844897)
   * - Apply patch from Andreas Beckmann to factor out a
   libpreludecpp0 package.
 - Move HTML documentation from libprelude2 to libprelude-dev.
 (Closes: #797161)
   * Switch from -dbg to -dbgsym.
   * Remove generated bindings/lua/PreludeEasy.cxx
 when cleaning to allow building twice in a row.
   * Don't disable PIE.
Checksums-Sha1:
 6b2a3433af105c6eaedfa0969bbc329752ea690a 2112 libprelude_1.0.0-11.9.dsc
 f6d5976ac2a9d5c38e24a33a81d9334332a0fa12 15972 
libprelude_1.0.0-11.9.debian.tar.xz
 31744a333f0c23411f3606e44fcda26f58ff0f99 499782 
libprelude-dev_1.0.0-11.9_amd64.deb
 cbf21abbfadfe09ff10d6e62ae609e133f84ef64 1268436 
libprelude-perl-dbgsym_1.0.0-11.9_amd64.deb
 923ab88eb0a6ca289c559098a5f2ad676bd18155 605300 
libprelude-perl_1.0.0-11.9_amd64.deb
 f7f4540909e8c42655f241c5b8c561915d589c74 848656 
libprelude2-dbgsym_1.0.0-11.9_amd64.deb
 7acb0ed08253171ec0e1edbf7ce3cffef21700e9 569344 
libprelude2_1.0.0-11.9_amd64.deb
 c42cf9d98df1887647f51ca7a138ca2aa23103a4 8210 
libprelude_1.0.0-11.9_amd64.buildinfo
 1ff24b32b097cc0d317ed1d0668e6a99f3f07cff 258052 
libpreludecpp0-dbgsym_1.0.0-11.9_amd64.deb
 e652ba8234b07ab532b0f0b78b1c4b1aed8ef64d 336018 
libpreludecpp0_1.0.0-11.9_amd64.deb
 c593d997458c6d4456e5c221497eae141906d11c 967136 
python-prelude-dbgsym_1.0.0-11.9_amd64.deb
 cfb038eea96f47c94f90320f9c659eb5ac501633 514932 
python-prelude_1.0.0-11.9_amd64.deb
Checksums-Sha256:
 b6942ae8b31d87105ed21d958d964e6546cc772b00886cb5313cc53c08991438 2112 
libprelude_1.0.0-11.9.dsc
 13715432da170e31495a11bee06226225965b55a4278f86641154c8a20eb6835 15972 
libprelude_1.0.0-11.9.debian.tar.xz
 72e9389b2bd922231b81a753e28b8205f50024bbdcc4ab193a17b0f2ae551687 499782 
libprelude-dev_1.0.0-11.9_amd64.deb
 c27a38d14b07013a59b341124fc063412cd94808b06ac99bf19ebd04fcf82179 1268436 
libprelude-perl-dbgsym_1.0.0-11.9_amd64.deb
 6334233ea74ceb6c884a64a3194722e6a12a1de0d38babbed3ecceb61b773425 605300 
libprelude-perl_1.0.0-11.9_amd64.deb
 f5ed5d24820616ef7f475a7e6c5c4a7527c55624d739eb6f5497240f871f86f8 848656 
libprelude2-dbgsym_1.0.0-11.9_amd64.deb
 24869482231d2d88ab360df4c866fe5d0f5dea96549c63db352fc4c64298e394 569344 
libprelude2_1.0.0-11.9_amd64.deb
 6e3941b31334c49c5c053f11e2684bcd0c606345292c18ff50650c208a83012f 8210 
libprelude_1.0.0-11.9_amd64.buildinfo
 7a4c38e173ac4e23855ad7c4be2f6d5393e1144802a1d25811f3493047aad3f4 258052 
libpreludecpp0-dbgsym_1.0.0-11.9_amd64.deb
 ac899e81a738e29baf2b2b5902f6811d4d55442bc3f68312e4574b78fb5bdc1e 336018 
libpreludecpp0_1.0.0-11.9_amd64.deb
 32ae9cdbcf3915f8d4918ff71b4b87dd7bde68734a68cebe69be39be63421d6c 967136 
python-prelude-dbgsym_1.0.0-11.9_amd64.deb
 32f2e4eae79ddcbf2b8b3e60555b22cae70ef778c9fd3a3b7c1ba22fc6c27d76 514932 
python-prelude_1.0.0-11.9_amd64.deb
Files:
 a9e3db3c17a39a24d41433d0 2112 libs extra libprelude_1.0.0-11.9.dsc
 b09d3c6e018bb01bcf16c06f97e77cb5 15972 libs extra 
libprelude_1.0.0-11.9.debian.tar.xz
 62500acdf1352f1897677c72391ea045 499782 libdevel extra 
libprelude-dev_1.0.0-11.9_amd64.deb
 a80dcb15dcf0f7d9c754e8394eddeb23 1268436 debug extra 
libprelude-perl-dbgsym_1.0.0-11.9_amd64.deb
 b22c02cd055015e06bb0b4aed9a2985f 605300 perl extra 
libprelude-perl_1.0.0-11.9_amd64.deb
 7b2a170ef9b4c6a4c3ca7e20751df9a5 848656 debug extra 
libprelude2-dbgsym_1.0.0-11.9_amd64.deb
 f8aaacceaf831f121f1de94f6ba7b3dc 569344 libs extra 
libprelude2_1.0.0-11.9_amd64.deb
 5432205fc1089d1cf07df87899ac5cdc 8210 libs extra 
libprelude_1.0.0-11.9_amd64.buildinfo
 ef06d06345a0b80fe276b8472c56ccb1 258052 debug extra 
libpreludecpp0-dbgsym_1.0.0-11.9_amd64.deb
 e6c9449a17e95e9bbfbed07c18a5937a 336018 libs extra 
libpreludecpp0_1.0.0-11.9_amd64.deb
 26c10fa28b0edd40ed3b5b35a22fb3bd 967136 debug extra 
python-prelude-dbgsym_1.0.0-11.9_amd64.deb
 191add99b168e08f535104579db20324 514932 python extra 
python-prelude_1.0.0-11.9_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAliuxkEACgkQiNJCh6LY
mLGzohAAt0gAGH4X7IxJoWH9MhS/fS/foVc1vN4nG4mJy6tF0Sf0A7ogkZKafHhA
c/zbR

Re: Bug#835533: dasher: Please package Dasher 5.0 beta

[Adrian Bunk]

On Thu, Oct 06, 2016 at 02:46:44AM -0400, Scott Kitterman wrote:
>...
> As frustrating as occasional removal/reintroduction cycles are, they are rare 
> enough that despite the frustration when they occur it's really not worth the 
> effort it would take to avoid them completely.

This assumes that all users are developers who are following unstable.

The vast majority of Debian users won't use stretch until after it 
became stable.

And even if a user does use unstable or testing, there is no clear way 
for a non-developer do get a removed package back into unstable.

It is a problem for users when Debian is a revolving door
for packages that get ITP'ed into one stable and then disappear
without a good reason for removal in a later stable.

Example maintainer opinion: [1,2]
  If we orphan 2.x someone might fix the RC bug and get it back into
  testing.
  At this point I think releasing stretch with 2.x would be worse than
  releasing stretch without freeradius.

When a user who uses FreeRADIUS 2.2.5 in jessie upgrades to stretch 
after it became stable, is it worse for the user he gets FreeRADIUS 2.2.9
in stretch with 3 years (or 5 years with LTS) of security support,[3]
or if he gets no FreeRADIUS in stretch?

FreeRADIUS is high-profile enough that many Debian developers do care 
and new maintainers were quickly found. Many other packages are not.

> Scott K

cu
Adrian

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806617#42
[2] this is *not* meant against this soecific maintainer,
but it is impossible to quote a maintainer opinion from
a public BTS without revealing who it is
[3] the security team stating that it cannot support something
would be a good reason for not shipping in stretch, but that
seems unlikely for FreeRADIUS 2.2 and would be orthogonal
to my point regarding users

-- 

   "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: Bug#835533: dasher: Please package Dasher 5.0 beta

[Adrian Bunk]

(Cc-ing ftpmaster, debian-devel)

On Tue, Oct 04, 2016 at 07:05:09PM +0200, Emilio Pozuelo Monfort wrote:
> (Cc-ing debian-a11y)
> 
> Hi,

Hi Emilio,

> On 30/09/16 13:03, Andreas Henriksson wrote:
> > While the patch would solve the RC bug and get dasher back into
> > testing, I'm hesitant to assist in uploading it because the
> > question "Do we *want* to ship dasher in it current state?" is
> > not something your patch addresses. If we do get dasher back
> > into testing we'll likely have to also support it for the
> > lifetime of stretch. If we're struggling now to find people
> > willing to invest any time into dasher maintenance how will
> > we be able to make any guarantees about being able to support
> > it for the lifetime of stretch?
> > 
> > Until we have a somewhat enthusiastic maintainer it's probably
> > better to make dasher available "on the side" rather than in
> > the main distribution IMHO. Could you tell me your view on
> > this and what your motivation for posting the patch was to better
> > help me understand your situation?
> 
> dasher is a critical piece of software for some people who couldn't use their
> computer without it. Other than this FTBFS, I don't think it's in a bad state
> (unless I missed something). So I'd say we should fix this bug and ship it, or
> let the accessibility team (co-)maintain this (as they do with Orca) and give 
> us
> a hand with it, if they want to do that.

you are too late.

Andreas did not apply my trivial patch to fix the RC bug.[1]

Even though Andreas was worried about noone being available to maintain 
dasher,[2] he did not follow my suggestion to send a WNPP bug.[3]

Andreas succeeded in getting dasher removed from Debian,[4]
conveniently not mentioning that he could have fixed the
"has not been part of testing" by applying my trivial fix.

Andreas claiming "there's noone willing to commit to actually taking 
care of the package" in the removal request is also quite at odds with
him being completely silent on my suggestion to file a WNPP bug.

The ftp admins were fast enough to not give anyone a realistic chance to 
react to the removal request.

It is a problem for users when software that is in one stable release 
disappears in the next stable release, and I guess dasher can forever 
serve as a good example of critical software having been removed from 
unstable without a single good reason.

I am also personally unhappy that creating a patch for the RC bug
triggered removal from unstable instead of getting the fix applied.

> Cheers,
> Emilio

cu
Adrian

[1] https://bugs.debian.org/811640#24
[2] https://bugs.debian.org/835533#15
[3] https://bugs.debian.org/835533#25
[4] https://bugs.debian.org/839735

-- 

   "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: Bug#835533: dasher: Please package Dasher 5.0 beta

[Adrian Bunk]

On Thu, Oct 06, 2016 at 02:46:46PM -0400, Scott Kitterman wrote:
> 
> 
> On October 6, 2016 8:51:59 AM EDT, Adrian Bunk <b...@stusta.de> wrote:
> >On Thu, Oct 06, 2016 at 02:46:44AM -0400, Scott Kitterman wrote:
> >>...
> >> As frustrating as occasional removal/reintroduction cycles are, they
> >are rare enough that despite the frustration when they occur it's
> >really not worth the effort it would take to avoid them completely.
> >
> >This assumes that all users are developers who are following unstable.
> >
> >The vast majority of Debian users won't use stretch until after it 
> >became stable.
> >
> >And even if a user does use unstable or testing, there is no clear way 
> >for a non-developer do get a removed package back into unstable.
> >
> >It is a problem for users when Debian is a revolving door
> >for packages that get ITP'ed into one stable and then disappear
> >without a good reason for removal in a later stable.
> >
> >Example maintainer opinion: [1,2]
> >  If we orphan 2.x someone might fix the RC bug and get it back into
> >  testing.
> >  At this point I think releasing stretch with 2.x would be worse than
> >  releasing stretch without freeradius.
> >
> >When a user who uses FreeRADIUS 2.2.5 in jessie upgrades to stretch 
> >after it became stable, is it worse for the user he gets FreeRADIUS
> >2.2.9
> >in stretch with 3 years (or 5 years with LTS) of security support,[3]
> >or if he gets no FreeRADIUS in stretch?
> >
> >FreeRADIUS is high-profile enough that many Debian developers do care 
> >and new maintainers were quickly found. Many other packages are not.
> ...
> 
> This is all true, but in the end, Debian is a do-acracy.  While we should try 
> to do the best for our users, there's no way we can do everything for 
> everyone.  Users who want to increase the chances our next release scratches 
> whatever their personal itch is need to get involved with development.

I am not disputing that.

What I am saying is that "try to do the best for our users" includes 
"do not remove a package that is in stable without a good reason from
the next stable".

I am not saying that anyone has an obligation to fix RC issues in 
packages he does not maintain.
If there is an RC issue that doesn't get fixed, that is a good reason.

If Debian is not able to provide security support for a package,
that is a good reason.

"maintainer doesn't want his package in the next stable" or
"package is orphaned" alone are not good reasons, especially
when the package is in testing or only kept out of testing
by a maintainer not applying a fix.

"upstream is dead" is also less obvious that it looks at first sight.
For some packages it does not even matter that much (e.g. packages
supporting specific older hardware).
Code that works for 10 years is also not necessarily in a worse 
state than some random code a highschool student pushed to GitHub
that gets ITP'ed.

I do see the problem that Debian accumulates more and more packages,
but instead of being a revolving door for packages Debian would need
a policy for ITPs if that should change.

> Scott K

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: Debian does not have customers

[Adrian Bunk]

On Wed, Sep 21, 2016 at 10:56:10AM -0700, Russ Allbery wrote:
>...
> If no one is ever going to look at the bug again, just close it.  It feels
> more confrontational, but it's far more honest, and it doesn't create
> unrealistic expectations.
>...

"no one is ever going to look at the bug again" is actually impossible 
to prove for a project like Debian - some new Debian developer or even 
some new upstream developer might actually look at it tomorrow or in a 
few years.

And if you want to be honest, you have to start by telling people
that it might well be s/again/at all/ - even in many actively
maintained packages.

An example:

Even though Debian is a pretty marginal distribution on the desktop 
market, the Debian GNOME maintainers are sitting on 3800 open bugs.

For a normal bug reported against the old version of GNOME in unstable, 
chances are noone will ever look at it and the efforts of the reporter 
for creating the bug (which might have been hours) are wasted.

Note that this is not meant against the Debian GNOME maintainers.

It might be a lot of non-fun work to debug an issue, especially
if it is something like a random segfault.

The time people are able and willing to spend on Debian is limited,
and noone can be forced to work on anything.

There would not even be any realistic way to deliver a fix - updates to 
stable are handled very restrictively in Debian, and the second-best 
option of using backports is in practive impossible for software like 
GNOME where updating one package does (due to upstream dependencies) 
often require updating two dozen other packages as well.

So allowing users to report bugs against stable does often already
create unrealistic expectations like "someone will look at the bug"
or even "the bug will be fixed in stable".

Policies for updating stable can be changed, but I do not see where to 
suddenly find the huge amount of people with the skills, spare time and 
enthusiasm to properly debug all issues reported against the ancient 
software [1] the users of Debian stable are using.

cu
Adrian

[1] all software in stable is currently at least 2 years old,
for GNOME that is 4 major releases

-- 

   "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: Network access during build

[Adrian Bunk]

On Wed, Sep 07, 2016 at 09:26:37AM -0700, Russ Allbery wrote:
>...
> Full disclosure: several of my packages in the archive have similar tests.
> Those tests are part of the upstream test suite for the getaddrinfo and
> getnameinfo replacement functions for OSes that are too old to have them.
> They check the results of the replacement getaddrinfo function against the
> results of gethostbyname, and similarly with getnameinfo and
> gethostbyaddr, and tolerate environments with no DNS by skipping the
> tests.  I intentionally run those tests on all builds, even ones that have
> getaddrinfo and getnameinfo, because otherwise they would never run for me
> (I have no ancient hosts around) and I wouldn't know if the portability
> code bit rotted for some reason.
> 
> While I could put in some sort of elaborate workaround to avoid running
> those tests in a Debian package build environment, I see no point in doing
> so, don't really like the additional complexity, see no particular reason
> why Debian should require this, and would probably just close any bugs
> asking for that.  (That said, I'm open to being convinced by good
> arguments.)
>...

The only controversial cases seem to be tests, and these can run
optionally after the packages have been built.

Has anyone already thought of moving such tests into a separate optional 
step after the build is completed?

What I have in mind is the last lines of dpkg-buildpackage output being:

  This package contains optioal tests that might access the network.
  You can run them separately using
dpkg-buildpackage --run-network-tests


Commandline parameter, DEB_BUILD_ option or buildpackage.conf might also 
define that they run automatically after building the packages - this is
then your personal policy, and autobuilders are also able to run the 
tests if they want to.


This would allow automated checking that the normal build does not 
access the network as well as everyone with privacy concerns to not
opt-in to running them, without making it much harder to run them,


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: Debian does not have customers

[Adrian Bunk]

On Wed, Sep 21, 2016 at 12:50:41PM -0700, Russ Allbery wrote:
>...
> But still, despite all of those caveats, I do think there are a few things
> that are fairly clear-cut.  If the package has 3,000 open bugs, just close
> out the unactionable reports in some polite and constructive way.  At that
> point, there are so many actionable bugs ahead in the queue that those
> reports are adding clutter and making it harder for people to get a handle
> on the bugs that can be directly addressed by the package maintainers.
>...

How do you define "unactionable reports" and "constructive way"?

A submitter who reported an occasional segfault in wheezy GNOME
3 years ago might answer that he still sees it in jessie today.

What action to you expect from the package maintainers to directly 
address this bug after that answer?

The real problem is not the clutter among old bugs - when noone
is able, available and willing to fix them it makes exactly zero 
difference whether there are 30 or 3000 open bugs.

The real problem is that with current resources it is not even 
possible to handle all new bugs in some packages.

But what you describe is based on the (often unrealistic) assumption 
that the package maintainers are able to handle all new bugs and are 
additionallt even able to handle some of the old bugs.

If you want to be honest, you have to tell users that they shouldn't 
waste their time on reporting bugs against the ancient versions of
such packages in stable.
It is not likely that anyone will ever look at these bugs - they are
clutter from the moment they are being reported.

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: Planned NMU of w3-recs would use much archive disk space

[Adrian Bunk]

On Thu, Oct 27, 2016 at 08:41:12AM -0200, Henrique de Moraes Holschuh wrote:
>...
> That said, Thaddeus, if you do go ahead with the upload please check if
> you can minimize that size somehow, even just a 10% drop in size would
> already be worth the work it took for something big like this.
>...

I do disagree with that.

10% of 400 MB [1] would be 40 MB.

Every version of flightgear-data-base uses 2.5 GB in the archive,[1]
so what would be the point of a maintainer trying hard to make his 
package use 40 MB less space?

If archive size is a problem, then telling one person to spend work on 
trying to save 40 MB in one package is not an effective way to solve the 
problem.

If archive size is not a problem, then there's no point in one person 
spending work and reducing the usefulness of a package for saving 40 MB.

> For example, suppose it ships the recommendations in several rendered
> formats (PDF, PS, HTML/XHTML) and master hypertext (XML DOCBOOK,
> whatever).

And this would be an approach that has a negative effect for users while 
only providing small benefits.

Any good solution is about compression.

Binary package in the archive:
35069348 bytes

Package in the archive recompiled in unstable (with dpkg using xz):
23867182 bytes

xz compression level 9 instead of the default 6:
20930302 bytes

So just rebuilding the package in unstable reduces the size by 32%.
Which already reduces the factor 6 increase in the contents to
a factor 4 increase of the actual binary package.

And using compression level 9 instead of 6 gives an additional 12%.

If archive size is something you are worried about, then the one place 
that matters most is the default compression level in dpkg.

Similar for the source package:

Reducing the contents by 10% would bring a 10% size decrease.

Compressing the .orig.tar of the old version with "xz -9" instead
of gzip gives me a similar 42% size decrease.

Changing the build-orig target in debian/rules is a simple change 
without any impact for users, that gives much more than a 10%
reduction you were already considering worth additional work.

>   Henrique Holschuh

cu
Adrian

[1] binary and source package

-- 

   "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: Intended MBF: maintainer scripts not starting on #!

[Adrian Bunk]

On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote:
> Hi,

Hi Ralf,

> in the Colis project (which aims at analyzing maintainer scripts) we
> found 39 maintainer scripts in stable which do not start on #!. The
> list is attached. Policy 6.1 says about maintainer scripts:
> 
>   if they are scripts (which is recommended), they must start with the
>   usual #! convention.
> 
> Any objection against filing bugs against the offending packages? Since
> policy says "must", severity=serious would be in order, right?

why do you want to file the bugs against stable?

It is clear that any such bugs in unstable/testing should be fixed,
and they are easy to fix. IMHO severity serious is appropriate.

Are they causing any actual problems in jessie, or do the scripts  
happen to work fine despite this bug?

I am asking since it is not clear to me whether this issue is worth
stable updates for > 10 packages.

> -Ralf.

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: unattended-upgrades by default?

[Adrian Bunk]

On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
>...
>  * it will be a different experience compared to what people will get
>when installing Debian normally, using d-i / debootstrap. Most
>(all?) of our desktop environments already have some automatic
>notification of available updates, but (a) not everybody uses them;
>and (b) that's not so useful on a remote server installation where
>there's no desktop for the system to show a pop-up or similar.
>...

Should Debian also default to automatically reboot?

If the answer is "no", then nothing is a solution that does not also 
solve how to notify the user when a new security update of the kernel 
was automatically installed on his remote server.

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: libc recently more aggressive about pthread locks in stable ?

[Adrian Bunk]

On Sun, Nov 06, 2016 at 05:41:34PM -0200, Henrique de Moraes Holschuh wrote:
> On Sun, 06 Nov 2016, Ben Hutchings wrote:
> > It's worth noting that TSX is broken in 'Haswell' processors and is
> > supposed to be disabled via a microcode update.  I don't know whether
> > glibc avoids using it on these processors if the microcode update is
> > not applied.  (Linux doesn't appear to hide the feature flags.)
> 
> It does avoid it.  For glibc libpthreads, Debian has blacklisted Intel
> TSX use [in libpthreads] on all of Haswell and much of Broadwell.
> 
> But anything else *will* attempt to use it, people query cpuid directly
> for these things.  You need a hypervisor that filters cpuid().

All users who are using intel-microcode from non-free instead of running 
outdated microcode with known errata should be OK here?

Running outdated microcode is a bad idea, and noone is making 
Debian-specific workarounds for all the other CPU errata.

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: Road to Stretch: let's stop increasing major version number in critical libraries at this point

[Adrian Bunk]

On Sat, Nov 05, 2016 at 11:14:02AM +0100, Thomas Goirand wrote:
> Hi,

Hi Thomas,

>...
> Finally, with the above examples as illustration (and please, these
> aren't attacks in any way...), I guess what I'm trying to say here is:
> 
> While disruptive changes are necessary evils so we upgrade everything to
> the latest version, I would like the Stretch freeze to be as short as
> possible. Therefore, I'd prefer if my DD friends were holding on
> upgrading to (non bugfix only) new upstream releases of libraries.

as announced many months ago, the transiontion freeze is today (sic).

This is exactly to ensure that no new disruptive library changes can
be started after today.

> Cheers,
> 
> Thomas Goirand (zigo)
>...

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: Bug#842796: libc recently more aggressive about pthread locks in stable ?

[Adrian Bunk]

On Sun, Nov 06, 2016 at 08:04:39AM +0100, Petter Reinholdtsen wrote:
> [Henrique de Moraes Holschuh]
> > And what should we do about Debian stretch, then?
> 
> I believe a good start would be to add an assert() in a test version of
> glibc and then run all the autopkgtest scripts on the packages in the
> archive to see how widespread the problem is.  It will not cover all
> packages, but at least a significant portion of the archive.
> 
> I suspect we are too close to the Stretch freeze to try to modify all
> the packages affected by the problem,
>...

This discussion sounds as if all this would be future hardware,
but hardware with working (and not disabled) TSX is available
in nearly every computer shop in the world for over a year now 
(the first fixed Intel CPUs were released in 2014).

Please don't make it sound as if TSX would be a huge problem for 
stretch - it is not.

Every nontrivial piece of software has bugs.

If anyone wants to search specifically for this class of bugs that
is appreciated, just like searching for any other class of bugs is
appreciated.

Running stretch on hardware with TSX available and enabled
is working fine for many users for quite some time now.

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: What to do when a maintainer is blocking maintenance for stretch?

[Adrian Bunk]

On Wed, Nov 09, 2016 at 06:45:43PM +, Mattia Rizzolo wrote:
>...
> Also, a personal pledge to everybody who's reading this: please don't
> attach yourself to your packages like mussels on a rock.  If you realize
> (or somebody else is making you realize) that you're doing a bad job on
> a package *and* there is a willing adopter, just give it up; or talk to
> the prospective adopter about some kind of collaboration, or something
> on that line.

And when there is no willing adopter available, an O or RFA bug against 
wnpp is the way to find an adopter.

An orphaned package maintained by QA where everyone can just upload 
without delay is better maintained than a package with an inactive 
maintainer.

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: More 5 november in the release schedule

[Adrian Bunk]

On Wed, Nov 09, 2016 at 11:16:36AM +0800, Paul Wise wrote:
> On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:
> 
> > Right. We want auto-removals to be useful for the release process, so that 
> > we
> > don't end up with a thousand of RC bugs in testing when we freeze, most of 
> > them
> > on packages that nobody cares about, not even their maintainers.
> >
> > However, we don't want auto-removals to drop your package behind your back. 
> > If
> > that happens, that's a bad thing and you should let us know so we can fix
> > things. auto-removals should notify the maintainer in advance, and only act
> > after a reasonable period of time.
> >
> > The "packages can't re-enter testing during the freeze" is an incentive so 
> > that
> > maintainers don't wait to fix a package after a few months, and so that we 
> > don't
> > have to go and remove them manually. This way you know that something is 
> > going
> > to happen if you don't act, yet you should have a reasonable amount of time 
> > to
> > do something. Hopefully this helps have a short(er) freeze, which is good 
> > for
> > everyone.
> 
> FYI, it looks like at least buildd stuff (IIRC that uses dose3),
> rt.d.o, snapshot.d.o and the Debian VoIP services will need to remain
> on jessie until the affected packages reach stretch-backports

Is anyone tracking what packages are installed from backports on
Debian machines, and the CVEs in them?

Using backports without doing that would be irresponsible.

> as a
> result of the autoremovals stuff:
> 
> https://lists.debian.org/debian-services-admin/2016/10/msg2.html
>...

Package removals from unstable are also a potential problem, example:

==> vogler.debian.org <==
New packages removed from Debian 'testing' (the maintainer might need help):
 - freeradius - https://tracker.debian.org/pkg/freeradius
 - freeradius-common - https://tracker.debian.org/pkg/freeradius
 - freeradius-utils - https://tracker.debian.org/pkg/freeradius
 - libfreeradius2 - https://tracker.debian.org/pkg/freeradius

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806617#22
The maintainer wanted to remove this package from *unstable*.

FreeRADIUS is popular enough that people noticed before an RM: bug was 
filed, and new maintainers were found immediately.
Other packages are not that popular.

If any packages needed on these Debian machines have been removed from 
unstable, they are not on your list.

This is the reason why a ITP/RM revolving door is creating huge 
headaches for users.

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: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Adrian Bunk]

On Sun, Nov 06, 2016 at 12:03:03AM +0100, Philipp Kern wrote:
> On 2016-11-05 22:23, Adrian Bunk wrote:
> > The solution you are trying to sell is apt-transport-https as default.
> [...]
> > Your solution would be a lot of work with relatively little improvement.
> 
> Well, the client-side exists and works.
>...

Yes and no.

It works, but there is much work left if you want to make that the 
default.

David already mentioned in this discussion where apt-transport-https 
needs improvements.

I did already mention that the current footprint of adding 
apt-transport-https to the installer and small base filesystems
is currently pretty large.
As an example, the installer would require two different TLS libraries
if you just add apt-transport-https.

I would guess there are also other areas that have to be looked at
if that should become the default, like how certificate errors will
be handled in the installer.

> > BTW: The "possible low-effort improvement without tradeoff" is:
> > 
> > Is apt-transport-tor working reliably enough for general usage?
> > Are security updates available immediately through apt-transport-tor?
> > Is there a good reason why apt-transport-tor is not mentioned
> > at the frontpage of http://www.debian.org/security/ ?
> > 
> > My current impression (that might be wrong) is that the technical side
> > would be available, only documentation and perhaps PR (e.g. email to
> > debian-security-announce) are missing.
> 
> If we are limiting ourselves to mirrors run by DSA (which is what happens
> for the backends of the onion balancer), we could have the same with an
> HTTPS-based solution just fine. It'd likely raise the same scalability and
> operational questions as HTTPS. Your proposal here simply has different
> tradeoffs, not none as you claim.

Russ and me were discussing one specific tradeoff.

Let me repeat the relevant problem:
  By discouraging users from using mirrors for security.debian.org,
  Debian is presenting a nearly complete list of all computers in
  the world running Debian stable and their security update status
  and policies on a silver plate to the NSA.

Russ answered:
  It's a tradeoff with freshness of security updates.

With HTTP this tradeoff between "not giving information about Debian 
users on a silver plate to the NSA" and "providing security updates
as soon as possible" exists.

This tradeoff still exists with HTTPS.

Tor offers a solution for this specific problem that does not have
this specific tradeoff.

> Kind regards
> Philipp Kern

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: NRSS has been deprecated [#696302]

[Adrian Bunk]

On Mon, Nov 07, 2016 at 08:58:53PM +0100, Adam Borowski wrote:
> On Sun, Oct 30, 2016 at 06:55:33PM +, Clint Adams wrote:
> > On Sun, Oct 30, 2016 at 06:28:41AM +0100, Adam Borowski wrote:
> > > A maintainer would then file "ITR: dasher" and wait for responses before
> > > requesting RM.
> > 
> > Why wouldn't you orphan first?
> 
> It answers a different question.
> 
> Orphaning means "I don't have time to maintain this package anymore but
> believe it's worth keeping for now" (as otherwise it'd be a RM).
> 
> Intending to remove means "I don't think this package is useful at all, in
> its present state nor any state within a reasonable amount of work.  Does
> anyone disagree?".

What you are suggesting is a proper process for handling all source 
removals, instead of the current practice where the maintainer can
just submit an "RM: dasher" and a few hours later the package is gone?

> We got plenty of packages orphaned for a decade that are in a good
> condition.  

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: unattended-upgrades by default?

[Adrian Bunk]

On Tue, Nov 08, 2016 at 11:16:53AM +0800, Paul Wise wrote:
> On Tue, Nov 8, 2016 at 4:26 AM, Adam Borowski wrote:
> 
> > Forced reboot on upgrade is damage.  Let's learn from errors of others.
> 
> needrestart has a mechanism (needrestart-session) to hook into user
> sessions, perhaps that could be extended to request users reboot for
> security updates.

But that does not help here.

Steve was saying:
  that's not so useful on a remote server installation where
  there's no desktop for the system to show a pop-up or similar.
and
  We're *definitely* going to do it for cloud images

Any "solution" for the reboot problem that assumes that there is a user 
who regularly logs into the machine misses the problem.

> bye,
> pabs

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: Intended MBF: maintainer scripts not starting on #!

[Adrian Bunk]

On Fri, Nov 04, 2016 at 05:05:33PM -0400, Scott Kitterman wrote:
> 
> 
> On November 4, 2016 5:01:31 PM EDT, Adrian Bunk <b...@stusta.de> wrote:
> >On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote:
> >> Hi,
> >
> >Hi Ralf,
> >
> >> in the Colis project (which aims at analyzing maintainer scripts) we
> >> found 39 maintainer scripts in stable which do not start on #!. The
> >> list is attached. Policy 6.1 says about maintainer scripts:
> >> 
> >>   if they are scripts (which is recommended), they must start with
> >the
> >>   usual #! convention.
> >> 
> >> Any objection against filing bugs against the offending packages?
> >Since
> >> policy says "must", severity=serious would be in order, right?
> >
> >why do you want to file the bugs against stable?
> >
> >It is clear that any such bugs in unstable/testing should be fixed,
> >and they are easy to fix. IMHO severity serious is appropriate.
> >
> >Are they causing any actual problems in jessie, or do the scripts  
> >happen to work fine despite this bug?
> >
> >I am asking since it is not clear to me whether this issue is worth
> >stable updates for > 10 packages.
> 
> The validity of the bug and if it's worth fixing the bug are completely 
> separate questions.  If the bug applies to the stable version, then that's 
> how it should be filled.
> 
> We shouldn't try to hide the problem by artificially avoiding including 
> stable.

Is this an actual problem, or only a policy violation?

If I would report hundreds of "dpkg-buildpackage -A" FTBFS bugs against 
stable, would you consider that a valuable contribution to unhide problems?

And there are users who do use the provided tools to look at the RC bugs 
in jessie before doing wheezy -> jessie upgrades.
Scary-sounding "postinst is broken" bugs for issues without any 
practical relevance are actually harmful here.

> Scott K

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: Intended MBF: maintainer scripts not starting on #!

[Adrian Bunk]

On Fri, Nov 04, 2016 at 10:21:13PM +0100, Ralf Treinen wrote:
> On Fri, Nov 04, 2016 at 11:01:31PM +0200, Adrian Bunk wrote:
> > On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote:
> > > Hi,
> > 
> > Hi Ralf,
> > 
> > > in the Colis project (which aims at analyzing maintainer scripts) we
> > > found 39 maintainer scripts in stable which do not start on #!. The
> > > list is attached. Policy 6.1 says about maintainer scripts:
> > > 
> > >   if they are scripts (which is recommended), they must start with the
> > >   usual #! convention.
> > > 
> > > Any objection against filing bugs against the offending packages? Since
> > > policy says "must", severity=serious would be in order, right?
> > 
> > why do you want to file the bugs against stable?
> 
> We just happenend to do use stable as primary corpus for our analysis.
> I agree that doing the same analysis for sid would be more useful. The
> question, however, also applies to sid: does this, when it occurs in
> sid, merit a MBF with severity=serious?

My opinion on that was already in my email:
  It is clear that any such bugs in unstable/testing should be fixed,
  and they are easy to fix. IMHO severity serious is appropriate.

> -Ralf.

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: OpenSSL 1.1.0

[Adrian Bunk]

On Thu, Nov 03, 2016 at 10:49:30AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On jueves, 3 de noviembre de 2016 12:34:23 P. M. ART Tino Mettler wrote:
> > On Wed, Nov 02, 2016 at 14:02:52 -0300, Lisandro Damián Nicanor Pérez Meyer
> > wrote:
> > 
> > [...]
> > 
> > > Today we the Qt/KDE team were hit but this same thing in the middle of our
> > > transition: libpq-dev pulls in libssl-dev which makes Qt5 FTBFS.
> > 
> > Hi,
> > 
> > libqt staying at OpenSSL 1.0 means all binaries linking against libqt
> > need to stay at OpenSSL 1.0. Is this correct?
> 
> To the best of my knowledge yes, because Qt dllopens it and thus doesn't 
> resolves symbols versions.
> 
> Note that this is valid for both Qt4 and Qt5.

You could enforce that no Qt-using package uses the wrong OpenSSL by 
adding libssl1.0-dev dependencies to libqt4-dev and qtbase5-dev.

After that, trying to compile any Qt-using package with the wrong 
OpenSSL should fail due to unsatisfiable build dependencies.

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: unattended-upgrades by default?

[Adrian Bunk]

On Fri, Nov 04, 2016 at 10:27:00PM +, Holger Levsen wrote:
> On Fri, Nov 04, 2016 at 10:51:15PM +0200, Adrian Bunk wrote:
> > Should Debian also default to automatically reboot?
> > 
> > If the answer is "no", then nothing is a solution that does not also 
> > solve how to notify the user when a new security update of the kernel 
> > was automatically installed on his remote server.
>  
> while you are 100% right, this is also a clear case of "perfect is the
> enemy of very good" ;-)

Steve suggested a solution that would avoid the problem of sending 
notifications.

But his solution cannot work properly without notifications.

It is very valuable that Steve started the discussion,
but his suggested solution might not be the best one.

Is "unattended-upgrades by default" actually a "very good" solution?
What would be alternatives?
Does "default" mean that this would happen without asking the user?
What are other distributions (not only Ubuntu) doing?

The Debian Cloud sprint is the background of this discussion.
What tools do people use to setup Debian cloud servers?
What options do these give to query the user during installation?
What notification options are available for these servers?
What UIs will the "inexperienced users" use to setup and manage
their servers?

unattended-upgrades (or something similar) will likely be part of any 
good solution. But everyone should be aware that it is not a complete
solution, and it is worth to start by also searching for better solutions.

> cheers,
>   Holger

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: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Adrian Bunk]

On Tue, Oct 25, 2016 at 11:06:23AM -0700, Russ Allbery wrote:
> Adrian Bunk <b...@stusta.de> writes:
>...
> So, I'm not quite sure how to put this, since I don't know how much work
> you've done professionally in computer security, and I don't want to
> belittle that.  It's entirely possible that we have equivalent levels of
> experience and you just disagree with me, and I want to acknowledge that.

I have some knowledge here and there, but I am definitely not
a Security Expert.

When something is so well-known or obvious that even someone like me 
knows it or is able to figure it out, it has to be pretty well-known
or obvious.

>...
> In the specific case of retrieval of apt packages, use of HTTPS raises the
> bar for the attacker who wants to know what packages you probably have on
> your system from simply parsing the GET commands (information that would
> be captured in any dragnet surveillance database as a matter of course)
> for package names and versions to writing Debian-specific analysis code to
> make (fallible) guesses from traffic analysis.  This is a fairly
> substantial change in the required resources, and makes various things
> (such as retroactive data mining when this particular use case wasn't
> anticipated in advance) considerably harder.

I hope I am not too rude when I state the general problem I have with 
the way you are arguing:
You are not trying to solve a problem,
you are trying to sell a solution.

The solution you are trying to sell is apt-transport-https as default.

The problem would be something like "more security/privacy for users"
or "make it harder for the NSA".

Your solution would be a lot of work with relatively little improvement.

>...
> Yes, you're not going to get absolute security against the NSA with cheap
> wire encryption, but you *do* change the resource battle.

If something makes it more costly for the NSA, the US taxpayer will 
just give them another Billion every year - no party in US congress
would oppose that.

Debian resources are far more limited.

Noone is stopping you from doing the work on the client-side for making 
apt-transport-https the default (that noone seems to be working on) if 
this is important for you - it is your time.

But for any properly formulated problem and a fixed amount of resources,
I doubt the best solution available would include apt-transport-https.

>...
> > By discouraging users from using mirrors for security.debian.org, Debian
> > is presenting a nearly complete list of all computers in the world
> > running Debian stable and their security update status and policies on a
> > silver plate to the NSA.
> 
> It's a tradeoff with freshness of security updates.  Personally, I usually
> use an in-house mirror of security.debian.org for various reasons, and
> it's worth noting that our "discouraging" isn't particularly aggressive.

You are drawing your conclusions from just looking at some solutions.

When I go back one step and think of ways to improve the situation for 
users, I do also see a possible low-effort improvement that does not 
have the tradeoff you are talking about and that does not require a 
local mirror. And when even I am able to come up with something, there 
is likely more.

(Not limited to security) it is usually worth the effort to start by 
properly formulating the problem(s) that should be solved, instead of 
limiting yourself to some solutions.

cu
Adrian


BTW: The "possible low-effort improvement without tradeoff" is:

Is apt-transport-tor working reliably enough for general usage?
Are security updates available immediately through apt-transport-tor?
Is there a good reason why apt-transport-tor is not mentioned
at the frontpage of http://www.debian.org/security/ ?

My current impression (that might be wrong) is that the technical side
would be available, only documentation and perhaps PR (e.g. email to
debian-security-announce) are missing.

apt-transport-tor could also be taken into consideration in the 
unattended-upgrades discussion as a (perhaps non-default) option 
offered for receiving the security updates.

Oh, and when I look at http://www.debian.org/security/ I see
a link "For more information about security issues in Debian, please 
... and a manual called Securing Debian."

The manual says "Version: 3.17, built on Sun, 08 Apr 2012".

I know that writing documentation is less sexy than implementing
technical solutions, but for the problem "more security for users"
proper user documentation is actually more important than many of
the technical solutions.


-- 

   "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: Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Adrian Bunk]

On Fri, Oct 21, 2016 at 08:55:26AM +0200, Jan Mojzis wrote:
> > "extremely outdated"?
> > 
> > This sounds like a hack from ~ 20 years ago when people realized that 
> > running several programs at the same time as nobody does not isolate
> > them from each other.
> > 
> > Much better solutions for restricting what a process can or cannot do 
> > are now available.
> 
> The basic idea is taken from extreme - sandboxing:
> https://cr.yp.to/talks/2007.04.27/extremesandbox.c[1] 
> 
> My 2 tools currently making only small
> part on this idea, only droping uids/gids.
> I would like to improve my tools in the future, 
> 
> but I thing first step:
> - running current daemons/cron scripts/... under differentd UIDs in the system
> simply by using extremesetuidgid/extremeenvuidgid (instead of 
> setuidgid/envuidgid)

One part of my email you conveniently ignored was:
  20 years ago such a hack would at least have ensured that every 
  process has a unique uid.
  Even this is no longer true.

I'd bet you did not even understand the problem.

I am actually quite sure you did not understand it, since what
breaks your hack is related to proper solutions for sandboxing.

> second step:
> - create (library ??) to use buggy libraries such openssl sandboxed using 
> idea from
> extreme sandbox
>...

All this feels like travelling 20 years back in time.

2007 was approximately the latest time when something like that was 
still considered acceptable security.

Today this is just extremely bad sandboxing, and anyone suggesting to
do anything like that in 2016 proves without any doubt that he doesn't
have a clue regarding security.

> Jan
>...

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: When should we https our mirrors?

[Adrian Bunk]

On Sun, Oct 23, 2016 at 06:04:50AM -0700, Kristian Erik Hermansen wrote:
>...
> The main issue is that a well positioned attacker, such as the NSA or
> Chinese router admins, have the ability to collect and analyze in
> real-time what systems have installed what patches installed by
> monitoring the historical / real-time patch requests downloaded to
> Debian systems.
>...

It is a common misconception that https could help against these kinds 
of attacks.

https is an improvement over http and it would be good if Debian could  
switch to https by default in stretch, but for the problem you are 
talking about it does not really make a difference.

https can obfuscate the traffic enough that a casual observer
has problems determining what exactly is being transferred.

If someone like the NSA is analyzing all your traffic, then the 
information when and how much data gets transferred should be
sufficient to deduce exactly the information you are worried about.

apt-transport-tor is the only option that has a realistic chance of 
helping you, unless you want to run a mirror of Debian in your network. 
Anyone who is seriously worried about these issues and has a clue about 
security will end up doing something like that.

For the kind of attacks you are describing, https is just snake oil.

> Regards,

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: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Adrian Bunk]

On Tue, Oct 18, 2016 at 04:15:50PM +0100, Steve McIntyre wrote:
>...
> Life's too short to go and fix all the crap in the world personally,
> but we can keep certain minimum standards for what we as a group allow
> into Debian. :-(

What policies and processes should ensure these minimum standards?
And who will do the work?

The whole problem is not unique to JS.

See #841113 for a random recent example in C where someone looked
at an ITP.

We are talking about 10 ITPs per day.

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: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Adrian Bunk]

On Mon, Oct 24, 2016 at 09:22:39AM -0700, Russ Allbery wrote:
> Adrian Bunk <b...@stusta.de> writes:
> > On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
> 
> >>...
> >> The value of HTTPS lies in its protection against passive snooping.  Given
> >> the sad state of the public CA infrastructure, you cannot really protect
> >> against active MITM with HTTPS without certificate pinning.
> 
> > You are implicitely assuming that mirrors can be trusted, 
> > and even that is not true.
> 
> > Who is operating ftp.cn.debian.org, and who has access to the logfiles 
> > on that server?
> 
> So, here, I think you're making the best the enemy of the good, which is
> always tempting in security.
> 
> Everyone (myself included) wants to create a system that's actually
> secure, the same way that we want to create software that works properly.
> But in security, even more so than most software, that's rarely possible.
> There's always another attack.  It's a sliding scale of tradeoffs, and
> just because you're not preventing all attacks doesn't mean that making
> things harder for the attacker isn't useful.
> 
> Looking at this worry in particular, note that you're now assuming that a
> nation-state has compromised a specific mirror (in some way, maybe just by
> running it without regard to the privacy of its users).  As pointed out,
> this only gets partial information, but more importantly, this requires
> the nation-state to actively do something.  They have to now either
> compromise the mirror or be running it in a way that may be discoverable.
>...

The government operating or having access to the mirror you are using is 
a lot more realistic and easier than the MITM with a fake certificate 
you were talking about.

> > When a nation-state actor analyzes all the traffic on a network
> > connection that also happens to carry the traffic between you and the
> > Debian mirror you are using, HTTPS won't make a difference.
> 
> Well, I disagree, largely because I think you're overestimating the
> willingness to do deep data analysis on something that's only a tertiary
> (at best) security objective.
> 
> Dragnet surveillance is the most common nation-state approach at the
> moment primarily because it's *really easy*.  Get a backbone tap
> somewhere, dredge all the unencrypted data, run simple analysis across it
> (pulling out URLs accessed is obviously trivial for unencrypted HTTP),
> throw it into some sort of huge database, and decide what you want to
> query for later.

Pulling out the dates and amounts transferred fot HTTP traffic is
also trivial.

> Doing traffic analysis that requires analyzing encrypted data by object
> size or the like is still certainly *possible* (that was the point that I
> made in my first message to this thread), but it's not *trivial*.  It
> requires someone go write code, go think about the problem, and regularly
> gather information from a mirror to correlate encrypted object sizes with
> packages.  It requires a *human* actually *think* about the problem, and
> then set up and maintain an automated system that requires some level of
> ongoing babysitting.

I would assume this can be pretty automated, and that by NSA standards 
this is not a hard problem.

> Can nation-states do this?  Obviously, yes.  But the goal here isn't to
> prevent them from launching these sorts of attacks.  The goal is to make
> it expensive, to require that they justify a budget to hire people to do
> all this additional work that requires custom automation, and to raise the
> bar across the board to make simplistic dragnet surveillance unrewarding.
> This forces them into making some hard decisions about resource allocation
> and attempting more visible intrusions.  Hard decisions are expensive, not
> just in resources but also in politics.
> 
> It *is* a tradeoff, not perfect security, so we should obviously also take
> into account how much effort it takes on our side and whether we're
> expending less effort than we're forcing from our adversary.  But, in
> general, ubiquitous encryption is totally worth it from that sort of
> effort analysis.  Once you get good systems in place (Let's Encrypt
> seriously changed the calculation here), adding encryption is usually far
> easier than the work required on the snooping side to recover the sort of
> metadata they had access to unencrypted.  I think that's the case here.

Let me try to summarize my point:

apt-transport-https makes it slightly harder to determine what packages 
are being transferred, and this is good.

When someone is seriously worried about a nation-state actor determining 
what packages he downloads then apt-transport-https is not a solution, 
and the proper solut

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Adrian Bunk]

On Mon, Oct 24, 2016 at 04:33:57PM -0700, Russ Allbery wrote:
> Adrian Bunk <b...@stusta.de> writes:
>...
> > I would assume this can be pretty automated, and that by NSA standards
> > this is not a hard problem.
> 
> Since the entire exchange is encrypted, it's not completely trivial to map
> size of data transferred to a specific package (of course, it's even
> harder if we reuse connections).  But the point I'm making is more that
> it's not something that just falls out of an obvious surveillance
> technique that has wide-ranging uses.  It requires someone to write code
> to *specifically* target Debian mirrors, which I think is much less likely
> than just collecting all the data and deciding to analyze it afterwards.
>...

If I were looking at the apt traffic, the most interesting for me would 
be the traffic to security.debian.org that a computer running Debian 
stable usually produces.

Just collecting the data when and how much HTTPS traffic is happening 
should be sufficient to determine information like the following:
  What Debian release is running on that computer?
  Which security relevant packages are installed in that computer?
  Are security updates downloaded automatically or manually?
  In the latter case, are they installed in a timely manner?

When your adversary is powerful enough that he is capable of monitoring
your traffic with security.debian.org, then apt-transport-https is just 
snake oil.

The NSA might actually be very grateful that there are people who are 
promoting such snake oil as solution, since this lowers the probability 
of people looking for solutions that could make it harder for the NSA.

I would assume it is unlikely that the NSA is monitoring the connection 
between me and my nearest Debian mirror. This does of course depend on 
your geographical location.

I would assume it is likely that the NSA is monitoring the connection 
between me and security.debian.org.

By discouraging users from using mirrors for security.debian.org,
Debian is presenting a nearly complete list of all computers in
the world running Debian stable and their security update status
and policies on a silver plate to the NSA.

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: When should we https our mirrors?

[Adrian Bunk]

On Mon, Oct 24, 2016 at 04:00:49AM -0700, Kristian Erik Hermansen wrote:
> On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk <b...@stusta.de> wrote:
> but also I should point out that your email is being routed
> insecurely via welho.com and lacks TLS in transit, so I also probably
> shouldn't consider your TLS knowledge very highly...

Your incorrect claims won't become better by personal attacks against me.

What would TLS protect against when sending an email to a public
mailing list?

The contents (including all headers) is anyway public, and if either
of us was worried about someone modifying the contents of the email
he would add a signature.

> > It is a common misconception that https could help against these kinds
> > of attacks.
> >
> > https is an improvement over http and it would be good if Debian could
> > switch to https by default in stretch, but for the problem you are
> > talking about it does not really make a difference.
> >
> > https can obfuscate the traffic enough that a casual observer
> > has problems determining what exactly is being transferred.
> >
> > If someone like the NSA is analyzing all your traffic, then the
> > information when and how much data gets transferred should be
> > sufficient to deduce exactly the information you are worried about.
> 
> The point is to make passive analysis more costly to do so. If they
> have to assign a probability and it takes exponentially more resources
> than simply "save PCAP to disk", then HTTPS has improved the
> situation.
>...

Against someone like the NSA the improvement is pretty marginal,
and I doubt it would increase the work they have to do much.

Encrypting the contents doesn't help much when you can deduce the 
contents from the timing and amount of the transfers.

Your claims that using https for that purpose would give any kind of 
protections against actors like the NSA are just snake oil.

Pretty dangerous snake oil, if someone ends up believing what you wrote  
instead of using a proper solution like apt-transport-tor.

Debian is an Open Source project, and the only way you can improve 
anything is by doing work yourself - if all you are doing is producing 
hot air, you will achieve nothing.

People have already pointed out several areas where work needs to be 
done for using https by default, and if this is important for you there 
is for example nothing stopping you from starting to work right now on 
improving the https transport in apt.

Or you could prove that it is actually not that important for you by 
doing no development work for that.

Noone is arguing that switching to https would be a bad thing,
but whether or not it will happen depends solely on whether or
not people like you will do the work to make it happen.

> Regards,

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: When should we https our mirrors?

[Adrian Bunk]

On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Re: When should we https our mirrors?"):
>...
> Adrian:
> > Noone is arguing that switching to https would be a bad thing,
> > but whether or not it will happen depends solely on whether or
> > not people like you will do the work to make it happen.
> 
> I think there is a problem with messages like your earlier one:
>
>  | It is a common misconception that https could help against these
>  | kinds of attacks.
>  ...
>  | For the kind of attacks you are describing, https is just snake
>  | oil.
> 
> It is very difficult for someone who disagrees with that to let it
> slide.  I don't understand why you thought it valuable to put forward
> that position so strongly. I'm afraid that your messages so far have
> come across as picking an unnecessary fight with Kristian,

In the email I replied to, Kristian did write:
  I am sure everyone here is much smarter than me, so I am looking for
  some feedback on this.

Kristian was not asking for how he could contribute to Debian.

Kristian was asking for feedback on what he described.

I gave feedback.

> while
> simultaneously blaming Kristian for continuing the argument.

Where did I blame Kristian for continuing the argument?
 
> I would have suggested writing something more like this:
> 
>  ] I agree that https is an improvement over http and it would be good
>  ] if Debian could switch to https by default in stretch.
>  ]
>  ] (This is despite the fact that I don't necessarily agree that https
>  ] helps significantly against the attacks you describe.  But I don't
>  ] think we really need to have that argument.)

This is not about agreeing on the favorite ice cream flacour.

My point is that for the problem Kristian is describing,
using https is just snake oil.

apt-transport-https is not a solution for this problem,
if this problem should be solved you need apt-transport-tor.

This global picture should be clear to everyone.

https by default should be doable and would be non-controversial,
but it would be a lot of work for relatively small benefit.

And it would not solve this problem.

If the goal is to solve this problem, a solution might for example be
to make apt-transport-tor more visible.

>  ] I encourage you to work with the relevant people on the technical
>  ] aspects of increasing the use of TLS by apt.  They could probably
>  ] do with your help.
> 
> OTOH, Kristian, I agree with Adrian that your comments about
> "shouldn't consider your TLS knowledge very highly" are inflammatory
> and inappropriate.
> 
> 
> Thanks,
> Ian.

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: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Adrian Bunk]

On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>...
> The value of HTTPS lies in its protection against passive snooping.  Given
> the sad state of the public CA infrastructure, you cannot really protect
> against active MITM with HTTPS without certificate pinning.

You are implicitely assuming that mirrors can be trusted, 
and even that is not true.

Who is operating ftp.cn.debian.org, and who has access to the logfiles 
on that server?

Debian would accept debian.nsa.gov as mirror, and the NSA might already 
operate or have access at some current mirrors.

> But that's
> fine; active attackers are a much, much rarer attack profile.  The most
> likely attack, and the one we're able to protect against here, is passive
> observation of mirror traffic used to build a database of who is using
> what package and at what version.  HTTPS doesn't *prevent* this, but it
> requires the attacker to do much more sophisticated traffic analysis, or
> take the *much* more expensive and *far* riskier step of moving to active
> interference with traffic, neither of which nation-state attackers want to
> do and neither of which they have the resources to do *routinely*.
> 
> It won't help if a nation-state actor is targeting you *in particular*.
> But it helps immensely against dragnet surveillance.

No, it does not help much.

When a nation-state actor analyzes all the traffic on a network 
connection that also happens to carry the traffic between you and
the Debian mirror you are using, HTTPS won't make a difference.

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: Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Adrian Bunk]

On Wed, Oct 19, 2016 at 09:33:14AM -0200, Henrique de Moraes Holschuh wrote:
> On Wed, Oct 19, 2016, at 06:56, Jan Mojzis wrote:
> > >I read manpage on github, but did not understood, what exactly this
> > > program provides.  Can it replace creation system users for dropping
> > > privileges?
> > 
> > It's doesn't create users.
> > It only drops privileges (extremesetuidgid) or sets $UID/$GID env.
> > variables (extremeenvuidgid).
> > 
> > For example:
> > extremesetuidgid -b 10 sleep 1
> > 
> > runs command 'sleep 1' under unprivileged uid/gid (computed getpid()
> > +10) 
> > e.g. for:
> > pid=10 ... uid=gid=100010
> > pid=11 ... uid=gid=100011
> > pid=12 ... uid=gid=100011
> 
> I am just wondering why is it called "extreme"?

"extremely outdated"?

This sounds like a hack from ~ 20 years ago when people realized that 
running several programs at the same time as nobody does not isolate
them from each other.

Much better solutions for restricting what a process can or cannot do 
are now available.

> It looks more like a functionality related to "exclusive" guid/uid,
> instead...

20 years ago such a hack would at least have ensured that every process 
has a unique uid.

Even this is no longer true.


tinysshd [1] is another worrisome example.

Writing an own "tiny" sshd from scratch, and the result is not even 
smaller than the dropbear everyone else uses for that purpose.

To make the NIH complete, it uses own versions of standard C library
string functions and an own (pretty primitive) build system.


cu
Adrian

[1] thank god only in experimental so far

-- 

   "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: [Letsencrypt-devel] Certbot in Debian Stretch

[Adrian Bunk]

On Thu, Nov 24, 2016 at 07:08:33PM +0100, Daniel Pocock wrote:
> 
> 
> On 24/11/16 17:39, Adrian Bunk wrote:
> > On Thu, Nov 24, 2016 at 05:22:29PM +0100, Daniel Pocock wrote:
> >> ...
> >> For networked services, it is different.
> >>
> >> Debian has already been carrying updated versions of Firefox and
> >> Chromium in stable including bundled dependencies too.  Maybe we need to
> >> have an objective way of deciding which other projects genuinely deserve
> >> the same treatment.
> >> ...
> > 
> > The problem with Firefox/Chromium is not "networked services".
> > 
> > The problem is that it is not feasible to backport all security fixes
> > to a 3 year old version of such a browser.
> > 
> > And the "objective way of deciding" is that not shipping any web browser 
> > would not be a realistic option.
> > 
> > For nearly any other package, not shipping it in a stable is the better 
> > option for Debian.
> 
> Why do you say it is the better option?
> 
> If a package is very useful and has made certain efforts to be stable
> (e.g. not arbitrarily changing the command line syntax) and it is a leaf
> package, maybe it is time to consider it?

Every update you put into stable might get automatically deployed
to millions of computers running unattended-upgrades (or similar).

Only doing "certain efforts to be stable" could easily result in huge
outages somewhere.

> The alternative is that more and more frequently, the user is tempted to
> get things from upstream apt repositories.  If many upstreams go down
> that path and more users accept it as normal, the net result may be even
> worse.

When upstream is very volatile, this is a decent option.

> Regards,
> 
> Daniel

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: OpenSSL 1.1.0

[Adrian Bunk]

On Wed, Nov 23, 2016 at 11:50:12PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 24 Nov 2016, Kurt Roeckx wrote:
>...
> > > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> > > might not be safe.   If it doesn't (i.e. at most you have a qt flag that
> > > says "use SSL", etc), then it should be fine.
> > 
> > It seems to be doing this in qtbase5-private-dev. Not sure if
> > there are actually any users of it.
> 
> If it does, all reverse *build* dependencies would need to be inspected,
> then.
> 
> AFAIK, that means they must not link to anything that could link to a
> different libssl than the one used by qt5.  If they do, everything needs
> to be inspected down to the details to ensure nothing will ever leak
> openssl contextes and data structures across a library boundary
> (including the application).

If inspection is not easily possible, then adding a dependency on 
libssl1.0-dev to qtbase5-private-dev should be sufficient to
ensure that this is not leaked to a different OpenSSL version.

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: OpenSSL 1.1.0

[Adrian Bunk]

On Thu, Nov 24, 2016 at 03:20:06PM +0100, Jan Niehusmann wrote:
> On Thu, Nov 24, 2016 at 03:59:10PM +0200, Adrian Bunk wrote:
> > If inspection is not easily possible, then adding a dependency on 
> > libssl1.0-dev to qtbase5-private-dev should be sufficient to
> > ensure that this is not leaked to a different OpenSSL version.
> 
> I see two disadvantages:
> 
> 1) doesn't catch cases where a package doesn't depend on libssl at all,
>but depends on two libraries which in turn use qt and libssl.
>...

I was answering to the "exposes OpenSSL internels (e.g. opaque structs)
in its API" problem.

When every -dev that contains headers exposing OpenSSL internals depends 
on the libssl*-dev it uses, then this problem is solved.

dlopen() is a separate problem.

> But I don't know a better alternative, either.
> 
> Jan

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: [Letsencrypt-devel] Certbot in Debian Stretch

[Adrian Bunk]

On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote:
> On Thu, Nov 24, 2016, at 13:39, Philipp Kern wrote:
> > So if you, as an upstream maintainer, have a change that is needed for
> > compatibility with changes in network APIs and the change is reviewable
> > by humans, a stable update could be possible. It's still on a
> > case-by-case basis, so you would need to ask and the Release Team cannot
> > approve what they do not know about.
> 
> There are more cases where Debian stable is getting new upstream
> releases.
> It's mostly to keep up with the security (MySQL, PHP),
>...

These are long-term supported upstream stable branches.

Debian cannot just sacrifice stability by throwing the latest upstream 
release of some random packages into stable.

And rewarding an upstream not able or willing to provide stability would 
also set the incentive the wrong way.

If it is likely that some packages cannot be supported until the end of 
the (non-LTS) lifetime of stretch in mid/end-2020, then please file RC 
bugs to keep these packages out of stretch.

> Cheers,

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: OpenSSL 1.1.0

[Adrian Bunk]

On Thu, Nov 24, 2016 at 02:50:23PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 24 Nov 2016, Adrian Bunk wrote:
> > On Wed, Nov 23, 2016 at 11:50:12PM -0200, Henrique de Moraes Holschuh wrote:
> > > On Thu, 24 Nov 2016, Kurt Roeckx wrote:
> > >...
> > > > > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> > > > > might not be safe.   If it doesn't (i.e. at most you have a qt flag 
> > > > > that
> > > > > says "use SSL", etc), then it should be fine.
> > > > 
> > > > It seems to be doing this in qtbase5-private-dev. Not sure if
> > > > there are actually any users of it.
> > > 
> > > If it does, all reverse *build* dependencies would need to be inspected,
> > > then.
> > > 
> > > AFAIK, that means they must not link to anything that could link to a
> > > different libssl than the one used by qt5.  If they do, everything needs
> > > to be inspected down to the details to ensure nothing will ever leak
> > > openssl contextes and data structures across a library boundary
> > > (including the application).
> > 
> > If inspection is not easily possible, then adding a dependency on 
> > libssl1.0-dev to qtbase5-private-dev should be sufficient to
> > ensure that this is not leaked to a different OpenSSL version.
> 
> How so? 
> 
> Consider the flattened tree (app is the root, - denotes a branch).
> 
> A - B - App -  C - D
> 
> Where A and D are two versions of openssl. B and C are libs (suppose B
> comes from qtbase5-private-dev) from different source packages.

Where does App get the definitions/declarations for the contextes and 
data structures it could leak between A and D?

If they are part of the B API and part of the C API, then they are used 
in the header files shipped in b-dev and c-dev.

If both b-dev and c-dev would depend on the libssl*-dev they use,
then App cannot be compiled with both B and C unless these use
the same OpenSSL. Any mismatch would very quickly be reported
as a FTBFS bug.

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: [Letsencrypt-devel] Certbot in Debian Stretch

[Adrian Bunk]

On Thu, Nov 24, 2016 at 05:22:29PM +0100, Daniel Pocock wrote:
>...
> For networked services, it is different.
> 
> Debian has already been carrying updated versions of Firefox and
> Chromium in stable including bundled dependencies too.  Maybe we need to
> have an objective way of deciding which other projects genuinely deserve
> the same treatment.
>...

The problem with Firefox/Chromium is not "networked services".

The problem is that it is not feasible to backport all security fixes
to a 3 year old version of such a browser.

And the "objective way of deciding" is that not shipping any web browser 
would not be a realistic option.

For nearly any other package, not shipping it in a stable is the better 
option for Debian.

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: OpenSSL 1.1.0

[Adrian Bunk]

On Thu, Nov 17, 2016 at 12:27:43AM -0500, Scott Kitterman wrote:
> On Wednesday, November 16, 2016 10:04:00 PM Lisandro Damián Nicanor Pérez 
> Meyer wrote:
> > On jueves, 17 de noviembre de 2016 00:40:42 ART Kurt Roeckx wrote:
> > > On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote:
> > > > The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
> > > > but that sort of assumes that you are only interested in openssl 1.1 for
> > > > ChaCha20 (and not the other changes).
> > > 
> > > I'm not willing to maintain such a patch.
> > 
> > I am with Kurt here. I myself didn't want to apply an untested patch to qt4
> > to add libssl1.1 support without enough time to test it (because after all
> > qt4 is dead upstream and we can only hope for the best, but not *right*
> > now).
> > 
> > We need to find another option.
> 
> We now have the particularly fun situation where neither openssl 1.1 (due to 
> #844366) nor openssl 1.0 (due to #736687) can get to unstable,
>...

s/unstable/testing/

openssl 1.1 and openssl1.0 have to enter testing at the same time.

#736687 is a non-issue for the transition itself, and the release team 
can force a package into testing ignoring such a bug.

> Scott K

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: libc recently more aggressive about pthread locks in stable ?

[Adrian Bunk]

On Thu, Nov 17, 2016 at 09:28:34AM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, Nov 17, 2016, at 09:11, Lucas Nussbaum wrote:
> > On 17/11/16 at 08:31 -0200, Henrique de Moraes Holschuh wrote:
> > > The deal with *current* Debian stable is that, if the breakage is too
> > > widespread, we simply might not be able to do the right thing (fix the
> > > real bugs).
> > 
> > Based on the number of bugs uncovered by my archive rebuild, I'm really
> > not sure that this class of bugs is widespread, and requires to be
> > special-cased. Relying on users to report problems, and then fix them
> > is probably enough.
> 
> The rebuild was helpful, but it depends on the application/library
> regression test suite to detect any application locking issues.  Not
> every package has those, or runs those during build :-(

But we do already have > 1 year of widespread testing by users
running unstable/testing on machines with TSX enabled.

So for unstable/stretch this does not seem to be a huge problem.

These are normal bugs that should be found and fixed if possible,
just like passing a pointer in an int or many other kinds of bugs.

Or do I miss anything here?

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: OpenSSL 1.1.0

[Adrian Bunk]

On Wed, Nov 16, 2016 at 10:53:18PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-16 19:49:44 [+0200], Adrian Bunk wrote:
> > The problem are not specific bugs, the problem is the whole size of the
> > problem:
> > 
> > 1. Sorting out what packages have to stay at 1.0.2
> > The majority of OpenSSL-using packages in stretch might end up 
> > using 1.0.2 - sorting this out is part of the ongoing OpenSSL
> > transition.
> 
> You have two choices: either port it to 1.1.0 and stay with 1.0.2.

60 packages got removed from testing since there was only a 10 day
window between openssl1.0 being available and autoremoval of these
packages.

And after submitting patches to switch packages to 1.0.2, it was you who 
said "Adrian, seriously? This is not a patch."

This is your transition, and it should actually be you who is working on 
getting all ~ 200 RC bugs in sid related to your transition resolved.

And this is only about the simple cases.
A huge problem is the unknown number of small and big clusters of 
packages that have to use the same OpenSSL version.

Noone from you OpenSSL developers seems to be working on sorting these 
clusters out.

Like I do not understand why Kurt is trying to switch Apache to 1.1
As far as I can see, Apache is part of the libcurl3 cluster where
all packages anyway have to stay at 1.0.2 for stretch.

> > 2. OpenSSL 1.1 support is often only build-tested
> > We are currently at 650 packages in unstable depending on libssl1.0.2, 
> > and when binNMUs will happen we might get a three-digit number of
> > new RC bugs like #843988 and #843532.
> 
> stunnel was prepared upstream to work with 1.1.0 and it wasn't perfect.
> We would also face the same problem if openssl 1.0.2 decided to do a
> realloc() at some point. Lucky it did not yet.
>...

Every non-trivial piece of software has bugs.

The relevant part here is "works with 1.0.2, but did not work with 1.1".
These are regressions when switching from 1.0.2 to 1.1, no matter where
the actual bug is.

> > 3. Another Debian OpenSSL security fiasco?
> > Bugs like #843988 are only about problems that show up immediately.
> > This is often code where mistakes can be CVEs, and bug #843988 or
> > the comment "With Kurt's patch, apache2 crashes on startup" don't
> > make me optimistic regarding silent new security holes.
> > Depending on how/if this was applied upstream, these might become
> > Debian-specific CVEs.
> 
> I forwaded (or tried) my 1.1.0 fixups to upstream. I didn't find alive
> upstream for the two perl patches I made and had hope that the debian
> maintainer knows how to forwarded them.

You are not the only one patching these, and surely not the least
knowledgable person making such patches.

And noone seems to be systematically tracking for all patches what 
happens in the end - even cherry-picking an upstream patch might
miss critical later upstream fixes.

The problem here is the huge amount of packages that need changes due to 
the OpenSSL API breakage.

> > People will remember the last time Debian screwed up badly in the area 
> > of OpenSSL, so this could really harm the reputation of Debian.
> > 
> > 4. Schedule
> > The transition freeze was 11 days ago, and the soft freeze is only
> > 1.5 months ahead.
> > If the work on points 1 and 2 above is not mostly finished
> > by December 5th (mandatory 10-day migrations will start, only
> > 1 month until the soft freeze), either the OpenSSL transition
> > or the release schedule have to be scrapped.
> 
> So people still can choose to go for 1.1.0 or 1.0.2. They may work on
> 1.1.0.

Is everyone aware that this choice is per-cluster and not per-package?

One single leaf package that chooses to stay at 1.0.2 and is part
of a cluster implies that you must force all other packages in the 
cluster to also stay at 1.0.2

> Sebastian

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: OpenSSL 1.1.0

[Adrian Bunk]

On Tue, Nov 15, 2016 at 07:03:28PM +1100, Scott Leggett wrote:
> On 2016-11-15.00:16, Adrian Bunk wrote:
> > Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid 
> > free." 
> > or #843988 will be a common sight on the list of RC bugs for several
> > months in any scenario with OpenSSL 1.1 as default.
> >
> > ...
> >
> > 2. move the stretch release schedule by 6-12 months to have
> >only OpenSSL 1.1 in stretch
> 
> So with OpenSSL 1.1 in stretch, the release schedule is going to move by
> 6-12 months regardless?

Shipping OpenSSL 1.1 as security-supported technology preview in stretch,
and a few packages that both work with OpenSSL 1.1 and do not have 
inter(r)dependencies with packages that don't work properly with OpenSSL 
1.1 could use it - that would be possible without negative impact on the 
release schedule.

> Regards,
> Scott.

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: libc recently more aggressive about pthread locks in stable ?

[Adrian Bunk]

On Mon, Nov 14, 2016 at 10:31:18AM +0100, Gert Wollny wrote:
> Am Sonntag, den 06.11.2016, 01:12 -0200 schrieb Henrique de Moraes
> Holschuh:
> > 
> > 
> > 
> > Unfortunately, when hardware lock elision support was added to glibc
> > upstream, libpthreads was *not* changed to properly assert() this
> > forbidden condition on the non-hardware-elision codepaths.  Such an
> > assert() would have given us consistent behavior, thus flushing the
> > bugs out in the open... at the cost of a performance hit (I have no
> > idea how severe), and much screaming.
> 
> An alternative to find problems with (un-)locking should be to compile
> the program in question with -fsanitize=thread (on amd64) and run it.
> 
> Unfortunately, in current unstable with thread sanitizer one might get
> #796246 (at least I had this).

Does "-fsanitize=thread -no-pie" work for you?

> Best, 
> Gert 

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: OpenSSL 1.1.0

[Adrian Bunk]

On Tue, Nov 15, 2016 at 09:37:01AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote:
> > On Nov 14, Lisandro Damián Nicanor Pérez Meyer  wrote:
> > > And yes, I would step back and switch libssl-dev to provide libssl1.0-dev
> > > and have libssl1.1-dev around for anyone who can really do the switch.
> > I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
> > bad default for next year's release.
> > Bad enough that I would have to use a different distribution for some
> > web servers.
> 
> That's why I wrote:
> 
>   And if we **really** need to switch to libssl1.1 then we **really** need to
>   delay the release by 6 months as a very minimum, maybe 1 year.
> 
> Yes, I also know that it sounds awful, but do we have another way out?

Yes, patching the OpenSSL 1.1 features that are really needed into the
Debian OpenSSL 1.0.2 package.

For ChaCha20 that's existing patches that are already being used
elsewhere.

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: OpenSSL 1.1.0

[Adrian Bunk]

On Wed, Nov 16, 2016 at 12:15:39AM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-15 00:16:14 [+0200], Adrian Bunk wrote:
> > And since 80% of all OpenSSL-using packages in unstable are still
> > using libssl1.0.2 (binNMUs have not yet happened), all runtime
> > issues observed so far are only the tip of the iceberg.
> > Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid 
> > free." 
> > or #843988 will be a common sight on the list of RC bugs for several
> > months in any scenario with OpenSSL 1.1 as default.
> Are you afraid of bugs or that nobody will look after them? Can't speak
> for apache but #843988 got patched and so did #843532.

The problem are not specific bugs, the problem is the whole size of the
problem:

1. Sorting out what packages have to stay at 1.0.2
The majority of OpenSSL-using packages in stretch might end up 
using 1.0.2 - sorting this out is part of the ongoing OpenSSL
transition.

2. OpenSSL 1.1 support is often only build-tested
We are currently at 650 packages in unstable depending on libssl1.0.2, 
and when binNMUs will happen we might get a three-digit number of
new RC bugs like #843988 and #843532.

3. Another Debian OpenSSL security fiasco?
Bugs like #843988 are only about problems that show up immediately.
This is often code where mistakes can be CVEs, and bug #843988 or
the comment "With Kurt's patch, apache2 crashes on startup" don't
make me optimistic regarding silent new security holes.
Depending on how/if this was applied upstream, these might become
Debian-specific CVEs.
People will remember the last time Debian screwed up badly in the area 
of OpenSSL, so this could really harm the reputation of Debian.

4. Schedule
The transition freeze was 11 days ago, and the soft freeze is only
1.5 months ahead.
If the work on points 1 and 2 above is not mostly finished
by December 5th (mandatory 10-day migrations will start, only
1 month until the soft freeze), either the OpenSSL transition
or the release schedule have to be scrapped.

> Sebastian

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: OpenSSL 1.1.0

[Adrian Bunk]

On Fri, Nov 18, 2016 at 10:22:59PM +0100, Moritz Mühlenhoff wrote:
> Adrian Bunk <b...@stusta.de> schrieb:
> > And/or get sponsorship from companies for supporting ChaCha20-patched 
> > 1.0.2
> 
> It's not a matter of whipping up some patch; anything less than an
> official backport of chacha20 into a 1.0.2x release is not going
> to be supportable.

Supporting 1.1.0 in addition to 1.0.2, including 2 years of supporting 
1.1.0 after upstream support for it ended - it is confirmed that Debian
is able and willing to support that.

Supporting 1.0.2 only [1] plus chacha20 patched into that - it is not 
obvious to me why this would be that much worse in comparison that
it would not be an option under any circumstances.

Whether it is the best available option is a separate question.

My current preference would be stretch 1.0.2-only[2], and an early 
buster a year later[3] if Fedora manages to make a release with 1.1
in June.

With dual 1.0.2/1.1 not working in the current release schedule,
what is your preferred solution?

> Cheers,
> Moritz

cu
Adrian

[1] which should see a lot less code changes now that upstream
is focussing on 1.1 and later
[2] with or without ChaCha20 patched
[3] my preference, whether the release team would agree I do not know

-- 

   "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: libc recently more aggressive about pthread locks in stable ?

[Adrian Bunk]

On Thu, Nov 17, 2016 at 11:38:46AM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, Nov 17, 2016, at 09:50, Adrian Bunk wrote:
> > But we do already have > 1 year of widespread testing by users
> > running unstable/testing on machines with TSX enabled.
> > 
> > So for unstable/stretch this does not seem to be a huge problem.
> > 
> > These are normal bugs that should be found and fixed if possible,
> > just like passing a pointer in an int or many other kinds of bugs.
> > 
> > Or do I miss anything here?
> 
> I am not sure we have that much user coverage, given the blacklisting we
> did in glibc.
>...

Skylake is not blacklisted anywhere, I assume?

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: OpenSSL 1.1.0

[Adrian Bunk]

On Thu, Nov 17, 2016 at 10:43:53PM +0100, Moritz Mühlenhoff wrote:
> Adrian Bunk <b...@stusta.de> schrieb:
> > On Tue, Nov 15, 2016 at 09:37:01AM -0300, Lisandro Damián Nicanor Pérez 
> > Meyer wrote:
> >> On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote:
> >> > On Nov 14, Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> 
> >> > wrote:
> >> > > And yes, I would step back and switch libssl-dev to provide 
> >> > > libssl1.0-dev
> >> > > and have libssl1.1-dev around for anyone who can really do the switch.
> >> > I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
> >> > bad default for next year's release.
> >> > Bad enough that I would have to use a different distribution for some
> >> > web servers.
> >> 
> >> That's why I wrote:
> >> 
> >>   And if we **really** need to switch to libssl1.1 then we **really** need 
> >> to
> >>   delay the release by 6 months as a very minimum, maybe 1 year.
> >> 
> >> Yes, I also know that it sounds awful, but do we have another way out?
> >
> > Yes, patching the OpenSSL 1.1 features that are really needed into the
> > Debian OpenSSL 1.0.2 package.
> >
> > For ChaCha20 that's existing patches that are already being used
> > elsewhere.
> 
> That's not an option, while there's an external patch for chacha20/poly
> by cloudflare it hasn't been upstreamed and we cannot cover it with
> security support in a meaningful manner.

1.1.0 will be out of upstream security support after August 2018,
1.0.2 after 2019.

Debian is able and willing to provide security support for two OpenSSL 
releases in stretch, that will both be without upstream support in 2020.

> And other features are not
> backportable at all.
> 
> Kurt has already asked who would do the backports and support them in
> https://lists.debian.org/debian-release/2016/10/msg00609.html, so stop
> pretending that's a genuine option.

Dual 1.0.2/1.1 is the expected mess, and people have to stop pretending 
it would be a genuine option that most of the important packages in 
stretch would use 1.1, unless the release schedule is moved by 6-12 
months.

Trying to make all or a majority of OpenSSL-using packages in stretch 
use 1.1 might not even be much faster in delivering 1.1 features to
stable users than making stretch 1.0.2-only[1], and release buster
1.1-only a year after stretch.

As a bonus, "stretch 1.0.2-only and early buster" would imply providing 
security support for one OpenSSL version that will be upstream-supported 
during the whole (non-LTS) lifetime of stretch, instead of providing 
security support for two OpenSSL versions that will both get out of 
upstream support during the lifetime of a stretch without early buster.

And/or get sponsorship from companies for supporting ChaCha20-patched 
1.0.2 through Freexian - this would be an option that would not impact 
the release schedule.[2]

OpenSSL upstream created this mess by only providing new features 
together with a huge API breakage, and there are no nice solutions
for stretch.

cu
Adrian

[1] shipping 1.1 as security-supported technology preview is an option
[2] I am aware that this would be controversial

-- 

   "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: Multi-Arch: allowed

[Adrian Bunk]

On Sat, Nov 19, 2016 at 05:53:04PM +0100, Julien Cristau wrote:
> On Tue, Nov  1, 2016 at 18:11:27 +0100, Thibaut Paumard wrote:
> 
> > The -dbg package is Multi-Arch same. It Depends on the packages for
> > which it provides debugging symbols, some of which are Multi-Arch:
> > allowed.
> 
> That Depends seems wrong, there's no reason a -dbg package needs a
> dependency on anything, AFAICT.

A -dbg package only works with the exact version of the package it 
provides the debug symbols for.

> Cheers,
> Julien

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: OpenSSL 1.1.0

[Adrian Bunk]

On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote:
> Marco d'Itri:
> > On Nov 14, Lisandro Damián Nicanor Pérez Meyer  wrote:
> > 
> >> And yes, I would step back and switch libssl-dev to provide libssl1.0-dev 
> >> and 
> >> have libssl1.1-dev around for anyone who can really do the switch.
> > I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very 
> > bad default for next year's release.
> > Bad enough that I would have to use a different distribution for some 
> > web servers.
> 
> At the moment, the maintainers of apache2 are picking the openssl 1.0
> route.
>...

For libcurl3 the OpenSSL version is part of the ABI due to SSL_CTX.
If packages linked with libcurl3 use a different OpenSSL version than
libcurl3, that can break badly.

Apache seems to have similar problems.

Such packages do not even have a choice of going to 1.1 since that would
make it impossible for their rdeps to use 1.0.2

> The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
> but that sort of assumes that you are only interested in openssl 1.1 for
> ChaCha20 (and not the other changes).

Trying to mix OpenSSL 1.0.2 and 1.1 is the expected mess.

And since 80% of all OpenSSL-using packages in unstable are still
using libssl1.0.2 (binNMUs have not yet happened), all runtime
issues observed so far are only the tip of the iceberg.
Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid free." 
or #843988 will be a common sight on the list of RC bugs for several
months in any scenario with OpenSSL 1.1 as default.

For Apache, the choices available are:
1. no ChaCha20 in Apache in stretch
2. move the stretch release schedule by 6-12 months to have
   only OpenSSL 1.1 in stretch
3. apply ChaCha20 patches to OpenSSL 1.0.2

You have the same choices for any other OpenSSL 1.1 features you
consider important.

Any explicit or implicit claims that you could just switch a package
like Apache to OpenSSL 1.1 within the current stretch release schedule
are just resulting in a lot of people wasting a lot of time.

> Thanks,
> ~Niels
>...

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: Rebuilds with unexpected timestamps

[Adrian Bunk]

On Sun, Oct 30, 2016 at 04:02:48PM +, Ian Jackson wrote:
>...
> Most of our packages use `make' or something like it.  make relies on
> timestamps to decide what to rebuild.  It seems that sometimes our
> source packages contain combinations of timestamps (and perhaps stamp
> files) which, in practice, exempt certain parts of the build from
> taking place (if one just does "apt-get source" and then
> "dpkg-buildpackage -uc -b").
>...
> What do people think ?
>...

Debian uses upstream tarballs, upstream tarballs often contain files 
generated based on the contents of the upstream VCS.

The "hello" package still builds after you autoreconf the package,
but the program no longer knows what version it is (automake tries to 
run build-aux/git-version-gen which is not in the source tarball).

"you autoreconf the package" means that you actually call "autoreconf".
"touch configure.ac" breaks the build of the hello package due to 
missing aclocal-1.14

Be prepared to see a lot of such issues when you touch random files.

If you want this to work properly, Debian has to move from using the 
generated release tarballs to the actual source in the upstream VCS.

> Ian.

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: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Adrian Bunk]

On Mon, Oct 31, 2016 at 03:23:51PM +0100, Bálint Réczey wrote:
> Hi Ian,
> 
> 2016-10-31 14:19 GMT+01:00 Ian Campbell :
> > On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
> >> 2016-10-31 10:38 GMT+01:00 Ian Campbell :
> >> > If possible I'd also prefer a solution which fixed qcontrol-static
> >> > without opting out for the normal dynamic/non-udeb binary.
> >>
> >> I ran the build tests on amd64, this is why I have not caught this error.
> >> A rebuild of lua5.1 should fix the problem.
> >>
> >> Dpkg changes are on their way, too in the next days. I would ask
> >> for a binNMU after dpkg is updated.
> >
> > Thanks, to check I understand: I should wait for #835146 to be fixed in
> > sid (which is expected to happen via a dpkg upload in the next days)
> > and then ask for a binNMU of lua5.1 then qcontrol (or maybe I have
> > reason to upload a newer qcontrol anyway, we'll see)?
> 
> Yes, this should fix qcontrol and maybe you don't even have to ask for
> rebuilds.  I think there is already an archive-wide rebuild planned to
> make reproducibility-related changes in dpkg take effect thus I suggest
> waiting a few days to see if you need to ask for binNMUs.

I do not see any reason for waiting instead of sending the binNMU 
request right now.

Based on the error message the only problem for qcontrol is that the
LUA 5.1 static library has not been compiled with the toolchain that
defaults to PIE, and the one and only change required to fix the build
of qcontrol should therefore be to request a binNMU of lua5.1

> Cheers,
> Balint

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: Rebuilds with unexpected timestamps [and 1 more messages]

[Adrian Bunk]

On Mon, Oct 31, 2016 at 01:42:26AM +, Ian Jackson wrote:
>...
> Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps"):
> > Be prepared to see a lot of such issues when you touch random files.
> 
> I'm certainly expecting to see lots of issues.
> 
> IMO if a package FTBFS when its timestamps are permuted, that is
> probably an RC bug.  It means that there are some files in the
> package, which it thinks it needs as part of the build process, but
> which cannot actually be built.
> 
> If it does "sufficiently different" things, but still succeeds, when
> the timestamps are permited then that's probably a minor or normal
> bug: evidently it can build either way, but this kind of situation is
> probably not intentional and it is setting us up for a future latent
> FTBFS.

The case where I end up with a building but broken "hello" program 
worries me a lot more than the case where I get a FTBFS in hello.

"hello has an empty version number" sounds harmless, but in a lot of 
cases the program or other packages using it might actually parse the
version number.

And I'd guess you might end up with even more complicated runtime issues 
if you mess with the timestamps of random files.

> > If you want this to work properly, Debian has to move from using the 
> > generated release tarballs to the actual source in the upstream VCS.
> 
> If the upstream tarballs are sufficient and our clean target ensures
> that everything is built from source, it can still work.

It can be made to work.

But I do not think it makes sense to do it this way.

Release tarballs contain sources plus generated files.

Lets look at the common "upstream uses git and autotools" case:

Using release tarballs made sense back in the days when git did not 
exist and Debian used the generated files for
  ./configure && make && make install

This already changed when packages started to use autoreconf on
a larger scale.

What you will end up with in practice is basically removing all 
generated files in the clean target.

This means that packages will use the release tarballs,
and then remove all files that are not in git.

At that point the best solution would be an alternative source package 
format that is based on git.

The much-used git-buildpackage is already in that direction, and hacks 
like pristine-tar would disappear with an alternative source package 
format.

> Ian.

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: Rebuilds with unexpected timestamps

[Adrian Bunk]

On Sun, Oct 30, 2016 at 11:48:56PM +, Simon McVittie wrote:
>...
> * Source for generated files in the tarball: should be in both git and
>   tarball, but sometimes mistakenly omitted from tarballs (e.g. configure.ac,
>   m4/foo.m4, build-aux/git-version-gen). Leaving these out of the tarball is
>   also an upstream bug, IMO, because it means the "source" tarball
>   is not really its own source. I'd suggest sending patches upstream to
>   add these to EXTRA_DIST.
>...

The ChangeLog file in the "source" tarball of the hello package is 
generated from the git metadata.

You are saying it is a bug that .git is not shipped in the source 
tarball of GNU hello?

> Regards,

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: Rebuilds with unexpected timestamps [and 1 more messages]

[Adrian Bunk]

On Mon, Oct 31, 2016 at 03:58:12PM +, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps [and 1 more 
> messages]"):
> > On Mon, Oct 31, 2016 at 01:42:26AM +, Ian Jackson wrote:
> ...
> > > If it does "sufficiently different" things, but still succeeds, when
> > > the timestamps are permited then that's probably a minor or normal
> > > bug: evidently it can build either way, but this kind of situation is
> > > probably not intentional and it is setting us up for a future latent
> > > FTBFS.
> > 
> > The case where I end up with a building but broken "hello" program 
> > worries me a lot more than the case where I get a FTBFS in hello.
> > 
> > "hello has an empty version number" sounds harmless, but in a lot of 
> > cases the program or other packages using it might actually parse the
> > version number.
> > 
> > And I'd guess you might end up with even more complicated runtime issues 
> > if you mess with the timestamps of random files.
> 
> I'm confused by what your point is.  Are you saying that issues of the
> category I quote myself describing, above, should be considered RC ?
> 
> I think the archive probably has a great many situations of that kind,
> and that my proposed approach to detecting them may not survive
> contact with reality.
> 
> If you are as worried as you say about this, then I look forward to
> your help in trying to do rebuilds with timestamp-fiddling and trying
> to analyise the copious piles of indigestible build logs which I
> expect such a process to produce.
> 
> Personally given my view that such bugs are probably not too serious,
> I was intending (when I get round to it, which may not be soon) to
> take crude measures to try to keep the false positive rate down.

What I am trying to say is that you will be opening a huge amount
of bugs for a very exotic problem, and that there is a solution
that will automatically fix a large part of them.

Many of the problems you are trying to solve would not be present if 
Debian would not be using upstream release tarballs.

A new git source format and a gradual switch to that would be a clean 
solution to solve most of these issues for a large part of the archive.

>...
> I think dgit plus the hypothetical `3.0 (rsync)' has all the
> properties you would hope for.  (There would still have to be .origs;
> it's up to each maintainer whether those would be upstream's, or made
> by gbp calling git-archive, or whatever.)

I am talking about a source format where the sole contents of the 
.orig.tar is the upstream .git, and the sole contents of .debian.tar
is debian/.git

> Ian.

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: NRSS has been deprecated [#696302]

[Adrian Bunk]

On Sun, Oct 30, 2016 at 06:28:41AM +0100, Adam Borowski wrote:
>...
> An user interested in future releases is usually a contributor of sorts,
> thus often has "devscripts" installed.

The typical user of Debian stable is running Debian on servers,
and will become interested in a future release after it became stable.

>...
> Once stretch is released, we'd file thousands of ITRs, listen to the
> crickets for a bit, then greatly decruft the archive!
>...

If you want to reduce the amount of cruft in the archive,
you should look at the other end.

When something that was ITP'ed into Debian is declared cruft after it 
has been shipped in stable releases, the question should be why it was 
allowed into Debian in the first place.

Especially when looking at the quality of much of the stuff from GitHub, 
the 10k binary packages that are new in stretch should be a bigger worry
than packages with a history of not causing problems in past releases.

> (although if popcon is 4 or so, that's probably telling enough).

It is telling us that relying on popcon numbers for anything is harmful.

What popcon numbers do you expect for architecture-specific packages 
that are only relevant for a subset of the supported hardware on a port?

Half of the stretch release architectures have a popcon lower than 25.

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: Rebuilds with unexpected timestamps

[Adrian Bunk]

On Tue, Nov 01, 2016 at 12:05:38PM +, Ian Jackson wrote:
>...
> Personally I think a Linux kernel tarball, without accompanying git
> history, is a GPL violation.
>...

Why would the git *history* matter for GPL compliance?

You can push from a shallow clone.

> Ian.

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: "PIE by default" transition is underway -- wiki needs updating

[Adrian Bunk]

On Wed, Oct 26, 2016 at 05:37:06AM +0200, Adam Borowski wrote:
> On Wed, Oct 26, 2016 at 12:37:18AM +0200, Andreas Cadhalpun wrote:
> > The current policy says:
> > "As to the static libraries, the common case is not to have relocatable 
> > code"
> > 
> > As of gcc-6 version 6.2.0-7 this is factually wrong, because the compiler
> > enables PIE by default, which means it produces relocatable code.
> > This should definitely be updated to reflect reality.
> 
> It's not that simple.  The compiler enables PIE by default only:
> * if you use "gcc" or "gcc-6".  gcc-5, clang, even gcc-snapshot still
>   default to non-PIE.

The intention is that gcc-6 will be the only gcc version in stretch.

> * on most first-class (release) architectures: amd64 arm64 armel armhf i386
>   mips mipsel mips64el ppc64el s390x.  This leaves out powerpc.
> * on none of second-class architectures: alpha hppa hurd-i386
>   kfreebsd-{amd64,i386} m68k powerpcspe ppc64 sh4 sparc64 x32
> * on none of unofficial architectures
> 
> Points 2-4 mean you need to bear with extra joy of supporting both variants
> on different archs.

As maintainer of an average package, it shouldn't make any difference 
for you.

In these special cases where it does, you might often already pass 
-fno-pie on all architectures now.

> So while indeed the current wording of the policy is wrong, the reality is
> currently... complicated.
>...

The "must not be compiled with the `-fPIC' flag" unless there is an 
exceptional case is still true.

So only a slight update in the wording is required regarding PIE.

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: Porter roll call for Debian Stretch

[Adrian Bunk]

[ adding debian-powerpc ]

On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> Niels Thykier  schrieb:
> > If I am to support powerpc as a realease architecture for Stretch, I
> > need to know that there are *active* porters behind it committed to
> > keeping it in the working.  People who would definitely catch such
> > issues long before the release.  People who file bugs / submit patches etc.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> a powerpc-specific build failure of mariadb in stable. The maintainer
> said he can't work on it, so if anyone considers himself/herself a
> powerpc porter, this is something to look it.

Can you give a hint what exactly should be looked at?

The bug did not make it clear that there is any problem left at all when 
I looked at it recently.

The last message was closing the bug.

There was a control command reopening the bug without giving any 
rationale, but the last control command was
  fixed 832931 10.0.27-1

buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]

If there is a problem left somewhere it is well-hidden, and not visible 
immediately when looking at the bug - I thought this was already resolved.

> Cheers,
> Moritz

cu
Adrian

[1] https://buildd.debian.org/status/package.php?p=mariadb-10.0=jessie

-- 

   "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: Porter roll call for Debian Stretch

[Adrian Bunk]

On Sun, Oct 09, 2016 at 11:13:21PM +0100, Adam D. Barratt wrote:
> On Sun, 2016-10-09 at 21:12 +0300, Adrian Bunk wrote:
> > [ adding debian-powerpc ]
> > 
> > On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> > > Niels Thykier <ni...@thykier.net> schrieb:
> > > > If I am to support powerpc as a realease architecture for Stretch, I
> > > > need to know that there are *active* porters behind it committed to
> > > > keeping it in the working.  People who would definitely catch such
> > > > issues long before the release.  People who file bugs / submit patches 
> > > > etc.
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> > > a powerpc-specific build failure of mariadb in stable. The maintainer
> > > said he can't work on it, so if anyone considers himself/herself a
> > > powerpc porter, this is something to look it.
> > 
> > Can you give a hint what exactly should be looked at?
> 
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.0=powerpc=10.0.27-0%2Bdeb8u1=1473621159
> 
> > The bug did not make it clear that there is any problem left at all when 
> > I looked at it recently.
> > 
> > The last message was closing the bug.
> > 
> > There was a control command reopening the bug without giving any 
> > rationale, but the last control command was
> >   fixed 832931 10.0.27-1
> 
> For unstable, yes. The stable package is still broken.

Thanks.

When skimming through that the bug I thought it was fixed in 
upstream 10.0.27, and no comment in the bug indicated otherwise.

As (pretty passive) reader of debian-powerpc, I am also puzzled by the 
fact that I cannot recall #832931 ever being mentioned there.

An email to the bug and the mailing list of the port stating that there 
is a problem, and what is known about it, can be really helpful for 
getting such a bug resolved.


> > buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]
> 
> That's an artefact of how builds for suites with "overlays" (i.e. pu /
> tpu) are displayed. If one actually looks at the archive:
> 
> mariadb-client-10.0 | 10.0.25-0+deb8u1 | stable | powerpc
> mariadb-client-10.0 | 10.0.27-0+deb8u1 | stable | amd64, arm64, armel, 
> armhf, i386, mips, mipsel, ppc64el, s390x

Ouch.

I thought the information in the version tracking was wrong
when buildd.d.o showed green.


> Regards,
> 
> Adam

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: [buildd] unexpected FTBFS on amd64 buildd «binet»

[Adrian Bunk]

On Sun, Oct 16, 2016 at 02:14:47PM +, lumin wrote:
> Hi there,
> 
> I encountered an unexpected FTBFS on amd64 that I can't repro.[1]
> And I'd like to ask the list before fixing it by e.g. an binary
> only upload.
> 
> My package lua-torch-torch7/experimental fails[2] to build from
> source because of an "illegal instruction" error at the debhelper
> auto test stage. However from that buildlog I can't tell which
> program to blame -- luajit or lua-torch-torch7.
> 
> The upstream code indeed contains instruction specific stuff but
> I have never encountered such failure on amd64 architecture.
> Besides, I tested this package with debomatic-amd64[3] and the
> result is quite healthy.
> 
> So I have trouble allocating where the source of problem is.
> 
> Cosmic ray?

No, bug in your package:

  -DUSE_AVX -msse4.2 -DUSE_SSE4_2 -msse4.1 -DUSE_SSE4_1 -msse3 -DUSE_SSE3 
-msse2 -DUSE_SSE2

> My questions:
> 
>  * should we suspect the health state of that amd64 buildd
>machine «binet»?
>  * what should I do next? do a binary-only amd64 upload or
>request (and how) for a rebuild against that package?
>...

You should fix your package so that it works on the lowest supported 
hardware of each port.

Autobuilding is only a small part of the problem, your package would 
also not run on many computers that Debian does support.

That means nothing higher than SSE2 on amd64, and no SSE at all on i386.

Similar problems exist in your package on arm* regarding OMAP3/OMAP4/NEON.

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: When should we https our mirrors?

[Adrian Bunk]

On Sat, Oct 15, 2016 at 02:03:36PM -0400, Paul Tagliamonte wrote:
>...
> So, the real question:
> 
> So, when are we going to push this? If not now, what criteria need to be
> met? Why can't we https-ify the default CDN mirror today?
>...

This is actually only the server-side part of the problem,
and the discussion so far misses that there is also a
client side that needs changes.

What changes have to be done in the distribution for fully supporting
using https-only mirrors in stretch? [1]

The first thing that comes into my mind would be adding the apt https 
transport [3] to the installer, which would currently add libcurl and 
GnuTLS and more to the installer.

When the https apt transport goes from exotic to mandatory,
its footprint should be reduced.

There might be other places in the distribution that also need changes.

> Toodles,
>paultag

cu
Adrian

[1] I am not saying that Debian mirrors should become https-only.[2]
But for example a company firewall blocking all ftp and http traffic 
would be the same issue on the client side, and in the post-Snowden
world where everything is moving to https it is not even that
unlikely to see something like this happening somewhere before
the EOL of stretch in late 2020.
[2] Using https as default on the client side in stretch is something 
that might make sense, but that requires full support both on
the client side and on the server side.
[3] package apt-transport-https

-- 

   "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: [buildd] unexpected FTBFS on amd64 buildd «binet»

[Adrian Bunk]

On Mon, Oct 17, 2016 at 03:10:57AM +0100, Ben Hutchings wrote:
> On Sun, 2016-10-16 at 18:57 +0300, Adrian Bunk wrote:
> [...]
> > You should fix your package so that it works on the lowest supported 
> > hardware of each port.
> 
> Right.
> 
> > Autobuilding is only a small part of the problem, your package would 
> > also not run on many computers that Debian does support.
> > 
> > That means nothing higher than SSE2 on amd64, and no SSE at all on i386.
> [...]
> 
> On i386 we cannot even assume MMX, as the earliest 686 models don't
> have it.

That is true, but what is supported and what is not is more complicated
and depends on what exactly gcc/binutils define as "i686".

The root of the problem is that the "earliest 686 model" is the
Pentium Pro.
The Pentium Pro does not support MMX, even though many 586 CPUs do.
And much worse, what is supported by the Pentium Pro is not a subset
of what is supported by all other 686 CPUs.

MMX is supported by many 586 CPUs like the AMD K6 and the Pentium MMX, 
but it is not part of i686.

Optional in 686 but emitted by the gcc i686 is CMOV, and that is the 
reason why even some desktop and laptop CPUs released as late as 2002 [1]
will no longer be supported in stretch.

Several 686 CPUs, including all VIA C3s (even the ones with CMOV) 
and all Geodes, do not support NOPL.

Due to the OLPC laptop using Geode, binutils were upstream-patched
in 2010 (sic) to no longer emit NOPL for i686.

So what exactly gcc/binutils define as "i686" (and what will therefore 
be supported by the i386 port in stretch) does not only depend on what 
the earliest 686 CPUs supported back in 1995 - it does also depends on 
politics in 2010.

> Ben.

cu
Adrian

[1] Via C3 1.0T

-- 

   "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: Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty

[Adrian Bunk]

On Mon, Oct 17, 2016 at 10:28:53PM +0200, Eduard Bloch wrote:
> Hallo,
> * Andrew Shadura [Mon, Oct 17 2016, 08:23:19PM]:
> > Hi,
> > 
> > On 17 October 2016 at 18:57, Sruthi Chandran  wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Sruthi Chandran 
> > > X-Debbugs-CC: debian-devel@lists.debian.org
> > >
> > > * Package name: node-has-values
> > >   Version : 0.1.4
> > >   Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
> > > * URL : https://github.com/jonschlinkert/has-values
> > > * License : Expat
> > >   Programming Lang: JavaScript
> > >   Description : Returns true if any values exist, false if empty
> > 
> > Honestly, I’d like to object to packaging a 31 line script in a
> > separate package. I’d rather see a package named
> > node-jonschlinkert-modules with all modules bundled, which would
> > Provides: node-has-values, node-copy-descriptor, …
> 
> +1
> 
> Seriously, can we please keep this nodejs stuff out of the main repository?
> 
> It's not like I don't trust APT guys in finding the right bullet to deal
> with thousands of trivial packages but do we really have to care about
> the costs of all that spam littering up our namespace?

I do not think insulting language like "spam" is helpful here.

In unstable there are around 3500 packages for perl modules,
and even more for python modules.

The whole JS ecosystem still being a bit immature is a real problem,
but the number of packages itself is not a problem.

I am not a fan of all that JS stuff, but I do not see any valid basis 
for rejecting such packages in general.

> Regards,
> Eduard.

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 aewm++ 1.1.2-5.1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jan 2017 21:14:06 +0200
Source: aewm++
Binary: aewm++
Architecture: source
Version: 1.1.2-5.1
Distribution: unstable
Urgency: medium
Maintainer: Chris Boyle <c...@debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 aewm++ - minimal window manager written in C++
Closes: 636804 817289
Changes:
 aewm++ (1.1.2-5.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Remove the obsolete dh_desktop call. (Closes: #817289)
   * debian/control: Update the homepage URL. (Closes: #636804)
Checksums-Sha1:
 6932629873f07947d801759d9c9a8761216dfc4c 1689 aewm++_1.1.2-5.1.dsc
 c907d76ce82baa75cc63be708f7207a7480d584c 7271 aewm++_1.1.2-5.1.diff.gz
Checksums-Sha256:
 c49ebe4e30747709d71c456e3e4bf569605712d7168ead38f1fa76382822ca88 1689 
aewm++_1.1.2-5.1.dsc
 ed1b2b6aca027eb364213ea933a5a32279a4445c7ab37e4f483d93e2e2428db5 7271 
aewm++_1.1.2-5.1.diff.gz
Files:
 957898de68524ed2cab10d0aff7aa9cb 1689 x11 optional aewm++_1.1.2-5.1.dsc
 9e2568cb69824f1fda007bb70bb2baeb 7271 x11 optional aewm++_1.1.2-5.1.diff.gz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh5J7gACgkQiNJCh6LY
mLGHjQ/+Pe9LH+ZPexJ8ubM6Gl+MGrfA9G9X20uWe7LIjPnSy0mSF1pbFrqpScXL
BP845/x/JdoFmbRID8t2DFcSV5Xl+L5jta0kksYPqCG4njLFtdbwD4tqZG64Op/e
mQkgzGY0zW6AfgklSw/KWYjCrGuVQGB2tI3UKbKo2To8dNFjAC7qM51GELhlKroM
8tPUyn+nCXcFPwgxov976uIdaY36K9JV+uQw5fRwyQXfaVFDPnLexxEOJDNuqInp
QyRVtZlhvzNtOxfDBwddxTpJJTVzENBf7eCNMBvumoeqG+1/rn7IuNoHd54ojsfE
wOTVe23CeulD1JTtbLr5HKaHxibVOmqwmNiweHXqDWJgW2VcG5CedikCOcTHWZFo
KDzBvMPmoTOJ1stES41e2aVhXHAB5TIf5JEYPNNDcZQ+LMCxeea01z4phSoA10lD
QUGO2d4CX38l00nwiREgMbUyEme+teZb06mdRI7hFYP1TCVbgwzjbRrFfy7VBhn6
wx5k644Nw47mQa1xgvTjcpJbnsZ26GAAJpOdnUyXIb95Mi08jPswb03hhKBCoyqF
i0HOVQRFZEtUB/9qPfeGJ93s32dbC898K+5De1UrbqpkUsol80cJFSoZ+4QzXFEE
nfuu6X99H9OfarzLkDjCxuRK1vYupujVmIYEkOJak0MeTnGPm30=
=dvku
-END PGP SIGNATURE-

Accepted mylvmbackup 0.15-1.1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jan 2017 21:34:08 +0200
Source: mylvmbackup
Binary: mylvmbackup
Architecture: source
Version: 0.15-1.1
Distribution: unstable
Urgency: medium
Maintainer: Debian MySQL Maintainers <pkg-mysql-ma...@lists.alioth.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 mylvmbackup - quickly creating backups of MySQL server's data files
Closes: 789885
Changes:
 mylvmbackup (0.15-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add the missing dependency on libfile-copy-recursive-perl.
 (Closes: #789885)
Checksums-Sha1:
 193f2acc08070153e91fed2f116b9f36f2a93e63 1979 mylvmbackup_0.15-1.1.dsc
 3b7e9c2c5330f62969a39aee60af58fbf6c42032 4600 
mylvmbackup_0.15-1.1.debian.tar.xz
Checksums-Sha256:
 06dbb67447da7c64ac336172004682f62d74de3598154d828a8135cc5cdabd93 1979 
mylvmbackup_0.15-1.1.dsc
 d7b922cb3601896fbc4986a5ea5ebf6eb947acac5fa24f6923b0b2aaecd3c205 4600 
mylvmbackup_0.15-1.1.debian.tar.xz
Files:
 46ad564ea7590406e8d2ae96961e8901 1979 misc extra mylvmbackup_0.15-1.1.dsc
 fe78d5960021473ef6fc2d9607e63655 4600 misc extra 
mylvmbackup_0.15-1.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh5LCIACgkQiNJCh6LY
mLELUQ/+N9V9HVyEpJ9pzevqqnl2NOBKnIRsPBNxhe7rxfz1RUngybLgvXL4qs2P
V28zgwIMeQ2qA4CuTwYKr64EGS84oAV6MZTn2aLpFn+SUFVIt4v2PRfpo+f6eudy
DHTM9n7ZKU2deifxUMR7VCpUJ06eQSd5abZeOhyEykoKPyK+1TYuIP3C9cbhYDMp
Kuv/UTkZtnkobbnvbworz1ygIn1fW6X7E3OH70dgCYcEsG3a0awcPSmaC+M2ShYn
mgbTv3hGB11EgYlCz4ADu39SW39AD3lJe7XHZnkoX3guTK5YWuk1tZnL3dJ5LWix
cYsjzOdhssTjxCCOvwY7dgiCH8xC/9oUMlPJkv4p2A7Gpg9SDk4f11gNVwVzCVZQ
FMkUeT3/MHukePYBrIzrobNHY+Jm2lGvTX6fSNVztVSN0j81ZmXrpJEQf54K+U8T
q6yFPSFHEKsyTwm2wGwxuhXWbD+6JzNDlypQmbILMiQBmf4KvJV6ud4nj9dnP/UH
uo9FSIPDHBRqoQiQlSLVFdR/F5H6Bawmyq0rG/MmVjhL2i3y+1TmNYeVtdppMAeQ
uSIpJaMRS4mz2vhLzSE0RiMvMQ0i5iS8SCEIUJKGj0uSiavZqloIwl1vPlkC+U9M
mUbYIf4dYFwaqWaQgwFv8SoU3QCnYazcs+oIZCL0ot3jJq9XQI8=
=kdGU
-END PGP SIGNATURE-

Accepted python-expyriment 0.7.0+git34-g55a4e7e-3.2 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jan 2017 21:24:35 +0200
Source: python-expyriment
Binary: python-expyriment
Architecture: source
Version: 0.7.0+git34-g55a4e7e-3.2
Distribution: unstable
Urgency: medium
Maintainer: Oliver Lindemann <oliver.lindem...@uni-potsdam.de>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 python-expyriment - Python library for cognitive and neuroscientific 
experiments
Closes: 830381
Changes:
 python-expyriment (0.7.0+git34-g55a4e7e-3.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add the missing build dependency on texlive-generic-extra.
 (Closes: #830381)
Checksums-Sha1:
 f40f8363b9a08d6a6da681b6c42298fe7500a008 2289 
python-expyriment_0.7.0+git34-g55a4e7e-3.2.dsc
 b18e73405f104a10c489bf56e29824ef10cee53b 3900 
python-expyriment_0.7.0+git34-g55a4e7e-3.2.debian.tar.xz
Checksums-Sha256:
 4f6fcc4ab8d61bf13fe76013555ad99d4ca6b692ca86130bb7edb0dac4745b78 2289 
python-expyriment_0.7.0+git34-g55a4e7e-3.2.dsc
 5ad4e114a24338ec0d73181f11bcc71fcd10c068fa27ef4b3a85c467356b97cb 3900 
python-expyriment_0.7.0+git34-g55a4e7e-3.2.debian.tar.xz
Files:
 754d3770a021944cf4ec6b86237f58b3 2289 science optional 
python-expyriment_0.7.0+git34-g55a4e7e-3.2.dsc
 08a357a07ac77386b25e770be809c2b4 3900 science optional 
python-expyriment_0.7.0+git34-g55a4e7e-3.2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh5KdsACgkQiNJCh6LY
mLGgMg//bY6l1hwZTl0pAT+nR6Imu9NILNVS6YDMmDPW18ojM+gkEXsgkfGP8L75
KrLrnlQDzXmT+CKUIGp/cF8pvbnOfJY7X4dFpX30x4elnJhW+tzPYDmOW5RwYWvO
axgIXIBgdMnKshfcNyHIhjlnSmtz+v9RcOC3K28sZv3Pf3F7W/FKkPUGjRqsRJYQ
3oL9Wr67NtmZc+VgjDb+8U0544lpcQqOYU7yrnCczWGNFapacMkUnxYT3LD2ZFJT
RtqrQdFiF3Nh19TkNwiK+En0UeDju3x7Suec8/GQFDUgXu5YBS6NbfrXG83++pJm
zAKqZg2TpeWIAvr7kz+KvCFE2NANPo7yba+sibNte9T/DWaipibWOpdyDFQpXSt+
XDUnw8LCZ9HoZ4RJ1YZUi1K4aY1COV4e1tcn+wjgSg1YGR7qwft5cS9nXavd+Pan
n2yPfwU7gJ/wy6hxhSWmSx/cSFu8e9zezLV0KGESVXWTqQE5JwHw3g0/SYAAVbfU
Ffh5649V+ykeANAnp8GBolhchQArwfCpdrghLjIUkfFrgmkKA3IssSxSRIBUh4Jy
Uz32B6qqiaKhONVV7SrSZ1dHap1IQgbD1JpqPqJYuuTOV2NJ/zxfm8W+hfL/HQED
SIY7FgkZAnedWOj7oO11/ZynIKrqDixfjCnVKk/qQqgGtK82O7c=
=V8z8
-END PGP SIGNATURE-

Accepted libdigidoc 3.10.1.1208+ds1-2.1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jan 2017 20:53:25 +0200
Source: libdigidoc
Binary: libdigidoc-common libdigidoc2 libdigidoc-tools libdigidoc-dev 
libdigidoc-doc
Architecture: source
Version: 3.10.1.1208+ds1-2.1
Distribution: unstable
Urgency: medium
Maintainer: Andrew Shadura <andre...@debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 libdigidoc-common - DigiDoc digital signature library common files
 libdigidoc-dev - DigiDoc digital signature development files
 libdigidoc-doc - DigiDoc digital signature library documentation
 libdigidoc-tools - DigiDoc digital signature library tools
 libdigidoc2 - DigiDoc digital signature library
Closes: 828391 851204
Changes:
 libdigidoc (3.10.1.1208+ds1-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix FTBFS by using OpenSSL 1.0.2. (Closes: #828391)
   * Drop the uninstallable libdigidoc-dbg package,
 it was replaced by libdigidoc-dbgsym. (Closes: #851204)
Checksums-Sha1:
 de37e6638e874b823d4ad8349988742573c72838 2124 
libdigidoc_3.10.1.1208+ds1-2.1.dsc
 0e3c033fd282f7577b42aa5524dc943560fbb894 3856 
libdigidoc_3.10.1.1208+ds1-2.1.debian.tar.xz
Checksums-Sha256:
 95a5f62e57b7bda21f6d844c854f38d74bdf1da510eb0961eaf321987fbccc46 2124 
libdigidoc_3.10.1.1208+ds1-2.1.dsc
 e24215773ab141ec63843c54352313e486372b1242a93ccfd25f511966be3e8c 3856 
libdigidoc_3.10.1.1208+ds1-2.1.debian.tar.xz
Files:
 89710c76a9f285b0bd2d2e0a9b2f1a8d 2124 libs extra 
libdigidoc_3.10.1.1208+ds1-2.1.dsc
 8f7a01bc4229005c668549f87615f8ed 3856 libs extra 
libdigidoc_3.10.1.1208+ds1-2.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh5IyAACgkQiNJCh6LY
mLGKYRAAn6y5fktQbJpejHDSUOQbu0iJp3QnJi04y7MQjih520gRF0JBId7SIOYy
JobZZGKXK3Zam6h6s/YNFMHvCzcO4iBUL5yr9VLXRwW1Z8sVk4hN2qLIgQj2K3ly
7HdutnSw6IP6MHwWqmu91o9H5ZkNHc5lO4wtkUaMin+MrsVKdReqE2eFAM+gzLuC
awsRdLVOTjrLFv8AffxhR6/MX9iOiqXcuxLA0dH6Y8d0jRstW8i3HtuRekhz4pRw
T/ZELerf3bnB58mOl/bIyx93uU84xhWtbOWLE6lBJmtjopN6tGxwTEGsueW1JoXv
yQ5yf7pfeAqp2QfvFJlaf+UgCViJPqNbsqpHbZY4q+vs7gqHRLasCIALHyBSuq5L
jH3dGKAlDrXfLK26M6L5ZKIJ/3Nos7N4yMBqVVXZ2oXtY1fGKvExmBoQhh3CaCQx
+JUqvpFYEMeN5CNGQ3fUm/EBjxep39WH/yoc4b8UHspuzWN05gN56KDDQQR8VbxD
h5U1YOePKMX3II8UP0MA14KPNs9fs56XnVRkpVBx1/w4x2zz2nUW9i9zBIoPTnLx
LwqqilqCAcMb0NpQj1xtXhhZQypL+HDo+WjrG0/bWZMjGq8paBd29qV1HX3NR7HL
o8AUxVXKJO1o4LmBT2L89+D1KmmnGm86ycA/PCF26abYpexhmtw=
=LB1Q
-END PGP SIGNATURE-

Accepted gdb-msp430 7.2a~mspgcc-20111205-3.1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jan 2017 22:08:56 +0200
Source: gdb-msp430
Binary: gdb-msp430
Architecture: source
Version: 7.2a~mspgcc-20111205-3.1
Distribution: unstable
Urgency: medium
Maintainer: Luca Bruno <lu...@debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 gdb-msp430 - The GNU debugger for MSP430
Closes: 777867
Changes:
 gdb-msp430 (7.2a~mspgcc-20111205-3.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Configure with --disable-werror to fix building with
 recent gcc versions. (Closes: #777867)
Checksums-Sha1:
 3846b6dbe01f0c7282d33d635ecff4d17d60a4a2 2043 
gdb-msp430_7.2a~mspgcc-20111205-3.1.dsc
 908534546ddccaaa5f5868ee9e0ce816c2603f48 6224 
gdb-msp430_7.2a~mspgcc-20111205-3.1.debian.tar.xz
Checksums-Sha256:
 2ecfc6d3f5b17c51a188fa802a6d920479bd7b6ea089e980d06830d9f0df5807 2043 
gdb-msp430_7.2a~mspgcc-20111205-3.1.dsc
 0b80587f25761145c0cf02a6882bfc82cf3646f4731382fcc9172f5c58671a1b 6224 
gdb-msp430_7.2a~mspgcc-20111205-3.1.debian.tar.xz
Files:
 3d3f0686f47067605805a87b26375ea3 2043 devel extra 
gdb-msp430_7.2a~mspgcc-20111205-3.1.dsc
 d04c3f965878ad7a348a8e72fda4dedd 6224 devel extra 
gdb-msp430_7.2a~mspgcc-20111205-3.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh5NcYACgkQiNJCh6LY
mLHCpA//Zye7zeBOeJjpkOU8RvIIC2sQX/NFbhKwcrKlwDZhWmtY9SQGJDpUEja4
UUrRtsxz+RbtlPiwDa8xxOPdnwpMS4hWF0LbHR9+W9x9+Qs+CurvJ0q57aSDLQkk
WbeA9cwWb+6hSKc8htQHnhCfKbXH1W3RPytKT853u/DtdiAMepLLgMwxhHXiLNuK
JKMShj1Wje6exeiKizT3R4CztG7DBUp2dCW1Ray2S12TLWzIRjf+Y41u9XW+y7b8
kAVJkY+GW7AlUB+lPHil7ujozNiVJta5fTLmAT6k57PYOh7lrQjljtHEzrD0bV8p
/wi/D7ruGSAgKvKPVLrjmOlPJL4otpxtb+zxHGcqNROE9aTJoP02R69s7r1laYZs
vRrh7Q3NBTuiv8szMaE6TmJUlm9hbiwyRlHpMFM4OrMlVj2D4cPp4kJRvnYCAVyq
l6gefMvsZlfOOzzyzhCs4VG8ui0QwYqL40JPbmH2cI2IbimBt94B3rQjaZuB1Rnu
8+AWxmeBwhFkL1PdENzBw8H0EcmoGOHipJ2cHfA1LxZwIGew13YUxrAR5CAZjuo2
aevvlP5YAtNAcITxDgMi+mQVwWp2XBLt0i68hSunZa67eALkZ7T6SewtD55mBNNd
LgqpBt0h2Enhe8JCQ6Ze2qOcx3wo76mZfPPA1E7jGxGeLPue1Do=
=Xo0g
-END PGP SIGNATURE-

Accepted khmerconverter 1.4-1.2 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jan 2017 21:45:15 +0200
Source: khmerconverter
Binary: khmerconverter
Architecture: source
Version: 1.4-1.2
Distribution: unstable
Urgency: medium
Maintainer: Soputtra San <eke...@gmail.com>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 khmerconverter - converts between legacy Khmer encodings and Unicode
Closes: 817298
Changes:
 khmerconverter (1.4-1.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Remove the obsolete dh_desktop call. (Closes: #817298)
Checksums-Sha1:
 d5f5592734df46ece7f9bfba2be765e510adec43 1776 khmerconverter_1.4-1.2.dsc
 445c8291cac3013df9fb1e2cfee6a4e8757371d1 3811 khmerconverter_1.4-1.2.diff.gz
Checksums-Sha256:
 25229cb9501c4ca26cf9434fe6b08b9d5a00dbb3fa05cfc48cca99a3d85c559b 1776 
khmerconverter_1.4-1.2.dsc
 43a771dc9fb053b804896d6650fcccdc3c21da55ba8f852bb9550cc510f7e766 3811 
khmerconverter_1.4-1.2.diff.gz
Files:
 3a59fece80df982d71aaedf9c11dfb4b 1776 text optional khmerconverter_1.4-1.2.dsc
 f73ccae6bd291235bf71a70f10a5cea1 3811 text optional 
khmerconverter_1.4-1.2.diff.gz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh5Lq0ACgkQiNJCh6LY
mLFLvA/8CrOdzUza5dLEBGSVPIYCdtTbJkSj0xizwbdIZPKoM6W4zCvwmFo/hMy2
eUAj1r3aCojpM4FvFMoggto5z9kZq2gitHYqZGJRtPRa5sDNqvXpMHOuxHRup/ck
eoE0lkJXkUaQ5hLWM01UQY76R5UUqgeRL6BaNs4wIwHnMW4jHiGm5YW6vTm+YJKB
endYnrI76viN/P0GBKdtFFVxECbko+y6QoyfzS8TWpRTODXgCIRxdgL9wwJEsHxE
VI4B6XGckSBB4V98gnhsJu95g2XQ3cUbWn24qX9dIHuKtLvAKhFFM0WBXk4Ao3CP
/YTd9/QHhymgvfPQF8MsutwGHL1K0qEcnlMw5y69tQytHofySVkom5U6S1LxhRff
Pqr6aIbGuaSGy3FPcxgnHLKFME8ItVsuEN2CsrN4X7qQiLkJqB/4MMkw6CkeqcDB
EnS9XPeFItPLgNJEf2R2IvlffYkleRlcEhqe4SXKh5ap0SGCltlr/KDhjTIDUj43
zJSlCcLBAN+bZL2rqVrxSWeZK0GsqXgFLN2uQBSp/VhQDTcH1sqGW2teYI96q6EK
ry3I+9pzsrel6SwxVz9DM4ixj5w4sC5xjGGZYGWfrKlCW+PEerBNp3lohxXhnKj0
g7J7XjkrpjuNYv9VGSmmwCcAJVQYn/sisBky/zyL5w0xga0nIXY=
=+VJ8
-END PGP SIGNATURE-

Accepted cvc3 2.4.1-5.1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jan 2017 18:58:49 +0200
Source: cvc3
Binary: cvc3 libcvc3-5 libcvc3-dev libcvc3-5-java libcvc3-5-jni cvc3-el
Architecture: source
Version: 2.4.1-5.1
Distribution: unstable
Urgency: medium
Maintainer: Morgan Deters <mdet...@morgandeters.com>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 cvc3   - Automatic theorem prover for SMT problems
 cvc3-el- Emacs mode for CVC3
 libcvc3-5  - Automatic theorem prover library for SMT problems
 libcvc3-5-java - Java bindings for CVC3 (bytecode library)
 libcvc3-5-jni - Java bindings for CVC3 (native library)
 libcvc3-dev - Automatic theorem prover library for SMT problems (development fi
Closes: 811823
Changes:
 cvc3 (2.4.1-5.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Use -std=gnu++98 to fix the build with gcc 6. (Closes: #811823)
Checksums-Sha1:
 247510dd6c06f1a279806e48ef734269131c93aa 2046 cvc3_2.4.1-5.1.dsc
 72868f65998e420f630ea880096e4a6ff2922e9b 10208 cvc3_2.4.1-5.1.debian.tar.xz
Checksums-Sha256:
 c6cb0fd23694694c7dd9b294c609a8da1180c72633817c3e77e4df4d96e8c4a2 2046 
cvc3_2.4.1-5.1.dsc
 b88085b8cf081ec2da326c403e34b5f3a076e36caa3d7a971595e1350684b993 10208 
cvc3_2.4.1-5.1.debian.tar.xz
Files:
 db95ea8fe44d85713e3d64ac5f7b48c6 2046 math extra cvc3_2.4.1-5.1.dsc
 db968c061f2adbb6bf1817e65b471c8f 10208 math extra cvc3_2.4.1-5.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh5ChsACgkQiNJCh6LY
mLFiRQ//cTysfIn2VW+LRAPaCwDmwPbKlgSJLlb+NnNwMB89TT0E6hGAorYcBIVQ
za/KhDdF9BJXYCFcLjngMC6RiU2uOKxeomtc4iXMBvVjAkTsAGQpMcnQ0ZzNDqJZ
ipNXEvgWwu5r2rZy4ewqobSum2k8QaZoeOUhZA8tKMKIn7Hz8EY+kXghvsy7Pmwx
q58673Aj09OFjjufJVxMhfIn5f64IJFkf7rumxhIWhCArIe/8wAk75m0K3GzOTk5
eRL1yL0/pkMe9Il2oISXtGp21WVmtZOEA9gdwuYVcoAjyBWrDEbvi2v0fMrTKKSk
FPl1HaNoOkInjCwhhURQ5mkh+19QVStVa0S3afOWm3qe2hSLAzD17g7KmoE993xp
YiAHlb0s+ctSWnsRyTmEqzKz8dmNqR5f8lHX+eBx0kVJlQXFuST3858sLlh9FxHj
7Kdfec12R8h83ZhI0s5HA21YxXjoGo4W3B5HvoA1evzH013tZc2aLP66wKFk04n6
YFi73yECYyBH2aKFBEHwOMd4lb5qnW6hq0mMdJ9B6r1SRjjBql937Cu3VJLjuFFx
aJ/cP4ymiybAr3L5KwygxDlV/UMzpVSk4h6tW/nMoGyS5lgQiHqf2ZCArz3ydM9s
Xj3CnsRggHLoRVgICuYYjUyglO5RUUpmN/lyYG8bkxabeBZd+QY=
=otAx
-END PGP SIGNATURE-

Accepted isakmpd 20041012-7.4 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jan 2017 20:45:19 +0200
Source: isakmpd
Binary: isakmpd
Architecture: source
Version: 20041012-7.4
Distribution: unstable
Urgency: medium
Maintainer: Jochen Friedrich <joc...@scram.de>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 isakmpd- The Internet Key Exchange protocol openbsd implementation
Closes: 828355
Changes:
 isakmpd (20041012-7.4) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix FTBFS by using OpenSSL 1.0.2. (Closes: #828355)
Checksums-Sha1:
 817101410ef5112eeb667840957c970b660c2c04 1777 isakmpd_20041012-7.4.dsc
 036366f4cb6959498f332e53403807241f78a530 31556 
isakmpd_20041012-7.4.debian.tar.xz
Checksums-Sha256:
 1c22637ed5e85e6dfd89c5bf34f2655c393812b00550e84bc2c9708d389da4d4 1777 
isakmpd_20041012-7.4.dsc
 993bac9a8b336cb32e7d757e8e988fd13da072bcb7b9139f536a150b29dd86c4 31556 
isakmpd_20041012-7.4.debian.tar.xz
Files:
 e2cdb653186402175b9afed3b6e9929b 1777 net optional isakmpd_20041012-7.4.dsc
 161a5da05009aada22b263a9497aebc8 31556 net optional 
isakmpd_20041012-7.4.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh5IJkACgkQiNJCh6LY
mLELbRAArJHKfOgqspXNFkG9XoFu5mfNJ5IObXfioCOFr2FzIwHUoYW0hYzeI+m7
V8ZOzXWkvbHzn6sBKmDxrwDL83r3+DGctMGbCmDuFsNO75UZKnIWHoesVAK5irMt
dxG3zpP9TTQlM9ROHhzxFDC3I4ErgbzuyIrSQyLxMCenuqAcQU9dTgvdAsWb8GI2
pmxIchUhYSx3kcX95H0fY2sFnxJp9JLhq2JsKARg4usxJHn6MLZwABNN47T0cdMp
eTwRSc7FcAtMKscydt+QNx2qf5I886SXwzGUzZJl2qZyKkwY4SnahCCYAYF29lxu
p8EPa9aCTTBkG7f2Y35wWOU94fSsyyHkBDJnH2G61JumWiQI/nrvOwK+b0+tDImF
Wa/JYge6vIzgkXU2tP+q7WyVhL2zJOU7JO+RNe9DsrclXO5pVqsh+ZPL2s/HVSRA
Wm6ltNuncLe+hqR7kv3/lVW4lVjb8u8WSlpOGPytmUwzsHA+gFNaob4ly72/ltwi
YEkbcFrvCVhqMrvsc5yQsSiPA6BUHg0Jw+fWhYbpTbeVk9SF8Ma95Fzy/ocLVP5l
FNyes/x44Xa1TfeAAjt9FPjhOygA3zGHo2anWX3Kuf0Y0sh1EMuCohscKltNytic
kS074FttAZV6+aQA6FAlvIdrbdkD7AZePzuc7vpjMKFoWSizsbE=
=pH06
-END PGP SIGNATURE-

Accepted freewheeling 0.6-2.1 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jan 2017 19:29:50 +0200
Source: freewheeling
Binary: freewheeling
Architecture: source
Version: 0.6-2.1
Distribution: unstable
Urgency: medium
Maintainer: Paul Brossier <p...@debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 freewheeling - live looping musical instrument
Closes: 831163
Changes:
 freewheeling (0.6-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Use -std=gnu++98 to fix the build with gcc 6. (Closes: #831163)
Checksums-Sha1:
 16c279d68efddf11bff07a4ce33b997ed9853009 1957 freewheeling_0.6-2.1.dsc
 ed1f742f91d920dc2443cad2983e9ba96d0a082b 64520 
freewheeling_0.6-2.1.debian.tar.xz
Checksums-Sha256:
 4dc2c50b3c490869cb57767a5a66acd749f526859d16d7bbc50d56a329e1d5b0 1957 
freewheeling_0.6-2.1.dsc
 71b255dc735a88008e8c45ab5f129e36818c22a24d5a63da5747af52c23009ce 64520 
freewheeling_0.6-2.1.debian.tar.xz
Files:
 cb44aaed1ed8891ea7b871925912b081 1957 sound optional freewheeling_0.6-2.1.dsc
 897727eb7a60f7ee9d7f2dce596df3cd 64520 sound optional 
freewheeling_0.6-2.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh5D0IACgkQiNJCh6LY
mLHlZg//XNo2OdLmfg3t5qtJNmc4WGCdM7DmjlsVJuP5VWzY3yYsztJ7/unM/d+2
SqZRmA7ioTIZ13C9M1todp6mSaBdmNAZOmLAVmT9qg8vDcuIumTRhyejE7pSlIKO
UNltYrCn+lGuPiu2+eSsR0Yyvltny2SC6czKn2bEv47A0rlSFAajDwwATuWL+FLy
iEXOIpDf/d94HbtjMUfQ+j38TMjVdoq05TrNGifcTE+BVNuc/5vaToKg3rse4AMK
z154sRBEQM/5RY3up5HZhKk54nu8NTrx+0sGhoB9QdBPD0oiZDLrTRT7qnfGuuzY
n0XIETr7/o8Gsbz8h0yND7cKRoxGSrcKt9NovtSNsKUAi8wUMh0CoYcu53id3yGo
TfCU3HrmJNltHfa8zSZCsxkSlUo3Rk6/0MjHtZE583fLPCTgq22yw/FTGOav9y2w
TAhXz9loPkmpWgLotp5RLApyl8plV5VvMsGwHN0nZ+3d3v9+LihTBRW+Fa4spvRJ
lu25C30aUQIniRZOrd9JOuJ53ey38QNTKbSo9jyDY/3cXE4n9jZVy81VUL5K0wW2
ElYYoGDLSMBJ80UBnsMESnDq7ajfaBw73oG6BeUz9t0U/q0mGfYspGsM6cN1EYbW
AgEttBLuVjmGN41ggKkEcuCgl1MKvWSnfRtpQqXwGpnmx4EV6Zs=
=1jM/
-END PGP SIGNATURE-

Accepted pidgin-openfetion 0.3-2 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jan 2017 19:27:12 +0200
Source: pidgin-openfetion
Binary: pidgin-openfetion
Architecture: source
Version: 0.3-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 pidgin-openfetion - Fetion protocol plugin for libpurple
Closes: 828502
Changes:
 pidgin-openfetion (0.3-2) unstable; urgency=medium
 .
   * QA upload.
   * Set maintainer to Debian QA Group. (see #795695)
   * Fix FTBFS by using OpenSSL 1.0.2. (Closes: #828502)
Checksums-Sha1:
 092e0221229566965798eb8d8c9dbbf58e64ad27 1848 pidgin-openfetion_0.3-2.dsc
 a880760bfa658d70b5e1dff209069f8e01605271 2124 
pidgin-openfetion_0.3-2.debian.tar.xz
Checksums-Sha256:
 88abfb89ab48cc47ae4e76b9bc203b7b7ab52d8cb2a6b4f0a4d71aff4459339d 1848 
pidgin-openfetion_0.3-2.dsc
 9bd4a832ff180ad0247f9d1c50eef31901af73c923e4b109295f2d712c1c91ba 2124 
pidgin-openfetion_0.3-2.debian.tar.xz
Files:
 7c16e0c64f8946ef966df801edbe0286 1848 net optional pidgin-openfetion_0.3-2.dsc
 421ab7e51cd29fc8ab11e009cb44eb99 2124 net optional 
pidgin-openfetion_0.3-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh5DxsACgkQiNJCh6LY
mLGLkg//RsMHird+ZC7o+uyuo7odun9fMF0tcDw4+eIbyGkaR5BmD7mCdkBLsnVE
Qlf3NJM9Gd96GOMRct3p+cIVaQpszZ87qqD5yO0JZv2zCxiEYg3RzJXqtQ/EStGv
GDUmeiNDb0L4UQ7YVuOsl0j+E5ERMzu5CjZCWE1WoUSWuRcOfFM6Eo9g+ZeB3vBQ
4V0eSG/NKQ2uCgsE/RwG7TzgzNm9dawgUFLQMk/wjiWIi7z4miFFUTMPU0K5O740
L+zUzN9FAI9a81WixD8C1XKm5qJ4ZSMiBiF1MtFA8pVjtLMRjgSzKy5Fs03pohZM
Eux38vJpLMKPBN9FtcC246AboRY/7V8iYtfiJ9n0GW4HizuheG+ig7vZkeApDf0d
fDxrANk3SAB7x7wNhF+mDsM9Xy3W/3gs40ZmPnULDIsupkEyDXErZTOD/1Glo/U1
wfh1nERrujYTiZPVExo++lvzuUVXnHx41aP1yLd9TQ9XCEBxVB9TB+k4bIcj77R1
wt3QBNm7qeVIx8iCDeC19YpnVhdYBPHtzi/js9Qc97CM7fMWpO60BIWouMS4MleE
/88MFn94cci+EGZB91VQzZmqxqkmdUHrWZIdbmqZfcLWUwEnzWpuE70EwH6MPzr0
bzekH9xme0Eq8LmiRnYpTnkGI4XfwDJXEUO9Nr4o3MXVVVJaoF8=
=NvYr
-END PGP SIGNATURE-

Accepted free42-nologo 1.4.77-1.2 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jan 2017 20:12:15 +0200
Source: free42-nologo
Binary: free42-nologo
Architecture: source
Version: 1.4.77-1.2
Distribution: unstable
Urgency: medium
Maintainer: Christian Stalp <ch...@chrishell.de>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 free42-nologo - Free42 is a re-implementation of the HP-42S calculator
Closes: 811760
Changes:
 free42-nologo (1.4.77-1.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Use -std=gnu++98 to fix the build with gcc 6. (Closes: #811760)
Checksums-Sha1:
 0bb106a4bd566ef7dd9321d22836d3cc159e5fb3 1843 free42-nologo_1.4.77-1.2.dsc
 479a89c22b9a0a96307949d0814b9d601620227a 4320 
free42-nologo_1.4.77-1.2.debian.tar.xz
Checksums-Sha256:
 706c3cba8b6db19dcb0ea62a3fd9614c20bd1f989f1cfbc861a83dda2e38fd8d 1843 
free42-nologo_1.4.77-1.2.dsc
 6828065520d1b97ad046790aad1d213f26918ca2de15ef0dae15354b2c484faf 4320 
free42-nologo_1.4.77-1.2.debian.tar.xz
Files:
 4f0282a24f4107859c3377cfdb7e3f93 1843 science optional 
free42-nologo_1.4.77-1.2.dsc
 f9ae7d398dc1c82fa44a44eb0045fae3 4320 science optional 
free42-nologo_1.4.77-1.2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlh5GVMACgkQiNJCh6LY
mLElcBAAqFaD+/tJ0Xu1dAohkdtJ8QhxVzs7dWttDHg1e4xfiErbSANwi+c5kYi9
zTgyhaNcupWUHNrpnzdeZvgK8551uhmbT4ZbVNakR0TFTGg5S2OzHnQz79fGe3TB
Dudv+3P6RfAPI+E4gqVbqAdhtHZfeUVqJFHOy9jweQWxOtdWDcV49KTQzX9ycRZR
/GTEEqG8zLQ5Q+VsL6J+E338mx6Tid1cJiEihUXTrI99j6sZDb1ShJIm7Raijw2K
hl3noxvlL7uTE+CU8/dvP3aUYsCatfUFZUlg903qudlmV9rWYkK0FPbUTEWGgNBY
gOKXXP67RLK/LNX1KOzW6zO+wo5J5ifcV+FX8P4HePVOXXwwErjWSED6s7+ozR7Y
5wJ00Dmn584YLlAIOXDgcSK+KOKdNFeC3sIWft6Dp9Q5YUOI6hdFnSijakkndZU/
aQ7P9TJJkP5wbAbZP7tAgr8JchirKpbYW6SjmMmJx8Of7QHzVxLaWBFpu9+Z5DL7
cqolK6vqYmuN7ReFc8oyUyiwYOQawvqmECnpJLRCUZ/ARuqdSkrsnG3AoV6CIZEo
o4sL5Rivk35L46iom5wlfpfbXcQFcJgzbOnwZESr+5Zu+5CSjOt6aumy6PzZrhv5
jKQYGrmuEsvqZajN3wIQ1e6W2BHk2mVFpr9YeKr+jy8YgRh1GcM=
=L+Hm
-END PGP SIGNATURE-