Accepted bitcoin 0.13.1-0.1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 28 Oct 2016 13:40:17 +1000 Source: bitcoin Binary: bitcoind bitcoin-qt bitcoin-tx libbitcoinconsensus0 libbitcoinconsensus-dev Architecture: source amd64 Version: 0.13.1-0.1 Distribution: unstable Urgency: medium Maintainer: Debian Bitcoin Packaging Team <pkg-bitcoin-de...@lists.alioth.debian.org> Changed-By: Anthony Towns <a...@erisian.com.au> Description: bitcoin-qt - peer-to-peer network based digital currency - GUI bitcoin-tx - peer-to-peer network based digital currency - transaction tool bitcoind - peer-to-peer network based digital currency - daemon libbitcoinconsensus-dev - bitcoin blockchain library development files libbitcoinconsensus0 - bitcoin blockchain library Closes: 841706 Changes: bitcoin (0.13.1-0.1) unstable; urgency=medium . * Non-maintainer upload. * New upstream release. * Patch for -latomic is included upstream, so drop Debian-specific patch. * Add semi-colons for hppa patch. (Closes: Bug#841706) Checksums-Sha1: 6d62c81e91a13f0957ad62e8961beb3abd881e47 2644 bitcoin_0.13.1-0.1.dsc c61dbb3a89d452e83e4ce454ee677c64dfda46b3 5952081 bitcoin_0.13.1.orig.tar.gz 14b4626ef22f431a2e1ddc18fd64c53afec3946b 36400 bitcoin_0.13.1-0.1.debian.tar.xz 3a2040b557fa67dd5c6e595766f93ca15dd1f86f 41668944 bitcoin-qt-dbgsym_0.13.1-0.1_amd64.deb 1e2e3870ba45a8e592981a1a3c25405be25e9e08 3108510 bitcoin-qt_0.13.1-0.1_amd64.deb de5a94038599703b92df616783311f714b6aa45a 4544926 bitcoin-tx-dbgsym_0.13.1-0.1_amd64.deb 97e6da707277b741a13a2abd243b8a45e02b3506 409546 bitcoin-tx_0.13.1-0.1_amd64.deb 5a519136ae88c763af233ff2361a89c3d74bffe8 29081084 bitcoind-dbgsym_0.13.1-0.1_amd64.deb e1d91ee3ee9d13da19c0b74a22b569aa1591895e 1489210 bitcoind_0.13.1-0.1_amd64.deb a807ad6cb613071d61078fd8ff633d690412752a 145638 libbitcoinconsensus-dev_0.13.1-0.1_amd64.deb 40d3e3159c7bbf2452ac5c35bf7a2c48dbf4250c 1031324 libbitcoinconsensus0-dbgsym_0.13.1-0.1_amd64.deb 41112782b454db9e5c16cb35f73530fe6bc20a0e 227810 libbitcoinconsensus0_0.13.1-0.1_amd64.deb Checksums-Sha256: ef29c5724b9b42dee3d25e49516f6522394965f2de4340a9187485f16a08127f 2644 bitcoin_0.13.1-0.1.dsc 97d4a1aea7aed957e76f8f5e6ba2a2bfc66c1fcbdaf76ee46bd0650e5957eaa9 5952081 bitcoin_0.13.1.orig.tar.gz e1c55196e6b6172ba40a7f7be8e3587d5155b2a493529a7070a35b08a4c45a5d 36400 bitcoin_0.13.1-0.1.debian.tar.xz ecd3be3d2c0bea654ffb4fd0ff129d0bf9fdc9f2a2e4313971cc08de60410693 41668944 bitcoin-qt-dbgsym_0.13.1-0.1_amd64.deb ef0c1cd32ef1846c1959423d0428e28c719a3f29b28906c136697b9278124ae0 3108510 bitcoin-qt_0.13.1-0.1_amd64.deb 7efb11fc2409b7ac7b40d00e42e051366c156bc65388ebf20b877b280edd0387 4544926 bitcoin-tx-dbgsym_0.13.1-0.1_amd64.deb 80b87121e880465fedcfb65470e5f7b10d75577efc543309016de27dae3b57e4 409546 bitcoin-tx_0.13.1-0.1_amd64.deb 1681a726b6213b2fbeebad37b5be8039b53f88f52e29851073c2454c4278bece 29081084 bitcoind-dbgsym_0.13.1-0.1_amd64.deb 4c089bb307efc40a1935c99011e045872dfd2197fa0ff286597484ee0ce1a230 1489210 bitcoind_0.13.1-0.1_amd64.deb b81c306ca7ddc6f006153219e27f3f307051171237713556c5f6d5536ddc6068 145638 libbitcoinconsensus-dev_0.13.1-0.1_amd64.deb 0eaf9aaff38d2524d30abc3caad3b47ba058e4ee9a30907938b8dc74f500c15e 1031324 libbitcoinconsensus0-dbgsym_0.13.1-0.1_amd64.deb 649c39da20d33376060ae1540eee94a4072eecc3055901c19e99252c9e6d61cf 227810 libbitcoinconsensus0_0.13.1-0.1_amd64.deb Files: 853bb7d9acb7953cdd8348bddf074c29 2644 utils optional bitcoin_0.13.1-0.1.dsc 3ccb66404e6da9b995a607de997ca3bf 5952081 utils optional bitcoin_0.13.1.orig.tar.gz 5e2eb44d9a52ce20ff8f031b8e25a230 36400 utils optional bitcoin_0.13.1-0.1.debian.tar.xz 33b4b357d6f88218de73b5ca41b4c596 41668944 debug extra bitcoin-qt-dbgsym_0.13.1-0.1_amd64.deb 849b33e1a89b3026ea4cedc2bba8368a 3108510 utils optional bitcoin-qt_0.13.1-0.1_amd64.deb 31ac38c96e58441bf4f1935d11340a53 4544926 debug extra bitcoin-tx-dbgsym_0.13.1-0.1_amd64.deb e3cf387d078bd33584b765e687e8b4f7 409546 utils optional bitcoin-tx_0.13.1-0.1_amd64.deb 23e7b31d87dcd0b402a99a8d9e1f20da 29081084 debug extra bitcoind-dbgsym_0.13.1-0.1_amd64.deb bc990053ce218f978d123159d11f05c6 1489210 utils optional bitcoind_0.13.1-0.1_amd64.deb d808c281bc7f7c1d868271b08f0cb952 145638 libdevel optional libbitcoinconsensus-dev_0.13.1-0.1_amd64.deb 5127293117ce244684f4ba415f1ac709 1031324 debug extra libbitcoinconsensus0-dbgsym_0.13.1-0.1_amd64.deb 3cf4686c30e2dbb2e1e8e9bf41a8d01b 227810 libs optional libbitcoinconsensus0_0.13.1-0.1_amd64.deb -BEGIN PGP SIGNATURE- iQIvBAEBCAAZBQJYEs/nEhxhakBlcmlzaWFuLmNvbS5hdQAKCRBhd7NVgqjYplB8 D/9Dx/FjX+LbqFreA7W1K6eJuRra2QBEKbS6FKWLZgtpVbmjpMzYiu+MaAUOI9AT sKslc7ByMeXusU4xzBF4PkOWsWU1zs6PH7dwUuCfg19mDFRPbV9HMZ4w94Tpmetm Im0QITh12OCaEqYXKlB4DD2RIXZUtXrSYnZSZwAzPwI+/KDhzZ69jXKODnnv/9P8 N4520Xblb8C8j3Reufm61C5EPWszod22IYUkF85UW1lyXf3CqHR9zWXpPeUto6kZ f3QJrZ8xNjXZCkpAlfaoAM3ELmddYsBnktG4zVRGRm2I+2oIx1GRezJwK5LjkPUs ajQt7SdPAjGfH59FK
Accepted bitcoin 0.13.1-0.1~exp1 (source amd64) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 27 Oct 2016 18:30:35 +1000 Source: bitcoin Binary: bitcoind bitcoin-qt bitcoin-tx libbitcoinconsensus0 libbitcoinconsensus-dev Architecture: source amd64 Version: 0.13.1-0.1~exp1 Distribution: experimental Urgency: medium Maintainer: Debian Bitcoin Packaging Team <pkg-bitcoin-de...@lists.alioth.debian.org> Changed-By: Anthony Towns <a...@erisian.com.au> Description: bitcoin-qt - peer-to-peer network based digital currency - GUI bitcoin-tx - peer-to-peer network based digital currency - transaction tool bitcoind - peer-to-peer network based digital currency - daemon libbitcoinconsensus-dev - bitcoin blockchain library development files libbitcoinconsensus0 - bitcoin blockchain library Closes: 841706 Changes: bitcoin (0.13.1-0.1~exp1) experimental; urgency=medium . * Non-maintainer upload. * New upstream release. * Patch for -latomic is included upstream, so drop Debian-specific patch. * Add semi-colons for hppa patch. (Closes: Bug#841706) Checksums-Sha1: baeaea8a8f1cad6661a76c82645ba32a6d8abf04 2664 bitcoin_0.13.1-0.1~exp1.dsc c61dbb3a89d452e83e4ce454ee677c64dfda46b3 5952081 bitcoin_0.13.1.orig.tar.gz 7269bb1077ef411e12e31cd3d4d0b89fd7a61bd3 36420 bitcoin_0.13.1-0.1~exp1.debian.tar.xz 005114adba249b32cc9ee79e767065b4007bb452 41668938 bitcoin-qt-dbgsym_0.13.1-0.1~exp1_amd64.deb 54bea9794c8f9c1eef331118a62818f3afef48f1 3108576 bitcoin-qt_0.13.1-0.1~exp1_amd64.deb 3e2a23b1e89ec8861f5472475aed08b0daa9b5b5 4544932 bitcoin-tx-dbgsym_0.13.1-0.1~exp1_amd64.deb 7814f0e4c6048bfb2856623303a31c675aa73cca 409470 bitcoin-tx_0.13.1-0.1~exp1_amd64.deb b5aeaa1b8ecb2ae9e15c240ed81a6eac7b2fb500 29081088 bitcoind-dbgsym_0.13.1-0.1~exp1_amd64.deb a2c7481b1f7718fe706aa3c60a3ad290078fd930 1489690 bitcoind_0.13.1-0.1~exp1_amd64.deb fe0ea12e1f47360f8cb6c25f0ea12f5bf1942067 145838 libbitcoinconsensus-dev_0.13.1-0.1~exp1_amd64.deb f73d0ae4892172d042c75f101d61af3e55fdf0d1 1031328 libbitcoinconsensus0-dbgsym_0.13.1-0.1~exp1_amd64.deb bfd8ba34b7d37ce323ecfc2ea3533363ba18d413 227752 libbitcoinconsensus0_0.13.1-0.1~exp1_amd64.deb Checksums-Sha256: 95bc0c047779ce5bad0f5ca83c140fe15e2cd864098ab544f97a7d593c7d69bf 2664 bitcoin_0.13.1-0.1~exp1.dsc 97d4a1aea7aed957e76f8f5e6ba2a2bfc66c1fcbdaf76ee46bd0650e5957eaa9 5952081 bitcoin_0.13.1.orig.tar.gz c8a909c695d2ce85ecb4a7f601b1ce4c38b3db8bb5d36bb4c2fdb28be311db98 36420 bitcoin_0.13.1-0.1~exp1.debian.tar.xz 900477d1c923f7969309fc227e974747bebd0b92f88369fc5eee523d18ea9d3c 41668938 bitcoin-qt-dbgsym_0.13.1-0.1~exp1_amd64.deb 78f505268bb52ef73d1b9f43dcbcd5eb1603349a4303857a9a71f5bacfff0b35 3108576 bitcoin-qt_0.13.1-0.1~exp1_amd64.deb 3f1d9f1fd01910568ced5353a8f8f3212a56dd688d504cc95a4ed721f72cba59 4544932 bitcoin-tx-dbgsym_0.13.1-0.1~exp1_amd64.deb c9723f1655b74e7b95c51dbf656c8470121d89cb3db30bde0b59f8c1592a159b 409470 bitcoin-tx_0.13.1-0.1~exp1_amd64.deb b29179f62c5d5b1b749f03a817b08c6ecb04cda9ab8bd211ff6ea201313dedc3 29081088 bitcoind-dbgsym_0.13.1-0.1~exp1_amd64.deb 7600b5714ed29b3adca47f140e9465c7cf0f89e4ce20447835ce177f327a620a 1489690 bitcoind_0.13.1-0.1~exp1_amd64.deb fad1ec817262c1feabb5acffd2dc7a99619f922ae426b84eedaed314e90f5428 145838 libbitcoinconsensus-dev_0.13.1-0.1~exp1_amd64.deb 7b8354a16d7d3ce986c63d9c9f4d1f03bc9d262c7d634308e28ee8e96a6fa603 1031328 libbitcoinconsensus0-dbgsym_0.13.1-0.1~exp1_amd64.deb 914c5d5c495bef901f41415120126088c3351dde64439b38a7dd51a9d09e1627 227752 libbitcoinconsensus0_0.13.1-0.1~exp1_amd64.deb Files: 88ea7c7b46fe27a37187e94daef1eadb 2664 utils optional bitcoin_0.13.1-0.1~exp1.dsc 3ccb66404e6da9b995a607de997ca3bf 5952081 utils optional bitcoin_0.13.1.orig.tar.gz 5ceee3cf1de48c600c838b9fd15a0d87 36420 utils optional bitcoin_0.13.1-0.1~exp1.debian.tar.xz b19d09554c54f418c53cb354c9a097cb 41668938 debug extra bitcoin-qt-dbgsym_0.13.1-0.1~exp1_amd64.deb 1dc4e47c65bb9ab279ded04afb3ee5b9 3108576 utils optional bitcoin-qt_0.13.1-0.1~exp1_amd64.deb 0799536f4b61693184fce15b570e0eb2 4544932 debug extra bitcoin-tx-dbgsym_0.13.1-0.1~exp1_amd64.deb 35efba74233f9d02c8a28f52c95e997e 409470 utils optional bitcoin-tx_0.13.1-0.1~exp1_amd64.deb 17f5d5dcd6868d624e1aaf119d675888 29081088 debug extra bitcoind-dbgsym_0.13.1-0.1~exp1_amd64.deb 834bca9502ff0f15cef7525132520168 1489690 utils optional bitcoind_0.13.1-0.1~exp1_amd64.deb 1524333cec99065ba261ff6868f9d941 145838 libdevel optional libbitcoinconsensus-dev_0.13.1-0.1~exp1_amd64.deb bc1bcc53193db5d5964a7d074ec47abb 1031328 debug extra libbitcoinconsensus0-dbgsym_0.13.1-0.1~exp1_amd64.deb e613bb39dbd834fcaad4ec1932520a84 227752 libs optional libbitcoinconsensus0_0.13.1-0.1~exp1_amd64.deb -BEGIN PGP SIGNATURE- iQIvBAEBCAAZBQJYEb78EhxhakBlcmlzaWFuLmNvbS5hdQAKCRBhd7NVgqjYpkdr EADAoZALLRTXh6QuahjiWP/im2kBe0ryknDeHngRM1ky+XGT+/wXfC6xaWmnNz/9 NsMO6cOug+cizweGrRKQgAuOzZ2pCGE3uXmLp7/rgaGUsEkg/5HV
Accepted bitcoin 0.13.0-0.1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 21 Oct 2016 17:13:13 +1000 Source: bitcoin Binary: bitcoind bitcoin-qt bitcoin-tx libbitcoinconsensus0 libbitcoinconsensus-dev Architecture: source amd64 Version: 0.13.0-0.1 Distribution: unstable Urgency: medium Maintainer: Debian Bitcoin Packaging Team <pkg-bitcoin-de...@lists.alioth.debian.org> Changed-By: Anthony Towns <a...@erisian.com.au> Description: bitcoin-qt - peer-to-peer network based digital currency - GUI bitcoin-tx - peer-to-peer network based digital currency - transaction tool bitcoind - peer-to-peer network based digital currency - daemon libbitcoinconsensus-dev - bitcoin blockchain library development files libbitcoinconsensus0 - bitcoin blockchain library Closes: 835809 835963 Changes: bitcoin (0.13.0-0.1) unstable; urgency=medium . * Non-maintainer upload. * New upstream release. * Allow compilation with gcc/g++ 6. (Closes: Bug#835963) * Additional fixes for openssl 1.1 compatibility. (See Bug#828248) * Check if -latomic is needed (it is on mips*). * Remove reproducible build patch, since leveldb build system is no longer used in 0.13. (See Bug#791834) * Update description since the blockchain is much more than "several GB" now. (Closes: Bug#835809) Checksums-Sha1: a3ced73480eed55f6c8af6949631503c2ff56001 2644 bitcoin_0.13.0-0.1.dsc 4a8b138aabfd14ba8ddd06f93995e9ad6173c58d 5833967 bitcoin_0.13.0.orig.tar.gz ec48767d1373a71575ea612c839b788d97ea3df1 36340 bitcoin_0.13.0-0.1.debian.tar.xz ebded62d643e4e204fd943d9b52bfc825d2683bd 41595874 bitcoin-qt-dbgsym_0.13.0-0.1_amd64.deb 32e3865ec5c2a691852ec3a6267adf2daa449132 3039502 bitcoin-qt_0.13.0-0.1_amd64.deb a031f96468b2b500a00677a85df22026cb1c266a 4532406 bitcoin-tx-dbgsym_0.13.0-0.1_amd64.deb 6f4163c4a1dcaac5758b31254afc257fc5d5ae3c 416768 bitcoin-tx_0.13.0-0.1_amd64.deb 7b6b879fbd324ade47d2f10ade0188b8c18f824d 29012436 bitcoind-dbgsym_0.13.0-0.1_amd64.deb 2bf5f8c30e098291748bb6e97041c547bac01460 1490796 bitcoind_0.13.0-0.1_amd64.deb 5118448adea390331c6688d01c9c7e1ddda1f444 154646 libbitcoinconsensus-dev_0.13.0-0.1_amd64.deb 68dcc152e4bb319069d4c140063c75de309c4238 1028458 libbitcoinconsensus0-dbgsym_0.13.0-0.1_amd64.deb 43ca6a532d41d70d764ba37498323bdff56f88e8 236572 libbitcoinconsensus0_0.13.0-0.1_amd64.deb Checksums-Sha256: 51065ee03b322a17e6b18a5c3f6c7dfa0eaf628b2cd727b04e80dd3d9c6ffef4 2644 bitcoin_0.13.0-0.1.dsc 852581d21716b74e0539f7fd2f9c17f5506f1c21c5cec6642b0286823ba97193 5833967 bitcoin_0.13.0.orig.tar.gz 3b5787fdce7a86b134808b029462ba9de38c339ccdb992e1c69419f533e15121 36340 bitcoin_0.13.0-0.1.debian.tar.xz 72231347c08a3f87cd0884d2a2f1192cc0e97bf35385aa481e7100f785bf22ef 41595874 bitcoin-qt-dbgsym_0.13.0-0.1_amd64.deb a7319a42c93a5f1b05621ac0fb42a4db9c71a10cd80079c8fbe2e6faa4d61ae7 3039502 bitcoin-qt_0.13.0-0.1_amd64.deb c7f42eabfb90895857dc7d1991352709a13d09039fa5d67243e6d7ec83ae3751 4532406 bitcoin-tx-dbgsym_0.13.0-0.1_amd64.deb fcaf412821c720941dbac8222583819b87d8d70570659ee1d8ab4629d3b93c5a 416768 bitcoin-tx_0.13.0-0.1_amd64.deb c316ca9de9851a8495bd717eb7ae190d230c71cac138d553ed9f4316feccc2c5 29012436 bitcoind-dbgsym_0.13.0-0.1_amd64.deb fab005cb41692905204b62496323ecd79f610569bed62b0e1c8fff8f2c4c560f 1490796 bitcoind_0.13.0-0.1_amd64.deb 2e0db1db01f8885add189086bcede5b5f06923d5aa1fa1ea61e3e5435f6c7e50 154646 libbitcoinconsensus-dev_0.13.0-0.1_amd64.deb ab9af99e88f2b60c639cf070fb8f76d37e6dfb8cc9ab3da0fcfd532b5b488012 1028458 libbitcoinconsensus0-dbgsym_0.13.0-0.1_amd64.deb 76752fc018a651a214986afe92eda998d150e43254c416e33ffd9c298622772f 236572 libbitcoinconsensus0_0.13.0-0.1_amd64.deb Files: 9f65a79769d8a751217308acb4b99df6 2644 utils optional bitcoin_0.13.0-0.1.dsc 1cee144c1a359d0f202be401744f9be7 5833967 utils optional bitcoin_0.13.0.orig.tar.gz 07537ca8ad4fd60d2ad0ae65f9daaec5 36340 utils optional bitcoin_0.13.0-0.1.debian.tar.xz aa47a8fdb2c672df7fd72ee93742d32e 41595874 debug extra bitcoin-qt-dbgsym_0.13.0-0.1_amd64.deb 706f20d238c90caca93f19a9b517fe13 3039502 utils optional bitcoin-qt_0.13.0-0.1_amd64.deb 6ab6f3907a56699c7c387fa01150c3b1 4532406 debug extra bitcoin-tx-dbgsym_0.13.0-0.1_amd64.deb c692e4ff91508e7d142aeccb5aba2a0f 416768 utils optional bitcoin-tx_0.13.0-0.1_amd64.deb ceb368f316f4023b130f15a2d20abb97 29012436 debug extra bitcoind-dbgsym_0.13.0-0.1_amd64.deb ccbc02016ec48300f0ece5c103ee8241 1490796 utils optional bitcoind_0.13.0-0.1_amd64.deb 447bfa0ca8eac189afeb5175f7fb5b12 154646 libdevel optional libbitcoinconsensus-dev_0.13.0-0.1_amd64.deb 5b93f8867c7205255e77c6d224e3f0b8 1028458 debug extra libbitcoinconsensus0-dbgsym_0.13.0-0.1_amd64.deb d1aa706ffb8addf5b7ac0ed2ffb6bde3 236572 libs optional libbitcoinconsensus0_0.13.0-0.1_amd64.deb -BEGIN PGP SIGNATURE- iQIvBAEBCAAZBQJYCc70EhxhakBlcmlzaWFuLmNvbS5hdQAKCRBhd7NVgqjYpi5z EADeqo1KzUdBujjZTCj0Z+xjMmldh6GLCzEvUfFSQGz1B3advylrMHXfQ
Accepted bitcoin 0.13.0-0.1~exp1 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 23 Aug 2016 17:06:04 +1000 Source: bitcoin Binary: bitcoind bitcoin-qt bitcoin-tx libbitcoinconsensus0 libbitcoinconsensus-dev Architecture: source Version: 0.13.0-0.1~exp1 Distribution: experimental Urgency: medium Maintainer: Debian Bitcoin Packaging Team <pkg-bitcoin-de...@lists.alioth.debian.org> Changed-By: Anthony Towns <a...@erisian.com.au> Description: bitcoin-qt - peer-to-peer network based digital currency - GUI bitcoin-tx - peer-to-peer network based digital currency - transaction tool bitcoind - peer-to-peer network based digital currency - daemon libbitcoinconsensus-dev - bitcoin blockchain library development files libbitcoinconsensus0 - bitcoin blockchain library Changes: bitcoin (0.13.0-0.1~exp1) experimental; urgency=medium . * Non-maintainer upload. * New upstream release. * Allow compilation with gcc/g++ 6. (See Bug#812275) * Additional fixes for openssl 1.1 compatibility. (See Bug#828248) * Check if -latomic is needed (it is on mips*). Checksums-Sha1: b142ffe6882e1262b6c7f82dac646ee2c345f733 2664 bitcoin_0.13.0-0.1~exp1.dsc 4a8b138aabfd14ba8ddd06f93995e9ad6173c58d 5833967 bitcoin_0.13.0.orig.tar.gz aee08daf9f8eb825f936e6f1788ba43c30ffaf0e 36296 bitcoin_0.13.0-0.1~exp1.debian.tar.xz Checksums-Sha256: f316eddbf878ca5986a96f536d5704ec0b7bf978f39d77859da7943b9066bbb8 2664 bitcoin_0.13.0-0.1~exp1.dsc 852581d21716b74e0539f7fd2f9c17f5506f1c21c5cec6642b0286823ba97193 5833967 bitcoin_0.13.0.orig.tar.gz 537b7b24f1e6426665d3110bbc7c5317c2be86782865197ef01362c9465b33c7 36296 bitcoin_0.13.0-0.1~exp1.debian.tar.xz Files: a17260514f2afca1e6e196ce4ddeee11 2664 utils optional bitcoin_0.13.0-0.1~exp1.dsc 1cee144c1a359d0f202be401744f9be7 5833967 utils optional bitcoin_0.13.0.orig.tar.gz 8ac5a4062cf3160cb7956b48afff71be 36296 utils optional bitcoin_0.13.0-0.1~exp1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIvBAEBCAAZBQJXu/mHEhxhakBlcmlzaWFuLmNvbS5hdQAKCRBhd7NVgqjYplhA D/4jiqlU9mNUfNG4zRPf+lO57UvdH3bq3L4vFcmR0PNHKN0j0W99qB5INS6wUr5n txzdRnMR8spMHvsesa9r+iddq6Z1tJodr+ZMUSoXzpo0hK9cLhQ2fWXT7huNxz7x rsCqYTAoucISiRGqzt1bdYSlE2ckLEJvUNheJxOvoUO4t9Ur3o5yhtzREB0yu6Dk 5TK/GrRsB3WO1H5nmdZLCS2tSvrZmRq/kwL6rzvP6fA9JGe0XUUloN2niZxWNlPF Wp7H8Vm1Kth4GhtCoCz2QQ9YbObFHuDqniNvEwW3dcSNxFFcE+s1oBFSeu8RDocx b/8wYjL79sgEDhk38igmhj4P/MtdhqUvKjTQhcL3nYCD6cQrW8aPMGKKxM9kQFSM o+QiUb6Qr87VZsJkq2iyggyoAj7/ZZC8Kr0Zc7fNFFE2iO+WwH4LJJDjlkFIATa7 GyGYFLXR1zfrXAEzbPUhME/8CZ3B3IlGG3MEWHK55WsqmClDdKJGAzEna/C/URMb jfpoQ4n63avUKPCev8EcbZFGYcxIcUkZI9le0Tcpr/ZdGaej2WbNTTQNHvr4wrGH 18FG9qaG/kg1yfy22CDRDEicV6oHW9pQ21dLDvtZTBNwnp8/NNR0ehP5kiIf15jw Lp84kEZjf7z2X8rvoyZJCdQChY4Q9H4v6cD7SMbq7d4wCQ== =5xLe -END PGP SIGNATURE-
Accepted bitcoin 0.13.0~rc3-0.1 (source amd64) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 20 Aug 2016 02:22:48 +1000 Source: bitcoin Binary: bitcoind bitcoin-qt bitcoin-tx libbitcoinconsensus0 libbitcoinconsensus-dev Architecture: source amd64 Version: 0.13.0~rc3-0.1 Distribution: experimental Urgency: medium Maintainer: Debian Bitcoin Packaging Team <pkg-bitcoin-de...@lists.alioth.debian.org> Changed-By: Anthony Towns <a...@erisian.com.au> Description: bitcoin-qt - peer-to-peer network based digital currency - GUI bitcoin-tx - peer-to-peer network based digital currency - transaction tool bitcoind - peer-to-peer network based digital currency - daemon libbitcoinconsensus-dev - bitcoin blockchain library development files libbitcoinconsensus0 - bitcoin blockchain library Changes: bitcoin (0.13.0~rc3-0.1) experimental; urgency=medium . * Non-maintainer upload. * New upstream release candidate. * Allow compilation with gcc/g++ 6. (See Bug#812275) * Additional fixes for openssl 1.1 compatibility. (See Bug#828248) Checksums-Sha1: 9ba03e29e8ec6a4576545a2881eb1fa36b9b8c94 2672 bitcoin_0.13.0~rc3-0.1.dsc ae1c6fe94b12097404fbdb8facc9e4df0e899f4e 5834659 bitcoin_0.13.0~rc3.orig.tar.gz f6cb6200e4935fbc9796356e8abcfb7c02f8b06b 35612 bitcoin_0.13.0~rc3-0.1.debian.tar.xz 6c121b1854e2412ac9076f1fc7ffee0c7c0549cd 41424204 bitcoin-qt-dbgsym_0.13.0~rc3-0.1_amd64.deb fdfed68f66ff1afc26ca3d30ba9c6e8e233e29d0 3036730 bitcoin-qt_0.13.0~rc3-0.1_amd64.deb de57cfe28c1f09292534075f247359bb39d10ee8 4522328 bitcoin-tx-dbgsym_0.13.0~rc3-0.1_amd64.deb 03dcce1af21162107ea7a1537cd8c8c4d9d8fbe5 416240 bitcoin-tx_0.13.0~rc3-0.1_amd64.deb 602bce1aa21d7f44fda2452dae0d372adcda6846 28917178 bitcoind-dbgsym_0.13.0~rc3-0.1_amd64.deb d57f1cfc40a1667c7ee626183be76121621e3aad 1490110 bitcoind_0.13.0~rc3-0.1_amd64.deb 867212a94b535176428efd0ce7da07e1f5b5c694 153914 libbitcoinconsensus-dev_0.13.0~rc3-0.1_amd64.deb a2bbcb3db30702b6eb29827a9d2d13566a120747 1028630 libbitcoinconsensus0-dbgsym_0.13.0~rc3-0.1_amd64.deb 401b670743cfeaccc94ed8523b0782e891df54a0 236156 libbitcoinconsensus0_0.13.0~rc3-0.1_amd64.deb Checksums-Sha256: 84aeb3e5998603a7f4a243fc34c03acc0782f8020a98e4a5e19bb243cf858c85 2672 bitcoin_0.13.0~rc3-0.1.dsc 8a942cb976227cff83af12f9ce1a7c6bf9d9cbc5d31c8e07ee2a4c04271e0d58 5834659 bitcoin_0.13.0~rc3.orig.tar.gz a464fe5477b83bafa507d1045c96b2ba8df1797836a68a3a5dbacc11b08f8b5d 35612 bitcoin_0.13.0~rc3-0.1.debian.tar.xz dbca2b12acb1ee4874e155698b689dcf86da59f48334b20f6a7890b2e3320277 41424204 bitcoin-qt-dbgsym_0.13.0~rc3-0.1_amd64.deb ec7e73fc0cc074b9a06a0a05c236489da8af08a3ad5c62ebec3943b6ccbf821a 3036730 bitcoin-qt_0.13.0~rc3-0.1_amd64.deb b264556b6e05a7bba6d21bfe4f1538dcd6bafac87ca1bfe99e2d5d604156711c 4522328 bitcoin-tx-dbgsym_0.13.0~rc3-0.1_amd64.deb c0bc8a1b8336d50e1c97a2b8195fd97e40fd9fb8e6ca3ef4d4a4927918304d16 416240 bitcoin-tx_0.13.0~rc3-0.1_amd64.deb 1942781b71ecd838d7cf3e248621177beaf8342c26904656feae510edb8d14cc 28917178 bitcoind-dbgsym_0.13.0~rc3-0.1_amd64.deb 7d6b3461094072682179e6bd1fc5ef267a68aab003f27528d4083feaa71fdc4d 1490110 bitcoind_0.13.0~rc3-0.1_amd64.deb 6ebd9f5fa30eafbe542fefdbf8ffa0f6da99e08b6ab2357b818075597504c61a 153914 libbitcoinconsensus-dev_0.13.0~rc3-0.1_amd64.deb d905ee755e3b2ecf5bfe591f6faf537595ddcdfa40d4dacecff0cd947bd452e6 1028630 libbitcoinconsensus0-dbgsym_0.13.0~rc3-0.1_amd64.deb 00bba66eb7522511408241542519941a050371d6ebdfcf59b10ea433c5bbdfea 236156 libbitcoinconsensus0_0.13.0~rc3-0.1_amd64.deb Files: b0187be51a5cd86c46add786f21ad620 2672 utils optional bitcoin_0.13.0~rc3-0.1.dsc b3b845729531145be9bebbe5ec136fb0 5834659 utils optional bitcoin_0.13.0~rc3.orig.tar.gz 33ad067e0eb25fbfde353f2ad1ab9d04 35612 utils optional bitcoin_0.13.0~rc3-0.1.debian.tar.xz 7b1502ce0feb515bc101f4e4ca4be372 41424204 debug extra bitcoin-qt-dbgsym_0.13.0~rc3-0.1_amd64.deb ae27fb8ef1ecd6e444c902f68d43eaff 3036730 utils optional bitcoin-qt_0.13.0~rc3-0.1_amd64.deb abd456e9bce8b9077710838ea9b1f92a 4522328 debug extra bitcoin-tx-dbgsym_0.13.0~rc3-0.1_amd64.deb 7edf70faaa0b5515dc0701d1cab999cb 416240 utils optional bitcoin-tx_0.13.0~rc3-0.1_amd64.deb a3906f34f05937cfef557b473cd4f605 28917178 debug extra bitcoind-dbgsym_0.13.0~rc3-0.1_amd64.deb 921b1fed330e469693b72411a22fd67b 1490110 utils optional bitcoind_0.13.0~rc3-0.1_amd64.deb f09a040af9def4edadeaae369a43c0cd 153914 libdevel optional libbitcoinconsensus-dev_0.13.0~rc3-0.1_amd64.deb 949869909dab8bc2bb04ff56ca984cea 1028630 debug extra libbitcoinconsensus0-dbgsym_0.13.0~rc3-0.1_amd64.deb 95228f239be75ec2a46257bd886ff117 236156 libs optional libbitcoinconsensus0_0.13.0~rc3-0.1_amd64.deb -BEGIN PGP SIGNATURE- iQIvBAEBCAAZBQJXt0IHEhxhakBlcmlzaWFuLmNvbS5hdQAKCRBhd7NVgqjYpvoX EADHvxUPLC8Q6I11GTANKV4bHbzMlDXGQobQkscFCO146u0+KgYp7N3Nr6COK0D/ XJMhZTRSFXqD1KIg6PjO9bveJOB5BQHENpr18kPyU6uvwFGbPM3aZCZTqOLz/uOK aebr86UdnvPTMO+h4ZqkMOrJwJ4nep+coy1OuxIXuHkWgdIKB1MxjsF8KN
Accepted bitcoin 0.12.1-0.1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 19 Aug 2016 18:48:51 +1000 Source: bitcoin Binary: bitcoind bitcoin-qt bitcoin-tx libbitcoinconsensus0 libbitcoinconsensus-dev Architecture: source amd64 Version: 0.12.1-0.1 Distribution: unstable Urgency: medium Maintainer: Debian Bitcoin Packaging Team <pkg-bitcoin-de...@lists.alioth.debian.org> Changed-By: Anthony Towns <a...@erisian.com.au> Description: bitcoin-qt - peer-to-peer network based digital currency - GUI bitcoin-tx - peer-to-peer network based digital currency - transaction tool bitcoind - peer-to-peer network based digital currency - daemon libbitcoinconsensus-dev - bitcoin blockchain library development files libbitcoinconsensus0 - bitcoin blockchain library Closes: 791834 808969 812275 822203 828248 Changes: bitcoin (0.12.1-0.1) unstable; urgency=medium . * Non-maintainer upload. * New upstream release. (Closes: Bug#822203) * Remove cdbs from debian/rules, add debian/copyright-check to help with updating debian/copyright info (Closes: Bug#808969) * Update dependencies to qt5. * Add dependency on libdevent-dev. * Add dependency on libzmq for ZeroMQ support. * Force use of gcc/g++ 5. (Closes: Bug#812275) * Compatibility patch for OpenSSL 1.1 opaque types. (Closes: Bug#828248) * Apply reproducible build patch from Reiner Herrmann. (Closes: Bug#791834) * Bump standards version. Checksums-Sha1: 75fec1287e7909f8083d67d9764c173f94acef88 2658 bitcoin_0.12.1-0.1.dsc a4aa233bf4587169925c6b7c1dfc288ef3b0bc40 6751284 bitcoin_0.12.1.orig.tar.gz 342640f62053156d912ebff69300dd944f6789f3 35548 bitcoin_0.12.1-0.1.debian.tar.xz f14f4db09b5071c708d5012122311e6eae8fef85 34998476 bitcoin-qt-dbgsym_0.12.1-0.1_amd64.deb 8bd4a93f7f617c50e7b5b71d7de3c3cc56fc8789 3699984 bitcoin-qt_0.12.1-0.1_amd64.deb 645eb920ad20fbba5ef0f7a65cd933440d24773c 3777508 bitcoin-tx-dbgsym_0.12.1-0.1_amd64.deb e62b1be2378c83d2a33c1ead35074eccd7baad2b 388430 bitcoin-tx_0.12.1-0.1_amd64.deb 6c916b63946fcf706a10f4845db23c2f11659f83 24958558 bitcoind-dbgsym_0.12.1-0.1_amd64.deb ff98c6ccbf22fbd2cef17e52503a5c7dd62ffbb8 1481674 bitcoind_0.12.1-0.1_amd64.deb df1aa04172cbb3bbfccb920d6c972a62929195cf 110360 libbitcoinconsensus-dev_0.12.1-0.1_amd64.deb b2ce67955e14ba54b07ca62263ecbe4eb6428337 647630 libbitcoinconsensus0-dbgsym_0.12.1-0.1_amd64.deb b47fabe1864f8d307f4fe640872c4f149566417e 195320 libbitcoinconsensus0_0.12.1-0.1_amd64.deb Checksums-Sha256: 485b8b526357d429ac9c638099e0b0ac555261a6bae2b92a72a56c06dfb358ab 2658 bitcoin_0.12.1-0.1.dsc 7bdc287575067461c123e1afcb48843f9f78eb5e6cac95b413e2e09f1f7fc7bd 6751284 bitcoin_0.12.1.orig.tar.gz 9e1632e375aec3c6cc3848ba17a1ecd4918f9a359352b555cfc0e621e3bc8751 35548 bitcoin_0.12.1-0.1.debian.tar.xz 25a321e39a228835d21a4916f93da09f6f4819c38c75008064829e0e1d53df57 34998476 bitcoin-qt-dbgsym_0.12.1-0.1_amd64.deb 9814bd1b8317742b2d3ed7e3974f2a0df3ccf1d0051652709b34491ca046def9 3699984 bitcoin-qt_0.12.1-0.1_amd64.deb 100078b351be7c13c69e39342f140653f83ebf3c26efad0ef8819e2a79a09acb 3777508 bitcoin-tx-dbgsym_0.12.1-0.1_amd64.deb 72b4f57b02d8f67b53b865c6145e71b6dcf6b49acac763d01430d076ffd58482 388430 bitcoin-tx_0.12.1-0.1_amd64.deb 6909953b723a9070263d610fdd1f6fc2bf68c9b4e3a2874d6bfe11a07bb5a292 24958558 bitcoind-dbgsym_0.12.1-0.1_amd64.deb 8c5c6821619de58c5bbdcca73c528505f069846c9443b6a26ce59910346e576d 1481674 bitcoind_0.12.1-0.1_amd64.deb 9f1406ca35381480fdce5843659261c226c834e5476100a4402b61f02b2e1c62 110360 libbitcoinconsensus-dev_0.12.1-0.1_amd64.deb 211cf805889b14480917d4bd72dfa9b4c3de18f206782d908d922c77362b0118 647630 libbitcoinconsensus0-dbgsym_0.12.1-0.1_amd64.deb 72498af83bf62082ff91eebadaf4b877b96995f60e95add4338d28452587ab80 195320 libbitcoinconsensus0_0.12.1-0.1_amd64.deb Files: a25660598381e536b6c054bc7b78424b 2658 utils optional bitcoin_0.12.1-0.1.dsc 94229fa506422290e60b215055f74434 6751284 utils optional bitcoin_0.12.1.orig.tar.gz 22a282327dc92e0705d5c2898fd886f4 35548 utils optional bitcoin_0.12.1-0.1.debian.tar.xz 3aeb964d16a0e0532acabb5a64e3b74f 34998476 debug extra bitcoin-qt-dbgsym_0.12.1-0.1_amd64.deb ebe889cfbe5637268d68a3cf43809d55 3699984 utils optional bitcoin-qt_0.12.1-0.1_amd64.deb f663b095a6b9e436affda21d018bfa72 3777508 debug extra bitcoin-tx-dbgsym_0.12.1-0.1_amd64.deb 9b7e9c58877c78853dc9e8da28a0f3af 388430 utils optional bitcoin-tx_0.12.1-0.1_amd64.deb 7e2e84404a99a27c41286ee176556b21 24958558 debug extra bitcoind-dbgsym_0.12.1-0.1_amd64.deb da27283e1575a603eac630f52b6d2e67 1481674 utils optional bitcoind_0.12.1-0.1_amd64.deb 65a19912d02346d6b80b52b7e28a1765 110360 libdevel optional libbitcoinconsensus-dev_0.12.1-0.1_amd64.deb b541386f5b52dc89933c75c78fbb4999 647630 debug extra libbitcoinconsensus0-dbgsym_0.12.1-0.1_amd64.deb 7ee55a71f36196478b9c9bace01ff3fd 195320 libs optional libbitcoinconsensus0_0.12.1-0.1_amd64.deb -BEGIN PGP SIGNATURE- iQIvBAE
Re: DAK Commands for Bikesheds
On Thu, Sep 17, 2015 at 01:42:58PM +0200, Joerg Jaspert wrote: > Please check if I forgot something obvious or if there is some big error > in it. Patches/git trees to merge from/... are welcome. dcut from dput-ng uses $login-$timestamp rather than "EPOCH" per se. Does this actually matter, or is it just convention though? ] The file needs to be signed by a valid key from the Debian uploader ] keyrings. Does the $login in the filename have to correspond to the signing key? Ditto the Uploader: field? ] This file has to be uploaded to ftp.upload.debian.org. I presume dak-commands will be queue-able if anyone updates queued? There's nothing fundamental preventing it, right? -1 on abbreviated command names fwiw; it's a text file so Action: create-bikeshed seems fine to me. I'd be a little inclined to have "bikeshed-create" personally, YMMV obviously. "update-bikeshed-acl" or "bikeshed-acl" or similar might be clearer than "access-bikeshed". I kind of think "Bikeshed: foo" might be better than "Name: foo" ? We have "Package: foo" not "Name: foo" in the Packages file, eg. ] if the name conflicts with an existing bikeshed a ] random string will be appended to it. Outright rejection would be better here, IMO. The user can always add a random string themselves if that's what they actually want. ] Package: A name of a source package to import from the base-suite. ] Repeat as often as needed. That's unusual. Is having multiple packages on a single header also valid? eg: Package: glibc, systemd, sysvinit ? If "Master:" is specified, is the uploader implicitly considered a master as well, or do they need to specify themselves? (It seems they are implicitly considered a master when updating the bikeshed's ACLs) I would have thought "Owner:" would make more sense than "Master:" fwiw. ] including dropping a bikeshed (Demolishing would be a more amusing verb :) (Likewise, "modify-bs" should clearly be "paint-bikeshed" given it only changes things that have no technical effect...) For the "Master" and "Uploader" fields, it would probably be nice if you could specify DDs by uid instead of just fingerprint. (Especially so that updates to the keyring were automatically reflected in bikeshed permissions) ] (eg., DMs need an ACL set for their package). It seems like it would be good to have some way of letting a DM hack on a package that they can't do in unstable -- ie, where they can practice, or demo their ideas, etc. This might be handy for "summer of code" projects for example. I wonder if it might be better to have two permissions arrangements: (a) don't specify any fingerprints, and anyone who can upload to unstable can upload to the bikeshed (same ACLs for DMs), or (b) do specify fingerprints, and those keyholders can upload anything in the bikeshed (no ACLs for DMs), but no one else can. Has the Auto-Update / mergeback stuff been implemented yet? It doesn't seem like it quite makes sense as is: ] Auto-Update: True or False. Automatically update packages imported ] from the base suite, whenever they get updated in the base suite. This ] may possibly break packages uploaded directly to the bikeshed. This option doesn't really seem useful to me -- rather than say "base-suite: jessie; auto-update:yes", why wouldn't you say "add both jessie and bs-my-awesome-thing to your sources.list"? If the base-suite is testing or unstable, users will have to have testing/unstable in their sources list anyway in order to get library dependencies most of the time... To me, it seems more useful to have two commands: Action: bikeshed-pull-from Bikeshed: bs-my-awesome-thing Suite: experimental Packages: apt, xorg and Action: bikeshed-push-to-base Bikeshed: bs-my-awesome-thing The thinking being that you'd use a bikeshed like: a) "bikeshed-create" -- voila, empty repo, with rules about what can go into it, and a base-suite for resolving dependencies b) "bikeshed-pull-from" -- add some packages from other suites (not necessarily the base-suite) c) upload -- add some of your own packages d) "bikeshed-push-to-base" -- (mergeback) move some/all of the packages in the bikeshed into the bikeshed's base suite (Autobuilders would use the base-suite and the bikeshed to resolve build dependencies; if the base-suite was a bikeshed itself, then recurse) If "auto-update" let me say "if a new source for foo arrives in unstable, rebuilt it in my bikeshed (with base-suite: stable) automatically", that would be cool, but... Are mergebacks atomic? ie if you try to mergeback 10 packages, and one of them fails, do you get 0 merged back or 9? 0 would probably be better, to avoid the case where the 1 that failed was a dependency of the 9 that succeeded. ] Command files allow Debian Developers to handle various archive ] related tasks without the help of a FTPMaster. This forbids DMs from creating bikesheds, doing any "owner" actions on a bikeshed, and doing mergebacks, no? (That seems
Re: DAK Commands for Bikesheds
On Sun, Sep 20, 2015 at 03:48:24PM +0200, Joerg Jaspert wrote:
> > That's unusual. Is having multiple packages on a single header also
> > valid? eg:
> > Package: glibc, systemd, sysvinit
> > ?
> I think it's cleaner to have one per package tag, but its either that or
> only one line, comma-seperated. No preference here.
*shrug* No real preference here either.
> > (It seems they are implicitly considered a master when updating the
> > bikeshed's ACLs) I would have thought "Owner:" would make more sense
> > than "Master:" fwiw.
> Then you end up having multiple owners.
I don't see a problem with that (eg, owner@bugs.d.o has multiple
recipients). But again, *shrug*.
> > For the "Master" and "Uploader" fields, it would probably be nice if
> > you could specify DDs by uid instead of just fingerprint. (Especially
> > so that updates to the keyring were automatically reflected in bikeshed
> > permissions)
> Fingerprint handling is way easier, especially when taking DMs in
> account, so that is noted, but will probably not be in the very first
> version.
I think uid handling would be pretty easy:
- change the bikeshed_acl table from "suite, level, fingerprint"
(level being "master" or "uploader") to "suite, level, uid, fingerprint".
- add a "check" constraint on bikeshed_acl:
CHECK ((uid IS NULL AND fingerprint IS NOT NULL) OR
(uid IS NOT NULL AND fingerprint IS NULL))
- when querying fingerprints for a suite, instead of:
SELECT fingerprint FROM bikeshed_acl WHERE suite = {} AND level = {}
use
SELECT COALESCE(acl.fingerprint, fp.fingerprint)
FROM bikeshed_acl AS acl OUTER JOIN fingerprint AS fp ON
(acl.uid = fp.uid)
WHERE acl.suite = {} AND acl.level = {}
Happy to have another look when there's enough code to suggest an
actual patch.
> > ] (eg., DMs need an ACL set for their package).
> > It seems like it would be good to have some way of letting a DM hack on a
> > package that they can't do in unstable -- ie, where they can practice,
> > or demo their ideas, etc. This might be handy for "summer of code"
> > projects for example.
>
> Ack.
>
> > I wonder if it might be better to have two permissions arrangements: (a)
> > don't specify any fingerprints, and anyone who can upload to unstable
> > can upload to the bikeshed (same ACLs for DMs), or (b) do specify
> > fingerprints, and those keyholders can upload anything in the bikeshed
> > (no ACLs for DMs), but no one else can.
>
> So basically what it is now (set no uploader and its same as for
> unstable, set fingerprints and its those), except for the "DMs need an
> ACL" is turned into "DMs don't need an ACL for a package, if listed as
> an Uploader in this bikeshed"? That would allow them to upload all
> packages to that bikeshed.
>
> Alternative would be to add that as a third option, so one would have
>
> - free for all, ACLs for DMs (as unstable)
> - free for all listed, ACLs for DMs
> - free for all listed, no ACLs for DMs
Oh, yes! That would just be:
Action: bikeshed-acl
Bikeshed: bs-foo
DM-ACLs: off
Uploader: [dm fp]
Uploader: [dd fp]
> The idea is to say "Make me a bikeshed of packages foo and bar, keep em
> updated with my base suite, i'm rebuilding against them everytime they
> update". It's not thinking about the end user here, that sure can add
> both suites.
In that case you actually want a bikeshed of packages foo, bar and baz;
so that you can upload baz to the bikeshed when you rebuild it, no? But
then you also get new versions of baz if you set auto-update.
But I'm not seeing the advantage over setting the base-suite and just
listing baz for your bikeshed. Everytime foo/bar changes you upload a
new baz, and the autobuilders pull the new foo/bar from your base-suite
as build-deps, and you're done.
I'm assuming that an upload to a bikeshed gets REJECTed if:
- uploader isn't in the acl for the bikeshed
- it's not a listed package for the bikeshed
- it's not in the overrides for unstable (or base-suite?)
- it fails standard corruption checks (bad tarball, lintian)
- it has an older version that what's already in the bikeshed
- it has an older version that what's already in the base-suit ?
> > To me, it seems more useful to have two commands:
> > Action: bikeshed-pull-from
> > Bikeshed: bs-my-awesome-thing
> > Suite: experimental
> > Packages: apt, xorg
> > and
> > Action: bikeshed-push-to-base
> > Bikeshed: bs-my-awesome-thing
>
> > The thinking being that you'd use a bikeshed like:
> > a) "bikeshed-create" -- voila, empty repo, with rules about what
> > can go into it, and a base-suite for resolving dependencies
> > b) "bikeshed-pull-from" -- add some packages from other suites (not
> > necessarily the base-suite)
> > c) upload -- add some of your own packages
> > d) "bikeshed-push-to-base" -- (mergeback) move some/all of the packages
> > in the bikeshed into the bikeshed's base suite
>
> > (Autobuilders
Re: Summary of the DebConf firmware discussion
On Fri, Aug 28, 2015 at 04:33:04PM +0100, Steve McIntyre wrote: This now means that more and more users end up enabling non-free just to be able to get at this firmware, which is a problem for many reasons. 1. Split up non-free? - Yes - need to work out details. (a) I'd argue non-free is already split up -- that's what the Section: header in the Packages file is for. That's certainly good enough for just pulling some selection of debs out for an installer image; and it seems like it wouldn't be too much work to use apt pinning to allow it to prevent non-firmware from non-free from getting in. For example, having the installer drop: Package: * Pin: release c=non-free Pin-Priority: -1 Package: * Pin: release c=non-free,s=non-free/kernel Pin-Priority: 500 into /etc/apt/preferences.d/10allow-non-free-firmware. (Note: Pin: release s= doesn't actually work. I /think/ it could be made to work, though maybe it shouldn't (section doesn't appear in the Release file after all). Worst case, Pin: package section=non-free/kernel could be made to work, I think) (b) In, hopefully, the mid-term, doesn't this sound like a job for bikesheds [0]? Drop non-free (and contrib?) entirely, and have a non-free or non-free-firmware-blob bikeshed, and have the installer-with-firmware come as part of the bikeshed. Nothing special about non-free at all that way, as other bikesheds could also have their own installer. [0] aka Debian PPAs for those who aren't au fait with the new terminology (c) Splitting non-free into separate components (ie, so you'd say main contrib non-free/firmware non-free/gfdl) under ftp.debian.org/debian/dists/* would be bad though, IMO -- it makes non-free require more attention (from archive admins, maintainers, users) when we should be working to give non-free less attention. *IMPORTANT*: We need to make sure that the messaging about this split is clear; just because we're splitting non-free firmware out of the default non-free area, that doesn't mean that we're suddenly endorsing it as a concept! (I think demoting non-free to one of many bikesheds would be a massive messaging improvement here) 2. Include non-free-firmware on official media? --- NO. Would the following be technically feasible? - I want to install Debian - download official USB installation image - write it to USB stick - Oh, I need non-free network drivers - download non-free firmware - mount installation image - copy firmware onto installation image - umount - boot, install Having installation on non-free firmware systems require a token amount of additional work by the user would be a fairly clear indication that non-free is bad, and it would be very clear that the official images, and in fact, every image we produce, doesn't include non-free firmware. 3. Advertise the unofficial firmware-included media better? - Yes. If we advertise them, it feels like doublespeak to call them unofficial to me. (Which is bad, though still better than not doing anything to prefer fully free stuff, and also better than making it a PITA for people to run Debian on common hardware, though, if those are the only alternatives) 5. Anything else we can do to improve the situation? I wonder if it would make sense / be interesting to do more of the preparation work prior to the install. For instance: If a user's machine includes hardware that needs non-free firmware, maybe we could suggest known-good alternatives that would offer similar functionality without the problematic firmware. If you could review this before install (on a web page, eg), and then choose where you want the non-free stuff or free alternatves (after browsing wiki links etc to fully inform yourself), you could download the firmware udebs you might need and a preseeding file corresponding to that choice, then effectively boot directly to an installed, working system, with no further questions. Also, having a hardware database that you could query before purchasing a new computer would be even better, no? (If you added a popcon style feedback loop where install results were uploaded back to a Debian server, you could log the time installation took, and use that info to provide future installs onto the same hardware with similar configurations with an *accurate* progress bar...) Cheers, aj
Re: Facilitating external repositories
On Mon, Aug 17, 2015 at 11:15:08AM +0200, David Kalnischkies wrote: On Sun, Aug 16, 2015 at 12:06:53PM +, Anthony Towns wrote: The user interface improvement might be worth it anyhow, but selling this as huge security improvement is just wrong, which is all I am against. I think it's a practical security improvement -- having one point you can exploit is a lot better than having four points you can exploit. But the desired use case is still grab stuff from someone on the Internet that I don't know well and give it root permissions on my system, and I don't think you can make that secure in any absolute sense. If there's any further improvements possible, I can't think of them. :( With extrepos as I describe them, the steps are: 1. You hear about a cool repo from somewhere, and are told to just get the example-abc123 repo. 2. You run extrepo add example-abc123, and run apt to install the packages. [3. check sigs on the key] That should ideally still include 3. as especially with a centralized site you are susceptible to end up with bad data stored under a similar name, like you do if you trust short keyids for gpg. Sure. In fact, why should extrepo add display that? Is there a web service that can work out trust paths...? That wasn't an all engines full stop. My initial comment on this was you will *eventually* need to deal with merging in the funky gui tools adding sources. (highlight by me). Ah, right -- I definitely read that as all engines full stop. My bad. And for the record, I think it is really really bad to even suggest that it is okay to ignore warnings. They are displayed for a reason – in that case there is a fair chance the user meant to configure another source but actually didn't. Yes, in real use, definitely. I've been kindof focussing on an absolute minimum viable solution. There are another few bits I've been handwaving over too for the record: - updating a repo (if it needs a new key or new url) is impossible as far as I've described - there's no way to relate repos (jessie vs wheezy base; stable vs dev versions; canonical site vs mirror) - providing a search function on extrepos.debian.net might be actively /harmful/ for security (ie, it'd be hard to avoid malicious repo creators being more effective at SEO on extrepos.d.n than legit repo creators) But (as I said to David in person) seems like it's time to have some code to throw stones at, rather than just list posts now... Cheers, aj
Re: Facilitating external repositories
On Sat, Aug 15, 2015 at 12:47:42PM +0200, David Kalnischkies wrote: I think my working assumption is anyone can register, and it's done automatically. If you want to ensure the URL is owned by the register, you could use a dummy DNS record (please add extrepo-de684554ae0c3440.example.org CNAME extrepos.debian.net. to your DNS). Srsly? Until now it sounded very open, but DNS records are far from being available for everyone (and far from being secured) beside that there can be multiple archives on the same domain. Try again. Like I said, my working assumption is anyone can register and it's done automatically, ie no check at all. You wanted something harder, not me :) A less obstruse check would be: - is the nominated key the signing key for the repo's Release file? - can the person sign an extrepo request with that signing key? which should be about sufficient to demonstrate control of the domain and key. Or did you mean that the DD signs the sources.list file directly? Well, then my key isn't usable for that right now, but in exchange the DD might have a slight problem in assuring the correctness of what he is signing: I am the owner of example.org/debian. Trust me. I'm not sure this is a problem -- if you're not the owner of example.org/debian, then the files I download from there won't have your signature. If they do have your signature, then it's just the question of whether I trust your random repo, and I can't figure that out just from knowing who you are. … I was thinking man-in-the-middle here. If I can register example.org/debian with a key of my choosing I can do really bad things, especially if example.org is the domain of a Debian mirror and I manage to trick people into adding this e.g. by claiming that this is a faster mirror… […] If you put in a /different/ key and go to the trouble of intercepting some users' traffic to example.org, things look slightly different: […] There's a few problems with doing that: a) anybody whose traffic to example.org you can't intercept will get an error if they check that repo against the nominated signing key. if extrepos.d.n does minimal sanity checking before adding a repo, this makes this attack a non-starter afaics. So, let me get this straight: The reason we need extrepo.d.o is because there could be an all consuming man-in-the-middle exchanging the description as well as the download of the archive key with something of his own choosing, but if we have extrepo.d.o this is suddently no longer a problem because it is too unlikely that there is such a man-in-the- middle. Obviously not. Here's how you currently setup an external repo as securely as possible: 1. You hear about a cool repo from somewhere, and are told to go to https://example.org/debian/README.html for more instructions. 2. You read that page, and obtain a line to add to sources.list and a key to add to apt-key. 3. You (maybe) look at the key to see if it's signed by someone you know, and doesn't look shady. 4. You add the key and sources.list entry, and run apt to install the packages. If https and example.org are secure, or if you are able to verify the key using the web of trust, this is fine (although it requires a bit of effort). If neither of those are reliable (because you've got a Lenovo laptop so anyone can fake SSL on you or just because its an http:// url not an https:// one; and because you don't understand gpg so don't know about the web of trust, or because someone in the Debian keyring isn't 100% perfect, eg), then there's a MITM attack: I capture your traffic to example.org, replace the README, key and repo, and you're stuck. That's the MITM attack that's avoidable. There's an entirly separate attack that's fundamental to external repos: I make an external repo of my own, pretend that it's good, get people to install from it, but actually upload bad things into it. In that case I'm not in the middle though, I'm an endpoint. With extrepos as I describe them, the steps are: 1. You hear about a cool repo from somewhere, and are told to just get the example-abc123 repo. 2. You run extrepo add example-abc123, and run apt to install the packages. extrepo uses a Debian signed certificate linking example-abc123 to a unique key and url, so that anyone who tries to get that repo is pointing to the same place. If you want to tell people to go to a different repo -- example-123abc say, that's fine; but allowing that is a required feature. Likewise, you could MITM the forums that are raving about what a great repo example-abc123 is, and make them look like they're raving about example-123abc, but I don't think that's avoidable. b) if someone's trying to install a PPA for secured-ssh, why would they go through extrepos? Because editing sources.list is hard and running 'extrepo add ppa-whatever-16734' is
Re: Facilitating external repositories
On Thu, Aug 13, 2015 at 11:23:19AM +0200, David Kalnischkies wrote: On Wed, Aug 12, 2015 at 11:12:05PM +, Anthony Towns wrote: I'm not sure if the idea is PPAs can only be added to by DDs/DMs. [...] There is a session about Debian PPAs at 2015-08-21 17:00..18:00 @ DebConf, so all the details there I presume, but as far as public information up to today goes (which I have seen) is that they are limited to DD/DM, on Debian infrastructure and signed by the usual archive signing key, so that trust in the archive-key isn't an issue here – the problem is just in easily adding PPAs to your sources which while currently bundled in this thread as well, I would like to avoid as a topic for now to focus on the archive-key part for external archives which aren't signed by Debian. Yeah, that mostly sounds straightforward -- apt key is already fine, uploads and new repos don't add much more risk than unstable already has, everything in PPAs goes to a central server and can be tracked so it's not easy to use PPAs to sneak things onto individual systems. The downside is it limits things to DDs/DMs, so it doesn't make it much easier to get totally new stuff available for Debian users, so that's where extrepos come in. To use an external repo, you need a deb822 sources.list file and a pubkey. To get those, you contact extrepos.debian.net, and either do some sort of search, or plug in a 6+ digit hex code. extrepos.debian.net spits back a signed bundle of the repo's public key and a deb822 sources.list (which includes a description of what the repo is meant to contain), both named to match the 6+ digit hex code. That could work (see also below), you just need to figure out a way of registering an external repository at extrepos.debian.org now, which involves deciding who can register one and how to ensure that what I register is actually owned by me because… I think my working assumption is anyone can register, and it's done automatically. If you want to ensure the URL is owned by the register, you could use a dummy DNS record (please add extrepo-de684554ae0c3440.example.org CNAME extrepos.debian.net. to your DNS). Or did you mean that the DD signs the sources.list file directly? Well, then my key isn't usable for that right now, but in exchange the DD might have a slight problem in assuring the correctness of what he is signing: I am the owner of example.org/debian. Trust me. I'm not sure this is a problem -- if you're not the owner of example.org/debian, then the files I download from there won't have your signature. If they do have your signature, then it's just the question of whether I trust your random repo, and I can't figure that out just from knowing who you are. … I was thinking man-in-the-middle here. If I can register example.org/debian with a key of my choosing I can do really bad things, especially if example.org is the domain of a Debian mirror and I manage to trick people into adding this e.g. by claiming that this is a faster mirror… I still don't think this is true? Let's suppose you've found a mirror of a PPA that's intended for building honeypots, so it has a version of sshd with a bad random number generator and a couple of known exploits. It's signed by the Debian archive keyring. Now I create an extrepo as follows: Type: deb deb-src URI: http://mirror.example.org/debian-ppas/honeypot/ Suite: stable Section: main Description: security enhanced sshd This repo contains enhaned builds of sshd and some related utilities with vastly improved security options over the standard builds in Debian. Signing-Key: [archive signing key goes here] How is that an advantage over just setting up my own extrepo with dangerous packages and a misleading description? If you put in a /different/ key and go to the trouble of intercepting some users' traffic to example.org, things look slightly different: Type: deb deb-src URI: http://mirror.example.org/debian-ppas/secured-ssh Suite: stable Section: main Description: security enhanced sshd This repo contains enhaned builds of sshd and some related utilities with vastly improved security options over the standard builds in Debian. Signing-Key: [*MY* signing key goes here] There's a few problems with doing that: a) anybody whose traffic to example.org you can't intercept will get an error if they check that repo against the nominated signing key. if extrepos.d.n does minimal sanity checking before adding a repo, this makes this attack a non-starter afaics. b) if someone's trying to install a PPA for secured-ssh, why would they go through extrepos? c) if you've gotten someone to install your extrepo, and they'll agree to install things signed by your key, why not just point them directly at a server you control? if you do that, you can be much nastier, eg by serving a real secured ssh to most people, and a vulnerable
Re: Facilitating external repositories
(Piling onto this after a dc15 dinner convo referencing it) On Tue, Jul 28, 2015 at 12:41:45AM +0200, Wouter Verhelst wrote: On Sat, Jul 25, 2015 at 07:27:21PM +0200, David Kalnischkies wrote: On Thu, Jul 23, 2015 at 10:14:21AM +0200, Wouter Verhelst wrote: (apologies if the identity of who's being quoted below is confusing) So aiui there's three levels of repos we're talking about: - Debian controlled: main, contrib, non-free; stable, testing, unstable, experimental - PPAs: Debian hosted, but more loosely controlled. experimental gone wild? maybe third party uploads? probably only free things? - External repos: all sorts of random crap. (I'm not sure where the line between Debian PPAs and external repos is) As far as trust goes, I think we can (and have to) assume that people can install Debian safely somehow; and from that point on have access to a current debian-archive-key as well as the debian-keyring and debian-maintainers keyrings. I think the level of trust you would want for PPAs then is probably that you're able to see a name and description (like rust2.0, this will give you pre-alpha access to packages of rust as it goes towards 2.0) and be confident that what you install will match what you expect from that. I'm not sure what checks will go into putting stuff in PPAs; being Debian hosted it would be possible to block uploads based on lintian checks, or limit PPAs to a specific set of packages (so the rust2.0 PPA couldn't sneak an update to libc6 in), or limit updates that change the Provides: or Conflicts: headers. I'm not sure if the idea is PPAs can only be added to by DDs/DMs. If not, can anonymous folks setup a PPA for pirated software, or try to compromise the PPA build system or similar? If PPAs are for DDs and DMs only, I'm presuming they can just use the existing Debian keyring to sign the PPA Release files. Anyhoo. To make external repos both secure and easy, I think you want to do two things: - make sure that it's easy to check that when you're talking about Bob's cool custom wordpress debs that you can be sure you don't end up at a different repo that your friend uses - limit the damage a bad repo can do (particularly by accident, though if you can limit malicious repos too, that's a bonus) To check that a repo is the same, I think you need to have a trusted party tie some sort of canonical name to a repo description. I think the canonical name could be a URL or it could be a shortened hash of the description (like a git commit id); and presumably the trusted third party would be a debian.org registry service. I kind-of like the hash idea since that makes it more difficult to repurpose a repo without changing its id. So I think that adds up to: - Apt will try to download it from a default location in the repository (or perhaps a location specified in the deb822 sources.list file itself). What the heck is it in this sentence? I envision deb822 sources.list file, but reading the location of the file from the file itself seems a bit hard to pull of in practice… I was thinking of having apt auto-update the file which is put there, so that if something changes (e.g., new signatures), we pick that up. To use an external repo, you need a deb822 sources.list file and a pubkey. To get those, you contact extrepos.debian.net, and either do some sort of search, or plug in a 6+ digit hex code. extrepos.debian.net spits back a signed bundle of the repo's public key and a deb822 sources.list (which includes a description of what the repo is meant to contain), both named to match the 6+ digit hex code. The user can then edit the sources.list file as desired (choose a different mirror, set a particular pin priority, ...?) From the POV of someone maintaining an external repo, all you have to do beyond making the packages and setting up the Packages files and signing your work is give it a permanent description and upload the whole thing to extrepos.d.n which will then generate the 6+ digit hex code identifier, sign the set of things, and make it available for download. Updates to the repo work automatically. Updating the key should be straightforward -- sign the new key with the old one and upload to extrepos.d.n. Supporting a cold storage key-signing-key could also work. You'd presumably want to be able to blacklist repos, in case they're taken down, their key is compromised, or they're found to be doing malicious or illegal things. That would mean polling extrepos.d.n, possibly during apt-get update? You might want to go further and let users rate repos; but maybe that could be done externally (eg, on a reddit board or a forum). You probably wouldn't want listing on extrepos.d.n to be taken as any sort of endorsement by Debian (or SPI) though. I'm not suggesting this be part of the base system. It should be part of the desktop task, probably, but that one is large enough already that this shouldn't make much of a difference.
Stetch goal: improvements to testing-proposed-updates / experimental?
Hi, (I'm attempting to bcc: -release, but leave discussion on -devel) Back during the freeze, there was a discussion on -private (Please respect Freeze Policy) about uploading new stuff to unstable (vs experimental or testing-proposed-updates). I'm going to summarise the overall goal as are there any good ways in which unstable can be more pleasant during the freeze for people who want to keep running unstable -- eg, I run unstable so I can keep up with cool upstream stuff, but people stop uploading cool upstream stuff during the freeze. Obviously, in improving things here, it shouldn't make things harder for people working on the release (either the release team or the other developers working on related packages). A few ideas were proposed, including: - RM approval should be required before packages get into testing-proposed-updates, rather than only for the testing-proposed-updates to testing step - uploads to t-p-u should have their bug fix claims checked (ie, that one of the bugs the uploads claims to fix is an RC bug that's present in testing; that all the bugs have already been fixed in an upload to unstable) - testing users should be encouraged to run apt-listbugs and include t-p-u in their sources.list - packages should be able to be migrated from experimental to unstable, rather than requiring a separate upload - during the freeze, uploads to unstable that bump sonames should be held for RM review (or that will otherwise prevent new uploads of other packages to unstable from being suitable for promotion to testing) - add automated testing for t-p-u (piuparts, ci.d.n?) - remove uploads from t-p-u if an RC bug is found in them? Do folks think those things are worth investigating further, and in particular, would ftpmaster and the release team be interested in reviewing/accepting patches along those lines or are there showstoppers with the ideas themselves? I guess the other interesting questions are something like: - are there any obvious ways in which the freeze could be shortened? - are there any obvious ways the freeze brought on earlier, without being lengthened? - are there any obvious ways in which the release team's workload during the freeze can be reduced? I was wondering if maybe it'd be possible to do some sort of statistical review of uploads accepted to testing during the freeze (how many RC bug fixes required more RC bug fixes, how long it took for library transitions to get in sync, etc) and get some ideas for those things. Otherwise, nothing much jumped out at me... Cheers, aj -- Anthony Towns a...@erisian.com.au
Accepted beanbag 1.9.2-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 31 Mar 2015 23:08:59 +1000 Source: beanbag Binary: python-beanbag python3-beanbag python-beanbag-doc Architecture: source all Version: 1.9.2-1 Distribution: unstable Urgency: low Maintainer: Anthony Towns a...@debian.org Changed-By: Anthony Towns a...@debian.org Description: python-beanbag - Helper module for accessing REST APIs python-beanbag-doc - Documentation for Python BeanBag module python3-beanbag - Helper module for accessing REST APIs Changes: beanbag (1.9.2-1) unstable; urgency=low . * New upstream. Various bug fixes and improvements. * Lowers sphinx version in Build-Dep. * Adds python-requests-oauthlib to Suggests. * Switch maintainer email address to @debian.org. Checksums-Sha1: 6a727787d801e04229bbd91b6fa34b12a548b941 2042 beanbag_1.9.2-1.dsc 41eec6f2c5fc99c5401e4e612f524adfc4575379 27016 beanbag_1.9.2.orig.tar.gz eaa2d3267426b5991c9865f589931712c7aa10cf 2072 beanbag_1.9.2-1.debian.tar.xz 4602d1ad628ce8fd7797b359585cf5e01463ee53 11938 python-beanbag_1.9.2-1_all.deb 6fd7d2b8e124e9bf00decea9d66460fc4b1972f4 12044 python3-beanbag_1.9.2-1_all.deb 9eecb8928e6f7b467176b9a78be5352bf5180b6f 37492 python-beanbag-doc_1.9.2-1_all.deb Checksums-Sha256: bdef1096227f76eaa7508793961023a06be2ca1ffcd828a9c74a08292c201dbb 2042 beanbag_1.9.2-1.dsc c6aa1e90ad229a6352e4e5f2d468b9cbf3522d74f7a6ac963e88cba769aaf780 27016 beanbag_1.9.2.orig.tar.gz d114bec03948d719debf88cde02efa1a11c2a7cededf6194767fca85e668a911 2072 beanbag_1.9.2-1.debian.tar.xz ebeed22553aa18a009662e5ac59483bb6954944572716a80eadaab9ed5bdc196 11938 python-beanbag_1.9.2-1_all.deb 76a91a5f67a8324feb38420db7095ef0aa2bbfe1aa485a2acb52c347ba3d4298 12044 python3-beanbag_1.9.2-1_all.deb 184c7e071ae73b0bd400d20e0dd316b8c32cfc96d28784a4ba068a89e13be103 37492 python-beanbag-doc_1.9.2-1_all.deb Files: d324927cd48ae5591f6767ae2a8ffea7 2042 python optional beanbag_1.9.2-1.dsc 47bfccbc3224d1595ae787f994f99720 27016 python optional beanbag_1.9.2.orig.tar.gz 5696c323a561ce154a04340fd37a04cd 2072 python optional beanbag_1.9.2-1.debian.tar.xz 4354414fcce8f8016102ea23fd6953cf 11938 python optional python-beanbag_1.9.2-1_all.deb 77f6299df5c2a7587516de16b47d953b 12044 python optional python3-beanbag_1.9.2-1_all.deb cdea4e9f934390f1ee9e54c148165b80 37492 doc optional python-beanbag-doc_1.9.2-1_all.deb -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJVGp5LAAoJEGF3s1WCqNimdZ8QAJFY+BUUWXOBUQjOHNh8m3M/ r3gIVlI1TUgdBzJsur9ESKMBTTWsAS73ijUqeMlFyVXxk9/RbVtnzwidV2UsqcUu ddAWvwgoHV+tCejcb1468HMx1VJ4FIlaaKZLWJC9+56CTf+v/UnOnuea8GzqhjuS wLx2MAGuN5j6U9jJESNA12a+KkBiy26SGF7hxeHhwqKobJGiuGtfZBHhKyhCdtRO RGLCkd9bxA1ok67sR1LGzBtimBLiWhIODRfWThpj0LeDf7h3/8HtO1YTk3O749BP RQaDBq6b9FEbxegwgDMED/wVkYrLXlddcBUx8ChxAJcqd3he9ckLSrlpyw7REjpm WwPkEbNlVBw0Tdd90WpsAjiIrOrMdaNG5/VDsdESge4l50hUMgtvo1qCD3OPJH4T cXq2glkvubbibr4expAHkdeYaGzE8Fg+aspI3v9kxMG3sNCu20qu3mNp5covcx4O MleIZYZXW3wVD4VYZlspeJYtSgBOjLnARAVWax3xTi4IG6c1Oql2jIgEZvaWwluC Lsl8P4L+/SCxmRQRvn+lFpi93vjxT4D9eYl+YU0kwxiFFb9z8faUmXmm2T6zVNv5 SKfruIRWHeEvLvGwHVHcN+jIr7JhqtI39kfxAH4XEjw0Ua230Dy5ZTjdYjF+aSH1 FnJVlsBkoN4bn0vSG8nD =GXBe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ycwiv-6t...@franck.debian.org
Accepted beanbag 1.9.1-1 (source all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 18 Mar 2015 14:58:56 +1000 Source: beanbag Binary: python-beanbag python3-beanbag python-beanbag-doc Architecture: source all Version: 1.9.1-1 Distribution: unstable Urgency: low Maintainer: Anthony Towns a...@erisian.com.au Changed-By: Anthony Towns a...@erisian.com.au Description: python-beanbag - Helper module for accessing REST APIs python-beanbag-doc - Documentation for Python BeanBag module python3-beanbag - Helper module for accessing REST APIs Closes: 780840 Changes: beanbag (1.9.1-1) unstable; urgency=low . * Initial release (Closes: Bug#780840) Checksums-Sha1: 05699186e4595fb5c61691378420cb8838bbcd82 2045 beanbag_1.9.1-1.dsc 5f20d539ddc6458ca554018f7df48613b527e1d4 22767 beanbag_1.9.1.orig.tar.gz dc32e254448057775ae6f53df7198b51ade917a9 1920 beanbag_1.9.1-1.debian.tar.xz 06e8c59ab6bbbdd5f6c1d0f799cd7072b8a54c80 10786 python-beanbag_1.9.1-1_all.deb 9efb6c16a5d27856eacd74b73f5270909418730a 10878 python3-beanbag_1.9.1-1_all.deb 5deae49ec67660f814456d5a96ae64573df52aa9 33302 python-beanbag-doc_1.9.1-1_all.deb Checksums-Sha256: d2f8a48767e67f5c838970b2e5a14de1936ce64b9d02a3ee819d8d9a0d3a40db 2045 beanbag_1.9.1-1.dsc 3143d6272595c85f809903aea52803e883d7676a042921c01256571c09059d57 22767 beanbag_1.9.1.orig.tar.gz 3feafb8093ba5678635b29a0d4e55c051e9a2c95f4825d6236456dc87690f48e 1920 beanbag_1.9.1-1.debian.tar.xz c8f4dbcc6c64eaeedb5e74c1335e972797cb1a2b6301b312d2ddfb44aebd29ea 10786 python-beanbag_1.9.1-1_all.deb 14e85265a1d90387398fa50bbad2d7e704d517430ce9c37ff86a75ca993b1f25 10878 python3-beanbag_1.9.1-1_all.deb c5ceeedc16380ec763c05c0a2745d6e0fab149977d6803ad10351b522fc5de7c 33302 python-beanbag-doc_1.9.1-1_all.deb Files: 76c8a4181b3916c3268a8f024591d9a4 2045 python optional beanbag_1.9.1-1.dsc 103dbf74aa33047966da1a10c8c1305a 22767 python optional beanbag_1.9.1.orig.tar.gz b4e8c5b02ad80bfff56a6444e1a2829a 1920 python optional beanbag_1.9.1-1.debian.tar.xz a9fd5131c4e35a3eadb280a5ca5c5661 10786 python optional python-beanbag_1.9.1-1_all.deb a173f99c32a3bf40649a9187b27086f9 10878 python optional python3-beanbag_1.9.1-1_all.deb 24d4847ba3aa4b308163bf0202e94023 33302 doc optional python-beanbag-doc_1.9.1-1_all.deb -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJVDBsiAAoJEGF3s1WCqNim/9YP/j0KvC/l7QhMdnb9Ze4l21JO bxKb322bhwX8rh59YlsyQDo9guQcjmoNKzC+2ocseWMplmYHpjFvu1A+7H7NZ4vf BLgOj7sdakh7iAWDorhlI1CJtLxufoJmTd46X+fD14ejIxS01kXH8sQaNxTNFLCr BjKRi4ElGDt0PIf7fWtixwxA72I5odPmgSlOFif/dbpe8nV1CncbRfmQGOFnAHNG 7imn7whHad8Kl8oIhm2TYZdWxO1N5OiRkXf/bqxl3GnQgEVbC3yGhm8rqnLRCTXZ ZE0RH5qz30QS7FqrP0jI4z4EBjj4OP0FJP5byg/PbQxJZbQQK5YfAp/SBwfs2WAi VPhjn8uQTNfvbyvN39vgqU9+oF/xzJUzq0+tKSaX/mliAS2Krb7oOqfRk1jHIb92 DPfIBl/IJ3wulDTZViQRMgxgLbKg5Hod6HeJR0a918Z/Qil/JuzJHqq+i+lf4Qgw 3HFZZZ//25HHVAxWN9mcKbUJ4KuN4t50IxWJE/xDm9dWTybsVTBmn1J1095ijKSN zJ2ExTvlQRX6adWG7vDOusCLh2BDwuqR+slRIyKMC9p1fJNtAgxkpjZYSHwdRBsv olu7QUFJGxbAH+7RDG92uVfpj+VaIaMfKyU+6cndtTmnnJKf2Jp8lhFkrIyqB+Xg RecTPbdgGEHHR0PuBvVs =+NPg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yaniy-0004og...@franck.debian.org
Re: oauth2 sprint at DebConf?
On Thu, Mar 19, 2015 at 01:16:19PM +0100, Vincent Danjean wrote: Le 19/03/2015 10:11, Enrico Zini a écrit : Hello, the oauth2 part of our single signon system is in need of a team of people to maintain it, and my experience so far has been that nobody seems to understand oauth2[1]. After your mail and a quick look in google, I found a overview of oauth2 that seems (at least to me) very interesting and clear, but it is in French. If some can/want to read it: http://www.bubblecode.net/fr/2013/03/10/comprendre-oauth2/ There's a link on that page that says English, clicking it goes to: http://www.bubblecode.net/en/2013/03/10/understanding-oauth2/ I've only skimmed it, but it seems readable... Cheers, aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150321055423.ga18...@master.debian.org
Bug#780840: ITP: python-beanbag -- Helper module for accessing REST APIs
Package: wnpp Severity: wishlist Owner: Anthony Towns a...@erisian.com.au * Package name: python-beanbag Version : 1.9.1 Upstream Author : Anthony Towns a...@erisian.com.au * URL : https://pypi.python.org/pypi/beanbag/ * License : MIT Programming Lang: Python Description : Helper module for accessing REST APIs BeanBag is a simple module that lets you access REST APIs in an easy way. See `http://beanbag.readthedocs.org/` for more information. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150320120715.32662.25496.reportbug@navy
Re: Pre-Depends: init-system-helpers
On Mon, Nov 17, 2014 at 10:10:58AM -0200, Henrique de Moraes Holschuh wrote: On Mon, 17 Nov 2014, Anthony Towns wrote: Having a single tool that does the basic stuff admins and maintainers need independent of init system seems like the right approach to me. *-rc.d is a terrible name for such a tool, though :( Err, yes. There were complains about the -rc.d prefix way back in Debconf2, but the truth is the ship had sailed already (due to update-rc.d). Migrating to a new tool with a less obnoxious name isn't a problem, Heh, isn't a problem seems a bit understated... but this needs to be planned carefully as it is going to span at least two stable releases. And invoke-rc.d and update-rc.d compatibility interfaces will have to be kept around for a *long* time, probably for at least two more stable releases, to avoid breaking things for third-party packages that don't use the LSB compatibility layer. If deb-systemd-* were to get merged in, it might be worth doing a name change at the same time, I guess. Changing either before jessie doesn't seem remotely plausible. I wonder if it would make sense to just merge it all into the service command; ie: # service --use-policy ssh start # service --use-policy ssh restart # service ssh enable # service acpid.socket mask-for-upgrade in place of: # invoke-rc.d ssh start # invoke-rc.d ssh restart # update-rc.d ssh enable # deb-systemd-helper mask acpid.socket I wonder a bit if it wouldn't make even more sense to just make the common command be systemctl, with Debian-specific patches for --use-policy and the various extra behaviours where necessary. Maybe just having a systemctl script with mostly compatible syntax provided for alternative inits would be a better approach. (The disadvantage to that would be that systemctl's a C program, so patching Debian specific options would be harder than with sh/perl scripts like service/deb-systemd-*/*-rc.d) Cheers, aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117143624.ga4...@master.debian.org
Re: Being part of a community and behaving
On Mon, Nov 17, 2014 at 11:05:13AM +0100, Bj??rn Mork wrote: m...@linux.it (Marco d'Itri) writes: On Nov 17, Steve Langasek vor...@debian.org wrote: This is what many still (retorically) wonder about: we the systemd maintainers did not reject that change, https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;bug=746578 Please try to be less selective in your quoting: the issue was still being discussed. I see. So any systemd bug with a 'wontfix' tag is still considered open for discussion? That's good to know. Thanks. Isn't any (open) bug tagged wontfix still open for discussion? If you've got new information, or a new approach that the maintainer might prefer, you can post it to the bug and discuss it with the maintainer... (That said, I didn't see any discussion in that bug from people listed in the systemd Uploaders line other than Michael Biebl's complaint about a systemd-shim bug two months after the wontfix tag was added. That doesn't *look* like it was still being discussed to me. Maybe that just means someone summarising irc/list discussions to the bug would have been helpful) Cheers, aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117144829.gb4...@master.debian.org
Re: Pre-Depends: init-system-helpers
On Mon, Nov 17, 2014 at 02:38:04PM -0200, Henrique de Moraes Holschuh wrote: On Mon, 17 Nov 2014, Anthony Towns wrote: If deb-systemd-* were to get merged in, it might be worth doing a name change at the same time, I guess. Changing either before jessie doesn't seem remotely plausible. I wonder if it would make sense to just merge it all into the service command; ie: # service --use-policy ssh start # service --use-policy ssh restart # service ssh enable # service acpid.socket mask-for-upgrade service is an user interface, while deb-systemd-*, invoke-rc.d, and update-rc.d are first and foremost to be used by a package's maintainer scripts (postinst, etc). They have different design goals. My understanding is that update-rc.d is the recommended way for admins to enable/disable services. Is that incorrect? (It's what I've documented in my proposed init guide/policy) Obvious alternative idea, provide a maintainer script oriented tool under a different name: service-maintscript ssh start service-maintscript ssh enable service-maintscript acpid.socket mask-for-upgrade But if we did that how would we recommend admins enable/disable services? Just use the native stuff (rm /etc/rc?.d/S*ssh; systemctl disable ssh)? IMHO it is best that we keep system interfaces separate from user interfaces like service, Yeah, I see where you're coming from. My intuition goes the other way; that it's better to have a single tool for both uses if that's feasible. We don't have anything special for doing cron jobs via packages compared to what admins might do to add a cron job, eg. Maybe that's a bad intuition though. BTW, it occured to me that it seems like a wart that update-rc.d doesn't respect policy-rc.d -- as it stands, policy-rc.d can prevent a service from (re)starting during install/upgrade, but it'll still start on the next boot. Is that just something that never got thought of / done, or does it actually make sense? Cheers aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117170715.ga13...@master.debian.org
Re: Pre-Depends: init-system-helpers
On Mon, Nov 17, 2014 at 09:22:39AM -0800, Russ Allbery wrote: Anthony Towns a...@erisian.com.au writes: BTW, it occured to me that it seems like a wart that update-rc.d doesn't respect policy-rc.d -- as it stands, policy-rc.d can prevent a service from (re)starting during install/upgrade, but it'll still start on the next boot. Is that just something that never got thought of / done, or does it actually make sense? Consider, for example, bootstrapping a new system in a local chroot that will then be deployed as a virtual image. You want policy-rc.d to prevent starting any daemons from the chroot while you're installing and configuring packages, but you still want all the service management links and policy installed as normal so that, after you turn this into a cloud image, everything will run properly. Thanks, that makes sense. I was thinking more along the lines of: - do the install with policy-rc.d overriding which services are active - once you change your policy (once you've finished bootstrapping), you change or remove policy-rc.d, and continue on your merry way But having update-rc.d obey policy-rc.d would stop that from working right; having /init/ obey policy-rc.d would work fine, but that's just crazy complicated. Followup question: does anyone actually use the detailed features of policy-rc.d or is always used in practice to turn all init scripts off? Cheers, aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117183719.ga2...@master.debian.org
Re: Being part of a community and behaving
On Sun, Nov 16, 2014 at 05:11:47PM -0500, Theodore Ts'o wrote: I would, for example, have classified the discussions / arguments in the systemd-sysv | systemd-shim bug ... I was really confused that this needed to go to the TC; from what I could tell, it had no downside systems using systemd, and it made things better on non-systemd systems. What was the downside of making the change, and why did it have to go to the TC instead of the maintainer simply accepting the patch? Reading through the bug log, I saw the following complaint from Michael biebl (one of the systemd maintainers), dated 6th Sept: Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not going to make it the first alternative. Installing a half-broken logind whould be a disservice to our users. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#27 The next mail in the bug log is Ian referring the bug to the tech ctte on 17th Sept; that was followed by some discussion over the next few days (18th, 19th, 23rd Sept). Ian proposed a resolution to overrule the systemd maintainers on the 1st of Nov, and called for a vote on the 5th of Nov. (For context, the GR vote was called for on the 2nd of Nov with the CFV going out on the 4th; the jessie freeze was announced at the end of the 5th) The bug referenced as [1] above was #756076 which was set as grave on 18th September, with a fix developed upstream on the 5th Nov, which was then uploaded to Debian on the same day (by Martin Pitt): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756076#56 https://github.com/desrt/systemd-shim/commit/a8c45a19a87b8dcd55d451c3dd37e34eca291435 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756076#82 I assume that RC bug was one blocker from the systemd maintainers' POV, but that bug doesn't seem to have been considered by the technical committee in its deliberations at all (at least in so far as Steve as systemd-shim maintainer is distinct from Steve as tech-ctte member). Cheers, aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116233111.ga22...@master.debian.org
Re: Pre-Depends: init-system-helpers
On Sun, Nov 16, 2014 at 01:43:37PM -0800, Steve Langasek wrote: Can someone of the systemd maintainers please explain why this is being done as a separate helper instead of integrating with the tools that are already defined in policy and already part of the base system (e.g., invoke-rc.d)? I think deb-systemd-invoke ~= invoke-rc.d deb-systemd-helper ~= update-rc.d deb-systemd-helper supports more options than update-rc.d (is-enabled, was-enabled, debian-installed, update-state, reenable, mask, and unmask in addition to enable and disable; and purge in place of remove), though. update-rc.d already supports enabling and disabling .service units. Adding the ability to specify foo.socket as well as having foo for foo.service seems straightfoward, and adding the additional actions needed to cope with upgrading services that could be restarted by dbus/etc during upgrade likewise seems sane. invoke-rc.d also works with .service units already; extending it to take over deb-systemd-invoke also seems like it would be straightforward. Having a single tool that does the basic stuff admins and maintainers need independent of init system seems like the right approach to me. *-rc.d is a terrible name for such a tool, though :( https://github.com/ajtowns/debian-init-policy While this policy mentions deb-systemd-helper, there's no explanation of when or why it should be used. 2.2.4 Maintainer scripts mentions when and why... Patches welcome if more explanataion is needed... Cheers, aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117002546.ga5...@master.debian.org
Re: libpam-systemd [Re: Being part of a community and behaving]
On Sun, Nov 16, 2014 at 03:52:39PM -0800, Don Armstrong wrote: On Sun, 16 Nov 2014, Anthony Towns wrote: I assume that RC bug was one blocker from the systemd maintainers' POV, but that bug doesn't seem to have been considered by the technical committee in its deliberations at all (at least in so far as Steve as systemd-shim maintainer is distinct from Steve as tech-ctte member). We actually discussed this in the bug log.[1] I was presuming Steve was speaking with his systemd-shim maintainer hat on for that email. Filing an RC bug doesn't help users of unstable, only users of testing (and hence stable); the systemd maintainers may have wanted to protect systemd users tracking unstable from systemd-shim breakage. I didn't see any evidence that they thought marking that bug as RC addressed their concerns. An RC bug against systemd-shim is the appropriate technical means of making sure that a buggy systemd-shim is not allowed into the release. That's true in theory; in practice, systemd-shim wasn't removed from testing despite having a grave bug in the month leading up to the freeze, so anyone running unstable or testing would still have been hit by the bug until the fix made it through. If the bug hadn't been fixed and the release team tried removing systemd-shim from jessie, I'd presume the tech ctte would've overruled the RC-ness of the bug anyway. Cheers, aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117004204.gb5...@master.debian.org
Re: Please more fish (was: so long and thanks for all the fish)
Hey Joey, On Sun, Nov 09, 2014 at 06:12:13PM -0400, Joey Hess wrote: Please take that message with a pound of salt. I was upset when I wrote it, it's probably not accurate, and I've left[1] for reasons that are much more broadly structural, and are certianly not the fault of the technical committee, or indeed of any one person. I wonder if you could describe what you think made Debian of '96 awesome? I miss reading inspiring manifestos of how things are meant to work in a hypothetical perfect world that makes everyone happy. (For me, I'd say what was cool about Debian back in that day was it was an anarchic collaboration that's doing cool, useful things with software. When I think about it, I usually conclude that Debian still wins because everything else interesting seems way more structured (ie, either corporate or benevolent dictator), but maybe if I like anarchic then the collaboration should be more ad-hoc anyway, and existing structures aren't relevant...) [1] Almost. Still need to orphan git-annex, git-repair, and github-backup. #768516: (O: etckeeper -- store /etc in git, mercurial, bzr or darcs) Planning on staying involved with those as upstream? FWIW, you might want to consider retaining your DDship despite orphaning everything, dropping any roles, unsubscribing from any mailing lists, seceding from the constitution, etc. There's not much obligation in keeping the account, and if you find yourself using some package that needs a bug fix, being able to do an NMU is handy (presuming you're not switching to a different distro, anyway). At least, I haven't had anyone begrudge me keeping my account while not doing anything much. (Also, can we contact your ego or superego directly via email too?) Cheers, aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110140124.ga9...@master.debian.org
Accepted gitit 0.10.4-2 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Wed, 01 Oct 2014 06:39:58 +1000
Source: gitit
Binary: gitit libghc-gitit-dev libghc-gitit-prof libghc-gitit-doc
Architecture: source all amd64
Version: 0.10.4-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Haskell Group
pkg-haskell-maintain...@lists.alioth.debian.org
Changed-By: Anthony Towns a...@debian.org
Description:
gitit - Wiki engine backed by a git or darcs filestore
libghc-gitit-dev - Wiki engine backed by a git or darcs
filestore${haskell:ShortBlur
libghc-gitit-doc - Wiki engine backed by a git or darcs
filestore${haskell:ShortBlur
libghc-gitit-prof - Wiki engine backed by a git or darcs
filestore${haskell:ShortBlur
Closes: 736189
Changes:
gitit (0.10.4-2) unstable; urgency=medium
.
* Add source files for minified JQuery (Closes: Bug#736189).
* Add lintian override for JQuery sources.
Checksums-Sha1:
8098c663f8a59e81355281983600c3915abcc663 5217 gitit_0.10.4-2.dsc
aa3fbaf938c6ce682a20727d6a64b6665bf8 51080 gitit_0.10.4-2.debian.tar.xz
1cb5b78e2c482c0a9a6267571ef1d0c29638dd22 155272
libghc-gitit-doc_0.10.4-2_all.deb
07dac1607cba46965063374fd9a9d585f53df8b1 9098422 gitit_0.10.4-2_amd64.deb
27100cfd29305a9f5b52e067d775f61a91cbd998 739714
libghc-gitit-dev_0.10.4-2_amd64.deb
eb21a854aa4ccfbf38bcd818855c4369abdde99f 1480978
libghc-gitit-prof_0.10.4-2_amd64.deb
Checksums-Sha256:
f4c53cec31f862c6665878209457afac6128134d2e529a699f387f41ce3a517d 5217
gitit_0.10.4-2.dsc
a91592524cec8c3e4bb6a80bbb84baea026395e54ea96d5a53f6c43ad4cf5e47 51080
gitit_0.10.4-2.debian.tar.xz
5fe79089611e851a41f1238003e95ae65fc424e70c3c4bafabfb3aff190367b2 155272
libghc-gitit-doc_0.10.4-2_all.deb
fb7bdda5af31a18f87e52fdd375123f18736e092dc5daf3c820a7be89f26e688 9098422
gitit_0.10.4-2_amd64.deb
b162c43b5cf50653f5413f3dabed5a17e115a9df7d28397eb199c1c7d1f0b01f 739714
libghc-gitit-dev_0.10.4-2_amd64.deb
7cf345f2bfb21784c3c704adc755c9ed3c98398541ccf01b88982e5f0ca722a6 1480978
libghc-gitit-prof_0.10.4-2_amd64.deb
Files:
c177648baefa2661caff046acb5715bc 155272 doc extra
libghc-gitit-doc_0.10.4-2_all.deb
c02cd0dd583925cac19a1eb876eb4aee 9098422 haskell extra gitit_0.10.4-2_amd64.deb
5bbd6fee07c4ed184c1e8b452f3aecda 739714 haskell extra
libghc-gitit-dev_0.10.4-2_amd64.deb
6a6f09fe68497fda6924735a1c2aab7d 1480978 haskell extra
libghc-gitit-prof_0.10.4-2_amd64.deb
3c13e91d9df84ddc6e27586252c683d1 5217 haskell extra gitit_0.10.4-2.dsc
a9d41da5588c9b0fbf69e435519d35c9 51080 haskell extra
gitit_0.10.4-2.debian.tar.xz
-BEGIN PGP SIGNATURE-
iQIcBAEBCAAGBQJULGvLAAoJEGF3s1WCqNimsHsP/01umtEqhbe++OJuyc2fDREc
Ry/nPWF4wQ8kW/TMNm22fU49xAFN8onwUmyS0i8brlcwe126u3vaPF2PmvGCPfzC
bLNKb1payCEmGcw4wAf/FvgMKLHfyxEb51Ryl2T+bWaukB95LWoGjOwu1HCkwBqv
z1LaOnHBRW1jFRkC3e2CC+LFh3TfMZEPWbsCVXsstVvBApxWUhsK9FvAoDiQRr3C
BVuAmnL4VNrH4WfwZyUMdCyEvCulE6qr0xuuWj7RWP1qN4XEoO+xd/hggWlE8Ibn
FwWXj+PPG7WPbDzerW7WbgpwP6qu1pTSmM6xJ1Yo2SeMVyWlvMwOynXQzTA23mUX
3L0igqsl4725+6dDThe1ifhmuSxYeV8ZpG3a9yTDdOEtXMvztrJsjGcOKj7RJY3Z
CnVf8e40hbWPjJ03ZlHkaA915LGTk/hlOGqL+0ctw4RoFClyfTOZoINeFig9/V2c
1AFSUfT0r7IcUsTBWJpFKSfKxajKlTSOv1seNtvvHPu1XCX5ISS51CKuvoJKzRGe
1z8YqQbF8bcwfq9OtKCLG0LeBmrP6HxOfDN7UDkjAYTmDvHEX0UJyM/HYhxJu9Ck
2jhHeZVgLredcdH1Fes0DGz7dzT/EFEyYoUIqwb0cotUjU4QPoK5O/2VVVhwNEwV
v6j+Emp4a2cgVnWVxNWG
=UM1I
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xzrkx-bo...@franck.debian.org
Re: Better pdiff handling for apt
On Fri, Jan 17, 2014 at 04:13:34PM +0100, David Kalnischkies wrote: On Sat, Jan 04, 2014 at 07:34:07PM +0100, David Kalnischkies wrote: So, I guess merging both could cross a lot of points of your list and be relatively easily feed into unstable for proper field-testing. (a upload of my part was planed as a christmas present to experimental, but as usual: If you want to make deity laugh, tell her your plans) I just did this merging the other day and Michael pushed it to experimental (again), so everyone should feel free to give it a spin, you might be in for a pleasant surprise ??? depending on how much you trusted the benchmark in my previous mail. [technical, it was indeed as easy as using my POC and Anthonys rred and put some minor glue between them ??? very nice :D ] Very nice indeed. There's an extra patch at https://github.com/ajtowns/apt/commits/better-pdiffs-dk that makes a couple of minor cleanups in rred.cc. I think there's a few more to do, but I got confused as to how the pkgAcqIndexMergeDiffs stuff works, and will need to print that out to grok it, I expect... Breakage potential: I decided for now to enable client-side merge by default but with detection for the X-Patch-Precedence field reprepro has introduced?? if it has merged patches on the server side, which falls back to the old handling. Ah, nice, that seems like it should make it backwards compatible in practice. It looks to me like dak and reprepro are the only tools that generate pdiffs currently, fwiw. Cheers, aj -- 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/20140120192156.ga27...@master.debian.org
Better pdiff handling for apt
Salut tout le monde, Some time ago (*cough* 2009), I had a play with working out how to apply pdiffs more efficiently than apt currently does, and implemented a proof of concept in python [0]. There weren't any replies (even a ooo, cool) when I posted to the deity list, so I left it at that; though trolling google now, I see that it got mentioned on -devel [1] not all that long ago (*cough* 2012), so apparently it did get read after all. Not that it looks like it would've done much good, because it seems like the script I put on the web, and the one I was actually using are completely different to the extent that the one on the web even has syntax errors. WTF? Anyhoo... Like many, I've been getting annoyed at how tedious pdiff application is over the past year, so over Christmas I thought I'd have a go at patching apt to do things properly. I've got it to the point where it works now, and apt-get update reports things like: Fetched 199 MB in 50s (3919 kB/s) over a 50kB/s link when updating testing+unstable for i386+amd64 for a day's worth of changes, rather than reporting 7000 B/s over a megabit link. It should also be much more pleasant on SSDs, since it only attempts to write each diff twice (once compressed, once uncompressed), and each packages file once; rather than writing each diff once, and the Packages file once for each diff. My patched apt source is up on github at: https://github.com/ajtowns/apt/tree/better-pdiffs My current theory is that it's best to re-specify the .diff/Index format by adding an additional header Patch-Step-Size: 1 1 4 3 2 1 1 which would indicate that there are six patches available, and that if you start from the oldest known version, you should apply patch 1, then patch 2 (patch 1 + 1), then patch 3 (patch 2 + 1), then patch 7 (patch 3 + 4), and then you're done (patch 7 + 1 == patch 8, which doesn't exist). If you wanted to run an archive where you only had to download one patch and apply it no matter how old your Packages file was, the line would look like: Patch-Step-Size: 12 11 10 9 8 7 6 5 4 3 2 1 (I think a nice efficient compromise method would be Patch-Step-Size: 8 8 4 4 4 4 2 2 1, which would only update a lg(diffs) each time you updated the packages file, and only require users to download and apply a maximum of lg(diffs) to get up to date) If the line's not present, it should be treated as: Patch-Step-Size: 1 1 1 1 1 1 1 ... which would be compatible with the way Debian does things, but presumably not with some derivatives. Anyway, the code works adequately as a proof of concept and I don't think it should need a major re-write, but the things I think still need doing to it are: * make sure main sha256/sha512/etc hashes are being checked after patches are applied * verify that diff sha1 hashes are being checked on download * don't keep diffs around after they've been applied * add support for Patch-Step-Size as above * more robust parsing of diff files in rred method * review code paths in acquire-item to make sure they're sane * fix up debug message for rred method and diff acquire-item classes * consider just reading the gzipped diffs directly rather than uncompressing them * check that the http downloads are being done as efficiently as possible (?) * consider leaving the diffs in partial/ * allow resuming downloading diffs, rather than always redownloading them from scratch * add an option to only allow diffs up to a fixed total size for embedded systems (since the diffs are loaded into memory as a whole before being applied) * add/update test suite? * fix up any code style issues * fix up rred method so it can be used directly from the command line to merge and apply ed-diffs * work out where ed diffs get generated these days, and provide patch to generate Patch-Step-Size header, and optionally use rred method to update patches to make it a bit easier to download stuff If anyone wants to poke around, please do! Cheers, aj [0] https://lists.debian.org/deity/2009/08/msg00169.html [1] https://lists.debian.org/debian-devel/2012/02/msg00411.html -- Anthony Towns a...@erisian.com.au -- 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/cajs_lcvjtdczrc7nneappeffv0kjwls3iq9s+xe9x1__dgm...@mail.gmail.com
Top level directory /run added to Fedora/Suse
Hi, Via LWN I see: I just uploaded a new version of systemd into F15, which establishes a directory /run in the root directory. ... In the past weeks key people from the Debian, Suse, Ubuntu and Fedora camps (and others, too) discussed the whole issue forth and back, ... ... With this upload Fedora and Suse have already adopted /run now. Debian folks will suggest this for their coming release. Ubuntu has agreed with introducing /run as well. -- http://lwn.net/Articles/436012/ I hadn't seen any hint of this up 'til now, and with a quick peruse couldn't find any posts. Are there any? If so, any urls? Anyway, I'd like to give a +1000 to this, and offer my thanks to the nameless Debianites who've pushed this forward. And hey, can we nominate the Debian/Suse/Ubuntu/Fedora cabal^Wrepresentatives who've already made such progress as the new FHS maintainers while we're at it? :) Cheers, aj -- Anthony Towns a...@erisian.com.au
Some stats...
Hey *, I did a blog post last night with some (IMO) interesting stats. If you're interested, the post is at: http://www.erisian.com.au/wordpress/2010/08/02/some-lenny-development-cycle-stats It's based on some dynamic javascripty charts of various numbers I could pull out that seemed interesting (RC bugs, the buildd graphs, and an LD50 one I made up). The source graphs are up on merkel and are kinda interesting; the only issue is the graphs are drawn on the client side which given the amount of data involved can be a bit slow on iceweasel; chromium-browser from unstable or google-chrome seems to handle it alright though. URLs: http://merkel.debian.org/~ajt/plots/counts.html -- RC bugs http://merkel.debian.org/~ajt/plots/ld50.html -- how long it takes to fix bugs (weekly data points) http://merkel.debian.org/~ajt/plots/buildd-1.html -- architecture buildd performances http://merkel.debian.org/~ajt/plots/buildd-2.html -- architecture up-to-dateness The box at the bottom right lets you do a rolling average, and you can click and drag to choose a particular date range to view. I haven't set it up to automatically update yet. Cheers, aj -- Anthony Towns a...@erisian.com.au -- 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/aanlkti=ehe=tapjwl+kkyetjmzy7_ybgfquetzoak...@mail.gmail.com
Re: Bug#540215: Introduce dh_checksums
Hey Russ, On Tue, Mar 9, 2010 at 13:57, Russ Allbery r...@debian.org wrote: Joey Hess jo...@debian.org writes: Russ Allbery wrote: It's also always worth bearing in mind that while a really good attacker can do all sorts of complex things that make them very hard to find, most attackers are stupid and straightforward. It's stupid and straightforward to install /usr/local/bin/ls. debsums will not detect it. True. Adding new binaries is, in my experience, more common than modifying binaries already on the system. I don't really mean to be arguing for debsums as a security mechanism, more just commenting on the general question. So what's the goal here? Basic integrity checking by defending against random corruption due to occassional hardware, software or admin errors? Or an additional security layer verifying that the installed system software is still exactly what it was intended to be? (Or, I guess, a third option would be that it's just some security theatre to make people feel more comfortable about their system's integrity, without actually adding any technical guarantees.) For basic integrity checking, I'm finding the dpkg patch I posted the other day works fairly nicely -- I've reinstalled the handful of packages that don't provide md5sums files so dpkg would generate the hashes file for me, and now I've got hashes for every package on my system, without having to worry about policy getting changed or packages getting reuploaded, or having to worry about bugs like any random packages I might use not following the new policy. And now that I actually look at debsums, rather than just checking with md5sum -c directly, I see debsums already gets invoked by apt by default to ensure that there's an md5sums file for every package. And that's been there for a fair while, based on Bug#132767. If the idea is just to catch a wide swathe of accidental errors, doesn't it make sense to stick with md5 as being cheap and unlikely to have accidental collisions, do the md5sum generation in either apt or dpkg to guarantee it's done for all installed packages, and leave it at that? That means we could get rid of a bunch of policy and code from package build scripts, which seems like it could only be a good thing; and it also seems pretty easy to do for squeeze (since it's already done as far as apt is concerned, and there's a patch for dpkg if desired, and no other packages need to be changed). The only drawback seems to be that you end up verifying what was actually installed, and that might differ from verifying what was meant to be installed in the event that the deb you're installing gets corrupted while you're reading it, despite having previously passing its own secure hash check. OTOH, if the idea is to do more than just basic integrity checking of dpkg-installed files, to aid in detection of and recovery from malicious/deliberate changes, it seems like there's a lot of things that ought to be done differently to how debsums/pkg.md5sums work (secure hash, checking conffiles, stuff in /var, checking added files, checking additional diversions, preventing addition/deletion/modification of the md5sums files...). (Well, better handling of the md5sums files themselves could be useful for basic integrity checking too -- a disk/fs error that trashes files in /var/lib/dpkg/info/ can be inconvenient too) Cheers, aj -- Anthony Towns a...@erisian.com.au -- 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/87b3a4191003091145p26467cag8d2d4cfb9dc20...@mail.gmail.com
Re: md5sums files
(I'm not subscribed to this list, so go ahead and Cc me)
On Thu, Mar 4, 2010 at 02:05, Peter Samuelson pe...@p12n.org wrote:
[Wouter Verhelst]
I must say I was somewhat surprised by these numbers. Out of 2483
packages installed on my laptop, 2340 install md5sums.
The surprising part, perhaps, is that dpkg itself didn't just generate
the other 143 md5sums files at installation time.
The easy (and usually correct) reason for things like that is dpkg's
source is scary.
I suggested this a long time ago and of course was met with so where's
your patch? Of course I was not willing to do the work.
See? Anyway, my patch is attached. It makes dpkg create a foo.hashes
when unpacking foo, whose contents looks like:
MD5:32b5e22f8e336b2f34e0dd87652e6dfc usr/share/doc/mawk/changelog.gz
MD5:87a34f1f55ac3f7fec2c7fc82565e8eb usr/share/doc/mawk/changelog.Debian.gz
...
Verification is a matter of something like:
$ cat /var/lib/dpkg/info/*.hashes | sed -n 's/^MD5://p' | (cd /;
md5sum -c) | grep -v ': OK$'
There's an option (--hash) that you can set to none to avoid
spending time calculating md5s if you so choose. Adding support for
sha1/sha256/whatever should be straightforward; afaik dpkg only has
code for md5 already built in though (though just invoking
/usr/bin/sha1sum etc would be an option of course).
Of course another option is just to pull the md5sums directly from the deb:
$ ar p /var/cache/apt/archives/ifupdown_0.6.9_i386.deb data.tar.gz |
tar --to-command='printf %s%s\n $(md5sum - | sed s/-$//)
${TAR_FILENAME#./}' -xzf - |
diff - /var/lib/dpkg/info/ifupdown.md5sums
1,3d0
346208729633adf45e2fa3f2bd3b19c6 etc/init.d/ifupdown
c6fffaae03271f1641920105ce68796b etc/init.d/ifupdown-clean
fab851ca87c5deb9d6f665e610184648 etc/default/ifupdown
4a2
a0f11cf1809a468c49b72e0aa0a8e26b sbin/ifup
(md5sums doesn't normally list conffiles, but does list hardlinks; the
above command does the opposite)
But
fundamentally, shipping a md5sums file is really just a tradeoff in
download size vs. installation speed, not unlike gzip vs. bzip2.
Advantages of doing in when unpacking:
- choice of checksum is the admin's decision
- we can quickly roll out support for sha1/sha256/crc/... checksums
by just changing one package
- admin has hashes of exactly what was unpacked, no matter the source
- no concerns about bugs in dh_md5sums or similar resulting in bad checksums
Advantages of doing it when uploading:
- provides some sort of double check of what's being uploaded
- saves CPU time on users' machines
For me, I'd rather have dpkg generate the hashes.
Cheers,
aj
--
Anthony Towns a...@erisian.com.au
diff -urb dpkg-1.15.5.6/debian/changelog dpkg-1.15.5.6-aj/debian/changelog
--- dpkg-1.15.5.6/debian/changelog 2010-01-09 04:02:03.0 +1000
+++ dpkg-1.15.5.6-aj/debian/changelog 2010-03-07 04:13:03.171356041 +1000
@@ -1,3 +1,11 @@
+dpkg (1.15.5.6+aj) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Automatically create /var/lib/dpkg/info/pkg.hashes containing MD5 hashes
+for unpacked files.
+
+ -- Anthony Towns a...@lazuline Sun, 07 Mar 2010 04:12:32 +1000
+
dpkg (1.15.5.6) unstable; urgency=low
* dpkg-source: with format 3.0 (quilt) ensure quilt's .pc directory is
diff -urb dpkg-1.15.5.6/configure.ac dpkg-1.15.5.6-aj/configure.ac
--- dpkg-1.15.5.6/configure.ac 2010-01-08 18:00:34.0 +1000
+++ dpkg-1.15.5.6-aj/configure.ac 2010-03-07 04:38:32.547372468 +1000
@@ -51,6 +51,16 @@
esac])
AC_SUBST(admindir)
+# Allow alternative default hash function
+hashtype=md5
+AC_ARG_WITH(hashtype,
+ AS_HELP_STRING([--with-hashtype=HASH],
+ [hash function to use for .hashes files]),
+[case $with_hashtype in
+ md5|none) hashtype=$with_hashtype ;;
+ *) AC_MSG_ERROR([invalid hashtype specified]) ;;
+esac])
+AC_SUBST(hashtype)
# Checks for programs.
AC_PROG_CC
diff -urb dpkg-1.15.5.6/src/Makefile.am dpkg-1.15.5.6-aj/src/Makefile.am
--- dpkg-1.15.5.6/src/Makefile.am 2010-01-09 03:23:06.0 +1000
+++ dpkg-1.15.5.6-aj/src/Makefile.am 2010-03-07 04:28:18.771356095 +1000
@@ -6,6 +6,7 @@
AM_CPPFLAGS = \
-DLOCALEDIR=\$(localedir)\ \
-DADMINDIR=\$(admindir)\ \
+ -DHASHTYPE=\$(hashtype)\ \
-idirafter $(top_srcdir)/lib/compat \
-I$(top_builddir) \
-I$(top_srcdir)/lib
diff -urb dpkg-1.15.5.6/src/main.c dpkg-1.15.5.6-aj/src/main.c
--- dpkg-1.15.5.6/src/main.c 2010-01-09 03:23:06.0 +1000
+++ dpkg-1.15.5.6-aj/src/main.c 2010-03-07 04:29:59.271360858 +1000
@@ -187,6 +187,7 @@
const char *admindir= ADMINDIR;
const char *instdir= ;
struct pkg_list *ignoredependss = NULL;
+const char *hashtype= HASHTYPE;
static const struct forceinfo {
const char *name;
@@ -516,6 +517,7 @@
{ admindir, 0, 1, NULL, admindir, NULL, 0 },
{ instdir, 0, 1, NULL, instdir, NULL, 0 },
{ ignore-depends,0, 1, NULL, NULL, ignoredepends, 0 },
+ { hash, 0, 1, NULL
Re: md5sums files
On Sun, Mar 7, 2010 at 10:28, Goswin von Brederlow goswin-...@web.de wrote:
Anthony Towns a...@erisian.com.au writes:
Advantages of doing it when uploading:
- provides some sort of double check of what's being uploaded
- saves CPU time on users' machines
- avoids having bad checksums due to the user having bad hardware
(which is one big use case of the files)
Big? It only makes a difference if:
a) the corruption happens as soon as it's written, not after some time
b) the file is too big/the system is too loaded to keep the file in
the page cache
c) the system memory is corrupted just enough to screw the file but
not everything else
Compared to random make install invocations changing files in the
system and similar, that doesn't strike me as a big use case.
In any event, it's fairly easy to generate the checksum in the same
pass as generating the file, see the attached patch. (It's not as easy
to generalise to other hashes as the previous one, unfortunately)
If you're still worried, perhaps about having read() return bogus data
from the .deb that happens to still be valid when passed through
ungzip and untar and after you've already verified the entire file by
md5/sha1/sha256 when downloading, you're getting to the point of
trying to safely install on an actively malicious system, and
nothing's going to make that work.
Cheers,
aj
--
Anthony Towns a...@erisian.com.au
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/configure.ac dpkg-1.15.5.6-aj/configure.ac
--- dpkg-1.15.5.6/configure.ac 2010-01-08 18:00:34.0 +1000
+++ dpkg-1.15.5.6-aj/configure.ac 2010-03-07 04:38:32.547372468 +1000
@@ -51,6 +51,16 @@
esac])
AC_SUBST(admindir)
+# Allow alternative default hash function
+hashtype=md5
+AC_ARG_WITH(hashtype,
+ AS_HELP_STRING([--with-hashtype=HASH],
+ [hash function to use for .hashes files]),
+[case $with_hashtype in
+ md5|none) hashtype=$with_hashtype ;;
+ *) AC_MSG_ERROR([invalid hashtype specified]) ;;
+esac])
+AC_SUBST(hashtype)
# Checks for programs.
AC_PROG_CC
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/debian/changelog dpkg-1.15.5.6-aj/debian/changelog
--- dpkg-1.15.5.6/debian/changelog 2010-01-09 04:02:03.0 +1000
+++ dpkg-1.15.5.6-aj/debian/changelog 2010-03-07 04:13:03.171356041 +1000
@@ -1,3 +1,11 @@
+dpkg (1.15.5.6+aj) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Automatically create /var/lib/dpkg/info/pkg.hashes containing MD5 hashes
+for unpacked files.
+
+ -- Anthony Towns a...@lazuline Sun, 07 Mar 2010 04:12:32 +1000
+
dpkg (1.15.5.6) unstable; urgency=low
* dpkg-source: with format 3.0 (quilt) ensure quilt's .pc directory is
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/lib/dpkg/buffer.c dpkg-1.15.5.6-aj/lib/dpkg/buffer.c
--- dpkg-1.15.5.6/lib/dpkg/buffer.c 2010-01-09 03:23:06.0 +1000
+++ dpkg-1.15.5.6-aj/lib/dpkg/buffer.c 2010-03-07 15:50:33.379710844 +1000
@@ -60,6 +60,13 @@
case BUFFER_WRITE_MD5:
buffer_md5_init(write_data);
break;
+ case BUFFER_WRITE_DUP:
+ {
+ struct buffer_data *bddup = write_data-arg.ptr;
+ buffer_init(NULL, bddup[0]);
+ buffer_init(NULL, bddup[1]);
+ }
+ break;
}
return 0;
}
@@ -90,6 +97,13 @@
case BUFFER_WRITE_MD5:
buffer_md5_done(write_data);
break;
+ case BUFFER_WRITE_DUP:
+ {
+ struct buffer_data *bddup = write_data-arg.ptr;
+ buffer_done(NULL, bddup[0]);
+ buffer_done(NULL, bddup[1]);
+ }
+ break;
}
return 0;
}
@@ -126,6 +140,14 @@
case BUFFER_WRITE_MD5:
MD5Updatestruct buffer_write_md5ctx *)data-arg.ptr)-ctx), buf, length);
break;
+ case BUFFER_WRITE_DUP:
+ {
+ struct buffer_data *bddup = data-arg.ptr;
+ ret = buffer_write(bddup[0], buf, length, desc);
+ if (ret != length) return ret;
+ ret = buffer_write(bddup[1], buf, length, desc);
+ }
+ break;
default:
internerr(unknown data type '%i' in buffer_write,
data-type);
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/lib/dpkg/buffer.h dpkg-1.15.5.6-aj/lib/dpkg/buffer.h
--- dpkg-1.15.5.6/lib/dpkg/buffer.h 2010-01-08 18:00:34.0 +1000
+++ dpkg-1.15.5.6-aj/lib/dpkg/buffer.h 2010-03-07 15:53:23.319707965 +1000
@@ -36,6 +36,7 @@
#define BUFFER_WRITE_NULL 3
#define BUFFER_WRITE_STREAM 4
#define BUFFER_WRITE_MD5 5
+#define BUFFER_WRITE_DUP 6
#define BUFFER_READ_FD 0
#define BUFFER_READ_STREAM 1
@@ -52,6 +53,14 @@
buffer_hash(buf, hash, BUFFER_WRITE_MD5, limit)
#if HAVE_C99
+# define fd_fdmd5(fd1, fd2, hash, limit, ...) \
+ do { \
+ struct buffer_data fdhash[2]; \
+fdhash[0].arg.i = fd2; fdhash[0].type = BUFFER_WRITE_FD; \
+fdhash[1].arg.ptr = hash; fdhash[1].type = BUFFER_WRITE_MD5; \
+buffer_copy_IntPtr(fd1, BUFFER_READ_FD, fdhash, BUFFER_WRITE_DUP, \
+ limit, __VA_ARGS__); \
+} while(0)
# define fd_md5(fd, hash, limit
Re: Bits from the release team and request for discussion
On Fri, Jul 31, 2009 at 05:39:23AM +1000, Anthony Towns wrote: On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote: About freeze timing we think that DebConf should definitely not fall into a freeze We noticed that releases in the first quarter of the year worked out quite well in the past like both Etch and Lenny. Taking these into consideration we think it would be best to freeze in December. We'll be consulting all key teams within Debian to see how their plans and schedules can fit into a new timeline. Before the end of August we hope to have finished this process of consultation and be able to present the new plan to you. Why not have a developer poll as to what month(s) would most suit people for the freeze, rather than limiting it to key teams? So, with August almost half-way over, I guess the release team's not going to be doing much more to seek input from non-key teams/developers. I still think it'd be interesting and useful to get broader input, though. Something like a choice amongst the following questions by GR might work: 1. The Debian project recommends that the release team target December 2009 for squeeze's freeze, and work hard to avoid allowing the freeze to slip by more than a few weeks. The project notes this is approximately 10 months after lenny's release, and approximately 18 months after lenny's freeze. The project acknowledges this may assist in synchronising Debian 6.0 and Ubuntu 10.04 LTS, may assist in setting up regular freezes every second December, and is intended to allow Debian 6.0 to be released prior to DebConf 2010. 2. The Debian project recommends that the release team target January-February 2010 for squeeze's freeze, following a December release summit with maintainers/upstreams for major packages to allow some new upstream releases that occur early in the freeze to be included. The project acknowledges this may assist in synchronising Debian 6.0 and Ubuntu 10.04 LTS, and may assist in setting up regular freezes every second year. The project notes this may or may not allow Debian 6.0 to be released prior to DebConf 2010. 3. The Debian project recommends that the release team target March/April 2010 for squeeze's freeze. The project acknowledges this will likely mean the freeze will be active during DebConf 10. 4. The Debian project recommends that the release team target May-July 2010 for squeeze's freeze. The project notes that this is approximately two years after lenny's freeze, and acknowledges this will mean the freeze will be active during DebConf 10. 5. The Debian project recommends that the release team target October-December 2010 for squeeze's freeze. The project notes that this will be after DebConf 10 has finished, and between 20-22 months after lenny's release. The project acknowledges that depending on the length of the freeze, this may mean squeeze will be released more than two years after lenny. Any thoughts? We could have such a vote over and done in about two weeks, with the DPL's consent, and it'd seem a lot more inclusive and less cabal-tastic than how things seem to be working atm... Cheers, aj signature.asc Description: Digital signature
Re: Bits from the release team and request for discussion
On Tue, Aug 04, 2009 at 01:09:14PM +0200, Philipp Kern wrote:
I'm grateful for those suggestions, Anthony. That page is just a pain
to maintain though. Not everything on it is up-to-date yet but I updated
quite some chunks.
So make it easy to maintain... Attached is an example converting it to
yaml with python table generation, coping with waivers.
I've made it automatically classify any arch with any failures as at risk,
rather than letting it remain listed as a candidate. It'd probably be better
to have any warnings imply at risk and any failures come pretty close to
meaning no, though...
Anyway, have a look, see what you think.
It'd be really nice to have all the buildd criteria be measurable (and then
automated). One idea might be to change fast security and redundancy into
speed/load measures, something like:
alpha amd64 armels390
buildd-speed 95%100% 50%113%
(%ge of i386/amd64)
buildd-load 55% 60% 95% 20%
n-buildds 2 3 6 1
idle-buildds 0.9 1.2 0.3 0.8
where speed is calculated as the overall average of:
time-to-build-on-$ARCH / time-to-build-on-i386/amd64
(ie, dpkg takes 20s to build on alpha, versus 13s to build on i386 after
and amd64+source upload would give 154%)
load is the percentage of time on average that each buildd is actually
building something, and idle-buildds is n-buildds * (1 - buildd-load).
Release criteria are then something like buildd-speed = 50%,
idle-buildds = 1.
Cheers,
aj
#!/usr/bin/env python
# Copyright (c) 2009 Anthony Towns
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
import sys, yaml
### formatting helpers
def FAIL(value): return (red,value)
def WARN(value): return (yellow,value)
def PASS(value): return (lime,value)
def c_truth(value):
if value == True:
return PASS(yes)
elif value == False:
return FAIL(no)
else:
return WARN(value)
def c_untruth(value):
if value == True:
return FAIL(yes)
elif value == False:
return PASS(no)
else:
return WARN(value)
def c_host(value):
if not value: return FAIL(none)
return PASS('a href=http://db.debian.org/machines.cgi?host=%s;yes/a'%(value))
def c_list(maybe,okay):
def c_list_f(value):
n=len(value)
str='acronym title=%s%s/acronym' % (, .join(value),n)
if n maybe: return FAIL(str)
if n = okay: return PASS(str)
return WARN(str)
return c_list_f
def c_num(maybe,okay):
def c_list_f(value):
if value maybe: return FAIL(value)
if value = okay: return PASS(value)
return WARN(value)
return c_list_f
def c_str(value):
if not value: return FAIL(-)
return PASS(value)
# criteria
criteria = [
(available, c_truth),
(portbox, c_host),
(porters, c_list(2,5)),
(users, c_num(30,50)),
(installer, c_str),
(archive-coverage, c_num(90,95)),
(archive-uptodate, c_num(95,97)),
(buildds, c_list(2,2)),
(buildd-redundancy, c_truth),
(buildd-fast-sec, c_truth),
(buildd-247,c_truth),
(concerns-rm, c_untruth),
(concerns-srm, c_untruth),
(concerns-dsa, c_untruth),
(concerns-sec, c_untruth),
(candidate, c_truth),
]
# table output
def dump_table(info,waivers):
arches=info.keys()
arches.sort()
candidacy_at_risk = {}
print table
print trtd/td
for arch in arches:
print td%s/td % (arch)
candidacy_at_risk[arch] = False
print /tr
for c,c_fn in criteria:
print trtd%s/td % (c)
for arch in arches:
v=info[arch].get(c,None)
if c==candidate and candidacy_at_risk[arch]:
if v == True: v = at risk
if v is not None:
col,contents = c_fn(v)
else:
col,contents = FAIL(-)
w = waivers.get(arch,{}).get(c,None)
if w:
col=cyan
contents += ' a href=%s(w)/a' % (w)
if col==red:
candidacy_at_risk[arch]=True
print 'td bgcolor=%s%s/td' % (col,contents)
print /tr
print
Re: Bits from the release team and request for discussion
On Fri, Jul 31, 2009 at 05:39:23AM +1000, Anthony Towns wrote: So, http://release.debian.org/squeeze/arch_qualify.html lists kfreebsd-* and m68k as not release candidates, and arm, ia64, mips and powerpc as at risk in addition to alpha and hppa. Only m68k is listed as having RM concerns. Is that page actually reflecting the release team's view of architecture status at all, and could it be made to correspond a bit more closely either way? So arm's dropped off that page, kfreebsd-* have been bumped to TBD, and alpha, hppa are still accompanied by ia64, powerpc, mips and s390 as being at risk. There's lots of fields with just a ? -- apparently there's no info on whether the RMs have concerns about everything but amd64, m68k, s390 and sparc... Anyway, some suggestions: m68k isn't available anymore, afaics -- it's not in unstable; doesn't seem any point having it in the list afaics amd64 has d-i support, surely? it did for lenny, despite lenny's page... querying port maintainers for amd64 and i386 seems like a waste of time. is there really any concern that no one will be around to support them? the foo-concerns should probably have two possible states: no, or yes with one or more links to mailing list threads stating those concerns having the Porting machine answer be yes with a link to the appropriate http://db.debian.org/machines.cgi?host=foo page would be as informative and help make the table take up less space using blue to distinguish waived requirements might be helpful, with something like Users: 45 (w) to save space. Having (w) link to a list post explaining the waiver would probably be helpful for people who'd like to understand why armel gets a waiver for multiple buildds but hppa doesn't, eg. both s390 and alpha seem to be keeping up with the build up-to-dateness requirements, based on the buildd.d.o graphs. probably worth linking the row headings for those percentages to the buildd.d.o graphs, really redoing the qualification page every release seems pointless; it's a wiki page so it's not automatically up to date or correct, and still needs to be validated by the release team; and arch maintainers don't seem to particularly be excited about doing it for exiting architectures... after initial qualification, why not have the status page be the canonical summary, linking to list posts for further information as necessary? Cheers, aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote: Architectures = As some of you might have noticed, we added the architectures kfreebsd-i386 and kfreebsd-amd64 to testing. [...] However, two architectures also have issues we need to bring to your attention: We sent mails to the porters of both alpha and hppa [...] So, http://release.debian.org/squeeze/arch_qualify.html lists kfreebsd-* and m68k as not release candidates, and arm, ia64, mips and powerpc as at risk in addition to alpha and hppa. Only m68k is listed as having RM concerns. Is that page actually reflecting the release team's view of architecture status at all, and could it be made to correspond a bit more closely either way? About freeze timing we think that DebConf should definitely not fall into a freeze Past freezes were: potato 2000/01 - 2000/08 (DebConf 0 was early 2000/07) woody 2001/07 - 2002/07 (DebConf 1 was immediately after the policy freeze started, DebConf 2 happened a week or two before woody released) sarge 2005/05 - 2005/06 (DebConf 5 was a month after release) etch2006/12 - 2007/04 (DebConf 7 was three months after release) lenny 2008/07 - 2009/02 (DebConf 8 was in 2008/08, a month into the freeze) How you relate DebConf 3 and DebConf 4 to sarge's freeze is up for debate, I suppose; while sarge officially froze a month before release, that's not necessarily real. I really don't see what the big deal with having debconf during a freeze is though... and that we should leave time after DebConf to integrate the possibly disruptive changes we introduced by doing cool stuff at DebConf. Fixing RC bugs is pretty cool... We noticed that releases in the first quarter of the year worked out quite well in the past like both Etch and Lenny. Taking these into consideration we think it would be best to freeze in December. Etch was intended to freeze in October, with a release in December; the freeze was delayed because of a high bug count (250 RC bugs). I think there was pretty heavy peer pressure to have any transitions and major uploads done well before December for etch. And lenny, of course, was frozen in July... We'll be consulting all key teams within Debian to see how their plans and schedules can fit into a new timeline. Before the end of August we hope to have finished this process of consultation and be able to present the new plan to you. Why not have a developer poll as to what month(s) would most suit people for the freeze, rather than limiting it to key teams? Also, how about soliciting input from our users, just in case they have something interesting to add? Maybe LTS-syncing will turn out to be something users really do/don't want, or maybe there are other priorities they have that are worth considering. Cheers, aj signature.asc Description: Digital signature
merkel fs issues
Hello, There seem to be some issues with the ftp mirror on merkel: $ pwd /srv/ftp.debian.org/ftp $ ls -l dists/sid/Contents-powerpc.diff/ | tail -n2 -rw-rw-r-- 1 archvsync archvsync 2053 Jan 14 13:40 Index ?- ? ? ? ?? dists/sid/Contents-powerpc.diff/2008-11-08-0841.02.gz Though I guess that looks like it's over NFS to spohr now, so hopefully doesn't imply there's local corruption on merkel. Cheers, aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 10:03:20AM -0500, Theodore Tso wrote: On Mon, Dec 29, 2008 at 03:02:41PM +1000, Anthony Towns wrote: Using the word software as the basis for the divide might be too much: I'm not convinced that leaving important parts of Debian undocumented over doctrinal disputes over licensing terms is actually in the best interests of users, but I recognize that's a position that people of good will can (and have) disagreed upon. If it were up to me, I would have Debian work towards a system where packages could be tagged to allow enable common user preferences (we won't be able to make everyone happy) be enforced by what packages they can see/install. Sure, I agree, and have supported similar proposals in the past. [0] [0] http://lists.debian.org/debian-project/2005/04/msg00074.html Separating packages into separate sections to support these sorts of policy preferences is a hack, Not entirely. The pool/main (and dists/*/main) separation makes it easy for mirrors to only get DFSG-free stuff (ie, they can just use rsync, rather than needing to parse Debian-specific policy files). Otherwise, though, yes, definitely agree. I like this a lot. However, I do have a few nits... We, the members of the Debian project, make the following pledge: 1. We will build a free operating system We will create and provide an integrated system of free software that anyone can use. We will make all our work publically available as free software. Given how literalistic some members of our community can be about interpreting Foundation Documents, the second sentence is a little worrying. I can easily imagine a Free Software Fanatic using the second sentance as an argument that we must stop distributing the non-free section, since non-free is, by definition, not Free Software. The non-free stuff in non-free isn't our work though -- it's stuff other people have made that we redistribute. our work is things like debbugs, dak, debhelper, *.diff.gz, etc. Maybe some DDs write non-free software that gets packaged, but that can at least be differentiated by Joe Random j...@example.com versus using a d.o address. And it could easily be argued that the work that Debian Developers to package non-free packages, which is after all distributed on the Debian FTP servers and via Debian Mirrors, would fall under the scope of All our work. I think any packaging code, even for non-free stuff, should be DFSG-free. That might require dual-licensing, but that's okay. I'm not sure what you were trying to state by the second sentence above; one approach might be to simply strike it from the draft. Or were you trying to add the constraint that any work authored by DD's on behalf of the Debian Project should be made available under a free software license, even if in combination with other software being packaged, the result is non-free? Pretty much, yeah. 2. We will build a superior operating system We will collect and distribute the best software available, and strive to continually improve it by making use of the best tools and techniques available. I'm worried about the first clause, because of the absolutist word best in best software available. Again, some literally minded DD's could view this as meaning that the best is the enemy of the good, and use this as bludgeon to say that since we have package X, we should not have packages Y or Z, because, X is the *best*. There's nothing there that says we won't also distribute the worst software available, though. If you're worried about the best being exclusionary, though, the same applies to tools/techniques. If bugzilla is the best tool for bug tracking, we must immediately stop using debbugs, eg. Ditto wiki software, list software, etc. I would certainly be willing to second and support such a proposal, should you decide that you are willing to make it as a formal proposal for a GR. So that's one, but at least four more would be needed... Here's a wiki page for people who think this is a reasonable or desirable sort of thing to do: http://wiki.debian.org/SocialContractRevision . I've only added my caveats, not ones that other people have already brought up. Cheers, aj signature.asc Description: Digital signature
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 10:10:24PM +0900, Osamu Aoki wrote: But the way you wrote in 4 as we will make any private discussions publically available at the earliest opportunity. is problematic since it is 100% disclosure pledge. I suggest something along we will make any private discussions publically available at the earliest opportunity to the extent appropriate for this objective. I am using this objective as to allow anyone to follow our discussions. I hope someone can rephrase this better. IMO, discussion that leads to technical changes, is really part of the source, much like in-code comments, READMEs, and version control logs. If you've got access to the reasoning that led up to a decision, you can have a much better understanding of what's going on, just as if you have access to criticisms being made, and what people propose to do about them, you've got a much better idea of what the code's capabilities are. There's nothing wrong with having a closed discussion with some friends about how to improve your packages, but it's much better if after the fact you make that discussion available to everyone who might be interested. The same thing applies to discussions about the direction of Debian -- when it might release, how decisions get made, what exciting new things we might consider doing. These are important bits of information that users, upstream, and developers of other distros should have access to. That doesn't mean *every* private discussion DDs have -- gosh, wasn't the football exciting last night? isn't very interesting to Debian, eg. But equally, it's not especially on-topic for most Debian areas, either. If there's a casual environment -- like debconf, or a pub, or an IRC channel; there's no need for complete logs or video records for everyone to be able to pore over, but summaries of the technical bits would be a win. Since it's worded as a pledge, it might make sense that if it (or something like it) is ever adopted, that existing developers membership being dependent on them agreeing to the pledge. That didn't happen with the previous SC change, but it seems strange to claim to have a social contract when a significant number of members don't actually support it 100%. I am not sure about the last part. If you said when a significant number of members don't actually abide by it 100%., I can agree. As much as we are discussing SC change now, we should allow us to discuss changing it as long as we abide by the current SC during its valid term. I mean people with view to have stricter FREE requirement should not be forced to leave project via this pledge process. I don't think the text I wrote puts any limits on how much you can support free stuff; it only puts limits on how much you can ignore other people's opinions and how poorly you can treat other people. If you only want to license your work under the MIT license, and never the GPL because you think that is too restrictive, eg, you can perfectly well make that pledge. To me, none of us made action which does not abide to the valid current SC. We only overruled a part of SC when it conflicted with another one in SC via GR. I.e. 100% free vs. user. I'm not saying the project doesn't support the SC as it stands, just that some DDs don't. That applies to both the remain 100% free claim (it's silly to do that now, because it wouldn't be a functioanl OS or we've never been 100% free up 'til now, how can we `remain' that way?) or the we support [non-free works'] use and provide infrastructure for non-free packages (but Debian will remain 100% free, I certainly won't, non-free should be dropped). It makes sense that day-to-day decisions that flow from the social contract might result in disagreements (eg, is the GFDL ever free?, should non-free be released as part of stable, or kept separately?, should packages in non-free ever delay packages in main getting released into testing or stable?), but when the social contract *itself* is the cause of disagreement within the project, I find that troubling. Although I did not agree to the current SC vote, I have been abiding to the current SC. Thus we casted our vote for this GR for lenny. Yeah, you can abide by a document you don't support, but if it's possible to get a document that 95% of the project as it stands actually *supports*, I think it makes sense to consider whether keeping the remaining 5% who have principled disagreements with some part or other is going to be a good way of running the project. My draft was written with the aim of being something that who simply want complete (software) freedom above all else could readily agree with, and sign their name to, as can people who don't much care about the politics or philosophy of free software and just want to keep some non-free packages well maintained. Maybe it doesn't succeed at that, I don't know. Anyway, given the last proposal I made [0] went nowhere, [...] This is Technical
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 12:04:43AM +, devo...@vote.debian.org wrote: In the following table, tally[row x][col y] represents the votes that option x received over option y. Option 1 2 3 4 5 6 7 === === === === === === === Option 1 4660727389 117 Option 2281 160 160 171 177 224 Option 325561 125 137 151 204 Option 4253 121 146 160 166 194 Option 5234 105 128 135 136 191 Option 6220 118 134 125 134 180 Option 7226 129 145 153 160 169 Dropping Option 1 because of Majority. [...] Dropping Option 2 because of Majority. [...] Dropping Option 3 because of Majority. [...] Dropping Option 4 because of Majority. [...] Dropping Option 6 because of Majority. [...] The Schwartz Set contains: Option 5 Assume blobs comply with GPL unless proven otherwise If you consider the same results, without the supermajority requirements for options 2, 3, 4 and 6, you get: Winner: Option 2: Allow Lenny to release with proprietary firmware It beats the second choice by 39 votes (160 versus 121), which is: Second: Option 4: Empower the release team to decide ... They beat the third choice by 99 votes (160 versus 61) and 11 votes (146 versus 125) respectively, which is: Third: Option 3: Allow Lenny to release with DFSG violations They in turn beat the fourth choice (which was the winning option, choice 5) by, respectively, 66 votes (171 versus 105), 25 votes (160 versus 135), and 9 votes (137 versus 128). Fourth: Option 5: Assume blobs comply with GPL unless proven otherwise (winner as per listed supermajority requirements and devotee's mail) Option 5 beat option 6 by only two votes (136 versus 134), while the others beat option 6 by, respectively, 59 votes (177 v 118), and 41 votes (166 v 125), 17 votes (151 v 134). Fifth: Option 6: Exclude source requirements for firmware (defined) Further discussion came sixth, beaten by between 95 votes (option 2), and 11 votes (option 6), with Reaffirm the social contract last, defeated by further discussion by 109 votes. The only differences between the text of options 2 and 5 seems to be that option 2 says: Option 2: Allow Lenny to release with proprietary firmware 4. We give priority to the timely release of Lenny over sorting every bit out; for this reason, we will treat removal of sourceless firmware as a best-effort process, and deliver firmware as part of Debian Lenny as long as we are legally allowed to do so. whereas option 5 has an additional subclause: Option 5: Assume blobs comply with GPL unless proven otherwise 4. [same text as above, with the addition of:] and the firmware is distributed upstream under a license that complies with the DFSG. It's possible that has no practical difference, in which case all the furour over the running of the vote has no practical effect. If there are actual cases where the difference is important (firmware still included in the kernel or other packages that's explicitly licensed as non-free, rather than being licensed under the GPL or other free license, but not including something that looks like source code), then I guess it's a question of whether the immediate past secretary's ruling on the supermajority requirements for the vote are going to be considered binding. The voters have spoken, the bastards... --unknown Cheers, aj signature.asc Description: Digital signature
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 09:08:04PM +1000, Anthony Towns wrote: Further discussion came sixth, beaten by between 95 votes (option 2), and 11 votes (option 6), with Reaffirm the social contract last, defeated by further discussion by 109 votes. Oh, a further thought came to mind. One way to simplify the vote is to look at who ranked option 1 (reaffirm the SC/delay lenny) first. There were a few interesting votes, that didn't rank any option first, namely: V: 6353227etobi Tobias Grimm V: -77---7 msameer Mohammed Sameer V: 2-- pape Gerrit Pape (There's nothing special about those votes from a constitutional POV, but they're an interesting way of communicating none of these options are my first choice, imho) Aside from those, everyone indicated some choice as #1. Five people ranked Option 1 as #1 _in addition to_ some other option, namely: V: 111amaya Amaya Rodrigo Sastre V: 112bartm Bart Martens V: 1---1-2 guus Guus Sliepen V: 1231--- reg Gregory Colpart V: 1132457 tale Tapio Lehtonen Additionally, 27 voters ranked option #1 above all other options (not counting p...@d.o, listed above): V: 145-2-3 adejong Arthur de Jong V: 1-2 bahner Lars Bahner V: 1356472 ballombe Bill Allombert V: 132 bas Bas Zoetekouw V: 1-2bayle Christian Bayle V: 1546372 brlink Bernhard Link V: 1465732 cmb Chris Boyle V: 1667273 daniel Daniel Baumann V: 1---3-2 dmn Damyan Ivanov V: 1267225 edelhard Edelhard Becker V: 1-2 godisch Martin Godisch V: 1456273 guillem Guillem Jover V: 1345362igloo Ian Lynagh V: 1237465 jaqque John Robinson V: 1546372 js Jonas Smedegaard V: 1-- lbrenta Ludovic Brenta V: 1345672 mmagallo Marcelo Magallon V: 1346562 pabs Paul Wise V: 1--paulwaite Paul Waite V: 1346275 peters Peter Samuelson V: 1236254 rmh Robert Millan V: 177 roktas Recai Oktas V: 1256473 schizo Clint Adams V: 1564372 stew Mike O'Connor V: 1456273 tb Thomas Bushnell V: 1--22-- timo Timo Jyrinki V: 1345672 vlm Vince Mulhollon Additionally, of the voters who ranked FD first, there was only one voter who then ranked option #1 above all the other options: V: 231 toni Toni Mueller By my count, that's a total of 29 developers in favour of a fairly strict interpretation of the social contract compared to the other options available, along with another 5 who consider that equally with some (but not all) of the other options, out of the 367 developers counted in the tally. That compares (somewhat loosely) with 42 developers (out of 323) voting FD above Release etch even with kernel firmware issues in the 2006 vote [0], or the 38 developers (out of 396) who voted for the Reaffirm changes option in the 2004 vote [1]. [0] http://www.debian.org/vote/2006/vote_007 [1] http://www.debian.org/vote/2004/vote_004 As percentages, that's 9.6% in 2004, 13% in 2006, and 9.3% in 2008 -- though the comparison is particularly weak since unlike the 2004 and 2008 ballots, the 2006 ballot doesn't distinguish between voters trying to say I don't want to vote on this and I don't want to see etch release with non-DFSG-free firmware. Those seem like lower numbers than I might have expected. YMMV. Also somewhat interesting: there were 17 developers who didn't express any preference amongst the options on offer (all simply voted in favour of further discussion): V: 221 ana Ana Beatriz Guerrero L??pez V: 221 anibal Anibal Monsalve Salazar V: --1arjan Arjan Oosting V: 221 bureado Jose Parrella V: 771 costela Leo Costela V: --1 dajobe Dave Beckett V: 221 filippo Filippo Giunchedi V: --1 florian Florian Ernst V: 221 francois Francois Marier V: --1helen Helen Faulkner V: --1 jluebbe Jan L??bbe V: --1jordi Jordi Mallach V: --1lange Thomas Lange V: 771 mace Miah Gregory V: --1 mhy Mark Hymers V: --1 sto Sergio Talens-Oliag V: 221vince Vincent Sanders And there were an additional 22 voters who just didn't distinguish between the various let lenny release options (8
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 08:45:16PM -0500, Theodore Tso wrote: On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote: I wonder how many DDs were ashamed to vote the titled Reaffirm the social contract lower than the choices that chose to release. I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. So what would such a SC look like? We previously had a vote to revert the SC to 1.0, and while it defeated reaffirming the current SC, it lost to the option of simply postponing it. Maybe with nearly four years of experience since then, that's changed though. Using the word software as the basis for the divide might be too much: we've already done a lot of work restricting main to DFSG-free docs, and I think it makes sense to keep that. Having main be a functioning bunch of free stuff with a minimal and decreasing amount of random non-free stuff we still need to support it works well, it seems to me. Back in the day, I tried writing a version of the SC that felt both inspiring and within the bounds of what we could actually meet. It looked like: We, the members of the Debian project, make the following pledge: 1. We will build a free operating system We will create and provide an integrated system of free software that anyone can use. We will make all our work publically available as free software. 2. We will build a superior operating system We will collect and distribute the best software available, and strive to continually improve it by making use of the best tools and techniques available. 3. We will build a universal operating system We will accept the use of our operating system by all users, for all purposes, without discrimination. We will support our users to the best of our ability in all the choices they make, no matter what our opinion of those choices may be. 4. We will be open about our activities We will conduct our affairs in public and allow anyone to follow our discussions. Where public disclosure is not immediately feasible we will make any private discussions publically available at the earliest opportunity. 5. We will respect the community We will ensure that members of the community can easily and effectively contribute their skills and views to the project. We will respect the membership of the community, and ensure that our treatment of their contributions reflects that respect. It doesn't try to say how these goals are met, leaving that up to the DPL, ftpmaster, debian-policy, individual maintainers and future resolutions by the project. I think that makes sense by and large, but having the project state that explicitly might be necessary to avoid continuing ambiguity and arguments. For example, having non-free in the archive and the BTS (and potentially buildds and elsewhere) is implied by point (3) (ie, supporting Debian users who choose to use non-free software to the best of our ability), and potentially using non-free software ourselves (such as qmail or pgp in the past) may be implied by point (2) (using the best available tools and techniques to do the best job we can). I would personally prefer for the project to have the freedom to decide those sorts of things on a day-to-day basis through regular decision making (maintainers, list debate, DPL, ftpmaster, RM, tech-ctte, simple majority vote), but I don't know if the rest of the project will buy that these days. I'm fairly sure some people won't, at any rate. It drops the 100% free phrasing we've had in the past, because fundamentally what we have isn't 100% free. It might be three-nines edging onto four-nines, but we don't even have an accurate measurement. Calling main as it stands today an integrated system of free software seems the best compromise between staying focussed on freedom, not claiming to be completely free until we are, and not devolving into impenetrable jargon that I could come up with. It redoes the we will not hide problems phrasing in a way that, I think, reflects the intent better than the current wording, which seems to support just about everything but the BTS to be done in secret. Unfortunately that's some way off current practice wrt conducting project activities on restricted machines, private IRC channels, unlogged IRC channels, in personal emails, and on private lists. I don't think the community clause is terribly well worded, but that's what you get when you make stuff up out of whole cloth rather than building on previous attempts. One other thing the above does is, unlike the current SC, is use the word Debian to refer solely to the project -- so it
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote: On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote: Interesting; Manoj's post isn't in the -vote archives on master. I wonder why that is? Actually, I think we need a GR on the lines of , | http://www.debian.org/vote/2006/vote_007 | General Resolution: Handling source-less firmware in the Linux kernel ` To get a special dispensation for lenny. I think this would be insane. [...] I object to a second round of this. I was ok with it once, [...] Hrm, were you? Hey, we can check! V: 12tb Thomas Bushnell -- http://www.debian.org/vote/2004/gr_editorial_tally.txt (in favour of editorial amendments GR that made all non-free anything unambiguously unsuitable for main; except maybe license texts) V: 3457216 tb Thomas Bushnell -- http://www.debian.org/vote/2004/gr_sarge_tally.txt (The Debian Project resolves that it will not compromise on freedom, and will never knowingly issue another release (excluding point updates to stable releases) that contains anything in the main or contrib sections which is not free software according to the DFSG.; with the various proposed exceptions for sarge ranged between [2] and [5], further discussion at [6], and reverting the previous GR at [7]) V: 12tb Thomas Bushnell -- http://www.debian.org/vote/2006/vote_004_tally.txt (Reaffirms that programmatic works distributed in the Debian system (IE, in main) must be 100% Free Software, regardless of whether the work is designed to run on the CPU, a subsidiary processing unit, or by some other form of execution.; Further Discussion won the day) V: 231 tb Thomas Bushnell -- http://www.debian.org/vote/2006/vote_007_tally.txt (Options were Release etch with DFSG problems, but no regressions compared to sarge, exemptions for images and for firmware while technically needed but with no specific end date, and further discussion; the first option won the day) Seems to me you held pretty much the same opinions then as you do now... The kernel team should *fix the bug* and not just sit on their hands. You know, I haven't been paying any attention, but somehow I don't think the kernel team have really just been sitting on their hands. It just seems like maybe there's a third option, you know? Well, I don't and maybe I'm mistaken, so as a show of good faith, here's a photo of me sitting on my hands [0]. Because, hey, _someone_ must have been doing it, right? We should not release until it's fixed. Why don't we embrace the principle fully, and remove all our old releases too? That's not sarcasm -- I just don't see a reason to reject that idea, but not also to keep compromising until there's no longer anything to compromise with. AFAICS, the idea is to stop Debian users and developers from kidding themselves that they've got a free OS and force them to fix the remaining problems until they do. And if that's really a good idea, why not commit to it? But hey, I never saw the problem with only wanting to distribute free /software/, and we know where that sort of thinking leads! Moreover, at the time, there was an amendment proposed to make it as long as required and it got fewer votes than the one-time thing. Pretty clearly, we *already decided* this issue, and we need no vote. We decided there would be an exception for sarge, and another one for etch. I don't think there's been any decision made via GR on lenny, and even if there had been, another GR could quite reasonably overturn it if enough people felt it was warranted. We need the relevant maintainers to be told your unwillingness to fix this means we will not be able to release. What good do you think that will do? Here, let me try: Thomas: your continued inaction and unwillingness to code an acceptable solution to this issue, in spite of being aware of the problem since at least 2004 -- over four years ago! -- means we will continue to do releases with non-free software. Did it do any good? Is there something different about other maintainers that will make that logic work better on them, than you? I object very strongly to the feeling that I am being held hostage by developers who will not fix the bug, and then protest emergency! we must release! no delay! we'll do it next time! and then sit on their hands again for another go-round. The solution is to refuse to play along, and to say, hey, you had two years; we're just going to wait until you fix the bug. Hey, you've had four years; we're just going to keep releasing until you fix the bug. Hint: you're not being held hostage by anyone, seriously. You know how you can tell? Two words: Stockholm syndrome. Cheers, aj, who knows what completely ignoring the lists is like, and wants a fresh comparison of that to randomly trolling into
Re: Adding lzma to dpkg's Pre-Depends
On Tue, Apr 01, 2008 at 08:05:06AM +0300, Guillem Jover wrote: As per policy 3.5 I'm bringing this up here. I'd like to add lzma to dpkg's Pre-Depends, so that we can use lzma compressed packages after lenny w/o having to add an lzma Pre-Depends on each .deb package compressed that way. Hrm. Alternatively, the packages _do_ pre-depend on lzma though; and you're aiming to avoid that by making lzma Essential:yes -- in the same way packages that pre-depend on perl or bash don't need an explicit dependency. libz and libbz2 are both included statically; would it make more sense to do the same thing with the lzma (ie, copy the binary into /usr/lib/dpkg), instead of making lzma essential? Cheers, aj signature.asc Description: Digital signature
Re: Blueray software, was: What CDs and DVDs should we produce for lenny?
On Mon, Mar 17, 2008 at 08:16:55AM -0500, Ron Johnson wrote: On 03/17/08 04:47, Philip Charles wrote: [snip] worrying about. Even then bluray disc(s) will take up about the same space as a CD set. 21GB on CD is 21GB on Bluray. Physical space isn't an issue for us. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
On Mon, Mar 17, 2008 at 01:39:40PM +, Steve McIntyre wrote: [ /me sets the Reply-To: to debian-cd again... ] But not Mail-Followup-To:... At a bare minimum: - installer - downloadable (business card) - installer+base - downloadable (netinst) - CD - disk 1 downloadable, disk 2+ jigdo-only - DVD - disk 1 downloadable, disk 2+ jigdo-only - BD - one image jigdo-only That's 25MB + 650MB + 4GB of images per-arch, for about 61GB in total, plus a whole bunch of jigdo images (about 500?). So more like 25 + 150 + 650 + 4000 = 4825 per arch, for about 63GB in total. Either way. Is it possible to create a jigdo image without creating the full ISO? ie, to go from a list of files you want on the ISO straight to a jigdo template without the intervening step of actually copying all the files around? Oh, absolutely. That's one of the biggest changes I made in debian-cd/mkisofs to improve performance. However... if we want to continue providing torrent downloads (which are very popular, I understand) then we do still need to make the full images too. So, there's three user scenarios, I guess: - great network access, download everything directly (netinst gets the process started quickest, and downloading everything is fine) - good network access but don't want to download debs multiple times, or want to download in bulk in advance (run a proxy or mirror; or download DVD/CD images, and use them) - bad network access (buy/download everything on DVD/CD/BD and use it to install, or populate a local mirror) And there's four ways we can get debs to people: - regular archive (apt, netinst, jigdo) - raw images (download via cd mirrors) - torrented images (download via cd torrents) - vendors burn images and mail them to people If you're buying/mailing images, it's out of our hands, provided vendors can get images in the first place, so ignore that. Our regular archive is already mostly optimised, so the more people using it, the better; that's just a matter of more jigdo use, afaics. That leaves us with torrent and http iso downloaders -- possible lots or possibly not too many depending on whether we can make jigdo any easier. But I don't think there's any way to avoid that, it's just a question of how many, isn't it? I guess there's an inequality like: images on mirrors = images on torrents = images via jigdo And images on torrents = images you have to generate. And the inequalities go the other way too: ease of downloading = ease of torrenting = ease of jigdoing and the real question is where you say if you really want the 23rd CD for mipsel, you're probably smart/dedicated enough to use jigdo. The other thing we /could/ do is encourage people who've done successful Debian installs to help contribute by participating in a torrent after the fact -- you could do all sorts of things like have a FUSE filesystem that takes a (partial) mirror and a jigdo file and lets you see fake iso files, which you then seed via bittorrent, eg. You could automate that, so it's just a question like the popcon one: Do you wish to participate as a torrent seed for other people installing Debian? Yes [No] Another option would be a jigdo firefox plugin -- even if a pure javascript jigdo turns out too hard, a plugin ought to be pretty easy. Otherwise there's Java potentially, but at that point you start getting into OS-specific scenarios, and worrying about ActiveX or .NET and installers or whatever, at which point things get too hard. :-/ I guess another option would be to have a virtual appliance that will do all the jigdo stuff for you by running a cut down Debian in a virtual machine (vmplayer, qemu, etc) and generating the isos for you. Hrm. In the real world, does jigdo actually saturate broadband bandwidth? It's been a long time since I've tried it, but I vaguely remember it not actually being very speedy. Ah, it was the stop downloading, add files to image that used to slow things down, but seem less of an issue now. The repeated wgets probably still aren't great for that matter, since it serialises downloading and establishing connections. Cheers, aj signature.asc Description: Digital signature
Re: What CDs and DVDs should we produce for lenny?
On Sun, Mar 16, 2008 at 11:59:52PM +, Steve McIntyre wrote: 2 small CDs per arch (business card, netinst) ~30 CDs per arch for a full CD set ~4 DVDs per arch for a full DVD set (total 353 CDs, 51 DVDs, 426 GB) Bluray image? Apparently there's been a winner in the format wars, and we could probably fit an entire arch on a single disc... Should we be counting a live CD/DVD/BD image in there too? Is it possible to do a javascript implementation of jigdo, so we could reasonably just publish a list of the files that need to go on most of the CDs instead of the entire iso images? If you can download an image via jigdo just by clicking in your browser, that'd seem like we could rely on jigdo much more heavily than we have. How many different boot images do we have these days? We used to have a different boot image on each of the first N CDs, do we still do that? Is there really a lot of value in the netinst image, versus the business card? You're going to be downloading stuff anyway, so the only difference I can see is if your system can download once you've got base installed, but can't from the installer. Would it be simpler just to expect that class of people to grab a full CD/DVD image (and thus have more than just base available once they've rebooted and are trying to get net working)? At a bare minimum: - installer - downloadable (business card) - installer+base - jigdo-only? (netinst) - CD - disk 1 downloadable, disk 2+ jigdo-only - DVD - disk 1 downloadable, disk 2+ jigdo-only - BD - one image jigdo-only That's 25MB + 650MB + 4GB of images per-arch, for about 61GB in total, plus a whole bunch of jigdo images (about 500?). Is it possible to create a jigdo image without creating the full ISO? ie, to go from a list of files you want on the ISO straight to a jigdo template without the intervening step of actually copying all the files around? If so, then the cost of having all sorts of images available becomes pretty small: generate a jigdo, let people who want it download the image using a javascript capable web browser. Cheers, aj signature.asc Description: Digital signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 07:52:28PM +0100, Raphael Hertzog wrote: On Sun, 09 Mar 2008, Raphael Hertzog wrote: On Sun, 09 Mar 2008, Ian Jackson wrote: With this message I am unilaterally declaring myself a maintainer of dpkg, and also declaring that Guillem is no longer a maintainer. For the record, Ian has been removed from the dpkg group on Alioth and we asked for an UNACCEPT of his upload, but I'm not sure it will be done on time as none of the ftpmasters responded yet to my queries on IRC. The package got unaccepted by Anthony Towns. Beyond that, any additional uploads of dpkg will be REJECTed until you guys resolve this nonsense. Flamewars on -devel, ignoring functional patches for months on end, package hijacks and requests for UNACCEPTs aren't the way to maintain dpkg. Cheers, aj signature.asc Description: Digital signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 10:38:44PM -0500, Steve Greenland wrote: On 09-Mar-08, 19:30 (CDT), Daniel Stone [EMAIL PROTECTED] wrote: I was going to ask on which grounds exactly you were judging the dpkg team's competence (and that of iwj's: have you reviewed the branch yourself? can you confidently say that it's all fine?), The problem is not the dpkg team has reviewed the patch and had problems with it, it's that they've ignored it for 6 months. That's not the full picture. Ian's been trying to be involved in the dpkg team for longer than six months, and not been incredibly effective at that; eg from July: I will of course be careful about controversial changes. For example, I'll refrain from committing my formatting fixup from #375711 until we've come to a conclusion. I hope you can trust my judgement about what would be a controversial change. -- http://lists.debian.org/debian-dpkg/2007/07/msg00013.html Ian then reposted the triggers spec and published a git tree for the patch, with the following comment: I'd appreciate it if no-one reformatted it or change the style. If you have disagreements with the code please discuss it here on the list before making any changes. Checking a significantly changed version into the main Debian git will cause snarl-ups because our merges will constantly need resolving. -- http://lists.debian.org/debian-dpkg/2007/08/msg00014.html -- http://lists.debian.org/debian-dpkg/2007/08/msg9.html Ian then reimplemented the status file parsing using flex, in a way he reported was faster, but hadn't tested, and suggested it get included in sid. I have written over the weekend a replacement for lib/fields.c and most of lib/parse.c, which uses flex (and flex start conditions) to generate a table-driven scanner-cum-parser. I haven't tested this fully for correctness yet, but I have done basic functionality tests and some performance tests. ... The downside is that it's 100K longer in code size. ... Anyway, I think we should deploy the flex-based scanner in sid (after I've tested it a bit more) and then think at our leisure about how to improve the shared code situation. -- http://lists.debian.org/debian-dpkg/2007/08/msg00028.html Guillem replied to that patch within about four days, but the git tree Ian developed it in was based on the triggers tree, so can't be easily merged independently. In October, Joey proposed his v3 source package format, which is one of the other major outstanding patches. I don't believe it has any stylistic problems, but it still seems to be being reinvented/redisgned, rather than being applied. -- http://lists.debian.org/debian-dpkg/2007/10/msg9.html -- http://lists.debian.org/debian-dpkg/2008/02/msg00012.html http://lists.debian.org/debian-dpkg/2008/02/msg00079.html http://lists.debian.org/debian-dpkg/2008/02/msg00131.html Also in October, Colin Watson asked what the status of triggers was. Ian replied: The implementation of triggers is not going to change incompatibly. It's well-tested now in Ubuntu and should just be merged into Debian's dpkg. -- http://lists.debian.org/debian-dpkg/2007/10/msg00107.html Guillem replied to that: Err, well of course it's highly desirable to not do such kind of changes without good reason, but I don't think the fact that it has been deployed in a derivative distro means that we should blindly merge any such code drops without review and/or possible changes. -- http://lists.debian.org/debian-dpkg/2007/10/msg00132.html Ian replied to that: Don't be ridiculous. This is offensive to me personally. This code has been * designed with extensive input from this mailing list in Debian fora * written by dpkg's original maintainer * tested extensively * available for merging for several months -- http://lists.debian.org/debian-dpkg/2007/10/msg00138.html Guillem didn't reply to that; his next comment on triggers a couple of weeks later was, in response to Ian: This isn't a matter of preference, I'm afraid. I reverted this because the change was wrong. NULL is incorrect in that context (a stdarg function expecting a char*), because it may be #define'd to 0. That's true, but then I agree with others [0] that an environment that defines NULL to 0 (even if the standard allows that) is not sane. Such ancient environment will also not be able to cope with modern software like gtk, anyway. [0] http://lwn.net/Articles/93577/ -- http://lists.debian.org/debian-dpkg/2007/10/msg00228.html There were a couple of messages that sounded promising in regards to a productive conclusion at the end of that month: -- http://lists.debian.org/debian-dpkg/2007/10/msg00230.html -- http://lists.debian.org/debian-dpkg/2007/10/msg00231.html Nothing much happened in Nov or Dec; both Ian and Guillem posted about random other stuff, a
Re: Google Summer of Code 2008
On Wed, Feb 27, 2008 at 01:53:17PM +, Jon Dowland wrote: On Wed, Feb 27, 2008 at 09:42:17AM +0100, Lucas Nussbaum wrote: (1) Forbid DDs and people in the NM process waiting for FD/DAM to apply as students. What if we do this, and still do not get many new people applying? How about a policy of prioritising non-DD/NM/DM/whatever contributions, rather than outright forbidding established people? Uh, applicants who're already familiar with the project (both Debian and the specific GSoC project they're applying for) have a much better chance of success; applicants who are already DDs have a much easier time actually contributing than people who aren't. Hamstringing ourselves and our applicants by discouraging prior involvement is crazy. For comparison: I mentored the same project in 2006 and 2007 with different students; the 2006 student unfortunately wasn't able to get anywhere; the 2007 student has been involved in Debian as a sponsored package maintainer for a while that happened to be related to the topic, worked on academic research also related to the topic, and at the end of the summer was was one of the test cases for deployment of Debian Maintainers; he was impressively successful at the GSoC task and has been continuing with it since then. Sorry, but preferncing people with no experience or involvement is a *completely* backwards approach, however you water it down. That said, GSoC is meant to be about *learning* and *getting people involved* in the project and mentorship, so a student who's already really experienced with Debian will still need to find some area that they don't already know inside and out, aren't already involved in completely, and can find someone who knows more about it than they do to act as their mentor. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
On Fri, Feb 22, 2008 at 06:23:28PM -0800, Daniel Burrows wrote:
Would it be possible to only re-order elements that were introduced by
a variable substitution? That would make the list deterministic without
changing what the maintainer wrote.
At best you could:
(a) sort substvar dependencies
(b) drop repeated deps from substvars
without messing up the maintainer's ordering. If you've got, say:
Depends: foo, bar, ${baz:Depends}
with ${baz:Depends} expanding to foo (= 1.2), then you have the choice
of:
Depends: foo, bar, foo (= 1.2)# duplicates foo dep uselessly
Depends: bar, foo (= 1.2) # drops explicitly added dep,
# and reorders, changing apt's
# behaviour
Depends: foo (= 1.2), bar # adds version info from shlibdep
# to explicit dep
I'm not sure the latter actually has the exact same behaviour as the
first; if foo2 Provides: foo and has a higher Priority: the first Depends:
might install foo2,bar,foo instead of just foo and bar; likewise if bar
Depends: foo2|foo.
For comparison, if you had:
Depends: foo (= 1.3), bar, ${baz:Depends}
ending up with
Depends: bar, foo (= 1.3)
instead of just ignoring the redundant baz:Depends entirely seems a
bit silly.
The *safest* way of doing eliminations is thus probably:
new_deps = []
for dep in expands_substvars(cur_deps):
add = 1
for odep in new_deps:
if odep.implies(dep): add = 0
if add:
new_deps.append(dep)
And if you're willing to have `foo, bar, foo (= 1.2)' - `foo (= 1.2),
bar' (as per above), then something like:
new_deps = []
for dep in expands_substvars(cur_deps):
add = 1
for odep_pos in range(len(new_deps)):
odep = new_deps[odep_pos]
if odep is None:
continue
elif odep.implies(dep):
add = 0
break
elif dep.implies(odep):
if add:
new_deps[odep_pos] = dep
else:
new_deps[odep_pos] = None
add = 0
if add:
new_deps.append(dep)
new_deps = [ x for x in new_deps if x is not None]
would work.
The new_deps[odep_pos] = None portion lets you turn:
foo, foo (= 1.0), foo (= 2.0), foo (= 1.5)
into:
new_dep still to look at
foo, foo (= 1.0), foo (= 2.0), foo (= 1.5)
foo foo (= 1.0), foo (= 2.0), foo (= 1.5)
foo (= 1.0), foo (= 2.0), foo (= 1.5)
foo (= 1.0), foo (= 2.0) foo (= 1.5)
foo (= 1.5)
Cheers,
aj
signature.asc
Description: Digital signature
Re: Meaning of the Altering package upload rules
On Fri, Feb 15, 2008 at 11:45:45AM +0100, Stefano Zacchiroli wrote: Hence I think we should push for source upload. Stop pushing and start programming. A technical approach to this would be implementing something along the lines of http://lists.debian.org/debian-devel/2006/07/msg00544.html It's trivial for interested DDs to setup an autobuilder; and if you're not willing to trivial work to demonstrate a policy change is useful, arguing's just a waste of everyone's time. Cheers, aj signature.asc Description: Digital signature
Re: Proposition: 'NMU' upload of wxwidgets 2.8
On Sun, Feb 03, 2008 at 04:30:09PM -0600, William Pitcock wrote: Currently, the packages that are asking for wx2.8 are almost all available and releasable in earlier versions, built against wx2.6. Uploading wx2.8 to unstable implies that it's suitable for apps to build against, which by all accounts it is not. Maybe an upload to experimental would be appropriate then? Usually. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [proposal] Documenting which revision is installed
On Fri, Dec 28, 2007 at 08:20:01AM +0100, Frans Pop wrote:
I agree with Anthony that it is very much preferable to have a solution
that's just able to automatically determine the correct version.
Okay, so here's a updated version that generates both debian_version and
lsb-release as specced by dato, if it's given arguments of debian-version
or dato-release, and has appropriate perms.
In order for it to be useful, I guess it'd need to be in base, and hence
written in perl or C (unless we decided to add python to base).
] $ ./debian_version.py debian-version
] /etc/debian_version should contain:
] lenny
] $ ./debian_version.py dato-release
] /etc/lsb-release should contain:
] DISTRIB_ID=Debian
] DISTRIB_RELEASE=lenny
] DISTRIB_CODENAME=lenny
] DISTRIB_DESCRIPTION=Debian x.y Testing distribution - Not Released
] $ ./debian_version.py noisy
] Packages seem to be from Debian release lenny
] Debian x.y Testing distribution - Not Released
] ['mirror.internode.on.net_pub_debian_dists_lenny_Release',
'http.us.debian.org_debian_dists_lenny_Release']
] 89.4% HIT RATE (1293 of 1447)
] 95.3% of installed packages available
] 4.4% of matching packages could be upgraded
] 1.8% of matching packages are more recent
] $ sudo rm /etc/debian_version /etc/lsb-release
] $ sudo ./debian_version.py debian-version dato-release
] $ cat /etc/debian_version; echo ; cat /etc/lsb-release
] lenny
]
] DISTRIB_ID=Debian
] DISTRIB_RELEASE=lenny
] DISTRIB_CODENAME=lenny
] DISTRIB_DESCRIPTION=Debian x.y Testing distribution - Not Released
Cheers,
aj
#!/usr/bin/env python
# Copyright 2007 Anthony Towns
# GPL v2 or later.
import apt_pkg, sys, os
apt_pkg.init()
def try_write(file):
try:
f = open(file, w)
except IOError:
f = sys.stdout
f.write(%s should contain:\n % file)
return f
def uniq(l):
return dict( [(x,1) for x in l] ).keys()
def get_installed():
vs = {}
i = open(/var/lib/dpkg/status, r)
p,v,x = None,None,None
for l in i.xreadlines():
l = l.rstrip()
if l.startswith(Package: ): p = l[l.find( )+1:]
if l.startswith(Version: ): v = l[l.find( )+1:]
if l.startswith(Status: ):
x = l.split( )[1:]
if l == :
if x and x[0] != hold and x[1] == ok and x[2] == installed:
vs[p] = v
p,v,x = None,None,None
i.close()
return vs
vlal = /var/lib/apt/lists
arch = .join(os.popen(dpkg --print-architecture, r).readlines()).rstrip()
def releases():
urs = {}
for path in os.listdir(vlal):
if not path.endswith(_Release.gpg): continue
path = path[:-4]
release_info = []
o,l,s,v,c = [None] * 5
for l in open(os.path.join(vlal,path)).xreadlines():
l = l.rstrip()
if l[0] != :
release_info.append(
(l[:l.find(:)], l[l.find(:)+1:].lstrip()) )
else:
x = release_info[-1]
x = (x[0], x[1] + \n + l[1:])
release_info[-1] = x
release_info_l = release_info
release_info = dict(release_info)
vendor = filter(None, [
release_info.get(Label, None),
release_info.get(Origin, None),
unknown] ) [0]
version = filter(None, [
release_info.get(Version, None),
release_info.get(Codename, None),
release_info.get(Suite, None),
unknown] ) [0]
pkgs = [x for x in os.listdir(vlal)
if x.startswith(path[:-7])
and x.endswith(_binary-%s_Packages % arch) ]
k = (vendor,version)
if k not in urs: urs[k] = ([],[],[])
urs[k][0].append( path )
urs[k][1].append( release_info )
urs[k][2].extend( pkgs )
res = []
for k,v in urs.iteritems():
(vendor, version) = k
(paths, rels, pkgs) = v
res.append( (vendor, version, paths, rels, readlist(pkgs)) )
return res
def readlist(files):
vs = {}
for file in files:
i = open(os.path.join(vlal, file), r)
p,v = None,None
for l in i.xreadlines():
l = l.rstrip()
if l.startswith(Package: ): p = l[l.find( )+1:]
if l.startswith(Version: ): v = l[l.find( )+1:]
if l == :
vs[p] = v
p,v = None,None
i.close()
return vs.items()
def compare(installed, list):
same, new, old = 0,0,0
tryagain = dict(installed)
for (p, tv) in list:
if p in installed:
if tv == installed[p]:
same += 1
del tryagain[p]
else:
x = apt_pkg.VersionCompare(installed[p], tv)
if x 0:
old += 1
elif x 0:
new += 1
else:
same += 1
del tryagain[p]
return same,new,old,tryagain
installed = get_installed()
release_pkgs = releases()
noisy = (noisy in sys.argv[1:])
iterate = (iterate in sys.argv[1:])
debian_version = (debian-version in sys.argv[1:])
dato_release = (dato-release in sys.argv[1:])
intro = Packages
while installed:
best = 0,len(installed),0,-,-,[],-,[]
for vendor, version, path, rels, packages in release_pkgs:
same,new,old,tryagain = compare(installed, packages)
if same best[0]:
best = same,new,old,vendor,version,rels,path,tryagain
Re: [proposal] Documenting which revision is installed
On Thu, Dec 27, 2007 at 04:21:20PM +0100, Adeodato Sim?? wrote: * Anthony Towns [Thu, 27 Dec 2007 17:34:49 +1000]: On Wed, Dec 26, 2007 at 11:53:25PM +0100, Adeodato Sim?? wrote: *Personally*, I like the idea of Javier Fern??ndez-Sanguino expressed in the mail linked above of keeping debian_version as is, and introducing /etc/lsb-release with detailed information like: DISTRIB_ID=Debian DISTRIB_RELEASE=4.0 DISTRIB_CODENAME=etch DISTRIB_DESCRIPTION=Debian GNU/Linux 4.0 'etch' The problem with base-files providing /etc/debian_version is that it means /etc/debian_version can really only tell you what version of base-files is installed. So if you upgrade every other package but base-files from 4.0r1 to 4.0r2, you have all the functionality of 4.0r2 but get reported as 4.0r1, and if you just upgrade base-files, you get reported as 4.0r2 while still having the bugs from 4.0r1 that were meant to have been fixed. Yes, of course. And this is brought up whenever there's talk about /etc/debian_version. :-) Right, so why not fix it properly? (Did you read the rest of my mail?) However, I believe that most people wanting more detail in that file, or another file, are aware of such limitations, The main limitation is that it's a nuisance to update -- you can't differentiate testing and unstable because of that, eg, and when we're due for a release we end up having testing/unstable pretend they're really stable already for a while, eg. Updating it more often just makes that more of a nuisance. Cheers, aj signature.asc Description: Digital signature
Re: wxwidgets 2.8, anyone?
On Sun, Dec 23, 2007 at 02:26:30PM +0100, Bernd Zeimetz wrote:
1. Get wx2.4 out of the archive _soon_. There's a list in wiki.d.o about
the status of the last applications using wx2.4, if I remember right.
Their maintainers had more than enough time to et them migrated to 2.6
(or 2.8, if there would be 2.8).
Sounds like these should be NMUed. gnue-{forms,designer}, openrpg, and
trustedsql sound easy; and jugglemaster is a new package depending on
an oldlib, tsk. That just leaves ctsim, newpki-client and surex-aven
requiring any actual work.
Cheers,
aj
signature.asc
Description: Digital signature
Re: [proposal] Documenting which revision is installed
On Wed, Dec 26, 2007 at 11:53:25PM +0100, Adeodato Sim?? wrote:
*Personally*, I like the idea of Javier Fern??ndez-Sanguino expressed in
the mail linked above of keeping debian_version as is, and introducing
/etc/lsb-release with detailed information like:
DISTRIB_ID=Debian
DISTRIB_RELEASE=4.0
DISTRIB_CODENAME=etch
DISTRIB_DESCRIPTION=Debian GNU/Linux 4.0 'etch'
The problem with base-files providing /etc/debian_version is that it means
/etc/debian_version can really only tell you what version of base-files
is installed. So if you upgrade every other package but base-files from
4.0r1 to 4.0r2, you have all the functionality of 4.0r2 but get reported as
4.0r1, and if you just upgrade base-files, you get reported as 4.0r2 while
still having the bugs from 4.0r1 that were meant to have been fixed.
Maybe it would be better to have aptitude or similar actually analyse
what's installed compared to the available Packages/Release files,
and generate a /etc/debian_version or /etc/lsb-release file based on
that. It wouldn't require any additional downloads -- it'd just be a matter
of:
- looking at /var/lib/apt/lists/*_Release to see what the latest
available revision is
- looking at /var/lib/dpkg/status and /var/lib/apt/lists/*_Packages
to see if the packages on this system are actually updated to
that revision
- based on the above updating /etc/debian_version to reflect the
version of Debian actually installed
And that way the only things needed for getting the right version would
be (the equivalent of):
# update Release file
apt-get update
apt-get dist-upgrade
aptitude debian-version-update
with no need to worry about multiple branches of base-files or whatever,
or worrying what apt pinning says the admin's intending to install
or similar.
I'm at a bit of a loss as to how you'd do it properly (using python-apt
or something, say), but a proof of concept is attached. Example output:
$ ./debian_version.py
Packages seem to be from Debian release lenny
91.7% HIT RATE (1325 of 1445)
95.5% of installed packages available
2.2% of matching packages could be upgraded
1.8% of matching packages are more recent
$ ./debian_version.py
Packages seem to be from Debian release 4.0r1
87.3% HIT RATE (517 of 592)
97.3% of installed packages available
0.0% of matching packages could be upgraded
10.2% of matching packages are more recent
$ ./debian_version.py iterate
Packages seem to be from Debian release 4.0r1
87.3% HIT RATE (517 of 592)
97.3% of installed packages available
0.0% of matching packages could be upgraded
10.2% of matching packages are more recent
Remaining packages seem to be from Debian release 4.0-updates
61.3% HIT RATE (46 of 75)
68.0% of installed packages available
9.8% of matching packages could be upgraded
0.0% of matching packages are more recent
Remaining packages seem to be from Debian-Security release etch
10.3% HIT RATE (3 of 29)
24.1% of installed packages available
14.3% of matching packages could be upgraded
42.9% of matching packages are more recent
Remaining packages:
bzr: 0.15-1
...
Cheers,
aj
#!/usr/bin/env python
# Copyright 2007 Anthony Towns
# GPL v2 or later.
import apt_pkg, sys, os
apt_pkg.init()
def get_installed():
vs = {}
i = open(/var/lib/dpkg/status, r)
p,v,x = None,None,None
for l in i.xreadlines():
l = l.rstrip()
if l.startswith(Package: ): p = l[l.find( )+1:]
if l.startswith(Version: ): v = l[l.find( )+1:]
if l.startswith(Status: ):
x = l.split( )[1:]
if l == :
if x and x[0] != hold and x[1] == ok and x[2] == installed:
vs[p] = v
p,v,x = None,None,None
i.close()
return vs
vlal = /var/lib/apt/lists
arch = .join(os.popen(dpkg --print-architecture, r).readlines()).rstrip()
def releases():
urs = {}
for path in os.listdir(vlal):
if not path.endswith(_Release.gpg): continue
path = path[:-4]
o,l,s,v,c = [None] * 5
for l in open(os.path.join(vlal,path)).xreadlines():
l = l.rstrip()
if l.startswith(Origin: ): o = l[l.find( )+1:]
if l.startswith(Label: ):L = l[l.find( )+1:]
if l.startswith(Suite: ):s = l[l.find( )+1:]
if l.startswith(Version: ): v = l[l.find( )+1:]
if l.startswith(Codename: ): c = l[l.find( )+1:]
vendor = filter(None, [L,o,unknown])[0]
version = filter(None, [v,c,s,unknown])[0]
pkgs = [x for x in os.listdir(vlal)
if x.startswith(path[:-7])
and x.endswith(_binary-%s_Packages % arch) ]
k = (vendor,version)
if k not in urs: urs[k] = ([],[])
urs[k][0].append( path )
urs[k][1].extend( pkgs )
res = []
for k,v in urs.iteritems():
(vendor, version) = k
(paths, pkgs) = v
res.append( (vendor, version, paths, readlist(pkgs)) )
return res
def readlist(files):
vs = {}
for file
Accepted ifupdown 0.7~alpha3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 22 Dec 2007 00:31:16 +1000 Source: ifupdown Binary: ifupdown Architecture: source amd64 Version: 0.7~alpha3 Distribution: experimental Urgency: low Maintainer: Anthony Towns [EMAIL PROTECTED] Changed-By: Anthony Towns [EMAIL PROTECTED] Description: ifupdown - high level tools to configure network interfaces Closes: 431059 456918 Changes: ifupdown (0.7~alpha3) experimental; urgency=low . * Apply patches from Andreas Henriksson (Closes: Bug#456918) - Fix aadr typo in IPv6 loopback method - Add dependency on new version of iproute that supports specifying netmasks as dotted-quads. - Re-add netmask field for backwards compatibility. - Flush addresses when taking down a static inet interface. (Closes: Bug#431059) - Switch inet/dhcp and inet6/static methods to iproute. - Update test cases. - Support for conversion of ifconfig format hwaddress to iproute format hwaddress. * Update Build-Depends: to reflect name change from nowebm to noweb. * Move DH_COMPAT setting from debian/rules to debian/compat file. * Don't ignore errors from make clean in debian/rules clean target. * Escape hypens in interfaces.5 manpage. * Don't create /usr/bin or /usr/sbin directories. * Bump Standards-Version. Files: 78cf4d98ffc82cba2dea72f58d7a41de 536 admin important ifupdown_0.7~alpha3.dsc 88c01c56bc0cd7b03ad8872a8419eeed 395670 admin important ifupdown_0.7~alpha3.tar.gz 245708bb4309bb72f26e2b4f3c6f1c31 53802 admin important ifupdown_0.7~alpha3_amd64.deb -BEGIN PGP SIGNATURE- iD8DBQFHa857Oxe8dCpOPqoRAlEEAJ4+iOXYZ7l37j/JCM/7jkNuMbLxUgCeLyNh uedAAxJRQNvBzVtIlyzr4Pw= =DnRS -END PGP SIGNATURE- Accepted: ifupdown_0.7~alpha3.dsc to pool/main/i/ifupdown/ifupdown_0.7~alpha3.dsc ifupdown_0.7~alpha3.tar.gz to pool/main/i/ifupdown/ifupdown_0.7~alpha3.tar.gz ifupdown_0.7~alpha3_amd64.deb to pool/main/i/ifupdown/ifupdown_0.7~alpha3_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: priorities
On Thu, Dec 06, 2007 at 11:03:08PM -0600, Manoj Srivastava wrote: Frankly, I suggest we look at the list of Unix commands as specified by the SUS -- which can also be seen at: http://en.wikipedia.org/wiki/List_of_Unix_programs So -- how many of the standard unix commands as defined by that page are not part of the standard section? I guess one of the the things I wonder every now and then is whether we really should be keeping standard as implying a ... traditional/historical/whatever Unix system, with pr and lpr and tcsh and bc and dc and whatever else that people would traditionally expect, instead of moving them to a task that can be installed only by people who actually know what they are, and then making sure we provide a real Unix system in that case. But by the looks of things there's still not much need for a change there, at least at this point. Cheers, aj signature.asc Description: Digital signature
Re: priorities
On Fri, Dec 07, 2007 at 08:25:05AM +0100, NN_il_Confusionario wrote:
Question: is there somewhere on the net a script (*) such that:
* it installs required/essential packages (_all_ of them but _only_
them) of such a release as a chroot in that directory
You could create a variant for debootstrap. That's not very hard,
depending on your mood:
# cp /usr/share/debootstrap/scripts/sid my-sid
# patch EOF
@@ -9,7 +9,7 @@
mirror_style release
download_style apt
finddebs_style from-indices
-variants - buildd fakechroot
+variants - buildd fakechroot minbase
if doing_variant fakechroot; then
test $FAKECHROOT = true || error 1 FAKECHROOTREQ This variant
requires fakechroot environment to be started
@@ -37,6 +37,8 @@
# ldd.fake needs binutils
required=$required binutils
fi
+
+if doing_variant minbase; then base=apt; fi
}
first_stage_install () {
EOF
# debootstrap --variant=minbase sid target/
http://mirror.internode.on.net/pub/debian/
If you don't want apt and its dependencies, you can add --include=ed
--exclude=apt as arguments, or similar. If you don't have anything
at all in base, you'll get some ugly error messages, but I think it'll
still work.
OTOH, there's not much reason not to have that in debootstrap by default,
afaics. What the hey, patch committed. Look for it in version 1.0.8 when
it gets released.
Every time I do someting like that, too much time is spent for
dependency hunting. Ad every time I forget to save the list of packages :-(
debootstrap --print-debs will give you a list of packages. It includes
both required and base in the same list, so you have to look for the split
yourselve (zlibg1 and adduser atm), but that's not too hard hopefully.
Cheers,
aj
signature.asc
Description: Digital signature
priorities (was: Re: RFC: cups as default printing system for lenny?)
Kind of reviving an old thread, but anyway: On Sun, Nov 11, 2007 at 07:12:35PM +0100, Marc 'HE' Brockschmidt wrote: I believe it to be one of the more important bits of a standard Unix *desktop* installation - but this just reminds me of the fact that I'm quite uncomfortable with keeping a system like package priorities around for much longer. Diverging use-cases (like in this case) show that one definition of standard isn't really helpful anymore. Haven't we more or less already moved away from priorities as meaning anything particularly important? We have: required/essential -- stuff that can't be removed: libc, dpkg, etc important -- the rest of base, stuff necessary to bootstrap and recover a usable and useful system standard -- a minimal collection of useful stuff we'd like to see on every Debian system optional -- all the good software in the world extra -- obscure stuff All the really important questions are which bits of optional (and occassionally extra) are useful for a given user. I'm not sure if there's any point to continuing to try to make sure that nothing = optional conflicts with anything else = optional. I think we may want to start thinking about getting rid of the whole thing and switching to something which allows us to express more complex importance measurements for packages. In fact, d-i and its task system have been a step in that direction, so we maybe should evaluate if we want to formalize it a bit more and get it into policy to replace priorities. required and important are both needed by debootstrap, so can't be gotten rid of (though they could be changed to use some other field/name). Priority: standard currently contains: at, bc, dc, lsof, file, less, sharutils, strace dnsutils, ftp, host, ssh, mtr-tiny, finger, w3m, whois doc-debian, doc-linux-text exim, mailx, mutt, procmail, mime-support, mpack gettext-base, locales pciutils perl (not just perl-base), python reportbug selinux policy That seems a pretty reasonable set of functionality to put on all Debian boxes (unless the admin specifically says otherwise), afaics. It might be sensible to replace ftp with lftp these days, though. And I'm not sure what happened to the exim v postfix defaults discussion a little while ago, and maybe procmail/mpack aren't all that necessary. It also includes, but afaics, probably doesn't need to (anymore): ispell, dictionaries-common, iamerican, ibritish, wamerican m4, texinfo (???) mtools (access unmounted msdos filesystems, not NTFS though) nfs-common, portmap (enables mounting NFS shares) pidentd (is IDENT still used on today's internet, with all its NAT?) openbsd-inetd (needed by pidentd) tcsh (people who remember what it is know how to install it) time (???) telnet (netcat is important, as is wget) But as far as default installs for anything of any real meaning, I just don't see Priorities as being relevant anymore. Cheers, aj signature.asc Description: Digital signature
Re: priorities
On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote: Anthony Towns [EMAIL PROTECTED] writes: It also includes, but afaics, probably doesn't need to (anymore): ispell, dictionaries-common, iamerican, ibritish, wamerican m4, texinfo (???) texinfo possibly for info and dating from the days of needing to have an info reader to get real documentation for many of the GNU tools? But texinfo only includes: /usr/bin/texi2pdf /usr/bin/texindex /usr/bin/texi2dvi /usr/bin/ginstall-info /usr/bin/makeinfo The info browser is in the info package (which is priority:important)... mtools (access unmounted msdos filesystems, not NTFS though) Probably obsolete at this point. pidentd (is IDENT still used on today's internet, with all its NAT?) openbsd-inetd (needed by pidentd) identd is still used somewhat, mostly with IRC, but it's almost certainly optional rather than standard. tcsh (people who remember what it is know how to install it) Having a /bin/csh falls into present on all Unix systems and likely to provoke WTF reactions if not there. Which isn't a requirement for standard, but hey... Also, I'm pretty sure that tcsh is very comfortably the second-most-used interactive shell, way ahead of zsh, on Linux systems. #rank nameinst vote old recent no-files 2 bash 69802 58316 2596 8885 5 305 mailx 62713 16369 30995 15343 6 438 tcsh 60057 9042 37123 13886 6 488 mutt 59151 7662 32588 18895 6 555 mtools 60985 6035 40222 14723 5 570 reportbug 61436 5780 40836 14816 4 588 time 61236 5539 41423 14267 7 885 dash 11100 2615 7604 876 5 1014 zsh 3801 2002 1366 431 2 Of course, there's half a zillion different zsh packages that should have their stats combined, but whatever. I find it pretty surprising that somewhere between 1 in 8 systems (vote/max(inst)) and 1 in 5 systems ((vote+old)/vote) still have tcsh used recently tbh. time (???) Likewise. time is a standard Unix program. And which is a built-in on bash, tcsh and zsh, so doesn't seem terribly useful most of the time... (not dash though) Cheers, aj signature.asc Description: Digital signature
Re: priorities
On Thu, Dec 06, 2007 at 10:26:11AM -0600, Manoj Srivastava wrote: I'm not sure if there's any point to continuing to try to make sure that nothing = optional conflicts with anything else = optional. Hmm. Can you elaborate on this, please? Is it because it is too hard to achieve this? Or you think this is something unattainable even in theory? It is a nice invariant, if only we could get it to hold for Debian. I don't have any statistics to back the following up. I don't think we have been doing it very thoroughly for years now, so at best it's something that's often true, but not always (eg, there's only one mail-transport-agent of priority optional or higher -- except there's actually three: exim4-daemon-light (standard), exim4-daemon-heavy and nbsmtp). It requires us to choose a winner amongst similar packages that use Conflicts instead of alternatives, when really we'd rather leave that up to our users (or people maintaining derivative distros, or tasksel or whatever). I don't think it serves an actual point -- back in the day saying install everything of priority optional or above was a feasible way of getting a really powerful and useful Debian system. That's not really plausible anymore thanks to the sheer amount of software. optional -- all the good software in the world extra -- obscure stuff If we are removing the invariant that everything in optional should not conflict with anything else in optional, and extra is where the conflicing packages go, is there any reason to retain extra as a distinct section? Being able to classify software as Unless you have a really special need, you don't want this still seems somewhat useful to me. I also somewhat like the idea of having your average free software package in main at a higher priority than your average non-free software package. Cheers, aj signature.asc Description: Digital signature
Re: priorities
On Thu, Dec 06, 2007 at 05:09:36PM -0600, Manoj Srivastava wrote: On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff [EMAIL PROTECTED] said: I use time in benchmarking scripts. I do not find the built in time to be a substitute for the good old fashioned time command. Observe: Why are either of those reasons to have /usr/bin/time on every Debian machine? We're not talking about removing the package entirely... (For comparison: nc/telnet are basic diagnostic tools to investigate why you can't run apt-get, reportbug, an email program and a web browser are needed for contacting remote humans if you get into problems installing or recovering a Debian system) Cheers, aj signature.asc Description: Digital signature
Accepted debian-maintainers 1.5 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 27 Nov 2007 03:14:00 +1000 Source: debian-maintainers Binary: debian-maintainers Architecture: source all Version: 1.5 Distribution: unstable Urgency: low Maintainer: Debian Maintainer Keyring Team [EMAIL PROTECTED] Changed-By: Anthony Towns [EMAIL PROTECTED] Description: debian-maintainers - GPG keys of Debian maintainers Closes: 452011 452600 452605 452719 452861 452881 Changes: debian-maintainers (1.5) unstable; urgency=low . [ Joey Hess ] * Added Debian maintainer Aurélien GÃRÃME. Closes: #452600 * Added Debian maintainer Arthur Loiret. Closes: #452605 * Added Debian maintainer Jelmer Vernooij. Closes: #452881 . [ Anthony Towns ] * Changed Katrik Mistry's deletion changeset to include links to mails requesting removal and a summary of the reason. * Added Debian maintainer Adriaan Peeters. Closes: #452861 * Added Debian maintainer Ondrej Certik. Closes: #452719 * Added Debian maintainer Asheesh Laroia. Closes: #452011 Files: 169dfabe964ce452360f6f0281128317 979 misc extra debian-maintainers_1.5.dsc 925e2284dafd03bff1b0ea191bbbdc8d 419447 misc extra debian-maintainers_1.5.tar.gz 647d67cf570bfb9b3e6f788f8cd0fa5c 238962 misc extra debian-maintainers_1.5_all.deb e89807be043af81bdb8493c26efe774c 300434 raw-keyring - debian-maintainers_1.5_all.gpg -BEGIN PGP SIGNATURE- iD8DBQFHSv93Oxe8dCpOPqoRArWUAJ4xSruQO/10pNTRWGurJyehQnwpxQCeIEVg cRu2l/3/Jx12OciC5isNtgc= =g4DV -END PGP SIGNATURE- Accepted: debian-maintainers_1.5.dsc to pool/main/d/debian-maintainers/debian-maintainers_1.5.dsc debian-maintainers_1.5.tar.gz to pool/main/d/debian-maintainers/debian-maintainers_1.5.tar.gz debian-maintainers_1.5_all.deb to pool/main/d/debian-maintainers/debian-maintainers_1.5_all.deb debian-maintainers_1.5_all.gpg byhand -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debian-maintainers 1.0 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 18 Nov 2007 18:13:54 +1000 Source: debian-maintainers Binary: debian-maintainers Architecture: source all Version: 1.0 Distribution: unstable Urgency: low Maintainer: Debian Maintainer Keyring Team [EMAIL PROTECTED] Changed-By: Anthony Towns [EMAIL PROTECTED] Description: debian-maintainers - GPG keys of Debian maintainers Changes: debian-maintainers (1.0) unstable; urgency=low . * Add James Troup, Michael Beattie, Ryan Murray, Joerg Jaspert, Brian Nelson, Marc Brockschmidt, and Christoph Berg to the Uploaders: field to enable automatic byhand acceptance. Files: 6cd9f8ef1fa26ba4db7c0b667046c73e 1048 misc extra debian-maintainers_1.0.dsc ccbc47f20a4d53053e9359787f36925f 169901 misc extra debian-maintainers_1.0.tar.gz 46eb0e705443086288fd1b2a00156588 32964 misc extra debian-maintainers_1.0_all.deb 71e49a5a21da0537542a801fcbfcf04f 41984 raw-keyring - debian-maintainers_1.0_all.gpg -BEGIN PGP SIGNATURE- iD8DBQFHP/SvOxe8dCpOPqoRAo0QAJ9QKeQNxdKgyqef2IsVdQ9a9MZrKQCdH/0+ cVz7bwnJXDBLECWkhEIKS/E= =zkL2 -END PGP SIGNATURE- Accepted: debian-maintainers_1.0.dsc to pool/main/d/debian-maintainers/debian-maintainers_1.0.dsc debian-maintainers_1.0.tar.gz to pool/main/d/debian-maintainers/debian-maintainers_1.0.tar.gz debian-maintainers_1.0_all.deb to pool/main/d/debian-maintainers/debian-maintainers_1.0_all.deb debian-maintainers_1.0_all.gpg byhand -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debian-maintainers 0.07 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 14 Nov 2007 00:53:27 +1000 Source: debian-maintainers Binary: debian-maintainers Architecture: source all Version: 0.07 Distribution: unstable Urgency: low Maintainer: Debian Maintainer Keyring Team [EMAIL PROTECTED] Changed-By: Anthony Towns [EMAIL PROTECTED] Description: debian-maintainers - GPG keys of Debian maintainers Changes: debian-maintainers (0.07) unstable; urgency=low . * Update README advice on where to send advocacy mails. Files: 9c971e077d8e4989039d89dca52b2ea9 718 misc extra debian-maintainers_0.07.dsc b2305c1e6a8cb2eafe1e779791cae357 183725 misc extra debian-maintainers_0.07.tar.gz 1a90f63030b03bde72e9aaee0215d3fb 9664 misc extra debian-maintainers_0.07_all.deb 8996dfe784f4fbe28262a1ddb83f451c 6116 raw-keyring - debian-maintainers_0.07_all.gpg -BEGIN PGP SIGNATURE- iD8DBQFHObrOOxe8dCpOPqoRAmEDAJ9eSV+9jtuezIbgYjGKE/RlueybBgCePCsd jLNjt3nFmIrinupu+eCI3qw= =rVOb -END PGP SIGNATURE- Accepted: debian-maintainers_0.07.dsc to pool/main/d/debian-maintainers/debian-maintainers_0.07.dsc debian-maintainers_0.07.tar.gz to pool/main/d/debian-maintainers/debian-maintainers_0.07.tar.gz debian-maintainers_0.07_all.deb to pool/main/d/debian-maintainers/debian-maintainers_0.07_all.deb debian-maintainers_0.07_all.gpg byhand -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debian-maintainers 0.07 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 14 Nov 2007 00:53:27 +1000 Source: debian-maintainers Binary: debian-maintainers Architecture: source all Version: 0.07 Distribution: unstable Urgency: low Maintainer: Debian Maintainer Keyring Team [EMAIL PROTECTED] Changed-By: Anthony Towns [EMAIL PROTECTED] Description: debian-maintainers - GPG keys of Debian maintainers Changes: debian-maintainers (0.07) unstable; urgency=low . * Update README advice on where to send advocacy mails. Files: 9c971e077d8e4989039d89dca52b2ea9 718 misc extra debian-maintainers_0.07.dsc b2305c1e6a8cb2eafe1e779791cae357 183725 misc extra debian-maintainers_0.07.tar.gz 1a90f63030b03bde72e9aaee0215d3fb 9664 misc extra debian-maintainers_0.07_all.deb 8996dfe784f4fbe28262a1ddb83f451c 6116 raw-keyring - debian-maintainers_0.07_all.gpg -BEGIN PGP SIGNATURE- iD8DBQFHObrOOxe8dCpOPqoRAmEDAJ9eSV+9jtuezIbgYjGKE/RlueybBgCePCsd jLNjt3nFmIrinupu+eCI3qw= =rVOb -END PGP SIGNATURE- Accepted: debian-maintainers_0.07.dsc to pool/main/d/debian-maintainers/debian-maintainers_0.07.dsc debian-maintainers_0.07.tar.gz to pool/main/d/debian-maintainers/debian-maintainers_0.07.tar.gz debian-maintainers_0.07_all.deb to pool/main/d/debian-maintainers/debian-maintainers_0.07_all.deb debian-maintainers_0.07_all.gpg byhand -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debian-maintainers 0.06 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 31 Oct 2007 18:40:58 +1000 Source: debian-maintainers Binary: debian-maintainers Architecture: source all Version: 0.06 Distribution: unstable Urgency: low Maintainer: Debian Maintainer Keyring Team [EMAIL PROTECTED] Changed-By: Anthony Towns [EMAIL PROTECTED] Description: debian-maintainers - GPG keys of Debian maintainers Changes: debian-maintainers (0.06) unstable; urgency=low . [ Joey Hess ] * Explicitly build-depend on gnupg rather than rely on jetring pulling it in, since runtests uses it directly. * Documentation/process updates. * Add links to new advocacy mails posted for DMs for whom we previously used the nm.debian.org advocacy status. . [ Anthony Towns ] * Add more advocacy mails and add the corresponding Debian uid of the advocates. * Sigh, actually update the index file and sig too. Files: 063090f34ec4a5f0c65ac53024b4cdf6 718 misc extra debian-maintainers_0.06.dsc 976547e9d9346b2251f93576cd0caea7 183662 misc extra debian-maintainers_0.06.tar.gz deaf43c7a1e3022676ba9658aaa4c172 9576 misc extra debian-maintainers_0.06_all.deb 8996dfe784f4fbe28262a1ddb83f451c 6116 raw-keyring - debian-maintainers_0.06_all.gpg -BEGIN PGP SIGNATURE- iD8DBQFHKEY1Oxe8dCpOPqoRAp4qAKCZ2TpTKGrjQ3SRoEv58NnM27Xb/ACeK26a gzQGsMJfSgEXW3itnZRJ1OQ= =pRgJ -END PGP SIGNATURE- Accepted: debian-maintainers_0.06.dsc to pool/main/d/debian-maintainers/debian-maintainers_0.06.dsc debian-maintainers_0.06.tar.gz to pool/main/d/debian-maintainers/debian-maintainers_0.06.tar.gz debian-maintainers_0.06_all.deb to pool/main/d/debian-maintainers/debian-maintainers_0.06_all.deb debian-maintainers_0.06_all.gpg byhand -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debian-maintainers 0.01 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 18 Oct 2007 02:27:20 +1000 Source: debian-maintainers Binary: debian-maintainers Architecture: source all Version: 0.01 Distribution: unstable Urgency: low Maintainer: Debian Maintainer Keyring Team [EMAIL PROTECTED] Changed-By: Anthony Towns [EMAIL PROTECTED] Description: debian-maintainers - GPG keys of Debian maintainers Changes: debian-maintainers (0.01) unstable; urgency=low . [ Joey Hess ] * Initial release. * Added Debian maintainer Miriam Ruiz . [ Anthony Towns ] * Added Debian maintainer Fathi Boudra * Added Debian maintainer Cameron Dale * Invoke gpg --list-keys in debian/rules build to make sure $HOME/.gnupg exists. Possibly should set GNUPGHOME instead. Files: 05fd134163a67cdae45aae804216f1e5 694 misc extra debian-maintainers_0.01.dsc 63ea19782522a4481b57dbe910957024 395993 misc extra debian-maintainers_0.01.tar.gz 1de8829f8ddf92558eddf048926c3c30 9124 misc extra debian-maintainers_0.01_all.deb 8996dfe784f4fbe28262a1ddb83f451c 6116 raw-keyring - debian-maintainers.gpg -BEGIN PGP SIGNATURE- iD8DBQFHFjukOxe8dCpOPqoRArbuAJ9u0cGUevcBGRdM0oDIDMRkBbXdAwCfbkI9 m50nkdLmKkzyV8VC+RkA5ig= =GCk2 -END PGP SIGNATURE- Accepted: debian-maintainers_0.01.dsc to pool/main/d/debian-maintainers/debian-maintainers_0.01.dsc debian-maintainers_0.01.tar.gz to pool/main/d/debian-maintainers/debian-maintainers_0.01.tar.gz debian-maintainers_0.01_all.deb to pool/main/d/debian-maintainers/debian-maintainers_0.01_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gzip 1.3.12-3.2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 14 Oct 2007 23:50:29 +1000 Source: gzip Binary: gzip Architecture: source amd64 Version: 1.3.12-3.2 Distribution: unstable Urgency: low Maintainer: Bdale Garbee [EMAIL PROTECTED] Changed-By: Anthony Towns [EMAIL PROTECTED] Description: gzip - The GNU compression utility Closes: 434275 Changes: gzip (1.3.12-3.2) unstable; urgency=low . * Non-maintainer upload. * Stop zdiff from dropping cmp's output. Patch thanks to Jorg-Volker Peetz (Closes: Bug#434275) Files: 4d9e2e82fbebb222e13ddaf14bd43bfd 546 utils required gzip_1.3.12-3.2.dsc 8b9929d026560db3aba3510b8abc6bfd 20326 utils required gzip_1.3.12-3.2.diff.gz 45bb3bcee439121c9dce0fa843394bf1 106486 utils required gzip_1.3.12-3.2_amd64.deb -BEGIN PGP SIGNATURE- iD8DBQFHEiRzOxe8dCpOPqoRApaZAJ9ojJx/TZ2rzlgKXmd3pFsNe2dc2ACcDJaZ 7krN5v9cgCroBd+qfCmHtSM= =27y8 -END PGP SIGNATURE- Accepted: gzip_1.3.12-3.2.diff.gz to pool/main/g/gzip/gzip_1.3.12-3.2.diff.gz gzip_1.3.12-3.2.dsc to pool/main/g/gzip/gzip_1.3.12-3.2.dsc gzip_1.3.12-3.2_amd64.deb to pool/main/g/gzip/gzip_1.3.12-3.2_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pristine tarball generator
On Wed, Oct 03, 2007 at 03:38:54PM +0300, Faidon Liambotis wrote: There's also --rsyncable which is appears mostly (if not only) on Debian and unfortunately can't be figured out from the headers. Multipart gzips would also not work even though I haven't yet find any. Both these are cases where the .gz file is equivalent to cat'ing two (or more) .gz files together, I would've thought, and should be able to be dealt with as such, possibly just by checking for a header, or by previously matching gzip output suddenly not matching anymore? Cheers, aj signature.asc Description: Digital signature
Re: pristine tarball generator
On Tue, Oct 02, 2007 at 04:15:44PM -0400, Joey Hess wrote: BTW, the next release of pristine-tar will support generating pristine gz files too, so will fully support pristine .orig.tar.gz. Regenerating pristine gz files from small deltas is quite a lot trickier, and currently works for about 99% of the .orig.tar.gz files in the Debian archive. Many thanks to paravoid for making it happen.. Oh wow, that's cool. Any chance of a post/blog on how that was achieved? Cheers, aj signature.asc Description: Digital signature
Re: Packages with RFCs deleted
On Thu, Sep 20, 2007 at 09:46:47AM +0900, Charles Plessy wrote: Le Wed, Sep 19, 2007 at 01:08:40AM +1000, Anthony Towns a ?crit : For what it's worth, we don't do that. References I'm aware of: http://lists.debian.org/debian-legal/2003/05/msg00092.html http://lists.debian.org/debian-legal/2003/05/msg00149.html Hi Anthony, thank for the links. So in the end, am I right to say that, since the point of view of the FTP team is that RFC are software, orig.tar.gz files which contain them fail to comply the DFSG and therefore are not accepted in main? It's not my POV that RFCs are software, no :) It is the POV of ftpmaster that everything in main, whether it be a .deb, .tar.gz or .diff.gz needs to meet the DFSG though. As you can probably tell from the second link above, I'm not personally very invested in having .orig.tar.gz's be pristine versus removing unused non-free stuff from them, but the position we've taken in the past has been to insist on it being removed, and I think it's worth being consistent. Cheers, aj signature.asc Description: Digital signature
Re: Packages with RFCs deleted
On Tue, Sep 18, 2007 at 11:24:21PM +0900, Charles Plessy wrote: Le Mon, Sep 17, 2007 at 03:35:15PM -0500, Peter Samuelson a ?crit : I fully agree with what you write. Indeed what I support is not to ignore the RFC or other similarly non-free, non-programmatic files, but to document them in the copyright file, tolerate them in the source package, exlude them from the binary packages in main, and ship them in non-free if they are non-redundant and provide an added value. For what it's worth, we don't do that. References I'm aware of: http://lists.debian.org/debian-legal/2003/05/msg00092.html http://lists.debian.org/debian-legal/2003/05/msg00149.html Packages in main can build packages in contrib, provided they don't rely on any non-free packages to do so (so you can build a data installer package, eg, but that's about it). So non-free stuff can't be included in the main source package, and non-free stuff can't be used to build a package in main, nor can it be generated from a source in main. Cheers, aj signature.asc Description: Digital signature
Re: Debian's Linux kernel continues to regress on freedom
On Wed, Sep 12, 2007 at 02:07:55PM +0200, Luk Claes wrote: What about adding clarifications, what about summarising parts of the RFC? You don't need a free license to do either of those things, though, which is part of the reason why... It's more about the freedom to fix things or to use things than it is to make it buggy... It's also not only about Debian, but in fact more about the freedom of our users to modify RFCs... ...modifying RFCs isn't a freedom most people value even slightly. Which is fine -- we distribute a bunch of stuff that doesn't have that freedom to people who appreciate having it packaged anyway -- that's one of the reasons we have non-free. If making RFCs available via non-free is awkward, or we're worried adding more interesting stuff to non-free might encourage people to use other non-free stuff they wouldn't otherwise, those are technical problems we can fix by improving our packaging tools and making non-free more fine-grained respectively. What's the value in continuing to debate this topic? [0] Cheers, aj [0] Well, other than giving us an excuse to call each other wackos and morons, of course... signature.asc Description: Digital signature
Re: Debian's Linux kernel continues to regress on freedom
(-kernel dropped) On Wed, Sep 12, 2007 at 03:47:43PM -0500, Manoj Srivastava wrote: On Wed, 12 Sep 2007 21:07:43 +0300, Faidon Liambotis [EMAIL PROTECTED] said: Sune Vuorela wrote: On 2007-09-12, Faidon Liambotis [EMAIL PROTECTED] wrote: You're not checking for copyright violations or for non-free stuff in all other packages. I obviously meant all other *existing* source packages, i.e. all the uploads that don't pass through NEW. Can you point me to violations of the DFSG, please? Just for the record, if other developers are repeatedly adding non-free stuff to packages in main without due care, it'd be technically plausible to run those uploads through NEW processing too. But we have lots of checks to ensure DDs are able to do a good job of sorting out free and non-free stuff, and the system of expecting updates to be good the vast majority of the time, filing bugs when they're not, and having them properly fixed seems superior in every way, so I'd /really/ hope nothing like that will be necessary. I think every maintainer is supposed to be doing this for their own packages. Only when we have evidence that the maintainers are not doing their job does Joerg have to spend his time doing their job for them. NEW processing is a second chance to catch these and other problems before they hit the distro; it's not something that can replace maintainers catching the problems at first pass. It's more like manual retraining of a spam filter -- you don't want it to be the common case that ftpmaster reviews licenses anymore than you want most spams to be looked at by a human. But just as you do want a human checking over at least a selection of messages and any misclassifications to make sure your spam filter's on track, if we want our policies on copyrights to be consistent, we want to be regularly reviewing the copyrights of some sampling of packages, and we want to pay closer attention to any edge cases where we notice things aren't going the way we want them to. ftpmaster samples packages with new names for copyright and other problems; most of the rest of the time we (ftpmaster, -legal, etc) only investigate further if there's some evidence there's an actual problem. At the point where it hits ftpmaster, though, the aim seems to me to be at least as much to ensure maintainers are doing the checks right (and consistently throughout Debian) as to do the checks themselves. Cheers, aj, who right atm can't think of a much higher compliment than comparing something to his spam filter signature.asc Description: Digital signature
Re: Why no Opera?
On Tue, Sep 11, 2007 at 06:26:45PM +0200, Juliusz Chroboczek wrote: The Firefox monoculture is doing a lot of harm to our community. So, I don't know what monoculture you're referring to. Popcon gives 23000 for iceweasel, 500 for dillo, and 18 for netsurf. (Correct me if I'm wrong, but I believe that konqueror statistics are not significant since it's also used as a file manager.) It's certainly significant as a web browser, just hard to get meaningful statistics about it from popcon. You missed epiphany though, unless you're really talking about a Gecko monoculture. nameinst vote old recent no-files iceweasel 41897 22448 6839 1260010 epiphany-browser 32506 11395 7614 13493 4 w3m53921 6902 30282 16735 2 konqueror 15175 5983 5437 3754 1 lynx 14852 5558 7840 1451 3 iceape-browser 4802 1974 1706 1122 0 dillo 1810 519 1015 275 1 w3m-img 721 0 0 0 721 If that's not a monoculture, I don't know what is. Depends on whether you define monoculture as only one strain, or as a preponderance of one strain. The problem with the former is that if you have a problem that wipes out that strain, you don't have any alternatives that can take over. In the latter case, you do have alternatives, it's just that it's going to involve a lot of growth on their behalf to do the taking over, which is still hard, but much easier. Old link: http://azure.humbug.org.au/~aj/blog/2004/05/11 Cheers, aj signature.asc Description: Digital signature
Re: virtualbox-ose: package hijack?
On Wed, Sep 05, 2007 at 11:39:42AM +0200, Daniel Baumann wrote: Michael Meskes wrote: I have no idea what Daniel really did on the package. I did about 90% of the inital packaging. Which just left the last 90% of the packaging, I guess. Patrick uploaded removed me from changelog in the two last uploads (virtualbox 1.4.0svn4130-dfsg-1 and virtualbox-ose 1.4.0svn4130-dfsg-1 that is) without notifying me. In all previous uploads to NEW, I was in the co-maintainer. FWIW, the uploads of virtualbox to NEW were: |virtualbox_1.4.0-1_amd64.changes: 20070618213209|process-unchecked|Moving to new 20070709174342|process-new|rejected |virtualbox_1.4.0svn3946-dfsg-1_i386.changes 20070801121715|process-unchecked|Moving to new 20070801222037|process-new|rejected |virtualbox_1.4.0svn3946-dfsg-2_i386.changes 20070801143204|process-unchecked|Moving to new 20070801222028|process-new|rejected |virtualbox_1.4.0svn3946-dfsg-1_i386.changes 20070802113206|process-unchecked|Moving to new 20070812215652|process-new|rejected |virtualbox_1.4.0svn4130-dfsg-1_amd64.changes 20070824113207|process-unchecked|Moving to new 20070827060822|process-new|rejected The .dsc from the first 3946-dfsg-1 above (1st August) listed: Maintainer: Patrick Winnertz [EMAIL PROTECTED] Uploaders: Philipp Hug [EMAIL PROTECTED], Marvin Stark [EMAIL PROTECTED] If you weren't involved in the uploads to NEW over the past month to notice, it seems reasonably fair to say you weren't co-maintaining the package. If that's something that was just a one month thing, fine; but it's not the end of the world either way. |virtualbox_1.4.0svn4130-dfsg-1_amd64.changes 20070830124706|process-unchecked|Moving to new 20070901080307|process-new|Accepting changes |virtualbox_1.4.0svn4130-dfsg-1_i386.changes 20070901194714|process-unchecked|Accepting changes |virtualbox-ose_1.4.0svn4130-dfsg-1_amd64.changes 20070903134705|process-unchecked|Moving to new 20070903173435|process-new|Accepting changes |virtualbox-ose_1.4.0svn4130-dfsg-1_i386.changes 20070904094702|process-unchecked|Accepting changes |virtualbox-ose_1.5.0-dfsg-1_i386.changes 20070905054704|process-unchecked|Accepting changes |virtualbox-ose_1.5.0-dfsg-1_amd64.changes 20070905070206|process-unchecked|Accepting changes Then doing an upload that goes to a new upstream revision, adds code which doesn't have a license at all, let alone a DFSG-free one, without consulting the people you're claiming to be co-maintaining the package with doesn't sound very impressive either. Upstream is generally cooperative and understands the problems, hence I see this a bit more relaxed (for the next few days only, until it's sorted out). However, if ftp-master do disagree, I'll can re-upload 1.4.0, superseeding the 1.5.0 upload. Personally, I don't think you should be even considering uploading anything right now -- the above seems to me to have been some pretty bad judgement calls, and the contents of an Uploaders: field or the lack of a proper license for something upstream intends to be free software can all wait for a day or two. For a package that's been in unstable for under a week to require a renaming due to trademarks, have a hijack war and thread on -devel, and start getting new upstream versions with non-DFSG code strikes me as pretty unimpressive all round, really... Cheers, aj signature.asc Description: Digital signature
Re: virtualbox-ose: package hijack?
On Wed, Sep 05, 2007 at 02:49:25PM +0200, Raphael Hertzog wrote: On Wed, 05 Sep 2007, Patrick Winnertz wrote: This was no good work which was quicked hacked together. I'm sorry, but when I upload a new upstream release of Django, I don't check every new file. It's all good that you do it, but it's not necessarily a requirement and I find it hard to blame daniel for that. Uh, Daniel included a file that doesn't have a DFSG license in an upload to main. That's not good enough. Reviewing diffs of upstream changes is one way to avoid it; it's not the only way, but if you're not going to do it, you still need to accept the blame for the mistakes you let through. Patrick's packages got a pretty thorough grilling for copyright issues by Joerg in the rejections from NEW over the past month, that Daniel's upload wrecked that work is something to be really quite embarassed about, not to excuse because it'd take a lot of effort to avoid. Cheers, aj signature.asc Description: Digital signature
Re: what happened to social contract?
On Wed, Aug 29, 2007 at 10:41:10PM -0400, [EMAIL PROTECTED] wrote: # Our priorities are our users and free software I must have misunderstood, I thought this was what Debian was all about. Which is fine, but the problem is there's so many ways of working on those priorities that nobody can be involved in all of them. So once you've picked some particular ways, your challenge is to find some other folks that're likewise interested; and since you've picked something that involves non-free stuff, you've immediately ruled out most of the people who're active on this list, who're here because they want to make a completely free operating system, for which opera just isn't relevant. At this point non-free stuff's probably specialist enough to warrant it's own group, rather than using -devel/-legal/etc, so it's easy to find the handful of other people who're interested in non-free stuff in Debian to make it work as well as possible. OTOH, while I'm interested in improving non-free, my priorities are elsewhere too atm... Cheers, aj signature.asc Description: Digital signature
Re: proposed release goal: DEBIAN/md5sums for all packages
On Fri, Aug 17, 2007 at 05:05:28PM -0500, Peter Samuelson wrote: I'd opt for dpkg generating the checksums upon _extracting_ the .deb file. [...] Where's the code for that? Changing write_filelist_except to update a new .md5 control file ought to be possible. You'd probably want to add a *newhash to struct filenamenode, though, and fill it out when unpacking, but working out the hash while unpacking (rather than running over every file to be unpacked twice) would mean hax0ring into the fd_fd_copy() invocation in tarobject() (archives.c), which seems tricky. Cheers, aj signature.asc Description: Digital signature
Re: /bin/sh diversions
On Wed, Aug 01, 2007 at 10:13:38PM -0700, Steve Langasek wrote: On Thu, Aug 02, 2007 at 06:54:49AM +0200, Mike Hommey wrote: diversions are far from being atomic. True, but it is persistent across upgrades and doesn't require any particular support from the package. Is it a bug (or a missing feature) that diversions aren't atomic? The --rename option to dpkg-divert means it can be done atomically if dpkg-divert is clever enough, at least in all the ways that count. Cheers, aj, surprised it's not already atomic signature.asc Description: Digital signature
Re: /bin/sh diversions
On Wed, Aug 01, 2007 at 06:00:21PM +0200, Pierre Habouzit wrote: On Wed, Aug 01, 2007 at 12:53:03PM -0300, Henrique de Moraes Holschuh wrote: OTOH, specifically using something else than /bin/sh for a fast POSIX-with-the-extensions-Debian-mandates shell (i.e. forget posh, but dash is good) does NOT need /bin/sh to point to it, so it can't trip on such issues caused by external factors outside of Debian's control. Afaict ubuntu did the change, and the sky didn't fell apart. It did cause a bunch of problems for Ubuntu users, though: https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463 Cheers, aj signature.asc Description: Digital signature
Re: Bug#435058: ITP: smolt -- Fedora hardware profiler
On Sun, Jul 29, 2007 at 08:25:58AM +0200, Mike Hommey wrote: On Sat, Jul 28, 2007 at 09:28:46PM -0400, Ricky Zhou [EMAIL PROTECTED] wrote: Package: wnpp Severity: wishlist Owner: Ricky Zhou [EMAIL PROTECTED] * Package name: smolt Version : 0.9.8.3 Upstream Author : Mike McGrath [EMAIL PROTECTED] * URL : https://hosted.fedoraproject.org/projects/smolt/ * License : GPL Programming Lang: Python Description : Fedora hardware profiler The Fedora hardware profiler is a server-client system that does a hardware scan against a machine and sends the results to a public Fedora Project turbogears server. The sends are anonymous and should not contain any private information other than the physical hardware information and basic OS info. What is the added value for Debian users of sending these informations *to Fedora* ? Modifying the package so it sends the data to a Debian server running the same/similar software to Fedora's sounds reasonable though. Not completely sure that there's much benefit to maintaining separate servers for Debian data and Fedora data -- but *reporting* the data separate would probably be a good thing if the proportion of Fedora users with smolt is significantly different to the proportion of Debian users with smolt. (That's because making a mistake on that score would be both easy if the data were combined, and lead to wrong comparisons between total Debian and Fedora users, to the detriment of whoever has the lower proportion of users running smolt, which would presumably be Debian) Integrating it with pop-con (or vice-versa) would be interesting. Cheers, aj signature.asc Description: Digital signature
Re: stupid dependencies on update-inetd
On Sun, Jul 29, 2007 at 03:59:13AM +0200, Marco d'Itri wrote: On Jul 29, Russ Allbery [EMAIL PROTECTED] wrote: So is anything ever valid other than openbsd-inetd | inet-superserver as a dependency? I keep getting confused on the rules around using virtual packages. Would rlinetd | inet-superserver be okay? Would Formally yes, but I do not think there is a reason for a package to choose a different default. inet-superserver all by itself be okay? No, but this would be taken care of by virtual-package-depends-without-real-package-depends (which explains the part you are missing). Isn't openbsd-inetd priority:standard? That's enough to make the real-package unnecessary, afaik (and that lets the default inetd be changed simply by changing the priorities of the packages, rather than the dependencies of lots of packages). I would've thought the Build-Dependency stuff isn't relevant for inetds. I think policy has had confusing advice on this for a long time now -- ttbomk the only cases where an explicit dependency on a real package is either useful or needed is when all the alternatives can be installed concurrently and are at priority:optional so that dselect and apt can select one easily when there's no hints to be taken from the priority levels; and when consistency is useful for the buildds, for much the same reason. Cheers, aj signature.asc Description: Digital signature
Re: Looking for new FTP assistants
On Tue, Jul 10, 2007 at 12:02:32AM +0200, Lucas Nussbaum wrote: People really do use both package priorities and sections still for selecting packages in the package management tools, and it would be great to have them fixed. Seconded. I tried once to install all optional packages at the same time (which is supposed to work). But it failed miserably. But couldn't all the override stuff be something that could be worked on by people without being FTP assistants? Exporting the overrides list to $RANDOM_VCS and allowing people to submit patches in an easy way could be enough... Committing override changes is already an ftpassistant task, normally individually, but I think bulk changes are possible too. Personally I'd look very favourably on anyone who wanted to become an ftpassistant who not only went and found the problems with the overrides but also prepared and verified a list of the changes needed (this package needs its priority raised; that one needs its priority lowered; once all these changes are made there aren't any new problems because having raised one package one of its dependencies also needs its priority raised; etc). We have a bunch of override change requests outstanding, mostly because the ftpmaster alias is so absurdly heavily spammed that they get lost in the noise; having more structured checking of priorities/sections that someone actually took the time to monitor would probably make that much better. (The idea being that you'd detect a problem when the override differs from the value in the package, and then either annotate that with a bug number because the package's value is wrong, or fix the override to match the package) ATM no one's paying any real attention to this; which does mean that there's not a lot of help to be had in working out how to make it better. OTOH, it also means it's not that hard to become an expert on the topic (no one else really knows that much about it) or the most effective contributor (no one else is doing much)... :) Cheers, aj signature.asc Description: Digital signature
Re: ftp.debian.org lacking behind and p.d.o too
On Mon, Jul 02, 2007 at 01:44:04PM -0400, Anthony Towns wrote: On Mon, Jul 02, 2007 at 02:48:34PM +0200, Daniel Leidert wrote: Can someone tell me, why ftp.debian.org is lacking behind? Apparently it's out of disk :( This is now fixed. Thanks for the report. Cheers, aj signature.asc Description: Digital signature
Re: ftp.debian.org lacking behind and p.d.o too
On Mon, Jul 02, 2007 at 02:48:34PM +0200, Daniel Leidert wrote: Can someone tell me, why ftp.debian.org is lacking behind? Apparently it's out of disk :( (250G for the current archive, 44GB for archived suites, 11G for an old packages.d.o, and the remaining 15G or so looks like it's used in .~tmp~/ directories from incomplete --partial rsyncs) Cheers, aj signature.asc Description: Digital signature
Accepted ifupdown 0.7~alpha2 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 18 Jun 2007 15:47:21 +0100 Source: ifupdown Binary: ifupdown Architecture: source powerpc Version: 0.7~alpha2 Distribution: experimental Urgency: low Maintainer: Anthony Towns [EMAIL PROTECTED] Changed-By: Anthony Towns [EMAIL PROTECTED] Description: ifupdown - high level tools to configure network interfaces Changes: ifupdown (0.7~alpha2) experimental; urgency=low . * Add command line interface options (ifup -o foo=bar eth1). Yay! * Switch to using iproute instead of ifconfig/route. Thanks to Andrew Pollock. * Drop support for kernels prior to 2.1.100 (and that don't have NETLINK for iproute). * Drop support for specifying a netmask in static inet interfaces. * Bump DH_COMPAT to 4 (from 1!) Files: b6f5758f6a14b2c8ff2fe23cb147d5f4 537 admin important ifupdown_0.7~alpha2.dsc a6af3aebbdd6e8c5eacd193c06c56f1d 377554 admin important ifupdown_0.7~alpha2.tar.gz 76cdfa4d6a0a2aba36b6b50a68c16a8a 52920 admin important ifupdown_0.7~alpha2_powerpc.deb -BEGIN PGP SIGNATURE- iD8DBQFGdxX5Oxe8dCpOPqoRAgYVAJ4qJcPSYNvpcEMpzPZLXi0NfUcTawCfetUX K6Y3L/YqEWtJ4+mkNhTWhTk= =zWxk -END PGP SIGNATURE- Accepted: ifupdown_0.7~alpha2.dsc to pool/main/i/ifupdown/ifupdown_0.7~alpha2.dsc ifupdown_0.7~alpha2.tar.gz to pool/main/i/ifupdown/ifupdown_0.7~alpha2.tar.gz ifupdown_0.7~alpha2_powerpc.deb to pool/main/i/ifupdown/ifupdown_0.7~alpha2_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ifupdown 0.7~alpha1 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 18 Jun 2007 15:47:21 +0100 Source: ifupdown Binary: ifupdown Architecture: source powerpc Version: 0.7~alpha1 Distribution: experimental Urgency: low Maintainer: Anthony Towns [EMAIL PROTECTED] Changed-By: Anthony Towns [EMAIL PROTECTED] Description: ifupdown - high level tools to configure network interfaces Changes: ifupdown (0.7~alpha1) experimental; urgency=low . * Add command line interface options (ifup -o foo=bar eth1). Yay! * Switch to using iproute instead of ifconfig/route. Thanks to Andrew Pollock. * Drop support for kernels prior to 2.1.100 (and that don't have NETLINK for iproute). * Drop support for specifying a netmask in static inet interfaces. * Bump DH_COMPAT to 4 (from 1!) Files: df2329c88a69f4d7efaa76ec898162ee 537 admin important ifupdown_0.7~alpha1.dsc 477323fc8b668ff0b99a3e82e1fcc511 377529 admin important ifupdown_0.7~alpha1.tar.gz 070337841fe3aa97c7b7bb5db29123cf 52932 admin important ifupdown_0.7~alpha1_powerpc.deb -BEGIN PGP SIGNATURE- iD8DBQFGdp7pOxe8dCpOPqoRAsIiAJ4hOTcFhqPWo1MJvCZ5KulOuKalcgCfbz6S yFAmb+XwDfhZfT4J5itRi84= =/38S -END PGP SIGNATURE- Accepted: ifupdown_0.7~alpha1.dsc to pool/main/i/ifupdown/ifupdown_0.7~alpha1.dsc ifupdown_0.7~alpha1.tar.gz to pool/main/i/ifupdown/ifupdown_0.7~alpha1.tar.gz ifupdown_0.7~alpha1_powerpc.deb to pool/main/i/ifupdown/ifupdown_0.7~alpha1_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License discussions in Debian (was: discussion with the FSF: GPLv3, GFDL, Nexenta)
On Mon, Jun 04, 2007 at 11:08:39PM +0200, Frank K?ster wrote: Anthony Towns [EMAIL PROTECTED] wrote: See, given that as an ftpmaster I'm one of the folks who actually implements the policy on what's accepted into main or not, it's not my loss at all. I think that Debian would very much benefit if there was a place (call it [EMAIL PROTECTED] or whatever) where our policy with regard to individual software's licenes could be discussed with the input of those who actually set this policy: the ftpmasters. Yes, that's the main reason for my involvement in this thread. Though it's not just ftpmasters, it's Debian developers in general; so that we don't end up with a consensus on debian-legal (or in ftpmaster) that doesn't match the views of Debian as a whole. AFAICS, that means welcoming developers who don't know the difference between subpoena and summons, not using it as a reason to ignore them completely. If debian-legal isn't the place for you (and AFAIK none of the other ftpmasters is a regular), maybe we need a new start and a different format. I used to be a regular on -legal, and I'm still subscribed. My views (such as people who aren't speaking on behalf of the project shouldn't make it sound like they are...) don't seem particularly welcome though, so I tend not to bother. I don't see any particular reason to think a new start or format would help much, but I'm open to suggestions. Cheers, aj signature.asc Description: Digital signature
Re: Reasonable maximum package size ?
On Tue, Jun 05, 2007 at 06:28:53PM +0900, Charles Plessy wrote: Le Tue, Jun 05, 2007 at 10:09:07AM +0200, Michael Hanke a ?crit : My question is now: Is it reasonable to provide this rather huge amount of data in a package in the archive? An alternative to a dedicated package would be to provide a download/install script for the data (like the msttcorefonts package) that is called at package postinst. I recently had a heretic idea that I did not dare to submit yet: we could port fink to Debian, and use it to build .debs from info files shipped in Debian packages in main, and sources downloaded from upstream's FTP sites. Some thoughts on constraints: * it's better to have stuff distributed by Debian than sourced elsewhere; we're a distribution, distributing is What We Do * it's better for users to have stuff in .deb's, so they don't have to worry about different ways of managing different stuff on their system * some large data sets are just compiled -- it can be good to distribute a small amount of source in a .deb and compile it on the user's machine. * some large data sets are compiled but it takes long enough that we don't want to do it on user's machines, so we have the usual source/deb situation here, and that's fairly easy too. * (***) many data sets don't fit those patterns though, but instead are just a bunch of data that needs to be shipped to users. doubling that by having it duplicated in a .orig.tar.gz and _all.deb is less than ideal * some data sets have large raw data and large compiled versions, so need a large source _and_ a large .deb containing different info. nothing much to be done in that case, though * (###) having .deb's generated on a user's system means they can't use aptitude or apt-get to install them easily; having .deb's generated on mirrors requires smart mirroring software rather than just rsync or similar; having .deb's generated by the maintainer or buildds requires both the source and .deb to be mirrored separately; having .deb's be the source format requires converting from the upstream source format adding complexity and making it harder to trace how the packaging worked For the ***'d case, it seems like having a debian.org mirror network that distributes unprocessed data tarballs, that're converted into debs and installed on user's systems would be workable. I don't see how we could resolve that with the ###'d concern though. If we were to resolve the ###'d concern by changing apt etc, we could conceivably add foobar_1.0.7-1_data.tar.bz2 files to the archive in the existing sections, for instance, and providing some form of Packages.gz file for them. I guess an evil solution to *** that doesn't cause problems with ### would be to create a dummy source package that Build-Depends: on the exact version of the package it builds, so that uploads include a basically empty .tar.gz that just has instructions on how to download new versions of the data, and an unprocessed copy of the actual data converted to _all.deb form. That'd give the correct behaviour for all the tools we've got, avoid unnecessarily duplicating the data, and maybe not be *too* confusing. Hrm, actually, I kind-of like that approach... I'm not sure if avoiding duplicating the data (1G of data is bad, but 1G of the same data in a .orig.tar.gz _and_ a .deb is absurd) is enough to just use the existing archive and mirror network, or if it'd still be worth setting up a separate apt-able archive under debian.org somewhere for _really_ big data. Bug#38902 for hysterical interest, btw. Cheers, aj signature.asc Description: Digital signature
Re: License discussions in Debian
On Tue, Jun 05, 2007 at 12:07:52PM +0200, Frank K?ster wrote: You could ask Anthony whether you're allowed to publish his reasons on -legal. That would do the project a great favor. You could just ask me directly you know... ] I thought choice-of-venue is non-free by default? ] ] Via Simon Phipps's talk at debconf, we've got Sun on the record ] as interpreting choice of venue as only being relevant when the ] two parties to a suit both have a presence in multiple jurisdictions, ] including the one that's chosen, which means it's not a problem at all. ] ] For the other case, even if Sun did want to make German laws apply to ] an Australian or similar, I don't think that holds up as a claim anyway. I don't think that's a particularly useful addition to what's already been in this thread. Well, beyond as inspiration as to how much better -legal could do if it was willing to come to with a conclusion of the form this license is flawed in these novel ways, but none of them are enough to make it non-free for Debian. Cheers, aj signature.asc Description: Digital signature
Re: License discussions in Debian
On Tue, Jun 05, 2007 at 09:08:31AM +0200, Frank K?ster wrote: That's true, as an ideal. In reality, you can't expect every DD or even maintainer to subscribe to -legal except when they've got a particular problem to discuss. Sure, but you don't need or want that. All you need is an unbiassed sampling of developers to participate, which is to say the list needs to be just as open to extremist opinions from people who think the GFDL is completely free as people who think the GPL is actually non-free. AFAICS the only way that's going to happen is by taking the view that Debian's definition of free as per the DFSG-free is just one view you can take, and that people who take alternative views -- whether stricter or more liberal, whether focussed on legal details or ignorant of them in favour of just doing stuff -- are still worth listening to, even though their views on what's free or not may well be fundamentally different to Debian's. If the only question is is this free or not? then you're going to get turf wars because there's just no middle ground, and whoever gets to make that decision controls the debate. Even just having analyses take the form of these are the consequences, personally I'd avoid them, though Debian doesn't think the problem's a big enough deal to worry about; Don agrees with me, but Francesco doesn't seems like it'd be most of the way there. But as it stands, -legal's analysis seems to me more to fit the mold of this is conceivably bad in some circumstances, not the same as anything in any good licenses, therefore it's non-free, and that's all there is to it. I'm not sure, however, that this is the general attitude on -legal: I've never encountered it. Take Don and Jordi G. H.'s exchange this month: ] If you disagree with the determination of the Developers, you can ] easily install the work from non-free, or cease supporting Debian in ] its entirety. The choice is yours, really. ] ] Our way or the highway isn't a nice thought either. Do you really ] think that the DDs that voted against putting the GFDL in non-free ] should fork off too? Debian is the best distro out there, and I'm very ] loyal to it, but I'malso very unhappy with its treatement of the ] GFDL, and I think this horrible mess should be fixed. And no, to be fair, skimming the archives does indicate it's not the general attitude at all, and I'm also pleased to have stumbled across an example of Michael Poole noting he's not a lawyer or DD while giving his thoughts/advice. Equally, if -legal were working 100% how I wanted it to, that'd just mean I'd be happy to trust it implicitly and wouldn't pay any attention to it at all; which probably means that the times I do pay attention now are the times it's going (imo) severely wrong, which is going to produce a pretty biassed view on my behalf. Comparing Ted Tso's and Thomas Bushnell's views, as cited on LWN some time ago [0] is probably a good reference point too. Having disagreements like the current one over choice of venue be escalated into claims that are one set of DDs are trying to prov[e] they are Holier Than Stallman, or another are sell[ing] out [freedom] isn't very helpful if we want the DFSG to be useful at helping upstreams and users. In *my* opinion, and ymmv etc, analysing licenses so that we can say: * These are almost certainly the effects, which barely anyone disagrees with (GPL is viral, CDDL is viral and GPL incompatible, QPL requires modifications to be made as patches) * These are things that might not happen, but that you might be concerned at (GFDL stuff can't be encrypted, or even have Unix permission bits set? CDDL leaves you vulnerable to nuisance suits in foreign countries) * These are ways you can avoid some of the drawbacks (use MIT instead of the old BSD license, explicitly limit when choice of venue comes into play) * Different people and organisations may reasonably have different views on the acceptability of various effects -- the FSF view the Affero GPL and GFDL as free, OSI views the APSL as free; and you may want to make a different choice to any or all of those organisations. Debian's choices are focussed on ensuring we can develop and distribute a high quality operating system that works for our users. This may mean we'll accept some licenses that aren't as free as we'd like them to be, in some cases (such as licenses with patch clauses, or obnoxious advertising clauses, etc). From what I've seen, debian-legal isn't very good at accepting anything less free than it'd like. Which is pretty understandable, but not really helpful either in advocating Debian's views (which are more accepting), or in working with other groups (upstream or down) who don't have the patience for endless nitpicking. It could also be a lot better
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Tue, Jun 05, 2007 at 02:09:06AM -0700, Steve Langasek wrote: Why doesn't it matter? If I've been sued because of something I've actually done that infringed the license, then surely the DFSG and Debian shouldn't be concerned with that (other than the question of whether what I've done is something that the DFSG requires of copyright holders); but if I'm being sued over something I *didn't* do, [...] If you're going to be sued for something you didn't do, and lose because in your absence you're assumed to have done it, why not go the whole hog and just have them assert you've used/distributed a program you've never actually used/distributed? AFAICS this is an issue only when there's a not completely trivial possibility that you have actually violated the license. - If I don't have the resources to fight the case in a court overseas, I risk summary judgement; the cost to me is the liberty to travel unmolested to Australia at some future date when I might have resources for travel. Speaking of which, the linux.conf.au 2008 CFP is open: http://linux.conf.au/presentations I suspect that anyone who can get their paper accepted will be able to get their travel costs covered by one of LCA, Debian or the Linux Foundation. (Kickass segues 'r' us) * If I get sued in Oregon, I have a wide range of local resources at my disposal to help me find appropriate legal representation; if I get sued in Australia, I'm stretching my connections pretty thin to find and evaluate legal counsel, and this process is going to cost more time and money on my part (and may leave me with inferior legal counsel anyway in the end due to logistical issues) For Australia, assuming you were being sued over free software stuff that you'd be doing in good faith, I think we could do a fairly good job helping you out. * Effective realtime communication with the lawyer is more expensive (transoceanic phone calls), and more inconvenient due to timezone differences (fine, fine, not for *me*, but you know what I mean) Yes, Australian lawyers seem to be in a very inconvenient timezone for me... ;) As an analogy, suppose that a license included the following clause: By distributing the covered work, you agree that the copyright holder can compel you at any time to play in an on-line black jack tournament at his website, geekblackjackstars.net, with an initial ante of $100. Should Debian consider this to be a free license because the clause won't necessarily be invoked and because some people win at blackjack? Clearly not. BTW, that site doesn't seem to exist. The difference between blackjack and choice of venue is that in one case you're being compelled to do something, and in the other you're pre-determining an argument. AFAICS that breaks that analogy. Two different analogous licenses might be: By distributing the covered work, you agree that the copyright holder can sue you for violations of the license. If you distribute the covered work, the licensor agrees not to sue you in any jurisdiction other than Berlin, Germany. I'd consider both those to be clearly free. Choice of venue goes beyond either of them, certainly. But I'm still not seeing a way in which it goes so far beyond them as to become non-free. Heck, is choice of venue actually different to the combination of those clauses? Simon Phipps' argument, presented at debconf last year, is (aiui) that the clause only comes into play when both parties are organisations that cross multiple jurisdictions anyway -- in which case they're both presumed to have a presence in the given jurisdiction anyway, and could reasonably be expected to be following its rules, afaics. Has this opinion been confirmed by a lawyer on *SPI's* payroll, not just by one on *Sun's* payroll? :) TTBOMK, no. ITYM acting on behalf of SPI rather than on SPI's payroll btw. :) [...] The current clause, though, puts the copyright holder in the dealer's seat, and the house always wins. Well, that's only true over the long term, and I don't think it's necessarily true even over the long term for court cases. Cheers, aj signature.asc Description: Digital signature
Re: Reasonable maximum package size ?
On Tue, Jun 05, 2007 at 03:58:08PM +0200, Frans Pop wrote:
IMO it would be worth it if we could split out gigabytes of data from the
main archive and thus significantly reduce the bandwidth needed for
mirror syncs. Especially if that data is only used by an extremely small
subset of users/developers.
Hrm, packages larger than 50MB in sid/i386 (main, contrib and non-free) [0]:
Eclipse NLS: (76MB)
76498868 eclipse-platform-nls
Software: (104MB) (not arch:all)
104032026 gcc-snapshot
Clipart: (144MB)
144354894 openclipart-png
Documentation: (147MB)
52801680 context-doc-nonfree
94869090 koffice-doc
TeX: (192MB)
56200406 texlive-fonts-extra
56559816 tetex-src
79907246 texlive-latex-extra
Debug packages: (369MB) (not arch:all)
53959746 boson-dbg
55430908 icedove-dbg
56274922 koffice-dbg
57383550 libqt4-debug
59787420 iceape-dbg
86404478 libgl1-mesa-dri-dbg
Game data: (1,413MB)
52247006 nexuiz-music
52552812 scorched3d-data
60332050 vegastrike-music
63569974 fillets-ng-data
69398222 beneath-a-steel-sky
75266604 openarena-data
86669382 torcs-data-tracks
100913422 tremulous-data
103359260 freedroidrpg-data
132611332 vdrift-full
138455838 nexuiz-data
140544192 vegastrike-data
161313228 fgfs-base
176337384 sauerbraten-data
Largest deb in unstable is sauerbraten-data at 176MB, largest
arch-specific deb is atlas3-test for ia64 at 158MB. Total size of debs
in sid/i386 is 17,259MB, so packages above 50MB make up about 10%-15%
of the archive by size already.
Moving game data elsewhere would require some way for games in main to
depend on data elsewhere.
Moving -dbg data elsewhere would presumably require some way to upload
to both archives in a single step, and we'd want to keep them reasonably
tightly coupled.
Not moving -dbg stuff elsewhere would mean there'd be no need to worry
about supporting arch-specific stuff, afaics. OTOH, if we did support
arch-specific stuff, maybe it'd make sense to move the game engines
into the other area along with the data if there's no point to having
the engine without a huge amount of data to use it with.
The advantages would be: [...]
- make it possible to not include such data on the regular binary CDs,
but for example on separate arch-independent data CDs
Particularly for game data, it seems like it'd make more sense (at least
from a user's pov) to include the game code and the game data on the same
CD, given they'd always be installed at the same time. I've no idea if
that could realistically be done, or if there's any point thinking about
it 'til later though.
Cheers,
aj
[0] find dists/sid -name Packages.gz |
xargs zcat |
awk '/^Package:/ {P=$2} /^Architecture:/ {A=$2} /^Size:/ {S=$2} /^$/
{if (S 5000) { print S, P, A }}' |
sort -n | uniq | less
signature.asc
Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, Jun 04, 2007 at 07:55:18PM +0200, Francesco Poli wrote: On Mon, 4 Jun 2007 19:30:36 +1000 Anthony Towns wrote: And I mean, I know what a GR is for, why are you telling me? It's still not a *good solution* for deciding these things; it's a last resort, and the only other options we currently have a ftpmaster decides and it's obvious to pretty much everybody. I'm rather surprised to hear you saying that, since you seem to have been the proposer of GR-2006-001... Sometimes you have to choose the best of a lot of bad options. When that happens, it's often good to spend some time trying to get better options for the future. [...] The official position of Debian is what we allow in main. That is to say? Bugs never happen?!? Nothing can possibly enter main by mistake or overlook?!? Of course it can -- official positions can be wrong, can be made by mistake or without due care, and can be changed. [...] Unfortunately, since -legal in general becomes an amorphous set of individuals who reserve the right to hold whatever opinions they like whenever questioned, there's little hope of -legal ever learning from its mistakes. Are you going to call the orwellian thought police, since I hold my *own* opinions?!? You don't need to call the thought police, you only have to think of them and they'll know to come! Cheers, aj signature.asc Description: Digital signature
