Accepted valgrind 1:3.7.0-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 28 Feb 2012 11:28:32 +0100 Source: valgrind Binary: valgrind Architecture: source amd64 Version: 1:3.7.0-3 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: valgrind - memory debugger and profiler Closes: 640154 Changes: valgrind (1:3.7.0-3) unstable; urgency=low . * Set myself as maintainer of valgrind, removing Andrés on his request. Thanks for the more than 7 years of maintenance Andrés! * Add s390x to the Architecture field (Closes: 640154). * Remove s390 that isn't supported upstream anymore. * Make valgrind believe it's cross compiled so that it builds on armel (hopefully), fix configure to deal with gcc version check properly (patches/0006-fix-configure.patch). Checksums-Sha1: 1e9e9c129f68a258c03e5f76ebe939484658cded 1368 valgrind_3.7.0-3.dsc bf634fd86ab4711f5e31c5d3c451818cf01f7370 23239 valgrind_3.7.0-3.debian.tar.gz 86fdd3f4dd56aff3c43d57eb4b4ebca8323ce029 28816616 valgrind_3.7.0-3_amd64.deb Checksums-Sha256: 5531056b21f01c026858f62a093f0bf801344a90547412a13139f3c4b5b5b80a 1368 valgrind_3.7.0-3.dsc 7d00dce08226f83b806543a5061f847df86ded9909008c760bcaeae98d66e112 23239 valgrind_3.7.0-3.debian.tar.gz 7cb6c6d8f300f6872bb8559e94f027d08ffdc1a8e3e41c4081274158e393053e 28816616 valgrind_3.7.0-3_amd64.deb Files: 2f1ca893597287001de224f86c74a916 1368 devel optional valgrind_3.7.0-3.dsc 668947d20818926b8996bd388adb0110 23239 devel optional valgrind_3.7.0-3.debian.tar.gz 9dd2b09ce6a9a9fe88125641245aabcc 28816616 devel optional valgrind_3.7.0-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9MrWkACgkQvGr7W6HudhwK8QCfTTMGQ4YyiUGInvlUji5NEumf ZVcAn3gcm1afYaQTYd8UEA0HhxLo0E6U =pxHp -END PGP SIGNATURE- Accepted: valgrind_3.7.0-3.debian.tar.gz to main/v/valgrind/valgrind_3.7.0-3.debian.tar.gz valgrind_3.7.0-3.dsc to main/v/valgrind/valgrind_3.7.0-3.dsc valgrind_3.7.0-3_amd64.deb to main/v/valgrind/valgrind_3.7.0-3_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1s2kch-ru...@franck.debian.org
Accepted valgrind 1:3.7.0-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 10 Feb 2012 14:16:17 +0100 Source: valgrind Binary: valgrind Architecture: source amd64 Version: 1:3.7.0-2 Distribution: unstable Urgency: low Maintainer: Andrés Roldán arol...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: valgrind - memory debugger and profiler Closes: 659215 Changes: valgrind (1:3.7.0-2) unstable; urgency=low . * Fix callgrind_control that should look for valgrind.bin and not valgrind. Closes: 659215. Thanks to Martin Apel. Checksums-Sha1: 32796f21e668c7ec4fc53be3954f8989357d8c4b 1415 valgrind_3.7.0-2.dsc af4ac03302430c76779a30d4842b4ba06075f5cb 22946 valgrind_3.7.0-2.debian.tar.gz a8d5bd4becf7b122ecab43fc4bd78464abc17696 28808150 valgrind_3.7.0-2_amd64.deb Checksums-Sha256: 11175e1d94123cb12949c85a609539c71e79ea86b9dd0b895b5c77fbdfa9c81c 1415 valgrind_3.7.0-2.dsc 4229a22a4efd4e42e9faf39e2d1c35774f29d48cd53cb5e203a3fb011ecd8f53 22946 valgrind_3.7.0-2.debian.tar.gz 421ac96323563a43985203374aa0f63ac54bcb5e26fdd604157462e309d3b399 28808150 valgrind_3.7.0-2_amd64.deb Files: dddb40c77907a8de8bfae1f0f6dc42c1 1415 devel optional valgrind_3.7.0-2.dsc b168822281b6e16f6eda684dba636129 22946 devel optional valgrind_3.7.0-2.debian.tar.gz df37c0eebc22c8d5f061fa2d12b5dbe5 28808150 devel optional valgrind_3.7.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk81GhsACgkQvGr7W6HudhxB7gCbBgfCLtLs0DHt+HGYLkYr5NRF GR4AnjiiPSAOgA7dR3A5vB9LtNrSxB6Z =jrbc -END PGP SIGNATURE- Accepted: valgrind_3.7.0-2.debian.tar.gz to main/v/valgrind/valgrind_3.7.0-2.debian.tar.gz valgrind_3.7.0-2.dsc to main/v/valgrind/valgrind_3.7.0-2.dsc valgrind_3.7.0-2_amd64.deb to main/v/valgrind/valgrind_3.7.0-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rvqb6-0004hl...@franck.debian.org
Accepted valgrind 1:3.7.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 21 Dec 2011 16:28:29 +0100 Source: valgrind Binary: valgrind Architecture: source amd64 Version: 1:3.7.0-1 Distribution: unstable Urgency: low Maintainer: Andrés Roldán arol...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: valgrind - memory debugger and profiler Changes: valgrind (1:3.7.0-1) unstable; urgency=low . * New upstream release. * refresh 0002-version.patch. * Drop patches merged upstream: - 0005-catch-manpages-errors.patch - 0007-implement-extra-dwarf-ops-gcc-461.patch - 0008-configure-support-linux-3.patch Checksums-Sha1: 9cd317ed81b517727e2655571234f42a8b2b2b5d 1415 valgrind_3.7.0-1.dsc b412f49895bb8a78fc314047119760b5d36e5b5e 6624216 valgrind_3.7.0.orig.tar.bz2 a3630e724dedcc94669480d8ee3abaf2b6794d3f 22613 valgrind_3.7.0-1.debian.tar.gz 6dc9e38e6c16d71aad51541d5177f11d945208fd 28808336 valgrind_3.7.0-1_amd64.deb Checksums-Sha256: 37c9b7d4cf32abfa10eef94403e865bb8e848e429d697fe4f6f9d615f40f5995 1415 valgrind_3.7.0-1.dsc 5d62c0330f1481fe2c593249192fa68ff454c19c34343978cc9ce91aa324cbf6 6624216 valgrind_3.7.0.orig.tar.bz2 c0f94bd40976eed71838cd20b08d864d1b347a1c87f645d1b6757440c8dfbdb9 22613 valgrind_3.7.0-1.debian.tar.gz 5a405ae285040e615b17b66e451058326c0793870999319de2dfeded21365333 28808336 valgrind_3.7.0-1_amd64.deb Files: 215701d093d49bd0949b502f0ee805d4 1415 devel optional valgrind_3.7.0-1.dsc a855fda56edf05614f099dca316d1775 6624216 devel optional valgrind_3.7.0.orig.tar.bz2 a7aecc4e313b97aa5f68dd05bd8c08ee 22613 devel optional valgrind_3.7.0-1.debian.tar.gz 37517b5bd09f7b9cc6dcde9bed7b96a8 28808336 devel optional valgrind_3.7.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8MAuAACgkQvGr7W6HudhwIBgCfV/9AGRvmaLszi5NpqqC49TcE aLEAnjpITTG1Faf1Xd0rx8bkbajrjl7c =l0CM -END PGP SIGNATURE- Accepted: valgrind_3.7.0-1.debian.tar.gz to main/v/valgrind/valgrind_3.7.0-1.debian.tar.gz valgrind_3.7.0-1.dsc to main/v/valgrind/valgrind_3.7.0-1.dsc valgrind_3.7.0-1_amd64.deb to main/v/valgrind/valgrind_3.7.0-1_amd64.deb valgrind_3.7.0.orig.tar.bz2 to main/v/valgrind/valgrind_3.7.0.orig.tar.bz2 -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rkypj-0004w0...@franck.debian.org
Accepted proxsmtp 1.10-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 03 Nov 2011 08:18:11 +0100 Source: proxsmtp Binary: proxsmtp Architecture: source amd64 Version: 1.10-1 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: proxsmtp - multi purpose SMTP Proxy Closes: 643260 Changes: proxsmtp (1.10-1) unstable; urgency=low . * New upstream release. * Rebuilding the package closes: 643260. Checksums-Sha1: a720a24fcf8e15d5325b8a9ea6684a8ada7c7ec8 1136 proxsmtp_1.10-1.dsc 80b54b33a94f16690dbcfca14e5d6f0078270067 181262 proxsmtp_1.10.orig.tar.gz f0970e359273edc2a4ecb1ea3c5c5414006e73a1 3272 proxsmtp_1.10-1.diff.gz 435cbdf5d749e7c3cd5bd0c0fde323e4097d4d2c 48890 proxsmtp_1.10-1_amd64.deb Checksums-Sha256: 1edac74cad7df0d81645ade461706a8022554105c066a09a62689aecd19e7c1c 1136 proxsmtp_1.10-1.dsc 33b13cb4cbbebd784768893404c992d6cc2e8d057c27c012e3a69f24ac60c4b5 181262 proxsmtp_1.10.orig.tar.gz a18f8411d188ae694599be8ab85ca24d516e87ec6ddf415c72c6bfe787124f02 3272 proxsmtp_1.10-1.diff.gz 7b86c6961c905f128ba296da89f23f8557c3244acbd113d56d9695020a2e92b4 48890 proxsmtp_1.10-1_amd64.deb Files: c65b74a36bca1e1e634c5ae2e43e855d 1136 mail optional proxsmtp_1.10-1.dsc 60989da5ce4c5da2cd286d75ae7eaf3e 181262 mail optional proxsmtp_1.10.orig.tar.gz a20e9eb17022977a76b0ec28b5d7d8df 3272 mail optional proxsmtp_1.10-1.diff.gz 3af739d534a9e9f03808666930d215b8 48890 mail optional proxsmtp_1.10-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6yQEgACgkQvGr7W6HudhwGOQCfVCs8HMQQB4tjNLWmpWLwYB8n 1+UAn1uTaxYzJigdfMN7ITH2b/dALG48 =87Di -END PGP SIGNATURE- Accepted: proxsmtp_1.10-1.diff.gz to main/p/proxsmtp/proxsmtp_1.10-1.diff.gz proxsmtp_1.10-1.dsc to main/p/proxsmtp/proxsmtp_1.10-1.dsc proxsmtp_1.10-1_amd64.deb to main/p/proxsmtp/proxsmtp_1.10-1_amd64.deb proxsmtp_1.10.orig.tar.gz to main/p/proxsmtp/proxsmtp_1.10.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rlrsu-0008k1...@franck.debian.org
Accepted valgrind 1:3.6.99svn12003-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 28 Aug 2011 23:14:32 +0200 Source: valgrind Binary: valgrind Architecture: source amd64 Version: 1:3.6.99svn12003-1 Distribution: experimental Urgency: low Maintainer: Andrés Roldán arol...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: valgrind - memory debugger and profiler Closes: 632666 Changes: valgrind (1:3.6.99svn12003-1) experimental; urgency=low . * Package a pre 3.7.0 snapshot (up to r12003 on 20110828). * Includes GCC-4.6 DWARF2 fixes hence Closes: 632666 on experimental as well. Checksums-Sha1: 592ff4d7eb14b01bf921396f048821177a520592 1434 valgrind_3.6.99svn12003-1.dsc da9cd400f819df5501864bff9ad0e390be8e40ef 5953587 valgrind_3.6.99svn12003.orig.tar.bz2 593def77698208fd1b39af655ad58e4ebe86b06b 29521 valgrind_3.6.99svn12003-1.debian.tar.gz 67796b0ec0ec32819560128c2c3f085117fbf800 25925528 valgrind_3.6.99svn12003-1_amd64.deb Checksums-Sha256: d9a8d4ba2b1cfae09dedbd97dd6f4f4ea79dd734436684ac5941c5026f9df5de 1434 valgrind_3.6.99svn12003-1.dsc 5d9e631d8476581592fbb5300dd89e82682f8da0c4e96b5394ce4541e29246df 5953587 valgrind_3.6.99svn12003.orig.tar.bz2 69eed86e9f94b87f88b9cbf4836e302b8acaa98f21d1215c5a72023d1a64786f 29521 valgrind_3.6.99svn12003-1.debian.tar.gz 90f92a31181f3a909007df6857aa5f2dd88b170c7ed09be43e1bb57cd4760fdf 25925528 valgrind_3.6.99svn12003-1_amd64.deb Files: b12d3984cd868ef2cdb5962ed61ec81d 1434 devel optional valgrind_3.6.99svn12003-1.dsc 86f9b74243d7e4ade84593e92dc5c6e7 5953587 devel optional valgrind_3.6.99svn12003.orig.tar.bz2 0b9b3c9902af73d230a8b119545a6e99 29521 devel optional valgrind_3.6.99svn12003-1.debian.tar.gz abd91d5db3955ae92fe307003958ef48 25925528 devel optional valgrind_3.6.99svn12003-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5asPAACgkQvGr7W6HudhzctgCdG3srVjXaJA2/6h+zaRcIhKH8 L9sAnjWx7Lj5jyTofm6mn+kXKejCIYZj =em8z -END PGP SIGNATURE- Accepted: valgrind_3.6.99svn12003-1.debian.tar.gz to main/v/valgrind/valgrind_3.6.99svn12003-1.debian.tar.gz valgrind_3.6.99svn12003-1.dsc to main/v/valgrind/valgrind_3.6.99svn12003-1.dsc valgrind_3.6.99svn12003-1_amd64.deb to main/v/valgrind/valgrind_3.6.99svn12003-1_amd64.deb valgrind_3.6.99svn12003.orig.tar.bz2 to main/v/valgrind/valgrind_3.6.99svn12003.orig.tar.bz2 -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qxn2x-00034m...@franck.debian.org
Accepted valgrind 1:3.6.1-5 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 23 May 2011 16:00:59 +0200 Source: valgrind Binary: valgrind Architecture: source amd64 Version: 1:3.6.1-5 Distribution: unstable Urgency: low Maintainer: Andrés Roldán arol...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: valgrind - memory debugger and profiler Closes: 475562 Changes: valgrind (1:3.6.1-5) unstable; urgency=low . * debian/rules: - use autotools-dev dh_autotools-dev_updateconfig. - do now strip under /usr/lib/valgrind (Closes: 475562). - use dh 7 to reduce debian/rules cruft. * Add armhf to the supported architectures. Checksums-Sha1: 6282983ba05ac6d5ba87f596a1e9c907edd72b03 1364 valgrind_3.6.1-5.dsc eab633742358cd33261652ab7342cae9653c4927 31060 valgrind_3.6.1-5.debian.tar.gz 1813426bc498b8dab52005f879afc430ab0d25cb 23937682 valgrind_3.6.1-5_amd64.deb Checksums-Sha256: f4022d4fe9a1fcaefdda168162e5f2bf144e8530e1e407eaae84498db12cc5b7 1364 valgrind_3.6.1-5.dsc da9a563141ca95f5f3b31cbcc7165823eed662dea7ec72f1e94c2510efa6f827 31060 valgrind_3.6.1-5.debian.tar.gz 45b1c3f762a3864195ad563c8e28c476354685252e2091d793eab48fc3345c22 23937682 valgrind_3.6.1-5_amd64.deb Files: bd5d1b5a99dd1dde932d56588b2f579b 1364 devel optional valgrind_3.6.1-5.dsc afff43dfd234e93d487d6b143b094798 31060 devel optional valgrind_3.6.1-5.debian.tar.gz a9276ff2bb98657b1b06919f77e88cec 23937682 devel optional valgrind_3.6.1-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3aaYMACgkQvGr7W6HudhzYSgCdFMG8+GD6XfjMd/fpEphRl7na MXgAnid5u9qr59EwnX/Uf3gGzJthdLO4 =uFDW -END PGP SIGNATURE- Accepted: valgrind_3.6.1-5.debian.tar.gz to main/v/valgrind/valgrind_3.6.1-5.debian.tar.gz valgrind_3.6.1-5.dsc to main/v/valgrind/valgrind_3.6.1-5.dsc valgrind_3.6.1-5_amd64.deb to main/v/valgrind/valgrind_3.6.1-5_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qoavs-000697...@franck.debian.org
Accepted valgrind 1:3.6.99svn11761-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 17 May 2011 08:47:28 +0200 Source: valgrind Binary: valgrind Architecture: source amd64 Version: 1:3.6.99svn11761-1 Distribution: experimental Urgency: low Maintainer: Andrés Roldán arol...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: valgrind - memory debugger and profiler Closes: 270066 309406 351823 576236 Changes: valgrind (1:3.6.99svn11761-1) experimental; urgency=low . * Package a pre 3.7.0 snapshot (up to r11761 on 20110517). * 3.7.0 comes with a gdbserver features which mitigates the following bugs: - Gdb interactions are simpler and avoid issues due to embedding (Closes: 309406, 270066, 351823) - this comes with better handling of registers (Closes: 576236). - 3.7.0 has a s390x port, so enable it as an architecture and see where it goes. * remove 0003-prevent-gcc-4.6-warnings-with-valgrind.h.patch since upstream now integrates those changes. * lintian fixes: - add overrides for sgcheck binaries and DSO. - update debhelper version depends to 7.0.50~ as suggested. Checksums-Sha1: f5739ea963fcd881624c4c3047000d2b60a90a23 1434 valgrind_3.6.99svn11761-1.dsc 617e9d75f1373a6b5fa784abde75896954da31c3 6060680 valgrind_3.6.99svn11761.orig.tar.bz2 9020a9b1f68358944f90f6c70c1f4d4868ff5882 29976 valgrind_3.6.99svn11761-1.debian.tar.gz 518963cf6b2443e3628670bee4637e2e34f54037 25394884 valgrind_3.6.99svn11761-1_amd64.deb Checksums-Sha256: 482c8cecbd354f32bbbf2243ebf8dd57762b496b39ada7bda9d54b860e844f87 1434 valgrind_3.6.99svn11761-1.dsc fb66ef6190eb5b7d59b05ba9691c8f013e82113693896ac50272ae4c3e64c618 6060680 valgrind_3.6.99svn11761.orig.tar.bz2 d5d40bd17bac569d4d9f98110ac20156b411b982960516d853006b241dd65ad0 29976 valgrind_3.6.99svn11761-1.debian.tar.gz 74b87293c337c883cab603b722826050dbcbb7fffa702959a2239f4ef298ac6d 25394884 valgrind_3.6.99svn11761-1_amd64.deb Files: 10da7ee13ebaa33d63fa15c30f15ef41 1434 devel optional valgrind_3.6.99svn11761-1.dsc 436936d9db808cbbbddac1b635f77e37 6060680 devel optional valgrind_3.6.99svn11761.orig.tar.bz2 f5a41a3e24684a8fad93fb18df7bcc80 29976 devel optional valgrind_3.6.99svn11761-1.debian.tar.gz 1d654d4f6f212e929d84d58c22fbd860 25394884 devel optional valgrind_3.6.99svn11761-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3SKJ4ACgkQvGr7W6Hudhxj8QCfTfid+fYRELjtMkQyGNMkVPb/ umkAnjn+xb/twAhUxaj3GMaO1jWrHPZi =/kfu -END PGP SIGNATURE- Accepted: valgrind_3.6.99svn11761-1.debian.tar.gz to main/v/valgrind/valgrind_3.6.99svn11761-1.debian.tar.gz valgrind_3.6.99svn11761-1.dsc to main/v/valgrind/valgrind_3.6.99svn11761-1.dsc valgrind_3.6.99svn11761-1_amd64.deb to main/v/valgrind/valgrind_3.6.99svn11761-1_amd64.deb valgrind_3.6.99svn11761.orig.tar.bz2 to main/v/valgrind/valgrind_3.6.99svn11761.orig.tar.bz2 -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qmgjf-0001jn...@franck.debian.org
Accepted valgrind 1:3.6.1-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 12 May 2011 13:35:29 +0200 Source: valgrind Binary: valgrind Architecture: source amd64 Version: 1:3.6.1-3 Distribution: unstable Urgency: low Maintainer: Andrés Roldán arol...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: valgrind - memory debugger and profiler Closes: 592614 Changes: valgrind (1:3.6.1-3) unstable; urgency=low . * update 0002-version.patch to loosen the checks on the arm version (Closes: 592614). Checksums-Sha1: a549717426a1ce044194ae68aaff6118208c1917 1342 valgrind_3.6.1-3.dsc b239df22a3ee55c0e78664612bf3208487e4d2a6 31109 valgrind_3.6.1-3.debian.tar.gz ec9ee1fb418795b88c27c611fe639650a720c7cb 73845066 valgrind_3.6.1-3_amd64.deb Checksums-Sha256: 4e6ef2cb1f836310bc9f1453ae4fef16e1bf2a2889b6e6107a755da2fbdeae44 1342 valgrind_3.6.1-3.dsc 01c0de11316971735118660417706e9ceb2e982bc7d1dc592467306835d59fb2 31109 valgrind_3.6.1-3.debian.tar.gz 10177f6d6ab77a98fab708818c424b5349bd1bcb5dccfe1c15791c9391c160b2 73845066 valgrind_3.6.1-3_amd64.deb Files: 23802b259ec97aaa5d3c2ee5dfdb64bc 1342 devel optional valgrind_3.6.1-3.dsc a790297dbf1f60e23bf09c2da24e8198 31109 devel optional valgrind_3.6.1-3.debian.tar.gz 2b4908550040624897f527a267a39291 73845066 devel optional valgrind_3.6.1-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3LxqsACgkQvGr7W6Hudhx+JQCeJRgLo95Xv+LwZjms80JogIDj 5w4An0E3nDV2JjwRVWVponNkat/3x+4n =x3X1 -END PGP SIGNATURE- Accepted: valgrind_3.6.1-3.debian.tar.gz to main/v/valgrind/valgrind_3.6.1-3.debian.tar.gz valgrind_3.6.1-3.dsc to main/v/valgrind/valgrind_3.6.1-3.dsc valgrind_3.6.1-3_amd64.deb to main/v/valgrind/valgrind_3.6.1-3_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qkubx-0006sl...@franck.debian.org
Accepted valgrind 1:3.6.1-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 12 May 2011 19:44:22 +0200 Source: valgrind Binary: valgrind Architecture: source amd64 Version: 1:3.6.1-4 Distribution: unstable Urgency: low Maintainer: Andrés Roldán arol...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: valgrind - memory debugger and profiler Closes: 626486 626496 Changes: valgrind (1:3.6.1-4) unstable; urgency=low . * Fix patches/0004-allow-or-quoting-of-strings-in-.valgrindrc.patch: out was copied too early leading to bad option parsing in case of leading spaces (Closes: 626486, 626496). Checksums-Sha1: 2c2d0a1a628095456d2d3484e897ecf2b4362f26 1342 valgrind_3.6.1-4.dsc ef0ad2b914797a6bbde33c79742e76c8d38a87ea 31227 valgrind_3.6.1-4.debian.tar.gz dba718583ca51cb69a5e57d549b4abd17a6fb1c8 73843184 valgrind_3.6.1-4_amd64.deb Checksums-Sha256: 7294fccb1289f9554e2260a73f1859673394ff4183bed348e742b937d1a85421 1342 valgrind_3.6.1-4.dsc 043012ca47c5016f9d33f1c7de1632723ba8d2d65ff7ca511bded6fc96985bc1 31227 valgrind_3.6.1-4.debian.tar.gz ab599b6c812eb497f9648d1bff0adba0118970458757d563b42401675454b1b0 73843184 valgrind_3.6.1-4_amd64.deb Files: 1cce66c022177ccef4ad8742f2a0394a 1342 devel optional valgrind_3.6.1-4.dsc eaf6e80679de49633531cc464971d80e 31227 devel optional valgrind_3.6.1-4.debian.tar.gz 0456a0d46d763096b8a2a62cd9066bcd 73843184 devel optional valgrind_3.6.1-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3MHVsACgkQvGr7W6Hudhx3XACgqAYp3yUaF13QUZNX/TW3+Vba +WkAmwYDGRCYurkIjiBQBicZbzopYw59 =YV/8 -END PGP SIGNATURE- Accepted: valgrind_3.6.1-4.debian.tar.gz to main/v/valgrind/valgrind_3.6.1-4.debian.tar.gz valgrind_3.6.1-4.dsc to main/v/valgrind/valgrind_3.6.1-4.dsc valgrind_3.6.1-4_amd64.deb to main/v/valgrind/valgrind_3.6.1-4_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qkahw-00015k...@franck.debian.org
Accepted valgrind 1:3.6.1-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 10 May 2011 23:12:23 +0200 Source: valgrind Binary: valgrind Architecture: source amd64 Version: 1:3.6.1-2 Distribution: unstable Urgency: low Maintainer: Andrés Roldán arol...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: valgrind - memory debugger and profiler Closes: 475562 507236 592614 598870 599563 603961 Changes: valgrind (1:3.6.1-2) unstable; urgency=low . * Enable valgrind build on armel (Closes: 592614): - s/arm/armel/ in debian/control; - build for armv7 since valgrind doesn't support older arm CPUs, thanks to Loïc Minier for the implementation details. * Add 0004-allow-or-quoting-of-strings-in-.valgrindrc.patch to allow parsing of options with spaces in ~/.valgrindrc (Closes: 507236). * Catch manpages build failures (Closes: 599563) thanks to Stefano Rivera. * Add suppression for __nss_database_lookup leaks in debian.supp (Closes: 598870). * String things not under /usr/lib/valgrind (Closes: 475562), document into the lintian-overrides why it shouldn't be stripped, namely http://valgrind.org/docs/manual/dist.readme-packagers.html. * Add 0006-workaround-SIGSEGV-on-PPC.patch to workaround PPC SIGSEGV (Closes: 603961). Checksums-Sha1: a4dca9c1372f07bc87c69f4563aee1c9223c96c9 1342 valgrind_3.6.1-2.dsc 7208bf6347e1bd85cac3372a7c7b486390e897a2 30927 valgrind_3.6.1-2.debian.tar.gz 5a08b6d7c49850716711f408077585c6dad0e62e 73845440 valgrind_3.6.1-2_amd64.deb Checksums-Sha256: f88cb18f619c52cb88a45147d57827f2944843262e3f71236c43e4ca68961da4 1342 valgrind_3.6.1-2.dsc dba19653647995d47208c7cd5777aeed76824ddec43adc8736c658a3413ded00 30927 valgrind_3.6.1-2.debian.tar.gz b6f38cbca49097b8283e50a907c6fb555086e023b66b157a5ff3a57306542d33 73845440 valgrind_3.6.1-2_amd64.deb Files: 6bc9e5610cb77fd60976aaeb2bd6053d 1342 devel optional valgrind_3.6.1-2.dsc 2090174736ef23ba836bea0f87522f4b 30927 devel optional valgrind_3.6.1-2.debian.tar.gz 9f303ab5bd2f526e2af7d9f514575712 73845440 devel optional valgrind_3.6.1-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3KJD0ACgkQvGr7W6HudhwykgCfVt/FakbW636fpv0xPxJlrMP0 DS8An1ifGCBSqLkTLUj/B79ZrypP1pAN =qM8Y -END PGP SIGNATURE- Accepted: valgrind_3.6.1-2.debian.tar.gz to main/v/valgrind/valgrind_3.6.1-2.debian.tar.gz valgrind_3.6.1-2.dsc to main/v/valgrind/valgrind_3.6.1-2.dsc valgrind_3.6.1-2_amd64.deb to main/v/valgrind/valgrind_3.6.1-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qk2k7-0007qb...@franck.debian.org
Accepted valgrind 1:3.6.1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 09 May 2011 22:55:27 +0200
Source: valgrind
Binary: valgrind
Architecture: source amd64
Version: 1:3.6.1-1
Distribution: unstable
Urgency: low
Maintainer: Andrés Roldán arol...@debian.org
Changed-By: Pierre Habouzit madco...@debian.org
Description:
valgrind - memory debugger and profiler
Closes: 549554 622586 625180
Changes:
valgrind (1:3.6.1-1) unstable; urgency=low
.
* Migrate to format 3.0 (quilt):
- use upstream .tar.bz2 directly;
- migrate patches from dpatch to debian/patches/*.
- valgrind builds twice in a row (Closes: 549554).
* Add myself to Uploaders.
* New upstream release (Closes: 622586, 625180).
* Add patches/0003-prevent-gcc-4.6-warnings-with-valgrind.h.patch to prevent
warnings about set but unused variables with gcc-4.6.
* debian/control:
- Bump standards version (no changes needed).
- Add VCS-* Headers.
- Add Homepage Header.
* Lintian fixes:
- Add missing ${misc:Depends} in debian/control.
- fix debian-rules-ignores-make-clean-error.
- migrate to dh_lintian for overrides, and update them.
- remove article from debian/control Description.
Checksums-Sha1:
4969576b04e495575209ebb79e586e1eea6c1833 1340 valgrind_3.6.1-1.dsc
6116ddca2708f56e0a2851bdfbe88e01906fa300 5974836 valgrind_3.6.1.orig.tar.bz2
3c7a8813dba51edf259538c9a3ef7b7888592962 28445 valgrind_3.6.1-1.debian.tar.gz
69d132c32e1d02e91e945ade1cedb4faf46dd958 41491042 valgrind_3.6.1-1_amd64.deb
Checksums-Sha256:
47e7594cffca750104b0a4b40fc1994eb74ff1e9e82096edc50605abf0e3eefb 1340
valgrind_3.6.1-1.dsc
49bdcc4fbcf060049b5f0dcfd8a187a6e90e0b0e57309f633b64e44430726a0e 5974836
valgrind_3.6.1.orig.tar.bz2
6d3b67905923eaedca5911c053a4247db7e17290b7a94f424742b39c51c490e5 28445
valgrind_3.6.1-1.debian.tar.gz
e2a55296efbe644e0036ea4b472256be2ef047f6e4e11a92dc048eff364cb794 41491042
valgrind_3.6.1-1_amd64.deb
Files:
1f49b7eb318449ab8262fd0d83a1ce6e 1340 devel optional valgrind_3.6.1-1.dsc
2c3aa122498baecc9d69194057ca88f5 5974836 devel optional
valgrind_3.6.1.orig.tar.bz2
a1c22dd2cb01431b3b82e759d9963514 28445 devel optional
valgrind_3.6.1-1.debian.tar.gz
9fd759bf3ca205d80ea025bf6697aff3 41491042 devel optional
valgrind_3.6.1-1_amd64.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk3I1gEACgkQvGr7W6Hudhza0gCfVk9hkJAHVBdaVqWUH1dTzsS8
NBMAnj/eVZocDjn0+QBarm4SVLBYD942
=ChfN
-END PGP SIGNATURE-
Accepted:
valgrind_3.6.1-1.debian.tar.gz
to main/v/valgrind/valgrind_3.6.1-1.debian.tar.gz
valgrind_3.6.1-1.dsc
to main/v/valgrind/valgrind_3.6.1-1.dsc
valgrind_3.6.1-1_amd64.deb
to main/v/valgrind/valgrind_3.6.1-1_amd64.deb
valgrind_3.6.1.orig.tar.bz2
to main/v/valgrind/valgrind_3.6.1.orig.tar.bz2
--
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qjgve-0003ph...@franck.debian.org
Accepted sparse 0.4.3+20110419-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 07 May 2011 16:26:29 +0200 Source: sparse Binary: sparse Architecture: source amd64 Version: 0.4.3+20110419-1 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: sparse - semantic parser of source files Closes: 625962 Changes: sparse (0.4.3+20110419-1) unstable; urgency=low . * Merge upstream up to 87f4a7fda3d17: + Fixes build with gcc-4.6 (Closes: 625962). Checksums-Sha1: f2673e751e2f2ec69443b82f3e91827788cc8f33 1235 sparse_0.4.3+20110419-1.dsc 6d0933b2633f8cebc00b1d4c0af8b821cdd6634b 172431 sparse_0.4.3+20110419.orig.tar.bz2 cff5011d257d377e2d9b068824a5dfbfa3e383c9 10259 sparse_0.4.3+20110419-1.debian.tar.gz 7d566b89e4a1d9bf597fa3fe17bddcd673620cc5 526506 sparse_0.4.3+20110419-1_amd64.deb Checksums-Sha256: 4e0dc00068e597f2ea1f4b82b0b887239aa4c8dc10af82f4d3bf8a90af5e3edf 1235 sparse_0.4.3+20110419-1.dsc 9059bc649ca8c9309e542d0015091ccf72ac9e3300db0adb4eba838cdcc82f9c 172431 sparse_0.4.3+20110419.orig.tar.bz2 2f61940155849703a7fa017b3c540e2fe5b1bee9b71219b71a82df119c8a17f8 10259 sparse_0.4.3+20110419-1.debian.tar.gz 795f0b678fa58dac87e2b3b5a362725119cc6751ec0e727169b109a04e73684f 526506 sparse_0.4.3+20110419-1_amd64.deb Files: a9b95d8fc52fb5c39bb53c06d085b556 1235 non-free/devel optional sparse_0.4.3+20110419-1.dsc a5c0b07bd00ad5ea292f804d7af1adbc 172431 non-free/devel optional sparse_0.4.3+20110419.orig.tar.bz2 a1699669e46f4552510061b848e1de08 10259 non-free/devel optional sparse_0.4.3+20110419-1.debian.tar.gz 4221c035f96190f8bf58fed7f75b3026 526506 non-free/devel optional sparse_0.4.3+20110419-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3FV0oACgkQvGr7W6Hudhza2QCdEV3/3XPWV3K9Ms+Xsvc4qp1L BTMAmwc3g6NRxm9DPqSyGS/s+1/qJayk =h4NB -END PGP SIGNATURE- Accepted: sparse_0.4.3+20110419-1.debian.tar.gz to non-free/s/sparse/sparse_0.4.3+20110419-1.debian.tar.gz sparse_0.4.3+20110419-1.dsc to non-free/s/sparse/sparse_0.4.3+20110419-1.dsc sparse_0.4.3+20110419-1_amd64.deb to non-free/s/sparse/sparse_0.4.3+20110419-1_amd64.deb sparse_0.4.3+20110419.orig.tar.bz2 to non-free/s/sparse/sparse_0.4.3+20110419.orig.tar.bz2 -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qiiuk-0005i2...@franck.debian.org
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 08:58:31AM +0200, Lucas Nussbaum wrote: On 05/05/11 at 08:51 +0200, Josselin Mouette wrote: Le jeudi 05 mai 2011 à 08:23 +0200, Lucas Nussbaum a écrit : Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Use case: During freeze, there's a library transition in unstable, and a new upstream version in unstable. You want to get the new upstream version into rolling (not testing), but you can't because it would pull the whole transition. You don’t need to pull the whole transition, that’s the point of my proposal. You just need to put the library being transitioned and your package. So you need a way to upload the new upstream version linked against the libraries in rolling. Alternatively, if testing is so broken you need that new upstream version and it can build against the testing libraries, you can use testing-proposed-updates - in all cases, for both testing and rolling, a targeted fix being preferable. That might not be the preferred solution during freeze. I am not sure of how testing-proposed-updates works. Could we: 1. upload package 1.1-1 (the new upstream we want in rolling) to testing-proposed-updates 2. accept package 1.1-1 into rolling 3. upload package 1.0-2 (new version of the package currently in testing, with a targeted fix) to testing-proposed-updates 4. accept package 1.0-2 into testing ? I'm not saying that rolling-proposed-updates should be used frequently, but it sounds more comfortable to have it at hand. Of course, we could also decide to add it later. Frankly I'd say that the simple proposal could be implemented like tomorrow, and we could see how well it fares, and refine it when we understand its dynamics. Right now there are too many what if, the simple proposal made of a second britney run + forces is non intrusive, can be done on a d.net host easily enough, and we could learn this way how it works in practice. Sounds better than over engineering. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505070728.ga27...@madism.org
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 09:07:28AM +0200, Pierre Habouzit wrote: On Thu, May 05, 2011 at 08:58:31AM +0200, Lucas Nussbaum wrote: On 05/05/11 at 08:51 +0200, Josselin Mouette wrote: Le jeudi 05 mai 2011 à 08:23 +0200, Lucas Nussbaum a écrit : Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Use case: During freeze, there's a library transition in unstable, and a new upstream version in unstable. You want to get the new upstream version into rolling (not testing), but you can't because it would pull the whole transition. You don’t need to pull the whole transition, that’s the point of my proposal. You just need to put the library being transitioned and your package. So you need a way to upload the new upstream version linked against the libraries in rolling. Alternatively, if testing is so broken you need that new upstream version and it can build against the testing libraries, you can use testing-proposed-updates - in all cases, for both testing and rolling, a targeted fix being preferable. That might not be the preferred solution during freeze. I am not sure of how testing-proposed-updates works. Could we: 1. upload package 1.1-1 (the new upstream we want in rolling) to testing-proposed-updates 2. accept package 1.1-1 into rolling 3. upload package 1.0-2 (new version of the package currently in testing, with a targeted fix) to testing-proposed-updates 4. accept package 1.0-2 into testing ? I'm not saying that rolling-proposed-updates should be used frequently, but it sounds more comfortable to have it at hand. Of course, we could also decide to add it later. Frankly I'd say that the simple proposal could be implemented like tomorrow, and we could see how well it fares, and refine it when we understand its dynamics. Right now there are too many what if, the simple proposal made of a second britney run + forces is non intrusive, can be done on a d.net host easily enough, and we could learn this way how it works in practice. Sounds better than over engineering. What I expect to be needed is to make rolling a real suite that retains packages. That will probably be needed sometimes. Though packages only in rolling should be a transitory situation that the rolling team is expected to minimize. This is a situation that does exist on the setups of our users already, like Samuel Thibault said on IRC where I said that first let's just factorize that fact and try to minimize the amount of between-testing-and-unstable setups out there to something that we manage and understand. r-p-u sounds like a can of worms. Maintainers are supposed to care about testing. Caring about rolling is just basically the same, and occasionally I wouldn't be shocked if the rolling team asked for a rolling targgetted fix to be uploaded to unstable, let it live just the day for it to be pinned in rolling, and let the maintainer continue its usual business. Again I don't expect rolling (but only experience can confirm that) pinning more than a few dozens packages, and r-p-u is probably an overkill (*and* is a bad feature, this is exactly the kind of stuff that I disliked in the early discussions about rolling: duplicating the effort for maintainers and similar issues). -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505072208.gb27...@madism.org
Re: glibc: causes segfault in Xorg
On Thu, May 05, 2011 at 09:56:03AM +0200, sean finney wrote: Maybe valgrind already does checks like this [...] It does. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505080442.gb27...@madism.org
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 06:51:35PM +0200, Goswin von Brederlow wrote: Pierre Habouzit madco...@madism.org writes: On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandoraâs box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they donât help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? Say you have just uploaded a new upstream release to unstable and then someone reports a RC bug against testing. Pushing this untested version into rolling isn't the right thing. Would a t-p-u upload get added to rolling quickly too in those cases? What if testing is frozen? I'd say let's see with the reality if it works or not. It's clear that rolling will have RC bugs. The question is will it be bearable or not. I think so. with what if discussions we'll go nowhere, that's why I'd be in favor of a small experiment with the smallest amount of work to be done (my just use a britney to chose between unstable and testing and nothing more proposal), and see how well/bad that performs. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505170545.gf19...@madism.org
Re: A concrete proposal for rolling implementation
On Fri, May 06, 2011 at 12:51:33AM +0200, Goswin von Brederlow wrote: Pierre Habouzit madco...@madism.org writes: On Thu, May 05, 2011 at 06:51:35PM +0200, Goswin von Brederlow wrote: Pierre Habouzit madco...@madism.org writes: On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening PandoraâÂÂs box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they donâÂÂt help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? Say you have just uploaded a new upstream release to unstable and then someone reports a RC bug against testing. Pushing this untested version into rolling isn't the right thing. Would a t-p-u upload get added to rolling quickly too in those cases? What if testing is frozen? I'd say let's see with the reality if it works or not. It's clear that rolling will have RC bugs. The question is will it be bearable or not.. I think so. with what if discussions we'll go nowhere, that's why I'd be in favor of a small experiment with the smallest amount of work to be done (my just use a britney to chose between unstable and testing and nothing more proposal), and see how well/bad that performs. Hell, why britney? To compute something that is actually installable and maximizes the installability count doh! -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505225350.gb...@madism.org
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 07:48:45PM +0200, Carsten Hey wrote: * Pierre Habouzit [2011-05-05 07:46 +0200]: On Wed, May 04, 2011 at 10:48:46PM +0200, Carsten Hey wrote: If more new upstream versions are uploaded to unstable (because they are targeted at rolling), it raises the number of RC bugs needing to migrate to testing through t-p-u. How would you ensure that they get enough testing before entering testing? That's the point, you don't target rolling, your goal is still to make stuff migrate into testing, rolling is just the extra few packages testing needs to fix the most important breakages that happen (e.g. your PAM example, or large migrations where dependencies across libraries are too loose and break testing, Joss said it happens to gnome quite a lot e.g.). So rolling would principally also be frozen during testing's freeze, this is not what the name seems to imply. Unlike variants where rolling would really roll, this one does not require an additional pseudo-suite in Debian [1] and could be implemented on rolling.debian.net without convincing the release team and ftpmaster first. There have been several DDs on -devel@ epressing concerns about the fact that having something unfreezed during the freeze would divert the attention from the release and many people don't want it to happen (including me). OTOH if Debian is more tested before the freeze thanks to rolling, it can help to reduce the freeze length… -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505230603.gc...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Tue, May 03, 2011 at 04:49:42PM +0200, Jan Hauke Rahm wrote: On Tue, May 03, 2011 at 01:31:24PM +0200, Pierre Habouzit wrote: On Tue, May 03, 2011 at 11:41:35AM +0200, Lucas Nussbaum wrote: It is clear from the discussion that there would be consequences. Some would be negative, some positive. I think that we have now a pretty good understanding of the possibilities and their consequences. The remaining problem is to count DDs heads in the two camps: - Let's focus on stable releases. A rolling release should not be provided officially by Debian. - Let's see what we can do about rolling, provided we find a way to do it without diminishing the quality of our stable releases. FWIW I'm in neither. My camp would be: Please do not impede our way to produce stable releases in any ways, do whatever you want with rolling. I'm sorry but I find that a lame request. If, in whatever circumstances, Debian as a project decides to care about something beyond stable releases, for instance something called rolling, it will as a matter of fact use power of the project for such new thing and thus distract that power from stable releases. Always. Saying that anyone can do anything as long as it never interferes with what we have now is exactly the definition of keeping the status-quo, i.e. preventing improvement. Granted, it also prevents breakage. Huh, no, you can do lots of stuff that don't harm releasing a Stable… I've suggested integrating aptosid (or $derivative) people inside of Debian as a way to provide rolling, I know that Joss did so on planet too e.g. That has two very important advantages: * it brings in new blood *now* (and not an hypothetical later) to actually take care of rolling (which doesn't make all my reservation moot but I reckon does lessen their scope significantly); * it brings people who know how to do that and already have infrastructure to do so. We would just give them the opportunity to benefit from the larger and robust infrastructure we have, while taking their experience. Looks like it's win-win. Have you asked *any* contributor of *any* project about why they didn't put their efforts in Debian but instead into a different project? That's not the same thing as creating ways inside of Debian to scatter resources on too many projects. That would be irrational. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504155811.gg27...@madism.org
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote: The new “rolling” suite --- This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. This is an excellente proposal which technically can be implemented this way: - having a new britney instance, which is chained to the result of the testing britney. - it is fed with a new hint file composed of forced migrations (those are versionned), feeding the result of the testing britney with sid. - result is a new release only made of testing or unstable packages. If you find the people wanting to make up the rolling team, I think it's a few hours work to setup (and overhead on the ftp servers would just be minimal: a new suite and associated Packages files, nothing more). Doing it this way: - leverages the same tools as what we have now (britney, dak); - only uses packages either in unstable or testing, which makes rolling a glorified Pin-file hence people using rolling don't diverge from the stable release work and are actually *worthwile* bug reporters and gives more coverage on testing *excellent*. - benefits from the release work: e.g. if a package is removed from testing, since rolling is recreated from that, it inherits that (nothing prevents the rolling team to force it back for whichever reason). - allows to take snapshots of rolling on a semi-regular basis (with associated d-i releases). E.g. every 3 months or so. Those would be alphas before the freeze, and betas during the freeze. I like it a lot, I'm even finding it useful: it looks like it resolves the rolling issues for people (wrt having something like a 'Usable' testing), but doesn't really forks testing, only glorified pinning managed at the project level instead of on each other's machines. But it doesn't make those users worthless to the release team, quite the contrary. It could even turn-up to become a useful release tool. I just love that proposal. At least something technical that makes sense, thanks Joss. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504161129.gh27...@madism.org
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandora’s box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they don’t help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504202329.ga20...@madism.org
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 10:17:03PM +0200, Stefano Zacchiroli wrote: If you want to go ahead with patching britney, by all means go ahead, as it might provide patches useful for the main brintey as well. But if you want to try some alternatives, we can probably help. I don't think you need to patch britney at all. Just take the last testing computed as a testing-britney output as a start, have a list of force-hints to be processed, taken from unstable, and there you go. It's just a new britney run. Admitedly there is a small patch to be done, force hints in britney are strictly versionned, for the rolling case one may want to have looser way to express force hints (with version ranges e.g.), but that should't be really hard. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504202724.gb20...@madism.org
Re: PPAs for Debian
On Wed, May 04, 2011 at 01:23:12AM -0400, Scott Kitterman wrote: PPAs as a developer tool are one thing, PPAs as a tool for random uploads, I think are quite another. I'd hate to see Debian make the same mistake that Canonical did in this regard. PPA on Debian infrastructure should be limited to people with a key in the keyring. Though we should make the software available for people to build their own PPA infrastructure easily. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504203954.gb21...@madism.org
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 10:48:46PM +0200, Carsten Hey wrote: * Pierre Habouzit [2011-05-04 22:23 +0200]: On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandora’s box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they don’t help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? If more new upstream versions are uploaded to unstable (because they are targeted at rolling), it raises the number of RC bugs needing to migrate to testing through t-p-u. How would you ensure that they get enough testing before entering testing? That's the point, you don't target rolling, your goal is still to make stuff migrate into testing, rolling is just the extra few packages testing needs to fix the most important breakages that happen (e.g. your PAM example, or large migrations where dependencies across libraries are too loose and break testing, Joss said it happens to gnome quite a lot e.g.). IOW to target rolling you target testing, IOW you help doing stable stuff, isn't that nice? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505054655.ga26...@madism.org
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 12:05:22AM +0300, Cristian Henzel wrote: What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Again, no disruption: people can keep on breaking some pieces of experimental, but if they want some other pieces to be useful for rolling users, they just need to be committed to more carefulness and to add them to the override file. I also find this a very good implementation, although I would like a 'true' rolling release, without any freezes at all. I'm not sure how much extra work it implies or how much sense it would make to have an exact clone of testing just without the freezes. Not a lot, I don't expect it larger than having to place a dozen hints usually, up to a small hundred during the peaks (100 is less than 1% of our source packages). Maintaining something like that isn't hard, it's already what the RM Team does to follow testing migrations, and if rolling is generated after testing is, the Rolling Team will benefit from the RT work so it's just an incremental effort. Nothing wasted. (And not wanting to finger point but I've read at least a certain RT Member saying that he would even consider help a Rolling Team as he's already doing that pinning on his workstation…) -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505055010.gb26...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Tue, May 03, 2011 at 11:41:35AM +0200, Lucas Nussbaum wrote: It is clear from the discussion that there would be consequences. Some would be negative, some positive. I think that we have now a pretty good understanding of the possibilities and their consequences. The remaining problem is to count DDs heads in the two camps: - Let's focus on stable releases. A rolling release should not be provided officially by Debian. - Let's see what we can do about rolling, provided we find a way to do it without diminishing the quality of our stable releases. FWIW I'm in neither. My camp would be: Please do not impede our way to produce stable releases in any ways, do whatever you want with rolling. I've suggested integrating aptosid (or $derivative) people inside of Debian as a way to provide rolling, I know that Joss did so on planet too e.g. That has two very important advantages: * it brings in new blood *now* (and not an hypothetical later) to actually take care of rolling (which doesn't make all my reservation moot but I reckon does lessen their scope significantly); * it brings people who know how to do that and already have infrastructure to do so. We would just give them the opportunity to benefit from the larger and robust infrastructure we have, while taking their experience. Looks like it's win-win. They probably have good ideas on what could be improved in Debian to make their job easier, while *we* don't since we never tried. Just to say that your bipartisan view is a tad simplistic :) -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503113123.gn...@madism.org
Re: Integrating aptosid?
On Tue, May 03, 2011 at 02:42:26PM +0200, Lucas Nussbaum wrote: On 03/05/11 at 13:31 +0200, Pierre Habouzit wrote: I've suggested integrating aptosid (or $derivative) people inside of Debian as a way to provide rolling, I know that Joss did so on planet too e.g. That has two very important advantages: * it brings in new blood *now* (and not an hypothetical later) to actually take care of rolling (which doesn't make all my reservation moot but I reckon does lessen their scope significantly); * it brings people who know how to do that and already have infrastructure to do so. We would just give them the opportunity to benefit from the larger and robust infrastructure we have, while taking their experience. Looks like it's win-win. They probably have good ideas on what could be improved in Debian to make their job easier, while *we* don't since we never tried. It's not as simple as let's integrate aptosid. There are at least two sides to this: - integrate the developers community in Debian. They are probably very nice etc, but: 1) they are not currently Debian contributors (even if some of them might be) That's not a real issue. 2) they might not adhere to Debian's values That would be one. 3) they decided to start a separate project, they might have good reasons to do it outside Debian The most likely would be (1) - integrate the technical processes inside Debian. We can't just add aptosid as a new Debian suite: that would be the worst solution (important overhead since Debian maintainers would have to care for unstable, testing and aptosid, then). So we need to work out solutions to reduce the overhead, and all the former discussion applies. I know it's not simple, but it's not necessarily harder than making testing usable, I think Joss made a pretty good case about that on his blog. Also, FYI, the aptosid development team is composed of 8 to 10 developers, contributing to different things at different levels (info gathered on #aptosid@OFTC). aptosid is just an example, I don't even know the distro, they may not be the best choice, I just try to find alternates ideas. Note that I don't think it takes more than 10 people to do the rolling distro like Joss propose it: snapshot unstable every month and fix the worst breakages. It takes more than 10 people to do the same in testing because each individual fix is tangled in the migration issue, hence rapidly needs to update things that are at first totally unrelated to be fixed too first. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503130534.go...@madism.org
Re: Integrating aptosid?
On Tue, May 03, 2011 at 03:05:34PM +0200, Pierre Habouzit wrote: On Tue, May 03, 2011 at 02:42:26PM +0200, Lucas Nussbaum wrote: It's not as simple as let's integrate aptosid. There are at least two sides to this: - integrate the developers community in Debian. They are probably very nice etc, but: 1) they are not currently Debian contributors (even if some of them might be) That's not a real issue. 2) they might not adhere to Debian's values That would be one. 3) they decided to start a separate project, they might have good reasons to do it outside Debian The most likely would be (1) Or/and the impression that the idea has no support within Debian. IOW I don't see real blockers here if we have the intention (and that they agree). -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503130724.gp...@madism.org
Re: Integrating aptosid?
On Tue, May 03, 2011 at 03:17:18PM +0200, Lucas Nussbaum wrote: On 03/05/11 at 15:05 +0200, Pierre Habouzit wrote: aptosid is just an example, I don't even know the distro, they may not be the best choice, I just try to find alternates ideas. Note that I don't think it takes more than 10 people to do the rolling distro like Joss propose it: snapshot unstable every month and fix the worst breakages. It takes more than 10 people to do the same in testing because each individual fix is tangled in the migration issue, hence rapidly needs to update things that are at first totally unrelated to be fixed too first. By proposing to provide a snapshot every month, you are proposing a different point in the quality/up-to-date-ness compromise map. This compromise looks less appealling to me than the rolling==testing or the aptosid ones. Also, are you aware of the monthly snapshots built by Michael Gilbert? See http://lists.debian.org/debian-devel/2011/04/msg00397.html I don't advocate it, I'm just saying there are other options that haven't been discussed yet. I don't really know which is better for the user, I couldn't care less (I've already stated I'm fine with unstable right? ;p). Though technically such a solution has less impact on our current release workflow and I prefer it. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503131855.gq...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, May 02, 2011 at 01:56:14AM +0200, Carsten Hey wrote: * Pierre Habouzit [2011-05-01 23:17 +0200]: The problem is, you need to entry points, one for testing as we know it, one for rolling. Actually, we need two entry points each, a default one and an exceptional one. The latter ideally requires a special permission from a release team before an upload. For testing these are unstable and testing-proposed-updates. Urgh. Sounds a lot. If you use t-p-u for testing and unstable for rolling, or unstable for testing and rolling-updates for rolling is just bikeshedding. The result is some of the users will use unstable and help testing, the other sort will run rolling-updates or rolling. So basically you split our users in two non overlapping sets, meaning that you divide coverage and tests. The result of this bikeshedding has an influence on how big these sets are. I agree, the original sizes, I expect them to converge more or less to the same end result, which is what is important on the long term. And clearly, we have to make rolling create its feeding routes, not steal testing ones, that's kind of obvious to me :) I'm interested about *why* they want it, not the mere fact that they do. Because when you know why they want it, maybe there will be better answers that don't make releasing even more brittle and burn even more people out. I guess it's mainly about new upstream versions (firefox, chromium, gnome and so on) they read in the news about, saw on other computers or really contain features useful for the users. Moving backports.org to backports.debian.org and enabling automatic upgrades by default are steps in the right direction to address this (except for desktop environments). Supporting or even recommending to use all packages from b.d.o to make it feel like a rolling release would be nearly the opposite of how it is intended to be used now and I don't think it would make those users really more happy. So all in all, the scheme used to manage b.d.o seems to lack improvement potential from a users point of view :) An other way to use newer upstream versions is via chroots. With faster internet connections, larger hard disks, faster CPUs and a smaller size of a minimal Debian chroot, using a chroot to run a single application could become more worthwhile. With a frontend to configure such things, it could be used be end users in future. Yes, I'd very much like to see this kind of routes explored before we rework all the suites in Debian… -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502060855.ga22...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, May 02, 2011 at 12:10:42AM +0200, Lucas Nussbaum wrote: On 01/05/11 at 23:46 +0200, Pierre Habouzit wrote: Benefits for Debian: - attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (developers, free software contributors), thus interesting to work with. Some of them could become Debian contributors. And even if they don't, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers]. I think those can use unstable, But unstable is a development branch not targeted at being used by 'standard' users. Well, assuming it's the case, what is missing in order to be usable by mere users? Also note that testing as is has not enough security support, and read Carsten very good example of the PAM issues. How would CUT or rolling address those? I've used testing in the past, in the sarge era. I had to constantly install packages from unstable for it to work, and the result was a nightmare of apt-get installability. I've not used testing since, so /maybe/ it's better nowadays, I'd very much like to have some feedback from real and recent testing users if there are any, but if I trust my past experience, the gap to make testing usable is significant. So maybe making unstable usable isn't *that* much more significant, and is definitely more compatible with our current workflow. and if they use rolling, I think I already proved or at least explained why those don't contribute to the stable in being, but rather the N+1 one. I think that you are mixing two things here: 1) whether we want to turn testing into a rolling release 2) what do do with the 'rolling' suite during freeze (fork a 'frozen' branch at the beginning of the freeze ? freeze rolling ? start by freezing rolling, then after a few months, fork 'frozen' and unfreeze 'rolling'?) I don't mix things. (1) is: no we don't want to turn testing into rolling because you need to freeze to release. If rolling appears it must be a second suite. So yes (2) is a question. But frankly, if the answer of (2) is we don't do rolling during freezes I don't understand the point of the whole discussion, so I assumed that the answer was yes we do rolling all the time. Actually, the more I read, I think that: - nobody knows why we want rolling or CUT (though I've read cut.d.net since, and to me it looks like a glorified snapshot of testing + d-i + cd images + all that makes a stable, which basically is just fine by me); - nobody knows what rolling *exactly* is, what the plan is. We know the hype and that Debian would very much like to support it, but what's the formal definition, what does it encompass, what does it mean, what's the recommended implementation? - give back to the free software world by providing a platform where new upstream releases would quickly be available to users. Since users would be able to test new upstream releases earlier, they would be able to provide feedback to upstream devs earlier, contributing to a shorter feedback loop. Why doesn't unstable fit that? Because unstable is a development branch not targeted at being used by 'standard' users. Testing is a release tool not targeted at being used at all. So to me testing and unstable are both more or less at the same point, with unstable having the clear advantaged to be targeted at _some_ users. Why is that so much easier to make testing usable with respect to making unstable audience broader? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502061917.gb22...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, May 02, 2011 at 09:13:31AM +0200, Marc 'HE' Brockschmidt wrote: Hai! Pierre Habouzit madco...@madism.org writes: On Sat, Apr 30, 2011 at 12:28:06PM +0200, Stefano Zacchiroli wrote: Size is just one ingredient. There are plenty of other ways to diminish barrier to deploy big changes in Debian: wider commit access rights, larger VCS repositories, more liberal NMUs, etc. (Unsurprisingly, several Debian derivatives have decide to pursue those other ways and one might argue that they have done so learning from Debian experience.) [...] Oh yes, you really want to attract new contributors ? build debhub.com (as in github) and force everyone to package stuff in there. Ehm, forcing people to use a certain VCS is usually a good way to _lose_ contributors... I'm not forcing the use of the VCS, more like some infrastructure to host packages if you want, during the development, so that it's easier to track, and not in its source-only form as what matters to users is actually the binary form. Which is missing nowadays. And I disagree, we may lose a few, but it can improve efficiency making it a stable operation, and I think having more standardized ways to look at packages and contribute to the packaging will lower the entry to help. But to be fair, this was an idea I developped in a bout 2 hours of time, it's bound to have deficiencies :) -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502071650.ga23...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, May 02, 2011 at 09:20:29AM +0200, Lucas Nussbaum wrote: Yes, it's mostly PR bullshit, and I don't expect it to significantly change Debian development processes. However, communication is necessary if we want to attract new users. What might change is more attention from developers to what happens in testing/rolling, which is probably a good thing since a better testing/rolling makes it easier to create stable releases from it. Is that it, really? What's the point of the rename, forcing all the testing users to sed their sources.list? Wow. Useful. [C] we could compromise. We could freeze rolling for 3 months, so that most of the stabilization work occurs with a single active branch, and then, for the final release preparation, fork 'frozen' off 'rolling', and unfreeze 'rolling'. That's horrible to do because the end of the freeze is *exactly* when people get demotivated, and that the last rush is mostly done by very few people. Doing that will make them feel even more alone, which is a great way to burn them out even faster. I really don't like it. I'd rather see ways on how to make the freeze shorter been explored instead. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502073027.gb23...@madism.org
Re: Debian rolling: tentative summary
On Mon, May 02, 2011 at 01:31:31PM +0200, Lucas Nussbaum wrote: Hi, Since I already sent too many mails in the 'rolling' discussion, I decided to send one more. Here is an attempt at a summary of what was said so far. It might not be complete, it's probably a bit biased, but I hope that it's still better than nothing. When replying, please try to focus on specific points, and change the subject accordingly. That's a decent summary of what was said I think. Though I feel that to make the discussion more solid, the following is missing: - What are the problems you try to address with rolling? And no the users want it isn't an answer, I'd reply why do they want it if that's the answer I get. - Are we sure that rolling is the best way to address those problems? - What is rolling exactly ? I'd add a few questions: - we acknowledged that some derivatives (e.g. aptosid) are doing the work of stabilizing unstable. Isn't it a better way of doing things in the sense that it doesn't harm testing a bit? IOW wouldn't it be a better idea to somehow (with their consent) swallow a derivative that seems to do what you want to instead of suffering NIH and reinvent something a derivative does? - I'll stress again that testing is a release tool, and sometimes to unblock large transitions it's easier to remove a package from the distribution so that it doesn't block thousands of other, or because the breakage it introduces is too large. This practice is very important, and I remember the release team having strong altercations with other DDs at the time whereas testing wasn't targeted at users. What would it be if testing becomes more user targetted? Should the removal policies be amended ? Beware, I think it's a huge no-go for the release team. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502124205.ge23...@madism.org
Re: Debian desktop market focused release
On Mon, May 02, 2011 at 02:40:21PM +0200, Abou Al Montacir wrote: On Mon, 2011-05-02 at 13:31 +0200, Lucas Nussbaum wrote: Benefits for Debian: * Attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (free software developers and contributors), thus interesting to work with (able to submit good-quality bug reports, etc). Some of them could also become Debian contributors. And even if they don't, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers]. * Give back to the free software world by providing a platform where new upstream releases would quickly be available to users. Since users would be able to test new upstream releases earlier, they would be able to provide feedback to upstream devs earlier, contributing to a shorter feedback loop. Debian is often identified by upstream developers as the platform with releases from two years ago. I would love to see Debian in a position to contribute more to improviing the quality of the Free Software world. Hi all, First, thank you for this message which summarizes huge mail thread. I didn't personally read most of the mails, as these are hundreds. So, please excuse me if I'm repeating something that was already said. What about keeping the same schema, which is working well (unstable==testing==stable), and just adding a new kind of parallel release path (unstable==testing==desktop) which is a kind of short cycle release targeting the desktop/laptop market. Today, testing is quite good quality, but sometimes it get stuck and cause headaches for a few days rendering PC non usable. So filtering this kind of things should be easy especially for stable lesser quality release. I like Debian's logo quality's first and think we should keep this even when going to the desktop market. So maybe we need to focus on this way based on short cycle releases (in addition to the regular release cycle). One way is to have a second release team for this purpose. An maybe the release team could monitor these desktop release in order to decide, the best time, to base stable on a giver desktop version unstable==testing==desktop ||==frozen==stable This is addressed in the thread, and some (me included) fear that it'll squander resources and lessen quality. If you don't add new people to do this extra work, then it means you'll make people do both, and they are already overwhelmed with their current work. Plus it splits the user base. It's all in the end of lucas mail FWIW. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502124409.gf23...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, May 02, 2011 at 05:36:34PM +0200, Stefano Zacchiroli wrote: On Sun, May 01, 2011 at 11:00:58PM +0200, Pierre Habouzit wrote: First of all I think you should concede that the exercise you're asking us to do cannot be done as easily as you did yours. I don't concede that. I've read your mail, and to sum up you say: (Note that the concede was on a side aspect, not on the fact that I was able---which clearly I was not---to convince you of my arguments.) So the next question is why your mail doesn't answer that. I still think that rolling is a bad idea, until you've proven me that it's the sole way to address a real life issue/need/itch. Yes, you're right and I've no answer for that, because the way I've interacted with people was in some aggregate form, which didn't permit me to investigate more than that. So, sorry, I give up on answering this. But that doesn't stop me from seeing as perfectly reasonable the use cases already mentioned several times in this thread (e.g. 20110501200120.ga18...@gnu.kitenet.net for a short version). It's very clear to me that they are not enough to convince you and others, but they are convincing for me. Well I don't want to be convinced or not convinced, you misunderstood why I'm asking that. I'm asking because I want to evaluate if rolling is the sole answer we can bring to these people. They say they want testing to be usable, but maybe what they want is something that we can achieve without touching testing at all. So I'd like to understand. There is absolutely no will on my end to be convinced or not convinced, this was a genuine question for pure technical considerations. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502164258.gg23...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sat, Apr 30, 2011 at 11:24:41PM -0700, Ludovico Cavedon wrote: On 04/30/2011 04:32 PM, Pierre Habouzit wrote: FWIW I think that rolling or CUT miss the point entirely. As a Debian user I use stable on my servers (with a few backports for the 3-4 things I need bleeding edge for). For my desktop I use unstable, and when that breaks (which is *very* rare, really) I go to snapshots and go back a few versions. I couldn't care about testing any less. And at work, every person I know either uses just stable or does the same as me. I know no testing user around me. Of course I'm not pretending I know the absolute Truth, but well, I find this whole users want testing badly thing dubious. I do know people who run testing. Actually I can see two kinds of users who run testing. -people who want to keep getting software updates, but do not want to run unstable [1]. They would point to testing in their apt sources.list. These are the users who want rolling -people who would decided to run the next stable release, before it is actually released, they would point their sources.list to wheezy (as of now). there are the users who will go though rolling, then frozen, then stable [1] I run unstable in my laptop, and it is stable enough for me, but for a regular user I can see how these 10 days between unstable and testing can help her to avoid getting in contact with major bugs/issues. I used to run testing in the sarge days. It was utterly broken with lots of uninstallable (or hard to insall) stuff when you had KDE migrations for example. I knew lots of people using testing at the time, we all moved to unstable because it was just too hard trying to get to install stuff at some point. Plus, you also have the very real effect of This RC bug that affects testing isn't fixed for 50 days because the fix that sits in unstable for now 45 cannot migrate because it's tangled in this or this transition. Okay I understand that rolling probably intends to fix the latter, but I'm not sure it's that easily fixable without some kind of testing-proposed-updates thing (which is a no-go because it means testing receives non-unstable-tested packages), *or* is pretty much impossible to achieve because you just can't make transition go faster, but for NMUing the blockers. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501074904.ga15...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 08:38:55AM +0200, Mike Hommey wrote: On Sun, May 01, 2011 at 01:32:19AM +0200, Pierre Habouzit wrote: FWIW I think that rolling or CUT miss the point entirely. As a Debian user I use stable on my servers (with a few backports for the 3-4 things I need bleeding edge for). For my desktop I use unstable, and when that breaks (which is *very* rare, really) I go to snapshots and go back a few versions. I couldn't care about testing any less. And at work, every person I know either uses just stable or does the same as me. I know no testing user around me. Of course I'm not pretending I know the absolute Truth, but well, I find this whole users want testing badly thing dubious. The real problem is not users want testing badly, but Debian wants people to use testing badly. Because what Debian releases is testing. If nobody uses it, we don't know until it becomes stable that it's broken in some subtle ways because it's not exactly what everyone else using unstable is using. So while I do agree with the rest of your message, I do see a need to make testing more attractive so that we have a solid user base actually testing what we are going to release, and stop saying to people that they shouldn't be using testing (and I've seen that said *a lot*). I know it's not a good excuse, but testing is something that many distributions have not. They have alphas, betas, pre-releases of many sorts, but testing is very specific to Debian, and it does receive attention. We would like more, sure, but I don't think we want to support testing either. I think we'd like people running unstable stick with testing when we freeze, that makes sense, yes. And FWIW, I use to migrate my servers to testing during the freeze (I did that for lenny and for squeeze), because the update flow is way slower than for the 18 other months. And I'm pretty sure others do it. Do we care about people testing being throughly tested all the time? I'm not really that sure, it's a volatile target and it makes no sense to fix software version incompatibility bugs that ends up never really exist in the release nor in unstable for more than a few days e.g. It's more work for a very doubtful quality gain. So instead of rolling, I'd find a way to expose testing a lot more while it counts for us, yes, and while we do care about testing being usable, meaning, the damn freeze! -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501075750.gb15...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 11:22:51AM +0300, Andrei Popescu wrote: On Du, 01 mai 11, 09:57:50, Pierre Habouzit wrote: I think we'd like people running unstable stick with testing when we freeze, that makes sense, yes. This doesn't make sense to me, why would I want to downgrade to testing during the freeze? Besides, during the freeze testing and unstable are not very different, at least that's what happened during the last 2 cycles, when most updates were done via unstable. As far as I can tell, the typical unstable user will rather use experimental during the freeze, because that's where the new stuff is. That's because it's not downgrading, I meant it rather as a freeze-with-testing kind of thing, IOW ageing with testing instead of living the bleeding edge. And no, not everybody lives in unstable for the bleeding edge, many people live with unstable because stable is too damn old for their purpose. E.g. as a developper, I need fresh enough tools: recent toolchain for its better diagnostics, better dev tools with more debugging features, though my software targets stuff way older (RH5 usually, which is globally older than *lenny*). So when the freeze arrives I'm mostly following testing, then stable for a few months to avoid the shitstorm that inevitably follows in the following 1-3 months after a release. I may not be a typical Debian User (but what is a typical Debian User anyways ?!), but I think there are more ways to use Debian than the clichés you're trying to enforce as the general rule. And FWIW, no I disagree, unstable users that want bleeding edge just suffer because experimental has no way to select overlays of wanted packages (Pinning is just a bad joke since you can't pin source packages nor regexes), and getting all experimental is just too damn broken. I think this class of users just cringe for 6 months until unstable becomes bleeding edge again. Also, and that's personal, I couldn't care about such users less, I don't think it adds value to Debian to make them happy. Putting random bleeding edge crap in a Bag isn't what I believe to be sane, and has never been a Debian goal afaict. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501094108.gc15...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 03:39:57PM +0200, Raphael Hertzog wrote: On Sun, 01 May 2011, Andreas Barth wrote: * Raphael Hertzog (hert...@debian.org) [110501 08:41]: Fixing RC bugs in testing and getting new upstream versions that are ready in testing is not a burden for developers, it's what we're supposed to do to ensure we can release as quickly as possible. Who is the we you are speaking about here? Does that we have enough man power to do that? We = developers/maintainers/Debian as a whole It seemed obvious to me. I understand members of the release team feel particularly responsible to do various release-critical tasks that should have been done by the maintainers but haven't (for various reasons). And I guess that's the reason of your remark. But that's not scalable ultimately. So I think it's a good move to say we support testing and we expect every maintainer to take care of their packages there (as opposed to the current situation where too much of that work is left in the hands of the release team). I've stared at that for a long time, read it three time to be sure I read it properly. And it seems I did… I'm still staring at it in disbelief while I'm answering. You're saying: Problem: I acknowledge that people are not interested in stable releases enough and that the RT has to compensate all the time. Solution: Let's pretend we care about testing being usable, that will make people who don't care, to actually care and fix their bugs! Of course the release team doesn't scale this way, I'm happy you noticed. But what you propose isn't even wishful thinking. I'm still not believing you've written something that naive, are you really deluding yourself to that point? PS: when you say your trick like that, you know, people know you're trying to trick them and it doesn't work anymore. I've two children, I can tell. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501163813.ga19...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 08:02:51PM +0200, Lucas Nussbaum wrote: On 01/05/11 at 18:38 +0200, Pierre Habouzit wrote: You're saying: Problem: I acknowledge that people are not interested in stable releases enough and that the RT has to compensate all the time. Those two statements are true: - A subset of DDs care about doing stable releases. The rest of DDs don't care. - A subset of DDs care about doing 'rolling'. The rest of DDs don't care. The release team obviously cares about stable releases, and I mostly read the individual positions of RT members in this thread as if we do 'rolling', it will be harder to do stable releases. Their position is completely understandable. It's likely that doing 'rolling' will impact stable releases in some ways. Some of the impact might be negative, some might be positive. But what we (the project) need to decide on is where we want to go. After all, we could decide not to do stable releases, or to do them every six months instead of every two years. The current choice of doing stable releases every two years is there only because a large subset of DDs care about doing that. The thing is, I think that rolling and testing are not compatible. So it seems unlikely to me that we can support both in Debian, especially not in the same namespace testing or rolling. I don't want to lose stable releases, it's a disservice to our users. And if you try something like your plan B, you'll have two issues: (1) you'll split the userbase, some of the users will use rolling instead of testing, and during the freeze we're very interested about our users to test testing. It's actually the period where it matters the most. In the end you get less testing coverage, hence mathematically lessen the quality. (2) developers who already care little about stable releases will even care less because they will be able to do the work that they like (brining their software up to date, not really caring about stable), IOW it'll divert attention of the maintainers even more. Both will lead to a poorer quality of the stable release, and probably even longer freezes. Both are a disservice to the stable release, and to our users. And in the end both will put more pressure on the shoulders of the RT members that already don't scale. Of course rolling has some appeal, but it's just hype, and well, sometimes our users want silly things and we should know better than to indulge them. I agree that a 6 months freeze sucks because we miss a release for many upstreams (gnome, KDE, …), which makes packaging harder. But maybe we should focus on how to reduce the freeze period (which would in turn mean that we should have some study about why it's 6-months long instead of 3 like I'm sure it could be). I strongly believe that lessening the quality of the Debian stable release is harming Debian as a whole. And I know I'm rehashing things, but this will inevitably lead to more work for maintainers: supporting stable + testing means more work there is no way it will reduce the work. It's our scarce resource (developpers), so why don't we *first* focus on making packaging easier, leaner, simpler, and *then* see what we can do with all that new free time we just bought? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501185525.ga20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 09:43:51PM +0200, Stefano Zacchiroli wrote: On Sun, May 01, 2011 at 08:55:25PM +0200, Pierre Habouzit wrote: (1) you'll split the userbase, some of the users will use rolling instead of testing, and during the freeze we're very interested about our users to test testing. It's actually the period where it matters the most. Just for the sake of the argument, that is not granted. The above is true only if the user base remains constant. Arguably, rolling is appealing to users of other existing rolling distributions which are based on Debian anyhow (name one) and, who knows, also to current users of release-every-6-months derivatives who want more support on all the archive. Yes, mine is speculation, but it seems to be in the same ballpark of a hidden assumption in the above. Well, we've heard about that argument before, namely when Ubuntu was created. I think we've had enough history to know that Ubuntu users don't directly make Debian better, and certainly not at a fast pace. I don't see why rolling users would benefit to testing for the same reasons[1]. The key point is, when we do need rolling users to help testing (namely during the freeze), it's when rolling is the most different from testing. So when the users from rolling actually don't help. The sole benefit from rolling is that unstable would probably end up less broken the two months just after a release. Also I skipped an important point out, name it (3), the entry points. unstable can't be the antechamber of testing and rolling at the same time. If unstable is diverted to rolling, it means a t-p-u like setup to feed testing. But that sucks, quality from t-p-u isn't as good as unstable, this is a really frowned upon way to feed testing, that the RT doesn't like to be forced to use. And if you say unstable feeds testing, then you'll need a dedicated feed channel for rolling, and you'll end-up with either less test for rolling (since this distribution say unstable/rolling has less users), hence rolling will suck, _OR_ it'll divert users from unstable and we're back to unstable being t-p-u without the name, which isn't acceptable. [1] Of course since both are under the Debian umbrella it'll /probably/ be a lot less politicized than the Debian-Ubuntu relations. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501195213.gb20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 04:01:20PM -0400, Joey Hess wrote: Pierre Habouzit wrote: FWIW I think that rolling or CUT miss the point entirely. As a Debian user I use stable on my servers (with a few backports for the 3-4 things I need bleeding edge for). For my desktop I use unstable, and when that breaks (which is *very* rare, really) I go to snapshots and go back a few versions. I couldn't care about testing any less. And at work, every person I know either uses just stable or does the same as me. I know no testing user around me. Of course I'm not pretending I know the absolute Truth, but well, I find this whole users want testing badly thing dubious. Consider all the users who are running stable, plus a backport of some servers, or a chromium or firefox installed from upstream because stable's is too old. Consider the users who have so many backports installed that they start to encounter integration problems between them. Consider users who install Ubuntu because there is no usable Debian release with a kernel new enough for their hardware, but then have to fight with it to disable some Unity thing. These are all use cases for CUT. Who are they? Unlike this constant handwaving, I've shared my experience (on #-devel), I'll repeat it here: at work we've like 10 Debian users, some with stable, the other with unstable. Why? Because we're developpers and if our software targets old stuff (RH5, it's as old as lenny), the latest gcc, valgrind, … are priceless tools, and we want them. I run unstable on my laptop and workstation for years, with almost daily dist-upgrades. Except for grub2 (and I've been stupid, I removed grub, I should have known better) I've had no serious issues for 5 years, nothing that prevented a boot, almost nothing that prevented X to start, and absolutely nothing that a revert to testing or using snapshots.debian.org couldn't fix (plus a dpkg-hold for good measure). At work something like 6 different people use that setup, and we have complex boots with dm-raid, lvm, cryptsetup, it never broke. Those are real users from real life. I'm not saying we-re representative of a majority of Debian Users, but unlike all the handwaived users we've read about in this thread, those are real. Could someone here explain with a real life example who the users who badly need CUT/rolling are, and explain to me why unstable isn't a good choice for them (and no, unstable brokeness doesn't CUT it — sorry I had to do it — my experience proves it's rare). -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501200845.gc20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 09:35:07PM +0200, Lucas Nussbaum wrote: [ Note that my position is based on the assumption that we have a share of DDs interested in rolling similar to the share of DDs interested in stable releases. Unfortunately, it's very difficult to know where we stand regarding this. ] I'm assuming that releasing is what Debian is about (and fwiw if you read Raphael's proposal, it's for him too), meaning that rolling is a second class citizen here. And frankly, I think that anything that makes rolling as important as releasing stables is against Debian (and its users) interest. Why? well just answer that question: would you run a rolling-based distro on servers? Answer: if you're a sysadmin it will be NO because the security model of rolling is update to the latest software, you know, the firefox-kind-of-security. Remember that we hate it, because with security fix come: - upgrade path hells - new bugs - removed features - … There are other distros out-there that do rolling release only (gentoo, arch), note how none of them also do stable releases (I think gentoo used to tag their repository every now and then, but that doesn't make them releases, please, at least not in the Debian sense). -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501201701.gd20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 04:26:57PM -0400, Joey Hess wrote: Pierre Habouzit wrote: Who are they? Unlike this constant handwaving, I've shared my experience ^^^ If you feel that my contributions and experience in Debian consist of constant handwaving, feel free to ignore and dismiss me. Your mail describes hypothetic users needing lots of backports. Where on earth did I speak of your contributions !? Please don't mix-up everything, this thread is painful enough as it is. Frankly I'm disappointed I used to think you didn't bait people like this. I'll re-phrase my question more directly: please explain me why CUT or rolling would change your life, and why wouldn't unstable cut it for you. Or if what was presented like an hypothetical user is you, why do you need so many backports that it doesnt work? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501203301.ge20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 10:36:07PM +0200, Lucas Nussbaum wrote: On 01/05/11 at 22:17 +0200, Pierre Habouzit wrote: On Sun, May 01, 2011 at 09:35:07PM +0200, Lucas Nussbaum wrote: [ Note that my position is based on the assumption that we have a share of DDs interested in rolling similar to the share of DDs interested in stable releases. Unfortunately, it's very difficult to know where we stand regarding this. ] I'm assuming that releasing is what Debian is about (and fwiw if you read Raphael's proposal, it's for him too), meaning that rolling is a second class citizen here. Well, I disagree. I believe that Debian is about building an operating system. Whether we deliver it through stable releases, or through a rolling release, or both, is an implementation detail. Yes, I pushed the thinking up to the point that I /also/ (I never said /only/) want to run Debian on servers and that a Stable release is the sole thing I'd like to run on them. [...] There are other distros out-there that do rolling release only (gentoo, arch), note how none of them also do stable releases (I think gentoo used to tag their repository every now and then, but that doesn't make them releases, please, at least not in the Debian sense). I don't follow your reasoning. - I don't think that we should restrict Debian to servers managed by serious sysadmins. - Gentoo Arch don't do stable releases, OK. Why would it mean that we couldn't do it? It's not a reasoning, I'm saying, I'm fine if Debian doesn't do rolling releases and to point people towards them. I just note that non of the rolling-released distro do no stable releases, something that tends to comfort my opinion that rolling and stable releases are somehow incompatible. It's clear that we are not going to stop doing stable releases anytime soon. However, there seem to be some interest in the rolling release concept. The question is: can we (Debian) provide a rolling release with an acceptable increase in workload, and without compromizing the quality of our stable releases ? If yes, why shouldn't we do it? Well, if you hadn't guess, I think it will increase workload and worse divert attention from what I think is a more important goal. But really what I'd like to see is numbers and compelling reasons to start all that CUT/rolling thing, because that's missing completely from the thread, I'm still not understanding why we need anything like that. You don't do something like that because it's hype, you do it because it's badly needed, and well, why? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501204833.gf20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 10:41:07PM +0200, Stefano Zacchiroli wrote: On Sun, May 01, 2011 at 10:08:46PM +0200, Pierre Habouzit wrote: Those are real users from real life. I'm not saying we-re representative of a majority of Debian Users, but unlike all the handwaived users we've read about in this thread, those are real. First of all I think you should concede that the exercise you're asking us to do cannot be done as easily as you did yours. You've been able to mention real users of an existing distro, you are asking others to provide evidence of users of a thing that does not exist yet; quite challenging... So you do have an inherent advantage, but let me try nonetheless. I don't concede that. I've read your mail, and to sum up you say: I've been in contact with lots of people interested into testing, Okay fine, I buy that, I won't call you a liar. So the next question is why your mail doesn't answer that. I still think that rolling is a bad idea, until you've proven me that it's the sole way to address a real life issue/need/itch. So why do Aptosid/Sidux/... exist, why do people think we should sell testing more? You don't answer that and it's critical to know it. IOW what does having CUT/rolling fixes please. FWIW I see one problem with the current testing, tied to the freeze, which is that a 6-months freeze means that we skip a release for all those projects that release twice a year, and those are many. Which is annoying for some of our users (gnome releases when it's not gnome3 are pretty sound e.g. it's not really bleeding edge that harms), and even more for packagers because it's harder not to package all upstream versions, it means that the upgrade is harder to deal with. But *that* I think can be adressed with a better experimental (using PPA, but we discussed that already and I think it's a consensus). And for that I think that rolling isn't the solution because of the entry-point issue I talked elsewhere: You still need to update testing during the freeze. And the larger the project, the higher the probability is that: - users will want the last version available; - you will have updates to send during the freeze. I surely miss other uses cases, so please enlighten me. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501210057.gg20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 11:07:48PM +0200, Raphael Hertzog wrote: On Sun, 01 May 2011, Carsten Hey wrote: Testing, OTOH, is really unique in that respect, with its mixture of fresh software and quarantine period. A 'frozen' requiring most updates to go through *-proposed-updates would make this quarantine period a lot less useful, and it would make circumstances like the one described above a lot more probable. One cause that testing-proposed-updates is not more widely used is that there is no good non-altruistic reason for a user to do so. More up-to-date packages are available in unstable and more tested packages are available in testing. There's a good reason to use testing-proposed-updates during freeze, it fixes security and release critical bugs that are present in testing! So if we tell users to use this repository, we're going to have some users (I upgrade my servers to testing during the freeze and I would enable it if it was generally advised for beta-testers). But yes there might be some unrelated regressions from time to time. There's a reason why it's not labeled stable yet. That's just semantics, Carsten mail is very good, and sums up what I've said elsewhere in a very clean way. The problem is, you need to entry points, one for testing as we know it, one for rolling. If you use t-p-u for testing and unstable for rolling, or unstable for testing and rolling-updates for rolling is just bikeshedding. The result is some of the users will use unstable and help testing, the other sort will run rolling-updates or rolling. So basically you split our users in two non overlapping sets, meaning that you divide coverage and tests. How come is that in the distribution interest?! I think it's not, I think it's resource squandering. So please, what is so useful and important that we wast our precious resources here, have two inconciliable Debians at once? Because users want it doesn't fly. I couldn't care less, I'm interested about *why* they want it, not the mere fact that they do. Because when you know why they want it, maybe there will be better answers that don't make releasing even more brittle and burn even more people out. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501211721.gh20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 01, 2011 at 11:39:47PM +0200, Lucas Nussbaum wrote: On 01/05/11 at 22:48 +0200, Pierre Habouzit wrote: On Sun, May 01, 2011 at 10:36:07PM +0200, Lucas Nussbaum wrote: It's clear that we are not going to stop doing stable releases anytime soon. However, there seem to be some interest in the rolling release concept. The question is: can we (Debian) provide a rolling release with an acceptable increase in workload, and without compromizing the quality of our stable releases ? If yes, why shouldn't we do it? Well, if you hadn't guess, I think it will increase workload I agree. The question is: will the increase of workload be worth it? and worse divert attention from what I think is a more important goal. Your point is basically we should discourage developers to do something else than working on getting the next stable release out. I don't buy it. I'm sure that we are all very good at procrastinating the things that we don't want to do, whether the excuses are provided by Debian or by other projects/hobbies. Developers who are not interested in helping with the release will just do something else. We can send a clear message to developers that getting the stable release out should be considered more important than working on rolling or on one's other pet projects, but besides that, I don't think that there's much more to do. No I say we're already not that good for Stable releases, why would we chose to be even worse. Would releasing be just a breeze my discourse would be very different. I think we're not that good at releasing that we can sustain rolling. 6 months of freeze is just too long. But really what I'd like to see is numbers and compelling reasons to start all that CUT/rolling thing, because that's missing completely from the thread, I'm still not understanding why we need anything like that. You don't do something like that because it's hype, you do it because it's badly needed, and well, why? There's a clear user demand for rolling releases. For evidence, one can look at the usage of Debian testing or unstable which clearly goes further than the DD community. Or at the quickly growing market share of ArchLinux. Or at the interest in LinuxMint and Aptosid. Personally, I'm surrounded by [advanced] Ubuntu users who would be interested in something *slightly* harder to use, with more recent software. I think that Debian is in a perfect position to provide a rolling release with marginal additional work, since we already have testing to build on. Benefits for Debian: - attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (developers, free software contributors), thus interesting to work with. Some of them could become Debian contributors. And even if they don't, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers]. I think those can use unstable, and if they use rolling, I think I already proved or at least explained why those don't contribute to the stable in being, but rather the N+1 one. Which is probably not bad, but not the most urgent thing. - give back to the free software world by providing a platform where new upstream releases would quickly be available to users. Since users would be able to test new upstream releases earlier, they would be able to provide feedback to upstream devs earlier, contributing to a shorter feedback loop. Why doesn't unstable fit that? - get back some attention that is currently taken away from Debian by derivatives. This is important to carry our /political/ messages, which are not necessarily carried out by our derivatives. *I* (but that's personal) don't care about that. I don't find that a compelling argument. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501214614.gi20...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
release because it's impractical to filter xorg packages from say the new KDE that sits in there at the same time). Testing is a Release Team tool before anything else. I don't think that making it more complex is gonna be of any help. It'll just kill the release team even more, and won't really solve anything. Plus I don't think that testing is broken, it serves its purpose well. What is broken is experimental. It has been created because 3 layers weren't enough, but it hasn't really been thought more than that. If you let me pursue the VCS analogy, just look at how git is developped. There are 4 spaces: - master: the releases (our stable) - maint: where the fixes go until it's merged into master (our stable-updates, somehow), and where next is merged when next is released. - next: where the devel happens, but nothing enters that before it has seen enough peer-review. This is our testing+unstable. - pu: as proposed-updates. There are totally unrelated topic branches here, glued together to check nothing is grossly broken, but it's rarely a working branch, or rather it's often broken. This is our experimental What is my point: nobody uses pu as a whole, instead there are a lot of topic branches that people can chose to enable in their next, because Junio always takes care that all topic can be merged into next. pu is just a directory of them all. Then when a topic branch becomes good enough, it gets merged into next, and leaves pu. We could make experimental (using a PPA-like decentralized infrastructure) work like that. It would clearly make our users more confident testing experimental stuff because each PPA is distinct from the other and you don't risk pulling to much crap on your system. It would solve the issues of e.g. reworking the packaging of llvm-2.8 (creating a llvm-2.8-NG PPA) and working on llvm-2.9 at the same time. It would allow us to make all the software that is in unstable only purposely go away (*-snapshot packages e.g., like gcc-snapshot and similar) because a PPA would be the place to go. And I'm sure there are lots of other good things it allows. But really, let's focus on relieving the expensive scarce resource (aka manpower, developers, maintainers) instead of adding burden on it for a dubious claim that users want it. If you add more burden to the scarce resource, instead of grabbing new users, you'll end up with worse quality and actually lose users: it's a lose-lose scenario on the long term. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110430233219.ga14...@madism.org
Re: Bits from the Release Team - Kicking off Wheezy
On Fri, Apr 29, 2011 at 02:21:40PM +0200, Stefano Zacchiroli wrote:
In general we need to promote the reduction of (potential) bottlenecks
in Debian rather than the contrary. ... and don't get me wrong: I'm very
well aware that this specific bottleneck is a very good feature to
have for the preparation of a stable release, given it means more
scrutiny and ultimately more quality. But given that rolling seems to
be willing to trade some of that stability off in favor of fresher
software, it might be warranted to lift it off there.
I think that we should not do any trade off on the quality of
rolling/testing/the-antechamber-of-stable, but instead raise the quality
of unstable so that (which isn't *that* bad, unstable is rarely badly
broken, and I know lots of stable releases of linux distributions that
are in worse state than the average of unstable on the same set of
packages…):
- testing is and remains a release only tool, as the stable staging
area.
- unstable becomes more suitable for less experienced users.
- stuff outside from unstable (experimental nowadays) gets more
attention.
I've already written one too long mail about that, but allowing DDs to
spin off some repositories in a PPA-way can be the way. Managing a
Debian mirror plus all the {uploading,building,bts}-infrastructure is a
PITA, but if we make it easy, it'll get used. As in VCSes branching
*and* merging repositories should be easy. For now we're not even in
the packing CVS era since branching is a PITA. Let's make it easy, and
then the whole rolling thing will be moot because unstable will be good
enough for our users 98% of the time.
[ And also relaxing our NMU policies would help too but that's yet
another story: in a few words, we should allow NMUs as soon as there
is enough acked-by for them… to enforce a minimal level of
peer-review, so that quality is checked, and relax all the conditions
to perform NMUs at once ]
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110501000619.gb14...@madism.org
Accepted dumpasn1 20101112-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 19 Mar 2011 09:49:14 +0100 Source: dumpasn1 Binary: dumpasn1 Architecture: source amd64 Version: 20101112-1 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: dumpasn1 - ASN.1 object dump program Closes: 573813 610934 Changes: dumpasn1 (20101112-1) unstable; urgency=low . * New upstream release (Closes: #610934): + Large numbers are now printed properly (Closes: #573813). * Migrate to dh 8. * Bump standards version to 3.9.1. * Switch to dpkg-source 3.0 (quilt) format. Checksums-Sha1: 37a2e20f7d890fbce7214a76b3f349d072ee9558 972 dumpasn1_20101112-1.dsc 663342df18e52bb22de8e624724749f24bd5a16f 56787 dumpasn1_20101112.orig.tar.gz aee347d29a9530d61aad69368b181733269b5cd9 3277 dumpasn1_20101112-1.diff.gz 90cd05041c65b09277c438b6a3b928fcb89cac02 49060 dumpasn1_20101112-1_amd64.deb Checksums-Sha256: 8bbf775f8e289371cfe8eb47e5389734b77118b981d3dc5362adf4f486f5356d 972 dumpasn1_20101112-1.dsc 42304dd5f820596c15fe82e98fd694bb137247fa4f85cbe9cddbfb8dba71bf5e 56787 dumpasn1_20101112.orig.tar.gz 2cb7b5e33016695ea9a3b06626a01312f9ba8a834dcd651219d084b5167d2d3f 3277 dumpasn1_20101112-1.diff.gz d566b4f16d11741091d41b0d5e1efeea13ad9c5f82aac6c728d3e0f09e356c4e 49060 dumpasn1_20101112-1_amd64.deb Files: 9fbdd1a9e347a75773687e563d25f97f 972 utils optional dumpasn1_20101112-1.dsc 4421e8b4128b75bd1868b80173e075cc 56787 utils optional dumpasn1_20101112.orig.tar.gz 0da40764708c7a7075f5fb890f09f938 3277 utils optional dumpasn1_20101112-1.diff.gz eb1c62d6491918559e97cac5701e5cdf 49060 utils optional dumpasn1_20101112-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2EcLAACgkQvGr7W6HudhxUPgCeIgSJmgI1GnVpuZcVLg1JGQQ7 CE4Ani84AkYYtU+2k7GI2lsIXBJ3QrNH =1oIM -END PGP SIGNATURE- Accepted: dumpasn1_20101112-1.diff.gz to main/d/dumpasn1/dumpasn1_20101112-1.diff.gz dumpasn1_20101112-1.dsc to main/d/dumpasn1/dumpasn1_20101112-1.dsc dumpasn1_20101112-1_amd64.deb to main/d/dumpasn1/dumpasn1_20101112-1_amd64.deb dumpasn1_20101112.orig.tar.gz to main/d/dumpasn1/dumpasn1_20101112.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1q0sw2-kl...@franck.debian.org
Accepted proxsmtp 1.9-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 19 Mar 2011 10:15:40 +0100 Source: proxsmtp Binary: proxsmtp Architecture: source amd64 Version: 1.9-1 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: proxsmtp - multi purpose SMTP Proxy Changes: proxsmtp (1.9-1) unstable; urgency=low . * New upstream release: + detect netfilter header properly (Closes: LP#694463). + Bump standards versions to 3.9.1. * Packaging updates: + Switch to source format v3 (quilt): + rename README.packaging as README.source. + Move to debhelper 8. * Add missing $remote_fs in proper LSB Headers (thanks lintian). * add libcap-dev to build-depends to enable capabilities features. Checksums-Sha1: 2de563c5ae9557500427200474aaf1bdbf49bb48 1112 proxsmtp_1.9-1.dsc 948d3035e7331d9e5f93ec7c2e8f0e7cb3024bb1 182800 proxsmtp_1.9.orig.tar.gz 144babedea34d5dd329cdfbc08f34b8bbfb51492 3760 proxsmtp_1.9-1.debian.tar.gz 7e5991bd63a5305f527a75757b712aca60121565 49228 proxsmtp_1.9-1_amd64.deb Checksums-Sha256: 5869c2f5c2a3961e8bca342a5b2422f712893ca424ccf527949bb1f6ee03dc60 1112 proxsmtp_1.9-1.dsc e4dd61a370b3bc1689f6281470bc992525c04d118d6efba5154dee61be810b58 182800 proxsmtp_1.9.orig.tar.gz 3af03c606f7adfd2ff23e62e96395da002da6f220030e4b998f5859d6d815723 3760 proxsmtp_1.9-1.debian.tar.gz af8155c313aebd17f0f780dc7cdf68a0e48302c25f79718fac70f7332ffd412e 49228 proxsmtp_1.9-1_amd64.deb Files: 95fd486a1789a11284222517b2461a97 1112 mail optional proxsmtp_1.9-1.dsc c5ab4f3c48c9baad14629ad5e291d8c1 182800 mail optional proxsmtp_1.9.orig.tar.gz ef830c8f904ba2e541f89d727d87a99d 3760 mail optional proxsmtp_1.9-1.debian.tar.gz 30be102d03143da3a8325c30065f1933 49228 mail optional proxsmtp_1.9-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2EdXYACgkQvGr7W6HudhzuXQCeKg9byfG0pqC3fmFR+I0ogXUH UBgAoKW/5ia1sARevYjv9DqerThozGwd =7525 -END PGP SIGNATURE- Accepted: proxsmtp_1.9-1.debian.tar.gz to main/p/proxsmtp/proxsmtp_1.9-1.debian.tar.gz proxsmtp_1.9-1.dsc to main/p/proxsmtp/proxsmtp_1.9-1.dsc proxsmtp_1.9-1_amd64.deb to main/p/proxsmtp/proxsmtp_1.9-1_amd64.deb proxsmtp_1.9.orig.tar.gz to main/p/proxsmtp/proxsmtp_1.9.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1q0saq-wy...@franck.debian.org
Accepted sparse 0.4.3-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 19 Mar 2011 20:26:16 +0100 Source: sparse Binary: sparse Architecture: source amd64 Version: 0.4.3-1 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: sparse - semantic parser of source files Closes: 566605 587005 607432 608592 Changes: sparse (0.4.3-1) unstable; urgency=low . * New upstream release (Closes: #587005): + inline forward declarations are now allowed (Closes: #607432). * Update Homepage (Closes: #566605). * Bump standards versions to 3.9.1. * Switch from cdbs to debhelper. * Add libxml2-dev and libgtk2.0-dev to build-depends to build new tools (Closes: #608592). Checksums-Sha1: f2b0faaab015e6e285e19a3c6977716ddeaefb8d 1169 sparse_0.4.3-1.dsc 6d0933b2633f8cebc00b1d4c0af8b821cdd6634b 172431 sparse_0.4.3.orig.tar.bz2 5cb10bd82ab9ad4ac769c3d3b09b31dd078e0e3f 6546 sparse_0.4.3-1.debian.tar.gz b9a7313c25ac69ac73a297a132a5148c151afe08 571032 sparse_0.4.3-1_amd64.deb Checksums-Sha256: 244cf5abe040c2220f5f97122b869e22b7a49511784a522ca4c8425696b0c71e 1169 sparse_0.4.3-1.dsc 9059bc649ca8c9309e542d0015091ccf72ac9e3300db0adb4eba838cdcc82f9c 172431 sparse_0.4.3.orig.tar.bz2 8f18829e7bf1afcad7b331a533dd6204a01f9291c789e5478e89fc978c9ac5ea 6546 sparse_0.4.3-1.debian.tar.gz 6f4696162cc09d1973bf4fbea35619203ab973f84d39c7190ceb35339b4cad56 571032 sparse_0.4.3-1_amd64.deb Files: ac2b43e6b5de11375a552595097b5657 1169 non-free/devel optional sparse_0.4.3-1.dsc a5c0b07bd00ad5ea292f804d7af1adbc 172431 non-free/devel optional sparse_0.4.3.orig.tar.bz2 778572fb7c014b5476e609fcaf311536 6546 non-free/devel optional sparse_0.4.3-1.debian.tar.gz 7eeffcdd002ee60028b8485605483116 571032 non-free/devel optional sparse_0.4.3-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2FA28ACgkQvGr7W6HudhzIrwCbBKqocaj2tbyo0S/C9fGzItP+ kNcAnRtbbQGJ76VgFfvXcZ9dlSmMpDdO =/SUt -END PGP SIGNATURE- Accepted: sparse_0.4.3-1.debian.tar.gz to non-free/s/sparse/sparse_0.4.3-1.debian.tar.gz sparse_0.4.3-1.dsc to non-free/s/sparse/sparse_0.4.3-1.dsc sparse_0.4.3-1_amd64.deb to non-free/s/sparse/sparse_0.4.3-1_amd64.deb sparse_0.4.3.orig.tar.bz2 to non-free/s/sparse/sparse_0.4.3.orig.tar.bz2 -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1q11sf-0007rq...@franck.debian.org
Accepted proxsmtp 1.9-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 19 Mar 2011 23:04:43 +0100 Source: proxsmtp Binary: proxsmtp Architecture: source amd64 Version: 1.9-2 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: proxsmtp - multi purpose SMTP Proxy Changes: proxsmtp (1.9-2) unstable; urgency=low . * libcap-dev is linux-only. Checksums-Sha1: 6851f34063b066ea855e28eb96ef7b2e283605b9 1127 proxsmtp_1.9-2.dsc c5cf13789e71b161ba8a19aceedd0488bed6ecf9 14904 proxsmtp_1.9-2.debian.tar.gz 3d62f72833ccb747fa403f09ca6497244496fc6a 49264 proxsmtp_1.9-2_amd64.deb Checksums-Sha256: 0affdae455df308e6a4c141d6516131de4c3b4a8133bf8eb55b8132e7d45a676 1127 proxsmtp_1.9-2.dsc 80ae570a93888740c5c06eda4baed1a5c36e61e17ec7c1af81181d54a838 14904 proxsmtp_1.9-2.debian.tar.gz e6b8cb1358ff5ab7694a3c93e4b4195d2c9a50d6336436fe558c4a179ae9d901 49264 proxsmtp_1.9-2_amd64.deb Files: 79d285fbcd656b963e6eb5ffd0b580af 1127 mail optional proxsmtp_1.9-2.dsc 2ebc4b73f2bcb597827f135ff9067473 14904 mail optional proxsmtp_1.9-2.debian.tar.gz 5706cf1de7244fd15426ea967e3d8341 49264 mail optional proxsmtp_1.9-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2FKJkACgkQvGr7W6HudhwPggCffCnXmYKkOOYGkkIHgJLoxgTV rKMAn3l/ond6qqinaaz0uf0pbGhX9U5O =Naqs -END PGP SIGNATURE- Accepted: proxsmtp_1.9-2.debian.tar.gz to main/p/proxsmtp/proxsmtp_1.9-2.debian.tar.gz proxsmtp_1.9-2.dsc to main/p/proxsmtp/proxsmtp_1.9-2.dsc proxsmtp_1.9-2_amd64.deb to main/p/proxsmtp/proxsmtp_1.9-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1q15pb-0002da...@franck.debian.org
Re: Bug#590527: ITP: mussh -- MUltihost SSH Wrapper
On Tue, Jul 27, 2010 at 12:46:16AM -0400, Holger Levsen wrote: Hi Jacob, On Montag, 26. Juli 2010, Jacob Luna Lundberg wrote: * Package name: mussh Mussh is a shell script that allows you to execute a command or script over ssh on multiple hosts with one command. When possible mussh will use ssh-agent and RSA/DSA keys to minimize the need to enter your password more than once. how is that different to dsh, already present in Debian? Or clusterssh ? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100728131459.gh6...@madism.org
Accepted apt-listchanges 2.85.2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 19 Jul 2010 11:15:50 +0200 Source: apt-listchanges Binary: apt-listchanges Architecture: source all Version: 2.85.2 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: apt-listchanges - package change history notification tool Closes: 491306 525978 Changes: apt-listchanges (2.85.2) unstable; urgency=low . * apt-listchanges no longer supposes that binary packages all have the same version for a given source package; Closes: #525978, #491306 Checksums-Sha1: ce7540dc9627dfd4192cdbd01a05d1df1465c7d0 1123 apt-listchanges_2.85.2.dsc c291321bcee8f05bc60461dabfe08f29d868a6f2 100596 apt-listchanges_2.85.2.tar.gz 1a24a572bd1f63a2ce4de86a2c84fdb40d6d4382 82992 apt-listchanges_2.85.2_all.deb Checksums-Sha256: a2fa936924be60b5bb10ecb55c4c83e9d0f87ef05e0c4a5d68919abeee0e99a5 1123 apt-listchanges_2.85.2.dsc 81bd817dc78fa2839b85bf0e7ffd8967b93192d6e98803fa8c3a4c2aa16ea96c 100596 apt-listchanges_2.85.2.tar.gz abe41ede9993044a5aced4a4a81d2ad59776aba7925359b6b9d6157b6b8aebfa 82992 apt-listchanges_2.85.2_all.deb Files: 1b0ded1bdba2470df89efc5396776559 1123 utils standard apt-listchanges_2.85.2.dsc 2ecb736a7d53b98f4d11a69fe1d5000f 100596 utils standard apt-listchanges_2.85.2.tar.gz 5a0e6c805a1dd4183599ebeb083e9cd0 82992 utils standard apt-listchanges_2.85.2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxEF+YACgkQvGr7W6HudhwoFwCfeJPqWcaZ3ECjZBg7Z+Ybjlwa l8IAoJxfs3Do8EmtoITdjk+/uq89Oo8a =iLjb -END PGP SIGNATURE- Accepted: apt-listchanges_2.85.2.dsc to main/a/apt-listchanges/apt-listchanges_2.85.2.dsc apt-listchanges_2.85.2.tar.gz to main/a/apt-listchanges/apt-listchanges_2.85.2.tar.gz apt-listchanges_2.85.2_all.deb to main/a/apt-listchanges/apt-listchanges_2.85.2_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oamhi-0007cl...@franck.debian.org
Re: APT do not work with Squid as a proxy because of pipelining default
On Wed, May 19, 2010 at 03:28:00PM +0200, Bjørn Mork wrote: Pierre Habouzit madco...@madism.org writes: On Wed, May 19, 2010 at 10:42:55AM +0200, Bjørn Mork wrote: 2) http proxy servers cannot always process pipelined requests due to the complexity this adds (complexity is always bad for security), and This is bullshit. It's *VERY* easy to support pipelining: parse one request at a time, and until you're done with a given request, you just stop to watch the socket/file-descriptor for reading (IOW you let the consecutive request live in the kernel buffers). Yeah, you make it sound easy. The fact is that it is. And I know it from a fact having implemented several custom http interfaces in the past. It's just _that_ easy. And since it's _that_ easy, when the broken proxy is free software, it shall be fixed. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100520231042.gb23...@madism.org
Re: APT do not work with Squid as a proxy because of pipelining default
On Wed, May 19, 2010 at 10:42:55AM +0200, Bjørn Mork wrote: 2) http proxy servers cannot always process pipelined requests due to the complexity this adds (complexity is always bad for security), and This is bullshit. It's *VERY* easy to support pipelining: parse one request at a time, and until you're done with a given request, you just stop to watch the socket/file-descriptor for reading (IOW you let the consecutive request live in the kernel buffers). Such an implementation of course doesn't benefit from the pipelining wins, but it works just fine. In addition to that, multiplying the tcp connections means more file descriptors to be used at the http-server side, which is way inferior to pipelining. If squid fails when apt uses pipelining then squid is to be fixed. I'd say that mentioning in the README.Debian of apt that disabling the pipelining may help is fine, but disabling it by default is wrong. Pipelining is defined in the RFC since the nineties ffs... -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100519124134.gc20...@madism.org
Accepted tokyocabinet 1.4.37-5 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 19 May 2010 23:21:30 +0200 Source: tokyocabinet Binary: libtokyocabinet8 libtokyocabinet-dbg libtokyocabinet-dev tokyocabinet-doc tokyocabinet-bin Architecture: source amd64 all Version: 1.4.37-5 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: libtokyocabinet-dbg - Tokyo Cabinet Database Libraries [runtime] libtokyocabinet-dev - Tokyo Cabinet Database Libraries [development] libtokyocabinet8 - Tokyo Cabinet Database Libraries [runtime] tokyocabinet-bin - Tokyo Cabinet Database Utilities tokyocabinet-doc - Tokyo Cabinet Database Documentation Changes: tokyocabinet (1.4.37-5) unstable; urgency=low . * Move to debhelper 7. * Switch to dpkg-source 3.0 (quilt) format * Disable pthread support on s390, hopefully fixing the test-suite for now. Checksums-Sha1: c39de4c834863c79151e86dd37b0605e03d7eeec 1299 tokyocabinet_1.4.37-5.dsc d7cc423e1559c194322a06c933768e295800ce4f 13235 tokyocabinet_1.4.37-5.debian.tar.gz 2987492437c76cd0ecbc2067a81a8929e4dcf704 284598 libtokyocabinet8_1.4.37-5_amd64.deb a76e33bc43fc0d148f0ad8055b17f343201fc5f1 756690 libtokyocabinet-dbg_1.4.37-5_amd64.deb c95e335675bfdcfc188ac893bfcee18f2c789c52 432430 libtokyocabinet-dev_1.4.37-5_amd64.deb 2d24270b72a7a3dfd2daa707e3b9c51a1123e91f 1043622 tokyocabinet-doc_1.4.37-5_all.deb 94c6a7ed0c7561c9400c73ab54c6d3ce49485f01 316160 tokyocabinet-bin_1.4.37-5_amd64.deb Checksums-Sha256: a0ec24d1a5b9254361622dbbf4a42ffe6c3a1b6bcc679e92c10aa48b95902fb7 1299 tokyocabinet_1.4.37-5.dsc 4dcffb41e3e7ced96f12676515a6c825296dc02933845a45e465f6efed319491 13235 tokyocabinet_1.4.37-5.debian.tar.gz 83a9937792ffd92724ea5781bb0136af06e7fd2f2a711ec4fc213fd523a44cca 284598 libtokyocabinet8_1.4.37-5_amd64.deb 2c30c160eec880006d25705aeb82cdf88c812e5565832013b750e3abd560b666 756690 libtokyocabinet-dbg_1.4.37-5_amd64.deb c4af851749e257a70cf835f621224a5604660f329f66b87a0ba5730669e3b76d 432430 libtokyocabinet-dev_1.4.37-5_amd64.deb 0a1b4efb8f038f6a64008cfc2e178a0a98ac23ecc92180e2e58a700bfaadbec9 1043622 tokyocabinet-doc_1.4.37-5_all.deb 7d3322a433bee47920ac60aeca906c9e4ec7058a2e20f130ffd795a2fadeb46a 316160 tokyocabinet-bin_1.4.37-5_amd64.deb Files: 8944a54a77f21d57b93bb99aacca4160 1299 libs extra tokyocabinet_1.4.37-5.dsc 0a78da939a358220baa27520fb80839d 13235 libs extra tokyocabinet_1.4.37-5.debian.tar.gz 0bb1645b66f25548814f30711ea55c38 284598 libs extra libtokyocabinet8_1.4.37-5_amd64.deb 109c463992559a6de7f27ab6ece9f470 756690 debug extra libtokyocabinet-dbg_1.4.37-5_amd64.deb 1f6b90fe2bb8f8a72233ca6c66a84b58 432430 libdevel extra libtokyocabinet-dev_1.4.37-5_amd64.deb cf7e5fb18f32870838c8058835bddcba 1043622 doc optional tokyocabinet-doc_1.4.37-5_all.deb 6ace74bd16747af85678ef8b4129286f 316160 utils optional tokyocabinet-bin_1.4.37-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkv0Vp4ACgkQvGr7W6HudhyZJACdFM8XeAELypQnF+ydRUS6ihms vmgAn0y40YY8K4y3KjlwlmS3D31FPoux =8ObK -END PGP SIGNATURE- Accepted: libtokyocabinet-dbg_1.4.37-5_amd64.deb to main/t/tokyocabinet/libtokyocabinet-dbg_1.4.37-5_amd64.deb libtokyocabinet-dev_1.4.37-5_amd64.deb to main/t/tokyocabinet/libtokyocabinet-dev_1.4.37-5_amd64.deb libtokyocabinet8_1.4.37-5_amd64.deb to main/t/tokyocabinet/libtokyocabinet8_1.4.37-5_amd64.deb tokyocabinet-bin_1.4.37-5_amd64.deb to main/t/tokyocabinet/tokyocabinet-bin_1.4.37-5_amd64.deb tokyocabinet-doc_1.4.37-5_all.deb to main/t/tokyocabinet/tokyocabinet-doc_1.4.37-5_all.deb tokyocabinet_1.4.37-5.debian.tar.gz to main/t/tokyocabinet/tokyocabinet_1.4.37-5.debian.tar.gz tokyocabinet_1.4.37-5.dsc to main/t/tokyocabinet/tokyocabinet_1.4.37-5.dsc -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oerlr-0007uz...@ries.debian.org
Accepted tokyocabinet 1.4.37-6 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 19 May 2010 23:36:27 +0200 Source: tokyocabinet Binary: libtokyocabinet8 libtokyocabinet-dbg libtokyocabinet-dev tokyocabinet-doc tokyocabinet-bin Architecture: source amd64 all Version: 1.4.37-6 Distribution: unstable Urgency: high Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: libtokyocabinet-dbg - Tokyo Cabinet Database Libraries [runtime] libtokyocabinet-dev - Tokyo Cabinet Database Libraries [development] libtokyocabinet8 - Tokyo Cabinet Database Libraries [runtime] tokyocabinet-bin - Tokyo Cabinet Database Utilities tokyocabinet-doc - Tokyo Cabinet Database Documentation Changes: tokyocabinet (1.4.37-6) unstable; urgency=high . * Woops, the test-suite was incorrectly disabled, enable it again. * Bump the urgency to high as this fixes the last RC issue of the package (unbuildable on s390). The RC bug isn't closed as it isn't really an tokyocabinet bug but likely a glibc one (see #40). Checksums-Sha1: 459d742b466ef9c5b43b727c68a73f2fa8b3dbb8 1299 tokyocabinet_1.4.37-6.dsc 34b704bf2cd888034be9bfa9ee019c66200a6b19 13361 tokyocabinet_1.4.37-6.debian.tar.gz 52f45be09bce472044af10dd93eb594e66971268 284744 libtokyocabinet8_1.4.37-6_amd64.deb 64548c4fc72524707dbb1fc0d198b100d7dc6634 757034 libtokyocabinet-dbg_1.4.37-6_amd64.deb 3e5b1fb1e19e87a906434f3e971216a3a1ebc690 432586 libtokyocabinet-dev_1.4.37-6_amd64.deb e32694771ac33d9ca5eaa6d49edb727f0aa4f261 1043752 tokyocabinet-doc_1.4.37-6_all.deb f09e528ef038bcf1c30f48007940d774419e03cc 316288 tokyocabinet-bin_1.4.37-6_amd64.deb Checksums-Sha256: a08da23cf1b6df1a76959c8c38eae381b5b143a73d64e2fdbd7afce460697925 1299 tokyocabinet_1.4.37-6.dsc dd22e548eeb057dfa7de30b769aeb5fc915cb85479dadc42c9c2cab07a5dedde 13361 tokyocabinet_1.4.37-6.debian.tar.gz 32b33513db7e49180b35a2034a065d04c4f651150a2c2f7a2201c4476c43b088 284744 libtokyocabinet8_1.4.37-6_amd64.deb 7a5a7585897803f27bb7dfb6eaada012d631ef37cde6a7ee707b0968b9c2455e 757034 libtokyocabinet-dbg_1.4.37-6_amd64.deb df86cd90a2f3a0c9c2b633100edb593331164bf76b3c6c61032bebf8816bf700 432586 libtokyocabinet-dev_1.4.37-6_amd64.deb 23a684e80f3a28c5a39f89cdc3d3cc7946b28d6b0142bef40f79d09546f1d17a 1043752 tokyocabinet-doc_1.4.37-6_all.deb be1fc07ec304e2970e09a3ed540393d834b5734f53af76ed8a9a197f58262c1a 316288 tokyocabinet-bin_1.4.37-6_amd64.deb Files: 60d595d59028b9d114dbc4ca7ff066ba 1299 libs extra tokyocabinet_1.4.37-6.dsc c77214db76bb718bee7a3901daeec122 13361 libs extra tokyocabinet_1.4.37-6.debian.tar.gz cfe332527765c6429bfc415ef180554e 284744 libs extra libtokyocabinet8_1.4.37-6_amd64.deb 1d4e4c5bed42b326b9e772fdcdf8fe24 757034 debug extra libtokyocabinet-dbg_1.4.37-6_amd64.deb 02c96bdfc9899c7e067f1f1ebfd52200 432586 libdevel extra libtokyocabinet-dev_1.4.37-6_amd64.deb 423ba397a9f543bad2bd27e1fa3d73ca 1043752 doc optional tokyocabinet-doc_1.4.37-6_all.deb a5bc40f63dc25217b875a1fc471e52a5 316288 utils optional tokyocabinet-bin_1.4.37-6_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkv0WocACgkQvGr7W6HudhxapgCePqeDN0cIjybLmUZbmmJ+pzQ7 ppQAni5Z6nYfQDrcIyhmm3QOy8nvPeW6 =XdBt -END PGP SIGNATURE- Accepted: libtokyocabinet-dbg_1.4.37-6_amd64.deb to main/t/tokyocabinet/libtokyocabinet-dbg_1.4.37-6_amd64.deb libtokyocabinet-dev_1.4.37-6_amd64.deb to main/t/tokyocabinet/libtokyocabinet-dev_1.4.37-6_amd64.deb libtokyocabinet8_1.4.37-6_amd64.deb to main/t/tokyocabinet/libtokyocabinet8_1.4.37-6_amd64.deb tokyocabinet-bin_1.4.37-6_amd64.deb to main/t/tokyocabinet/tokyocabinet-bin_1.4.37-6_amd64.deb tokyocabinet-doc_1.4.37-6_all.deb to main/t/tokyocabinet/tokyocabinet-doc_1.4.37-6_all.deb tokyocabinet_1.4.37-6.debian.tar.gz to main/t/tokyocabinet/tokyocabinet_1.4.37-6.debian.tar.gz tokyocabinet_1.4.37-6.dsc to main/t/tokyocabinet/tokyocabinet_1.4.37-6.dsc -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oerad-0004zl...@ries.debian.org
Accepted tokyocabinet 1.4.37-4 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 07 Feb 2010 11:14:51 +0100 Source: tokyocabinet Binary: libtokyocabinet8 libtokyocabinet-dbg libtokyocabinet-dev tokyocabinet-doc tokyocabinet-bin Architecture: source amd64 all Version: 1.4.37-4 Distribution: unstable Urgency: high Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: libtokyocabinet-dbg - Tokyo Cabinet Database Libraries [runtime] libtokyocabinet-dev - Tokyo Cabinet Database Libraries [development] libtokyocabinet8 - Tokyo Cabinet Database Libraries [runtime] tokyocabinet-bin - Tokyo Cabinet Database Utilities tokyocabinet-doc - Tokyo Cabinet Database Documentation Changes: tokyocabinet (1.4.37-4) unstable; urgency=high . * Disable the test-suite on armel until the buildds kernels are fixed. Checksums-Sha1: 5b957449b9830d79f4832ca455e9bb029a631680 1268 tokyocabinet_1.4.37-4.dsc a815d71e717c3283faadcc687d52824af1ab7190 12967 tokyocabinet_1.4.37-4.diff.gz 16fe2cbcbf6c974d63689dbd2994d05d5061b8f3 284518 libtokyocabinet8_1.4.37-4_amd64.deb a60d65d5cc351ea0990437594d222bc25fb8bdab 754114 libtokyocabinet-dbg_1.4.37-4_amd64.deb 10579ab5e5556464c35408f36efd6c03563e3a12 434580 libtokyocabinet-dev_1.4.37-4_amd64.deb 500f587cca8ab16320b568b8bdc45bce5de8bd94 1043620 tokyocabinet-doc_1.4.37-4_all.deb 2ad3f3f70c198b24ae8819db5338758c8b576958 316930 tokyocabinet-bin_1.4.37-4_amd64.deb Checksums-Sha256: e99eac07318a5ba500a3c92390fa787e018638d94697b0fabeebb51bdff87184 1268 tokyocabinet_1.4.37-4.dsc ba5cdedccb7fdef35d45be284ae1fca6886557b485da0ca77223f5d53d81fe47 12967 tokyocabinet_1.4.37-4.diff.gz 20fd38ed0a025a88787b980e1c331819b65bd25e1f1a9e79abbcf11d276e64cb 284518 libtokyocabinet8_1.4.37-4_amd64.deb c83c42d15d144900aec2b1a56756cd72d18c3d7749b08759809ea4e40c265470 754114 libtokyocabinet-dbg_1.4.37-4_amd64.deb 66047bb617d541be7c9293f0b0f72a8f8ac30313b553e58f7497281d14822bdc 434580 libtokyocabinet-dev_1.4.37-4_amd64.deb 7330f2761fca99d44c5db2305f2f250136003cdc1f201951b077da4177a30a41 1043620 tokyocabinet-doc_1.4.37-4_all.deb 34b6dfef1dd88c561bce077fb704f637ce0d928d1897ca004a69ed2c49b06821 316930 tokyocabinet-bin_1.4.37-4_amd64.deb Files: 091538c93b4cd49135a1bab9ccc24ba4 1268 libs extra tokyocabinet_1.4.37-4.dsc 79de542cc4e000da0730fc18eb585387 12967 libs extra tokyocabinet_1.4.37-4.diff.gz 6d1c43e5dacb9cd4169673a49c8b1c22 284518 libs extra libtokyocabinet8_1.4.37-4_amd64.deb 7ad124da2134c27c840814d448014181 754114 debug extra libtokyocabinet-dbg_1.4.37-4_amd64.deb 118308b242e0c2d49c41542a0959427c 434580 libdevel extra libtokyocabinet-dev_1.4.37-4_amd64.deb 9621188022ea94a05c142ef1edcb82de 1043620 doc optional tokyocabinet-doc_1.4.37-4_all.deb e29945dbd051b987cea0550f52bb7742 316930 utils optional tokyocabinet-bin_1.4.37-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAktuskQACgkQvGr7W6HudhwkiACdGSiiJyewvE5Ef2eHz51qqsE7 AWcAniVAtwS7CPkxDMxLPnr6+/LScQNn =ONc9 -END PGP SIGNATURE- Accepted: libtokyocabinet-dbg_1.4.37-4_amd64.deb to main/t/tokyocabinet/libtokyocabinet-dbg_1.4.37-4_amd64.deb libtokyocabinet-dev_1.4.37-4_amd64.deb to main/t/tokyocabinet/libtokyocabinet-dev_1.4.37-4_amd64.deb libtokyocabinet8_1.4.37-4_amd64.deb to main/t/tokyocabinet/libtokyocabinet8_1.4.37-4_amd64.deb tokyocabinet-bin_1.4.37-4_amd64.deb to main/t/tokyocabinet/tokyocabinet-bin_1.4.37-4_amd64.deb tokyocabinet-doc_1.4.37-4_all.deb to main/t/tokyocabinet/tokyocabinet-doc_1.4.37-4_all.deb tokyocabinet_1.4.37-4.diff.gz to main/t/tokyocabinet/tokyocabinet_1.4.37-4.diff.gz tokyocabinet_1.4.37-4.dsc to main/t/tokyocabinet/tokyocabinet_1.4.37-4.dsc -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted nsd3 3.2.3-5 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 10 Nov 2009 21:45:02 +0100 Source: nsd3 Binary: nsd3 Architecture: source amd64 Version: 3.2.3-5 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: nsd3 - authoritative domain name server (3.x series) Changes: nsd3 (3.2.3-5) unstable; urgency=low . * init: remove spurious and bogus -- argument to nsdc. Checksums-Sha1: 325b3321f36ca801f9d01aca3f4303c1e7f39a01 1114 nsd3_3.2.3-5.dsc 7e43043e31183843e535254ad08101bd0873fac7 8406 nsd3_3.2.3-5.diff.gz 846078aeaf6aabcad52def8562b218f7120e5375 907306 nsd3_3.2.3-5_amd64.deb Checksums-Sha256: 85da9c459be14bf3a75f625853d66db6f06a09b0f7d54e075e5e36d02ff15c1f 1114 nsd3_3.2.3-5.dsc 02cebbd6876b4cff3becb50d106066b8d5a45fca753f60e90c3c5f61fabfd41d 8406 nsd3_3.2.3-5.diff.gz ffba6187f277fd33510ad94cc4378182cbf0eadb40ce0990c945635d5b56d791 907306 nsd3_3.2.3-5_amd64.deb Files: 156a80bb2be113b49bd6d941eeb92292 1114 net extra nsd3_3.2.3-5.dsc 1c5ae3942ec21ad45c2860d7b0a30c71 8406 net extra nsd3_3.2.3-5.diff.gz db381fbc7186301ab0f18fdf05d386cf 907306 net extra nsd3_3.2.3-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkr50TQACgkQvGr7W6HudhyxygCffJjKIvzleVEjojEZ3hB0kD8+ FuAAnRbS5jhdBcWjpWe0DU3EWjTLUaFX =zebX -END PGP SIGNATURE- Accepted: nsd3_3.2.3-5.diff.gz to main/n/nsd3/nsd3_3.2.3-5.diff.gz nsd3_3.2.3-5.dsc to main/n/nsd3/nsd3_3.2.3-5.dsc nsd3_3.2.3-5_amd64.deb to main/n/nsd3/nsd3_3.2.3-5_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted tokyocabinet 1.4.37-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 10 Nov 2009 21:57:05 +0100 Source: tokyocabinet Binary: libtokyocabinet8 libtokyocabinet-dbg libtokyocabinet-dev tokyocabinet-doc tokyocabinet-bin Architecture: source amd64 all Version: 1.4.37-2 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: libtokyocabinet-dbg - Tokyo Cabinet Database Libraries [runtime] libtokyocabinet-dev - Tokyo Cabinet Database Libraries [development] libtokyocabinet8 - Tokyo Cabinet Database Libraries [runtime] tokyocabinet-bin - Tokyo Cabinet Database Utilities tokyocabinet-doc - Tokyo Cabinet Database Documentation Changes: tokyocabinet (1.4.37-2) unstable; urgency=low . * Add patches/0004-Cherry-pick-alignment-fixes-from-1.4.38.patch to try to fix SIGBUSes on sparc and hppa. * Fix section for libtokyocabinet-dbg (Use debug). Checksums-Sha1: 4e3a67ede4e7cd725756ca7160e8958c927a23ca 1268 tokyocabinet_1.4.37-2.dsc d8f1de938949b453bf3d1f47d62f73c05358fb67 10857 tokyocabinet_1.4.37-2.diff.gz a364071b4d7b0af23afd1764fbe23cc8a7bebb4a 278720 libtokyocabinet8_1.4.37-2_amd64.deb c71881817c9ea9dea5a073860e75ce3c2840cc2d 825566 libtokyocabinet-dbg_1.4.37-2_amd64.deb 5d61b65ababffbd3c15e14735112424f49220fcd 427164 libtokyocabinet-dev_1.4.37-2_amd64.deb 14ef8b0ae4e8ee55bee50bb8eb6b1e2314fb2496 1043354 tokyocabinet-doc_1.4.37-2_all.deb 0df5700569e41003eda3db462d3327f68586dfad 298626 tokyocabinet-bin_1.4.37-2_amd64.deb Checksums-Sha256: b49bcd3c22f966bef160027c3aca604846ab5b51e884f51f7452f827d2862a72 1268 tokyocabinet_1.4.37-2.dsc cfc500505c9e487fc105fc6cf54902d51e98edb4a6cdb23dd85225035063aefd 10857 tokyocabinet_1.4.37-2.diff.gz d2364ea446e35a683b537016f409dc1ed5d023c215e70cbcbd41d2cd4aeec0bd 278720 libtokyocabinet8_1.4.37-2_amd64.deb eaecba941ea0704737f3b14aae40a6fc329d42d03a067de95c01cf672725c5a5 825566 libtokyocabinet-dbg_1.4.37-2_amd64.deb 356fee4a0ae980bd58b5b4fcd240f87b9443e095a1b914997ab7a0f0219f20ee 427164 libtokyocabinet-dev_1.4.37-2_amd64.deb 74f0c5fcc9bd6cb427d9731ddad3bbfcb5f030a0266c1b4e80a697734253f4f0 1043354 tokyocabinet-doc_1.4.37-2_all.deb 17693f56e15205a3cec3039d8e804e8b53b293e38a0f069b52b655ff7386a174 298626 tokyocabinet-bin_1.4.37-2_amd64.deb Files: 679af602badcc23ee7b545a1496eae58 1268 libs extra tokyocabinet_1.4.37-2.dsc 2aba9b2f90eb8a793b4959eb5449d4e3 10857 libs extra tokyocabinet_1.4.37-2.diff.gz 228d91a0fa905a8c062ef3f852b80bfc 278720 libs extra libtokyocabinet8_1.4.37-2_amd64.deb a3ae48ed3c6a0182309b0f1a1488a55c 825566 debug extra libtokyocabinet-dbg_1.4.37-2_amd64.deb 0116ea72b02fa3dad4e3a7b2b1d12131 427164 libdevel extra libtokyocabinet-dev_1.4.37-2_amd64.deb 4ccaca7cd7fcde60dab4c07eba00353a 1043354 doc optional tokyocabinet-doc_1.4.37-2_all.deb a61fd57cf76bc8c08989e9bd1d20fb8a 298626 utils optional tokyocabinet-bin_1.4.37-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkr50/oACgkQvGr7W6Hudhw2IQCeN84TKSw3rHAj0okXR+dzaRXn UtMAnRIqweWdBpy3whRr3gJ6X07IHw7d =n5kn -END PGP SIGNATURE- Accepted: libtokyocabinet-dbg_1.4.37-2_amd64.deb to main/t/tokyocabinet/libtokyocabinet-dbg_1.4.37-2_amd64.deb libtokyocabinet-dev_1.4.37-2_amd64.deb to main/t/tokyocabinet/libtokyocabinet-dev_1.4.37-2_amd64.deb libtokyocabinet8_1.4.37-2_amd64.deb to main/t/tokyocabinet/libtokyocabinet8_1.4.37-2_amd64.deb tokyocabinet-bin_1.4.37-2_amd64.deb to main/t/tokyocabinet/tokyocabinet-bin_1.4.37-2_amd64.deb tokyocabinet-doc_1.4.37-2_all.deb to main/t/tokyocabinet/tokyocabinet-doc_1.4.37-2_all.deb tokyocabinet_1.4.37-2.diff.gz to main/t/tokyocabinet/tokyocabinet_1.4.37-2.diff.gz tokyocabinet_1.4.37-2.dsc to main/t/tokyocabinet/tokyocabinet_1.4.37-2.dsc -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted nsd3 3.2.3-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 09 Nov 2009 21:12:27 +0100 Source: nsd3 Binary: nsd3 Architecture: source amd64 Version: 3.2.3-4 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: nsd3 - authoritative domain name server (3.x series) Changes: nsd3 (3.2.3-4) unstable; urgency=low . * add debian/gbp.conf to be able to use git-dch. * Rename README.packaging, and s/tokyocabinet/nsd3/ in it * postinst: do not remove user-provided statoverrides. Checksums-Sha1: 76aad35b4f3cb861fa549020717768fc166939a0 1114 nsd3_3.2.3-4.dsc f94ee73ad53bd9599820f30b5f18e3ac9b5203e7 8363 nsd3_3.2.3-4.diff.gz caba96110a41ada6ca899e2057ee6b9366ba9443 907254 nsd3_3.2.3-4_amd64.deb Checksums-Sha256: 5952c97bb0df678f6179906ad985543352828f313ae5adbb6fe41f0034691710 1114 nsd3_3.2.3-4.dsc 94987c038335973371348f551e8728fe8b203cb3476d251b5fdd170467a47e3e 8363 nsd3_3.2.3-4.diff.gz 08ea62db4d1a2eb4e3c41411fbeaafb496cc9559d8410fb0a7dcddb815308338 907254 nsd3_3.2.3-4_amd64.deb Files: a70117bc4a52e589bd434dcd392da66b 1114 net extra nsd3_3.2.3-4.dsc 40d721d0e3b46097526c483b4f1eed66 8363 net extra nsd3_3.2.3-4.diff.gz e69e4a11c4e7f503dfe9a2dee567eaeb 907254 net extra nsd3_3.2.3-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkr4eC4ACgkQvGr7W6HudhzZWACfQz+7zUCyWGL29amDQfLp0l6U a94AnjLDWnhJFIOCycYRLt7qfZTmdsCU =vcoh -END PGP SIGNATURE- Accepted: nsd3_3.2.3-4.diff.gz to main/n/nsd3/nsd3_3.2.3-4.diff.gz nsd3_3.2.3-4.dsc to main/n/nsd3/nsd3_3.2.3-4.dsc nsd3_3.2.3-4_amd64.deb to main/n/nsd3/nsd3_3.2.3-4_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#554893: startup script should be more careful with chown -R
On Sun, Nov 08, 2009 at 06:11:20PM +0300, Michael Tokarev wrote: reopen 554893 thanks [Cc'ing debian-devel because it's wrong to call valid claims bogus and closing security bugs without any changes, especially since the issue at hand in the package actually is bogus from the beginning] For all I care you cannot exploit this bug, unless you can make the nsd user write symlink to files there. If this is asking for trouble, and my next upload is going to fix that, it's not really worth the fuss about cc-ing d...@... -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Accepted tokyocabinet 1.4.37-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 08 Nov 2009 16:12:00 +0100 Source: tokyocabinet Binary: libtokyocabinet8 libtokyocabinet-dbg libtokyocabinet-dev tokyocabinet-doc tokyocabinet-bin Architecture: source amd64 all Version: 1.4.37-1 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: libtokyocabinet-dbg - Tokyo Cabinet Database Libraries [runtime] libtokyocabinet-dev - Tokyo Cabinet Database Libraries [development] libtokyocabinet8 - Tokyo Cabinet Database Libraries [runtime] tokyocabinet-bin - Tokyo Cabinet Database Utilities tokyocabinet-doc - Tokyo Cabinet Database Documentation Closes: 508835 530966 Changes: tokyocabinet (1.4.37-1) unstable; urgency=low . * New upstream release (Closes: #508835, #530966). * Add debian/watch file thanks to Chris Lamb. * Add patches/0003-Readd-alias-symbols-for-tcmpoolput-APIS.patch to avoid ABI bump. * Move tokyocabinet packaging to collab-maint. Checksums-Sha1: 5b09abc702cfb59f60bec0a665d42958938d4aa2 1265 tokyocabinet_1.4.37-1.dsc 7c3d47332b83d3063c850b5cec6160f2d0f89450 988695 tokyocabinet_1.4.37.orig.tar.gz 844d62b5881bf675fafb052e6b73523ed37b18ea 9928 tokyocabinet_1.4.37-1.diff.gz 28f5069161161162254cb373bcb32dac8ecfb98c 278688 libtokyocabinet8_1.4.37-1_amd64.deb 3da1518bc8e0bc3bac4ed3978b3819dce1f8b13b 825648 libtokyocabinet-dbg_1.4.37-1_amd64.deb 90ad9d70747287b4aef72b24866eae8261b45b41 427136 libtokyocabinet-dev_1.4.37-1_amd64.deb 5b05203b077f302c76fd37d55535003acb9e3861 1043246 tokyocabinet-doc_1.4.37-1_all.deb ac32316954cf37dadfce471af90f3d15f194d6d3 298558 tokyocabinet-bin_1.4.37-1_amd64.deb Checksums-Sha256: 48be00cfbef1be15406936e9e8a0904b7e71e02d6a934cc975c27df0f9593d17 1265 tokyocabinet_1.4.37-1.dsc 49e28ac3891a60f8f98d4178966ff7c8e882715793a0a76c582f6a38d0972ac8 988695 tokyocabinet_1.4.37.orig.tar.gz 6e145b657f8dc0521ba573e79639db3dcdde2ca4c6086031a61bd4271ab82d06 9928 tokyocabinet_1.4.37-1.diff.gz e763e3b5a904f34ae50a9064e37f2bd632f9173c983d03ff954d1aee98f6258c 278688 libtokyocabinet8_1.4.37-1_amd64.deb e17c6fd4257763c578099ba5d88052b8c1b77507c3b3c2d5c60bf861cb2fefc1 825648 libtokyocabinet-dbg_1.4.37-1_amd64.deb f43b442baf20d0a20ab445b13c61a5d54130a495bb012eff9b472f6cb5433ee5 427136 libtokyocabinet-dev_1.4.37-1_amd64.deb 33283b8b4cc93ec9b6b100184e19b82ec0278e74776595501f0fff7536b3c536 1043246 tokyocabinet-doc_1.4.37-1_all.deb 1c2b317a60790a02f3a2b0d21b779db2e40b157b9abd07badf7505c0b540b492 298558 tokyocabinet-bin_1.4.37-1_amd64.deb Files: d6d98dbb0554d3fe70acd3f2b3667b81 1265 libs extra tokyocabinet_1.4.37-1.dsc 51741ff17c2aefeb35779db2156fb55f 988695 libs extra tokyocabinet_1.4.37.orig.tar.gz 786480acbc040be9b17fa78866bd8769 9928 libs extra tokyocabinet_1.4.37-1.diff.gz b43ec8765889d5b704ab1cb1e650ad2d 278688 libs extra libtokyocabinet8_1.4.37-1_amd64.deb 91629fe137d137ab8d3bd20842c178c2 825648 libs extra libtokyocabinet-dbg_1.4.37-1_amd64.deb dbe89c17f11f14f035f801abde242257 427136 libdevel extra libtokyocabinet-dev_1.4.37-1_amd64.deb 1071ecbb1c7dbdc77b7a719a2d0aca4a 1043246 doc optional tokyocabinet-doc_1.4.37-1_all.deb 9da4625934b0d9576efe6f3aff9fa595 298558 utils optional tokyocabinet-bin_1.4.37-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkr24L4ACgkQvGr7W6HudhwIPwCgo+wj2kGToFO4G80VYVAi7PCA W9kAnRW7+OKBKGcFDLmu4Hzv4FuEOfMs =cYsv -END PGP SIGNATURE- Accepted: libtokyocabinet-dbg_1.4.37-1_amd64.deb to main/t/tokyocabinet/libtokyocabinet-dbg_1.4.37-1_amd64.deb libtokyocabinet-dev_1.4.37-1_amd64.deb to main/t/tokyocabinet/libtokyocabinet-dev_1.4.37-1_amd64.deb libtokyocabinet8_1.4.37-1_amd64.deb to main/t/tokyocabinet/libtokyocabinet8_1.4.37-1_amd64.deb tokyocabinet-bin_1.4.37-1_amd64.deb to main/t/tokyocabinet/tokyocabinet-bin_1.4.37-1_amd64.deb tokyocabinet-doc_1.4.37-1_all.deb to main/t/tokyocabinet/tokyocabinet-doc_1.4.37-1_all.deb tokyocabinet_1.4.37-1.diff.gz to main/t/tokyocabinet/tokyocabinet_1.4.37-1.diff.gz tokyocabinet_1.4.37-1.dsc to main/t/tokyocabinet/tokyocabinet_1.4.37-1.dsc tokyocabinet_1.4.37.orig.tar.gz to main/t/tokyocabinet/tokyocabinet_1.4.37.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted proxsmtp 1.8-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 08 Nov 2009 16:41:39 +0100 Source: proxsmtp Binary: proxsmtp Architecture: source amd64 Version: 1.8-1 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: proxsmtp - multi purpose SMTP Proxy Changes: proxsmtp (1.8-1) unstable; urgency=low . * New upstream release (Upstream repacked with the .svn cruft removed). * Migrate away from cdbs to dh7. * Create /var/run/proxsmtp from the init script rather than the .deb. Checksums-Sha1: 4b8897f90185714c342ef80bbf4f3eca4d39cbb9 1074 proxsmtp_1.8-1.dsc ca4b83056a9a4882eac42aea932882114d211e66 158547 proxsmtp_1.8.orig.tar.gz 87835629b850ba2215c3413ff079b8b321d4cdcc 3265 proxsmtp_1.8-1.diff.gz 96b4ca7b77db5c04b9fb9a89c219a7d1d0717cc9 34788 proxsmtp_1.8-1_amd64.deb Checksums-Sha256: 245108dc588fdc14d17c193831171a0feacb7e0dfdcf409360633aa6662ed852 1074 proxsmtp_1.8-1.dsc c8113ffc4559af778a777ee2c7f3b1bb9d7fde99b26530c7d59da8382912fee3 158547 proxsmtp_1.8.orig.tar.gz beda1a84204ad4770a4f7190c0943df3d6cb434d80700d4a558fcad0e6bde3e2 3265 proxsmtp_1.8-1.diff.gz 78dc257334ff864212326579c0b4ff91359e0cfbc71226806b737e377dbdc00f 34788 proxsmtp_1.8-1_amd64.deb Files: 5744fb0eb0d0358fc493813a921fb59c 1074 mail optional proxsmtp_1.8-1.dsc 5e4c93358098750f490e72ae9229f966 158547 mail optional proxsmtp_1.8.orig.tar.gz acb7e4e9e266bf1bd658a11d96bd9aa7 3265 mail optional proxsmtp_1.8-1.diff.gz 0246b841316d0cf0c77bd432be29fa11 34788 mail optional proxsmtp_1.8-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkr26WwACgkQvGr7W6HudhwbkgCeL+N7NU6Y25QkdfavjVp81IlT fWYAni/3DtfPXdjWuFmapGDtUbXbr/1Y =ITll -END PGP SIGNATURE- Accepted: proxsmtp_1.8-1.diff.gz to main/p/proxsmtp/proxsmtp_1.8-1.diff.gz proxsmtp_1.8-1.dsc to main/p/proxsmtp/proxsmtp_1.8-1.dsc proxsmtp_1.8-1_amd64.deb to main/p/proxsmtp/proxsmtp_1.8-1_amd64.deb proxsmtp_1.8.orig.tar.gz to main/p/proxsmtp/proxsmtp_1.8.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted nsd3 3.2.3-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 08 Nov 2009 18:03:20 +0100 Source: nsd3 Binary: nsd3 Architecture: source amd64 Version: 3.2.3-2 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: nsd3 - authoritative domain name server (3.x series) Closes: 554893 Changes: nsd3 (3.2.3-2) unstable; urgency=low . * Rework how directories are chowned nsd:root: - use dpkg-statoverride for /usr/lib/nsd3 and /etc/nsd3. - use chown (no -R) for /var/run/nsd3 (Closes: #554893). * Do not rebuild db from postinst, init.d will do it. * Move packaging to collab-maint. * Move standards version to 3.8.3. Checksums-Sha1: 874a33067066dbd9be25036aca80735d2478d01d 1114 nsd3_3.2.3-2.dsc b453ef4e8ceb427f46a3a58bdfa617a4ae603cdc 8161 nsd3_3.2.3-2.diff.gz 939690b7ea3c7df63e23ed7d01d27ed3e1e23dfe 907076 nsd3_3.2.3-2_amd64.deb Checksums-Sha256: 376b21910639c650dea3b91d875aeef8c7b8c8a485d8f00680f1121259604846 1114 nsd3_3.2.3-2.dsc ff67303abb25e9a6481d39f40844f22af5a25a35b5c5269f38a2464f146778e1 8161 nsd3_3.2.3-2.diff.gz 5287b294d74ca44342adf8945454bfa08a19bc9fc56cbb262d7713dd7c5b7274 907076 nsd3_3.2.3-2_amd64.deb Files: eb90f9c1535a20d8c1c919d32bdaeccb 1114 net extra nsd3_3.2.3-2.dsc fcbe85b53f9e525c91af034a47e4d2a4 8161 net extra nsd3_3.2.3-2.diff.gz ae7690bc25ba14e93f5deef17dbb8407 907076 net extra nsd3_3.2.3-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkr2/L0ACgkQvGr7W6HudhxWiQCgp7uqcbRw+bpRAXqdlMMoucZe 00YAniWoqyEnuR2fXkw3YgGc7xqdbRaY =qMkv -END PGP SIGNATURE- Accepted: nsd3_3.2.3-2.diff.gz to main/n/nsd3/nsd3_3.2.3-2.diff.gz nsd3_3.2.3-2.dsc to main/n/nsd3/nsd3_3.2.3-2.dsc nsd3_3.2.3-2_amd64.deb to main/n/nsd3/nsd3_3.2.3-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted nsd3 3.2.3-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 08 Nov 2009 19:27:49 +0100 Source: nsd3 Binary: nsd3 Architecture: source amd64 Version: 3.2.3-3 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: nsd3 - authoritative domain name server (3.x series) Changes: nsd3 (3.2.3-3) unstable; urgency=low . * Simplify init script wrt nsdc calls. * Ignore chrooted, as it seems that db paths must be absolute relative to the host environment and not the chroot, IOW the db rebuilds from init work. * Fix permission issue wrt nsd.conf that should be nsd:nsd 640. Checksums-Sha1: b2874ed9c7135a1d5b29adf78665b730f3d1a541 1114 nsd3_3.2.3-3.dsc 55a8048ef4a95c198120812008cfb2c5a511 8248 nsd3_3.2.3-3.diff.gz c08dfebbeacaafda77e21aa88203019bc8879c8b 907164 nsd3_3.2.3-3_amd64.deb Checksums-Sha256: 1a32f87265a5b9c3390325398c9e2dd73272af37f3cd756f1853a97b53ccbea4 1114 nsd3_3.2.3-3.dsc 9a77955e49e781f38873f8ab5e2d00c5ec582ff89e243aa2f82af8e7498b30df 8248 nsd3_3.2.3-3.diff.gz 02f9364af1d658b6b08b9fe7887eca78f53b89f0dd23d91cf25589df07f1bbe8 907164 nsd3_3.2.3-3_amd64.deb Files: 81fb70ec5ea3b8fc14c2c2272f43129c 1114 net extra nsd3_3.2.3-3.dsc 5227bcc44a16aa4b7749f4a74ce4b377 8248 net extra nsd3_3.2.3-3.diff.gz a7d00b676704a7a083e79b187dfc3a41 907164 net extra nsd3_3.2.3-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkr3De0ACgkQvGr7W6HudhxguACdHRu1latZL1ph9EACtMzP8GkU MLoAn20tBLgXS6R1I8L0EkYKE4DLfjmk =jakz -END PGP SIGNATURE- Accepted: nsd3_3.2.3-3.diff.gz to main/n/nsd3/nsd3_3.2.3-3.diff.gz nsd3_3.2.3-3.dsc to main/n/nsd3/nsd3_3.2.3-3.dsc nsd3_3.2.3-3_amd64.deb to main/n/nsd3/nsd3_3.2.3-3_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted vimperator 2.1-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 11 Oct 2009 22:42:50 +0200 Source: vimperator Binary: iceweasel-vimperator Architecture: source all Version: 2.1-2 Distribution: unstable Urgency: high Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: iceweasel-vimperator - Iceweasel extension to make it have vim look and feel. Closes: 540672 Changes: vimperator (2.1-2) unstable; urgency=high . * Do not conflict against future firefox releases (Closes: #540672), Bump urgency to not slow anything for this sole tiny change. Checksums-Sha1: 2e631ac1428c73bd099c4d3e1f3acbc1321805a9 906 vimperator_2.1-2.dsc 861972062abebb9b6be4e7de79e66c22d15470d0 296661 vimperator_2.1-2.tar.gz 13d5cf242991b7fae0e0d83a01013cb5f59e60a7 302476 iceweasel-vimperator_2.1-2_all.deb Checksums-Sha256: e0742ff6270147f8ff442af0f23d49e6047a5aefd39f7c4367d5b99f178903d6 906 vimperator_2.1-2.dsc f0032441c9e3a57f319aa6c9ad364d0f48f5903d04f994c52ef4c48e71a18fb0 296661 vimperator_2.1-2.tar.gz 64386f436b529474a3fa89adf979c3351eeb19a8a6459a80bcd1d07c6970fc89 302476 iceweasel-vimperator_2.1-2_all.deb Files: 2ca8c241540f7557b37c97229f1fe139 906 web optional vimperator_2.1-2.dsc 38a168a8b35d768a147d0b1b22815c43 296661 web optional vimperator_2.1-2.tar.gz 3a36497ce995e0ba95b202253c2a3624 302476 web optional iceweasel-vimperator_2.1-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrSQ2sACgkQvGr7W6HudhzAqwCfQouB3+iLgAmiLggrff3h0s2D qGUAoIjWeDK4ThP8pD7TYuELfqs+d8Ju =l8X+ -END PGP SIGNATURE- Accepted: iceweasel-vimperator_2.1-2_all.deb to pool/main/v/vimperator/iceweasel-vimperator_2.1-2_all.deb vimperator_2.1-2.dsc to pool/main/v/vimperator/vimperator_2.1-2.dsc vimperator_2.1-2.tar.gz to pool/main/v/vimperator/vimperator_2.1-2.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: libjpeg62-dev - libjpeg-dev transition
On Sat, Sep 19, 2009 at 03:00:54PM -0700, Steve Langasek wrote: On Sat, Sep 19, 2009 at 07:40:28PM +0200, Pierre Habouzit wrote: On Sat, Sep 19, 2009 at 07:20:40PM +0200, Pierre Habouzit wrote: On Sat, Sep 19, 2009 at 02:32:51PM +0200, Andreas Barth wrote: * Pierre Habouzit (madco...@madism.org) [090919 01:08]: I'll put blocks in my hint file to be sure that both those packages will migrate in testing together (I'm unsure if britney is clever enough to block them until all the binNMUs are done, I don't think it is). Then please ask for binNMUs of all the package that B-D on libjpeg-dev. Then we will let that migrate. The question is: Are libjpeg62 and libjepg7 co-useable? (This only works if symbol versioning is turned on.) Huh, libjpeg62 and libjpet7 have different so-name so they are co-installable. I don't get what you mean with co-useable and it certainly has nothing to do with symbol versioning. If you meant things built against libjpeg7 and loading plugins linked against the libjpeg62 then yes, I think we're good, because libjpeg7 uses symbol versioning. libjpeg62 doesn't though. Then they're not usable together under any circumstances where libjpeg7 will be loaded into memory first. Hmm, you're right. So we need an intermediate upload before the virtual package changes where libjpeg7 Breaks libjpeg62. Bill could you do that please ? Then we'll proceed with switching the -dev Provides, blocking libjpeg62 from tansitionning, and launching the binNMUs of anything that build-depends upon libjpeg-dev. Then we'll see what becomes uninstallable because of the breaks, and fix those packages first. Then let that migrate. Bill, could you also check if any of the packages that already Build-Depend on libjpeg-dev will FTBFS ? Those packages have to be fixed before we start the binNMU campaign, so that no _known_ issue impedes us. We'll already have our load of unexpected ones... TIA. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: Transitional (dummy) packages considered silly
On Sun, Sep 20, 2009 at 06:16:52PM +0200, Magnus Holmgren wrote: On lördagen den 19 september 2009, Pierre Habouzit wrote: There is one point in having the transitional package: it ensures that no package does try to take foo as a package name in $stable + 1 which would then in turn confuse apt. A transitional package doesn't strictly prevent a maintainer from uploading another source package with a binary package that takes the place of the transitional package, as long as the version of the new package is greater, which it has to be even if the old package only exists in stable, doesn't it? I think either britney or dak should choke on that at some point. That is the state of the art. Could you please elaborate where and why this field would help ? FWIW I would be interested to read about a field semantics that would solve the git issue properly. IOW in lenny we have git being the GNU file manager stuff, and git-core the VCS. If you find a scheme that would allow git-core to become git, and git to become gnuit in _one_ release cycle[1] then your proposal is worth it. Let me elaborate on my last paragraph. The idea is that if 'bar' Supersedes 'foo', then versions of 'foo' greater than that of 'bar' (or an explicitly declared version) are a different package and should not be considered for upgrading 'foo'. For example: Actually Supersedes should always be versionned I think, which is something I missed, and make the thing pretty interesting in fact ... Finally, I think your proposal doesn't work, because Supersedes cannot work if two distinct binary packages Supersedes the same binary. We can obviously ensure this doesn't happen in the _same_ Debian distribution. I don't see how we can feasibly ensure it across different releases in a sane way (and I know lots of people having deb lines for stable, testing and sid in their sources.list). If two packages supersede the same package 'foo', then both should be installed in place of 'foo' on upgrade, but only if they supersede the same version of it (I suppose that's how it will have to be done). So you can have e.g. (modulo syntactic details) foo 1.3.7-3, bar 1.3.7-4 (Supersedes: foo (1.3.7-4), a new foo 1:1.0.2-1, then later a foo-bar 1:1.2.0-3 that Supersedes foo (1:1.2.0-3), and it will be possible to deduce that foo 1.3.7-3 should be upgraded to bar 1.3.7-4 and not to foo-bar. Multiple different packages reusing the same name in subsequent releases seems pretty contrived to me, however. All in all, I think your proposal is just a shorthand to make your debian/control marginally smaller and having to write extensive (slow[2]) patches to dpkg, but also britney, dak and pretty much everything dealing with .debs, for absolutely no real gain wrt the current state of stuff. I will concede that Supersedes should not imply Replaces or Conflicts, but merely be a hint to APT. Then neither dpkg nor britney nor dak should need to be patched. Though a question remains: Should dak reject a package that tries to supersede a package of which a newer version already exists in the archive? I don't think so; the other 'foo' could be uploaded before the superseding 'bar'. ... especially reading that. I answered thinking you meant Supersedes to be an alias for something complicated, not a hint for apt. As a hint, it's probably a worthwhile goal, and I -see- ways to even make it work for name reuse in subsequent releases. Actually with versioning enabled, it's even quite simple. Looking at your example, with = in the versions instead of equality to make it more robust, lenny: git 4.3.20-10 git-core 1:1.5.6.5-3+lenny2 squeeze: gnuit 4.9.5-1 Supersedes: git (= 4.9.5-1~) git 1:1.6.4.3-2 Supersedes: git-core (= 1:1.6.4.3-2~) When a user upgrades, then /apt/ can grok that the proper upgrade path for 'git' coming from a version = smaller than 4.9.5-1 is using gnuit instead. It can then just do what was suggested in another mail in the thread and migrate autoinstalled flags from git to gnuit. At the same way, the sole thing you need to prevent apt to consider upgrading git (aka gnuit) into git (the VCS) is to make sure that the new git has a strictly greater version than the package it replaces, which can always be done using the dreaded epochs (it's ugly, but fancy things like reusing a package name for two different things is hard, and it's logical there is a price to pay). So while I dismissed your idea at first thinking you wanted to make it a dpkg thing, now that I understand that you rather want it to be an /apt/ one, it makes really more sense to me. The point remains though that: - apt - dselect - aptitude - cupt must support that. I don't think in the end that britney or dak needs to grok this header after all, as britney isn't about upgrade paths of a given package, but rather trying to build
Re: libjpeg62-dev - libjpeg-dev transition
On Sat, Sep 19, 2009 at 11:47:35AM +0200, Bill Allombert wrote: On Sat, Sep 19, 2009 at 01:08:12AM +0200, Pierre Habouzit wrote: On Sat, Sep 19, 2009 at 12:04:32AM +0200, Bill Allombert wrote: Dear developers, There is a new version of libjpeg in the archive (JPEG7), but is it not yet cleared for building packages against it. If your package Build-Depends on libjpeg62-dev, please change to 'libjpeg-dev' (without the 62) to ease the transition. Err no, please don't. The fact that some packages Build-Depends on libjpeg62-dev is merely an historical artefact. I know, the fact that it's the case though, allow us to plan for a smoother transition. That'd be silly to not leverage that fact. First I'd like to see packages already build-depending on libjpeg-dev to be rebuilt against a libjpeg7 that provides libjpeg-dev. Actually, I have already done a test-rebuild of all the packages that build-depends on libjpeg62-dev or libjpeg-dev against a modified libjpeg7-dev that provide both libjpeg62-dev and libjpeg-dev, and there is only six FTBFS five of them being just test-suite update, and I send a patch for the sixth (netpbm) in the BTS. That' be great (if not already done) to open important bugs on those packages please, so that we can track that down. I just opened a meta-bug to track the libjpeg transition on release.debian.org, please mark those bugs as blocking the meta-bug, it'll help us track them TIA. I can provide you the logs if you want. I believe you, and only 6 ftbfs is relatively good news. The problem is, packages have to migrate together. The more packages that makes, the more probable it is the transition gets mixed up with another one. So I ask again, please let's do the -dev switch _first_ then bug packages wrongly depending upon libjpeg62-dev. The later can be done incrementally without, the first bit cannot. In the end we _do_ want all packages Build-Depending upon libjpeg-dev, that's clear. Though the smoother path is making them switch after the transition is done, not before. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: libjpeg62-dev - libjpeg-dev transition
On Sat, Sep 19, 2009 at 01:01:38PM +0200, Pierre Habouzit wrote: On Sat, Sep 19, 2009 at 11:47:35AM +0200, Bill Allombert wrote: On Sat, Sep 19, 2009 at 01:08:12AM +0200, Pierre Habouzit wrote: On Sat, Sep 19, 2009 at 12:04:32AM +0200, Bill Allombert wrote: Dear developers, There is a new version of libjpeg in the archive (JPEG7), but is it not yet cleared for building packages against it. If your package Build-Depends on libjpeg62-dev, please change to 'libjpeg-dev' (without the 62) to ease the transition. Err no, please don't. The fact that some packages Build-Depends on libjpeg62-dev is merely an historical artefact. I know, the fact that it's the case though, allow us to plan for a smoother transition. That'd be silly to not leverage that fact. First I'd like to see packages already build-depending on libjpeg-dev to be rebuilt against a libjpeg7 that provides libjpeg-dev. Actually, I have already done a test-rebuild of all the packages that build-depends on libjpeg62-dev or libjpeg-dev against a modified libjpeg7-dev that provide both libjpeg62-dev and libjpeg-dev, and there is only six FTBFS five of them being just test-suite update, and I send a patch for the sixth (netpbm) in the BTS. That' be great (if not already done) to open important bugs on those packages please, so that we can track that down. I just opened a meta-bug to track the libjpeg transition on release.debian.org, please mark those bugs as blocking the meta-bug, it'll help us track them That would be #547393 -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: libjpeg62-dev - libjpeg-dev transition
On Sat, Sep 19, 2009 at 02:32:51PM +0200, Andreas Barth wrote: * Pierre Habouzit (madco...@madism.org) [090919 01:08]: I'll put blocks in my hint file to be sure that both those packages will migrate in testing together (I'm unsure if britney is clever enough to block them until all the binNMUs are done, I don't think it is). Then please ask for binNMUs of all the package that B-D on libjpeg-dev. Then we will let that migrate. The question is: Are libjpeg62 and libjepg7 co-useable? (This only works if symbol versioning is turned on.) Huh, libjpeg62 and libjpet7 have different so-name so they are co-installable. I don't get what you mean with co-useable and it certainly has nothing to do with symbol versioning. If so, this is not a real transition, and we could all relax (packages will just one by one start using the new libary, and we can just rebuild packages slowly, and everthing is ok). That's exactly what I intend to do, that's why I don't want bill to make people change their build-dependencies _yet_. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: libjpeg62-dev - libjpeg-dev transition
On Sat, Sep 19, 2009 at 07:20:40PM +0200, Pierre Habouzit wrote: On Sat, Sep 19, 2009 at 02:32:51PM +0200, Andreas Barth wrote: * Pierre Habouzit (madco...@madism.org) [090919 01:08]: I'll put blocks in my hint file to be sure that both those packages will migrate in testing together (I'm unsure if britney is clever enough to block them until all the binNMUs are done, I don't think it is). Then please ask for binNMUs of all the package that B-D on libjpeg-dev. Then we will let that migrate. The question is: Are libjpeg62 and libjepg7 co-useable? (This only works if symbol versioning is turned on.) Huh, libjpeg62 and libjpet7 have different so-name so they are co-installable. I don't get what you mean with co-useable and it certainly has nothing to do with symbol versioning. If you meant things built against libjpeg7 and loading plugins linked against the libjpeg62 then yes, I think we're good, because libjpeg7 uses symbol versioning. libjpeg62 doesn't though. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: Transitional (dummy) packages considered silly
On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote:
When a binary package is renamed or split, as well as if several packages are
merged under a new name, transitional packages are normally created, which
depend on the new packages, which in turn Replaces and Conflicts with, and
possibly Provides, the old packages. I find those dummy packages as silly to
create as to uninstall after upgrading.
I propose a new control field called e.g. Supersedes that will provide the
same semantics. In its simplest form, a renamed package will declare that it
Supersedes the old package name. That will be considered equivalent to
conflicting with/replacing earlier versions of the superseded package, as
well
as providing a new version of it, just like a dummy package. Multiple
packages
can supersede the same package (but they should probably be the same
version),
and one package can of course supersede many others.
Well, I'm not sure what the practical gain is, could you please
elaborate on the suggested Supersedes: semantics ?
Note that transitional packages are seamless for users. When users has
foo in $stable, and foo gets renamed into bar in $stable +1, then there
is that:
$stable: package foo
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts foo}
$stable + 2: foo is dropped, replaces/provides/conflicts foo in bar can be
dropped.
After user has upgraded from $stable to $stable + 1, he doesn't have
'foo' anymore.
There is one point in having the transitional package: it ensures that
no package does try to take foo as a package name in $stable + 1 which
would then in turn confuse apt.
That is the state of the art. Could you please elaborate where and why
this field would help ?
FWIW I would be interested to read about a field semantics that would
solve the git issue properly.
IOW in lenny we have git being the GNU file manager stuff, and git-core
the VCS. If you find a scheme that would allow git-core to become git,
and git to become gnuit in _one_ release cycle[1] then your proposal is
worth it.
Finally, I think your proposal doesn't work, because Supersedes cannot
work if two distinct binary packages Supersedes the same binary. We
can obviously ensure this doesn't happen in the _same_ Debian
distribution. I don't see how we can feasibly ensure it across different
releases in a sane way (and I know lots of people having deb lines for
stable, testing and sid in their sources.list).
All in all, I think your proposal is just a shorthand to make your
debian/control marginally smaller and having to write extensive
(slow[2]) patches to dpkg, but also britney, dak and pretty much
everything dealing with .debs, for absolutely no real gain wrt the
current state of stuff.
[1] this is theorical discussion as such a proposal would need to be
implemented in dpkg, then pushed to user, then used, IOW only
squeeze+1 would be a target for Supersedes use anyway.
[2] yes slow, because for each package install, dpkg would have to
wonder if anything supersedes it, and deal with all the issues that
would arise if _two_ binary packages Supersedes the same thing.
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
signature.asc
Description: Digital signature
Re: libjpeg62-dev - libjpeg-dev transition
On Sat, Sep 19, 2009 at 12:04:32AM +0200, Bill Allombert wrote: Dear developers, There is a new version of libjpeg in the archive (JPEG7), but is it not yet cleared for building packages against it. If your package Build-Depends on libjpeg62-dev, please change to 'libjpeg-dev' (without the 62) to ease the transition. Err no, please don't. First I'd like to see packages already build-depending on libjpeg-dev to be rebuilt against a libjpeg7 that provides libjpeg-dev. In order to do that please provide a libjpeg6 not providing libjpeg-dev and a libjpeg7-dev which does provides it. I'll put blocks in my hint file to be sure that both those packages will migrate in testing together (I'm unsure if britney is clever enough to block them until all the binNMUs are done, I don't think it is). Then please ask for binNMUs of all the package that B-D on libjpeg-dev. Then we will let that migrate. _Only then_ you will open a mass bug on all packages that b-d on libjpeg62-dev to ask them to move to libjpeg-dev instead, so that the transition remains manageable. Doing it the other way ensures loads of pain to come. I'm not sure if we're ready for this transition yet though, I'll let luk or other RA/RM check if now is the best moment to do so. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: Explicitely Cc bug reporters
On Thu, Sep 10, 2009 at 04:21:50PM +0200, Bernhard R. Link wrote: * Sandro Tosi mo...@debian.org [090910 16:09]: Do others feel we should enable emailing the submitter by default? there are some reasons not to? But reporters are sacrifing some of their time to help us make our distribution better. Do you really think we should scare them away by rewarding bug reports by pulling the reporters in lengthy discussions how the bug is best fixed? When the maintainer think the bug reporter is not to be annoyed, then he should mail nnn-silent or whatever, because that is the exception. Not the reverse. This is a major (if not _THE_ major) annoyance with the BTS. FWIW this is a long discussed issue, and the BTS maintainers do not share this opinion (that mailing @ should also mail the submitter) so we're basically stuck. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Explicitely Cc bug reporters
On Thu, Sep 10, 2009 at 05:23:32PM +0200, Stefano Zacchiroli wrote: On Thu, Sep 10, 2009 at 05:08:00PM +0200, Pierre Habouzit wrote: When the maintainer think the bug reporter is not to be annoyed, then he should mail nnn-silent or whatever, because that is the exception. Full ACK. Not the reverse. This is a major (if not _THE_ major) annoyance with the BTS. FWIW this is a long discussed issue, and the BTS maintainers do not share this opinion (that mailing @ should also mail the submitter) so we're basically stuck. Conceptually, what we want is trivial: we want submitter to be subscribed (in the sense of bts subscribe) by default. If they want, they are free to opt unsubscribing. That should probably be something that would fly for me actually. and you could make reportbug take an option to add some kind of pseudo header so that subscribing is not done for the rare cases when sender doesn't want to be subscribed. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Explicitely Cc bug reporters
On Thu, Sep 10, 2009 at 04:58:30PM +0200, Samuel Thibault wrote: Leo costela Antunes, le Thu 10 Sep 2009 16:52:43 +0200, a écrit : Why not include a pseudo-header to subscribe to bugreports on submit? I thought about that too, but that doesn't solve the original problem: clueless reporters won't enable it and absent-minded maintainers will forget to Cc them. that's easy, it must be the reverse. Sane default, and simple way to override it. Sane default is: submitter should be subscribed. Easy way to override: pseudo-header to not be subscribed Easy way to override 2: let reportbug have a --do-not-subscribe-me-to-bugs--I-mean-it--I-really-want-to-be-a-PITA-for-the-maintainer for people that never remember about the pseudo-header. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Wed, Sep 09, 2009 at 08:50:34AM -0500, Manoj Srivastava wrote: Seems to me that we have a widely used convention (which might not be universal) that will meet our needs, and at least seems compatible with a lot of software under distributed version control. I think it well behooves us to re-use this, rather than go off an reinvent the wheel ourselves and be incompatible with _everything_ else out there. FWIW, for having discussed it with Raphael on #-qa, he seems pretty much convinced my proposal to make DEP3 compatible with git-format-patch is going in the good direction. He's annoyed I sent that mail so late (and FWIW sorry but I hadn't the time to do it before, and when I had time in august I hadn't connectivity.. but whatever) but I think the proposal will be amended so that we're compatible. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: Release goal: Getting rid of unneeded *.la / emptying dependency_libs
On Thu, Sep 10, 2009 at 12:35:12AM +0200, Kurt Roeckx wrote:
On Wed, Aug 26, 2009 at 03:46:36AM -0400, Felipe Sateler wrote:
Steve Langasek wrote:
On Wed, Aug 26, 2009 at 02:08:40AM -0400, Felipe Sateler wrote:
But this will cause trouble anyway. Imagine this case: glib changes
SONAME, both app and library depend on glib. app is recompiled, gtk isn't
yet.So then app NEEDED libglib-2.0.so.1, gtk NEEDED libglib-2.0.so.0.
Kaboom! The only real solution is to make gtk's SONAME dependent on
glib's, eg libgtk- x11-2.0.so.0-glib-1 (a la boost upstream with gcc
versions).
I think I should have added that the app does not have to link directly
with
glib.
That's what symbol versioning is for.
From /u/i/g/g/gtktextchild.h:
struct _GtkTextChildAnchor
{
GObject parent_instance;
gpointer GSEAL (segment);
};
You lost anyway. If GObject or gpointer changes, symbol versioning doesn't
save you because _GtkTextChildAnchor is a public type
This can all be solved using symbol versioning. Buf it will
probably require alot of work to get it right.
And it will probably require a _lot_ of code to be kept around for lots
of time. At best compatibility layers, and worst case, pure duplication
of all APIs.
symbol versioning is really nice, but it's not magic either ;)
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
signature.asc
Description: Digital signature
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Tue, Sep 08, 2009 at 03:23:50PM +0800, Paul Wise wrote: On Tue, Sep 8, 2009 at 7:53 AM, Pierre Habouzit madco...@madism.org wrote: On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote: Anyway, I'd rather wait some time until people have tried using this format before deciding if we must make some special case due to git format-patch. It's not a special case. Kernel people, git people, gnome people, X.org people, all can cherry-pick patches and format-patch them away. If you ask them to add one missing header like the actual source or commid-id they took the patch from, they'll probably do it (I would at least). If you ask to rewrite the full stuff, then really, go to hell will probably be the (sane) answer you'll get. What format do the other DVCS systems use for patch export? IIRC hg generates mails pretty much like git nowadays, and the `hg import` feature works mostly like git does: You can import a patch straight from a mail message. Even patches as attachments work (to use the body part, it must have type text/plain or text/x-patch). From and Subject headers of email message are used as default committer and commit message. All text/plain body parts before first diff are added to commit message. I'm not used to bzr at all, but I would be surprised it does sth _very_ different. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Patch Tagging Guidelines (aka DEP3)
On Mon, Sep 07, 2009 at 11:03:37PM +0200, Raphael Hertzog wrote: Hello, after several rounds of discussion on -devel, we now have a new standard defining meta-information to integrate on patches that we distribute/apply in our packages: http://dep.debian.net/deps/dep3/ Sorry I haven't answered to the DEP before, but I've been pretty busy so far. FWIW I don't like it completely because it's not compatible with the de-facto standard used by kernel-like project (that would count linux, or git, and many other). In git (and the idea is trivially used in any VCS that can format-patch to mail) you use either rfc822 headers or pseudo-headers for many fields you have re-defined. My point is that there are _lots_ of patches that follow the kernel conventions out there, and it should not require anything more than grabbing the patch, possibly add an URL in it pointing to where you grabbed it from, and be done with it. Your proposal requires an extensive rewrite of such patches, and it kind of sucks. Also I would like to be able to extract my patches from my git repository just doing a git format-patch upstream..upstream+patches e.g., and not having to touch them (hence the need for pseudo-headers). Here are my remarks wrt individual fields: * Description/Subject: Description should just be any bit of rfc822 text that isn't a header nor a patch nor a pseudo header. What you propose for Description is just a major hassle for any people using git/hg/... And you should have a short description, as Subject:. The description should not be mandatory, the Subject should be. Also, if the patch contains a line with exactly ---\n, then all that follows, up to the diff is data that is _not_ part of the Description, and should be dropped (it's where git puts its diffstat, and this format has also become a standard nowadays too). * From should be an allowed synonym for Author (git uses both, with a preference for From). * Reviewed-by is usually rather Acked-by. * Forwarded as a boolean (no/not-needed/...) field is IMHO useless, but whatever. Also, when the argument is an email address, Cc: is usually preferred. * Instead of Last-Update, simply Date: is usually preferred. Plus the proposed format is all but an iso standard. rfc822 dates are a better idea. Your proposal doesn't explicit what repetition of fields means. Debian usually uses: Foo: value1, value2, value3, ... But git people usually use: Foo: value1 Foo: value2 ... Both should be accepted and understood in the same way. Finally, I would suggest that Author or From should be mandatory for conforming patches, rather than Origin. And I would suggest a License: field for people wishing to license their patch with a specific license. FWIW, I don't believe any packager with an upstream using git will consider adopting DEP3 without those fixes. With those fixes though, it's just a tiny bit of effort for them, so you'll instead probably see quite a fast adopting rate for DEP3... -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote: On Sat, 05 Sep 2009, Guido Günther wrote: I tried to point that out in June: http://lists.debian.org/debian-devel/2009/06/msg00551.html but failed. It'd be really helpful if DEP-3 would be compatible with the git format-patch output. I missed that thread earlier and reacted to the dda mail in 20090907234314.ge13...@artemis.corp Would it be helpful to say that From: can be an alias for Author: and Subject: an alias for Description:? I made a full proposal for header fixes to be git/hg/... compatible. git format-patch alone will stil not be enough to generate a DEP3-compliant header but would that resolve your concerns? It will be compatible if you relax the use of headers to pseudo headers, and forget about your (sorry) ridiculous request for Description to be a rfc822 formatted field. Not only it's never used by anyone, but it's also a major PITA to edit. Like I said in my other mail, you want a Subject as a summary, and what you call Description is all that: - isn't a header - isn't a recognized pseudo-header - is before the patch or an optional ---\n line. It's a pretty simple definition, rather simple to implement in any kind of patch parsing tool. Indeed it's not compatible with grep-dctrl or whatever, but sadly for you, there _IS_ a standard for patches already, and it looks like that: - http://lkml.org/lkml/2009/8/31/369 - http://lkml.org/lkml/2009/8/31/40 - http://article.gmane.org/gmane.comp.version-control.git/126207 - http://article.gmane.org/gmane.comp.parsers.sparse/2001 - and I could go on with wine, x.org, gnome, ... patch submissions... damn even the glibc nowadays ! Anyway, I'd rather wait some time until people have tried using this format before deciding if we must make some special case due to git format-patch. It's not a special case. Kernel people, git people, gnome people, X.org people, all can cherry-pick patches and format-patch them away. If you ask them to add one missing header like the actual source or commid-id they took the patch from, they'll probably do it (I would at least). If you ask to rewrite the full stuff, then really, go to hell will probably be the (sane) answer you'll get. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: The future of the boot system in Debian
On Sun, Sep 06, 2009 at 12:04:33PM +0200, Marco d'Itri wrote: On Sep 06, Steve Langasek vor...@debian.org wrote: When should maintainers start adding upstart jobs to their packages? Not before the upstart compat package that provides upstart-job for sysvinit-based systems is available. Is this relevant for Linux-specific packages as well? I.e., do we want to continue supporting sysvinit on Linux systems? for one: LSB somehow requires it. second: I think it's disruptive for users to be unable to do /etc/init.d/$service stop/start/restart anymore. So I'd say that even for Linux we want some kind of sysvinit like scripts anyways. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Re: The future of the boot system in Debian
On Sun, Sep 06, 2009 at 01:45:35AM -0500, Manoj Srivastava wrote: Package: upstart Severity: wishlist Version: 0.6.3 Tags: patch On Sat, Sep 05 2009, Manoj Srivastava wrote: diff --git upstart-0.6.3.orig/debian/changelog upstart-0.6.3/debian/changelog index be2b21f..afaf59a 100644 --- upstart-0.6.3.orig/debian/changelog +++ upstart-0.6.3/debian/changelog @@ -1,3 +1,14 @@ +upstart (0.6.3-1.1) UNRELEASED; urgency=low + + * Add support for loading SELinux policy early in the boot +sequence. This changeset adds conditional support for loading SELinux +policy early in the boot sequence if a) it is enabled at compile time, +and b) the machine has SELinux enabled at run time. Also, since the +SELinux support patch is conditionally effective, this patch adds +support for enabling it on Linux architectures. + + -- Manoj Srivastava sriva...@debian.org Sat, 05 Sep 2009 12:15:46 -0500 Isn't it a duplicate of #543420 where the maintainer claims upstream doesn't want such a patch ? -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Re: The future of the boot system in Debian
On Sun, Sep 06, 2009 at 10:52:22AM -0700, Steve Langasek wrote:
On Sun, Sep 06, 2009 at 06:40:44PM +0200, Pierre Habouzit wrote:
On Sun, Sep 06, 2009 at 12:04:33PM +0200, Marco d'Itri wrote:
On Sep 06, Steve Langasek vor...@debian.org wrote:
When should maintainers start adding upstart jobs to their packages?
Not before the upstart compat package that provides upstart-job for
sysvinit-based systems is available.
Is this relevant for Linux-specific packages as well? I.e., do we want
to continue supporting sysvinit on Linux systems?
for one: LSB somehow requires it.
No. The LSB requires *LSB packages* to use init scripts. Debian
packages are not LSB packages.
Okay, my mistake.
second: I think it's disruptive for users to be unable to do
/etc/init.d/$service stop/start/restart anymore.
The transition plan here is to allow users to use the 'service' command
('service $service stop/start/restart') as an abstraction layer. If the
ports all migrate to upstart too, we'll eventually want to stop shipping
these symlinks.
I see. Let's hope our SHELLs will pick up completions soon enough then
;)
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
signature.asc
Description: Digital signature
Accepted nsd3 3.2.3-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 30 Aug 2009 00:21:05 +0200 Source: nsd3 Binary: nsd3 Architecture: source amd64 Version: 3.2.3-1 Distribution: unstable Urgency: low Maintainer: Pierre Habouzit madco...@debian.org Changed-By: Pierre Habouzit madco...@debian.org Description: nsd3 - authoritative domain name server (3.x series) Closes: 535878 539979 543580 Changes: nsd3 (3.2.3-1) unstable; urgency=low . * New upstream release. * Pass SHELL=/bin/bash to make so that nsdc.sh gets the proper shebang (Closes: #535878). * Disable largefile as it breaks architectures not allowing unaligned 8-bytes access, and it's likely to be a problem for nsd3 (Closes: #539979). * Make init.d read more values from the actual configuration using nsd-checkconf -o, and do less stuff if people are using chrooted stuff, because we probably aren't doing it right (Closes: #543580). Checksums-Sha1: 0b5b32b49bd0dbb43593a2656fa8c2cbb5f7a38e 1091 nsd3_3.2.3-1.dsc 2afcc6e1086eef7f5e538c7d837f628f83a19a86 855917 nsd3_3.2.3.orig.tar.gz b896606dabb954397bec81ac320f9cf2637c8347 7728 nsd3_3.2.3-1.diff.gz 7d2c0cb0da9bf99aed945f276dc645e94d3930cc 907024 nsd3_3.2.3-1_amd64.deb Checksums-Sha256: bcc9764dbe108caf47a11fbe16223857a68938b517fa59a1050a601a68dff888 1091 nsd3_3.2.3-1.dsc 2a9b4cb63b002a2a63ec8243f90a9e041f08b9498faa5b35ca71ce3334d842ff 855917 nsd3_3.2.3.orig.tar.gz 9ae76c89246923f911bf35ccfdade6e1c3286e6be466ec725e4d0fd4c6006e19 7728 nsd3_3.2.3-1.diff.gz a0233cb322913c72a9288f16312f6511846dde347dbc7a4208ea16460c1ffa75 907024 nsd3_3.2.3-1_amd64.deb Files: 566bca1ccd1901c0d1f56a64304d302e 1091 net extra nsd3_3.2.3-1.dsc 5ddb35dfb7da0defb82cda4f7388cba2 855917 net extra nsd3_3.2.3.orig.tar.gz fd507b21ad68b1961395123369bbca91 7728 net extra nsd3_3.2.3-1.diff.gz 26fd17ac2cd474994c21cbd28d380274 907024 net extra nsd3_3.2.3-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqZqhQACgkQvGr7W6HudhwPtgCgqZS6s/RqXMsA2skd1So5m/jw kxkAn2SldCdrtp4G/VZvvvKelky1MvZO =DH9L -END PGP SIGNATURE- Accepted: nsd3_3.2.3-1.diff.gz to pool/main/n/nsd3/nsd3_3.2.3-1.diff.gz nsd3_3.2.3-1.dsc to pool/main/n/nsd3/nsd3_3.2.3-1.dsc nsd3_3.2.3-1_amd64.deb to pool/main/n/nsd3/nsd3_3.2.3-1_amd64.deb nsd3_3.2.3.orig.tar.gz to pool/main/n/nsd3/nsd3_3.2.3.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.
On Sun, Aug 09, 2009 at 06:04:34PM +0200, Raphael Hertzog wrote: retitle 485330 Allow context diff in debian/patches/ in 3.0 (quilt) format thanks On Thu, 06 Aug 2009, Pierre Habouzit wrote: That said, yes, using non-unified diff is as laughable as using RCS or SCCS nowadays. Though I consider it a bug if dpkg refuses to apply a patch that patch(1) (that it uses in the end) would apply fine. I shall say that I absolutely don't get why there even is an analyze() routine in Patch.pm, analyze() extracts information from the patch in order to: - create directories that do not exist yet (patch will not do that for you AFAIK or at least that's the assumption that the current codebase made, it might have changed since this part of the code has been written) According to the man page, and to tests I did, it does - have a listing of all modified files in order to harmonize their timestamp afterwards (required to avoid unwanted rebuilding when patching auto-generated files and their source file) Can't you get that using lsdiff from patchutils ? Extracting those information require to parse the patch files, so why not error out when the parser finds something not allowed? With that we clearly agree ;) So while I have no opposition to allowing patches in context format (and not other non-contextual ones), the fix is most likely not the short one proposed by Charles. It's not. Instead the Dpkg::Source::Patch object should have full support of the context format at least in the analyze() part. Or you may use lsdiff. if you want that, let patch(1) do it using its --dry-run mode. It'll report failed hunk and bad syntax the same way. You'll be surprised how much permissive patch actually is. IIRC missing context in unidiff is not always fatal for example (even when the numbers on the @@ lines stipulate that there should be more lines than what there is). Sure, but there are some tools to verify how clean a patch is, but yeah, you're probably right on that. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.
On Fri, Aug 07, 2009 at 04:12:35PM +0200, Frank Küster wrote: Pierre Habouzit madco...@madism.org wrote: On Fri, Aug 07, 2009 at 10:45:14AM +0900, Charles Plessy wrote: Le Thu, Aug 06, 2009 at 09:26:02AM -0700, Russ Allbery a écrit : (filterdiff comes with patchutils.) Given that, this seems like a tempest in a teapot to me. Just convert the diff into whatever format the tool that you're using expects or the reviewer wants to read. Hi Russ and everybody, I already explained that I prefered that the patch stays in the original format Then you'll need to write your own patch system that calls patch(1) to apply the patches, à la cdbs-simple-patchsys. Why should he need to do that? If you'd had written submit patches to dpkg, I could get a meaning out of it, but here? He doesn't want to diverge from upstream. Oh boy, are you even reading... That's a workaround to wait for dpkg to be fixed. If you're willing to fix dpkg, please go ahead, but Charles first try is clearly _not_ a proper fix, hence for now no such patch exists. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.
On Fri, Aug 07, 2009 at 10:45:14AM +0900, Charles Plessy wrote: Le Thu, Aug 06, 2009 at 09:26:02AM -0700, Russ Allbery a écrit : (filterdiff comes with patchutils.) Given that, this seems like a tempest in a teapot to me. Just convert the diff into whatever format the tool that you're using expects or the reviewer wants to read. Hi Russ and everybody, I already explained that I prefered that the patch stays in the original format Then you'll need to write your own patch system that calls patch(1) to apply the patches, à la cdbs-simple-patchsys. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.
On Wed, Aug 05, 2009 at 10:07:02PM +0900, Charles Plessy wrote:
After deleting the following check, my source package builds fine.
--- a/scripts/Dpkg/Source/Patch.pm
+++ b/scripts/Dpkg/Source/Patch.pm
@@ -325,9 +325,6 @@ sub analyze {
unless (defined($_ = getline($diff_handle))) {
error(_g(diff `%s' finishes in middle of ---/+++ (line %d)),
$diff, $.);
}
- unless (s/^\+\+\+ //) {
- error(_g(line after --- isn't as expected in diff `%s' (line
%d)), $diff, $.);
- }
$_ = strip_ts($_);
if ($_ eq '/dev/null' or s{^(\./)?[^/]+/}{$destdir/}) {
$fn2 = $_;
Why not just applying the patches and catch errors if there are, instead of
writing a new patch parser from scratch just to check that it looks like being
in the unified format?
FWIW I've read this sub-thread with some kind of consternation,
especially seeing how wrong some arguments are.
First of all, non-unified diffs are called context diffs, and can have
... wait for it ... context. Those are actually valid ed scripts IIRC.
The reason why unified diffs are prefered is because those are usually
way more readable.
For example, vim upstream is using non unified diffs with context as a
way to release its incremental versions, still nowadays.
That said, yes, using non-unified diff is as laughable as using RCS or
SCCS nowadays. Though I consider it a bug if dpkg refuses to apply a
patch that patch(1) (that it uses in the end) would apply fine. I shall
say that I absolutely don't get why there even is an analyze() routine
in Patch.pm, if you want that, let patch(1) do it using its --dry-run
mode. It'll report failed hunk and bad syntax the same way.
I concur with Charles that it's a dpkg-dev bug, I don't think his patch
is valid though. I'm unsure if it needed all that trolling, and that a
minor bug on dpkg-dev asking for non-unified diffs support is in order.
In between there are as many already said many workarounds, the easier
one being to regenerate the diff, which you can easily do using
combinediff (I've not checked if there is anything more
straightforward):
$ cat aa
toto
tuti
titi
$ cat ab
toto
tutu
titi
$ diff -C2 aa ab | tee aa-to-ab.diff
*** aa 2009-08-06 18:25:44.875327948 +0200
--- ab 2009-08-06 18:25:50.107327652 +0200
***
*** 1,3
toto
! tuti
titi
--- 1,3
toto
! tutu
titi
$ combinediff aa-to-ab.diff /dev/null
unchanged:
--- aa 2009-08-06 18:25:44.875327948 +0200
+++ ab 2009-08-06 18:25:50.107327652 +0200
@@ -1,3 +1,3 @@
toto
-tuti
+tutu
titi
Cheers,
--
Intersec http://www.intersec.com
Pierre Habouzit pierre.habou...@intersec.com
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.
On Thu, Aug 06, 2009 at 06:33:28PM +0200, Pierre Habouzit wrote: Those are actually valid ed scripts IIRC. Okay, sorry, I meant to remove that sentence that is actually wrong... sorry 'bout that. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Nettoyer un répertoir e plein de .deb ?
On Mon, Aug 03, 2009 at 09:56:00PM +0200, Pierre Habouzit wrote:
On Mon, Aug 03, 2009 at 04:02:43PM +0200, Éric Seigne wrote:
Bonjour,
es-ce qu'il existe une commande rapide et efficace pour faire le
ménage dans un dossier plein de paquets .deb pour ne garder que ceux
dont les numéros de versions sont les plus récents ?
Par exemple j'ai
package_1.2.0-0_i386.deb
package_1.2.0-1_i386.deb
package_1.3.1-0_i386.deb
package_1.3.4-6_i386.deb
package_1.3.4-7_i386.deb
et je ne veux garder que le dernier ... y a ça, sans se lancer dans
des outils de gestion de dépots ?
Merci d'avance,
Éric
Sauf que ça ne marche pas... parce que je pars du principe que le
file-name contient l'époch ce qui est généralement faux...
Le fix suivant devrait corriger ça:
#!/bin/sh
dry_run=
doit() {
$dry_run $@
}
while test $# != 0; do
case $1 in
-n) dry_run=echo ;;
--) shift; break; ;;
*) break ;;
esac
shift
done
if test $# != 1; then
echo usage: foo.sh directory 21
exit 1
fi
cd $1
for p in $(ls *.deb|sed -e 's/_.*//'|sort -u); do
keep=
+keep_v=
for v in $(ls ${p}_*.deb | sed -e
's/^[^_]*_\([^_]*\)_[^_]*\.deb$/\1/'); do
+ver=$(dpkg --info binutils-dev_2.19.51.20090704-1_amd64.deb|sed -ne
'/Version: /{s/ *Version: *//p;q}')
if test -z $keep; then
keep=$v
+keep_v=$ver
-elif dpkg --compare-versions $keep gt $v; then
+elif dpkg --compare-versions $keep_v gt $ver; then
doit rm -f ${p}_${v}_*.deb
else
doit rm -f ${p}_${keep}_*.deb
keep=$v
+keep_v=$ver
fi
done
done
Et sinon la bonne manière est d'utiliser dpkg --info et de prendre le
Package: et Version:, de trier pour chaque Package: unique par ordre de
Version: selon dpkg --compare-versions, et de ne conserver que le
dernier de chaque. Je pense que dpkg --compare-versions est accessible
depuis perl-apt (si ça existe) et je suis sur que c'est accessible
depuis python-apt pour l'utiliser dans apt-listchanges. Mais j'ai la
flemme d'écrire le script en question.
--
Intersec http://www.intersec.com
Pierre Habouzit pierre.habou...@intersec.com
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie
signature.asc
Description: Digital signature
Re: Linking libxxx.so to libxxx_r.so? dpkg-shlibdep doesn't like it...
On Sun, Jul 05, 2009 at 11:01:21PM +0200, Christian Hammers wrote: Hello To help packages like Apache which have some parts like libaprutil that wants to link against libmysqlclient16_r.so and some like PHP that wants to link against libmysqlcient.so, it was proposed that libmysqlclient.so should be made a symlink pointing to the thread safe *_r.so version. (This change would be introduced for the upcoming new soname version which is not yet into unstable! Performance issues were considered to be negligible as the client library only copies data from and to the server) But when putting a corresponding symlink into debian/libmysqlclient16.links, the build process fails with: dh_shlibdeps -a -l debian/libmysqlclient16/usr/lib -L libmysqlclient16 LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot:/debian/libmysqlclient16/usr/lib dpkg-shlibdeps -Tdebian/libmysqlclient16.substvars -Sdebian/libmysqlclient16 debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0 dpkg-shlibdeps: warning: dependency on libnsl.so.1 could be avoided if debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0 were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libcrypt.so.1 could be avoided if debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0 were not uselessly linked against it (they use none of its symbols). LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot:/debian/libmysqlclient16/usr/lib dpkg-shlibdeps -Tdebian/mysql-client-5.1.substvars -Sdebian/libmysqlclient16 debian/mysql-client-5.1/usr/sbin/mysqlmanager debian/mysql-client-5.1/usr/bin/mysqldump debian/mysql-client-5.1/usr/bin/mysql_client_test_embedded debian/mysql-client-5.1/usr/bin/mysql_waitpid debian/mysql-client-5.1/usr/bin/mysqladmin debian/mysql-client-5.1/usr/bin/mysqltest_embedded debian/mysql-client-5.1/usr/bin/mysql debian/mysql-client-5.1/usr/bin/mysqlshow debian/mysql-client-5.1/usr/bin/mysqlcheck debian/mysql-client-5.1/usr/bin/myisam_ftdump debian/mysql-client-5.1/usr/bin/mysqlimport debian/mysql-client-5.1/usr/bin/mysql_client_test dpkg-shlibdeps: warning: debian/libmysqlclient16/usr/lib/libmysqlclient.so.16 has an unexpected SONAME (libmysqlclient_r.so.16) dpkg-shlibdeps: error: no dependency information found for debian/libmysqlclient16/usr/lib/libmysqlclient.so.16 (used by debian/mysql-client-5.1/usr/bin/mysqldump). dh_shlibdeps: dpkg-shlibdeps returned exit code 2 make: *** [binary-arch] Error 1 Before I start looking for a creative workaround - is this approach a good idea in the first place? You cannot do that: diff -U0 =(nm -D /usr/lib/libmysqlclient.so.15.0.0 | cut -d' ' -f2- | sort -u) =(nm -D /usr/lib/libmysqlclient_r.so.15.0.0 | cut -d' ' -f2- | sort -u)|grep '^-' --- /tmp/zshUjt2JU 2009-07-08 15:49:03.888491590 +0200 -B my_errno Unless this big fat command yields nothing with the .16 version, libmysql_r.so has *not* an ABI that includes the one of libmysqlclient.so. IOW programs that would be built against libmysqlclient.so on other distros will not work on Debian at all if you do that. As of the dpkg-shlibdeps warning you can probably work it around with proper -x arguments (ugly). -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Linking libxxx.so to libxxx_r.so? dpkg-shlibdep doesn't like it...
On Wed, Jul 08, 2009 at 03:53:58PM +0200, Pierre Habouzit wrote: On Sun, Jul 05, 2009 at 11:01:21PM +0200, Christian Hammers wrote: Hello To help packages like Apache which have some parts like libaprutil that wants to link against libmysqlclient16_r.so and some like PHP that wants to link against libmysqlcient.so, it was proposed that libmysqlclient.so should be made a symlink pointing to the thread safe *_r.so version. (This change would be introduced for the upcoming new soname version which is not yet into unstable! Performance issues were considered to be negligible as the client library only copies data from and to the server) But when putting a corresponding symlink into debian/libmysqlclient16.links, the build process fails with: dh_shlibdeps -a -l debian/libmysqlclient16/usr/lib -L libmysqlclient16 LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot:/debian/libmysqlclient16/usr/lib dpkg-shlibdeps -Tdebian/libmysqlclient16.substvars -Sdebian/libmysqlclient16 debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0 dpkg-shlibdeps: warning: dependency on libnsl.so.1 could be avoided if debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0 were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libcrypt.so.1 could be avoided if debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0 were not uselessly linked against it (they use none of its symbols). LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot:/debian/libmysqlclient16/usr/lib dpkg-shlibdeps -Tdebian/mysql-client-5.1.substvars -Sdebian/libmysqlclient16 debian/mysql-client-5.1/usr/sbin/mysqlmanager debian/mysql-client-5.1/usr/bin/mysqldump debian/mysql-client-5.1/usr/bin/mysql_client_test_embedded debian/mysql-client-5.1/usr/bin/mysql_waitpid debian/mysql-client-5.1/usr/bin/mysqladmin debian/mysql-client-5.1/usr/bin/mysqltest_embedded debian/mysql-client-5.1/usr/bin/mysql debian/mysql-client-5.1/usr/bin/mysqlshow debian/mysql-client-5.1/usr/bin/mysqlcheck debian/mysql-client-5.1/usr/bin/myisam_ftdump debian/mysql-client-5.1/usr/bin/mysqlimport debian/mysql-client-5.1/usr/bin/mysql_client_test dpkg-shlibdeps: warning: debian/libmysqlclient16/usr/lib/libmysqlclient.so.16 has an unexpected SONAME (libmysqlclient_r.so.16) dpkg-shlibdeps: error: no dependency information found for debian/libmysqlclient16/usr/lib/libmysqlclient.so.16 (used by debian/mysql-client-5.1/usr/bin/mysqldump). dh_shlibdeps: dpkg-shlibdeps returned exit code 2 make: *** [binary-arch] Error 1 Before I start looking for a creative workaround - is this approach a good idea in the first place? You cannot do that: This is poorly worded, you can do what you want, but it means that you will break binary compatibility with other distributions. By bumping the soname, you ensure that nothing will break with this change, so Debian-wise it's probably fine. Note though that openssl for example hasn't the same soname on RedHat for example (where it's libssl.so.4 I think), so I'm not sure the whole cross-distribution binary compatibility stuff is that much of a concern. I'll let other people comment on it though. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
On Sat, Jul 04, 2009 at 11:30:12PM +0200, Goswin von Brederlow wrote: Yannick yannick.roeh...@free.fr writes: Goswin von Brederlow wrote: And hey, the good reason was diverting the package management tools is unacceptable. But, no, we have to do insults instead of arguing. Alas, despite the diversion of the package management tools, I find ia32- apt-get pretty useful. For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript engine). With ia32-apt-get, I could install the 32bit version of my GTK theme engine so that Firefox can look good. Is there a design problem in converting 32bits libraries to ia32-* packages or the sole problem is the diversion of apt-get and co? There where 3 minor bug reports about an ia32-* package not working right. Out of an estimate of 160-200 packages people use. I think that is pretty good. All 3 bugs where fix in a subsequent upload and currently there are no reported missconversions. On the other hand ~45 bugs about missconversion or missing packages in the old ia32-libs where closed (and will have to be reopened now). So I don't believe there is a design problem there. That part works just fine. But the diversions had people totaly in outrage. So much so that I believe they didn't even look past that at all. You absolutely don't get it do you ? Your conversion system is an ugly hack, something completely horrible, that is meant to break in horrible ways, has no forward upgrate path to a multiarch work, and so on. If you really mean to provide something like ia32-apt-get, what you ought to do is to: - help the user create and maintain a proper 32bits chroot; - let ia32-apt-get or whatever it's called be a forward to running apt-get inside that chroot; - find a way to let the user run commands from that chroot seamlessly. That would be totally acceptable, and probably an improvement over the current situation. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
