Accepted mysql-5.7 5.7.26-1 (source) into unstable

[Lars Tangvald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 14 Jun 2019 07:59:19 +0200
Source: mysql-5.7
Binary: libmysqlclient20 libmysqld-dev libmysqlclient-dev mysql-client-core-5.7 
mysql-client-5.7 mysql-server-core-5.7 mysql-server-5.7 mysql-server 
mysql-client mysql-testsuite mysql-testsuite-5.7 mysql-source-5.7
Architecture: source
Version: 5.7.26-1
Distribution: unstable
Urgency: high
Maintainer: Debian MySQL Maintainers 
Changed-By: Lars Tangvald 
Description:
 libmysqlclient-dev - MySQL database development files
 libmysqlclient20 - MySQL database client library
 libmysqld-dev - MySQL embedded database development files
 mysql-client - MySQL database client (metapackage depending on the latest 
versio
 mysql-client-5.7 - MySQL database client binaries
 mysql-client-core-5.7 - MySQL database core client binaries
 mysql-server - MySQL database server (metapackage depending on the latest 
versio
 mysql-server-5.7 - MySQL database server binaries and system database setup
 mysql-server-core-5.7 - MySQL database server binaries
 mysql-source-5.7 - MySQL source
 mysql-testsuite - MySQL regression tests
 mysql-testsuite-5.7 - MySQL 5.7 testsuite
Closes: 927308
Changes:
 mysql-5.7 (5.7.26-1) unstable; urgency=high (security fixes)
 .
   * Imported upstream version 5.7.26 to fix security issues:
 - 
https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html
 - CVE-2019-1559 CVE-2019-2566 CVE-2019-2581 CVE-2019-2592
 - CVE-2019-2614 CVE-2019-2627 CVE-2019-2628 CVE-2019-2632
 - CVE-2019-2683 CVE-2018-3123
 (Closes: #927308)
   * Disable unstable test xa_prepared_binlog_off for dep8
   * d/patches: Remove fix-mysqldump-test-dates
 The issue has been resolved upstream
   * d/control: Add build-dep on pkg-config to fix FTBFS
Checksums-Sha1:
 6d8c865e5301a2d626d8582301c00d046b2de64e 3241 mysql-5.7_5.7.26-1.dsc
 d92843355a8af65d45305a888eeca4a28ba90c32 51098338 mysql-5.7_5.7.26.orig.tar.gz
 77f294a36e7ca364c24414cdbeb85ba538feb8db 156212 
mysql-5.7_5.7.26-1.debian.tar.xz
Checksums-Sha256:
 b5385257f0d9e67b971289667ccbf5b8b3e7120e88e7502065f1c385a35ab1fe 3241 
mysql-5.7_5.7.26-1.dsc
 effca6d3aceebc286a9fb046257330d125cc2f4def87081c286bfc4df3d974d1 51098338 
mysql-5.7_5.7.26.orig.tar.gz
 208bc7455bf0048e791910208bc3f061baa8e110dc6209fe2446ad96b35a8158 156212 
mysql-5.7_5.7.26-1.debian.tar.xz
Files:
 2772441b03dd79dcce625e5c1306995d 3241 database optional mysql-5.7_5.7.26-1.dsc
 0fb4db48959b0e05a7dba0bbfbb4f8ca 51098338 database optional 
mysql-5.7_5.7.26.orig.tar.gz
 f39686200ad6a31b5ae70d3256c8200c 156212 database optional 
mysql-5.7_5.7.26-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJdCg/VAAoJEOVkucJ1vdUuo3gQAI5jIgvrq1km5rOUaw6x/LA8
jNs0CKzLbQW9qxFI+4lqleANPgDF9FwqENOFKr4eNUdet5cbd2UL6fMAsJFp2eys
aXrxASNMHEUSXCWFkP5ceNDus68rRpn/mAlvhQTUSAf6q7l6aMNnrhhcxK5G2eh5
X4CUN20Iu7QUrT+Ssmy3dLScsMXbVm/tGNNg7TM+ZPH5x9af73cnJlMkEiQOxxQ/
XUEJFN5SrEV008ntK3Tz3W5ILV6dlkaGlB3Q22J1K5YUiJVpYlvCQvW7a5MqJPpx
aG97cFSTtg3VWu83xpnWWABuoV7DgzlHaDXDClYw4zbUxMsl3pyRs6ioDPVM9KZj
F3guXEVQ8qzVwcswek/++1i4/syzAkQOyI32Lxsz4rA3t7d3C5crD/FXmKCfQxSk
VAciuvCP8AtDLfS1G0zV0SQjHk2AgaB1fcH8mQzyGVqBnAaG+tPwrUpeUixPZxWw
Cp7AH7hXpd0N3qJwdVnEHiAmfZMLBkReh9L2VZEwQzvH/hRXXZi1MmBAwgPz0EvX
jJ7u0EOb+w555J13/ThAOsjLeyUDVN0N1qVFNUhICJTf4siF/2b8/LJxMfd4coe1
0mIG55/2FFCrrD/zDAWFCcaPithNgIKjAAq5BTgm/RFDCxNK9Aawj45EKPzNceMt
2RvrgrIB7TdsKAWo7B2O
=osXy
-END PGP SIGNATURE-

Accepted mysql-5.7 5.7.25-1 (source) into unstable

[Lars Tangvald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 22 Jan 2019 08:03:45 +0100
Source: mysql-5.7
Binary: libmysqlclient20 libmysqld-dev libmysqlclient-dev mysql-client-core-5.7 
mysql-client-5.7 mysql-server-core-5.7 mysql-server-5.7 mysql-server 
mysql-client mysql-testsuite mysql-testsuite-5.7 mysql-source-5.7
Architecture: source
Version: 5.7.25-1
Distribution: unstable
Urgency: high
Maintainer: Debian MySQL Maintainers 
Changed-By: Lars Tangvald 
Description:
 libmysqlclient-dev - MySQL database development files
 libmysqlclient20 - MySQL database client library
 libmysqld-dev - MySQL embedded database development files
 mysql-client - MySQL database client (metapackage depending on the latest 
versio
 mysql-client-5.7 - MySQL database client binaries
 mysql-client-core-5.7 - MySQL database core client binaries
 mysql-server - MySQL database server (metapackage depending on the latest 
versio
 mysql-server-5.7 - MySQL database server binaries and system database setup
 mysql-server-core-5.7 - MySQL database server binaries
 mysql-source-5.7 - MySQL source
 mysql-testsuite - MySQL regression tests
 mysql-testsuite-5.7 - MySQL 5.7 testsuite
Closes: 919817
Changes:
 mysql-5.7 (5.7.25-1) unstable; urgency=high (security fixes)
 .
   * Imported upstream version 5.7.25 to fix security issues:
 - 
https://www.oracle.com/technetwork/security-advisory/cpujan2019-5072801.html
 - CVE-2018-0734 CVE-2019-2420 CVE-2019-2434 CVE-2019-2455
 - CVE-2019-2481 CVE-2019-2482 CVE-2019-2486 CVE-2019-2503
 - CVE-2019-2507 CVE-2019-2510 CVE-2019-2528 CVE-2019-2529
 - CVE-2019-2531 CVE-2019-2532 CVE-2019-2534 CVE-2019-2537
 (Closes: #919817)
Checksums-Sha1:
 f268bdacf122c1cee2c22b24178943c925fe39e3 3229 mysql-5.7_5.7.25-1.dsc
 cbec35bbe2f2540232105a307770c432380be352 49107578 mysql-5.7_5.7.25.orig.tar.gz
 ff3b9a8a74ce38fa89ce45794fc4770b373918ac 156756 
mysql-5.7_5.7.25-1.debian.tar.xz
Checksums-Sha256:
 23c71f834fcefd5766b130243558844d578e51858271f5f10231e19ae92bf3bd 3229 
mysql-5.7_5.7.25-1.dsc
 354c427c8679c6a4774f60723ea211e54b4383307764d240940f960d110bf5cf 49107578 
mysql-5.7_5.7.25.orig.tar.gz
 40c4d766d4c154c54982fba3e6683279fdc11bb8ca89cdcb596415645d827e94 156756 
mysql-5.7_5.7.25-1.debian.tar.xz
Files:
 7d30f684b59316b3112a58b955fc7380 3229 database optional mysql-5.7_5.7.25-1.dsc
 db53cbcc972276cec7a450b042956c57 49107578 database optional 
mysql-5.7_5.7.25.orig.tar.gz
 31fe0ce87d8e78cbbc072319179f07b2 156756 database optional 
mysql-5.7_5.7.25-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcT1+fAAoJEOVkucJ1vdUu5rwP/28rKR43o3juNnlnlfeqFoTp
rbDnvtF1ltcoEDK52PsRZp3m4W6bI3DqtMy5pYTVklwKsB2hy7CaiLije/OqDqHo
fSry/lAiOkh43VqFKYpgCBgDcMeMUVrTeZKsJI1k0WQk+NKeHPxm+r9Fz8Q6GCOg
U5tXsw+AVug7w2VJpwB4LbW3LcuZ7vH+Hd19dwtUbxVM4J1+1zCE6h48K6C0F8oW
VuHGvyH1Ltmw1zEgi9BjWBTmzvySqBO8UtKfObs3px7Xzjy3qH5pKlYUXfFOWyAg
3JHI8QNSrV+n4O7kGq8uPQ2uPNHFj8DwRElQakKvJUdTbkwnKIHgj7k/MKcYxO2P
F2W6Kn7SLixSvaQwKqCTogEi/HYLOJDyOPTVxM/GZjjv8W25KUj89YUz4wS+YU9W
FjoOhGW81GGXLnNWUMWRNk3FJM4Gm9WriNlKJ2vmWGFlwR1Utfe4Q9jfgrv2+RRM
atCfIE1VS94Vb8QFrwLztrePzcg76iV4257IDb2JRknACWGL3OMXKMpmctfoCrm6
vKv+c9yWkpdJ1z4OoEF7tomKyugETwZn+w3sbjOTCdKKsIvwB8PQOP8oHBGQthpE
ySWRbsyWt3g9lqbGB96Wv4g6dw68mAizGenpmJ1/TcLxBpCJKdDO3wjMQl1VSp7O
FM+eafOreRaZ3UcUQPvs
=MW4D
-END PGP SIGNATURE-

Accepted python-coverage-test-runner 1.13.1-2 (source all) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 18 Nov 2018 23:26:08 +0200
Source: python-coverage-test-runner
Binary: python-coverage-test-runner python3-coverage-test-runner
Architecture: source all
Version: 1.13.1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Lars Wirzenius 
Description:
 python-coverage-test-runner - fail Python program unit tests unless they test 
everything
 python3-coverage-test-runner - fail Python program unit tests unless they test 
everything
Changes:
 python-coverage-test-runner (1.13.1-2) unstable; urgency=medium
 .
   * Orphaning due to retirement.
Checksums-Sha1:
 1c47ce5a8e2e5a69c1a23ca996f344ec9c983ff2 2078 
python-coverage-test-runner_1.13.1-2.dsc
 97ce554dfa6952e9c3d588d8f6afc69d2017f819 2284 
python-coverage-test-runner_1.13.1-2.debian.tar.xz
 2cd7b59f580a2229e62782ac41c37ceaaceb8db9 6476 
python-coverage-test-runner_1.13.1-2_all.deb
 303bb4c3633b5222e4f1fb2741d86661a4affeaf 6805 
python-coverage-test-runner_1.13.1-2_amd64.buildinfo
 be4623e0f904cd3ddf45ed9e2930ded1de1c286c 6572 
python3-coverage-test-runner_1.13.1-2_all.deb
Checksums-Sha256:
 92ef4553e221fedf9b4a5e2489e102d33c56c87e47440f48af4b12edc18c9db8 2078 
python-coverage-test-runner_1.13.1-2.dsc
 626224ac1d2711e36af957d77cc73c0ce8245445d2577e22ffc2826534414a06 2284 
python-coverage-test-runner_1.13.1-2.debian.tar.xz
 5c77bd75b1c556544ab7e6986465084cb6b49513558e75e28713f80037889605 6476 
python-coverage-test-runner_1.13.1-2_all.deb
 e1c0e58fb1485f27f6c2b5438d32231d0db049c7ffa18853c71a44587cfa1c9c 6805 
python-coverage-test-runner_1.13.1-2_amd64.buildinfo
 ef81fd7c2db4c68abc2c336cc3ded4f0ad04a8ec35a923934801ef05427128a0 6572 
python3-coverage-test-runner_1.13.1-2_all.deb
Files:
 98aebed7f633dd741f677006ac08f239 2078 python optional 
python-coverage-test-runner_1.13.1-2.dsc
 d80a1b52e725561d2a61757bd85020d0 2284 python optional 
python-coverage-test-runner_1.13.1-2.debian.tar.xz
 b942dda1d1c6417bf60a897abc69dc21 6476 python optional 
python-coverage-test-runner_1.13.1-2_all.deb
 83f7fe129f457bdcb833a60be4455d94 6805 python optional 
python-coverage-test-runner_1.13.1-2_amd64.buildinfo
 98dc53bced1f509dd7210f25d27ff83b 6572 python optional 
python3-coverage-test-runner_1.13.1-2_all.deb

-BEGIN PGP SIGNATURE-

iQI/BAEBCgApFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlvx2QQLHGxpd0BsaXcu
ZmkACgkQbC+mFux6IDEaHw//Xok+bFUauyug5dVjHW59XNwCi/OSQmo1aF9CTkzW
zURMBB1ofONgzOkc4WTorsMrFHxcqUvxOCo1iPQo+GXdNgZUXQnPIvb5gRqSGzE7
VjuNlW+WWPgtYcadoqWotOpsbWyzebSe0KPLLj1IdSnBNKp5XN+r9gocAuwllsnh
IyNypgBccns3kvcEpEFrV60istqYPXtYW9Jq66letg+ypcou00WVHdlCW6PZs+iY
oi09deYtGdGl95hBFMJqUac0iyrB1655Wk/x+l/RZ4VuydrlSiCmlvbgI3zA3XJc
JMGcllE0f2yxguYhso7qlpxQbxceBRhptDzjfPS5PMJn6TiVQcDvKChN/2Pz7y0D
b+9TKLcwgZVx2gQOSJr583VJFLimCLokBse2t1JNCCmn3LUHAxm5zS282nI6hIfz
bNTHGbwVG4FL2ILHX46GZKGLYdqhe/Zcv9I+mnF7U5vw6TRSzC/GhfaMW8P4K+1p
j2nXMf9qxOZQyc+Z1tYNu61OVwUz0OzpGc8Y371KfF1j8pL5vNubEWr+qShlR2EW
zrXSgOXM3MVfpmRXTK1Ah7zdzr3sWFEZYsq18kAkejdh+L8VL6+9ASxkVq5PXypH
HsKnql2BxnXlmPVJIOXd4hxXne7NFiPCdU5LjQHjmFVhNFh4Oj1C8yVICCCUQ+Lx
b88=
=kTs7
-END PGP SIGNATURE-

Accepted python-cliapp 1.20180812.1-2 (source all) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 18 Nov 2018 23:24:43 +0200
Source: python-cliapp
Binary: python-cliapp python3-cliapp
Architecture: source all
Version: 1.20180812.1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Lars Wirzenius 
Description:
 python-cliapp - Python framework for Unix command line programs
 python3-cliapp - Python framework for Unix command line programs
Changes:
 python-cliapp (1.20180812.1-2) unstable; urgency=medium
 .
   * Orphaning package. (I'm retiring.)
Checksums-Sha1:
 ef09c2b5a3d13fd56e2fb85d062a626f40e3085a 2012 python-cliapp_1.20180812.1-2.dsc
 54252ea163f5c4e5de3c9ad956b9b8c2d73c1634 3840 
python-cliapp_1.20180812.1-2.debian.tar.xz
 f884a4338e03fd534971a172da29bf6a923397b7 42156 
python-cliapp_1.20180812.1-2_all.deb
 3b1879b73ac064053c58fd68ddd10778d49dc94b 7011 
python-cliapp_1.20180812.1-2_amd64.buildinfo
 c2e0f6f40a5ac553f4c7c3dc8e8e82dbebe58a8a 46172 
python3-cliapp_1.20180812.1-2_all.deb
Checksums-Sha256:
 196cf23bdc4936af5becef3592edbaed5bf750cbb51841befb574cdfe5dfae01 2012 
python-cliapp_1.20180812.1-2.dsc
 aa069cf1f8ca5127fbd295b02bfd53ee79541c5e98079ed1d91edc6c43eeafc1 3840 
python-cliapp_1.20180812.1-2.debian.tar.xz
 5cd4c9f2bfde8f855bac1897df98e443930d169b6a910d44391a49f3c0c8c291 42156 
python-cliapp_1.20180812.1-2_all.deb
 8131c493cca0a734822303f4798403de9344a4bfe00a5ed72b8b52194f77e915 7011 
python-cliapp_1.20180812.1-2_amd64.buildinfo
 4335397d6d5672becbd4f7e8bf83eaaccc524db53f2302b20cab32b778fa087e 46172 
python3-cliapp_1.20180812.1-2_all.deb
Files:
 b1ea69328f3c90b47749ce2be2040670 2012 python optional 
python-cliapp_1.20180812.1-2.dsc
 e8f2a278ba869bb2a77d665ff31325ee 3840 python optional 
python-cliapp_1.20180812.1-2.debian.tar.xz
 4e6cef3a24c4ad2335df3742827f50cd 42156 python optional 
python-cliapp_1.20180812.1-2_all.deb
 cbdd069e385cc70f04728ef231e3976c 7011 python optional 
python-cliapp_1.20180812.1-2_amd64.buildinfo
 543d61130412a65aa40e23ee452b4574 46172 python optional 
python3-cliapp_1.20180812.1-2_all.deb

-BEGIN PGP SIGNATURE-

iQI/BAEBCgApFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlvx2K8LHGxpd0BsaXcu
ZmkACgkQbC+mFux6IDHatQ//atccwf7fe0Go1+WdgphtWnykWDQ9WykHMPjRi4Ds
V0by4kj7EMPf+Qgvog2HagRXRyeAiJ/S/uIVtvBASbzz/f9zWwMUvTIbfSFRma5L
uGZE7FEDNRR5n5bacuWoYDo6vZxCQSOxjoyjIInXh4qfE6liuFDAnDuoRKM4FMDu
V1bNIGI7az7y3+GZMsK9wiOe1sJQ9pAfAHsZ9Jxi8z8v7jpipVoWadjvsJZMS6FU
kaToOb6OFCbKOT1qZiP+xtf14PhDVD6p+AWHHzVz9z8P25wrIBTDCMDBe5UMrRgj
Q7D6pxmDIHmKt4s++MKdLHrwllvfRv125Xm6WK3GYXqHXaNSGaeRWBEjTqOc4xqb
cJnyqHVzI5QJd/T/m8LwxmSPjzxO1P0jjUIDsAD4VUhA5s8DyCDtkKkGHI1Li4Xf
t9wEweqesxVQOSfSdQpxGDPZFhWCewlXtOXoL7SJjSIBMrOmr6s8PXGnGd11oruF
Jmgp75KR9QaTTR4qBrQn7EBsu4rw5W787tdeUtz6zYLUAusbJysL/QqRKdf4zNW1
6INrfc4P3YltnZgr3nqt3jFz3gAJ9wPeR+X+rRpLrsLRh3mpAUQR2EROhOZnGS32
XIB/D/eeS3MQUx82l18PxJRO2IzXK941WSHq8jo/DNOUt883RMfat7G9V/d/1hvP
66U=
=/ST6
-END PGP SIGNATURE-

Accepted cmdtest 0.32-2 (source all) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 18 Nov 2018 23:23:28 +0200
Source: cmdtest
Binary: cmdtest
Architecture: source all
Version: 0.32-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Lars Wirzenius 
Description:
 cmdtest- blackbox testing of Unix command line programs
Changes:
 cmdtest (0.32-2) unstable; urgency=medium
 .
   * Orphaning package, due to retirement.
Checksums-Sha1:
 93fcbee78d1a00c90a8702bd84c94a055271b005 1772 cmdtest_0.32-2.dsc
 fc91d56eba3ebaff9bc33f3dcbe0c0b845abc6b3 2336 cmdtest_0.32-2.debian.tar.xz
 01c14fe338336a1000eaa293772275239f322e3e 21632 cmdtest_0.32-2_all.deb
 494608781bc4388bdf84f5ec6969cba8aab8bf67 5902 cmdtest_0.32-2_amd64.buildinfo
Checksums-Sha256:
 34ea723cdeb223d06f6359a1dfe9663bae6b903e9dd2c45bb80b19f159440304 1772 
cmdtest_0.32-2.dsc
 761a623547cda83a8ce5226bc88c2969dd4a51c19b4c0fadfe3357a1ab194f36 2336 
cmdtest_0.32-2.debian.tar.xz
 90b7fc7737b1e96d3e06fe95686ce6526dec9c2611be3c5de02770098f20d34b 21632 
cmdtest_0.32-2_all.deb
 38756761d27ad9e6da201069cfd026e77f87b1f022e1927d919685c395828d6f 5902 
cmdtest_0.32-2_amd64.buildinfo
Files:
 92fddf1773a923464491d0b023570ae0 1772 devel optional cmdtest_0.32-2.dsc
 b0c940ea18a79b059b7ebd707d1d93b0 2336 devel optional 
cmdtest_0.32-2.debian.tar.xz
 82761524ead02fc3b77faa9791829d28 21632 devel optional cmdtest_0.32-2_all.deb
 cf93a93b8d295446949a7c94e62a074c 5902 devel optional 
cmdtest_0.32-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQI/BAEBCgApFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlvx2HALHGxpd0BsaXcu
ZmkACgkQbC+mFux6IDFxoBAAlhhX28PnD3MYRnA3+fDOieX1xGGuOXIOc6q8xeVh
ZCrvFSIb3vQy5sBKqVUX29oo9eQJAlxvJknAGEOxguxn4A6W6IwWVLlKs3mZx3qz
728Eg8jX1vx/rnfiL955QsTUsYjzkOG3Kfbqa8Ef2U5NQikuu0hNaeRb4tKJertK
tZwiOCLYYM4iD+/G6bnNkInzM0bTEDmkqvzbobW1uu0qARQP6nPhnyQq54Jpspht
7MVTr4Dqoc/K2Ozfk6ZMTD7EAH1X1a95Lut+8m1zH3irilS725lVZG1VKRpSx8Dh
RWQoCrUEabmUA8su2pjzk5DFTLLZw8AtHJ8S7PrWXnLSWRm4LkbQQvQ5oW2s7FvG
3VHWszVJ0lpi7/MpKi1GOYFfjGb2TMwV7sslpLh5Fya3+4Cw5fvqrruKHintuANQ
bPUhNStz7NMrrJED0BHMpDsl91v0gb+RG1PGgfmch3UbpiSPR5B2htPhr44KxZAp
UAw1qeD6NcUgdLpHhsMztxepbo+U8BW0+v95fN0+C5btLQc1pCvqKkIa4XNZbTaF
otv9qcoyJsoE/voLVs3o3LNRE5E4Mv8EuqCSfOtrIu+zosjzpmh+garp7u3yJTCX
+K5V37uAIkusWZiju5k2bDUkKqDwLYAKb/zMGWlBw760tJdnUkGTzS70ALGR36En
LUI=
=U0KI
-END PGP SIGNATURE-

Accepted vmdb2 0.13.2-2 (source all) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 18 Nov 2018 19:02:28 +0200
Source: vmdb2
Binary: vmdb2
Architecture: source all
Version: 0.13.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Lars Wirzenius 
Description:
 vmdb2  - creator of disk images with Debian installed
Closes: 911690
Changes:
 vmdb2 (0.13.2-2) unstable; urgency=medium
 .
   * debian/rules: disable check (Closes: #911690)
   * Orphan package. I'm retiring.
Checksums-Sha1:
 922c36f39c53b5989913f80dd6eae099a606069d 1842 vmdb2_0.13.2-2.dsc
 82c722868cd937b5d65a48b584e07b75bb87baa0 1996 vmdb2_0.13.2-2.debian.tar.xz
 4a224d4688311a577f1174e2c437f7aa6392e773 15292 vmdb2_0.13.2-2_all.deb
 01f3ebeb9042fddaed7ab42f2e5d2f830572da39 7357 vmdb2_0.13.2-2_amd64.buildinfo
Checksums-Sha256:
 85f5520662e8dbd51a00ed311f9958808fd548c75c3ef295483158ce14075356 1842 
vmdb2_0.13.2-2.dsc
 1780dbc8b4a850a717a2445dde188b18fc9627ff0345fa15f481c7375bf919d1 1996 
vmdb2_0.13.2-2.debian.tar.xz
 035289cad65df6e67bd34e1fedfaab9189823dcff96b12ea91bcfd4a2ee95bfb 15292 
vmdb2_0.13.2-2_all.deb
 9fd13204678b20e25c6878c739c95856461c7cb48f30f66defcc070899678814 7357 
vmdb2_0.13.2-2_amd64.buildinfo
Files:
 8f48899955ec3e06759ecdaacb4da705 1842 admin optional vmdb2_0.13.2-2.dsc
 08b6b667602263510030d449048289f7 1996 admin optional 
vmdb2_0.13.2-2.debian.tar.xz
 d6d9dfe4da9b34a9413c52699e302967 15292 admin optional vmdb2_0.13.2-2_all.deb
 15a2182d1ba7443f6d9f2dd4fb72378e 7357 admin optional 
vmdb2_0.13.2-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQI/BAEBCgApFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlvxm4gLHGxpd0BsaXcu
ZmkACgkQbC+mFux6IDETng//ckedSoN5iCwkPgE7fNcGiCAu4MWHA6wqv+6v1imD
LJDZwmHN46zKIMeoyo7GR0xfxIOeTAXx+EQurPpLxuaHfVOEpvNlPqXL1pcnmzpC
LZyTF2Qj+oCta2lE/jo8Mnp87DAUibgdfvMGWBLdcFKZoO72vF7QzdbavVMtSsAG
nx+xwMYN93nG6vlKrCHXVUEWMCz3B/UHHNlvzh1pJ7CTrBrhi7/qfvTGmQn8o7ft
NTRpwLL1peVBI1K29VXXdlzGmiDSGVmZUWpyKflf2JqBnwp1KRiw2ZHUSuVraqYh
JrysgB0xvUCMXK7z3IqnTisW217YBwF3bE8H8VXpRJ2S+TN+TNMFeJU5OL102JIa
Br4ca72SyytcIIFXPB2I/0BCJCf1M3FK1wssvtBXf4eBkUpgLkz3XQLNghV67Qmc
1rR4sRldvGTTo8XftOVx9684/VPhNWfEMCNjlNmkCIJEWZgcVf1ce8rK3ut5L4js
FzvO2ByJOyu119YkqocsHCdrtVbgSwqnwXuUSa+A0NkA5A0m0CfdZhu4CAmVV9ou
l3jy3B/1TZwl2ha4bpq8ctmi7HKNhKK0Y0iLSeqmP4QRaF/QtysKKexgyxxoVBQW
0QM0Kdk+vXX7ZDSm+bslfmixoC4E8j1uj5h2tE5G7yEVnVqgudS5tpUJGIqBb72c
/oo=
=ffNj
-END PGP SIGNATURE-

Accepted python-ttystatus 0.38-2 (source all) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 18 Nov 2018 18:27:45 +0200
Source: python-ttystatus
Binary: python-ttystatus python3-ttystatus
Architecture: source all
Version: 0.38-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Lars Wirzenius 
Description:
 python-ttystatus - terminal progress bar and status output for Python
 python3-ttystatus - terminal progress bar and status output for Python
Changes:
 python-ttystatus (0.38-2) unstable; urgency=medium
 .
   * Orphan package. I'm retiring.
Checksums-Sha1:
 7e0f79221375c3a0706b3ef782d5f811a94943ef 1967 python-ttystatus_0.38-2.dsc
 d2f9116be7bdd8e1e92d46ca3277d212a77cea20 2896 
python-ttystatus_0.38-2.debian.tar.xz
 96fcbc6e4b1493dc72868dde3c66534725475006 15376 python-ttystatus_0.38-2_all.deb
 0624b3f6e451a03b42ea57d3c6a08ad61063184a 7108 
python-ttystatus_0.38-2_amd64.buildinfo
 3a0938187afd3f8fca460bf84c0b2e75ab25a2b4 14960 python3-ttystatus_0.38-2_all.deb
Checksums-Sha256:
 b1f2974d749b8fb6e9ac08cb25b73b2bcc75fcddfb01e921d76835f7586224ae 1967 
python-ttystatus_0.38-2.dsc
 a86c328c89af2fbfcb8ed499620aaf6f9fc554a200c61d6be4c8f00da816e72c 2896 
python-ttystatus_0.38-2.debian.tar.xz
 acd766c964156bb03bf550a767b5702f004cab2a35f15b4d2351d4976b139ea2 15376 
python-ttystatus_0.38-2_all.deb
 cb91c70a77ed33e4a37fa9cca33364dc9bf83d48ee1e096152a789bb35312f90 7108 
python-ttystatus_0.38-2_amd64.buildinfo
 77dc4bc18c241f6ae5d17ab795f634f335aa9f40f5a22e55cb41e83242538d6e 14960 
python3-ttystatus_0.38-2_all.deb
Files:
 7df2c67da8520ce2450f480fbb6ed1a3 1967 python optional 
python-ttystatus_0.38-2.dsc
 bfb231c3dabbdfef5c208e140712e44a 2896 python optional 
python-ttystatus_0.38-2.debian.tar.xz
 f14e51c138c4340f71578f7611548e43 15376 python optional 
python-ttystatus_0.38-2_all.deb
 cdf1b37978ecc8a839b34fad19c7900e 7108 python optional 
python-ttystatus_0.38-2_amd64.buildinfo
 46c0c6902a19bce0521540b5ae4da9ad 14960 python optional 
python3-ttystatus_0.38-2_all.deb

-BEGIN PGP SIGNATURE-

iQI/BAEBCgApFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlvxkzULHGxpd0BsaXcu
ZmkACgkQbC+mFux6IDGNcRAAkrYcyD1hPk7D2/lGg5X6WYtQ9yj8pRUAZ1iMAnBZ
xv3As0dShsACS9uwG30H8Y38cQO76GnJ4Nd2lE1vOD0H111U/Id8vX8sMTgNX85i
K8d5mxly/Fs18Dq1Jcm+Y7W2uY79U3791TM85TB1b5cp9G6dIT/JHrLZN5kHYJqK
GiOdu+vwfjz4J2Lhy/mxIbTrniwRWLKiRNZ7XNhiYqxVmbP2SWQAe/VXI8ZwYB+L
ACTfC1sSEnZqHCZw9LGj8hYUZeU7l0IfPT+J5CTZhN1N0YW9tG6AUsqiEZa/dQ2O
zHxARb3f2GBeb2FRaoTxOo5EHJ/j/2n3s1cKO7nU+8+f0qZspEdodeknsosuQqyc
ZVaBffXJMHh0kGiObzpm3uj6Jz9tDpaIjb247qp6nRvIFW7LczQlAJupyRiPk3eM
9j2qozeD6cONxbErG70FLnU2rBX5ZwFOnmgcnjlol9ekSEyWfS6uXDYh3Lc+D+Fu
JC4gLnR7mnzCBp+FubkhWprjkUsxnBXQ8megkT+MOTLEHlflyI0toQ+C17lKrCgJ
tInH5AjiqU39IGsffzTsowj/+XAxScpeuymJPZPbI7wNT+j1EnvoSPUWmTQvXmoK
P78JJKdHNEjkoMlRLVDCnharSO9e/gfgI8jGH6TrYNQjxUQ7jTeT6vnfHcKab2SN
Duc=
=ehyw
-END PGP SIGNATURE-

Opt-in to continue as DD/DM? (was: I resigned in 2004)

[Lars Wirzenius]

Tollef Fog Heen :
> (I also wonder if we should just require people to opt in to their
> DD-ship on a yearly basis instead of doing most of the WAT/MIA dance. If
> people can't be bothered to reply to a single email saying «yup, another
> year please» with some reasonable amount of pinging and time to reply,
> they are effectively MIA, at least if they haven't let people know on
> -private or similar.)

I support automatically retiring DDs and DMs that don't repond to a
ping, or don't upload, or don't vote, or otherwise show activity.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Accepted mysql-5.7 5.7.24-1 (source) into unstable

[Lars Tangvald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 26 Oct 2018 10:13:22 +0200
Source: mysql-5.7
Binary: libmysqlclient20 libmysqld-dev libmysqlclient-dev mysql-client-core-5.7 
mysql-client-5.7 mysql-server-core-5.7 mysql-server-5.7 mysql-server 
mysql-client mysql-testsuite mysql-testsuite-5.7 mysql-source-5.7
Architecture: source
Version: 5.7.24-1
Distribution: unstable
Urgency: high
Maintainer: Debian MySQL Maintainers 
Changed-By: Lars Tangvald 
Description:
 libmysqlclient-dev - MySQL database development files
 libmysqlclient20 - MySQL database client library
 libmysqld-dev - MySQL embedded database development files
 mysql-client - MySQL database client (metapackage depending on the latest 
versio
 mysql-client-5.7 - MySQL database client binaries
 mysql-client-core-5.7 - MySQL database core client binaries
 mysql-server - MySQL database server (metapackage depending on the latest 
versio
 mysql-server-5.7 - MySQL database server binaries and system database setup
 mysql-server-core-5.7 - MySQL database server binaries
 mysql-source-5.7 - MySQL source
 mysql-testsuite - MySQL regression tests
 mysql-testsuite-5.7 - MySQL 5.7 testsuite
Closes: 911221
Changes:
 mysql-5.7 (5.7.24-1) unstable; urgency=high (security fixes)
 .
   * Imported upstream version 5.7.24 to fix security issues:
 - 
https://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html
 - CVE-2016-9843 CVE-2018-3133 CVE-2018-3143 CVE-2018-3144
 - CVE-2018-3155 CVE-2018-3156 CVE-2018-3161 CVE-2018-3162
 - CVE-2018-3171 CVE-2018-3173 CVE-2018-3174 CVE-2018-3185
 - CVE-2018-3187 CVE-2018-3200 CVE-2018-3247 CVE-2018-3251
 - CVE-2018-3276 CVE-2018-3277 CVE-2018-3278 CVE-2018-3282
 - CVE-2018-3283 CVE-2018-3284
 (Closes: #911221)
   * d/patches: Dropped mysql-test-run.patch
 Issue is fixed upstream
Checksums-Sha1:
 4a2094e2c429cabaf01a281f9d73aacf2afb1225 3229 mysql-5.7_5.7.24-1.dsc
 bd106953ca5bd0097483ca2bb9d13784bfc64365 49110448 mysql-5.7_5.7.24.orig.tar.gz
 e93182c505c50426df5a029c99b708c5a73146ab 155416 
mysql-5.7_5.7.24-1.debian.tar.xz
Checksums-Sha256:
 0840dc6bd325d53eb575f69bf724b801ee554d9a66f95a2e80c5ceb09a6ce8f3 3229 
mysql-5.7_5.7.24-1.dsc
 b980dced9c9eb3385cca44870facc220504ca011196c5a19c2bfe43d3f5d6212 49110448 
mysql-5.7_5.7.24.orig.tar.gz
 d2bb8a3e65be070c767a39f3e0bba6bcf719b21d017df6c98e6c1be96752ede2 155416 
mysql-5.7_5.7.24-1.debian.tar.xz
Files:
 07870c696141bcbe8d03d200a78cb8b1 3229 database optional mysql-5.7_5.7.24-1.dsc
 ee658554c11330116268783c45e9ed3c 49110448 database optional 
mysql-5.7_5.7.24.orig.tar.gz
 783c21bcf3d3009ff7bc5ac4e6231d88 155416 database optional 
mysql-5.7_5.7.24-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJb0vuYAAoJEOVkucJ1vdUuwboP/Ry5WLO6imVkutl6m08ptJSo
xLtZE61mVJHDZL1bGXI1IKTxWpa6zAhgIsA4/lAyn953Bh8chYztiS2FSG8sU/3u
zHuk2bWBrclRDr6iOIlUoNNZoA36Ny2pZH3C+/qScyB1ywC8EoX0C77Mf/JkTmqH
7AzfJNbbHIkzbO16NJReGByZNW+dRiV9Hb3qa7tPy9dlcSHKFVNniAEIqRoq17PG
PeVFk30jNZFsZGaU1VCFKdEw2sNgKSbiXq70bpMQ6AYcXFcuujnZUWsodoeOOGfN
QNGXtULgEKjrLcixYdHRx+VTav2A67Csw8rzezDMRfxJdQ9GejMn21i8N2ihLYpo
dXxvjjtU+/xArMbMTFA3ELj3ycxwTddlEv9gUI591+nzrLnzcJYWucXUNy6LnDk6
eVNFsQ05vAeENQus82b6XUq2xfEoImvM2/BvQVOAspzU4mY4A25+hc4gsF1UGbNY
b5irF9ItsjxFubsmUNiFPLHBdzbcvJeedOmIxkN+HuYs01vhn99mCgscnC24fG78
Nf0FOrU68KJRWguVFvb4CAAClW0s/zBXD0kPwe5JMItVtlVxzG7Hcl0baIzjP8Tq
ogoSUntafhkfdKal3IFZUV6OMpZlXrKFl+c2LpBpJgK3o1slh6Ak+11neAb5Hfxz
v3byhT82+yNLu9lMqkKz
=+hRZ
-END PGP SIGNATURE-

Limiting the power of packages

[Lars Wirzenius]

The problem: when a .deb package is installed, upgraded, or removed,
the maintainer scripts are run as root and can thus do anything.

Sometimes what they do is an unwelcome surprise to the user. For
example, the Microsoft Skype .deb and the Google Chrome .deb add to
the APT sources lists and APT accepted signing keys. Some users do not
realise this, and are unpleasantly surprise.

(Note that I'm not saying Microsoft or Google are doing something
nefarious here: they're trying to make sure security updates for their
packages will be deployed to user's system; this seems like a worthy
goal. But it's a surprise to some users.)

I don't think it's good enough to say the user shouldn't install
third-party packages. It's not even good enough to say the user should
use flatpaks or snaps instead: not everything can be packaged that
way. Debian's own packages can have equally unwelcome surprises.

Imagine a package that accidentally removes /var, but only under
specific conditions. You'd hope that Debian's testing during a release
cycle would catch that, but there's not guarantee it will. (That's a
safety issue more than a security issue.)

A suggestion: we restrict where packages can install files and what
maintainer scripts can do. The default should be as safe as we can
make it, and packages that need to do things not allowed by the
default should declare they that they intend to do that.

This could be done, for example, by having each package labelled with
an installation profile, which declares what the package intends to do
upon installation, upgrade, or removal.

* default: install files in /usr only
* kernel: install files in /boot, trigger initramfs
* core: can install files anywhere, trigger anything
* maintained-by-liw: full power to do anything

This might be implemented in various ways. For example, dpkg could
create a temporary directory, and bind mount the directories the
profile indicates are needed, into a temporary shadow of the full
system. Maintainer scripts would be run in the shadow environment.
Thus, if they try to do something that isn't allowed by the packages
profile, they can't.

The profile should be in the Packages file, and each apt signing key
should specify which repository (i.e., Packages file) it applies to.
There may be per-key restrictions for what profiles are allowed.

This is a quick thought, while I was trodding in the dark, wet, cold
evening to the grocery store. It's not a full specification, and it
may well not solve all problems that may happen when installing a
broken or malicious .deb. I'd like for us to solve at least the more
glaring problems, rather than throw our hands up and say it's to
difficult a problem. I'd like to be safe from my own mistakes, and if
that means our users are more safe and secure as well, that's a good
thing.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Package not compatible with old systemd

[Lars Wirzenius]

On Tue, Sep 18, 2018 at 09:21:11AM +0200, Ondrej Novy wrote:
> I think my solution is correct, because Swift works with any init system
> and I want to only say "it doesn't work with older systemd". I don't think
> it's correct to list all possible init systems in Depends.

Would Conflicts work here?

Conflicts: systemd (<< 235~)

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Limiting the size of installed changelogs

[Lars Wirzenius]

On Thu, Sep 13, 2018 at 11:22:37AM +0100, Ben Hutchings wrote:
> The src:linux package has a very big changelog (about 1700 kiB
> uncompressed, 600 kiB gzipped).  On my system the largest installed
> changelogs, by some way, are all versions of this.  (The next largest
> changelogs come from src:glibc, at about 200 kiB gzipped.)

I was curious, so I ran the following on my laptop:

$ find /usr/share/doc -name '*changelog*' -printf '%s %p\n' | sort -n | tail 
-n10 | while read size path; do echo $(humanify "$size") "$path"; done
2 MB /usr/share/doc/libgstreamer-plugins-bad1.0-0/changelog.gz
2 MB /usr/share/doc/xserver-common/changelog.gz
2 MB /usr/share/doc/xserver-xephyr/changelog.gz
2 MB /usr/share/doc/xserver-xorg-core/changelog.gz
2 MB /usr/share/doc/xserver-xorg-legacy/changelog.gz
2 MB /usr/share/doc/xwayland/changelog.gz
2 MB /usr/share/doc/gimp/changelog.gz
2 MB /usr/share/doc/gimp-data/changelog.gz
2 MB /usr/share/doc/libgimp2.0/changelog.gz
4 MB /usr/share/doc/libvirt0/changelog.gz

While changelogs are sometimes really useful, that's a fair bit of
diskspace on my laptop, and a fair bit of bandwidth to transfer, for
fairly little gain.

> The older history is unlikely to be of any use to users.  So on smaller
> systems this could be a significant waste of space.  (I know it's
> possible to filter out the installation of docs entirely, but I don't
> think this option is well known.)

I agree that we can drop older changelog entries. I suggest truncating
changelogs, at least large ones, by dropping any entries from before
stable, when uploading to unstable. So uploading to unstable today,
any entries from before stretch can be dropped. When a changelog is
truncated, there should be a URL to the full changelog, so those who
really are curious can find it. (Possibly oldstable would be a better
cut-off point.)

Alternatively, we could change things so that the changelog for each
Debian release (major part of version) is put in its own file.

With this scheme, uploads to unstable today would have
/usr/share/doc/*/changelog.debian10.gz. Once buster is released,
uploads would include changelog.debian11.gz instead. This would allow
a fairly natural rotation.

> - Does it make sense to compress changelogs with xz?  For src:linux,
> this achieves about a 20-25% reduction over gzip.

I'd be OK with using xz -9 to compress changelogs. This would also be
easily doable in debhelper. From the ten files I showed at the
beginning, I get about a 29% savings recompressing as xz.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Debian 9.5 Installer

[Lars Wirzenius]

On Mon, 2018-08-13 at 11:00 +0200, Julien Cristau wrote:
> A previous iteration on this was
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722898

A modern SSD can write hundreds of megabytes per second, and contains on
the order of a terabyte. Older SSDs are smaller, but slower. Rotating disks
are much slower, but typically also many times larger.

write speed disk size   wipe time   note
(MiB/s) (TiB)   (h)

20  1   15  older laptop HD
200 0.250.7 older laptop SSD
500 1   0.6 new laptop SSD

40  1   7   older desktop HD
200 1   1.5 desktop SSD

These are calculated times. Real times are likely longer, since wipe speeds
tend to be below what the hardware actually achieves.

Most people do not need to wipe their disks at installation time, when
using full-disk encryption. It would be enough to do that when the system
is booted, and can be used, in the background, at a priority that does not
hurt normal use.

Those that do need it should opt into wiping. As a user experience, having
to opt out of something you don't need is not great. Worse, the installer
it not a good place to explain the things one needs to make an informed
decision.

Having the installation process effectively pause even for half an hour is 
bad. And half an hour is a best-case scenario that only applies to those
with high-end hardware.

Could we make "wipe disks" into an option in the partitioner, rather than
having people cancel what might be a crucially important thing? And default
that to "no wiping"?


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

Accepted python-cliapp 1.20180812.1-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 12 Aug 2018 15:22:03 +0300
Source: python-cliapp
Binary: python-cliapp python3-cliapp
Architecture: source
Version: 1.20180812.1-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius 
Changed-By: Lars Wirzenius 
Description:
 python-cliapp - Python framework for Unix command line programs
 python3-cliapp - Python framework for Unix command line programs
Changes:
 python-cliapp (1.20180812.1-1) unstable; urgency=medium
 .
   * New upstream version.
   * Add build-dep on dh-python.
Checksums-Sha1:
 0b6ecd1a18a7a87d9922f421e8c896f080809f7a 1982 python-cliapp_1.20180812.1-1.dsc
 11b2ceb1b8cfec54371d10da4445041af3db4d6a 47168 
python-cliapp_1.20180812.1.orig.tar.xz
 0a8cd039c27d425dc2add6556e06dece57c6c682 3768 
python-cliapp_1.20180812.1-1.debian.tar.xz
 6771699f5193740089d0e4e61be0a7f00f2901ac 6560 
python-cliapp_1.20180812.1-1_source.buildinfo
Checksums-Sha256:
 257694bb2c37e0681217696ad30d968e8c1c3a0e8f49aa0f941ab99b0b81496c 1982 
python-cliapp_1.20180812.1-1.dsc
 e3e6e1babd86de617f70b651fafc2b21fc9c104ca7294778bee88187ac9f7f8f 47168 
python-cliapp_1.20180812.1.orig.tar.xz
 c4784d6b922eaf8ce1fea300681373fc1a14570694a755bb7ee064fb33b7574b 3768 
python-cliapp_1.20180812.1-1.debian.tar.xz
 3d673570f23d9c3a71cca56a7b0dc300afe1a6c7359a8b1f2df67d1b16cd6411 6560 
python-cliapp_1.20180812.1-1_source.buildinfo
Files:
 bbe31e2efe87f96a1b0143b439bbe052 1982 python optional 
python-cliapp_1.20180812.1-1.dsc
 2097e308b1426ddbef988cb5e2c5af38 47168 python optional 
python-cliapp_1.20180812.1.orig.tar.xz
 61fbdb8d38f6fbce9b26785f15888c39 3768 python optional 
python-cliapp_1.20180812.1-1.debian.tar.xz
 9b24f7fc94d5d6f942688e0988e77e77 6560 python optional 
python-cliapp_1.20180812.1-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAltwKTYACgkQbC+mFux6
IDGsXBAAuFbO4qEB2OHHvpDecnSObaVDyNhzvT0gLCaHvpPjUahrZTtk5mgUnciv
IuRPVVZLkVgUSNiNWGBn0t8WfWXspwED702eySNI+SqklRrOtTl7NQlvqKX0hXaI
32D8+2h+EtNmwzJ0qboSu72VHq2ldJgIaEaxehiS8uClCq9VBJRcVXUANOByifRU
MoDpP9gcNCfo5qZF3Js1jmS++THXbBmMDv2yZlvX0GLD+dOkU8W+YMrOG4xJpcUM
+PL/s1eUJJYXvl/w3K/dOROc9rw3BtSwcUpCgC7oYPrIK5Shm4L+OM/MJs4Z40LS
Tv4eEa0MqzzxJNbKaORxWZSlodAcBEKbqSM5S88tx33EDrQM93Oi9uSLt9F3RWuC
VFRLXip4tZJZZHEHVnbYUZ0WXOgt8l8L2r9ROy96C0m0g112e1gkc0Q8qNGAMQd2
x31B6D9dYBMy4kn5t4lWJVfp383vhXoGBoe/E7LuckH24EIVLEVsSmSMUHTnDI36
aJaHSqy6yNTzTDV9qRFz7lB+Trj54a1ddW/Ges3GU6PVFvNLY8CQFOkna5Ofz8vf
0NJCQIlvvzTGwzhSUh63EO+QV2ERkNErnzqjL/l8XSb0G5IWrCh7gupKPRXKGC1B
i/axndgdwETdg+CPNJTQztofBI6YiGoNQbT6XJDjeWXyC0EBFSs=
=kI/8
-END PGP SIGNATURE-

Accepted mysql-5.7 5.7.23-1 (source) into unstable

[Lars Tangvald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 30 Jul 2018 09:13:54 +0200
Source: mysql-5.7
Binary: libmysqlclient20 libmysqld-dev libmysqlclient-dev mysql-client-core-5.7 
mysql-client-5.7 mysql-server-core-5.7 mysql-server-5.7 mysql-server 
mysql-client mysql-testsuite mysql-testsuite-5.7 mysql-source-5.7
Architecture: source
Version: 5.7.23-1
Distribution: unstable
Urgency: high
Maintainer: Debian MySQL Maintainers 
Changed-By: Lars Tangvald 
Description:
 libmysqlclient-dev - MySQL database development files
 libmysqlclient20 - MySQL database client library
 libmysqld-dev - MySQL embedded database development files
 mysql-client - MySQL database client (metapackage depending on the latest 
versio
 mysql-client-5.7 - MySQL database client binaries
 mysql-client-core-5.7 - MySQL database core client binaries
 mysql-server - MySQL database server (metapackage depending on the latest 
versio
 mysql-server-5.7 - MySQL database server binaries and system database setup
 mysql-server-core-5.7 - MySQL database server binaries
 mysql-source-5.7 - MySQL source
 mysql-testsuite - MySQL regression tests
 mysql-testsuite-5.7 - MySQL 5.7 testsuite
Closes: 904121
Changes:
 mysql-5.7 (5.7.23-1) unstable; urgency=high (security fixes)
 .
   * Imported upstream version 5.7.23 to fix security issues:
 - 
http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html
 - CVE-2018-0739 CVE-2018-2767 CVE-2018-3054 CVE-2018-3056
 - CVE-2018-3058 CVE-2018-3060 CVE-2018-3061 CVE-2018-3062
 - CVE-2018-3064 CVE-2018-3065 CVE-2018-3066 CVE-2018-3070
 - CVE-2018-3071 CVE-2018-3077 CVE-2018-3081
 (Closes: #904121)
   * Moved internal test binaries out of usr/bin
 The client binaries mysqltest and mysql_client_test are only
 meant to be used by the mysql test suite, and are no longer
 installed in /usr/bin
Checksums-Sha1:
 f6c1208522cb835aa3c7f1a9423e34299162753b 3240 mysql-5.7_5.7.23-1.dsc
 e88edced7261412e66fc5570ed375bb3a36494bf 49025014 mysql-5.7_5.7.23.orig.tar.gz
 d5bfaf65dd4ef45462e45b570b2c703b245eb181 154320 
mysql-5.7_5.7.23-1.debian.tar.xz
Checksums-Sha256:
 75eeffb07127f5369d8ba60817ea446e90ac30bd2b82e057d38224e64dd06f9e 3240 
mysql-5.7_5.7.23-1.dsc
 d05700ec5c1c6dae9311059dc1713206c29597f09dbd237bf0679b3c6438e87a 49025014 
mysql-5.7_5.7.23.orig.tar.gz
 4378e37edd7493a477c34682027a180b647a8d375083f6679bba918ab65c8305 154320 
mysql-5.7_5.7.23-1.debian.tar.xz
Files:
 a6168eba126fdbdac50cd4e7b80ccb4d 3240 database optional mysql-5.7_5.7.23-1.dsc
 de108e7ff350aa10402a3e707a4b4c75 49025014 database optional 
mysql-5.7_5.7.23.orig.tar.gz
 4b2329bca1e24e6659f829e95d9ae402 154320 database optional 
mysql-5.7_5.7.23-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbZGr+AAoJEOVkucJ1vdUuJzAQAIv1dkBwme8gD9dOPW2p06Kn
rBEySXtWJ8xF6LhlZM95MwADYlXIhAQrRuVu9a26IXEEh3A7PUQWxnqkXeOlszYp
kjIIg0OGp/FNkB0i5AaC1rKBOKa/vwXpu6WXdMzI9f25NFwJ6lHgkovd1NNBwVqC
tTS1pgYPQUuWuQAfHh/TJlTvXdJaAKHF+1nnMS/sCCCq0bM2OothzasZezZBc/1W
2P26VjmCaDaMWcT18xkCmTBjLHoZY1DhsAGyEs7ugNJtPvgoMpFoDaNmtk69vrwk
fuN7TWUYyuzS9lTo2CFVFeFBN7zFI2mUSHVo2UF3I784eLk9NQEkB7KDh+mHB23X
iO2CzM9tFB4Gi6HCJzcFLqS50GPPnPDld2RrdYq4zsQjjupnQPl93aPDIYndAnhg
L1C30LCnGBVVQPbwkl9aO+dZ/eppQoHzuVH88Zy9auTydqGHIDMgL46b0ZdcX99T
hESOVC7NtlMFNjhm9AFS5h2mH+Dnc0lwOwn1amfeVMCTeJTmBETiJbpSq12BdK0c
WR0AXqacrx8jCVfMTN7wvWYq0sH5tQ/fmDtNfw9Nt04BGNv383e5qHsrKSOngJzJ
4yOgKd+n6UxGHb8p9sBVPBx4ePyvhfiQdBMmadqZvsOACww5VYBdiZ5nLb5t80UN
cFDfDa7SwX1EcORD7ib7
=/3I7
-END PGP SIGNATURE-

Accepted sharness 1.0.0-1 (source all) into unstable, unstable

[Lars Kruse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 13 Jul 2018 03:52:54 +0200
Source: sharness
Binary: sharness
Architecture: source all
Version: 1.0.0-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Kruse 
Changed-By: Lars Kruse 
Description:
 sharness   - shell library for automated tests with TAP output
Closes: 902730
Changes:
 sharness (1.0.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #902730)
   * add DEP8 tests
   * add upstream documentation
   * add overrides for issues to be discussed with upstream
   * add upstream meta information (DEP12)
 see https://wiki.debian.org/UpstreamMetadata
   * d/copyright: add licensing for debian packaging.
 Thanks, Sergio Durigan Junior
   * place "aggregate-results.sh" below doc/contrib/
Checksums-Sha1:
 bb222e6771f8c2d6d6d92205b2029b0492232962 1874 sharness_1.0.0-1.dsc
 97331ad700109c5bd9ace8eb1294609f5ce5b734 36000 sharness_1.0.0.orig.tar.gz
 7cbf680d3f3f8cf35991fa1ddf89d8ceebff41f9 2740 sharness_1.0.0-1.debian.tar.xz
 48e6a5d0652cdd4d8dfdb15673ff3719137a8160 28520 sharness_1.0.0-1_all.deb
 001cab84503abff1c90fb04413d25fbb3b964b6a 5439 sharness_1.0.0-1_amd64.buildinfo
Checksums-Sha256:
 1246c22b6b7aa270bdc8c2fa20e01cdfe8b462ac483ab8990943db68977aa65d 1874 
sharness_1.0.0-1.dsc
 2f3a848c951af713af51867ec8975445d556d1202d62eb30536740fc62934242 36000 
sharness_1.0.0.orig.tar.gz
 f89c6385b39b3ebc468b1a76e6d416328ba819ca5edc3ec8a0fb8c77de7d797e 2740 
sharness_1.0.0-1.debian.tar.xz
 6edad44a752dbcae8ae1e11d4c66454474139324d5bdfe5192d915a1684efdd6 28520 
sharness_1.0.0-1_all.deb
 4800421e29dfa919df93df5388de5ff4cfabd4805ce0afd1296fe477ca60dac1 5439 
sharness_1.0.0-1_amd64.buildinfo
Files:
 d91035f878e9d97162d71115669a05c4 1874 devel optional sharness_1.0.0-1.dsc
 6070e6a09acfb94904fef1ee403e54dc 36000 devel optional 
sharness_1.0.0.orig.tar.gz
 a572bc24b38f6777af655671fb83 2740 devel optional 
sharness_1.0.0-1.debian.tar.xz
 37d66da2f5222a2b57933b474c0b1ceb 28520 devel optional sharness_1.0.0-1_all.deb
 536601ded379f58a0446a3854b6fb200 5439 devel optional 
sharness_1.0.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEI3pUsQKHKL8A7zH00Ot2KGX8XjYFAltIJtIACgkQ0Ot2KGX8
XjZe9g/8D3YeRyeOsnBFqFpsg2qcxKO1opm2jRAWF/BPeLeCVvIADY7x4Ebc6ZAW
ta+nH+eMFcaS5nJ47GEBq8MT0NUQ0brQQTCeI+z6V+yOYMDDYTVVLUg3JFoJppaw
ldnHDfylK0zESM/5LiuUh/0xHUhJ2ScWzmQKlIh+PDtwIwwKNIscRYPbFwLv1tWf
ncAbeOcnn6vN1Svtng+stfDYlCDcB7o5N/d9lStpLY60Uu9iWOK4QSOQm01iOZjq
p+gEahKZtzoe5SLWyxhQMgkFaZ33tbnYR5nfW5NvFKGok3pDJM5pPEdY16UQf5RG
6zRci10rDLQl+HW09/xxINmnHvdNqll10N1UNN0dgWSTla0o99FYaePE9GKlbkLg
CSg3rjdM7EmbASvFrLlpFv/qlMa6dZtLmfExtzFZ+G2mMInzsNy7soaMDV3w/cPA
4Atd298WjNtDhuiAkSIM9bsB3jg213P50AleH3nS3O4JdP4CYIj/x5eqmNc28Nno
VwUa67jAKTr2Qi8lt8+vUtIBkok8CLTfwEorK4uFRf2HGwAPbwmfzPV/arMKhEP3
cyoVw6MOK0ishwjMV/boL4D17DZVbFDGX6SqhBuDtBEZ7He01TI0PNLhL+Cebb0m
zH2K9VEIeT+C+E+S2nKx+CZKLGIRg7ToGtlIiu/oHarlbDEntBw=
=Jd7P
-END PGP SIGNATURE-

Re: vmdebootstrap going away in September, switch now

[Lars Wirzenius]

Package: autopkgtest
Version: 5.4.2


On Sun, 2018-07-29 at 23:24 +0200, Michael Biebl wrote:
> I notice that the autopkgtest man pages still reference vmdebootstrap,
> specifically autopkgtest-virt-qemu.1:
> 
> > BUILDING IMAGES
> >Debian
> >For Debian you can use vmdebootstrap(8) to build a suitable image. 
> > E. g. for unstable:
> > 
> >   vmdebootstrap --verbose --serial-console --distribution=sid \
> >  
> > --customize=/usr/share/autopkgtest/setup-commands/setup-testbed \
> >  --user=test/test --size=100 --grub 
> > --image=autopkgtest-sid.raw
> >   qemu-img convert -O qcow2 autopkgtest-sid.raw  
> > autopkgtest-sid.img
> >   rm autopkgtest-sid.raw
> 
> 
> Could those man pages be updated to list the commands for a/the
> recommended replacement/successor of vmdebootstrap?

vmdebootstrap is going away and the manual page quoted above needs to be
updated to use a replacement, such a debos or vmdb2 or FAI.

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

Building Debian packages in CI (ick)

[Lars Wirzenius]

I've recently made the first release of ick, my CI engine
(https://ick.liw.fi/), which was built by ick itself. It went OK, but
the process needs improvement. This mail has some pondering on how
the process of building Debian packages should happen in the best
possible taste.

I'd appreciate feedback on these thoughts. (This email is a big long,
but I've published the same thing on my blog, if that's easier to
read:
https://blog.liw.fi/posts/2018/07/19/building_debian_packages_in_ci_ick/)

# Context

I develop a number of (fairly small) programs, as a hobby. Some of
them I also maintain as packages in Debian. All of them I publish as
Debian packages in my own APT repository. I want to make the process
for making a release of any of my programs as easy and automated as
possible, and that includes building Debian packages and uploading
them to my personal APT repository, and to Debian itself.

My personal APT repository contains builds of my programs against
several Debian releases, because I want people to have the latest
version of my stuff regardless of what version of Debian they run.
(This is somewhat similar to what OEMs that provide packages of their
own software as Debian packages need to do. I think. I'm not an OEM
and I'm extrapolating wildly here.)

I currently don't provide packages for anything but Debian. That's
mostly because Debian is the only Linux distribution I know well, or
use, or know how to make packages for. I could do Ubuntu builds fairly
easily, but supporting Fedora, RHEL, Suse, Arch, Gentoo, etc, is not
something I have the energy for at this time. I would appreciate help
in doing that, however.

I currently don't provide Debian packages for anything other than the
AMD64 (x86-64, "Intel 64-bit") architecture. I've previously provided
packages for i386 (x86-32), and may in the future want to provide
packages for other architectures (RISC-V, various Arm variants, and
possibly more). I want to keep this in mind for this discussion.

# Overview

For the context of this email, let's assume I have a project Foo. Its
source code is stored in `foo.git`. When I make a release, I tag it
using a signed git tag. From this tag, I want to build several things:

* A **release tarball**. I will publish and archive this. I don't
  trust git, and related tools (tar, compression programs, etc) to be
  able to reproducibly produce the same bit-by-bit compressed tarball
  in perpetuity. There's too many things that can go wrong. For
  security reasons it's important to be able to have the exact same
  tarball in the future as today. The simplest way to achive this is
  to not try to reproduce, but to archive.

* A **Debian source package**.

* A **Debian binary package** built for each target version of Debian,
  and each target hardware architecture (CPU, ABI, possibly toolchain
  version). The binary package should be built from the source
  package, because otherwise we don't know the source package can be
  built.

The release tarball should be put in a (public) archive. A digital
signature using my personal PGP key should also be provided.

The Debian source and binary packages should be uploaded to one or
more APT repositories: my personal one, and selected packages also the
Debian one. For uploading to Debian, the packages will need to be
signed with my personal PGP key.

(I am not going to give my CI access to my PGP key. Anything that
needs to be signed with my own PGP key needs to be a manual step.)

## Package versioning

In Debian, packages are uploaded to the "unstable" section of the
package archive, and then automatically copied into the "testing"
section, and from there to the "stable" section, unless there are
problems in a specific version of a package. Thus all binary packages
are built against unstable, using versions of build dependencies in
unstable. The process of copying via testing to stable can take years,
and is a core part of how Debian achieves quality in its releases.
(This is simplified and skips consideration like security updates and
other updates directly to stable, which bypass unstable. These details
are not relevant to this discussion, I think.)

In my personal APT repository, no such copying takes place. A package
built for unstable does not get copied into section with packages
built for a released version of Debian, when Debian makes a release.

Thus, for my personal APT repository, there may be several builds of
the any one version of Foo available. 

* foo 1.2, built for unstable
* foo 1.2, built for Debian 9
* foo 1.2, built for Debian 8

In the future, that list may be expanded by having builds for several
architectures:

* foo 1.2, built for unstable, on amd64
* foo 1.2, built for Debian 9, on amd64
* foo 1.2, built for Debian 8, on amd64

* foo 1.2, built for unstable, on riscv
* foo 1.2, built for Debian 9, on riscv
* foo 1.2, built for Debian 8, on riscv

When I or my users upgrade our Debian hosts, say from Debian 8 to
Debian 9, any packges from my 

Bug#902730: ITP: sharness -- Sharness is a portable shell library to write, run, and analyze automated tests for Unix programs. Since all tests output TAP, the Test Anything Protocol, they can be run

[Lars Kruse]

Package: wnpp
Severity: wishlist
Owner: Lars Kruse 

* Package name: sharness
  Version : 1.0.0
  Upstream Author : Christian Couder 
* URL : https://github.com/chriscool/sharness
* License : GPL2+
  Programming Lang: Shell
  Description : Sharness is a portable shell library to write, run, and 
analyze automated tests for Unix programs. Since all tests output TAP, the Test 
Anything Protocol, they can be run with any TAP harness (e.g. "prove").

Each test is written as a shell script, for example:

  test_expect_success "Success is reported like this" "
echo hello world | grep hello
  "

  test_expect_failure "We expect this to fail" "
test 1 = 2
  "


Sharness is used by a few Debian packages as part of their DEP8
tests (via autopkgtest):
  * gearmand
  * git-reintegrate
  * git-remote-bzr
  * git-remote-hg
  * hiera-eyaml
  * jemalloc
  * mod-gearman
  * munin
  * pass-otp
  * puppet-lint
  * puppet-module-puppetlabs-concat
  * puppet-module-puppetlabs-ntp
  * puppet-module-puppetlabs-stdlib
(the list was assembled via https://codesearch.debian.net)

Currently these packages embed a copy of the sharness.sh file below
debian/tests.
I will file bug reports against these packages (including patches) after
the sharness package is available, in order to help them getting rid of
their embedded code copies.

I am part of the munin packaging team, thus the munin package would
benefit immediately from this package.

I plan to maintain the sharness package for the foreseeable future.

I will need a sponsor for uploading this package.

Cheers,
Lars

Accepted mysql-5.7 5.7.22-1 (source) into unstable

[Lars Tangvald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 23 Apr 2018 08:20:42 +0200
Source: mysql-5.7
Binary: libmysqlclient20 libmysqld-dev libmysqlclient-dev mysql-client-core-5.7 
mysql-client-5.7 mysql-server-core-5.7 mysql-server-5.7 mysql-server 
mysql-client mysql-testsuite mysql-testsuite-5.7 mysql-source-5.7
Architecture: source
Version: 5.7.22-1
Distribution: unstable
Urgency: high
Maintainer: Debian MySQL Maintainers 
Changed-By: Lars Tangvald 
Description:
 libmysqlclient-dev - MySQL database development files
 libmysqlclient20 - MySQL database client library
 libmysqld-dev - MySQL embedded database development files
 mysql-client - MySQL database client (metapackage depending on the latest 
versio
 mysql-client-5.7 - MySQL database client binaries
 mysql-client-core-5.7 - MySQL database core client binaries
 mysql-server - MySQL database server (metapackage depending on the latest 
versio
 mysql-server-5.7 - MySQL database server binaries and system database setup
 mysql-server-core-5.7 - MySQL database server binaries
 mysql-source-5.7 - MySQL source
 mysql-testsuite - MySQL regression tests
 mysql-testsuite-5.7 - MySQL 5.7 testsuite
Closes: 895997
Changes:
 mysql-5.7 (5.7.22-1) unstable; urgency=high (security fixes)
 .
   * Imported upstream version 5.7.22 to fix security issues:
 - 
http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html
 - CVE-2018-2755 CVE-2018-2758 CVE-2018-2759 CVE-2018-2761
 - CVE-2018-2762 CVE-2018-2766 CVE-2018-2769 CVE-2018-2771
 - CVE-2018-2773 CVE-2018-2775 CVE-2018-2776 CVE-2018-2777
 - CVE-2018-2778 CVE-2018-2779 CVE-2018-2780 CVE-2018-2781
 - CVE-2018-2782 CVE-2018-2784 CVE-2018-2786 CVE-2018-2787
 - CVE-2018-2810 CVE-2018-2812 CVE-2018-2813 CVE-2018-2817
 - CVE-2018-2816 CVE-2018-2818 CVE-2018-2819 CVE-2018-2839
 - CVE-2018-2846
 (Closes: #895997)
   * d/tests: Broken test main.ssl_ca disabled for dep8
 Upstream report: https://bugs.mysql.com/bug.php?id=90749
   * d/copyright: Added entry for new file .gitreview
   * d/control: Replace obsolete build-dep on dh-systemd
 Dependency is replaced by debhelper (>= 9.20160709)
Checksums-Sha1:
 2cafefd0e09a988eca132a957ec124cc42346cfa 3240 mysql-5.7_5.7.22-1.dsc
 f4a65a2789cb2f697178327623407f7314b65faf 48985783 mysql-5.7_5.7.22.orig.tar.gz
 dfbce56a592cfa09ec1d614e13997a8da8e76446 153880 
mysql-5.7_5.7.22-1.debian.tar.xz
Checksums-Sha256:
 fccfac28a873255b61fb0ac27e42f35f54758ea0ef71fb565ca099ef185e652c 3240 
mysql-5.7_5.7.22-1.dsc
 5b2a61700af7c99f5630a7dfdb099af9283c3029843cddd9e123bcdbcc4aad03 48985783 
mysql-5.7_5.7.22.orig.tar.gz
 3598c15fdff340747d024a3d618287dde86787defb55f91f1f4f87f418175300 153880 
mysql-5.7_5.7.22-1.debian.tar.xz
Files:
 9655d793b89ebaf0d3e72cd0967b7b3f 3240 database optional mysql-5.7_5.7.22-1.dsc
 4af7ca82eb0dfd4cfb23fe6ea28a2fae 48985783 database optional 
mysql-5.7_5.7.22.orig.tar.gz
 fc9f74a806c900ef90166c6bd077afcd 153880 database optional 
mysql-5.7_5.7.22-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJbGpozAAoJEOVkucJ1vdUu0QkP/A2n623XqcxYMT1vhaPj2sq1
Nhu7mhh4WVvxEAG96z38oQJh/Thu5qXCChuCXjOZp6CioU39/3KDJuTRhkPCha1r
Y0RZzNQ3TbZVjgUk7y40UsWxjBxzZla911d0fF6LlvqjtBgRamymVkC91eSL50lo
QZGGNg7urqbZjaOcyZVRWTLexHRRQAKsOo7MS1skfNYD/OTdseqdEnY8Xm5kEF/v
Na/KJCWW9+T3FhBs1Gdek192q8KmgJljL2TIVndcwI4tDfd27f9HTf+tQC0WzZdh
e+2j+JiQE5uyJ/sYCStR15OIT19OnsJKdtiuYG2NXV6+StgMf3wDIoSD2Adp9HEf
x2gjMoM35mfzsizlijrFa+6bgur+ZUiqzWZ7xR++Ro7ZTw+xNybYob+Rp4gaWkf9
flQhTNraky9YgMY590eoY0IzN5lAFWtP3qS/pQPD2uL+oWhuL6fd3i38YYBzDwMg
wxairUIhUMbQX0V5cmEL4XlZ5Og0s41WXe3FyWhri6CKfQXaz6j7gzIYCywJKKtw
NIkVRR8yw0IwldGSZt42txOgSoOKF04Li6fhdJyIkEj4RZsytRlWMu8c1uuQdHIa
M2uCwJOlTVARRHFFgBt5FtsNOKVspzoOdsb5GeAdCDx6Dcy0wlzY2CBV2p2VD8ba
4D+F2H78kQNVt8ByxkgH
=eMCG
-END PGP SIGNATURE-

Accepted vmdb2 0.13.2-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 06 May 2018 09:26:24 +0300
Source: vmdb2
Binary: vmdb2
Architecture: source
Version: 0.13.2-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 vmdb2  - creator of disk images with Debian installed
Changes:
 vmdb2 (0.13.2-1) unstable; urgency=medium
 .
   * New upstream version.
Checksums-Sha1:
 51877b1aff6027468fe79f08850518c49cb97005 1821 vmdb2_0.13.2-1.dsc
 be8fabbb036e0886fc284d61114b710e3ad23321 22252 vmdb2_0.13.2.orig.tar.xz
 11a434891046e3aba3d731bb6d39601e6682f4f3 1904 vmdb2_0.13.2-1.debian.tar.xz
Checksums-Sha256:
 8c58a0423a6cc1f1fd8be0a7f6b2eec1cb6d69e8da4cb48c6000a437607b2f03 1821 
vmdb2_0.13.2-1.dsc
 a9a8954a3a786fd78b5e5b14b6a9771d1c316a4990f79ec9823e655f0d2bd7f7 22252 
vmdb2_0.13.2.orig.tar.xz
 bd134f5871f9cc2e9f674b1d0c832409ba3cc99b9f60755138810b6d74e128b0 1904 
vmdb2_0.13.2-1.debian.tar.xz
Files:
 a8a2ce4df9e3043645ed49dee77da309 1821 admin optional vmdb2_0.13.2-1.dsc
 366d6e0b468efa4a4b0703ad915a4ccb 22252 admin optional vmdb2_0.13.2.orig.tar.xz
 bb1e66ebe7b9e5518533ff04878b26fb 1904 admin optional 
vmdb2_0.13.2-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlruoNUACgkQbC+mFux6
IDGpDQ//R/6SZNZ4Mfpu8h3AWWLN0qqWnYsLmnH1eDhc9mJa8pXVrUYC5mJmrlOz
aDo/qssfXmVBqEr+rumcHUsOnfjkqmwCUYDX3jQ/TCuDouAqz+yjH8TCDUK5uOME
Tn+1tVaIWs838OALtzPlS0Ws6ug5nxC6U5NcVzQ6mMNi1pxroO11QRQU9jb3yUnE
gsMKufyuRyfBW5/W2uM9h7/oaCqUNsjroHJgZrp1BuDC3EN2fojoj2AUTzDPL4iY
B9LCfPhxPgSgs1NGw+eg7rCTdfunCN29fKdsDA7hzjNhqT/sut2bsrd0bQRViUXX
LxG74lO+84kHvt/sNAT/PVjXxNP56i/xgkk8UI89wzdO6TElE3LCyxgC982cNM5D
G0xjyzRGUH50JtaA/KCn81GIjG795fd6FKcdR0Y6IcEk1YTvyIoM15v3UPoye4lm
6finvsCC9f5+HC6/ounyzXybdmPnP+2vBZaXGksEKFZ1E71wqg4qnNAzYKtb4XPL
UWv7sn7tIbiYBf5uo/cS8hvxKvcxfq2Sm3ItZPWuxtNNFuh2HWrMF0KUyIfBQooE
07j33jXYjblwG9ozhuI3osS5A1JY9gMt6VGzDv4sa9UQ0MxiyZ3+ZmIFjBHdLyxT
RM4UZBYnFbovWc8VLo1PDUD6/2wgJiCJ6FOd4Q6/hxvbxH7ycUA=
=8OKd
-END PGP SIGNATURE-

Accepted vmdebootstrap 1.11-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 27 Apr 2018 17:07:58 +0300
Source: vmdebootstrap
Binary: vmdebootstrap
Architecture: source
Version: 1.11-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 vmdebootstrap - Bootstrap Debian into a (virtual machine) disk image
Changes:
 vmdebootstrap (1.11-1) unstable; urgency=medium
 .
   * Fix maintainer address in debian/control.
Checksums-Sha1:
 064101a3288e3d3178b1c3b3f5489f2f876ff713 2097 vmdebootstrap_1.11-1.dsc
 4005461ac67b511039e44aa77f42331db93b2683 59684 vmdebootstrap_1.11.orig.tar.xz
 2bd73bd9b1fe4104df5016546cc255e28fa290fe 6676 
vmdebootstrap_1.11-1.debian.tar.xz
Checksums-Sha256:
 d8a556914c4753bfbe6021215123641cb6bc87e7776163538f9df3c6b80274b5 2097 
vmdebootstrap_1.11-1.dsc
 85d48b376bc6e5d6984be5da7bb294b0f96ce0f3ad0187da265edfc694435130 59684 
vmdebootstrap_1.11.orig.tar.xz
 0c3f3b5ff7681f487e894efc1f85a071f353bf695b96cb3ad2b0897952cee479 6676 
vmdebootstrap_1.11-1.debian.tar.xz
Files:
 fff2a6dab75ee8cf315ed58b196c80fc 2097 admin extra vmdebootstrap_1.11-1.dsc
 2db349146f3d8dd9e470ca77d5c23abc 59684 admin extra 
vmdebootstrap_1.11.orig.tar.xz
 43dc377203ee1d9f248f94202c2c2c49 6676 admin extra 
vmdebootstrap_1.11-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlrjMAYACgkQbC+mFux6
IDGluQ/+Lkopu+m0gwCZxIUGU4X18R7f+kuyaJk3HiWuXd6fAkVJ4Q6MW2odGIs+
oVMXLhue6aHI00nKVV2bp/66bvzUVj6tUS1k5bTBIne5NKXonwrmYzLVsDjJgMJo
tlDWpTYOfpR6fEjQxfgkSQFmx03pRrccekTibFlNLv3Oxhx8DeL8HVEdPIPMEA9n
G6qdFoeEkH1FiqUU7DRdFH98RR8iVmSNIZ0lVXeb9a37xkjWRhL3KfrP0U7tvPRi
Ce8nQFBYP7uWiWvakaj1zpgYMzDgKdxQn/pjJxv5qFeMNwdIl0rHlr4q555Q+dbp
Qz1NYn/mA0wrCfXjUIhna+zjAEwocVWKqM98JytIKPKJy26nQLgdYyHil50ew8Bp
43wuQJXT8RDDI2EA6pSWxi8rgRGMub93QPyJfa6psaoajd2vEBv6xIfB9FfNjHqf
sg15eu2H4OTcCKb+4jMH6xwS/nJPOwHksEFyxcoGY5vhF4WrfM9OKCZxLrwIYwO7
as1AwWgmhLSrWpJR/TojVBKwnKHSXsQxnelf8ImM47Hjy2NO1Ybr6Fzh0og7SfRL
/M3yuadUioMUqcCLDrs00FQVGiOdPlYksgsSLBp3Vc9qXQvXhsp5mwl0BPRqQCgL
TL0/lCnQeJ9JYahWDWVfmgrtOKXhlYMcY+AUDLkA6MuEBouWpvw=
=LkZF
-END PGP SIGNATURE-

Re: Comma in Maintainer field

[Lars Wirzenius]

I feel like performing cruel acts on a previously viable equine
entity.

On Sun, 2018-04-22 at 14:56 +0100, Ian Jackson wrote:
> I think this is not really desirable.  It would be much better to make
> the syntax a subset of 5322, at least.

I think we should make this easy on ourselves. Let's drop the entire
idea of having our developers manually write something that conforms
to obscure and complicated rules for email addresses. Let's allow
ourselves write things in easy, obvious ways and have any tooling that
needs to use that information to send an email construct the address
in the correct way. This is much easier than getting all tools that
need to extract the informaion to be simple, and concentrates the
tricky bits into a few tools. Very few human brains need to be injured
with 822 and its descendants.

Specifically, I propose we not store anything like this:

Maintainer: "Bo Ö, Sr" 

Instead we should store this:

maintainer:
  name: Bo Ö, Sr
  email: b...@example.com

Let's also not store this in debian/control, but in something like the
package tracker. We can have the archive software put in a Maintainer
field with current syntax, if we want to, at least for a transition
period.


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

Re: Bits from the release team: full steam ahead towards buster

[Lars Wirzenius]

On Wed, 2018-04-18 at 11:16 +0500, Andrey Rahmatullin wrote:
> No, users and, I suspect, a large part of admins and developers cannot
> easily say which of two codenames is newer, and it doesn't matter what are
> those two codenames. Numeric versions are usually used to help with this,
> but not so much in Debian.

I've been developing a habit of writing both number and codename:
Debian 9 (stretch) and Debian 42 (billgates).

I think it would be a good habit for others as well, especially in
public-facing communication.

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

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Lars Wirzenius]

On Fri, 2018-03-23 at 04:07 +0100, Guillem Jover wrote:
> On Fri, 2018-03-23 at 03:33:48 +0100, Adam Borowski wrote:
> > apt show $PACKAGE
> > 
> > There's no need to duplicate the information inside .dsc/.deb and apt
> > indices.
> 
> Do you realize that the point of the repository (not apt :) indices is
> precisely to duplicate all the information from the .dsc/.deb? Plus
> some extra stuff.

This is in fact not the case. The information in the Packages file
does not necessarily come from the source package. For example,
package tags does not come from the source package, but from an
external source.

Section and priority information only partially comes from the source
package, and primarily from the ftp master overrides file. Worse, the
values in the source package (even in unstable) may be entirely wrong
for the binary package.

Having, say, Homepage come from an external source insted of
debian/control does not seem to me like a big revolution to me.


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

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Lars Wirzenius]

On Thu, 2018-03-22 at 15:40 +0100, Guillem Jover wrote:
> I'm not sure now if this also has been said before, but I'm happy to
> repeat it in any case. :) I'd very strongly object to completely moving
> those fields out of the source packages, because it means when you get
> or have a source package lying around then it's missing important
> metadata and it stops being standalone, which would require checking
> somewhere online, and you might first need to infer which distro/repo
> was this coming from. I'll happily take outdated data than no data any
> day, because usually you can use that outdated data to trace your way
> to the current one, not so if it's missing.

I believe I understand your point of view, but I still disagree.


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

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Lars Wirzenius]

On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote:
> I admit I do not agree with this and it was discussed here before.  Can
> we please agree that anonscm.debian.org remains a valid URL and stop
> starting another round of package uploads for the sake of changing Vcs
> fields.

I'm repeating myself, but could we please find another way to store
this information than in the source package? I'd like to see all of
the following stored somewhere else than the source package:

* Maintainer, Uploaders
* Vcs-*
* Homepage
* debian/watch

Possibly also Section and Priority.

All of the above can change and it's silly to have to make a source
upload to change them. They also easily get out of date and so are
likely out of date for a stable release.

I envision a service, metadata.debian.org, with a suitable
authenticated API to allow Debian package maintainers to update the
information, and having tracker.debian.org, dak, and other parties
fetch the data from metadata service, for inclusion in, say, Packages
files.

I think this would be a better thing to spend time on than talking
again about keeping anonscm around.


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

Re: Updated proposal for improving the FTP NEW process

[Lars Wirzenius]

On Sat, 2018-03-10 at 23:06 +0100, Andreas Tille wrote:
> In this longish thread I have read one contribution where a developer
> expressed that he was happy about checking his SONAME bumped package
> that was erroneous and luckily ftpmaster found the problem. 

I'm happy that the ftp masters are doing their job in the best way
they can. This includes any re-reviews of packages already in the
archive, at whatever points they choose, be that when there's a new
binary package from an old source package, randomly chosen packages,
or targeting packages whose SHA3 ends in 42.

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

Re: Updated proposal for improving the FTP NEW process

[Lars Wirzenius]

On Wed, 2018-03-07 at 00:30 +0500, Andrey Rahmatullin wrote:
> On Tue, Mar 06, 2018 at 07:27:40PM +, Ian Campbell wrote:
> > > I know for a fact that quite regularly licence checks on binNEW packages
> > > causes RC bugs to pop up.  I acknowledge it may be a burder for the ftp
> > > team, but that reason alone probably deserves to keep binNEW as it is.
> > 
> > That would seem to justify some sort of randomized spot checks on the
> > archive, not arbitrarily focussing on the subset of packages which
> > happen to need a new binary package for some reason.
> 
> Exactly.

It's almost spring in northern Europe and with the lengthening day I
start getting many crazy ideas. Here's one: it would be truly awesome
if we could review each source package at least once per Debian
release cycle. I don't think that's possible, it would be awesome if
it were.

There is, in unstable, about 28000 source packages right now, if I'm
counting correctly. A release cycle is about two years. That's about
40 source packages per day, every day. That would require either a
very large number of extra volunteer reviewers, or automation.

If most upstreams were systemtically tagging (perhaps using SPDX)
their sources with licence information, or we had a mostly reliable
tool for deducing that information automatically, this might be
feasible.


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

Re: Updated proposal for improving the FTP NEW process

[Lars Wirzenius]

On Mon, 2018-03-05 at 14:51 +, Chris Lamb wrote:
> Hi Martin,
> 
> > In many cases, there is an issue open about the new binary package
> 
> (In my experience, there is not.)
> 
> > When there is no bug report open at all, well, bad luck.
> 
> Well, possbibly, but if one is investing time and effort in changing a
> process it seems a shame not to cover these cases IMHO. :)

I think that in cases there a package lands in NEW because it's added
a new binary package, or changed the name of one of its binary
packages, any package could be filed against the *source* package.


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

Re: A proposal for improving transparency of the FTP NEW process

[Lars Wirzenius]

On Fri, 2018-03-02 at 22:05 -0600, Steve Robbins wrote:
> I assume that the reason my packages have been processed is due to one
> > of two reasons: a) I get quoted on LWN several times a year, so I'm a
> > celebrity and get special treatment
> 
> I expect that's it.  

For the avoidance of doubt, especially for onlookers: I was, of
course, being sarcastic with that LWN command, and I think Steve is
continuing by being deadpan sarcastic in response.

I wish text/plain carried font information so I could use a font to
indicate when I'm being sarcastic (Times, Helvetica, or Courier).

> Or possibly you have a more generous notion of "fast".  Currently there are 
> five or six dozen packages waiting more than 2 months.  That's not fast in my 
> books.

By "fast" I mean "less than 24 hours". I uploaded vmdb2 (new source
package) about a month ago. The timestamp of the mail saying it's
going into the NEW queue is 16:27. The ACCEPTED mail has a timestamp
of 18:00. That was on February 10.

Admittedly, it is quite a small package, but that's kind-of my point.
Making it easy for others to do the thing you need them to do is what
you can do to make things easier for you. Asking them to do more work,
or to change how they do their thing, is less likely to go well.

The Linux kernel maintainers flat-out reject large patches that dump
big changes without prior discussion. This is because it's easier for
them to digest changes in smaller chunks, and they put the
responsibility for presenting the changes that way on the people
producing the patches.

For Debian, I think we should have the same approach. Not literally
the same approach, of course, since that would mean having the Debian
package maintainer refactor the upstream code into smaller programs,
and that would just be silly. But the same approach of making it the
uploader's responsibility to present a new package in a way that makes
it easy to review it. This includes making copyright information easy,
and working with upstream to make it clear, possibly by using SPDX
markup for copyrights and licensing. For all of Debian it meants
finding or developing tools for automating extraction of copyright
information into debian/copyright in whatever manner is needed.
We have licencecheck, and if that isn't good enough, we can improve
it.

There may be other reasons why some packages stay in NEW for a long
time. Getting information from ftp masters about the reasons why, and
a discussion of how we can make easier for them to make NEW review
easier would, I feel, take us forward better than another than us
complaining that things are taking too long.

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

Re: A proposal for improving transparency of the FTP NEW process

[Lars Wirzenius]

On Fri, 2018-03-02 at 13:51 +0100, Gert Wollny wrote:
> How do you want to achieve this with a source package that has 13k+
> source files and where upstream does not provide a standard license
> header for each file? I.e. there is some license text and it needs to
> be quoted, but licensecheck doesn't detect the license or doesn't
> detect the copyright entry, so one has to manually inspect many files
> to get it right. 

If upstream and the package uploader togehter don't make the copyright
status so clear it's easy for ftp master (or anyone else) to review,
then yes, I think we'd be better off with not adding that software to
Debian. Ftp master time is a scarce resource, I think we should try to
be careful of how we spend it.

> Do you really want to reject these packages outright from Debian, even
> though they follow the DFSG?

Do we really want to pile on more work on an already busy team just so
you can do less?


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

Re: A proposal for improving transparency of the FTP NEW process

[Lars Wirzenius]

On Fri, 2018-03-02 at 13:00 +0100, Gert Wollny wrote:
> as the one who is the uploader of the package that is currently longest
> in the NEW pipeline (vtk7), I'd like to make a proposal how
> transparency and also the interaction from non ftp-master members to
> review packages could be improved.

I'm not involved with the ftp master team in any way, except I
occasionally make them do work by uploading things that go to thew NEW
queue. In the past decade ago, the NEW processing has almost always
been fast, and when it hasn't, it's been due to issues like a Debian
release happening.

I assume that the reason my packages have been processed is due to one
of two reasons: a) I get quoted on LWN several times a year, so I'm a
celebrity and get special treatment or b) I take care to make my
packages easy to review. I've had a couple of rejections, and those
were clear bugs, and after I fixed them, the re-review went fast.

> Short version: Use the salsa per-package issue tracker for problems
> that come up with the review in NEW.

Counter proposal: let's work on ways in which uploaders can make it
easy and quick for ftp masters to review packages in NEW. The idea
should be, in my opinion, that any package that requires more than a
day of work to review should be rejected by default.


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

Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED

[Lars Wirzenius]

On Thu, 2018-03-01 at 11:59 +0530, Pirate Praveen wrote:
> It seems ftp masters are literally the masters with only a GR powerful
> enough to over turn their decisions. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881339#55

This seems correct, from my reading of the Debian constitution.

> I do not think this is really in sync with the rest of debian
> philosophy. I think the following steps would improve the situation.

I disagree with it not being in sync with Debian philosophy. The
Debian constitution is quite explicitly written to avoid concentrating
power in the hands of a single individual (the DPL), due to
unfortunate misuses of power long ago. It follows that power should
also not be concentrated into the hands of a small, self-electing
group (the technical commitee), either.

> 1. If a single ftp master is in disagreement, there should be a team
> decision (in previous cases of disagreement also, other team members did
> not get involved).

I'm not sure this would change the outcomes of ftp-master decisions. 
From experience, I find the team to have a pretty strong consensus and
would not expect the team as a whole to disagree with the decision of
a single team member. Overall, I think that's a good thing.

It might result in decision being more formally documented, perhaps.
That would probably be a good thing.

> 2. CTTE should be able to overrule a delegate when there is a conflict
> just like conflict between two debian developers.

I'm opposed to this. We would need a GR to make this happen, since it
would need a change to the constitution. I for one would vote against
such a change.

(I express no opinion on the root complaint about circular build
dependencies and how we handle them.)


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

Accepted vmdebootstrap 1.9-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 24 Feb 2018 20:54:16 +0200
Source: vmdebootstrap
Binary: vmdebootstrap
Architecture: source
Version: 1.9-1
Distribution: unstable
Urgency: medium
Maintainer: VMDebootstrap List <vmdebootstrap-de...@lists.alioth.debian.org>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 vmdebootstrap - Bootstrap Debian into a (virtual machine) disk image
Changes:
 vmdebootstrap (1.9-1) unstable; urgency=medium
 .
   * Add NEWS.Debian to warn about vmdebootstrap going away.
Checksums-Sha1:
 d928557c8bf21484430407d70db1f1053792562f 2156 vmdebootstrap_1.9-1.dsc
 a9f050735bdb46ff09b2856c08fbfd0be568b187 59616 vmdebootstrap_1.9.orig.tar.xz
 f403c27255e3c9cacd714289822039b35997f05f 6616 vmdebootstrap_1.9-1.debian.tar.xz
Checksums-Sha256:
 aef47c7170dd7d66d91fcc5171a03ffeb477c2c22a4e3aab86ee7f34a55e5c70 2156 
vmdebootstrap_1.9-1.dsc
 4525adcc30c7d97aedade021b0f99d56b41d43316547232f424ddff95a99d542 59616 
vmdebootstrap_1.9.orig.tar.xz
 cd17b9dc4ab93fa70c429c58c5b95f49a3cc2bf1f3c60b366bc45536dcdc1b84 6616 
vmdebootstrap_1.9-1.debian.tar.xz
Files:
 f599f28a9d65aff26c552c9a77e766cc 2156 admin extra vmdebootstrap_1.9-1.dsc
 4b2e0d1711642bb9b13db6337fa39e41 59616 admin extra 
vmdebootstrap_1.9.orig.tar.xz
 67665e6a85f43bc28d58a8a72d2bb066 6616 admin extra 
vmdebootstrap_1.9-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlqRudIACgkQbC+mFux6
IDFvcxAAj165ZWmb5Y1lfj5ezTR08PPBThCZd4vlEkbQLPyWEKN+Lq9/Z9XJmIe2
8uTGf5bBdq3UTL6ru/OZof+v8aA80pIFRMk3L52b5uh7qjDFVMLAZ8M2L5CiWX2Q
NZ43HUapF6sTWprGj9vZaqkodbHNxjPvPPFSD3aVGnYYxTIOxzLBr/MqwD36atqA
adWjPpHPenRYBE7J+7MbnZU54l76B5YTsp/02oQP2Kqj4n++i21ppt775uXbdZR3
cu8ZEHZCxqDJCEKqEpaz7bzrDTiTP94hKXiaIcBQBWE5d4ZLlVnTFY/ufcjS8OCe
GZJYFh3faXJCbY8whPyxctwsjWylA9HAyOerESCJ80uQG0dToXHGw+YN4rPqEInm
WnUzZ0DPqc8bVHPq9T/2zmEcAAwyFVaFtSU9FVAwMXhQqRIs+azL4QVhKPCkkjO3
RTBagEyRdyOPZL2gxjTEPMFhcbqdFE6fz++BbrlVxG8PtWYXRupNAH3w8HbDTcBy
pHzBAGhn8FR29OFo1TaGPFan2NdgZOSJxhoX5Y8XJFc+KdEGhj6o6YUrtQAEMrBh
hBrJ10uYKGXA8cxrRFnDfVuMmEsRobHbecExpRu7sUEtTzXfO1G8+VTPXrqIXqCc
OCnvQCPV5H5cydM9F8ZeEePB2wy7ivZuumNx192dmoPSiQfRAZM=
=Nc1v
-END PGP SIGNATURE-

Accepted vmdb2 0.12-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 24 Feb 2018 11:05:32 +0200
Source: vmdb2
Binary: vmdb2
Architecture: source
Version: 0.12-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 vmdb2  - creator of disk images with Debian installed
Changes:
 vmdb2 (0.12-1) unstable; urgency=medium
 .
   * New upstream version.
   * debian/copyright: Added Stuart.
   * debian/control: Updated Homepage, patch from Geert Stappers.
Checksums-Sha1:
 ed2fb41b0be62b1e239ab9e42af15acf27d26601 1795 vmdb2_0.12-1.dsc
 15ce284729ec38571ed21eb44d8da8c8a63937e8 22108 vmdb2_0.12.orig.tar.xz
 d6634e3b09c9400bd652f5a63b9081443a2d8c1a 1828 vmdb2_0.12-1.debian.tar.xz
Checksums-Sha256:
 7c4966b4a22480d2ce1abbb5d95273d5615c97acf8b6f23f4d3176e10817f844 1795 
vmdb2_0.12-1.dsc
 3969884b95e1b6d64a87f10b6085c61b44de8a058b965503c041305a93d25486 22108 
vmdb2_0.12.orig.tar.xz
 542fb75dbc89170e6fd1438f9efbbf900292bc425b6f03709c2b7898e4b94f81 1828 
vmdb2_0.12-1.debian.tar.xz
Files:
 1b3c59a787f53e59fa409caae0725323 1795 admin optional vmdb2_0.12-1.dsc
 818e0f9417d9f77029b57420eb88ba21 22108 admin optional vmdb2_0.12.orig.tar.xz
 832595c0a926e240c7bb02138f76b511 1828 admin optional vmdb2_0.12-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlqRL2oACgkQbC+mFux6
IDFZxA/+NsmKnCGfCeCBTM8/xhcQ+SlIrykwjBGtVv1p4C5OmZGuXuy0ZgFqr2jj
GRAfu4gYzdJRHOC+ioyHUO5zutExyuKJ6+PHixW8Gu4VWnYA7BSJDYZsuzsayuHc
kFmTmBfJ7HwEIXvnUzAXuOdNN6BlVkwWLYAYiC+BCshIlIIVP0Fs0zQV4OVvOOds
/yXSlJOghgFcwgfdVuWjmILZJHt1mF8sI9NN8mZdBOkxOnTEHcwwovkQTjwBNrxN
osnuWUyQFPp0QYVBvFbqg+ukCANMGkYRNsfBTl1sWlOOPvfjitUwCZWSCssUvtVF
kcOpIRvEjnPiZtwVbOQiAnBeHiWpQoAUHsdT/X2H8k9604woEEpJX5E0g69/6m/Y
CLmlkuiku+xw6q/5RSdfZm4ll2AX5Qnz2dA79WdCp7YSxOcR65qqAQ+lpckK0A1E
sJTj4skn/RVvNtM1CmqFivJ2mRmw6EB0skJYQB32cj5rdAlDrl67TaEXj1bALExq
kKvPUppagws8seeDqT+6JWQBDgJSKFJphR6t47C9t4TlACcp5ji1Uud5ek0lRJU2
XcmBl3FC2bYT30zOWdz0eAxAjo5p4ZCGsHVMrvzSnir+HZTYROUVvwSoAVgUhCaN
9AlWMRBP6BBd4/iIvWSftGa5cxQflzyToI+Cp0pTj+8CeTNKndo=
=m6th
-END PGP SIGNATURE-

Accepted cmdtest 0.32-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 24 Feb 2018 09:59:34 +0200
Source: cmdtest
Binary: cmdtest
Architecture: source
Version: 0.32-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 cmdtest- blackbox testing of Unix command line programs
Closes: 890628
Changes:
 cmdtest (0.32-1) unstable; urgency=medium
 .
   * New upstream version. A no-change release, to trigger an upload to
 Debian. (Closes: #890628)
Checksums-Sha1:
 998a64485cb35a1112b8774bdaa0fab01dd6d39e 1742 cmdtest_0.32-1.dsc
 d8a438bf03066c5498e552d9eee155d1985d1fb0 38880 cmdtest_0.32.orig.tar.xz
 43059fcdc63ff0c3d19b7632fe099281a0e58960 2276 cmdtest_0.32-1.debian.tar.xz
Checksums-Sha256:
 b4ee0b76d5166696ef8df49a87007335415d6cf694c54df73068c6b03798996b 1742 
cmdtest_0.32-1.dsc
 c6be8b13bc3538e26c6c9035d5494e6b12f3b4d52bcd4d7fa9ab4e1be0218c69 38880 
cmdtest_0.32.orig.tar.xz
 1d6535a320c0c0fe3928159c8d40f443241effe014ec86c10ea4712556bfcfa5 2276 
cmdtest_0.32-1.debian.tar.xz
Files:
 7e09cf32f114ac9559761e699e120cdc 1742 devel optional cmdtest_0.32-1.dsc
 e2bad0ab4ec062fa0d118b6cbab04577 38880 devel optional cmdtest_0.32.orig.tar.xz
 d3ff5886fc0e6f8b170dc797b78554b9 2276 devel optional 
cmdtest_0.32-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlqRH1QACgkQbC+mFux6
IDF0bw//UyOM1scRk8Obm76ie+kZGUQ849q92DxANQLimQsISYlo9yba4q4b43z1
EnKuLPti1TyqOJxhdewksRPVYoHvIMxxUhzOWWpLplCZYDUhgHOofwmVbbr7C5c/
6DOWz+bnMi/A3BAI6ON0SrM3tKtnDMfE/RM+5N0ZIO1KcEHMgdAuFZJihUlOXXXI
1Gdh0DrmSYB5poACF7/DFDXJ/uo4B9IUokn0rbGb/pO1LWkSrCELKQhtdt2cHerI
G34fGZvg71clvHzZ/V0nPJmQaw43+b1TPnynSC9J7gzrRllbRzfCXuVcLWNvPFtp
ewSwGobtj7x+h985YMrJ+MVPiHjXyaO2ADk02iUGFxc4lRLEUfnr9RAqQEM6PX3z
+fO0jTEdEUboNZjBVn+31CM21679t8Vh1xrTXlEnfobsQpLAUD14UKs6rxq9PKJ5
4zOGI8ZQi8ZbK5pJ7p/IDgFHe2+SB8ZtvN05wANSzveuTCCVJcooIvBxxPHyg6v0
F0aPD8A485XwvRkjxi/aXspSNXIxDYjDy0Xc7LPLW6KHLRMmeFf1U+RcuMOIWA4o
52+DTtD5jWpl7ez61G6LLrCInhMgKQdJemsTPxA67HsyU19VelZBoUKvpWkYkC15
RrsAEZ36ROrERFfGNE+hGA6sGjLz03FvcnWLW9aBKvOTu/UAosw=
=+WC6
-END PGP SIGNATURE-

Re: Extended Long Term Support for Wheezy

[Lars Wirzenius]

I don't have an opinion on whether this should be done on Debian
servers or not, but I have a comment on providing security support for
more than a decade. How do you plan to deal with the kernel? Do you
expect to backport security fixes to the wheezy kernel, or upgrade the
kernel to newer versions from time to time? A newer kernel may be
necessary for hardware support as well. What's your plan on that? In
addition to the kernel, the rest of the plumbing layer may need
upgrades to handle hardware support, security, changes elsewhere.

I wouldn't want to put a device with Linux kernel from the 2.2 era
(2013) on the Internet anymore. I wouldn't want to put a device with
4.15.4 in 2033.

Personally, I don't find backporting kernel and plumbing changes for
over a decade to be a viable approach. I find planning to upgrade
software on the devices is the way to go. On the other hand, I'm no
longer working on things expected to last 25 years, though I did do
that in a previous job.

While I'm sceptical, Ḯ'm not saying that it can't be done, so I'm not
objecting. Instead, I'm asking, what your plans for this are?


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

Re: Debian part of a version number when epoch is bumped

[Lars Wirzenius]

On Wed, 2018-02-14 at 18:52 +0100, Vincent Bernat wrote:
>  ❦ 14 février 2018 16:09 +0200, Lars Wirzenius <l...@liw.fi> :
> 
> > > > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> > > > this will be true with X 1:1.6 as well.
...
> That's exactly the point. You wanted X >= 1.8 and you get X 1.6.

I don't think that's what you said, or at least it was hard for me to
understand it that way.

> More concrete example (now a bit in the past). On Wheezy, you want to
> depend on a 1.8 JRE (you package independently). You put
> default-jre-headless (>= 1.8). Since you have forgotten about the epoch,
> this pulls Wheezy default-jre-headless (1:1.7-47+deb7u2). So you add the
> epoch to both your own package version default-jre-headless (1:1.8-1)
> and to the dependency. All good. You upgrade to Jessie and rebuild
> everything. Jessie comes with default-jre-headless (2:1.7-52) which
> shadows your default-jre-headless (1:1.8-1) package.

I think I now understand what you mean: you're actually worried not
that version numbers compare in illogical ways, but that people write
wrong versions in dependencies.

I don't think that has anything to do with epochs, and I don't think
getting rid of epochs would actually solve that problem. The root
cause for people getting version numbers wrong in dependencies, in my
expeience as a Debian developer, is that not all version numbers are
very simple, and that updating them is a manual task.

It's true that epochs make version numbers a little more complicated,
but not as much as sheer length. The median length of version numbers
in stretch is 8 characters, looking only at version numbers without an
epoch. Getting those wrong is very easy, even without epochs, and not
really harder than with epochs, in my experience. I admit an epoch may
trip someone, but it's not happening often enough that it's a problem
worth solving by getting rid of epochs, in my opinion.

I know of only two ways to get version numbers correct: automation and
testing. For shared libraries, we have automation. Maybe we can have
that for other classes of dependencies as well. For everything else,
we're going to need testing.

Automating all generation and updating of runtime and build time
depencies would be a good thing to have. Not an easy thing to achieve,
of course.

I, for one, would welcome a general AI for automating this. Skynet is
a worth it if we can get versioned dependencies right every time.

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

Re: Debian part of a version number when epoch is bumped

[Lars Wirzenius]

On Wed, 2018-02-14 at 11:54 -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 14 Feb 2018, Vincent Bernat wrote:
> > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> > this will be true with X 1:1.6 as well.
> 
> Only if your program is severely buggy.
> 
> Hint: either it matches dpkg --compare-versions exactly, or it is a
> severe bug.

For extra clarity:

$ if dpkg --compare-versions 1.8 '>=' 1:1.6; then echo 1.8 comes after
1:1.6; else echo no it does not; fi
no it does not
$ 

A version with a lower epoch (or no epoch, which is implicitly a zero
epoch) always compares less than one with a higher epoch. This is
regardless of what comes after the epoch in a version number.
Otherwise there would be little point to epochs.

For the gory details, see the policy manual:
https://www.debian.org/doc/debian-policy/#s-f-version


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

Accepted vmdb2 0.11-1 (all source) into unstable, unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 10 Feb 2018 17:56:41 +0200
Source: vmdb2
Binary: vmdb2
Architecture: all source
Version: 0.11-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description: 
 vmdb2  - creator of disk images with Debian installed
Changes:
 vmdb2 (0.11-1) unstable; urgency=medium
 .
   * New upstream version.
Checksums-Sha1: 
 a182c08f709e2fea41af63be3f6b9c997c4a0511 15004 vmdb2_0.11-1_all.deb
 5fb6f0e13800f1ba9c76d9590153767c6a130215 1802 vmdb2_0.11-1.dsc
 f663fbbda295dea39ca9d1c6e2d2ce31c449b3a1 22040 vmdb2_0.11.orig.tar.xz
 31c34356662d980f88de1f31c1b5af12ea6aeaaa 1748 vmdb2_0.11-1.debian.tar.xz
Checksums-Sha256: 
 7dacf26b2af7bcdacfd7c17596d65936b9041e9b7d61343f52076f260e49bede 15004 
vmdb2_0.11-1_all.deb
 1bd93b592a4ed6e88ad1518fd9a52ecf07e299b1cac2f0a85d86153e0b7c0fbb 1802 
vmdb2_0.11-1.dsc
 11222dc467350b8e3bf42622007f1d95ed08445734536ef7eab5cf42fc0213de 22040 
vmdb2_0.11.orig.tar.xz
 99e317d12a042bb26aca500ffa848378f8481c342287053ee994065c5e990b00 1748 
vmdb2_0.11-1.debian.tar.xz
Files: 
 270a99a05651d03a86bb3aae4ce6ee96 15004 admin optional vmdb2_0.11-1_all.deb
 13b13a04a21cf7fdcf899d4ed56c1f4c 1802 admin optional vmdb2_0.11-1.dsc
 1dc85afbda87b44e2fe1ade5b281aa6f 22040 admin optional vmdb2_0.11.orig.tar.xz
 02f78511d54dad48a1e98a4d87f220d6 1748 admin optional vmdb2_0.11-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlp/GSoACgkQbC+mFux6
IDGDiBAAqc8WmdJ/fKmUwNdY70CAHDtnv15wY3aXPRsdmKRCC1XkZEN3Ifmn2lIG
iiJtePOVft+gdkDxiZZ86eQzfoy/l7txIFoIqp+x9Fvo/Uv3ey/Nt/+CKzhNG9qK
zWlibFEL6dx/8H/JDTw5FXf/on8Gu6SMBcbGJXwQi1bw3DGLeF936X0R02G6/NH4
YDSoXs0GaW77TIW6fmwY5Cj/N5nLVN8x8FHXlQ+j6/q6wV5CQiWX/646C4SiXiBL
/8ljJQmroPFKuGvt57SOkSwXuMjirJgXZ7Kj5DV5EP4t7xakZgBXSjDUdtQOXkm7
1QjNoq3OStny6TPkSrS6CNXVyT3fmZbLQ3+dmAqIqf075l208fN7x+i+EyQKeql2
o7mponjALBJMU0VjG2hvmx3fsj4Lm/la1KXIQ60ILnwwoggDZZlXn6bX0I1cago0
gwfRkji26P+8sXAO1H4OdIo4vhTfzWparrz8hRqM730NqAtNXML/VJFeosqXHDJf
KhUip8sicoIdnQoNEt+9am4Q113xQKAnYw9YtecEpaHDNu37aYFRkRg4/W2Bb35Y
jjSvml5EacEoxtFwIQ2KfnwV23G4AvK06iom1v3lEaERDquQoFboWHota+TEi6Gx
7qNFo1iwcb+0hiqGY6q+BO08AoJFYHPIwMgpB9f0jbnoeBCNJaQ=
=DHVl
-END PGP SIGNATURE-

Bug#889826: ITP: vmdb2 -- create disk images with Debian installed

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius <l...@liw.fi>

* Package name: vmdb2
  Version : 0.9
  Upstream Author : Lars Wirzenius <l...@liw.fi>
* URL : https://github.com/larswirzenius/vmdb2
* License : GPL3+
  Programming Lang: Python
  Description : create disk images with Debian installed

 vmdb2 creates disk images with Debian installed. Conceptually it's
 like vmdebootstrap, except that the output is a disk image instead of
 a directory tree. Such images can be used for virtual machines, as well
 as real hardware.
 .
 vmdb2 is a successor of vmdebootstrap and intends to replace it. It's
 intentionally not backwards compatible with vmdebootstrap, however.

Re: Debian part of a version number when epoch is bumped

[Lars Wirzenius]

On Tue, 2018-02-06 at 13:31 +, Jonathan Dowland wrote:
> On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
> > This is one of the many situations where I'd like developers to *ask*
> > when unsure or uncertain of something.
> > So, in fact, the epoch bump was totally useless, and as it often happens
> > in those cases, it's causing headaches for somebody.
> 
> Maybe introducing epochs should force a round-trip through NEW...

That would completely ruin my plan to only ever release version 1.0 of
all of my future projects, but increase the epoch instead.

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

Re: Removing packages perhaps too aggressively?

[Lars Wirzenius]

On Thu, 2018-02-01 at 11:10 +0100, Abou Al Montacir wrote:
> In general I agree with this as a DD, but when I wear my user hat I don't.

I disagree, I'm afraid. As a user, the speed in which we do removals
from testing or unstable shouldn't matter to you. What matters is that
the software you need is in the stable release. For that, you need to
know that something is not going to be in the next stable release,
with enough time for you to request it to be included if it matters to
you.

(I think we need ways of helping users to do that, but it's orthogonal
to how fast we remove things from testing.)


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

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Lars Wirzenius]

On Thu, 2018-02-01 at 08:37 +0100, Christoph Biedl wrote:
> Adam Borowski wrote...
> 
> > Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove".
> 
> Sounds like a very good idea. For me, I could automatically parse these
> and check against the list of packages installed on my systems, or are
> used to build packages (thanks for .buildinfo files) outside the archive.
> 
> > After filing the ITR, if no one objects in a period time, the bug would be
> > retitled to Ro{M,QA} and shoved towards those guys wearing hats with "FTP"
> > written on them.  Such a period could be:
> > * (if we decide to CC ITRs to d-devel): short: a week?
> > * otherwise: long: 6 months?
> 
> The short period, but not *that* short. I'd expect any reaction will be
> pretty soon but allow people to be offline for a week. In the situation
> where removal is obviously the right thing to do, waiting months is
> mostly horror.


When the cost of making a mistake is high, it pays to spend a lot of
effort to avoid making them. If the cost of removing a package from
testing or unstable is high, we should put in a lot of effort to not
removing packages unless we're really sure it's worth it. Taking
longer to remove packages, to learn of negative effects such removal
would have, is such an effort.

On the other hand, there's also a cost to spending a lot of effort to
avoid mistakes. Being very careful at all times, and doing things more
slowly, tends to slow down development, sometimes by quite a lot. Case
in point: Debian used to be fairly careful about removing packages
from testing, but in the past couple of release cycles, removal from
testing has had a low threshold, and it's been my impression that this
has helped us do better releases with less pain.

The reason that has worked is that the cost of making a mistake when
removing from testing is low. If a package is removed due to having RC
bugs, fixing those bugs will let the package back into testing fairly
quickly, and automatically.

Removing a package from unstable has a somewhat higher cost, but it
seems to me that it it's still fairly low. Thus I would advocate
keeping the time-until-removal fairly short. In other words, a week 
should be OK.

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

Accepted mysql-5.7 5.7.21-1 (source) into unstable

[Lars Tangvald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 19 Jan 2018 08:13:12 +0100
Source: mysql-5.7
Binary: libmysqlclient20 libmysqld-dev libmysqlclient-dev mysql-client-core-5.7 
mysql-client-5.7 mysql-server-core-5.7 mysql-server-5.7 mysql-server 
mysql-client mysql-testsuite mysql-testsuite-5.7 mysql-source-5.7
Architecture: source
Version: 5.7.21-1
Distribution: unstable
Urgency: high
Maintainer: Debian MySQL Maintainers <pkg-mysql-ma...@lists.alioth.debian.org>
Changed-By: Lars Tangvald <lars.tangv...@oracle.com>
Description:
 libmysqlclient-dev - MySQL database development files
 libmysqlclient20 - MySQL database client library
 libmysqld-dev - MySQL embedded database development files
 mysql-client - MySQL database client (metapackage depending on the latest 
versio
 mysql-client-5.7 - MySQL database client binaries
 mysql-client-core-5.7 - MySQL database core client binaries
 mysql-server - MySQL database server (metapackage depending on the latest 
versio
 mysql-server-5.7 - MySQL database server binaries and system database setup
 mysql-server-core-5.7 - MySQL database server binaries
 mysql-source-5.7 - MySQL source
 mysql-testsuite - MySQL regression tests
 mysql-testsuite-5.7 - MySQL 5.7 testsuite
Closes: 887477
Changes:
 mysql-5.7 (5.7.21-1) unstable; urgency=high (security fixes)
 .
   * Imported upstream version 5.7.21 to fix security issues:
 - 
http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html
 - CVE-2018-2562 CVE-2018-2565 CVE-2018-2573 CVE-2018-2576
 - CVE-2018-2583 CVE-2018-2586 CVE-2018-2590 CVE-2018-2591
 - CVE-2018-2600 CVE-2018-2612 CVE-2018-2622 CVE-2018-2640
 - CVE-2018-2645 CVE-2018-2646 CVE-2018-2647 CVE-2018-2665
 - CVE-2018-2667 CVE-2018-2668 CVE-2018-2696 CVE-2018-2703
 - CVE-2017-3737
 (Closes: #887477)
Checksums-Sha1:
 8a5ff3493435e5394daceeefce432ae8782d13e2 3252 mysql-5.7_5.7.21-1.dsc
 63b07cfd33d494b223e9b4d73492d3508834abd0 48931457 mysql-5.7_5.7.21.orig.tar.gz
 a576fd9f138cdc94490002721641c51b5f80a663 153668 
mysql-5.7_5.7.21-1.debian.tar.xz
Checksums-Sha256:
 315114fd47fab2dff9632256c582343550da50895df6633bff109abb1deca2e0 3252 
mysql-5.7_5.7.21-1.dsc
 ad29ecb6fb3c3571394fe231633a2d1d188d49e9eb749daa4e8799b7630daa09 48931457 
mysql-5.7_5.7.21.orig.tar.gz
 9a375e417dd966652b202792b6ab3695262bba32ae49fb2f430ab67405588cd3 153668 
mysql-5.7_5.7.21-1.debian.tar.xz
Files:
 7bbe9ef368bdffd60e1f715aeee3f2f2 3252 database optional mysql-5.7_5.7.21-1.dsc
 27313ded360f39f237e99404666bc448 48931457 database optional 
mysql-5.7_5.7.21.orig.tar.gz
 06c60390c5d24f8610389d7de24b2db2 153668 database optional 
mysql-5.7_5.7.21-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJacbknAAoJEOVkucJ1vdUuDX8P/iku+UgvbPmY3ErRlLJGvNTZ
kiOURRGcTqUUclzF8sHq7s3ZipazWMjuWcyuEM/OaUvLqAvSxjs5cShXTQc80l2q
htAm++gXxzlMN1wgoEjfuchpYF5nni3tCj9zEcEguyPnwgmv0+SjnmClEjsFA1MS
8lnwbf+AQKnRAPGUC7iQcT1b34MIbFbjQBCtJ3aWsO1sBsXa6qgsiw80J8GGG73/
XTCYsOMRzjM6BzgaX9EiE35MNJShi94FpTbWNaMlRdPQ12zVbq0HnXecHnTbBu5C
/NmLebb6+Yys3ryUDOibuEgxtkE58dyjZhnX1RoTMb3Dcxa3MgUP1X1tM+enj+JO
SnFZXTMfUH49CxmGNx5CJ67GWAL2xpyEQAo7In+Wt30JvrSJJJ1Q/n1EY6XU+0g/
iT9Svriisy6Pc/SCqXEm8oA6TQ8fhSdJHwavOTfkiahJyI89NBAj+5QtkdP00+G5
+yGf3dYd5Jj1yoYva0ZpeFTY1HwlQOOMAS6KGGlPmymZWtY89JzfKSUmML0MZOeM
RMmm4gBnd/KAwwbD9AzQBHfRd+uTScZHaVsIrqMzHhiCeXX88dkv0OGeA6iW20pm
/V4McZ/j36TWmuPqcbLrEFJsFRKdVsfHoVkU/ygi8BUf/LoZHLQBz4o7lxmI3HAO
Bi6ojKpHfHjeN7nMIA29
=P2hh
-END PGP SIGNATURE-

Re: ITP: debos -- Debian OS builder

[Lars Wirzenius]

On Thu, 2018-01-11 at 11:00 +0100, Benjamin Drung wrote:
> Both tools create a Debian OS and use a Jinja config which allows
> specifying individual steps. Can the forces be joined?

One is in Go, one in Python. There's nothing similar in the code bases.
I see no chance of "joining forces", nor much point.

Bug#886238: Please introduce official nosystemd build profile

[Lars Wirzenius]

On Thu, Jan 04, 2018 at 10:44:24PM +0300, Hleb Valoshka wrote:
> On 1/3/18, Steve Langasek  wrote:
> 
> > Moreover, defining an official nosystemd profile in Debian signals that we
> > are willing to support it, which means any maintainers who refuse such
> > patches will immediately become the targets of abuse from anti-systemd
> > zealots.
> 
> "anti-systemd zealots" Steve, when did you join LP fanclub? When
> Ubuntu decided to throw away your upstart and use systemd instead?
> Should I remind your votes in CTTE?
> 
> Please take your Ubuntu employee hat off and speak as DD.

I think you're out of line. Please stop.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Why do we list individual copyright holders?

[Lars Wirzenius]

On Tue, Jan 02, 2018 at 09:33:08PM -0800, Steve Langasek wrote:
> These statements are not in contradiction.  Saying "this package complies
> with policy version X" doesn't say anything about what version of policy the
> package *should* comply with.  Our tooling should absolutely be optimized
> for reporting discrepancies against the current policy version, not for
> second-guessing the correctness of a given Standards-Version declaration.

In my opinion, we don't want a situation where packages get to choose
which versions of the Policy they comply to. They should always comply
to the current version.

The reason we have a Policy document at all is so that all the
packages work together. Some of this is simple: all manpages go under
/usr/share/man, all executables go in one of /bin, /sbin, /usr/bin,
/usr/sbin. Some things are more complicated. All in all there's a lot
of details to get right for 50,000 packages maintained by 1000 people
to form a cohesive, working whole.

The Standard-Version header in debian/control is one of the mechanisms
we use to keep track of where each package is, as far as compliance.
lintian is another. Unfortunately, many of the details are difficult
to test automatically, so can't only rely on lintian.

Over the past several years, I've spent less time updating
Standard-Version in my own packages than I've spent reading this email
thread. I don't want to ridicule anyone's concerns, but I'm of the
opinion that when it comes to S-V, the concerns seem rather overblown
to me.

(I would like to offer a tiny squeak of support for those willing to
do work to move stuff from out of the source package, when it doesn't
need to be there. Homepage, Vcs-*, Maintainer, and Upladers from
debian/control, at least, and debian/watch files entirely. Possibly
Section and Priority fields as well.)

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Lars Wirzenius]

On Fri, Dec 29, 2017 at 12:42:28PM +0800, Paul Wise wrote:
> On Fri, Dec 29, 2017 at 10:21 AM, Guillem Jover wrote:
> 
> > I'm also growing some URL switching fatigue when it comes to Debian's
> > git repos. And that's one of the reasons I moved all my packaging to
> > my own server some time ago.
> 
> This is just a symptom of a Debian design flaw that dates back to
> before we started using VCSen for packaging. We include information in
> the source package that can change independently of the source package
> (such as Vcs-*, Homepage, debian/watch, Maintainer/Uploaders etc).
> These should be stored externally to source packages and merged into
> the Packages/Sources files by the archive software.

+1

-- 
I want to build worthwhile things that might last. --joeyh

Accepted python-ttystatus 0.38-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 04 Dec 2017 18:27:18 +0200
Source: python-ttystatus
Binary: python-ttystatus python3-ttystatus
Architecture: source
Version: 0.38-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 python-ttystatus - terminal progress bar and status output for Python
 python3-ttystatus - terminal progress bar and status output for Python
Changes:
 python-ttystatus (0.38-1) unstable; urgency=medium
 .
   * New upstream version.
Checksums-Sha1:
 b00afbd3c47c0717dc3a5f0bf4151fb28922b696 1937 python-ttystatus_0.38-1.dsc
 1054671c226e59e900e6ca557a11c4cc37730d9a 27344 
python-ttystatus_0.38.orig.tar.xz
 9fcc70e82b07fe422939521e18ac335f42bc810f 2832 
python-ttystatus_0.38-1.debian.tar.xz
Checksums-Sha256:
 29a27e5c25fc6d357cf9498a8868bfd925b8a981f8e99ff3f9d8787689f8a0da 1937 
python-ttystatus_0.38-1.dsc
 e544dd5b0f77ebc3bb5b4ace34bd3d2751e72956ec096c8ffb34beaead433628 27344 
python-ttystatus_0.38.orig.tar.xz
 95c383f79b63488e0d8c108efec356fe1ced15356001edcb778c5ca0b8e28a96 2832 
python-ttystatus_0.38-1.debian.tar.xz
Files:
 cebb90b3a439cc3a01ba3500338a64e7 1937 python optional 
python-ttystatus_0.38-1.dsc
 cba1550dbab5936f72682a5671eb4990 27344 python optional 
python-ttystatus_0.38.orig.tar.xz
 d489c4943dff7d776aab0f5a3bd7112d 2832 python optional 
python-ttystatus_0.38-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAloleGUACgkQbC+mFux6
IDF5+xAAqL1k9GOTJiTjh/VFFOGRDs4jpMcyTRMfP1xSC3tHvTjCyQtctpDrYmnt
Cg01j18gPkbTPhVgMwCkEbI3s8+DiZbA/YFpa/vhHTbY2HlXbPGI1pc91PWOA1Vs
mlTjo9Ybh/BW1HrtjzsxVwWPpE+MWWoALi2NDkvTJtKkm1s9s2iMtx9A7u35BesY
MGat2aurlNg60NUOvomBF0Ky9Ohbf4LKglDbZ53WUpePrZjXLdl1cqeF/jv+gOlk
rn44QA8rmvIKBBGlGsSbr9Opkf13+Fi4/Ylin7Vn9uC8fkntqzshlYBjYkZ9xwyT
HpoScoX6neJb1r3HGhgDq6Choo1BIrUwCbrczIZjFqPhllwXmcevRTXOG9N+akfU
QXrEQ6ma2vDBM2OJcD4tnXr9wYic6Q6r6IvDGmslgROXn61uv19VJq/1ouF5UZgO
P9M54JOLGnjQcPZpQeILclHU7OhdmuPHqtMSzsI+vwObIm/hmFnao2bewZSpoz5z
rrJqOMvIrrvqNrWgLlIcdmiHjTly1mHJKqcFk/lIMdYORQD38SYx6xZsDXXE5x+V
zMBmpEEaENLPV2BWTyLcDNx3K4QdPt3W0974pPeivrTT3CZ9mHNHJSIphk5LjPEI
zsvmVk4emptHRBmZcEfhpZOAftoBh0jOhypIRH4+V173sedK2l0=
=0ZAw
-END PGP SIGNATURE-

Re: Debian Stretch new user report (vs Linux Mint)

[Lars Wirzenius]

On Mon, Dec 04, 2017 at 02:33:07PM +0100, Jeroen Dekkers wrote:
> Just because software comes pre-installed doesn't mean it is free. And
> if it is also impossible to replace the software you also can't update
> it with a free version so the user has even less freedom than when you
> can replace the software with something else.

While there is truth to what you say, and while it's a point that gets
brought up pretty much every time the issue of non-free firmware is
discussed, it is not a problem Debian can solve. We don't produce the
hardware, we have little say in the choice of the hardware, and there
is little we can do fix the freedom-related problems of software
embedded in or too tighly dependent on hardware - except that we can
explain the problems and pros and cons of possible solutions and maybe
point to less-problematic hardware choices. The result of this is not
a perfect world, but it might be a better world.

Just because a problem is currently too difficult to solve doesn't
mean we have to give up any hope of solving other problems that are
feasible for us to solve.

Myself, I would prefer us to keep both the free-software-only ISO and
the non-free ISO with firmware and other things needed to get typical
modern hardware running, and improve the discoverability of the
latter. I think we can do that without having to have a GR to change
the Social Contract or the DFSG.

-- 
I want to build worthwhile things that might last. --joeyh

Re: recommends for apparmor in newest linux-image-4.13

[Lars Wirzenius]

On Thu, Nov 23, 2017 at 03:01:09PM +0100, Christoph Hellwig wrote:
> That's still not an upstream default lsm.  Looks like someone in
> Debian just decided to make apparmor the default, which is horrible
> news :(

Hello, Christoph,

do you think you could manage to either point the general -devel
reading population to a discussion of why using AppArmor by default is
horrible news, or write that yourself? That would seem to be more
constructive than you just showing up after months of discussion
saying it's horrible news.

(If you need to, I can lend you my time machine so you can send the
explantion last year and we can avoid escalating things to the current
stage.)

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Proposed change of offensive packages to -offensive

[Lars Wirzenius]

On Wed, Nov 22, 2017 at 11:10:20AM +, Iain R. Learmonth wrote:
> Currently, as far as I can tell, sudo is build without PC_INSULTS. We
> should probably rename the sudo package to sudo-offensive.
> 
> This option is defined in the source code as "Define to 1 to replace
> politically incorrect insults with less offensive ones." and so by not
> defining this option, the package is explicitly built to be offensive.
> 
> Obviously we should allow for a transitional package here...

That seems like unnecessary complexity and work, to me. I'd be OK with
either letting the package be as it is now, or to build it without the
"non-PC" insults. Doesn't seem worth it to have two packages for this.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Lars Brinkhoff]

Adrian Bunk wrote:
> If anyone is running stretch, buster or sid on ARMv4t hardware, then
> please let us know what device and kernel you are using and whether
> you intend to use buster.

My StrongARM-based Netwinder machine has been lying dormant for a while,
but I was planning to bring it back up.  It's ARMv4 without Thumb.

Accepted python-ttystatus 0.37-1 (all source) into unstable, unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 11 Nov 2017 10:30:11 +0100
Source: python-ttystatus
Binary: python-ttystatus python3-ttystatus
Architecture: all source
Version: 0.37-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description: 
 python3-ttystatus - terminal progress bar and status output for Python
 python-ttystatus - terminal progress bar and status output for Python
Changes:
 python-ttystatus (0.37-1) unstable; urgency=medium
 .
   * New upstream version.
   * Fix debian/rules.
Checksums-Sha1: 
 cebb3afe5e7578e9ca813fcd64dc0700c2e11e44 15092 python-ttystatus_0.37-1_all.deb
 cf7e0e2c1f9d2e35b22e54a79aba6f89884e783d 14672 python3-ttystatus_0.37-1_all.deb
 3e4123efcc2a2b95ec5636bbdfe342d87ebfaac1 1937 python-ttystatus_0.37-1.dsc
 e675dcfbb8386141dba67fbae6767b9caacf6378 27128 
python-ttystatus_0.37.orig.tar.xz
 e39cd60ed06aaa62ea0dadc38fb12431ad835784 2816 
python-ttystatus_0.37-1.debian.tar.xz
Checksums-Sha256: 
 ed79d51cd972070e40e02a8990d6df3f85f43fb7d4f3ad05a4b4110887ccb6a8 15092 
python-ttystatus_0.37-1_all.deb
 decf4bf990d1927a8ea493947d82a0b342142c18cf780eaf8fb9facf86d51db9 14672 
python3-ttystatus_0.37-1_all.deb
 e81f01e4362167d95292371292ad1dbc3111090c60c2749fa6c65e2264b9b881 1937 
python-ttystatus_0.37-1.dsc
 89dc70da1e49b099bcc4b7332b266936ecd5c75223f4e4bf9b6add5064cb5712 27128 
python-ttystatus_0.37.orig.tar.xz
 43e91579f411d2046ba6bc4831ea5406800736c5afc6e457dc42cb76e4ee2497 2816 
python-ttystatus_0.37-1.debian.tar.xz
Files: 
 f8f919786b6088c3246020c1e0f6f52e 15092 python optional 
python-ttystatus_0.37-1_all.deb
 d1081aa9f54122d3b89943977e3d7d2f 14672 python optional 
python3-ttystatus_0.37-1_all.deb
 b925e388a13ec7afa68410cfd6a33d7d 1937 python optional 
python-ttystatus_0.37-1.dsc
 809cfe29f83ac119cb4a4de32f325a2d 27128 python optional 
python-ttystatus_0.37.orig.tar.xz
 b2a33cefb1054b32f6d53a33ea85eefb 2816 python optional 
python-ttystatus_0.37-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAloG2zcACgkQbC+mFux6
IDHuJw/6AtjHu+Hupvx1vM2TPes4v7I5VnlN4OKNGQox7RrzVVMvgYeSq9oO0lp6
wwbh4hw2TUXyz3FyMZRa1GxUqcxwz10DzL4uZi/SEkLHpQULAe2T4ZidgjeMhn0E
op7fUeb5UEOvoLnRh5YjSvMKkpEZD2EytbqauLEdHSc8cXkER0VsY2jXyXykxx3q
UACPaQMq2sw28AvMk3qAqYYu8XPieqoycRzctQyP1LC8OlFRr80KWXdiOWDIWuO7
z3jySqyliQZ5lnOYrATO59hoLWprsKlsUQfqkBDYounprk/t8YGbtpvpvVoiWXfE
kASvVsj2UxiG3fxgX04qOvcFobQHIOYMKeIur/2jHW+YmxqoA9ahemXOB2KgQlrn
tC8QZdt2N+qrAzJB1kvdHjJ5mnfP546VS8w8LpAf0Zex+tdtLjIuiFELZNSkK9cI
xLPEZdO4TvXFA5XPOF6iTYpTnzfZSZ64z848s3Kgtl+RrujYLp/KPKiQa2t3G/LL
0V51z+jKHqx+o6IkB7KcXOiOzr7TR5Dl8AnZOaAjJAEIqZMUrpSM4JufyhduPBDN
oFN7z8CseJZIreaU7NULBh524PpmhMw42Svf6mLWsWfZvWa+e0X1qRBTXZl1Iej9
M7AOK4pQaLg0wpRXvUexP/VLc5SGqgdh3DU1RRHrRvrtUJpV2vI=
=a+h3
-END PGP SIGNATURE-

Accepted vmdebootstrap 1.8-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 17 Sep 2017 17:02:13 +0300
Source: vmdebootstrap
Binary: vmdebootstrap
Architecture: source
Version: 1.8-1
Distribution: unstable
Urgency: medium
Maintainer: VMDebootstrap List <vmdebootstrap-de...@lists.alioth.debian.org>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 vmdebootstrap - Bootstrap Debian into a (virtual machine) disk image
Closes: 874525
Changes:
 vmdebootstrap (1.8-1) unstable; urgency=medium
 .
   * New upstream version
   * Add Steve to Uploaders. He did two NMUs and is willing. Drop
 Antonio, by request.
   * Set home page to current.
   * Update Vcs-* links (Closes: #874525)
Checksums-Sha1:
 8a3e6aae69d1f128af6729479b6bd0c11e482ecf 2156 vmdebootstrap_1.8-1.dsc
 5ad0720d4081428d5d11b9d7a9608bf82fe0feca 59068 vmdebootstrap_1.8.orig.tar.xz
 3e5a5d54a381db982093de4c47a49ff35a70116b 6028 vmdebootstrap_1.8-1.debian.tar.xz
Checksums-Sha256:
 4049c7424389ed5e4ed627969f96e86146dec84a2e8537aedcdf89e0c8264897 2156 
vmdebootstrap_1.8-1.dsc
 9b31a1ddacefe2d0b469c995185c5c82e00ba536cd13a7760463d811a8af79af 59068 
vmdebootstrap_1.8.orig.tar.xz
 d0382c65517440386cce33a9122434173fec3578fac685a3da93677f3b2a9fd3 6028 
vmdebootstrap_1.8-1.debian.tar.xz
Files:
 bfbf0bb9913d0c0dbb56aec6ca78209c 2156 admin extra vmdebootstrap_1.8-1.dsc
 aa51547e4f51dffed0b02b6ae3fbdac0 59068 admin extra 
vmdebootstrap_1.8.orig.tar.xz
 ccd70b7498bcdbf7bce1a1545adeff6a 6028 admin extra 
vmdebootstrap_1.8-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlm+gpoACgkQbC+mFux6
IDHvdhAAloPpvw2epzYrcsqKaQKoZBMNnyAlM7bSVw9YfsQon2HeCEzvkZOIvB6X
avxpMYcVnhW6riQtM1fJG0w0Iwk5Wu6DD7YxU/RpjaVTolytN+7Cobr402GKOdIV
/QluE8VAbW2rpjWdTbORBtqnswLRtpNQ69haGapPrqQKtU6DbB5RKEoqJhLcE3zf
sYikUBnLF/7al0i6KMM5UuE9RBKc3FxHp5wPrfSL3aAAVdXt4/xJDVQs9HH+5+Js
gVahWzQQ3sgp6m+6unzgN4mvRNN9CYmlcrMZuW57bvCyXtAAJo3ia1OJdciz2Ggw
poVV0mujjeKYYW6dykYfR685o4p84Xvw/rJ3MTzGeoTwDEGkx0gTFAMfHexv9kh8
MXn9Ajz4iY6jh4gIcRVP8Ahm0vtGCKR4GPi80L3V4qsXVBYywz7miK7/9Y8BWry6
nuzPgPcxOv8zWtvzYol7IDL5MnkScOvAoZtsEa+Y7eGtGKvHTOJ7wv3JLJeIc3iG
/LonlgmmGaNEPaxl3sI+gYWrBAdOy9rJFn4tqVy7rNwNLi29zNoaDBGRD/YXsaKM
UZKecI30tfYnq9SNUDcjIc4TVEubNX7waLyxnrBE6Y+UJVAq3xJAqLu/WigzHHTk
YyIKqo8HP6cFbEcyCIJB6rtbtJJNw6fokqdmE66T9+v7cgPs7eA=
=0nNj
-END PGP SIGNATURE-

Accepted python-cliapp 1.20170827-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 27 Aug 2017 10:22:16 +0100
Source: python-cliapp
Binary: python-cliapp python3-cliapp
Architecture: source
Version: 1.20170827-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 python-cliapp - Python framework for Unix command line programs
 python3-cliapp - Python framework for Unix command line programs
Closes: 873298
Changes:
 python-cliapp (1.20170827-1) unstable; urgency=medium
 .
   * New upstream version. (Closes: #873298)
Checksums-Sha1:
 3c87fee4cfdd5144599b79c97d4348b945419ad4 1957 python-cliapp_1.20170827-1.dsc
 8209d5c0db4afe66ea54b61b44f3552d53257d55 46820 
python-cliapp_1.20170827.orig.tar.xz
 3c9285eee075708eee18efd6e1301791f030bf4e 3572 
python-cliapp_1.20170827-1.debian.tar.xz
Checksums-Sha256:
 53ca3df9183f65bf394556b31f06c4dfcbc3cc06aa7a3b9144ddc96990d9d3e6 1957 
python-cliapp_1.20170827-1.dsc
 fdacb12f1ea32e4cdcf749cc18a8de9af27697d467f9256e38acd347a2b408aa 46820 
python-cliapp_1.20170827.orig.tar.xz
 e5d9a4ad779a2eb679f63557c91aef38f1ca1302357c7f5159129a82571b 3572 
python-cliapp_1.20170827-1.debian.tar.xz
Files:
 0983f281f3c4f01c2001ccfb935cf841 1957 python optional 
python-cliapp_1.20170827-1.dsc
 df11c91d6b2baa5d59cdd0f40825b205 46820 python optional 
python-cliapp_1.20170827.orig.tar.xz
 be6ee641f5978779ac61657012f54067 3572 python optional 
python-cliapp_1.20170827-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlmix0YACgkQbC+mFux6
IDHn4BAApveJF2nbYL7CXLHFhagMxrJCndMEuYy0niuAoiay09dOEPRvISqOz4xj
CZbNggoVHBWusjHV400pBQWgnCbb82yvQ3wujaoz3dVi93uYwy9sQA1edODTQMr4
VRQRhNlA5YxHquWDp+YkGUG3nuXiLLxvaYC33tDc6sSSAq63a/geo3FluY74p7qW
cvXqA8vHzXhEDnTdytrpsf3K60Qxgu4rx5WOcNmwo5150QCXw/4CQHwzylG71E6d
GDPI4IE4VSdeg0LEIg+7ss0W3XHlNXEBN5QFTYPP1m39oYr9aELqPPdCupmyc/ey
xC3N/k947QtPT3SmAww44LTADMgkpRvYXoKHiN7YeO3iQ4R/YG5sinc0crDOyxVM
CHm3D/BYLFshZ324KtiEx0DZjpvx/LCGILclbhOMigjL4MtT7Za2bjVd/hZr5jYb
hrtMG8W7f+F015j2cwdK92Z+ZrC7g6Kfv9nS1hCKS//8c6AUKHxMqzQMMS92/hTR
eg5JkNdKZ2AXSbFTBOjIy4nURaFPkAu+HDWmfqmeKKeU4GcPA9+bsKP3R/QUTrwX
keO8y6GNIxYJeZPloeNyPoz9uhAwgferDLju7U/HqZKH3ihzO2+fVBlr4XvqGiTf
FDyctvcNfjSJhSn+/3quJ5qfoo6ildie7Q+sRW+rLw2lbU7MbTk=
=PD4e
-END PGP SIGNATURE-

Accepted python-cliapp 1.20170823-1 (all source) into unstable, unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 23 Aug 2017 18:54:02 +0300
Source: python-cliapp
Binary: python-cliapp python3-cliapp
Architecture: all source
Version: 1.20170823-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description: 
 python3-cliapp - Python framework for Unix command line programs
 python-cliapp - Python framework for Unix command line programs
Changes:
 python-cliapp (1.20170823-1) unstable; urgency=medium
 .
   * New upstream version.
   * debian/copyright: Add Codethink to debian/copyright. (cliapp was
 worked by me, Richard Maw, and Richard Ipsum, while working at
 Codethink.)
Checksums-Sha1: 
 3b70ac5610061dff092385d24bc092c8b9febe7e 41570 
python-cliapp_1.20170823-1_all.deb
 dea0e49eae6b40672cdd44a3d17f2d56e7fd906e 45560 
python3-cliapp_1.20170823-1_all.deb
 6a0cda2a167b72ee4c685b86227899e62c15b4a7 1957 python-cliapp_1.20170823-1.dsc
 e70f8729950fd425cd20f482b64de0376a741926 46784 
python-cliapp_1.20170823.orig.tar.xz
 c8916bed13d979810bdbe76ce2d015133a58ece6 3560 
python-cliapp_1.20170823-1.debian.tar.xz
Checksums-Sha256: 
 2150ed150828347a538dfc3b3ed9ababb0d28743fd24171f7e41e2f2b82581a5 41570 
python-cliapp_1.20170823-1_all.deb
 00a103f149b214b801b372ab6c240f63fdc64c4049c3e91a8ec48d7fc234949e 45560 
python3-cliapp_1.20170823-1_all.deb
 de5e8de53320e58adf8ba69995b27897fb8739f58d0011dc6e2db7231a49f26f 1957 
python-cliapp_1.20170823-1.dsc
 868d0f33be3d0701a050594aec1ee41b110f894cbfa993639cd2a809eb5e3087 46784 
python-cliapp_1.20170823.orig.tar.xz
 da5c7af71befbf395cc374ecbc3a405967bffe8f616e532aef3796f15000d32a 3560 
python-cliapp_1.20170823-1.debian.tar.xz
Files: 
 55a92fa17f533892bff8c232867eef83 41570 python optional 
python-cliapp_1.20170823-1_all.deb
 e7fd507098a9bb71be1d04c07ddd58a2 45560 python optional 
python3-cliapp_1.20170823-1_all.deb
 00920f947f407756030db0fe74341b84 1957 python optional 
python-cliapp_1.20170823-1.dsc
 7c15be163435c2f16c0ab508b4875d40 46784 python optional 
python-cliapp_1.20170823.orig.tar.xz
 c092a0dbf98669e802de3c96ec113827 3560 python optional 
python-cliapp_1.20170823-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlmdqLYACgkQbC+mFux6
IDG78A//dmqB/FQcTPI+45aRPwGbQthiaC37f+9pPkWdSZfo9MMFMw1UK5JnLK9T
0IhC0plsRyrgmj0Q1LWD9jXswLKWucTxJn2xEGGpQbmII+VFlcayyCw3arrkJImb
1trGTSDbIu2UynXXYMz1eyqKj/dyq5BQpKpLukmbtqkjgiGw/GGFILNP5ayKLl8k
o0kJpZ5c9wUsb1v8zqqc4aIgIcczwt55Zzy2EbmeEea6ocZG9wGaunHrY9hwJH/g
RY6Nz5gN0+VekT3z2Vk35DFTUMLPDrtB/iPZM0siYUzgl5Rs47roeBL1JouGMOmj
b5/4XlURB5oHxY66gEyMC4xVv+nOOvNu3tgY1zVJ98tOrYOvnYt/cVzbazXLuPR7
n78Brt9rFcHR0iegYuJz3g2QKsEJxzCAZnoIZfOihv8jtTKyIELwHc54U+q6uQAY
ZqULK8z1NJNNj+xYptvOScRcn1bBYcMcs1aC/RErlCj3A3+/muNA1SQfTtQ/lDqv
CuDvDJ6XykkAmBYVQS/INUmhjvP3hx8BwGBXg+42dWvtLrSYU480sC+oRdKfL0c/
4E93ir/33cYhWs6/NmwXzJYUcK7j7w1cgrV4Xbvat5Q8hoFyb75E+wVd43Fnx5tC
8Bs48Pf9oKf2lQ6TFFv9PKBuvsy9H7GIaS/Wf/du/WX/u9m3wc0=
=qMpS
-END PGP SIGNATURE-

Accepted python-coverage-test-runner 1.13.1-1 (all source) into unstable, unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 05 Jul 2017 17:30:53 +0300
Source: python-coverage-test-runner
Binary: python-coverage-test-runner python3-coverage-test-runner
Architecture: all source
Version: 1.13.1-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description: 
 python3-coverage-test-runner - fail Python program unit tests unless they test 
everything
 python-coverage-test-runner - fail Python program unit tests unless they test 
everything
Changes:
 python-coverage-test-runner (1.13.1-1) unstable; urgency=medium
 .
   * New upstream version.
Checksums-Sha1: 
 e01dbfbef5e4b38163788c0d99b6dea67edb74fb 2048 
python-coverage-test-runner_1.13.1-1.dsc
 9c8eb9cc2ab1853b5057ea0becebf4c9f2b9ef9f 19244 
python-coverage-test-runner_1.13.1.orig.tar.xz
 6af47e0c7c9cf9a877c15e8b564dc74a43e87d6a 2224 
python-coverage-test-runner_1.13.1-1.debian.tar.xz
 22df90f535b547e2eac553da3c497808989b5381 6340 
python-coverage-test-runner_1.13.1-1_all.deb
 129b61675d78a0fda43c60ab62d8f602fcc96746 6420 
python3-coverage-test-runner_1.13.1-1_all.deb
Checksums-Sha256: 
 523507c74b30964ee557c67ded6ce8c5ff6f6da5c7e5a0336194b169004b9d85 2048 
python-coverage-test-runner_1.13.1-1.dsc
 b0fb586cae25dc60c5107e3d0756aed3c6155191c35d9e5411fb4867fc4e0a80 19244 
python-coverage-test-runner_1.13.1.orig.tar.xz
 2ca66b0cc582ed07147cd244ee32f651887335f5f5739f3b3280fb65e3832fe9 2224 
python-coverage-test-runner_1.13.1-1.debian.tar.xz
 84b4a887dc3e80f715de035931e134f7119ae0fbd4ecdc3b1af7a019458dd801 6340 
python-coverage-test-runner_1.13.1-1_all.deb
 90409b04f6341276a8b64bbb849b793f0b356874ab355d5392c6a4d08b6a6720 6420 
python3-coverage-test-runner_1.13.1-1_all.deb
Files: 
 9b110bc8352ad90689e97046fdfcfc35 2048 python optional 
python-coverage-test-runner_1.13.1-1.dsc
 b32354abb26b5aa47dfb5286eae3e206 19244 python optional 
python-coverage-test-runner_1.13.1.orig.tar.xz
 123943e36a8f302fb1c87ad0edd5e6fd 2224 python optional 
python-coverage-test-runner_1.13.1-1.debian.tar.xz
 e1bf05c98f426ca84ee1a0b7a383699a 6340 python optional 
python-coverage-test-runner_1.13.1-1_all.deb
 ea448268c01781d17601432a3a307125 6420 python optional 
python3-coverage-test-runner_1.13.1-1_all.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlldDkoACgkQbC+mFux6
IDHpbw//TjEwyFQ4YrvigXF3/aHTNnm7XgdXXFnbP+zM2p7JCvD+nMoa1jE+xyya
K1U8+9D7qL90Emlb2cBE3Lob9SbB7oTXdC+EQSIvGrV3SEvLcjcNWK/53GF17qav
oozznOln1Y4ZMZjH+ZrIn5bFg+zDiUyO6GEh0QyF27iZX7srwNcNgLJxhvbi7pA4
Nth6yMqmIlOBOe/ZE+dwsY929fn3WmyRi3ktSWyrGSPVVm0p1rKw4SFE1krrE2xd
2+6P3HMzxVMu3kXpM917qnLjdkIsEX9/ZRxx7YWBNTcwf3v8LNCYN565Z8d5xCGt
NE/SMFrXiI3750neafgvRXgtuBPkjb69HvszwJPJe+Pka/TA89PpM5mzDWSin9Cm
OHvX1RzmaxRWYuFRvcaDAvsIbHdZy1P5hgFf8oUZBH7zy9IG6VKpCgar/GsqHPPT
GNXbfq2mWX2f35SnS9IxG+EmWuLJdDqw2wwfJuywYeouFvSrqUdf/3vS3R2ff9X0
L6RDRqYqs2yAbHEHql1HqNCwFS9ai7RKdpHhYyTSs3Vlpc4bTfEYnw1lqHC1F9b5
dF+A46DLExxFqqFV2f26LA4AisIAyxFpcGzM7JOFvVn0ZaeWAg1evpFSKEpw+N4h
U2OlG/iBnxyobFmdsskPzPPV9gAIHwAiwPI1HzNHE6ZCsvXVBkY=
=FyY4
-END PGP SIGNATURE-

Accepted obnam 1.22-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 25 Jun 2017 13:30:00 +0300
Source: obnam
Binary: obnam
Architecture: source
Version: 1.22-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 obnam  - online and disk-based backup application
Changes:
 obnam (1.22-1) unstable; urgency=medium
 .
   * New upstream version.
Checksums-Sha1:
 66e781ae74256966f2986bf3b768315e47d2 2033 obnam_1.22-1.dsc
 f9868aabec80a3a8bd16a7213a7d64c0fddbdaaa 299312 obnam_1.22.orig.tar.xz
 dbcb825ae9816392256fb77b15e299a8382b0fa3 6776 obnam_1.22-1.debian.tar.xz
Checksums-Sha256:
 fce8373a8ed15cb91291f1d16f383942b690eff10b4188411352a1da21084971 2033 
obnam_1.22-1.dsc
 7d584615015724b1aad72c874b8682ed79e57b58136bfd68b6cb965e6a7c 299312 
obnam_1.22.orig.tar.xz
 624070017b8d0f651cc9a6ef2004629aa034882d4c6739e7b715c547e41339fc 6776 
obnam_1.22-1.debian.tar.xz
Files:
 24f92ad8bc03d53ba6f63c6e0d26b448 2033 python optional obnam_1.22-1.dsc
 ceb1a152554598077f028b190c07c548 299312 python optional obnam_1.22.orig.tar.xz
 f56e9ea81d95d057132bed86dcffd5d6 6776 python optional 
obnam_1.22-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAllPng8ACgkQbC+mFux6
IDEHLA/+NaXWg4SbPdHVW9gZs9em0EyXads6AP4fjBGtlYzUArb31+FGSFP7e+eL
nMIGkvgyeHUTxD8NiS/MH/03PYk0gcWgB4aaVEXenUypjUEzfNZG1+TqZCT2rDdt
FvEurvFynBgy8CAaqNX9TXyj45X+QBGTTA5y2au31UtHdBC8MLQO1qUmWhNqPJCd
tqdg0G3FNqoASjQ93G1Fd4lAKrXiYlhWcCE4ue9RCpoiHWAbS0mh2nFY6JBeLOf4
lEDbXaCzaIKJfZjvpO1wI9uRCwY0VVcZd2FWNxsCc8Yr/WqHDKU/VdGtlM7TdqBK
mXp+LeTI51OuzHmvnB3t42o4UO5k9pWy6gQzIFTnBS9Gufg/1/obdf0HjEht5Did
6n3dKHnlfBCUjjdzIjI5Dww5hh+OXQXxhRCoryqkBQG99fUJlvk/UKcP5EuJZhoF
sG+2vOVgonElP4oZIO4ZfFVFxcRpSW4CsU4AEh7dIDdPfrFio5z3fPTAxi6hxofO
rycfXFlBKDE+mGwTVX5CvZIkOzD1X14Z3JEfVc72tUZha4q3abPpGeG57x9aOKsH
jkBEGqPPDLtA/HMK2du7OSVPVeGkn+Zr66lqeseeXZonAnbixRIRKDaa0QMR5N0V
DvYk2KGfHcoLU7gq+skhE9vQ7lnS9MipkAA5zhCNIebEfJmNt+U=
=FlBZ
-END PGP SIGNATURE-

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Lars Wirzenius]

On Mon, May 15, 2017 at 01:42:09PM +0200, Arturo Borrero Gonzalez wrote:
> On 15 May 2017 at 13:30, Paul Wise  wrote:
> > TBH if I was confronted with the new LXDE web design with CSS turned
> > on, I would probably just close the page. The old page is way more
> > informative and less heavy on the marketing.
> >
> 
> Hi Paul,
> 
> I believe that what we are actually looking for is a bit of
> improvement in the marketing side.
> Modern and fancy things.
> 
> The LXDE example is good on that.

http://lxde.org/ seems to be the site in question. I agree with Paul,
I don't like it, and when I encounter pages in that style, I tend to
close the window.

* It's not nearly information-dense enough. www.debian.org is too
  dense, but the lxde one goes too far in the other direction.
  Something in between would be good.

* It's hard for me to navigate or to find anything. It has a short
  one-sentence summary ("Desktop environment for all"), but nowhere on
  the front page does it mention that it works on Linux. That
  information is probably on some other page, linked from the front
  page, but finding that is someone else's job.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Accepted mysql-5.7 5.7.18-1 (source amd64 all) into unstable

[Lars Tangvald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 19 Apr 2017 07:23:52 +0200
Source: mysql-5.7
Binary: libmysqlclient20 libmysqld-dev libmysqlclient-dev mysql-client-core-5.7 
mysql-client-5.7 mysql-server-core-5.7 mysql-server-5.7 mysql-server 
mysql-client mysql-testsuite mysql-testsuite-5.7 mysql-source-5.7
Architecture: source amd64 all
Version: 5.7.18-1
Distribution: unstable
Urgency: high
Maintainer: Robie Basak <robie.ba...@ubuntu.com>
Changed-By: Lars Tangvald <lars.tangv...@oracle.com>
Description:
 libmysqlclient-dev - MySQL database development files
 libmysqlclient20 - MySQL database client library
 libmysqld-dev - MySQL embedded database development files
 mysql-client - MySQL database client (metapackage depending on the latest 
versio
 mysql-client-5.7 - MySQL database client binaries
 mysql-client-core-5.7 - MySQL database core client binaries
 mysql-server - MySQL database server (metapackage depending on the latest 
versio
 mysql-server-5.7 - MySQL database server binaries and system database setup
 mysql-server-core-5.7 - MySQL database server binaries
 mysql-source-5.7 - MySQL source
 mysql-testsuite - MySQL regression tests
 mysql-testsuite-5.7 - MySQL 5.7 testsuite
Closes: 844275 860547
Changes:
 mysql-5.7 (5.7.18-1) unstable; urgency=high (security fixes)
 .
   [ Lars Tangvald ]
   * Imported upstream version 5.7.18 to fix security issues:
 - 
http://www.oracle.com/technetwork/security-advisory/cpuapr2017-3236618.html
 - CVE-2017-3308 CVE-2017-3309 CVE-2017-3329 CVE-2017-3331
 - CVE-2017-3450 CVE-2017-3453 CVE-2017-3454 CVE-2017-3455
 - CVE-2017-3456 CVE-2017-3457 CVE-2017-3458 CVE-2017-3459
 - CVE-2017-3460 CVE-2017-3461 CVE-2017-3462 CVE-2017-3463
 - CVE-2017-3464 CVE-2017-3465 CVE-2017-3467 CVE-2017-3468
 - CVE-2017-3599 CVE-2017-3600
 (Closes: #860547)
   * d/patches: Dropped fixes that are applied upstream
 - fix_test_events_2
 - fix_mysql_config_flags
 (Closes: #844275)
   * Add connection_control plugin (LP: #1633485)
 This is a security-enhancing plugin (disabled by default)
 that enables rate limiting of connection attempts
 https://dev.mysql.com/doc/refman/5.7/en/connection-control-plugin.html
   * d/server-core.install: Remove my-default.cnf
 The config file has not been maintained in a long time, and would
 cause errors if used with a 5.7 server. Removed from build by upstream
 .
   [ Robie Basak ]
   * Drop innotop
 The bundled innotop util was not maintained. For details, see:
 
http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2017-January/010180.html
Checksums-Sha1:
 af67fd65dedae7d9456bca2ef343b46a3bf69272 3255 mysql-5.7_5.7.18-1.dsc
 346e91db0160434488493966054eb25f712c89c8 61612105 mysql-5.7_5.7.18.orig.tar.gz
 56966d0cfdbabe0d51bc75951c210315bd53a763 3291820 
mysql-5.7_5.7.18-1.debian.tar.xz
 a190b5166c01a6348ad9aec3f05da212da673cf9 1297472 
libmysqlclient-dev_5.7.18-1_amd64.deb
 890b10d01eba096a6382e24829130385141b2bf2 1850642 
libmysqlclient20-dbgsym_5.7.18-1_amd64.deb
 f076f3447dcfd0a672247a343615a0946ef2070e 952002 
libmysqlclient20_5.7.18-1_amd64.deb
 d19eb6461cd58daf0b975930b7576af3c65f809b 6632684 
libmysqld-dev_5.7.18-1_amd64.deb
 bb7e772b5989845ce8991239a2411c8cb6e1995d 11942 
mysql-5.7_5.7.18-1_amd64.buildinfo
 fe2ee423f84c712d1e897c6a1e431e477ab13ac8 17671678 
mysql-client-5.7-dbgsym_5.7.18-1_amd64.deb
 0b2454ca645499b2a1081fc24f4b5a4ffe30f8e9 2431644 
mysql-client-5.7_5.7.18-1_amd64.deb
 0d00a2bdf10938ef5f048d2ae15b01205367c3e1 62065540 
mysql-client-core-5.7-dbgsym_5.7.18-1_amd64.deb
 5685df980ff2fa7c6f384a831bf760c50bd9e025 7033952 
mysql-client-core-5.7_5.7.18-1_amd64.deb
 76e8fe99a025f6fba7c4586c83f8312d434e6499 155492 mysql-client_5.7.18-1_all.deb
 c34bac40e8945d51844412d9ff077899b1e79d57 17281462 
mysql-server-5.7-dbgsym_5.7.18-1_amd64.deb
 8f3a10d4a881432a4251cabfd296f6d1b64d7b09 3308928 
mysql-server-5.7_5.7.18-1_amd64.deb
 f2b42501d7a4c8003a37f1f24cb64bc6b168b6ec 82381706 
mysql-server-core-5.7-dbgsym_5.7.18-1_amd64.deb
 9758078b9bf11ed94b2d940df774f6dc6b802ba9 7817456 
mysql-server-core-5.7_5.7.18-1_amd64.deb
 45fe61e86b866ded445232b0668a005dd3efe4ce 155616 mysql-server_5.7.18-1_all.deb
 d6044bbee6421e366b70e802c8df3be3cccd14a6 61932096 
mysql-source-5.7_5.7.18-1_amd64.deb
 ce3d9d9b2fad849264fd7e8b6435296fcf321933 122285890 
mysql-testsuite-5.7-dbgsym_5.7.18-1_amd64.deb
 2b35d7d6b0b700cc30de2f360ec2a3a724c6dcc6 22613380 
mysql-testsuite-5.7_5.7.18-1_amd64.deb
 78cc66836a7628b4a4e8fd59952358246ae5b64f 155474 
mysql-testsuite_5.7.18-1_all.deb
Checksums-Sha256:
 9e9e7e368c90e5f3d7624603efd8195c833a85fb2cc4d2400ee9e3df316b4d83 3255 
mysql-5.7_5.7.18-1.dsc
 ae6f5e2cf7b936496cf60260cd7fd5a0862c21f48cd240448021c4ea067a0f0c 61612105 
mysql-5.7_5.7.18.orig.tar.gz
 3941392c361f78e3d83bda640d070e4e35af3ecd2fff1c251a6bd010b389f372 3291820 
mysql-5.7_5.7.18-1.debian.tar.xz
 c41c5daf45364a3e9d626570f40be9b11510a4d00fa6fbfad830d38cf7ba

Bug#860453: ITP: sparseutils -- interact with sparse files

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius <l...@liw.fi>

* Package name: sparseutils
  Version : 0.0.1
  Upstream Author : Richard Ipsum <richardip...@fastmail.co.uk>
* URL : https://pypi.python.org/pypi/sparseutils/
* License : GPL3+
  Programming Lang: Python3
  Description : interact with sparse files

 This package contains the utilities sparsemap and mksparse. Sparsemap
 lists the areas of a file that are holes and data, and mksparse creates
 a new file with holes and data.


The test suite for Obnam, my package, will be using this in the future.

Re: Bug#860170: node-brfs -- browserify fs.readFileSync() static asset inliner

[Lars Wirzenius]

On Thu, Apr 13, 2017 at 08:59:30AM +0200, Wouter Verhelst wrote:
> On Wed, Apr 12, 2017 at 10:16:18PM +0100, Jonathan Dowland wrote:
> > On Wed, Apr 12, 2017 at 03:35:46PM +0200, Bastien ROUCARIES wrote:
> > > Subject: Re: Bug#860170: node-brfs -- browserify fs.readFileSync() static 
> > > asset inliner
> > 
> > This should have "ITP" in the title of the bug.

Best achieved by using reportbug, which gets all the details right so
that those who need to, can filter out WNPP related bug reports.

> > > Browserify is an JavaScript tool (compiler) that allows developers
> > 
> > 
> > should be "a", "an" is used if the following word begins with a vowel.
> 
> (or the letter h followed by a vowel)

A hat, a hotel. a helmet. Unless the speaker has a dialect where
they're an hat ("an 'at"), etc. It seems Cockney is one such dialect.

I'm not a native speaker. The rule I was taught is "it's an if the
next word starts with a vowel _sound_ when spoken". Javascript starts
with a J sound. An elephant starts with a trumpet sound, which kind of
a vowel.

English is too complicated. We should all switch to Finnish instead.
Free Finnish lessons at Debconf. Lipputangonnuppi.

To bring this into the topic of Debian development, there used to be
people running spell checkers on package descriptions. Is that still
happening?

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Fwd: can anyone review diaspora-installer?

[Lars Wirzenius]

On Thu, Apr 06, 2017 at 11:17:26AM +0530, Pirate Praveen wrote:
> Sharing with wider debian community, hoping to get some support.

I'm afraid I cannot give my support to this. I'm not involved with
release management, so this is just one rando developer's opinion.

> Current version in unstable does not have any RC bugs

Possibly it should. Looking at

https://sources.debian.net/src/diaspora-installer/0.6.3.0%2Bdebian4/diaspora-download.sh/

If I read that code correctly, it downloads code from github, and
installs it. There is no verification step that the downloaded content
is valid and hasn't been substituted by an attacker. This seems to me
unfit for a Debian stable release. I would expect the package to check
the checksum of the downloaded tarball, or similar mechanism.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: System libraries and the GPLv2

[Lars Wirzenius]

On Thu, Mar 30, 2017 at 10:30:44AM +0200, Florian Weimer wrote:
> * Lars Wirzenius:
> 
> > A compication in this is that even though the developers of a program
> > would be happy with linking to OpenSSL, people who've written other
> > libraries the program uses, or other code included in the program, may
> > not be. I'm such a person. If some code I've released some code under
> > GPL2 (only), and you link use it in a way that causes it to be linked
> > with OpenSSL without asking me, you'll make me unhappy. I'm unlikely
> > to sue you (life is too short), but I might grumble lengthily into my
> > cup of tea.
> 
> This is interesting.
> 
> Do you hold the same position regarding newer versions of GCC (which
> have changed the libgcc license to GPLv3+ (plus exceptions), which is
> probably as GPLv2-compatible as the OpenSSL license)?
> 
> On some architectures, libgcc is required for full “long long”
> support, so it's not really optional even for C.

I say I want people to ask before they do something that my licence
doesn't allow. You want me to have an opinion on another licencing
situation. I don't want to play this game. It'll just end in me asking
probing questions about other people's tea preferences.

Instead, I'll repeat that licenses shouldn't be violated. One way of
achieving that is to ask copyright holders for additional permissions
that are needed to avoid a violation.

I don't like convoluted, controversial re-interpretations of legalese
to achieve Nirvana.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: System libraries and the GPLv2

[Lars Wirzenius]

On Thu, Mar 30, 2017 at 10:09:20AM +0200, Vincent Bernat wrote:
> Well, that's really new to me. Why would you object to link to OpenSSL?

I'm not sure how to respond to this.

I don't understand why it is new to you. The conflict between the
OpenSSL and GPL licences is well known, at least within Debian. I
don't like weakening the GPL for my own code.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: System libraries and the GPLv2

[Lars Wirzenius]

On Thu, Mar 30, 2017 at 08:14:25AM +0200, Vincent Bernat wrote:
> As Carlos, it's hard for me to believe anyone will object to OpenSSL
> linking, all the more when they implemented the support for it.

A compication in this is that even though the developers of a program
would be happy with linking to OpenSSL, people who've written other
libraries the program uses, or other code included in the program, may
not be. I'm such a person. If some code I've released some code under
GPL2 (only), and you link use it in a way that causes it to be linked
with OpenSSL without asking me, you'll make me unhappy. I'm unlikely
to sue you (life is too short), but I might grumble lengthily into my
cup of tea.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#829076: general: Random freezes but the mouse can still move

[Lars Wirzenius]

(Reply-to points at me, I doubt there's any need for much discussion.
If you disagree, tweak you headers accodingly.)

On Sun, Feb 26, 2017 at 02:06:17PM +0100, Geert Stappers wrote:
> On Sun, Feb 26, 2017 at 01:00:03PM +, Debian Bug Tracking System wrote:
> > From: Lee Garrett 
> > To: 829076-cl...@bugs.debian.org
> > Subject: close
> > User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.23)
> >  Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
> > 
> > close
> 
> Why?

Timeline of this bug:

* John Muir reports problem on his computer (GUI freeze, details
  irrelevant right now).
* Abou Al Montacir responds and tries to help.
* Lee Garrett responds as well, suggesting one of the Debian support
  channels.
* John Cuffs tells Lee to "shut the fuck up", and quotes a spam that
  isn't visible (anymore?) in the bug log.
* Lee closes ticket.

To me this looks like behaves like an unpleasant person, and Lee
possibly confusing the two Johns with each other and closing the
ticket under the assumption that John Muir doesn't want to be helped.

In any case, I think Lee's first response is correct: the BTS isn't
the best place to diagnose the problem. If a diagnosis is done and a
reasonble culprit is found, an more realistically actionable bug
report should be opened, and until then, closing this one seems OK,
even disregarding John Cuffs's attempt to moderate the discussion.

While I have your attention: it's February 26, and Sunday, so you
should make a backup today and then verify that it works.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Accepted python-cliapp 1.20160724-2 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 05 Feb 2017 09:19:14 +0100
Source: python-cliapp
Binary: python-cliapp
Architecture: source
Version: 1.20160724-2
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 python-cliapp - Python framework for Unix command line programs
Closes: 852882
Changes:
 python-cliapp (1.20160724-2) unstable; urgency=medium
 .
   * Fix "FTBFS: Test failures" by disabling build-time checks
 (Closes: #852882)
   - when -1 was uploaded, the tests passed, but pylint is
 now a newer version with new checks
   - Debian is in a freeze, this is the minimal change to work
 around the bug; the tests have passed in previuos uploads,
 with an older pylint, so disabling them should be sufficiently
 safe and less risky than hacking up code at the last second of
 a release cycle
Checksums-Sha1:
 05692251cfb8adf560ae9b8cf596106873b57838 1862 python-cliapp_1.20160724-2.dsc
 ff4b921298254ff54b640a1a3eb562bed6631e82 3728 
python-cliapp_1.20160724-2.debian.tar.xz
Checksums-Sha256:
 aa362859254b1d9e2083d68594c0b94f3de1ccc531654617edb3a8f81d28085a 1862 
python-cliapp_1.20160724-2.dsc
 33cdb79779bc66698c421052904e97cd33a908526c2e1214247e6a28998a5e5c 3728 
python-cliapp_1.20160724-2.debian.tar.xz
Files:
 cf1a2a60b638ace00ed82f4656382767 1862 python optional 
python-cliapp_1.20160724-2.dsc
 275764954ded0774c6eee4a76af7594a 3728 python optional 
python-cliapp_1.20160724-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAliW4/MACgkQbC+mFux6
IDHjsRAAlK7OYHIHd28aUf5AmkOItVfb45tXMvZzpghPN1tBYIbrQyJmI65oiYWx
1shfjbs9xRmurI99NpEVYd+4uatP/tFYmiyIMKF2KlL2wFLdYQDJ5LZaNnzcREEI
NuPBf7GznrfjfXu88jm98w217YVtFjT2V0TfvCYvI9X2+DFovxZc1YuqdBSXu8YO
mJKH7xkbdivPwxq8aEEdccMpzahZdBVImIju4fgDpUOAin69pIyE1eliztV+g0kt
mK1h/KvSb+L558lSHQyk9+Kbw38tSLhF3YG5O7M0SBwipZtW9qknmKpnm6qqvnDB
v8qhp8qivsPa/FR6Phi06htDvtM7wfrj6XAqw8ivIzYAPvYHPvtUi+XvNozufOB3
zkOrGek9jkUMAkkkcrdtA7hlSYmWqV5GtK+Oj4puAhxORx+bTWjjUX4NIFwm+fJm
W/dSDuABMIKUXV1TgWVvH/Up9LOT0DKbqjsnZXC3135cjPgx8DuGDBan8trBlGYg
vhQ05RmLlts5H8dPzSdZIkoChcsvh+oHw5+zpELU+QtzHDvM1bTSTjkfZwQ/0Lcf
cm4XwVr80FdPWakd9kEOzN9I69s8C/8bM9lfkYevJB6FRyaUOgcqVBWhuGSDcRGO
Eu3UUURxiQ0lDVI1EFPU0fTWxQylKSzIL39bymfTHfTrTwZIc9k=
=YF4U
-END PGP SIGNATURE-

Accepted mysql-5.7 5.7.17-1 (source) into unstable

[Lars Tangvald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 01 Feb 2017 01:12:18 +0100
Source: mysql-5.7
Binary: libmysqlclient20 libmysqld-dev libmysqlclient-dev mysql-client-core-5.7 
mysql-client-5.7 mysql-server-core-5.7 mysql-server-5.7 mysql-server 
mysql-client mysql-testsuite mysql-testsuite-5.7 mysql-source-5.7
Architecture: source
Version: 5.7.17-1
Distribution: unstable
Urgency: high
Maintainer: Debian MySQL Maintainers <pkg-mysql-ma...@lists.alioth.debian.org>
Changed-By: Lars Tangvald <lars.tangv...@oracle.com>
Description:
 libmysqlclient-dev - MySQL database development files
 libmysqlclient20 - MySQL database client library
 libmysqld-dev - MySQL embedded database development files
 mysql-client - MySQL database client (metapackage depending on the latest 
versio
 mysql-client-5.7 - MySQL database client binaries
 mysql-client-core-5.7 - MySQL database core client binaries
 mysql-server - MySQL database server (metapackage depending on the latest 
versio
 mysql-server-5.7 - MySQL database server binaries and system database setup
 mysql-server-core-5.7 - MySQL database server binaries
 mysql-source-5.7 - MySQL source
 mysql-testsuite - MySQL regression tests
 mysql-testsuite-5.7 - MySQL 5.7 testsuite
Changes:
 mysql-5.7 (5.7.17-1) unstable; urgency=high (security fixes)
 .
   [ Bjoern Boschman ]
   * Imported Upstream version 5.7.17
 .
   [ Lars Tangvald ]
   * Updated mysql_config flag patch for 5.7.17
   * Upstream version 5.7.17 fixes security issues:
 - 
http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
 - CVE-2016-8318 CVE-2016-8327 CVE-2017-3238 CVE-2017-3244
 - CVE-2017-3251 CVE-2017-3256 CVE-2017-3257 CVE-2017-3258
 - CVE-2017-3265 CVE-2017-3273 CVE-2017-3291 CVE-2017-3312
 - CVE-2017-3313 CVE-2017-3317 CVE-2017-3318 CVE-2017-3319
 - CVE-2017-3320
   * d/copyright: Add files for connection_control plugin
   * d/*.README.Debian: Fix spelling errors
   * d/libmysqld-dev.lintian-overrides: Override "depends-on-obsolete-package
 depends: libmysqlclient-dev => default-libmysqlclient-dev" which is a
 false positive for src:mysql-5.7
   * d/control: Add myself to Uploaders
 .
   [ Andreas Beckmann ]
   * d/copyright: Fix more issues noticed by lintian: drop copyright info for
 files that were removed upstream, reorder shadowed sections
Checksums-Sha1:
 77089653456630036feccef86384778a74009221 3255 mysql-5.7_5.7.17-1.dsc
 6d848f7ea596a7a81a353415189f04452ef20df6 61480982 mysql-5.7_5.7.17.orig.tar.gz
 ed75f23599501640fc64a0d060a385e293e5741f 3386860 
mysql-5.7_5.7.17-1.debian.tar.xz
 cd75124787695bf9e8dd27818308db6dd4d9f633 6659 
mysql-5.7_5.7.17-1_source.buildinfo
Checksums-Sha256:
 ebb6a0c630b833b6b2f9c02666eaf93166c0d29884b1534c455b19000e5db971 3255 
mysql-5.7_5.7.17-1.dsc
 b75bba87199ef6a6ccc5dfbcaf70949009dc12089eafad8c5254afc9002aa903 61480982 
mysql-5.7_5.7.17.orig.tar.gz
 fdd9f5ffdda3aa56f5439e2b4554c2d34d92f9365f887f7ce3e480de35636490 3386860 
mysql-5.7_5.7.17-1.debian.tar.xz
 e055e155aca358db7e75c46c475ea8a95186b3adfb9e3de2bcf3d9e7b665b97c 6659 
mysql-5.7_5.7.17-1_source.buildinfo
Files:
 032df72c072dd7c650c329d9a255af12 3255 database optional mysql-5.7_5.7.17-1.dsc
 cfabc622427f149a8b8301a251a0484d 61480982 database optional 
mysql-5.7_5.7.17.orig.tar.gz
 215cac48f2c3684ff17845f979e08993 3386860 database optional 
mysql-5.7_5.7.17-1.debian.tar.xz
 58ac53b63541d01c4d495c1eff4d54ab 6659 database optional 
mysql-5.7_5.7.17-1_source.buildinfo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYkSm/AAoJEF+zP5NZ6e0IrP8P/1h4F88FH64Ta8RHouuEYnZj
50CxgBMzNXS/u+VYRxOAi7DtnXSpNZ+bF7D//iiM8Oj73eDwMvX5OZpdc01BSgLS
DIrbHkoiEst8mWLc/KUIGPr/Fje+QSmT7eybTWgs7VY6lvKJlarfKUldlrxRpKzd
l0lxGq/dWI2+mdBrKDwGtsEBnx/IclpLwe8vNE1ZbfUyD9oov8TzyqIQehm/PURZ
MdxGPol4vRNAVG9KrBkABOk/374q9kJsVQan/2n3KJ81qJ22xdtbqwQgkDpEimZq
N96HmddEauR97Rp/0b30OLvj4ngz4kt/UcEYa0r/cJ0swRqu85j3XP2dqKfVEaJH
lwTbWJf3PNtfOVubkWdvky2TeYRZqgx56hqm62uhbQv930XeKyYT7VEIIgBUR+oO
ZXsZvtZuIWEfTtE5cxT0u+d5HDL/JWEGUAbIBnGnGHkFQUunfJSJSRNZ1wCSEbSm
vWYlU9YzQmDqtDTAtuEDbYMV4c+OLJgkU+CpsBEf3e2vsJ4PjI585iiw1R9LCaia
yfOqzwRGk8/mVy2zpfS73XjoGtagr86FuoLBhp6vKlsDyzaALJGpH4peqmhiwNVB
27zzoklj2zJTkEj2VPbpHcRGPS32nrJokWloycc0cVVxeyKS7hcjgC4wiPFuUm6i
0PIpNgh1SJY9t+0OAWkf
=Mal9
-END PGP SIGNATURE-

Re: Git hosting for code that provides Debian services

[Lars Wirzenius]

On Mon, Jan 30, 2017 at 10:31:41AM -0700, Sean Whitton wrote:
> Sorry, my e-mail was poorly worded.  I'd like to know why Lars thinks
> that they are not sufficiently free.

I don't want to spend much time on this (there are backups to make and
test) so I'll just link to the infinitely wise Bradley Kuhn:
http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Git hosting for code that provides Debian services

[Lars Wirzenius]

On Mon, Jan 30, 2017 at 07:16:59PM +0530, Pirate Praveen wrote:
> On തിങ്കള്‍ 30 ജനുവരി 2017 07:05 വൈകു, Lars Wirzenius wrote:
> > Is the Gitlab software still an "open core" product of Gitlab the
> > company?
> > 
> 
> git.fosscommunity.in is running Gitlab Community Edition, code that is
> DFSG compliant and accepted in debian main
> https://tracker.debian.org/pkg/gitlab
> 
> gitlab.com runs Gitlab Enterprise Edition. See
> https://about.gitlab.com/products/ for different products of Gitlab Inc

Right, so the answer is that Gitlab is still an "open core" project. I
therefore repeat that I find it sad that it's being pushed as a
service for Debian to use.

I personally don't find "open core" projects to be fully free
software, even if they follow current DFSG, OSI, and FSF criteria. I
may be in a minority with that view, of course.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Git hosting for code that provides Debian services

[Lars Wirzenius]

On Mon, Jan 30, 2017 at 06:57:46PM +0530, Pirate Praveen wrote:
> The entire idea of that instance is to make a 100% Free Software public
> git hosting service available to the Free Software community.

Is the Gitlab software still an "open core" product of Gitlab the
company?

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Accepted mysql-5.6 5.6.35-1 (source) into unstable

[Lars Tangvald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 17 Jan 2017 12:41:15 +0100
Source: mysql-5.6
Binary: libmysqlclient18 mysql-client-core-5.6 mysql-client-5.6 
mysql-server-core-5.6 mysql-server-5.6 mysql-testsuite-5.6 mysql-source-5.6
Architecture: source
Version: 5.6.35-1
Distribution: unstable
Urgency: high
Maintainer: Debian MySQL Maintainers <pkg-mysql-ma...@lists.alioth.debian.org>
Changed-By: Lars Tangvald <lars.tangv...@oracle.com>
Description:
 libmysqlclient18 - MySQL database client library
 mysql-client-5.6 - MySQL database client binaries
 mysql-client-core-5.6 - MySQL database core client binaries
 mysql-server-5.6 - MySQL database server binaries and system database setup
 mysql-server-core-5.6 - MySQL database server binaries
 mysql-source-5.6 - MySQL source
 mysql-testsuite-5.6 - MySQL 5.6 testsuite
Closes: 847992 848118 851156 851234
Changes:
 mysql-5.6 (5.6.35-1) unstable; urgency=high (security fixes)
 .
   [ Andreas Beckmann ]
   * Stop building the unversioned metapackages, these are now built from
 src:mysql-5.7.
   * mysql-server-core-5.6: Add Breaks+Replaces: mysql-server-5.5 for the moved
 innochecksum manpage.  (Closes: #847992, #848118)
 .
   [ Lars Tangvald ]
   * Imported upstream version 5.6.35 to fix security issues:
 - 
http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
 - CVE-2016-8318 CVE-2016-8327 CVE-2017-3238 CVE-2017-3244
 - CVE-2017-3257 CVE-2017-3258 CVE-2017-3265 CVE-2017-3273
 - CVE-2017-3291 CVE-2017-3312 CVE-2017-3313 CVE-2017-3317
 - CVE-2017-3318
 (Closes: #851234)
   * Fix failing test main.events_2
 The test was failing after 2017-01-01 because of a hardcoded date in the 
test
 Added workaround patch, pending upstream fix.
   * Fix ftbfs with newer libedit versions
 The new version had an api change, causing the cmake check to fail.
 (Closes: #851156)
Checksums-Sha1:
 519ca2b073f5c326df6652fd2914ef960dec9861 2735 mysql-5.6_5.6.35-1.dsc
 a971f01d711addd87c860fb534d51139a73d5319 32167628 mysql-5.6_5.6.35.orig.tar.gz
 d79d38229bf08f8550c5624c404ee71e4540afa9 249340 
mysql-5.6_5.6.35-1.debian.tar.xz
Checksums-Sha256:
 9636b1669d928eb28f1f21a49883828901f96695d6be15c26f41d69842130e92 2735 
mysql-5.6_5.6.35-1.dsc
 dddcba169b98844d7c65346cbd791c853edf942d78440381685087b84aa35020 32167628 
mysql-5.6_5.6.35.orig.tar.gz
 af86365a9b64114d5cb685d65082b4a03e257d357a444e1675c2f3547c36a397 249340 
mysql-5.6_5.6.35-1.debian.tar.xz
Files:
 3cfb212766b9325dbb911554268fba7c 2735 database optional mysql-5.6_5.6.35-1.dsc
 e4f170f6f73aa94c0d8da90019545908 32167628 database optional 
mysql-5.6_5.6.35.orig.tar.gz
 a036542f6a3824318c41e726eed7845c 249340 database optional 
mysql-5.6_5.6.35-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYgiC5AAoJEF+zP5NZ6e0ItRgP/R/QVWG9at7cRLJM/3QlyU2P
J+kLDC1ce4/qYAxu77f1w94S9qQ759tMuLU0huQK/eg0GTPC3udjmP+AzW3TiBRi
FGf9n/AGdgCyGR1KQbL8uwbEmmHXWOW+EjHKhp9WtByyMdIiQGCL521kxHroqP5S
9wPFFjcj4+IDQXclylBc0YUWe7WiHhhjIr7bvrQuCVJYeZK2mhx4YRyA9K16wUtJ
oXhIo/bEuktZhMDtUn8nTDM53/+9a2PzH4HK4k2lPv0NCWaJ7BBDGbbeMsc/Ly18
cUqpk3s12ux9uMIdQmjnC/1/xKd8g/cZcNAkO61UBuWKuHbn39wNvRmKjiLAfY8Z
gSvAcEQ+QMidyoEsPsYgLzmTnTU+/TA3VpciUioLn6mtj6HU/bGUvYjbV+tpg/Ca
DoCEa/Xm3pFTIAMFiZVa7Oapy+IY0s8p0dPljQoSLJvyDqW0advmW3qSgvSNaGpC
QaJdiQmU7ipqIx+1yFRr/ycoFwmmjXFkLRckdjFCgkrNAXgDwm9KrwgGftCblSWo
WFS9EvhqXN2qZEX7v8jeH3R8VqOAL5smObzPlKwiZXY+96t9/bZrhSOG/jZcpX/n
PE0OBD4Fq7XG8dtLtQFfRNAgdLtRV4aq1drBMNm3cTqMPwB8hyuu3P9LDl18PwWh
e5gNKdU5rzDdP71MnTJE
=Cz1b
-END PGP SIGNATURE-

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Lars Wirzenius]

On Mon, Jan 16, 2017 at 08:50:57AM +0100, Ole Streicher wrote:
> Sean Whitton  writes:
> > I agree with the principle that test failures should be RC by default.
> 
> This is something which seems to have no disagreement here. My concern
> is just that I want to have a simple way to override this, to assign
> this to a different package etc. I want to have the same flexibility
> here as for bugs.

A failing test means there's a bug. It might be in the test itself, or
in the code being tested. It might be a bug in the test environment.

Personally, I'd really rather have unreliable tests fixed. Unreliable
tests are like playing Russian roulette: mostly OK but sometimes you
get a really loud noise that makes your parents and loved ones be
ashamed of you.

Picture this: a cocktail party. Many people mingling around, dressed
up and engaging in smalltalk, sipping colourful drinks. A new couple
arrives and is immediately surrounded by old fiends. "Hi, Jack and
Joan, how are you? How is that lovely offspring of yours?" The couple
look down, and their faces get a careful, blank expression. "It's not
good. We don't know what we did wrong. We're so ashamed. We don't know
how such a thing could happen. We thought we were such good parents."
A shocked silence fall on the group, in the middle of the hubbub of
the greater party. "You see, our child, our child..." Jack sobs and
can't get the words out, so Joan takes a deep breath and speaks. "Our
child wrote a test that fails randomly, and released it." One by one
their friends leave the group, quietly, and without speaking a single
harsh syllable. But for months, they had to wait for an invitation to
a new party.

Apart from social exclusion, unreliable tests waste a lot of time,
effort, and mental energy. When a test fails, you have to find out
why. What caused the fail? Is it because the test it bad, or because
the code it tests is broken? If you let a test fail randomly, you have
to debug that test many times. It also kills confidence in the test
suite: if all tests pass, is that too also just a random fluke? Can
you actually make a release, or should you do some tedious manual
testing just to make sure flaky test success didn't cover up a bug
somewhere?

Until an unreliable test is fixed, in my opinion it'd be better if the
test suite didn't fail because of it. Run the test by all means, to
gather more information for debugging, but don't fail the whole test
suite.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Python 3.6 in stretch

[Lars Wirzenius]

On Sun, Jan 08, 2017 at 06:27:57PM +0200, Lars Wirzenius wrote:
> Python 3.6 isn't even in experimental yet

This bit was wrong. 3.6 is in experimental. That doesn't change my
point about a transition being too late now, however.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Python 3.6 in stretch

[Lars Wirzenius]

On Sun, Jan 08, 2017 at 04:58:01PM +0100, Galbo Branbert wrote:
> I couldn't find any official statement if Python 3.6 will be the default
> interpreter in stretch (as it was the current stable when the soft freeze
> happened it should be, right?)

Python 3.6 was released 23 December. The stretch transition freeze was
on 5 November, a month and a half earlier. Upgrading the default
Python 3 from 3.5 to 3.6 is a transition, and given the number of
Python packges, it's likely to be a large on. What's more, Python 3.6
isn't even in experimental yet, so it seems to me that it's way past
the time when switching to it would be appropriate. After all, the
point is not to sneak in a new version at the latest possible moment,
but instead make sure whatever version of Python is in stretch, and
all the packages that use it, work very well

It'd be nice to have the newest of the newest of everything in a
Debian stable release. That seems to be incompatible with actually
making a stable release.

This time, us Python users need to compromise and make do with a
slighly older version of Python. It's not too bad.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: unattended-upgrades by default

[Lars Wirzenius]

On Sat, Jan 07, 2017 at 12:04:54PM +0100, Santiago Vila wrote:
> Now we can't be the Universal OS, no matter what we do :-)

Distro development is difficult, let's go shopping.

Sarcasm aside, here's a summary of the situation, as I understand it.
tldr: let's not despair, we have a mostly technical problem that's
simpler to solve than choosing a default editor, we can handle this.

We'd like most hosts running Debian to get security updates as soon as
possible after the updates have been received. This would make Debian
users more secure, and also the whole of the Internet. A simplistic
approach (unattended-upgrades plus automatic rebooting) is not going
to work. However, we can do less simplistic approaches, we just need
to design and implement those.

This is a big change, and it's way too late in the stretch cycle to
make it now. However we do it, we'll want months of use on real hosts
to find corner cases and special cases. It will have to wait for the
next release of Debian. Thus we're not in any great hurry and can take
the necessary time to do this right.

So far we've identified at least cloud images as a case where
automatic upgrades and related reboots are probably not particularly
painful. Even for those there's going to be cases where they're
unwanted. However, having the necessary software to do upgrades +
reboots and enabling them would still be a good default. Add an easy
and well-documented way to disable upgrades, and we should be good.

Arguably the same approach should work on any system without a
graphical desktop installed. On those, using the interactive features
for notifying the user is probably good enough, with the exception of
hosts where a desktop is installed but never used, and the server
solution is enough for those.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Accepted mysql-5.7 5.7.16-2 (source) into unstable

[Lars Tangvald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 03 Jan 2017 07:44:43 +0100
Source: mysql-5.7
Binary: libmysqlclient20 libmysqld-dev libmysqlclient-dev mysql-client-core-5.7 
mysql-client-5.7 mysql-server-core-5.7 mysql-server-5.7 mysql-server 
mysql-client mysql-testsuite mysql-testsuite-5.7 mysql-source-5.7
Architecture: source
Version: 5.7.16-2
Distribution: unstable
Urgency: medium
Maintainer: Debian MySQL Maintainers <pkg-mysql-ma...@lists.alioth.debian.org>
Changed-By: Lars Tangvald <lars.tangv...@oracle.com>
Description:
 libmysqlclient-dev - MySQL database development files
 libmysqlclient20 - MySQL database client library
 libmysqld-dev - MySQL embedded database development files
 mysql-client - MySQL database client (metapackage depending on the latest 
versio
 mysql-client-5.7 - MySQL database client binaries
 mysql-client-core-5.7 - MySQL database core client binaries
 mysql-server - MySQL database server (metapackage depending on the latest 
versio
 mysql-server-5.7 - MySQL database server binaries and system database setup
 mysql-server-core-5.7 - MySQL database server binaries
 mysql-source-5.7 - MySQL source
 mysql-testsuite - MySQL regression tests
 mysql-testsuite-5.7 - MySQL 5.7 testsuite
Closes: 841592 844275 847231
Changes:
 mysql-5.7 (5.7.16-2) unstable; urgency=medium
 .
   * Fix the test main.grant_user_lock when run as root
 The test was to log in as anonymous user, but would use the current system
 user. This was ok in most cases, but failed when the test was run as root
 since root has its own mysql user by default.
 (Closes: #841592)
   * Fix invalid build flags being used by mysql_config
 mysql_config was pulling in build flags from the build environment, causing
 build failures in other packages if the environment contained invalid 
flags.
 It now uses a whitelist system instead.
 (Closes: #844275)
   * Limit number of mtr parallel tests based on aio-max-nr system setting
 On systems with many cores the test suite could fail or be unstable because
 each server needs a certain number of aio slots. Build now limits max test
 parallelization based on the max number of slots available on the system.
   * Fix upgrade issue from mysql-5.5 in Jessie
 An innochecksum file was moved from server to server-core in 5.7, causing
 file conflicts when upgrading.
 (Closes: #847231)
   * Added patch to fix failing test main.events_2
 The test uses a hardcoded date (2017-01-01), and fails after that date.
 The patch is temporary pending upstream fix of the test.
Checksums-Sha1:
 0249b7d7f891272350eb0dfd4e9cb1538ab0acd3 3213 mysql-5.7_5.7.16-2.dsc
 2dfc780382d3762e1b59b3b370085d8d9e1b7d85 3389688 
mysql-5.7_5.7.16-2.debian.tar.xz
Checksums-Sha256:
 56aa64b6bf356f068e9e41fca92204ed5d38d1b284f931184a097b8b4cb14c5f 3213 
mysql-5.7_5.7.16-2.dsc
 f936a2846fb61e0ec29e488fc8f4dc03503430bf508f8c5960fadbccffc609fb 3389688 
mysql-5.7_5.7.16-2.debian.tar.xz
Files:
 940567923538855719705aa7b8f7c47e 3213 database optional mysql-5.7_5.7.16-2.dsc
 f835061f73c144a72eb483ae675c8b54 3389688 database optional 
mysql-5.7_5.7.16-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYa/cjAAoJEMAFfnFNaU+yf0QQANaAwyvgV/wHSHtRtrjSoWVE
TPBfGACvjChdN6Jo13wlJD6tiu+6VUTsQPecbclxSQQ9CZn3KylDUcvoz0w9czLy
MRj4QrEcnBpaV+yf1dGNfzG+VMoOJ0YhdU7yVmhqj3yt0TGOP39mXrEmf8IJteRh
zeMJ953CQTaZrFtclCgKFGeyP566VS/ByME/G02RPVFnOzHCjwrEsbO3M6CRRyxD
jLzceiMU4xkV2Bcd4ibuZ3hfQlrMy4i08SMUKkoLVuk/a7Fk4DXj7HQ1sc1Mes/x
ri9xvBlqsSe8+Oy1/dlUXzK9JRd2qfqIakRMymM3JM74rUFP8Mm3K3LgRXcPdWn5
/oXDFB9kcajvvc/k7thlmPg/OECF/NU6NZnrAXjZtzWxtKF9dINgJ/ZMXf2wZlN5
nB5I8ht2H2Z4JlqweekpalJ/OKXlkH0tUoKXTzqTq2LjzL4QGUkKuKGyGqwgu5dc
P6bMCdVrvemO310rlWZackr3qTcBOEiNx7RqyCR8fjpEmXMgM7KKjM/6cY13dDnz
ogohYKzNjnfZOvBxzaFdZuazOKOOGWiNYmfscsb+W0zLzMxWMV+xbE5/2VW2CQG0
KR1By0fNE366YRg8LI/to/Pybvl7MSXP4aX0vqkBtVGPp56AYM9Mg78xrvL0ejZC
z8iTQhJf8gJYhjNpjbhG
=vfew
-END PGP SIGNATURE-

Re: Can we kill net-tools, please?

[Lars Wirzenius]

On Thu, Dec 29, 2016 at 08:17:01PM +0100, Bernd Zeimetz wrote:
> In my opinion ip provides all the things you are mentioning - what are
> you missing? with -o as option the output is rather easy to parse.

I find ip's output hard to read. I have to take time to visually parse
it every time, I can't just skim it. The ip -o output seems parseable,
but no easily extensible (I'd prefer something like YAML instead).

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Can we kill net-tools, please?

[Lars Wirzenius]

On Thu, Dec 29, 2016 at 10:30:26AM -0500, Theodore Ts'o wrote:
> OK, you can remove the last half, but keep in mind there are plenty of
> people who aren't using the exotic features provided by iproute2, and
> are very happy using the more convenient and shorter BSD-style
> commands.  If you're going to remove it _becase_, the least you can do
> is to make the transition a bit more gentle.

For stretch+1, what I'd like to see is a tool that a) works b) has
output that's nice for a human to read and c) has output that can be
easily processed by programs. None of the current tools comes anywhere
near. Bonus points if the command line syntax is reasonbly nice, and
the manpage doesn't start with a BNF syntax description.

Of, you know, I can continue to mostly ignore things since I'm in the
vast majority that doesn't do or need complicated network setups.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Accepted obnam 1.21-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 29 Dec 2016 17:11:54 +0200
Source: obnam
Binary: obnam
Architecture: source
Version: 1.21-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 obnam  - online and disk-based backup application
Closes: 849596
Changes:
 obnam (1.21-1) unstable; urgency=medium
 .
   * New upstream version.
 - Fix --one-filesystem bug (Closes: #849596)
Checksums-Sha1:
 39366ba072a3a5f3cf17a2b9239d4ca95ed94a5a 2033 obnam_1.21-1.dsc
 0352817e36206278006a779cdcdfe8278a4ab71d 295800 obnam_1.21.orig.tar.xz
 a162f313771f3510eb6273c2bbd8067c5353c58b 6756 obnam_1.21-1.debian.tar.xz
Checksums-Sha256:
 fdaa71ea8d04866226bd9e1a66011d1e06767199af29e0a0403c57fa14caaf0a 2033 
obnam_1.21-1.dsc
 7e859dc5ac464240bfc387d3b534a85804fdd3abe136c07e388a4150b0be9162 295800 
obnam_1.21.orig.tar.xz
 946654088de004c811f7f3e9a6f1a1465bf6d1b524d79b6f65d8da4c13c3cbe9 6756 
obnam_1.21-1.debian.tar.xz
Files:
 2a2371abc72c756982c9e19524176c42 2033 python optional obnam_1.21-1.dsc
 3a44bc426633f928429f317561654725 295800 python optional obnam_1.21.orig.tar.xz
 59de97ccc56031c48e69a1741fb9133f 6756 python optional 
obnam_1.21-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlhlP3sACgkQbC+mFux6
IDEvORAAj1AIsIJlNXugIynqhrMGa+tzvDXZ7z3bPg2s+wvHiTG2TMCiJOQiGWBU
Oi6GakO/3o3TwmF+iCgm8iDVWnbE98UY/E59Spd13eZJPMhgWOEL6JRvq3sk01bI
7M09SExRN/9PX1BhXsKCOoE+OK4q6u/dW+HraMXfryFd2I4SCt3Zyf27g3z3Or7j
kXnGPfSKH/ISBlOzlrDhcAu371E/nmJ/Fn9b0mBO/Akw9YwNniPFaIAOZeUnsarD
I7KJoQ1hz+0y01emEpqG4oo7uA27s0NEfH10KlB0cMDi4iDS4NBm0cDv826VI1gm
Svo2pPE4m0R/27+cz1YPu/KxyrMry4Ouep4Q6WozeQwPg/jx759z3eKJethPOrMh
uHI8GViY1fYwx88ZxGch7ImmwGWYRLKqVpdSeUK+U7FAm0ypdB4kom+7pcBs5gNX
oGWy/xcdZX53y+jeLRAISNRnGtNLjMdQxJmUUbDbtjO9jfMQGaaSqIJYiTTY+njk
vWbf+Q9ryRxCuMJWibzv4aucEZbqBSjqd+kYZ/RktxTHj3c+6R20c+fBzyBwYU/A
9/l9QoNzpUI5/MkXqsnO4nPZPheHmOW3uKE3VIbWOuJyOtEtxphT5Q+HSiHETrfL
EE/Zrb000YKi3vcXCkf6OzggRJBqTBBBFmhtcixj3Vn0SCQJ1hk=
=rLQ/
-END PGP SIGNATURE-

Accepted python-ttystatus 0.34-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 26 Dec 2016 10:39:34 +0200
Source: python-ttystatus
Binary: python-ttystatus
Architecture: source
Version: 0.34-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 python-ttystatus - terminal progress bar and status output for Python
Closes: 844235
Changes:
 python-ttystatus (0.34-1) unstable; urgency=medium
 .
   * New upstream version.
 - Fixes FTBFS (Closes: #844235)
   * debian/control: Require Python 2.7.
Checksums-Sha1:
 7914af6ec03757c76be0e8b2e3a26de28ba739af 1830 python-ttystatus_0.34-1.dsc
 0272997b61eccbb6761d00f729d1ebc1e7ee818e 29920 
python-ttystatus_0.34.orig.tar.xz
 2ba38ab4beaa3b370df8c51f29ba37636493e03d 2784 
python-ttystatus_0.34-1.debian.tar.xz
Checksums-Sha256:
 9da58792795da54962c1971c59bfcee325982119931fbcbcdcbf1f13f5f9d1b3 1830 
python-ttystatus_0.34-1.dsc
 151717480ecdef067e6a7a432b882129c5a2f5fe83faf7f20dd6b085535c90f8 29920 
python-ttystatus_0.34.orig.tar.xz
 3c182f30d9fc7564eb5772d0b977aa2618dbf9576ad6a25b4e496286de76b9ef 2784 
python-ttystatus_0.34-1.debian.tar.xz
Files:
 8edaf9d4c05ac1043a2a5d55f21c824f 1830 python optional 
python-ttystatus_0.34-1.dsc
 128486d983eefafe603b0974dc5972dd 29920 python optional 
python-ttystatus_0.34.orig.tar.xz
 32936e418b3389c27c7955c102574eac 2784 python optional 
python-ttystatus_0.34-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlhg2HMACgkQbC+mFux6
IDHYOw/+OtBHa8c/5mWDVxUt4Mw8gzQMqTMdCbByGasTsnKjQju0YS/rS2QqCX67
s0zGto68NE14xzX7H7WJSQp4HCMiS+sRVv9Og3zlylQMvFoGHqgwV7Iwj6ZaPqgY
udkejKP75Gm0wg+66bGZNloc4M8AdAYj1ZIX97tPaw8/rgzI017aILvx0rQVksrW
hCJCbVTSOTDzsq0tmtL+EyCtBTqWR9WC2onTi9n8f5RHKdRsBXYGcqFZLPIHrkaC
dqJQhJGWh8Jct1UAE+FqVLFmtzz7WvjXsyEogGFSz5Flr6vnpTURzWiZWjnHyfm4
lSN4Ls78sdmNV3ckumV03C+7M450GR/E4Vc+8U2yM9Dae5aFmidJ7QtYULPA7/6l
KWracIMg0we+v6c0NwXnvb0JhtzKiyWksnYapum1UXC4aI+cTjCi5CuXBdjhWn65
YcOeoz//e6oX8MVqLwzneXtiaszCyQECLaO3/sly+HAVivllJwKFoBw8mentUrY6
zamwBBzSjQBEIWSlTQd/Qh6eH0ECzfcbz8oMw0BSX6bV11PbS/NXYeT+6kJvgrq4
czbFgBAlbI6acu7XSA1TNrh+bOvS/XKRgSlWzGM7XgfadT01ArOVuqiOtpmf3hGO
ggwN8erCYVxXcCK8XAAETbNKA6lYkgY2nvtj9v2ifnwA61pV9x8=
=1uyq
-END PGP SIGNATURE-

Accepted obnam 1.20.3-1 (source) into unstable

[Lars Wirzenius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 15 Dec 2016 11:19:42 +0100
Source: obnam
Binary: obnam
Architecture: source
Version: 1.20.3-1
Distribution: unstable
Urgency: medium
Maintainer: Lars Wirzenius <l...@liw.fi>
Changed-By: Lars Wirzenius <l...@liw.fi>
Description:
 obnam  - online and disk-based backup application
Changes:
 obnam (1.20.3-1) unstable; urgency=medium
 .
   * New upstream version.
   * debian/rules: do not run yarn tests during package building to
 work around a gpg2 gpg-agent related bug that I can't seem to fix
 right now.
Checksums-Sha1:
 243af3c860947a20a189549bec850cb26af9b6d5 2064 obnam_1.20.3-1.dsc
 af750258823236cfcc7a3420fbb6704c456bee91 295648 obnam_1.20.3.orig.tar.xz
 1f58030bb4bf428b8b2fa006c0fbfc53d50fb164 6688 obnam_1.20.3-1.debian.tar.xz
Checksums-Sha256:
 675203183916d5a1ee8c1ca617b4f8fc995f82402f0e72d29650363a44dc 2064 
obnam_1.20.3-1.dsc
 6e57ae6c41f07a5f70543a6010c601cefbb2987209ab671f1d61c964b8ced6c8 295648 
obnam_1.20.3.orig.tar.xz
 0a1d034e2f3f3a809d382eeb7f3ccf6b416fae31001a129d30932052900b93f1 6688 
obnam_1.20.3-1.debian.tar.xz
Files:
 a29c7020d7129c9c7821572132a3c7dc 2064 python optional obnam_1.20.3-1.dsc
 dff9e368f96d507d0e58af10895daa60 295648 python optional 
obnam_1.20.3.orig.tar.xz
 c437ae888692c1f5911ec2f28a8251b6 6688 python optional 
obnam_1.20.3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQI/BAEBCgApFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlhSb4ELHGxpd0BsaXcu
ZmkACgkQbC+mFux6IDHt4Q//Ywe9Dgf7Sk99CsLHm2YjZYWN6vN6YnikCdZR6EHZ
B7CMNY4NbDaQgM+2fKSGho/w4jZGIIoTRzxCU1rwDt8jh2xPl7vWlQx3JHr9yfqK
HX0zwENZ95fxmAwbCA/k6EeHpT3ytK4e/v0NsB4ebHNOSPBUWhAtIwm6wVQO0CnT
20wyvyjVqGU9L2rgckYDr2rn9wJHdQHTwUE7Grz6jewMqHObveWz9uElb2SC4PNW
/HNYpFW6SeNs+DpDnyGvpzVAmOgXRTAyV8skNzi/nU8Ip7t/fCRyP/MoXu77SFgC
XGKxnYi87dvmshXtkYBjvvWvOtgzWcROp6TKVovNCK4o/bNYvXy/iQAuP/SuAw++
lwo5dbECAaoHHfqKOJuhqruuJdvnK8Za2OBBFpTwvkMd+9StTJJRlb8qrUV03Eiv
ZCn+5SxfVUeJZveAqvDvV1pRTz5k+6FWWz64MmqDNl4awrDtuJjycmnIS3o6SBHG
hyG9+tvuePSeR5kxASu1WogVOFRXVph+x0YW3cOrDpvhLQdvVTJccxP155E6eBuL
SiQDpAcz79kEeotkF5iUkvOB9Orlk0+Qr1fAZj46xJVvKD8mRpyXq9b0tIjZyo9p
7P2SRbsf8B0NUf8VHWqlEhZ1fhd2HVU23oGN3oKbu4qGRtmTiVTqn1MFVe3CvePV
z3U=
=pb+s
-END PGP SIGNATURE-

Re: Bug#847749: ITP: node-user-home -- Get the path to the user home directory

[Lars Wirzenius]

On Mon, Dec 12, 2016 at 11:56:53AM -0300, Fernando Toledo wrote:
> A package to get user home path ?
> The world is dying...

We've had a number of discussions about nodejs's approach to what is a
suitable library/package size. Can we please not have that again?

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: DEP 8: Gathering Django usage analytics

[Lars Wirzenius]

On Fri, Nov 18, 2016 at 11:55:48AM +, Holger Levsen wrote:
> I fail to see the relation to http://dep.debian.net/deps/dep8/ - can you
> explain?

It's a benign acronym collision: both Debian and Django define DEP:
ours is Debian enhancement proposal, their is Django enhancement
proposal. See https://github.com/django/deps for more info.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: DEP 8: Gathering Django usage analytics

[Lars Wirzenius]

On Fri, Nov 18, 2016 at 08:54:08AM +1100, Brian May wrote:
> Lars Wirzenius <l...@liw.fi> writes:
> 
> > If I understand this correctly, Django wants to gather usage
> > statistics from installed Django instances, in a way that they say
> > respects user privacy (though I failed to understand how, given a
> > quick read). They claim this information gathering is necessary for
> > them to sustainably get funding for Django development.
> 
> ... there was a response to this email here:
> https://github.com/django/deps/pull/31#issuecomment-261181821
> 
> Probably better to followup on this pull request as opposed to here,
> where upstream will read it.

I'd rather not debate this on github. It's a proprietary system, and
effectively a web forum I'd need to keep polling to see if there's
responses. Further, that response paints me either as someone who's
misunderstood what they want to do, or a troll. If that's how I'm
going to be painted for disagreeing with them, then I don't want to
talk to them. It's probably true that I have misunderstood the details
of their proposals (I did find them written in a way that's confusing
to me), but the details probably don't matter much: if you software
reports on your users (and that includes developers), and the users do
no opt in to that, you're violating people'e privacy and you shouldn't
do that. If it's software packaged for Debian, the Debian package
maintainer should patch it out.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: More 5 november in the release schedule

[Lars Wirzenius]

On Sun, Nov 13, 2016 at 11:23:24AM +, Steve McIntyre wrote:
> FTAOD: I thank the release team for their tireless work on making each
> Debian release better than the last. We keep on adding more and more
> software and making things harder and harder to stabilise and release,
> and I 100% support their efforts to improve the process of releasing
> Debian.
> 
> I hope that the vast majority of Debian contributors think the same.

+1. I agree with Steve.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Accepted mysql-5.6 5.6.34-1 (source) into unstable

[Lars Tangvald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 18 Oct 2016 12:06:09 +0200
Source: mysql-5.6
Binary: libmysqlclient18 libmysqld-pic libmysqld-dev libmysqlclient-dev 
mysql-client-core-5.6 mysql-client-5.6 mysql-server-core-5.6 mysql-server-5.6 
mysql-server mysql-client mysql-testsuite mysql-testsuite-5.6 mysql-source-5.6
Architecture: source
Version: 5.6.34-1
Distribution: unstable
Urgency: high
Maintainer: Debian MySQL Maintainers <pkg-mysql-ma...@lists.alioth.debian.org>
Changed-By: Lars Tangvald <lars.tangv...@oracle.com>
Description:
 libmysqlclient-dev - MySQL database development files
 libmysqlclient18 - MySQL database client library
 libmysqld-dev - MySQL embedded database development files
 libmysqld-pic - PIC version of MySQL embedded server development files
 mysql-client - MySQL database client (metapackage depending on the latest 
versio
 mysql-client-5.6 - MySQL database client binaries
 mysql-client-core-5.6 - MySQL database core client binaries
 mysql-server - MySQL database server (metapackage depending on the latest 
versio
 mysql-server-5.6 - MySQL database server binaries and system database setup
 mysql-server-core-5.6 - MySQL database server binaries
 mysql-source-5.6 - MySQL source
 mysql-testsuite - MySQL regression tests
 mysql-testsuite-5.6 - MySQL 5.6 testsuite
Closes: 841049
Changes:
 mysql-5.6 (5.6.34-1) unstable; urgency=high (security fixes)
 .
   * Imported upstream version 5.6.34 to fix security issues:
 - 
http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html
 - CVE-2016-3492 CVE-2016-5507 CVE-2016-5584 CVE-2016-5609
 - CVE-2016-5612 CVE-2016-5616 CVE-2016-5617 CVE-2016-5626
 - CVE-2016-5627 CVE-2016-5629 CVE-2016-5630 CVE-2016-6304
 - CVE-2016-6662 CVE-2016-7440 CVE-2016-8283 CVE-2016-8284
 (Closes: #841049)
   * Packaging will now create /var/lib/mysql-files, as server will now by
 default restrict all import/export operations to this directory. This
 can be changed using the secure-file-priv config option.
   * Change mysql-testsuite dependency from python to libjson-perl.
 Tests written in python were rewritten in perl, so testsuite no longer
 depends on python, but tests fail if libjson-perl is missing. Also added
 libjson-perl build-dep to fix build-time test failures (LP: #1631338)
   * Add working dir to perl lib path for dep8 upstream.
 New versions of perl will no longer automatically include working dir in
 the path. This was causing the mtr suite to fail to start.
   * mysql-common is no longer included in source package as it has been moved
 to src:mysql-defaults
   * Removed patch fix-man-page-links, as the issue is fixed upstream.
Checksums-Sha1:
 5c822b5386c8aa5bd5ded5f8d1ca7b58f4cf7e70 3113 mysql-5.6_5.6.34-1.dsc
 b352b44385668f0d327d3f275f33f660d85497b3 32094762 mysql-5.6_5.6.34.orig.tar.gz
 f9978dac603a569d6766a510915b49b79e1c4cdb 248404 
mysql-5.6_5.6.34-1.debian.tar.xz
Checksums-Sha256:
 e1112fd6605346e3ed3c21cad7cef3b4c4afaa8b6a65688cc6b8dbb1e8b0359e 3113 
mysql-5.6_5.6.34-1.dsc
 ee90bafec6af3abe2715ccb0b3cc9345ed8d1cce025d41e6ec2b2b7a7d820823 32094762 
mysql-5.6_5.6.34.orig.tar.gz
 5408bf930b4aba855af820220faeb49a0ed8b90b32110bc4e5f2a13ac6188689 248404 
mysql-5.6_5.6.34-1.debian.tar.xz
Files:
 45496b261616ba1d9679a433b8af8a31 3113 database optional mysql-5.6_5.6.34-1.dsc
 255c5781f0cbb13f0e745b21c0ae3c1c 32094762 database optional 
mysql-5.6_5.6.34.orig.tar.gz
 6bdc93dc74e5d69051bb01cf9f9d8561 248404 database optional 
mysql-5.6_5.6.34-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYIePcAAoJEMAFfnFNaU+yvlQQAKrMFgAf9RwAeefl8301GP6+
uyVWxUk+xDmhrxf0LnL6QIQQGufJWI5IA84xm7xf6aXr13h22Tm4w/OUhUXWr0h2
ZgzcBbvpUrCfXUuHWqlO+OzEk5mw3QLdcGFVhFIa43ZybcNOQlaV6N9jno1gOtty
YKyj8Rz0Ix19TT1OPpOpzViiapn2/YwD4HhhfKUbmFbMHSWdiwH+wEcW4qSXB/Zl
3A7Ok5xHBJhehDuhVou960+uE79n3ID4F3OtGceJV6SSSDpzeelWHZ5Gs12M0hNi
OX3iMpy0Okjks7ri9CHFC8s2sBQHHnt6WzZkBL8RHMJPdlAKEtQl0oG22ObYCiRg
dLDUQ05tcvXNWCcqSQndrlDzXVDdtxee8aR/Zdstzyvj1vkLN7jlLy8KglE4yqaP
+Vv7ZyY4cqOIUmK9btvmkETjP0mjajMvMffx9cxWxzY3gehzJ7a7RgFf88+I5gJp
K2ZzlZHOZna3oA2MyRf8cd8B7Z8W6+dPZDmzkh0xPL/GXDNHP6QWfXA/xiQ29iC6
aQ75+d47EevOaneJo+eskIhPl3ZRDVTwUHELvHTXGV8mxnjuS5cR9/1Qa9toqISD
CqCuq7iHU08qdr+CaUT3OIAgITA7F/TzpR52o0q7Dnl1YPRpUxf8UsEvz1OWoamn
Pty8YZrQLSogAsoW+bY2
=JCvB
-END PGP SIGNATURE-

Re: DEP 8: Gathering Django usage analytics

[Lars Wirzenius]

On Mon, Nov 07, 2016 at 06:05:18PM +1100, Brian May wrote:
> https://github.com/django/deps/pull/31

If I understand this correctly, Django wants to gather usage
statistics from installed Django instances, in a way that they say
respects user privacy (though I failed to understand how, given a
quick read). They claim this information gathering is necessary for
them to sustainably get funding for Django development.

Reporting the fact that a site uses any particular software is,
itself, a privacy violation.

I'd prefer Django didn't do this, or the Debian packages enable it,
unless it's opt-in by sysadmins installing Django and also each user
using a site built on top of Django whose use is going to be reported.
All types of "call home" should be strictly opt-in.

It's a very sad situation if free software projects have to compromise
on privacy to get funded.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: More 5 november in the release schedule

[Lars Wirzenius]

On Sun, Nov 06, 2016 at 11:59:34AM +0100, Marc Haber wrote:
> That is really really bad. I really hoped back in 2015 that you were
> joking when you announced that.

It's really, really good. I was really glad that it isn't a joke.

I'm even willing to justify my opinion: Keeping testing in a state
that can be released seems to be the only way in which we can make a
release in a reasonable time frame. We've tried several other
approaches, which haven't worked. The approach of "let's freeze and
then try to fix things" didn't work. Let's not try it again.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: unattended-upgrades by default?

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
> One of the topics that we've been talking about yesterday is automatic
> software upgrades of cloud images. Some of the cloud platform
> providers really want this so that unsophisticated / inexperienced
> users of Debian images on their platforms will be secure by
> default. But there are potential issues here:

I am in favour of enabling automatic updates, particularly security
updates, on clould images by default. In fact, I wouldn't mind having
them on all types of installation by default. In my opinion, the
ecosystem-wide security benefits of having Debian systems keep up to
date with security updates by default overweigh any inconvenience of
having to tweak system configuration on hosts where the automatic
updates are problematic.

If we do this, we should prominently note it in release notes and have
a (wiki) page that explains how to turn off the automatic updates.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 06:04:26PM +0100, Paolo Greppi wrote:
> On 03/11/2016 17:54, Lars Wirzenius wrote:
> > I see the following possibilities now:
> > 
> > a) You rename the yarn package manager in Debian (both package and
> >binary). I keep the yarn name for my program and package.
> > 
> > b) We both rename. Nobody uses the name yarn, either as package or as
> >a binary name.
> 
> I'd go for a).
> 
> It is clear that this package will install /usr/bin/yarnpkg binary only.
> The package itself should be yarnpkg or node-yarnpkg.

Cool. Thank you.

> Should I just retitle this bug ?

Retitling the bug report is probably a convenience to those reading it
later, but the important bit is that the package and binary names are
correct when you upload.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 04:17:37PM +0100, Paolo Greppi wrote:
> On 03/11/2016 15:28, Lars Wirzenius wrote:
> > The JS package manager called yarn is quite new. It wouldn't be
> > unreasonable to suggest to them to rename it to avoid a naming
> > conflict, in my opinion.
> 
> Fine, I have opened an "Issue" in the github tracker, let's see if this
> is received constructively:
> https://github.com/yarnpkg/yarn/issues/1656

Upstream seems to not want to change the name. They closed that bug
with the following explanation:

# We don't have any intentions of using the yarnpkg binary as the sole
# one. There's prior art here with Node.js using node instead of
# nodejs even though there's already a Debian package called node. See
# #673 for more information.

The upstream 673 bug doesn't actually contain an explanation, though.

I see the following possibilities now:

a) You rename the yarn package manager in Debian (both package and
   binary). I keep the yarn name for my program and package.

b) We both rename. Nobody uses the name yarn, either as package or as
   a binary name.

I'm not happy if I have to give up the yarn name. I find it unfair
that I have to rename just because some new upstream decides to use I
name I've already been using for years, and refuses to reconsider
their use of the name.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 04:17:37PM +0100, Paolo Greppi wrote:
> Fine, I have opened an "Issue" in the github tracker, let's see if this
> is received constructively:
> https://github.com/yarnpkg/yarn/issues/1656

Thank you.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 02:02:31PM +, Ian Jackson wrote:
> I searched github for `yarn'.

You don't find my software on github. I do not want to rely on
non-free services like github.

> There are lots of hits for other
> programs, including:
>   - a dialogue editor (for games, I think)
>   - a VM
>   - something to do with mongodb and .net
>   - the Hadoop thing
>   - a blogging application
>   - a wrapper for ssh.
> and lots more.

How many of those were public in mid-2013?

> Obviously "yarn" is a really bad name.  Someone who picks a name like
> that must obviously expect that they can't necessarily have that name
> in every namespace.

When I chose the name in 2013, I didn't other software that was called
yarn.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 01:32:14PM +0100, Paolo Greppi wrote:
> cmdtest provides yarn since this commit:
> http://git.liw.fi/cgi-bin/cgit/cgit.cgi/cmdtest/commit/?id=859bb5ba9631df883dd7b074ff649ea2ca76e1ad

Yep, in 0.27-1, uploaded Sep 21 this year. cmdtest has included the
yarn program since June, 2013. I added that because people kept having
trouble finding the package when they want to install (my) yarn.

> A package search for yarn currently returns no match.
> https://packages.debian.org/search?keywords=yarn

I assume that's because it's a Provides, and not an actual package
name. I haven't created a separate yarn package to avoid making the
FTP masters from processing another package in NEW.

> The real issue here is that both cmdtest and the proposed package
> install a yarn binary.

I don't think that's the only reason, I think the package name
conflict is also an issue. But you're right that the binary name
conflict also needs be resolved.

> 1. as you suggest, renaming this package and the binary it installs to
> yarnpkg

Yes, please. :)

> 2. keeping the package name yarn but renaming the binary to yarnpkg

I don't see why you'd call the package yarn. There would be a conflict
with the yarn name that cmdtest provides.

> 3. renaming the executable yarn in cmdtest to yarn-something-else, and
> have cmdtest provide yarn-something-else

It's been called yarn in the cmdtest package for years. I'd prefer to
not rename it, thanks. It's a name that's dear to me, has some
pleasant memories associated with it, and that I've gotten used to.

The JS package manager called yarn is quite new. It wouldn't be
unreasonable to suggest to them to rename it to avoid a naming
conflict, in my opinion.

> 4. ignoring the conflict and setting the Conflict flags in both packages
> (https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts)

I don't think this is acceptable at all. There's no reason for these
two packages to conflict. There's no reason why we'd prevent someone
from installing both at the same time.

> For 3, there could be a cmdtest-legacy package for those who do not use
> yarn/yarnpkg and like to invoke the yarn binary in cmdtest as yarn
> rather than yarn-something-else.

Oh dear, please no. This is just insane. A whole bunch of work with no
actual benefit. It just makes things more complicated for everyone.

> At the moment we are confusing the newbies who come to Debian for
> JavaScript development.

I understand. I admit that I don't much care. Having to learn that
it's called yarnpkg in Debian, yarn on MacOS, and maybe something else
somewhere else seems not too big a deal to me. It's a very minor
difference compared to the churn in the Javascript ecosystem.

> It would be easier if they could apt-get install node/yarn and then just
> type node/yarn to use them.

Traditionally in Debian, we've handled naming conflicts by giving a
name to the first package using it. There have been exceptions of
course: node, and git come to mind. Some of these conflicts have been
solved by decree by the FTP masters, a couple by the technical
committee. Many have been resolved amicably by the Debian package
maintainers. Let's aim for that in this case.

I don't know of any cases when naming conflicts in Debian have been
solved by having a duel at Debconf. It's nearly a year to the next
Debconf, which is probably too long for solving this. Also, I've lost
my lightsabre.

We in Debian will always have naming conflicts like this, as long as
we have a flat namespace for packages (or in /usr/bin). It doesn't
help when upstreams don't do sufficient due diligence when choosing
names, meaning that we need to resolve them in Debian.

> - cmdtest has ~50

It's not a particularly popular package. I make no claim of
popularity, only of having used the name first.

> - for yarn/yarnpkg it's difficult to predict now, but probably it will
> end up in the range 0-6000, high or low depending how much traction it
> will get.

I don't think that is implausible. I'm not sure it's important, though.

> In conclusion, I leave it to those who know more what is the best thing
> to do !

Well, my opinion is still that it'd be nice if you called both the
package and binary yarnpkg. That would be a very simple, easy
solution. If you can convince upstream to also call the binary yarnpkg
(or yarnjs, or some other variant), that would be even better.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 08:36:21AM +0100, Paolo Greppi wrote:
>Package name: yarn
> URL: https://github.com/yarnpkg/yarn

My cmdtest package provides yarn, since the main tool it now provides
is yarn (a testing tool), not cmdtest. Perhaps your package could be
called yarnpkg?

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature