Re: Validating tarballs against git repositories
On Sun, Mar 31, 2024 at 08:16:33AM +0200, Lucas Nussbaum wrote: > On 29/03/24 at 23:29 -0700, Russ Allbery wrote: > > This is why I am somewhat skeptical that forcing everything into Git > > commits is as much of a benefit as people are hoping. This particular > > attacker thought it was better to avoid the Git repository, so that is > > evidence in support of that approach, and it's certainly more helpful, > > once you know something bad has happened, to be able to use all the Git > > tools to figure out exactly what happened. But I'm not sure we're fully > > accounting for the fact that tags can be moved, branches can be > > force-pushed, and if the Git repository is somewhere other than GitHub, > > the malicious possibilities are even broader. > > I wonder if Software Heritage could help with that part? Yeah (provided that archival happens at the right moment) you can use Software Heritage APIs to detect, for instance, git history rewrites as and also commits moving from one branch/tag to another. It occurs to me that in the Guix/Nix packaging model, where they note down the commit of interest in their packaging recipe, you'll also automatically discover if a commit disappeared from upstream repo without needing a lot of extra tooling/integration (although not if it has moved between branches). However, you need a backup place to retrieve the commit from in case it disappear or gets rewritten upstream (Guix uses Software Heritage for this). Cheers -- Stefano Zacchiroli . z...@upsilon.cc . https://upsilon.cc/zack _. ^ ._ Full professor of Computer Science o o o \/|V|\/ Télécom Paris, Polytechnic Institute of Paris o o o <\> Co-founder & CTO Software Heritageo o o o /\|^|/\ https://twitter.com/zacchiro . https://mastodon.xyz/@zacchiro '" V "'
Accepted beancount 2.2.0-3 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 21 Apr 2019 17:00:36 +0200 Source: beancount Binary: beancount python3-beancount python3-beancount-dbgsym Architecture: source all amd64 Version: 2.2.0-3 Distribution: unstable Urgency: medium Maintainer: Python Applications Packaging Team Changed-By: Stefano Zacchiroli Description: beancount - Double-entry accounting from text files python3-beancount - Double-entry accounting from text files - Python module Closes: 923606 Changes: beancount (2.2.0-3) unstable; urgency=medium . [ Santiago Vila ] * patches/0003: Ignore FileNotFoundError from self.tmpdir.cleanup(). Fixes a FTBFS problem which happens randomly (Closes: #923606) Checksums-Sha1: 0cb6b75d9fd8c99b59c41b8b57c4c49b37fafb28 2361 beancount_2.2.0-3.dsc 1dfb06e21c410f00b121bbeb0e70b1132a5b4e1b 5216 beancount_2.2.0-3.debian.tar.xz 7757c1936446017956ad2cf0036a9c4592e7b603 168140 beancount_2.2.0-3_all.deb c3b94f32a976708a506f819618560afb7ce422c1 11067 beancount_2.2.0-3_amd64.buildinfo 8b828abb465b0844cab95be5afeca991c23cd925 50860 python3-beancount-dbgsym_2.2.0-3_amd64.deb f8401956361fa48fc475a4794e49d02c8a3f0bad 487848 python3-beancount_2.2.0-3_amd64.deb Checksums-Sha256: 3201d91b5fd391921f544c2b7dd60a08132a0ee08ce1bba395cdcd504269926a 2361 beancount_2.2.0-3.dsc 2ca065765f732f440ef63834363f5575d27f3f1389027a7ab27c981d8b26064d 5216 beancount_2.2.0-3.debian.tar.xz 41fdbc7fd95d834004fb9f753e4435fb3bc9f5a5a6b4a829e02af9176d7c72b6 168140 beancount_2.2.0-3_all.deb 306359507eb4ef6a6229e5010b94fcf0a86fb02f6f7ce08544d95ff23773bc09 11067 beancount_2.2.0-3_amd64.buildinfo d8bec6b9091033c1b9a9dc866d0366436a368df116cff0f25bb89ac6394295f5 50860 python3-beancount-dbgsym_2.2.0-3_amd64.deb cff04ab80ff87380e3a4a740a8d66057a26ac6db5b55a862fd4b8c3667d66770 487848 python3-beancount_2.2.0-3_amd64.deb Files: 7c8860c08bb1603760dc6205cdc7ff8e 2361 utils optional beancount_2.2.0-3.dsc 754f565dda8d9a5bd919f61ef4c0d4ce 5216 utils optional beancount_2.2.0-3.debian.tar.xz df9f1e2e4e3711efef81888516a85ed3 168140 utils optional beancount_2.2.0-3_all.deb 52472fcb40e96b16b079aad5fc4379ad 11067 utils optional beancount_2.2.0-3_amd64.buildinfo 69a78a650e0d5007efd361cb1e970001 50860 debug optional python3-beancount-dbgsym_2.2.0-3_amd64.deb b6e71fab339275d36cd3ba414b37bf76 487848 python optional python3-beancount_2.2.0-3_amd64.deb -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAlzEVPkQHHphY2tAZGVi aWFuLm9yZwAKCRB8fkKPk0EnmVxHD/wIbH5kahi7Ug8b9NZ71Grd+HntD2sxxXbP LIVoQ3HKEWGRRqRA0xdMT2ZSE+4F8c8eUjRPDCdr0T2sTaUjPXGlpB8/h9NNBzTT p/aCD/kYI18L1METCwzxdCbuGHCmJkG+DeW09/5skFQwRlei8ysxAS7Z0ULJp2Qs RHpxqj9HSkkkR6JuG9/z/RVeppfcu1b58u1NBquCGCv6n4fVlK2gef5X+Wzmrp5T NadDq3gaXwjxVBaJLO/E+IegFfBPbpx4/lPT3Uio+0XB2tznXpxumriJFR2DfCcq XK6b6rb0mYk9KimtccA35SzrSChvudrBrHAmqPbTlMN1+oQzO/fsYUE943bOiLlS HCD7z0dcGryVbFutFRn6+UjHwjkmK0U9Ka0J5zuXrBA6a+85TitPJUF2GvsRiHzd WUC8OWnoWILM4TF0eRDMypZtWX2kso/aeDQObmEjdosyV0Mhd8RSt/50p3HsL/lv KRzONOnhsMnKLNjFPWj/54fRR3X5LiBOtESa7GVwHtzM9atf5aeQ2Q/h0HvwsqKi ZuE2rjhude/3r2mAX/o4OPLHTkzYi6McPD16ClXda4eUZt6WsIfep5/TR18qi6Qu yWKZgwnH2BCNwlAgVNX/VSRtGsDPAJmTlfJjpo/99uksk3LtBg0xGFGiGGHsqY62 z6pwckW00A== =/1Zo -END PGP SIGNATURE-
Accepted fava 1.9-4 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 14 Jan 2019 10:20:52 +0100 Source: fava Binary: python3-fava Architecture: source all Version: 1.9-4 Distribution: unstable Urgency: medium Maintainer: Python Applications Packaging Team Changed-By: Stefano Zacchiroli Description: python3-fava - Web interface for the double-entry accounting tool Beancount Changes: fava (1.9-4) unstable; urgency=medium . * generate manpage with help2man and ship it * rules: do not ship __pycache__ dirs as part of help files Checksums-Sha1: 646c3cbbc96ef6a30a967c2ed23f61eaaca83539 2213 fava_1.9-4.dsc 2261a3647a6a0668fd12961c0573f851072bb4b2 3228 fava_1.9-4.debian.tar.xz f927e0429a5d79267476b6791580a19629ad367b 7689 fava_1.9-4_amd64.buildinfo c8e449f27255d819abe7fc41354cc71a76d39199 471364 python3-fava_1.9-4_all.deb Checksums-Sha256: 538fa9c62d287d6b89def76de9b135b4be2129170b86d5e556b669e286624290 2213 fava_1.9-4.dsc 187d76eb5f919857bff8cc38351cb304bbe3713b5617d09b2ebc1cc1754e4e50 3228 fava_1.9-4.debian.tar.xz 30a42f4ea5f5beca80d156c65655c624c61055cc7abf9fc3a01a38bcbf4b97f1 7689 fava_1.9-4_amd64.buildinfo e84d5f7da9bbeb53e2201bc1ec6066f488aaccf4e5e299552dc94366266b0069 471364 python3-fava_1.9-4_all.deb Files: 8df100b7230edf01dbb0f392026f6a83 2213 python optional fava_1.9-4.dsc 4c5fbaae35c4e9e2dc804e2d8da6cd13 3228 python optional fava_1.9-4.debian.tar.xz dc695810d98b25000aa0b047e39daf58 7689 python optional fava_1.9-4_amd64.buildinfo cb17a48f4416240c947c97eff8776837 471364 python optional python3-fava_1.9-4_all.deb -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAlw8Va8QHHphY2tAZGVi aWFuLm9yZwAKCRB8fkKPk0EnmUQGD/4xC0WLd85CaGgV40rQmSbQVGuYiazQfZ7i ugk4oX7UiDd9SlkZKGaDsX8weSW3gNdxKyrx/3nCZneaGJexjSweiwMAmIqGM1lf 0VcHu3VX0NjH1q5EdnJ6Lxx28q00KBdEwMckQxuEA6To9yWz/fjRBedU9iI/546u 9Niha66LWVDG3UJcGpcTyoKF6aHMS7VsMMEF7AAS15WoPj9DOcWRyBIWj98a+mlh 82R6N1i2JFnxR18V+3Ai5HxyngEC4BYI5i0ulwXWfOnkudCgEs1vMYVprY2mANOn YqwgmrgMh3WLCyHXgriCFMc1UnKw8X6RvT9LQJYb0vtWgaJmZno7/pwl7tImJzs0 y8QozVBGLds0uYxXQSO6pHkk/E/Bp79YqZHZQJngL0Urpy6DlBxBetHZvqmvNCkv g7upSQgXmcymZ+BOpv/aVdNIp0vlSGL21ztvUMyWvSkULUvvcB/V4f9sdGhDKTvm q7Ik8+nrhUTRTKO6nQZ6ysufJhHCiTPLGAIKlNXW0fH7Pa9jJbm5M+6TeUGTMmgZ AxKmowCzUiyyoKd1Mom+85QJZsvdCbNOOV+KbVqpMZoTZxNYYNhhXuqE1BBBjT5u E06XlFHRkeL481wd/qKe90SSh5K+fBNBygRTXHhV5v/H8RNfGJRIWThaWbFRRdUx KsvRVKDwqg== =QuPT -END PGP SIGNATURE-
Accepted beancount 2.2.0-2 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 14 Jan 2019 10:01:37 +0100 Source: beancount Binary: beancount python3-beancount Architecture: source all amd64 Version: 2.2.0-2 Distribution: unstable Urgency: medium Maintainer: Python Applications Packaging Team Changed-By: Stefano Zacchiroli Description: beancount - Double-entry accounting from text files python3-beancount - Double-entry accounting from text files - Python module Changes: beancount (2.2.0-2) unstable; urgency=medium . * rules: do not ship *.picklecache files with Python examples (fixes build unreproducibility on armhf) * manpages/whatis.txt: provide sensible whatis entries for manpages (fixes lintian warnings) Checksums-Sha1: 826d97d90bbbc686cf02ea4623012f359c1a17aa 2361 beancount_2.2.0-2.dsc 877b223c9a7a12001d8896b1a57591cf6025da01 4904 beancount_2.2.0-2.debian.tar.xz fa03329d9d88774744fb17ab4eddd9da32172de9 167964 beancount_2.2.0-2_all.deb e45934d0c52fdcb39c486b4b568bc36713706b1f 11227 beancount_2.2.0-2_amd64.buildinfo 8133f7b6743791ee45909c1d11fcf280d8a9b181 50952 python3-beancount-dbgsym_2.2.0-2_amd64.deb d82e630058c829b426d862a0f8d29c1840492906 487608 python3-beancount_2.2.0-2_amd64.deb Checksums-Sha256: f8cd6537cb55560cf9f5b5ebe24bbf68d465f59d7d39c1c86d18d71df35b8925 2361 beancount_2.2.0-2.dsc 99332ec286f09947ff918f38b330229ebf11729d52e1a579d58a8cf45967a892 4904 beancount_2.2.0-2.debian.tar.xz 7a16e2a87ebd43054b7a8080a56ed77549c28521688c31cac861b76d6272c5d4 167964 beancount_2.2.0-2_all.deb 7891cc7ab6df25aafc6a37cfeb67aa8eb578197f8476bc4adcfd715b6c028c0d 11227 beancount_2.2.0-2_amd64.buildinfo 3fbe0f8f49663ccbd579168d379607c20e3d159c1a55031ac5ce4bdb2109f0cf 50952 python3-beancount-dbgsym_2.2.0-2_amd64.deb af913eb85c732418ec6e38a627e5ea16287c9e25dcaf85629df6ae5cb748947b 487608 python3-beancount_2.2.0-2_amd64.deb Files: 6d9a8b91acf4047fc4b2ffcb91a97041 2361 utils optional beancount_2.2.0-2.dsc b6e664af185c217e91f9489b805cbb71 4904 utils optional beancount_2.2.0-2.debian.tar.xz b5940d4741275ddafbf39611a358f2cc 167964 utils optional beancount_2.2.0-2_all.deb bad6e1d0762c3d3e89603f950ec2f3d2 11227 utils optional beancount_2.2.0-2_amd64.buildinfo 7a5534c381ca7b59b5db528dfb606f4c 50952 debug optional python3-beancount-dbgsym_2.2.0-2_amd64.deb 786e632aac9c1116d7424b99a82a044d 487608 python optional python3-beancount_2.2.0-2_amd64.deb -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAlw8VC8QHHphY2tAZGVi aWFuLm9yZwAKCRB8fkKPk0EnmZ7MD/9AmiETd2HJsYd8phq+cTceLvEGXGrHtPzL ekBoqxZ2QOaTD8a0ziQ3FtY6bdSJ4gim8anvelUqk42gwZTsXkClQGcu3uDRK94i LycvSeHECFtmJIwuYDhbks4Ba/bJ9tlSd+Q/2UkQ9whuvOWU/0KT3bvtUrLu/tXd HKvC2k5CwEHP1d0HgY1POMW6eTwhHCIOpE1eSZw+iZcj9y09KZzt1UyC3wSmjc/m TekesOIDXtcfzmp2fF0M/DD+wHP+iv2TLomTM/dHoOsfe58dxtg/JevawqfNdnOq ZX8kTLban5NV8lO8p5sBrr4I49byjOpGRru9/77X7zAoJFJqDS4DyBTnhYXh4L+x o1O/um0tX5212XZDoYasFQa/ai9N5PxmHpzJqWChAJAg8H1rGtVyFtbyQvko/2Cu LFJ9+87XPADkZw8p0cFu/tlrJfXLqwGzz/dGUXz7qznXjfvrhPS+Jojx+xonbQwb HgTOigEKOS6RWPKip29Q5cP0CuKK+pnpQDn5LjissKBHTN614OudWfVi18NxWy9I 90/cPll10K45sWZ5BFZe7Pk03jx+ZqYv6B7PVdHxjaTnUbdJqW4OjbTQEmxQYs3E E1Rw9Maj7uGu8a5SFo2WcPmoV7iY0R/d+6PcdKfUW5dB8GXHvILY+ssf8eVMo12x +P8DqPLUZw== =rBnH -END PGP SIGNATURE-
Accepted beancount 2.2.0-1 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 08 Jan 2019 21:31:17 +0100 Source: beancount Binary: beancount python3-beancount Architecture: source all amd64 Version: 2.2.0-1 Distribution: unstable Urgency: medium Maintainer: Python Applications Packaging Team Changed-By: Stefano Zacchiroli Description: beancount - Double-entry accounting from text files python3-beancount - Double-entry accounting from text files - Python module Changes: beancount (2.2.0-1) unstable; urgency=medium . * New upstream release. Checksums-Sha1: 53bacbd69c871272187b1cdd8aecbb55abd771f7 2361 beancount_2.2.0-1.dsc e867e58d164aa3cae5ebe7d9bc4e60b4486d2b8f 1521567 beancount_2.2.0.orig.tar.bz2 4861eaa872b3571ff530997f4cd666d0fb46841f 4376 beancount_2.2.0-1.debian.tar.xz 955186ab67017d1ecab93f1f8c9ec4945c5cd0a3 168004 beancount_2.2.0-1_all.deb aa169dddecfeaf70f9ac3c9106f83fd47263e42e 11221 beancount_2.2.0-1_amd64.buildinfo 426b4104ac0cd61e4c51fab215816e11ba220d9c 50940 python3-beancount-dbgsym_2.2.0-1_amd64.deb 6d6db66e82448ba504418440b6f737be9f82dc25 487544 python3-beancount_2.2.0-1_amd64.deb Checksums-Sha256: 7b70e02f7472070a54c0d033fa5b3cd12c624cbd40fe6d68ae171534dfdc1a8f 2361 beancount_2.2.0-1.dsc 2c43afa11d80e5a0ad537f580706bb116dd2398a8dffbae753bd37dc05173aeb 1521567 beancount_2.2.0.orig.tar.bz2 a8e6185312be5972360e09453466b0178d3fdd31c352d3a03e35bebbc4ad1d5b 4376 beancount_2.2.0-1.debian.tar.xz 62730e11419175f3dc68beaa28207a88f962ceabfddab86389c1854f1ec5eace 168004 beancount_2.2.0-1_all.deb bcbe72415966b740e747a4a2d8847563b0685155a5645e386416dd5f53eec343 11221 beancount_2.2.0-1_amd64.buildinfo 20708a8dafd091024afcaee6f399ad6ecbbf40721ab2db29ff2e87ab93acf634 50940 python3-beancount-dbgsym_2.2.0-1_amd64.deb 5d0fdaa636166493fc338dc07dec0feeff3fa7128000b3f3fae9a099219a88f3 487544 python3-beancount_2.2.0-1_amd64.deb Files: f4e1d4d84f155dcd75c66f9cae050788 2361 utils optional beancount_2.2.0-1.dsc 791a658720f91404454a1005cda80c4d 1521567 utils optional beancount_2.2.0.orig.tar.bz2 ba32c7c698922d1cdf0d226d08f8254d 4376 utils optional beancount_2.2.0-1.debian.tar.xz 18815db58e6785da6d9b98d63c64e73a 168004 utils optional beancount_2.2.0-1_all.deb 88d0d8c8c2340e26396af87c73eff49d 11221 utils optional beancount_2.2.0-1_amd64.buildinfo a5af5404d0f3ef4309325e1bec73b70f 50940 debug optional python3-beancount-dbgsym_2.2.0-1_amd64.deb 23f3f0a6331fbb3265f3900272ce3a66 487544 python optional python3-beancount_2.2.0-1_amd64.deb -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAlw1CW4QHHphY2tAZGVi aWFuLm9yZwAKCRB8fkKPk0EnmS5rEACnKvVrBgO/MFwOAUH+JWC0/pqqrrZZhAK3 FZp35fDlYu507qbRQoAyFoCzbjfC/Jk/lG4/Fru9b3mjJ+bB7zNJCZIww49iKzth N6dU2am4axY6ccaNLXEofkn/JsTYoPDF6CI2UlQEL8cjaXIbwEmGokBFu3h96ziz cPCzycmiojUCWlGwhNe9tAiVRNJQLL20a8Rlx2VjOxW+lZ3J9zZNaadbBPJ4JAu0 6QzE2GoSb52oD/qYkcfazurBBNez4toHRW+v9CjPEUbtHb3+uJ6Jgu4bzIBt9t1d YG8frhjN0tu3SFOziugrGmEZnn4sEErEIymXBa9B0SCS0n+6HzYGHstz+XA6V488 d1IcStzcnQoONOjcHtAN7oZq1CbNAgtbJBwtdyWFw2QYhj1uV4fCkZkfJ0USgUjc Ct89rrB2b6fUw9e/V4A9N+pLuEeP4xP42UvFNqCRRAWSc7/VImWHSa5T92Rl7xRa yZYxBMuQqrRhOFhpVkY+fIGJjyZ7oxKIV7WvJ1w5sPXG+SVMoOP4uo2KEo6ZWlTf 4Y56YNQrX9m4H4pCkKnc/yi+AwlUpckw/Z+20AIXQgfp9cO5YcprtbpFRdNI011a quBixeq61qDxLh+xA075heJqNtNQb3KVUwjviRrnxGL0tY5vMAZUILM1WTpO+dbI 9xviiMxTvg== =R4Cn -END PGP SIGNATURE-
Accepted fava 1.9-3 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 08 Jan 2019 14:43:10 +0100 Source: fava Binary: python3-fava Architecture: source all Version: 1.9-3 Distribution: unstable Urgency: medium Maintainer: Python Applications Packaging Team Changed-By: Stefano Zacchiroli Description: python3-fava - Web interface for the double-entry accounting tool Beancount Closes: 918641 Changes: fava (1.9-3) unstable; urgency=medium . * compat: bump debhelper level to 12 * control: add missing build-dep on cheroot * control: depend on the minimum cheroot version that ships egg-info (Closes: #918641) * drop python3-fava.pyremove, because fava.help is needed as a module Checksums-Sha1: 8e06e7037034a099a80ea5b13fd59d5cab200198 2194 fava_1.9-3.dsc e4fd40828431f7b81c1693e38cdfa0e386a02d2d 2876 fava_1.9-3.debian.tar.xz f247ea8fccecc14d9e33828e4c9b7f95287a4bba 7625 fava_1.9-3_amd64.buildinfo 418e579be5a04fb2628c76448a09e089c691124e 470504 python3-fava_1.9-3_all.deb Checksums-Sha256: bc2ce301e02a8c3ff272e4c5a6313410db9bdc89cf895b0a9dd8e3d68e766117 2194 fava_1.9-3.dsc 0f5c8c00c7bfbb1eebbfd95b766502e0dfc7a9a0f2a87057c74dafc35872a426 2876 fava_1.9-3.debian.tar.xz 30cdfb96dfdd013f54db6d673ade3440ca81f2fb03ef4e141973725d14d1d8aa 7625 fava_1.9-3_amd64.buildinfo 4e702f2342569b519bf23a547698420b9bd2fe3e640009067d6689243897092e 470504 python3-fava_1.9-3_all.deb Files: fe3dd907a996d20ee2318ed5c18b1081 2194 python optional fava_1.9-3.dsc 478ddedf795ad1c9c724ff5dc6474e0a 2876 python optional fava_1.9-3.debian.tar.xz c29426889ac74955c17bb7a08a6a5e87 7625 python optional fava_1.9-3_amd64.buildinfo c7ca27cb95c944a8380ef3853d50286a 470504 python optional python3-fava_1.9-3_all.deb -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAlw0rAkQHHphY2tAZGVi aWFuLm9yZwAKCRB8fkKPk0EnmcS4D/411z7i/aGOaGZtL1Tn5P17sl+FxRgh0Ii2 pVcjBUeHBlS8B/Jb+ix6Nn3m8D1gu7hLJnxradYN0E6Qi3iJIxSKSSydlYZpSnlX ktzsEi2pnSACxGRSrYAVe8wwkichXGATf1L2WehcIWj7c9D0cA0Apwp1fMZbWjxb y16tklLct1LfTKjVfg+ha9H8Nsl5zG79YYLYcQ4w6pitDChmrn5MtT7pVUS0QiNA OUAdMMT9OgNNet/8h7I3VfjaU/tspzJ+by5mT87TesmL5syUUXJRo9fwQFLCNa8w epFL5Y79GWksipMczkokjXLG1zqHT2hQN6iutJiJD5A8yeTW1P+D9/Q9FL4RV3rh B263cbYUd4t01BnbQKSEH7fTHXcDzFyREFpr+sUB5GvB3zPtbGLPCqhNsb6EhqhP 1fESY8S7LblmEiorJpT+FVX2m/W2DPK1E1bAHQYs6kwTE1YpfnQo/PSClytWwqe8 abt4ZjcToKHMTqtM+ixgib7U6e6or+Rz8dzRbzzoeKQO5hS4M7RXyaQEMqL3e+MO wOygfZVyPucuKRxAfzbiuDaNtmBKu1jLgJQrddSYmjY1Xtaaw7eXDx+1aEOOmPjh s2ouaJr13PmFQBFfig0rgZx4ic9NcNiX8fn1hnHo5wuNqZ8yjrPOmJ+U9ir7tSLG 3nK+OCiX2Q== =pcY8 -END PGP SIGNATURE-
Accepted beancount 2.1.3+hg20181225-3 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 07 Jan 2019 13:45:11 +0100 Source: beancount Binary: beancount python3-beancount Architecture: source all amd64 Version: 2.1.3+hg20181225-3 Distribution: unstable Urgency: medium Maintainer: Python Applications Packaging Team Changed-By: Stefano Zacchiroli Description: beancount - Double-entry accounting from text files python3-beancount - Double-entry accounting from text files - Python module Changes: beancount (2.1.3+hg20181225-3) unstable; urgency=medium . * rules: do not ship __pycache__ dirs with Python examples * control: bump Standards-Version, no changes needed * compat: bump debhelper level to 12 Checksums-Sha1: 4afcec64895eca2435ed557458b96850e928d5f3 2435 beancount_2.1.3+hg20181225-3.dsc c07d0ada03a3808cc4ac24743cb3d8a741997d07 4360 beancount_2.1.3+hg20181225-3.debian.tar.xz edf332d9d7cbf6c90afd0b50cd7c7c1c6d7ced1b 167688 beancount_2.1.3+hg20181225-3_all.deb 0ff6dda5e55d1bd50ba422fe14d5d7f8518daeeb 11375 beancount_2.1.3+hg20181225-3_amd64.buildinfo e9c3ef34ee1f910698077c7d777c8146e387a1e8 50956 python3-beancount-dbgsym_2.1.3+hg20181225-3_amd64.deb 3b259a0fc244ccf32bd44532cbf7b0d74dba7f9c 486156 python3-beancount_2.1.3+hg20181225-3_amd64.deb Checksums-Sha256: b571f658bf877fd7cf3871a8b89b391343c7d711d9cd6c9d8dfc47b0b3e0c5ce 2435 beancount_2.1.3+hg20181225-3.dsc 7b822ded4e79a19701ac7591181cf76b9ff0138c005e6b1dd7c8ba275c631cda 4360 beancount_2.1.3+hg20181225-3.debian.tar.xz 31a721884398849a03e638aba6a56ef58f0e26b44c20c9fb571a30471889badc 167688 beancount_2.1.3+hg20181225-3_all.deb 3e6e90dc6899cf6d2022d2d2f5d7e8102216908c92b628ac2224adf47f70c6ba 11375 beancount_2.1.3+hg20181225-3_amd64.buildinfo b7b0dfaec4a484d4b145690291ff83bf5abe78bd23de4ebaf4282542d35adb50 50956 python3-beancount-dbgsym_2.1.3+hg20181225-3_amd64.deb 4603283a9b2886fb855397daf94d2d779e167fbbd4ff1e46280e358e057cc599 486156 python3-beancount_2.1.3+hg20181225-3_amd64.deb Files: ed7ac626fc06974044080303c86d994a 2435 utils optional beancount_2.1.3+hg20181225-3.dsc 7c95c65cd357fac01336c5f65753ca2b 4360 utils optional beancount_2.1.3+hg20181225-3.debian.tar.xz abb90cd1315b6b1dfd4f46126d02f8cb 167688 utils optional beancount_2.1.3+hg20181225-3_all.deb bcab58e82256bf980a16844a4664adb3 11375 utils optional beancount_2.1.3+hg20181225-3_amd64.buildinfo ec71b096f136968fbd7badb1ba576d63 50956 debug optional python3-beancount-dbgsym_2.1.3+hg20181225-3_amd64.deb 108cde2c5e0a1c0608a0d5e768825520 486156 python optional python3-beancount_2.1.3+hg20181225-3_amd64.deb -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAlwzSqEQHHphY2tAZGVi aWFuLm9yZwAKCRB8fkKPk0EnmV+oD/wP4XaS1S2hJ0d0lsLLmgJFeMtAxkRl7kb0 NF3z2lU4sHOLQ+9zr3rTTOsUh12KMxetqGARo8lxeJp2Dg+MHZCE/yF4SjpPv8jy l2LF+ZjfyNGAIgzI3NbfuIENhCvEwAxvzcqQhD5xlG40vLCaarDRKTd05N2dwUXY 3Zz8A2nCP+JEXHvZG4Ch9BOQTv1BxnwwBevV95lFgP5U/8X1UVeQocwZ/XJ9j7wP HSmuWPL2FIDJI2Mvoqm6Od8dvFQqoxFMYVhX0YxGHKlbjWn6DOlZjLkGB8fpZPrg Y+//vRTJjyAYIJgFK8VOaiTdA/G8uqqHjc/uYPz6320gcUg0u4CKrl5wwnOKutxQ 9bvlBMCF4qt/osm1JuLDl7ypgnMT6VInVircpt7L+c3HKncZD/brjoXnhP6zFwMj vJldJzPTHcK6nc4Ek4VbJFnF8FcmHuBtFHJ2Zl4ctkjlwlGvUX5cL8I1GWWolwdJ LZNdEPYnnS5A0jfmz+E67vOJUPjLDYzhxMziMW/i+xz6ko9YOA9KhxyuPSWLvgub vkCcEpKDK/d2pI2uJzijAHW+U8lIoUF2umYc4TDhqrntvs4d4iafZCMaD4EOc7a/ eD6eJBMNBKbIHXZ2JK5CPO7+sk6DfAeBhSO5XN+TDPKoWBQV5Ksqd+3GvtijdPAu ePGSIZ61jw== =KZBE -END PGP SIGNATURE-
Accepted fava 1.9-2 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 01 Jan 2019 19:15:00 +0100 Source: fava Binary: python3-fava Architecture: source all Version: 1.9-2 Distribution: unstable Urgency: medium Maintainer: Python Applications Packaging Team Changed-By: Stefano Zacchiroli Description: python3-fava - Web interface for the double-entry accounting tool Beancount Closes: 917954 Changes: fava (1.9-2) unstable; urgency=medium . * debian/copyright: document additional copyright owners and licenses applicable to app.js (Closes: #917954) Checksums-Sha1: 964fdbce4b713b7cd6bca5d13e90a66fa5e4b553 2176 fava_1.9-2.dsc a394f85102d2dddb1f3aa3c97f929c52706e6130 2752 fava_1.9-2.debian.tar.xz 0cbd86dba1cc5d1dfa1aa86130695b4287dab0a3 7622 fava_1.9-2_amd64.buildinfo acdd002e2c549171019a5a05826ee41f3b0bd45c 465056 python3-fava_1.9-2_all.deb Checksums-Sha256: d6ef433797d3649668a6286f93295db1c1f29567c5c55a0587770bc376bf2874 2176 fava_1.9-2.dsc c45757d2737e0dabecb6b9a369576c8ff8b11755d8c71bd40f3abd5979bfcc8e 2752 fava_1.9-2.debian.tar.xz 37ba5d85d519535264213963aa0928fa6c1096caeea6993dde63d6864836faf8 7622 fava_1.9-2_amd64.buildinfo 92f4446067c88dd0acee573601e795bdf0fbd1f9e71a8fd9027c05df7641686c 465056 python3-fava_1.9-2_all.deb Files: aa40ceefaa70d327f45c2671be5a2ad4 2176 python optional fava_1.9-2.dsc 8061bbcc5d8ad1f92aca02c84ecdb4de 2752 python optional fava_1.9-2.debian.tar.xz 5db5c59b68e17902823db028dfd787c4 7622 python optional fava_1.9-2_amd64.buildinfo e34bfb9e98f17da4a79f1a919d0d68cd 465056 python optional python3-fava_1.9-2_all.deb -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAlwrsD8QHHphY2tAZGVi aWFuLm9yZwAKCRB8fkKPk0EnmWMaEACOSg7cZ8pcblKa6Nb6hkkLJTLwGuemXNE6 d2iw4KeK6ryBlBFL8w5F1FTDyYE3qaRFUE6CpNd3fzWba2sGKyimhAqdjHiR4doX v9C9VtncXy8hPCF2GGvAIlx4k+9xJDdntyE+PTKPMxwepY5AYvcpw3whSVGX19+M hGn5Tci6T5eiM2jEtrvd95ckJtSlUK8yd4hUzCQsRN3WKqnyxMzJMoT5hH2OV75I 2Pbie6Szk3qgsPFPst+NqQGsH/hQg4TtJn5wsbVAPwG2+YTgou1buo9UsAqyA5Lt DB5fxeAUuTXPzgz3saG5+lVGH9LvlH4V+c/U1PRzQfxd1EJlFGdEqm4NYRE3i45z xCoMZS20Jr2YCZ1Zzk5L48BaVBLu0YsoCJP3otiGghPTY8QpgU9rGbuRgL73iS+7 dxreK59pBvlgFur0Z3OYuPvSXOnkXajX7PXggvH+pcFBLKlvB/MsBjlDHb8E54M7 i7jT7yZ08Eo+nkrES5aanzzKN3OjWDsnpFhGG9tiFkwCrUnL3j2PkT97Be3bU0je yEGScOjrzzqIQNn6ADInAqXDLbxZ/TnllrkeV+8XQI68vTjp263EKCDjWCzjYtF+ SxxDPyo251yDGmy+wsV/DbuD0zcZFRNrQ18CW+3vZpLwOBQskNN0rBj3GEYCjy+Q omIhEeoVOQ== =h4m+ -END PGP SIGNATURE-
Accepted beancount 2.1.3+hg20181225-2 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 01 Jan 2019 19:09:05 +0100 Source: beancount Binary: beancount python3-beancount Architecture: source all amd64 Version: 2.1.3+hg20181225-2 Distribution: unstable Urgency: medium Maintainer: Python Applications Packaging Team Changed-By: Stefano Zacchiroli Description: beancount - Double-entry accounting from text files python3-beancount - Double-entry accounting from text files - Python module Closes: 917960 Changes: beancount (2.1.3+hg20181225-2) unstable; urgency=medium . * rules: simplify manpage dir creation * ship upstream examples * ship upstream info about where to find online documentation * copyright: release packaging files under GPL2 or later * copyright: document missing copyright and license for beancount/web/third_party/sorttable.js (Closes: #917960) Checksums-Sha1: d77f5688cc385e2d8abba435c32cac707b349166 2435 beancount_2.1.3+hg20181225-2.dsc 3962f5f2e06861cf53f97668af7f08755f2d87bd 4228 beancount_2.1.3+hg20181225-2.debian.tar.xz a7b2aa2f3d564783998ac8c709fd483dcba653a3 197996 beancount_2.1.3+hg20181225-2_all.deb 2b04de79cad35bceb063a996487c444cb81112b6 11408 beancount_2.1.3+hg20181225-2_amd64.buildinfo d25c06b68664d2fe0c37217fce32db1caba5dbe7 56220 python3-beancount-dbgsym_2.1.3+hg20181225-2_amd64.deb 39a338498bd3383c49c9a2e7ca5ec524fc4043de 486088 python3-beancount_2.1.3+hg20181225-2_amd64.deb Checksums-Sha256: e21b75f34f41d34dc6bd6a1f620b399d8424ba70503cf6d38aeaea61e505291b 2435 beancount_2.1.3+hg20181225-2.dsc d4de6c2f0506dfc76692b66112799deb2aca31970ff7e7e4be8bfe3b274d3a43 4228 beancount_2.1.3+hg20181225-2.debian.tar.xz 31cb8e8e4d5752bd5c24bcb28ec996c5a020eb0c73a5fc89819bc1dc0d04510b 197996 beancount_2.1.3+hg20181225-2_all.deb 6a9ca3b76e11ddf4667464c44b7f8f9166f639b0591ee3e1563e8db6378bce78 11408 beancount_2.1.3+hg20181225-2_amd64.buildinfo 066182cb0f149d72c9884faee178ab5b970d1ee5fad69ffa51ddb80f0cdbf947 56220 python3-beancount-dbgsym_2.1.3+hg20181225-2_amd64.deb f756a53f3e96fb991f1d6adaf489439982659c2dafe96a1607923b495de4f313 486088 python3-beancount_2.1.3+hg20181225-2_amd64.deb Files: fa7d897082062dc66b051cc03edbbf5a 2435 utils optional beancount_2.1.3+hg20181225-2.dsc f4145c22b5a3c40deed8f800ea73b78c 4228 utils optional beancount_2.1.3+hg20181225-2.debian.tar.xz ee151ab74c62e01d4ec74de60babf801 197996 utils optional beancount_2.1.3+hg20181225-2_all.deb 225fad7e56c9857962b4c965d8ae8b2d 11408 utils optional beancount_2.1.3+hg20181225-2_amd64.buildinfo 1ad4b62b1d75f988ee4399bd61babade 56220 debug optional python3-beancount-dbgsym_2.1.3+hg20181225-2_amd64.deb 6529d4cda9b510cd03e5b32481507429 486088 python optional python3-beancount_2.1.3+hg20181225-2_amd64.deb -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAlwrrY8QHHphY2tAZGVi aWFuLm9yZwAKCRB8fkKPk0EnmRWaD/9mSuqHhwnPiEg5DV1r+TgX6uxWAWYp+XgX JQ33NT1cgGw74HvRPPcXlpAJCbH0qcyqKW45hE3HuZr+ioI/opaPfDPQvruU/v6S 0I8mZ0naFR5lYinVocRL/DC/7T/10h8rxtNhnJBEib+9ZUYfhPsyilDB4+/CVo/k hZSCfMjIGiMB8NlD5I22O5leo33/eyUdUxbdBy1ZmPoI2VULfHeWHvviDKfKNfBz u/Eqlq60T7pslP6cTWHAKLLf09n3R8lMKNCmx89aI2s0lgxYIlEMNv2UfbD+vIKR zgwye6e9j6QEHyNZM3NoQD0Nd1BViw74iGAOXGmJCbY3CnT479BbGeKq9gLa5JXe QWp2O3LA2hD27DNH/MP3nZYiDaLaCjCFqQrXbzaZYvclv8Qc4PWWbOxfxucbtnT2 wL0kDupiNAwvvafZRpsZtIvyx5PrSWTuRhKgKlOFkSHDWPFS0+17kw0UevpDKlKT +vGddqL0EC5Md0OuhcvP0NoPcVoHEwMlX+92k59xBqUBBOpsUYmtbsNZdiAxKFLd 7UQWPyv6joV3Mf3RgRnkWcfR2NriA8MdsqkbBXNTECyNYsnXbDET7508pdXP1sOf fM6xpyYagGqEPDY4V4OPPp6QA1BaK46coGL06m7WFW4Dji+Qoy7kDV2B/atnG1JG SzSvARVZdQ== =hZt9 -END PGP SIGNATURE-
Accepted beancount 2.1.3+hg20181225-1 (source all amd64) into experimental, experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 26 Dec 2018 09:05:09 +0100 Source: beancount Binary: beancount python3-beancount Architecture: source all amd64 Version: 2.1.3+hg20181225-1 Distribution: experimental Urgency: medium Maintainer: Python Applications Packaging Team Changed-By: Stefano Zacchiroli Description: beancount - Double-entry accounting from text files python3-beancount - Double-entry accounting from text files - Python module Closes: 799626 Changes: beancount (2.1.3+hg20181225-1) experimental; urgency=medium . [ Nicolas Dandrimont ] * Initial release. (Closes: #799626) * patches/0001: remove fonts.googleapis.com links from bean-web template . [ Stefano Zacchiroli ] * Update to upstream version 2.1.3 + recent hg snapshot * patches/0002: make test_version more lax to accept non git/hg versions Checksums-Sha1: b3b19db1a6937f36e70c3dd4d44218b00cad2b13 2435 beancount_2.1.3+hg20181225-1.dsc 56f94f8e1b30bbca1bfb3dfd762883ac7f4662d3 1739978 beancount_2.1.3+hg20181225.orig.tar.gz 27f11cd88814837b8fc0770ea02f35735d28c883 3512 beancount_2.1.3+hg20181225-1.debian.tar.xz bed296a14be69948cd448b0ef3dc563d1b794cb2 76244 beancount_2.1.3+hg20181225-1_all.deb b78015d82af6c6400eeb5cc3fa2da8c699666eab 12067 beancount_2.1.3+hg20181225-1_amd64.buildinfo 3ba8dee35239f659e641df69f99663e9e03be8f4 56208 python3-beancount-dbgsym_2.1.3+hg20181225-1_amd64.deb 1f15c340e7b6f4469f1d6a12489e1f66965c5a8e 485576 python3-beancount_2.1.3+hg20181225-1_amd64.deb Checksums-Sha256: cba5effe0f51a9bcd8559a65ab260042121540d4c97e7b7b1027eb3879506cd2 2435 beancount_2.1.3+hg20181225-1.dsc 0c5ad4a7ce8dc22a5cec4c88cd8cf3a6a65644aff3d754cc7919cac4db6d8023 1739978 beancount_2.1.3+hg20181225.orig.tar.gz 1476ab0a373526eda722ad3d78bbb0dc5c1c9716ffa00dbe98bec63f01db292a 3512 beancount_2.1.3+hg20181225-1.debian.tar.xz 9a95f4df079957f383cd6d43a19cbf9ed11bd0880bbbd9f4c45bd0fed4ebde46 76244 beancount_2.1.3+hg20181225-1_all.deb 8d707b6e444ea7a42299a9f2a3e5995b3510e0c0a7b23ade8a2961b9036eef87 12067 beancount_2.1.3+hg20181225-1_amd64.buildinfo 8b015d7bbf253d73acb5990f716c0a3ebc5afb42f824aa843ae78c0949f5a4ea 56208 python3-beancount-dbgsym_2.1.3+hg20181225-1_amd64.deb 67590498dbb302fd24be2e610a8b55fec6fef5876dfe6df274e4dce6c4cb238f 485576 python3-beancount_2.1.3+hg20181225-1_amd64.deb Files: 2911c446c5b0736aca9b470dea8c705c 2435 utils optional beancount_2.1.3+hg20181225-1.dsc 7320dbacd788a036e63c35b4bd9fb77d 1739978 utils optional beancount_2.1.3+hg20181225.orig.tar.gz 0cd13c58ebc114bde6620e4f15f5e8cf 3512 utils optional beancount_2.1.3+hg20181225-1.debian.tar.xz 82bcafe0d66d561fbe5a82d7ec5c0c15 76244 utils optional beancount_2.1.3+hg20181225-1_all.deb 16e27bc36f485ac5b7b726ad572754e6 12067 utils optional beancount_2.1.3+hg20181225-1_amd64.buildinfo 25cfd392562c4cba3003207514f2973d 56208 debug optional python3-beancount-dbgsym_2.1.3+hg20181225-1_amd64.deb 6d10517dfafb8c00a51f923abb9c1cc0 485576 python optional python3-beancount_2.1.3+hg20181225-1_amd64.deb -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAlwjaBwQHHphY2tAZGVi aWFuLm9yZwAKCRB8fkKPk0EnmQzoEACRLaKHvPp3EEvKgmGPecAdx+B5ckZlOeB9 rcvRpOJcgoUWgnMmm6PHrZWg1rcDNFQ8HjZKxXF7Vy/eD5ndlQK4Zs5CHoAf+kIq FGFIRcqNqu0nJAdZMu51p8cAecUKA2sKjTRd4c7/atYkLA4+lQZJZLfYJyln2EB2 8RkA1Y02C8/79aw4z3h0VmXz0XqzhxoPhGJ4C1VBiCZd4uWcUXWlb2U09ct1awcx HGZ7MJBFBhjkg4S7T63Rf38cK3BvA7Y8mWcziU28dw1CGODvR0BGEXhGNJGQBvAU BCrS3WPVzE9L1NxfkYpAMI/LvBCCw/Wb0hqvZoF+CJ+t0X5nIl1fpwQnj2mKvt26 Dt1eYEybxX6YgZ41qpsii2c1bvul7yvutuFyg6RtheyyWsXSPT/sICEuO4/5I9fG vOqr+pL51iXhuy10AN99RZWShCLDEm0nMogccZIdMgB2cTlz+LBtWAWLjoAgMx4n yQUG/2U2g8eIlq0KyySsNxws4ih4TVYOMlopJtKV1MtOyjozu+VJUPt4caZxGUMg Ke+rDzjtY2MjZ3EXPy3ar/tD9zKQuhbndc1H3LZFzhi6fETcSQAC7nTgkH15ZUsI Q593/VzQbq8uE/t3sczMmqLc/IT1it5pAKzlWGsAOJqeX/1DMHCTtviHBmz8kuWy PFAQIHJwdg== =CTJY -END PGP SIGNATURE-
Accepted fava 1.9-1 (source all) into experimental, experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 31 Dec 2018 16:15:31 +0100 Source: fava Binary: python3-fava Architecture: source all Version: 1.9-1 Distribution: experimental Urgency: low Maintainer: Python Applications Packaging Team Changed-By: Stefano Zacchiroli Description: python3-fava - Web interface for the double-entry accounting tool Beancount Closes: 917532 Changes: fava (1.9-1) experimental; urgency=low . * Initial release. (Closes: #917532) Checksums-Sha1: 27c9edb3def7916c3d716c839487f3dffe63ec83 2176 fava_1.9-1.dsc 952e6cb73ef99edec3caf879baebc4c13f64d344 58 fava_1.9.orig.tar.gz 874c315529d685f6da577de8d2194750dfaece74 2328 fava_1.9-1.debian.tar.xz 8e7586380b68a55c5334f7a676bb81328ee9ff38 7622 fava_1.9-1_amd64.buildinfo d77a9d9a1afa4fb61d85d029233198504253f45b 464860 python3-fava_1.9-1_all.deb Checksums-Sha256: a1b8b193e7c02cfb42e1b7a4459f3d631b9dc0ffd4dd8407b543270eb58306ad 2176 fava_1.9-1.dsc 337d04d9c898f7a34d89e251574b8f32ee8c9badc0b13b9f5391ba6e684ab984 58 fava_1.9.orig.tar.gz 4fe8ecde16272d959b766ed1f3a1be39d2f79c2090ce4cbe2abe71c4a82f6a39 2328 fava_1.9-1.debian.tar.xz 08facf7d2626b55021eac53950a1bc10f0f4e7260dad8589dfa26fb57855cc98 7622 fava_1.9-1_amd64.buildinfo a344d7629b739c84a71e4ab9e70afa35f7b0ec564751bb30d7c8c0bd2a74f003 464860 python3-fava_1.9-1_all.deb Files: 16e619a9e2ba248e362a21e48faafb3c 2176 python optional fava_1.9-1.dsc dc7417268a0957496e1053d25c64caa8 58 python optional fava_1.9.orig.tar.gz 68d94eeb17c44acb5f1e8c694e3afeb0 2328 python optional fava_1.9-1.debian.tar.xz bdbee4c0e8f2bbea10f17b15d8cf96d5 7622 python optional fava_1.9-1_amd64.buildinfo 3b944e5e34ae9cb594cae0f06d0e44c2 464860 python optional python3-fava_1.9-1_all.deb -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAlwqM4QQHHphY2tAZGVi aWFuLm9yZwAKCRB8fkKPk0EnmTRzD/9FppCQ2eoJfUaXE/RcolZDXAXeqteX3VYl gZ1qMYZjxwlhJEihslWpAVeMd1jV/251+UAFLP9ml0tT8OtCMwlN8cO3l+YV6Iz8 NQ2Q2ulAo9nsTmuk68WOOozRALlNPe9aR2Flebkx59OQ7jF8o9kjOGuw5kcuvFQI r8dJnOZKF/IQ/S1+A8ndTQKx6XExf3M/miP8O7BatybfxVkiPdgQs4I3uRddQg4i KRLy6M7WywbJth9KaDLiIbISB8vs4wsHeqXFl6IQ8SjxD6xokvGSWZeRePu/E9aF SUqLl8aCsy6seoz0NIE2PowOEhRs+lKXNdacS/e7TJj8rm7OvVnVNgJMRvzb42Yr 6QZo4zafgSCrZFNUE1lepEiXSH1bPZ/cV6BqxujeP2d1DC2o93BMBzZRjx7KFyCD OYZESsuX1v/A6ecfEEvjLwlvXCK0brTIbSR1DLITuUHpJumNmd2Ts6fDnVwn3r9k o3gW9L4Nbp77jrrr0Nvl2F+/K0GsXXBDRJXALX+UFPSoiz0guaIqeGEzBmhuCEm+ Ir0eb8xpN1Ep+3VOZ5wyS3Oy0XQYcTZLuOfgHL5oTOeqoQbQURZ3U5qZQrsIBJYO AbYBGv4s2nydtVsOWAEkOz6fyZngqFEUtreKW+Ab2YcTUL4HxehYgSrFPEEVuBrk zpI0NUV6jA== =QGhS -END PGP SIGNATURE-
Re: call for participation - Debian contributors survey, 1st ed.
On Mon, Nov 07, 2016 at 11:22:42PM +0100, Joerg Jaspert wrote: > No logging or name is needed, with the set of questions in this survey > one only needs a bit of knowledge of Debian and its people to identify a > high amount of the survey takers, I think. (I still took it) This is becoming an FAQ, so let me address it here instead of just waiting for the blog post including its answer to be written. Yep, you're absolutely right. And this is in fact why we included in the survey announcement a promise to distribute the results only in aggregate form, because cross-referencing with Debian info it would be easy to deanonymize people. So the "thread model" here is not "untrusted/byzantine survey organizers" (if you don't trust the organizers you're probably screwed anyhow, as we could be lying about not logging IP address or HTTP referrers, after all). The "threat model" is rather: "untrusted readers of published survey *results*", which we will aggregate to avoid deanonymization. And of course all questions are optional, so if people fill itchy about specific ones, just leave them out. I'm available for further clarifications if needed, Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Re: unattended-upgrades by default?
On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote: > To solve the issue and provide security updates by default, I'm > proposing that we should switch to installing unattended-upgrades by > default (and enabling it too) Please do. I've been doing this for ages on all my Debian machines, and never regretted it. Yes, in some cases you do not want unattended-upgrades for reasons like those you mentioned, but those are the special cases, not the default. We should just prominently document the change, so that users that need to avoid unattended-upgrades know how to do so. Thanks for bringing up this topic, Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Re: [Request] Is there any way to get the full source codes of Debian?
On Thu, Sep 08, 2016 at 10:35:03AM +0200, Matthieu Caneill wrote: > On Thu, Sep 08, 2016 at 04:22:58PM +0900, 우승훈 wrote: > > I can download a lot of full source code of open source project > > easily, however, in Debian case, I cannot find the full source code. > > If is it possible, could you tell me how to get the full source > > codes of Debian? ( Especially jessie ver. )Repeatly, I will not use > > the source code commercially or any other purpose, just for the > > researching. You might be interested in the Debsources Dataset, which is a curated scientific dataset, extracted from the Debsources web application that Matthieu already mentioned. It contains all Debian source code and more. You can find the dataset described in this (preprint) paper https://upsilon.cc/~zack/research/publications/debsources-ese-2016.pdf , to appear in Springer Empirical Software Engineering. A corresponding BiBTeX entry is available at: https://upsilon.cc/~zack/research/publications/debsources-ese-2016.bib . Using that dataset you can download all the deduplicated source code of Debian stable releases dating back to almost 2 decades as a (small) set of (big) tarballs, accompanied by a Postgres DB with related all of them together, to releases, and to other computed metadata. Note that, while we finalize the actual upload to Zenodo[*], the dataset is available from the temporary URL: http://sources.debian.net/static/emse-2015/ Hope this helps, Cheers. [*]: long story, they are in the process of migrating to a new mechanism that will allow to upload datasets this big autonomously, whereas the current setup requires manual intervention to do so -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Re: [Request] Is there any way to get the full source codes of Debian?
On Thu, Sep 08, 2016 at 10:35:03AM +0200, Matthieu Caneill wrote: > On Thu, Sep 08, 2016 at 04:22:58PM +0900, 우승훈 wrote: > > I can download a lot of full source code of open source project > > easily, however, in Debian case, I cannot find the full source code. > > If is it possible, could you tell me how to get the full source > > codes of Debian? ( Especially jessie ver. )Repeatly, I will not use > > the source code commercially or any other purpose, just for the > > researching. You might be interested in the Debsources Dataset, which is a curated scientific dataset, extracted from the Debsources web application that Matthieu already mentioned. It contains all Debian source code and more. You can find the dataset described in this (preprint) paper https://upsilon.cc/~zack/research/publications/debsources-ese-2016.pdf , to appear in Springer Empirical Software Engineering. A corresponding BiBTeX entry is available at: https://upsilon.cc/~zack/research/publications/debsources-ese-2016.bib . Using that dataset you can download all the deduplicated source code of Debian stable releases dating back to almost 2 decades as a (small) set of (big) tarballs, accompanied by a Postgres DB with related all of them together, to releases, and to other computed metadata. Note that, while we finalize the actual upload to Zenodo[*], the dataset is available from the temporary URL: http://sources.debian.net/static/emse-2015/ Hope this helps, Cheers. [*]: long story, they are in the process of migrating to a new mechanism that will allow to upload datasets this big autonomously, whereas the current setup requires manual intervention to do so -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Re: GPL debate on kernel mailing list
On Tue, Sep 06, 2016 at 05:25:49PM -0400, Theodore Ts'o wrote: > On Tue, Sep 06, 2016 at 02:29:56AM +0200, Zlatan Todorić wrote: ... and we're discussing all this on debian-devel because ... ? -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: copyright precision
On Mon, Aug 15, 2016 at 05:59:43PM +0100, Simon McVittie wrote: > * If we had a good toolchain to compile and audit this stuff, people > and companies who want to know the copyright holders could just use > that to inspect the upstream source code and cut out the middle-man. I've comment on this in my follow-up to Nikolaus. > * Our copyright files are only correct inasmuch as upstream's copyright > attribution is correct. Right. But that doesn't make it less valuable. In provenance theory knowing that someone has witnessed that someone else has said something is a useful data point. And [FOSS] software provenance is a big deal these days. If the price to pay for doing so is not too high, there is an important role for Debian to be played there. > * I will continue to complain as long as my "source" packages are > expected to contain 87kB monsters like > > <https://sources.debian.net/src/adwaita-icon-theme/3.20-3/debian/copyright/>, > which is fairly clearly not anyone's preferred form for modification, > and if we're being honest probably not really anyone's preferred form for > consumption either. I beg to disagree (at least) with the latter. No matter the size, once parsed you can query that file with questions like "what's the license/copyright of this file according to [this] Debian [package]?". That's one of the thing that the Debsources API is meant to allow. But to be clear: I'm not advocating for keeping nor ditching anything in particular here. I've been asked which level of integration of machine-readable debian/copyright exists in Debsources. I've answered to that, testifying that we do have downstreams of our *current* debian/copyright files. No matter that, Debian can decide: that is not worth maintaining that information / that is worth only if better tooling is available / that is worth only if someone else shows up to do the job / etc. Like it or not, downstreams will cope. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: copyright precision
On Mon, Aug 15, 2016 at 10:53:53AM -0700, Nikolaus Rath wrote: > > * If we had a good toolchain to compile and audit this stuff, people > > and companies who want to know the copyright holders could just use > > that to inspect the upstream source code and cut out the middle-man. > > I think even the best tooling wouldn't be able to automatically generate > correct copyright files. However, it would make it feasible to keep an > initially-correct copyright file correct over time (by flagging > potentially copyright affecting changes in an upstream release and > providing a straightfoward way to integrate those changes). Indeed. I don't think the ideal tooling here could be fully automated (at least in the most general case), it could/should be semi-automated at best. In that respect, it doesn't seem in any way different from other machine-readable information that we extract from upstream projects. Take dependencies: in many cases they could be extracted from other kinds of metadata (or, failing that, from README files, developer documentation, etc). But then they can be wrong, and need curation by a human maintainer for correctness; or at least usefulness. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: copyright precision
On Fri, Aug 12, 2016 at 02:19:43AM +0200, gregor herrmann wrote: > AFAIK there are plans around sources.d.n to use the d/copyright files > in Copyright-Format 1.0. Currently they are browsable at > https://sources.debian.net/copyright/ but IIRC some more analysis is > planned. We do have downstreams for machine-readable debian/copyright files. I'm in touch with companies who have used those to cross-check their independent findings about copyright/licenses of source code that goes into their end-user products. I haven't yet had time to watch Kate Stewart's DebConf16 talk video [1], but her and other people at the Linux Foundation are working in reusing our machine-readable copyright information too. [1]: https://debconf16.debconf.org/talks/100/ For the actual technical roadmap of sources.debian.net/copyright, Orestis (Cc:-ed) might be more up to date than me --- or ask on debian-qa@, where Debsources development is discussed. The fact we do (or don't) have downstreams for copyright information of course does not counter Simon's considerations in this thread about being clear about why we do maintain that information. For me personally it has always been a very natural self-imposed duty: as package maintainers we have to check copyright/license of all files to ensure we do not distribute non-DFSG stuff; compiling a list of extracted information to better keep an eye on how it evolves over time seems a good practice; and if you're going to have a list it's much better to make it readable by a computer. The problem we're having here is clearly about *tooling*. If we had a good toolchain to compile and audit machine-readable debian/copyright files without sweating, nobody would complain. We have improved a lot over time here (cme and lintian checks comes to mind), but there's still a long way to go. FOSSology integration in Debian seems the natural next step here. I believe Kate talked about that too in her DebConf16 talk. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: [pkg-gnupg-maint] Beware of leftover gpg-agent processes
On Sat, Aug 06, 2016 at 12:56:58PM -0400, Daniel Kahn Gillmor wrote: > ouch! please do file this as a distinct bug report, it's something i > haven't run into myself and i'd like to track it down. Done, that's #833596. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: [pkg-gnupg-maint] Beware of leftover gpg-agent processes
[ quoted text reordered ]
On Fri, Aug 05, 2016 at 02:43:30PM -0400, Daniel Kahn Gillmor wrote:
> The simplest way to see the control group hierarchy is with "systemctl
> status". When these processes are launched by the user service, they'll
> end up in the user@.service like this:
[...]
> If they've been autolaunched, they'll end up in the sesion-X.scope
> sub-tree.
It was indeed the case for me: they had been auto-launched.
> > On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
> >> On desktop systems (where i'd expect the majority of secret key access
> >> happens), for folks who are running systemd, i recommend enabling the
> >> systemd user services, as documented in
> >> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
> >>
> >> systemctl --user enable gpg-agent
> >> systemctl --user enable dirmngr
OTOH, doing this inhibited a proper start of my GNOME session at next
login: only Nautilus started (I can tell because I've it handle my
desktop icons) and I could use it to browse the filesystem, but GNOME
Shell didn't see to be running. Reverting the above with "disable" [*]
fixed the issue, and at next login GNOME session started properly,
including GNOME Shell.
I haven't yet filed this as a bug report, because my package mix is
kinda unusual at present: Debian testing + hand-picked gpg from
experimental. But it might be useful for you to know about this. Let me
know how I can debug it further and/or if you'd like to move this
discussion into a dedicated bug report (and when).
Cheers.
[*] actually, I manually removed the symlinks from
.config/systemd/user/default.target.wants/, but AFAICT the effect is
the same
--
Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: PGP signature
Re: Beware of leftover gpg-agent processes
On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
> On desktop systems (where i'd expect the majority of secret key access
> happens), for folks who are running systemd, i recommend enabling the
> systemd user services, as documented in
> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
>
> systemctl --user enable gpg-agent
> systemctl --user enable dirmngr
Thanks for the tip. Do you know if this is needed also for GNOME (or
other FreeDesktop) session users? Within GNOME, on Debian testing, I see
that my running gpg-agent process is already a directly child of systemd
(PID 1), but I'm not sure if that's because it has been started by it,
or rather because the GPG process who originally spawned it is now gone.
FWIW gpg-agent/dirmngr are currently _not_ marked as enabled in my user
session, I've checked with (systemctl --user status).
Thanks a lot for your work on GPG dkg, I'm really thrilled to see gpg2
becoming the default!
Cheers.
--
Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: PGP signature
Re: Verifying dep-5
On Sat, May 28, 2016 at 02:18:51AM +0300, Dmitry Bogatov wrote: > But seems we do not have tools to check it. Probably, we need some way > to mark licenses of whole binary packages. WDYT? You're correct that we have no way to document the licenses of binaries. The Policy is currently only concerned to document licenses at the source (files) level. Note that having a human-maintained documentation of the license of each binary we ship is not enough to properly do the checking you've in mind. Tracking licensing information across builds is actually an open research question on which various teams around the world are working---on various angles: formalizing dependencies across builds, dynamically tracking builds using syscall tapping, inspecting built binaries ex post, etc. There are prototypes of all these things around, but TTBOMK they are all very limited (e.g., restricting to a specific build system and/or a programming language) and as such by no mean generic enough to scale to the size and diversity we have in Debian. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Vcs-* and shared repos
On Wed, May 25, 2016 at 09:19:34PM +0200, Iustin Pop wrote: > And regarding layout: vcswatch already has code to try both > `/debian/changelog' and `/changelog' and use either of them. Having an > explicit layout (-l standard vs. -l native) would make this more > explicit rather than relying on heuristics. > > So while I would prefer the minimum changes needed, I'm wondering > whether explicit layout is not something that should actually be done. I'm convinced we will need at some point to document VCS packaging layouts in a way that allow tools to use that information programmatically. But right now that information will not be actionable, whereas the subdirectory already is (for debcheckout and friends). By also considering the fact that the "-d DIR" solution does not prevent to add a "-l" in the future, I think minimality wins here (hence my "Yay" to your proposal in separate mail). YMMV. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Vcs-* and shared repos
On Wed, May 25, 2016 at 09:25:41PM +0200, Iustin Pop wrote: > Since option 1) is restrictive (doesn't allow expansion), and option 2) > with "-x foo" is along what we already have, I propose that for now: > > - we add "-d path/to/project" (debcheckout, vcswatch, policy, etc.) > - document that the list of options can be extended in the future > (policy) > > And we leave the discussion of repository layout (native, debian/ only, > etc.) for another time. > > Yay/nay? Yay. My 0.02 EUR, -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Vcs-* and shared repos
On Tue, May 24, 2016 at 11:24:43PM +0200, Iustin Pop wrote: > A potential syntax for the Vcs-* fields would be: > > Vcs-Git: https://anonscm.debian.org/git/pkg-haskell/DHG_packages.git/ p/ghc I think something like this, or with the equivalent expressivity, would be useful and welcome, yes. I just wonder whether we should also take the chance of improving the spec in a way that will allow, down the line, to automatically find the actual packaging code also in other, more complex situations. Specifying a branch is the first thing that comes to my mind. But we have seen in the past that it might also be useful to be able to specify the given layout of the Git repository (i.e., is it a debian/ only, is it split debian/upstream, is it merged debian/upstream, etc). All this considering, here are a few options: 1) URL [DIR] <- what you suggested 2) URL [dir=DIR] where "dir" is an actual string, in keyword-argument style, that makes it explicit what the extra optional argument means. This would allow in the future to have other extra arguments without creating ambiguity. This would allow something like the following: 3) URL [dir=DIR] [branch=BRANCH] [layout=LAYOUT] I really worry that (1) might be something too simplistic that we regret in the future. So (2) might be more wise. (3) is probably overkill at this point, because I don't think we're ready for the layout bikeshed. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Debian package on Windows
On Thu, Mar 31, 2016 at 03:03:18PM +0800, Paul Wise wrote: > Quite ingenious really. I'm curious about the set of syscalls they've implemented, and in particular about which non-POSIX (but Linux) syscalls are in that set. Has anyone seen that list yet? > I wonder if we should start offering Debian installs for it too, as we > do for other non-free hardware/virtualisation/cloud platforms. I think we should. It will help Windows users use less proprietary software in their daily lives, and my very well work as a "gateway drug" to 100% Free Software in the long run. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Archive changes
All, On Wed, Mar 16, 2016 at 08:32:17AM +0100, Stefano Zacchiroli wrote: > But it might be a good idea to track all upcoming breakages using the > BTS. Fell free to tag and/or mark as blocking the above bug report as > needed. And to report more similar bugs :) I've now reported #818463 against ftp.d.o to track the archive changes. Please report individual bugs against the services that are broken as a consequence of the archive changes, and mark the above bug as blocked by those new bugs. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Archive changes
On Wed, Mar 16, 2016 at 12:20:43AM +, Steve McIntyre wrote: > >To test it, this is limited to experimental. We hope nothing breaks on it, > >but lets try for a few days. If that works out, we should adjust > >unstable, and another short time later coordinate with the release team > >to adjust testing, so it ends up in the next release. > > Please, no. We need more time than that to fix things up. I've noticed an upcoming breakage in sources.debian.net too, and reported it as #818324. Luckily that is trivial to fix for us. But it might be a good idea to track all upcoming breakages using the BTS. Fell free to tag and/or mark as blocking the above bug report as needed. And to report more similar bugs :) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Going ahead with non-free-firmware
On Mon, Jan 11, 2016 at 05:43:45PM +0800, Paul Wise wrote: > On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote: > > So you don't want another component, but something that looks like a > > component in some places only? I.e. it behaves like a component in that > > it gets its own Packages (and Sources?) indices, but it has neither its > > own area in pool/ nor is it used in packages' Section field. > > Right. This would be nice for some other use-cases too, like cut-down > Packages/Sources files for special-purpose systems. Correct. And that's why I was actually hoping that something like this could actually be a *generalization* of how Packages/Sources files are being generated, rather than a new special case to be added---which would certainly be a sign of bad design for this proposal. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Going ahead with non-free-firmware
On Mon, Jan 11, 2016 at 09:52:08AM +0100, Ansgar Burchardt wrote: > dak doesn't really like having a package in multiple components: the > layout of pool/ requires that the files would have to be duplicated. > Then dak only knows that a "binary package" belongs to a suite, not to > a given (suite, component) tuple, i.e. it will just appear in the > component where the files are located. I don't understand why we're talking about duplicating the actual .deb-s here. What I'd have imagined---but I don't know the internals of dak, so there is only that much I can contribute to the design discussion---is that the .deb-s would have been in a single place; under non-free exactly where they are now. Then, in addition to the usual Packages files for non-free, we would generate *another* one, that APT can find under non-free/firmware, which only contains a given subset of the .deb-s. Now of course the question is how to tell the Packages generation part of dak which packages should be in that subset Packages file. I would've expected to use some metadata for that. "Section: non-free/firmware", suggested by pabs, seems reasonable enough. > I also think that it is nicer for packages to be just in one canonical > location. Absolutely agreed. > Finally note that users will most likely have to update their > sources.list for the stretch upgrade anyway as I also plan to rename > the security suite[1]. (It has been suggested to use symlinks to > allow continued use of the old names, but I think apt checks the > Suite: and Codename: fields of Release these days so that might not be > enough. We also might want to eventually drop the old name.) I don't think that the fact users have to update their sources.list anyhow for an unrelated change is a very solid argument for imposing another one onto them. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Going ahead with non-free-firmware
On Mon, Jan 11, 2016 at 08:25:21AM +0100, Philipp Kern wrote: > I kept suggesting the same, but thought that it'd need a GR because of > "non-free" and "contrib" being listed explicitly in DFSG §5. Happy to > see that this wasn't actually necessary. :) One of the points of the non-free/firmware naming was precisely to make it clear that it's just a subset of what is already mentioned in SC §5. Introducing (what looks like) a new section would incur in the issue you just mentioned. I don't remember anyone proposing to highlight a specific subset of non-free, rather then introducing a new archive area, in the discussions of years ago, but maybe it's just me. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Going ahead with non-free-firmware
On Sat, Jan 09, 2016 at 08:48:25PM +, Steve McIntyre wrote: > Are we sure on the name? Previous commenters have suggested that > "non-free/firmware" might be better. I understand that may be more > awkward to implement in terms of directories... :-) If my recalling is correct, at the BoF there was indeed a mild preference for non-free/firmware, because that names better captures the fact that /firmware is indeed a sub-part of "non-free" rather than something new. There was also concerns that introducing something *separate* wouldn't fly with the social contract, which explicitly mentions main/contrib/non-free whereas it does *not* mention non-free-firmware. In that sense "just" allowing to select a sub part of non-free wouldn't be a problem, whereas introducing something new might be. But an important part of the above reasoning in favor of non-free/firmware was that user enabling explicitly non-free in the sources.list and *not* enabling non-free/firmware would get the non-free firmware anyhow. I.e., no regressions or changes needed w.r.t. the status quo. From other messages in this thread I understand this is actually not going to be the case. Which would be problematic and also a little bit disturbing. Is really no technical way to easily allow to have packages in multiple (sub-)parts of the archive? Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#809705: general: let people use non-free software but opt-out of non-open software
On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote: > Your second item has been brought up before with different > focus/rationale/purpose. At least I remember there being an interest > in splitting "non-free" into "non-free/firmware" vs. various other > non-free sub components. Another one that is worth mentioning here --- which I discussed in the context of non-free.org with Dafydd Harries and others --- is introducing a debtags facet to capture the reason why a package is in non-free. At least two hierarchies come to mind: 1) which point of DFSG is not respected, and 2) which one of the 4 freedoms are not granted. I've had on my TODO list proposing the relevant debtags facets since at least 2 years, but never found the time to actually do that. This is a very actionable item: it is enough to follow the procedure for proposing a new debtags. (Procedure that I cannot find right now, but IIRC it includes coming up with a list of tag names + a list of at least N packages, with N relatively low, that are already in the archive and that would carry each tag.) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#809705: general: let people use non-free software but opt-out of non-open software
On Tue, Jan 05, 2016 at 08:15:37AM +0100, Johannes Schauer wrote: > while I would welcome this sort of information being captured using debtags, > this would not help me if I wanted to tell apt which packages are okay for me > and which ones are not because apt cannot set pin priorities according to a > package's debtags, right? Right, but you need to start encoding the information in a machine parsable way somewhere. Once you've that, you can exploit the information, not before. > Also, can the reason why something is in non-free not be captured by > increased and a more structured use of DEP-5 (machine-readable > debian/copyright)? Policy §12.5 already requires to explain why a package is in non-free: Packages in the contrib or non-free archive areas should state in the copyright file that the package is not part of the Debian distribution and briefly explain why. and DEP-5 prescribes the Disclaimer field to that end. Unfortunately, no further (machine-readable) structure *within* the content of that field is prescribed by DEP-5. So, yes, we will need to improve that part of DEP-5 if we want to exploit information in there. I duly note that, out of the box, having the information in d/copyright won't help with APT pinning either. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#807053: ITP: flask-api -- browsable web APIs for the Flask micro web framework
Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli <z...@debian.org>
* Package name: flask-api
Version : 0.6.4
Upstream Author : Tom Christie <t...@tomchristie.com>
* URL : http://www.flaskapi.org/
* License : BSD-2-clause
Programming Lang: Python
Description : browsable web APIs for the Flask micro web framework
Flask API is an implementation of the same web browsable APIs that the
Django REST framework provides. It gives you properly content negotiated
responses and smart request parsing.
The binary packages will be named python{,3}-flask-api.
The package Git repository will be put under the DPMT umbrella.
Bug#807054: ITP: flask-testing -- unit testing utilities for the Flask micro web framework
Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli <z...@debian.org>
* Package name: flask-testing
Version : 0.4.2
Upstream Author : Dan Jacob
* URL : http://pythonhosted.org/Flask-Testing/
* License : BSD-3-clause
Programming Lang: Python
Description : unit testing utilities for the Flask micro web framework
(Long description forthcoming.)
The binary packages will be named python{,3}-flask.ext.testing.
The package Git repository will be put under the DPMT umbrella.
Re: debian.org RTC: announcing XMPP, SIP presence and more
On Sat, Nov 07, 2015 at 12:05:16PM +, Daniel Pocock wrote: > The Debian Project now has an XMPP service available to all Debian > Developers. Your Debian.org email identity can be used as your XMPP > address. Thanks to everyone involved, this is a great milestone for the Debian Project. I've a couple of questions: - Do we offer any reasonable guarantee about the long term availability of the XMPP service, e.g., for people that stop being Debian Project Members? I guess the answer here is "no", and it's a reasonable one. But we should be clear on the matter, as it might affect people's decision on whether switching to @debian.org as their main XMPP contact or not. - Can you recommend best practices and/or tools for migrating from a primary XMPP identity to a new one? I (shamefully) still use an @gmail.com address as my main XMPP identity and I've been looking into migrating away since quite a while. But I've hundreds of contact there and I don't really know how to minimize their (and mine) pain during a migration. If anyone have tips, I'll be very glad to hear about them. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: git, debian/ tags, dgit - namespace proposal [and 1 more messages]
On Mon, Nov 16, 2015 at 02:02:32PM +, Ian Jackson wrote:
> I'm considering:
>archive/{debian,ubuntu}/
>{debian,ubuntu}/archive/
>
> I'm still considering the capitalisation idea.
>
> Other suggestions welcome.
More of a meta-idea.
You're absolutely right in being unwilling to use "dgit" as part of the
namespace, on the basis that it is just a specific implementation of a
more general specification. But then, the natural consequence of that
argument is that you need a generic name for the "thing" that the
specification standardize. Once you have that name, and everyone is
clear on the fact that it names the standard rather than the
implementation, there would be nothing wrong in using it as part of the
namespace.
(Or you can just say that "dgit" is an overloaded name for both the spec
and a specific reference implementation of it. But I'd agree that doing
so might in the long term end up being confusing.)
Hope [but not so sure that] this helps,
Cheers.
--
Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: PGP signature
Re: DAK Commands for Bikesheds
On Sun, Sep 20, 2015 at 03:48:24PM +0200, Joerg Jaspert wrote: > I've updated https://ftp-master.debian.org/users/joerg/README.commands > with hopefully not too many new errors. :) Minor nit (assuming I've got the naming convention right). --- README.commands.orig2015-09-20 17:33:11.752599712 +0200 +++ README.commands 2015-09-20 17:33:31.772637265 +0200 @@ -121,7 +121,7 @@ #+BEGIN_EXAMPLE Action: bikeshed-create -Bikeshed: theoneandonly +Bikeshed: bs-theoneandonly Description: This is all you need, ever Base-Suite: sid Package: mailfilter @@ -129,7 +129,7 @@ Breaks: bs-doesnotyetexistbutihateitalready Depends: bs-ohthisisevenbetter #+END_EXAMPLE -Create theoneandonly bikeshed based on sid including the mailfilter +Create bs-theoneandonly bikeshed based on sid including the mailfilter package from sid at time of creation. Uploads are allowed by anyone in the uploading keyrings, whenever mailfilter is updated in sid it will also be put into theoneandonly bikeshed automatically. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Re: DAK Commands for Bikesheds
On Thu, Sep 17, 2015 at 04:39:43PM +0100, Wookey wrote: > It wasn't supposed to be a joke. Bikeshed is an appropriate name, in > the unix tradition of mildly amusing/punny names. Not to mention that this bikeshed thread about the Bikeshed name is going to be both epic and very meta. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Bug#797359: ITP: universal-ctags -- Generates an index (or tag) file of names found in source files
On Sun, Aug 30, 2015 at 12:44:44AM +0200, Víctor Cuadrado Juan wrote: * Package name: universal-ctags * URL : https://ctags.io/ A continuation of the exuberant-ctags implementation of the ctags Hey, can you elaborate a bit on how universal-ctags compare to exuberant-ctags? This is by no means an objection to packaging this, but as a heavy user of exuberant-ctags for Debsources, I'm curious about how the two compares, specifically in terms of performances and language support. Thanks! -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Summary of the DebConf firmware discussion
On Sat, Aug 29, 2015 at 12:52:34PM +0200, Philipp Kern wrote: On Sat, Aug 29, 2015 at 12:34:49PM +0200, Raphael Hertzog wrote: To me having the non-free firmware in the official image is not a problem as long as we don't allow them to be loaded without an explicit confirmation of the user. FWIW, I could totally live with that. I shall note that this would potentially move us away from the acceptance of Debian by the FSF. The fact it will impact what the FSF thinks of Debian is a secondary problem. The main problem is that it will certainly move us away from our own Social Contract. My rationale for this is as follows. First, Debian official installation image are conceptually part of what we call Debian, i.e., main. I see no other possible logical interpretation of where those images reside w.r.t. the archive categories present in the Social Contract. Second, in terms of free-ness, it doesn't matter whether something is actually used by the users, or only distributed. That is the standard we have upheld since forever in accepting/rejecting packages in main. Conclusion: Debian official installation images cannot contain non-free firmware. On the other hand that state went on for years and we should be able to form our own opinion about freeness and how to abide to our commitment to users and free software. We have formed our own opinion. Repeatedly, over many years and many votes. We can certainly have another vote if there is the desire to do so. But implying that we have not formed our own opinion up to now is IMHO just wrong. I take the chance of this message to thank Steve for his (AFAICT very accurate) report of the DebConf15 BoF. There are in there very useful and actionable discussion points, that we can work on to improve the experience of Debian users, without having to re-decide again whether non-free firmware should be in main or not. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Summary of the DebConf firmware discussion
On Sat, Aug 29, 2015 at 01:15:21PM +0200, Paul Wise wrote: I think this needs to be additional subsets of non-free rather than splitting up non-free, for backwards compatibility and other reasons. This is why I prefer non-free/firmware over non-free-firmware for naming these. Agreed. It would make clear that with this change we are actually just allowing our users to selectively enable parts of non-free, rather than forcing them to enable all-or-nothing. Also, it would allow the installer to only enable the relevant sub-section based on hardware detection, rather than opening the flood gates of the whole non-free. (I don't know how complex this would be to implement in dak though :-/, because we want a package uploaded to non-free/firmware to show up both in non-free/firmware and in non-free.) One per use-case probably? I can think of at least these possibilities based on a couple of my old blog posts: non-free/docs non-free/firmware non-free/drivers non-free/web non-free/comm non-free/formats non-free/apps http://bonedaddy.net/pabs3/log/2011/09/18/revisiting-personal-software-freedom/ http://bonedaddy.net/pabs3/log/2009/09/19/personal-software-freedom/ Thanks for these references, very useful! Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Q: any reason for debian-policy non-i18n-ed?
On Sun, May 10, 2015 at 01:13:10PM +0900, Hideki Yamane wrote: Why debian-policy has not been gettexted? Just a curious :) I suggest to ask the debian-policy maintainers, instead of debian-devel :-) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Q: why binary-log by systemd-journald is not enabled by default?
On Sat, May 09, 2015 at 10:41:17AM -0700, Josh Triplett wrote: The on-disk persistent journal (/var/log/journal) is disabled because at the moment, Debian systems use syslog by default (via rsyslog), and enabling the persistent journal would result in two copies of log messages. I've enabled the on-disk persistent journal on some machines (while still keeping syslog around) and I'm quite happy with the result [*]. However, upstream defaults in terms of disk usage are a bit too eager: using up to 10% of filesystem space for /var/log/journal might be a lot. And yes, I know about the SystemKeepFree safeguard, but the resulting increase in disk space used by logs compared to syslog is still significant (and it will spread to other places, e.g., backups). No matter how journald will be integrated more tightly in Debian, can we haz a saner default? And while we are at it: is the persistent journal backup-safe? or does the binary format get in the way, implying risks to backup incomplete / corrupted log entries? Cheers. [*] FWIW, I've learned about the need of enabling persistent logging from Lucas' slides about systemd here http://www.lucas-nussbaum.net/blog/?p=874 . I found that slide deck to be a very nice and compact primer about systemd administration, if you come from a sysvinit background -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: patch-tracker down?
On Sun, May 03, 2015 at 02:50:17PM +0200, Iustin Pop wrote: Resurrecting this year-old thread. I guess the patch tracker is still down, right? It is, yes. Browsing a few random packages seems to work correctly, although without an extensive test suite I don't know how well the code works for various packaging types. [...] PS: Long-term, the current codebase needs some redoing - e.g. it uses cheetah as templating engine, and that's not available under Python 3, etc. I very much agree. This is why, from an idea coming from Lucas, I've included in the scope of the upcoming GSoC work on Debsources [1] the following: 2) a patch tracker web app to publish details about the source code differences that Debian packages carry with respect to upstream releases of the same software. [...] implement on top of Debsources a new web app, similar to the (now defunct) patch tracker [1]: https://wiki.debian.org/SummerOfCode2015/Projects/Debsources%20as%20a%20Platform From an ecosystem point of view, Debsources already have both packed and unpackages source packages, updated daily via push. On top of it adding a tiny web skin that presents the patches is not much of a work --- in comparison with the general infrastructure overhead of having a source mirror, unpackaging it, etc etc. This is why I'm interested in giving a try to recasting the old patch-tracker.d.o on top of sources.d.n (to that end I've temporarily booked patches.d.n), rather than deploying them as separate services. OTOH, the patch-tracker.d.o code base already exists, and Debsources is not yet a *.d.o service (mostly due to my lack of energy in doing the migration, nothing else). So YMMV on what is the best course of action for having back a web app exposing Debian patches w.r.t. upstream. In terms of technologies, Debsources is both Python 2 and 3 (although currently still deployed on Python 2), and Flask based. If you, or anyone else, is motivated more on working on these technologies than in modernizing the old patch-tracker.d.o code base, please come and talk to me. Having competition in the area wouldn't be necessarily bad either. In particular, it might motivate in implementing a generic patch parser in Python (supporting the various kind of packages), to be included in python-debian. Cheers. [ thanks to pabs for pointing me to this thread ] -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: patch-tracker down?
Thanks for your prompt answer, Iustin, On Sun, May 03, 2015 at 04:16:26PM +0200, Iustin Pop wrote: So: - we could have the current patch tracker resurrected easily as a stop gap measure; not sure what the policies are around debian.org services, but from the point of view of just the patch tracker, probably about one weekend effort; or: This, absolutely. I just wanted to mention that something related to patch tracker is brewing around Debsources, especially for those that might be planning significant refactoring on the patch-tracker.d.o code base. But GSoC outcomes are hardly unpredictable, so I'm not ready to commit to the availability of something by the end of the summer. If it is easy to resurrect patch-tracker.d.o as is, and you're willing to work on it, by all means go for it. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: debian github organization ?
On Tue, Apr 21, 2015 at 05:41:56PM +0200, Nicolas Dandrimont wrote: I sure hope that won't mean getting Debian onboard the proprietary edition of their software, but rather them helping the proper packaging of their software. +1 And, besides, we should have by now all learned that 3rd party hosting is not a strategically smart move, with all the forges closing down these days. If anything, we should run our own GitLab (or Kallithea, FWIW). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull’ (was: debian github organization ?)
On Sun, Apr 19, 2015 at 12:13:32PM +0800, Paul Wise wrote: To those of you who are willing to use github for Debian related things, it would be great if you could: Mirror the repositories to alioth so Debian has a backup. I'd rather see it the other way around: advertise the alioth Git repo as the main one (e.g., in Vcs-* fields), and mirror it to GitHub for people who want to contribute via GitHub's pull requests. Also accept contributions via email or git request-pull. AOL. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: aptitude has Priority: standard, why?
On Tue, Mar 31, 2015 at 10:18:50AM -0300, Henrique de Moraes Holschuh wrote: apt-get is the simple tool everyone knows about, though. It also needs another simple tools like apt-cache to be really usable. It's tangential to the main topic of this thread, but you might want to give /usr/bin/apt a try: it abstracts over apt-get / apt-cache, offering a single CLI entry point to (some of) the functionalities of both. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- 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/20150331132238.ga18...@upsilon.cc
Accepted cudf 0.8-1 (source amd64) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 30 Mar 2015 19:44:28 +0200 Source: cudf Binary: libcudf-ocaml-dev libcudf-dev cudf-tools Architecture: source amd64 Version: 0.8-1 Distribution: experimental Urgency: medium Maintainer: Debian OCaml Maintainers debian-ocaml-ma...@lists.debian.org Changed-By: Stefano Zacchiroli z...@debian.org Description: cudf-tools - command line tools for package upgrade problem descriptions libcudf-dev - C library to access descriptions of package upgrade problems libcudf-ocaml-dev - OCaml library to access descriptions of package upgrade problems Closes: 752212 Changes: cudf (0.8-1) experimental; urgency=medium . * new upstream release - include workaround for parallel build FTBFS (Closes: #752212) Checksums-Sha1: c8ec62270944d00e6bfdb583d850269be65d90d2 2136 cudf_0.8-1.dsc 34233ffc70e706a70637f406106ed0e7c1d8c7c0 55147 cudf_0.8.orig.tar.gz 598dd930b1015ba2333bdbb8ad7bdf657bbe2875 3920 cudf_0.8-1.debian.tar.xz 69c2b15acf48b4dcd986c12932eaa5d4a50ab58d 98606 libcudf-ocaml-dev_0.8-1_amd64.deb 21cdd1b6fbf019e621a03f489d94b1b609614461 129678 libcudf-dev_0.8-1_amd64.deb a4d7f179d90b3f5d6e3e40f6361ff8e1f1e74798 205062 cudf-tools_0.8-1_amd64.deb Checksums-Sha256: 56fd122f1872d6466f78ff5333f26d832a570e2fdc08c1811655427768c000b2 2136 cudf_0.8-1.dsc 06f8ce019c87893e27d545b5cf8dc38041657a4c4856c02be4e99e8175874229 55147 cudf_0.8.orig.tar.gz 8ccc7472dbc69e63052d6df65d9408b676ea2fa4b8b5cc26ebf877696896d1b3 3920 cudf_0.8-1.debian.tar.xz 844b5d83d732e9e117fa363efd177f488c3fd8a25ee647aa9007bebee7a0678c 98606 libcudf-ocaml-dev_0.8-1_amd64.deb 9f51f420a2465b5613fd84cec1aa7b7089d4a0001138368a4c3d3d64eec392bf 129678 libcudf-dev_0.8-1_amd64.deb 6ccfe78b5ec585648434c9601683e72ec3898a9b972756b66ce4b4a1f1c2f8eb 205062 cudf-tools_0.8-1_amd64.deb Files: f3575ec2748c010ef4aa1c4f8ae5b4a4 2136 devel optional cudf_0.8-1.dsc abf34d3daedd81580b7b32a871341b2f 55147 devel optional cudf_0.8.orig.tar.gz 428475f189f0b070b71498208d9efc91 3920 devel optional cudf_0.8-1.debian.tar.xz a79b9e8d41e7bf67a64db5a7e33b0450 98606 ocaml optional libcudf-ocaml-dev_0.8-1_amd64.deb 539f0a2a8cc7139b3927082098bc4166 129678 libdevel optional libcudf-dev_0.8-1_amd64.deb da0d7b60b6883affa0a71bf6fb815fa7 205062 devel optional cudf-tools_0.8-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIVAwUBVRmOwpwxUDxthmOWAQgIzQ/9FKjvf6dDBDrT0GoDGgO7ynR/eylsHB4s jJv6H2I2iNM0JzkJ48LH4BdWAKYPiQBrbprK1SPSGGefF22vxkPziUsG8yiScwU2 QmdXHDdk+6KrpF9+5QT24sa2nbm84f7m+fkCHpsDWuhXii2d3LAgZTKF0RNZWfyg m+KM1K96GH4QnS5yvwxMA00QQJiOBvpbf/z+dYx6rdN8WzzTvZRGI0t0CL22RsNm DUSApT5AdfNpv/KL42YfLRx7KmcHYYgoescZ1IKDGAVs9PxNrUgBBih1G8zhbd2/ DW07k5vGUVofvoxUXs8dnOrjxHMZ7jKAHpFjACPoGlJsCAkRXGy+ywjyv0ezXJsp FD42T5ljEHT26pAuwPjNxdzwr0leKM+UQfh8OqLOdUVJ3XPp1KXu2nHAt+lam6/w ulFHWZktBbW/A8d3toBA0av6QUX/+rJDtYuHfv6w24hTwcL3mVwV1G8ZkO6G+CRi R0jt40qUN+zqmFfC3MJDE9XoB5rsUmCmFq6vYz6mKEXBoQfC4jOYCtj3TI/n10Ku eoqdyXkqqIKYnjpjS4SZs4LF3peeXnoTyD5L1gIgudHZuDJdptZrrGFlWvDpYnVR liuUX1pR95Rwl/AFQKFR9j7mxDZw7CgY/GsfWALb/1RSWBRwB8kXHGiLrqCldk2m iOyuZvDYLpM= =QhTh -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/e1yce2p-0003oj...@franck.debian.org
Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]
On Mon, Jan 19, 2015 at 05:14:18PM +0800, Paul Wise wrote: People often file bugs for issues they discover in software they don't use or care about, getting followups to those isn't necessary. Uh? What's your rationale for this, and in particular for the often part? Surely the typical use case for a bug report is I use this software - this feature doesn't work - I submit a bug report? That is the use case we should optimize for, because taking the risk of leaving out the original bug submitter from conversations around that bug increase friction in the bug fixing process, in turn reducing the quality of our distro. The main use cases of someone reporting a bug against software they don't use is quality-assurance activities. Which is clearly a very important activity, but we should not optimize for it. I've done my share of QA work in Debian, including mass bug filing, but my gut feeling is that still, 90% of the bugs I've reported to Debian throughout all my life are against software that I use and care about. (Clearly, we should not make the QA use case needlessly painful. Hence I'm all for the opt-out mechanism you and Don discussed in another part of the thread. But I'm convinced that we should optimize for the other use case.) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Accepted dose3 3.3~beta1-3 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 12 Dec 2014 16:39:24 +0100 Source: dose3 Binary: libdose3-ocaml-dev libdose3-ocaml dose-distcheck dose-builddebcheck dose-extra apt-cudf edos-distcheck Architecture: source amd64 all Version: 3.3~beta1-3 Distribution: unstable Urgency: medium Maintainer: Debian OCaml Maintainers debian-ocaml-ma...@lists.debian.org Changed-By: Stefano Zacchiroli z...@debian.org Description: apt-cudf - CUDF solver integration for APT dose-builddebcheck - Checks whether build-dependencies can be satisfied dose-distcheck - Checks whether dependencies of packages can be satisfied dose-extra - Extra QA tools from the Dose3-library edos-distcheck - Checks dependencies of packages (transitional package) libdose3-ocaml - OCaml libraries for package dependencies (runtime files) libdose3-ocaml-dev - OCaml libraries for package dependencies (development files) Closes: 772875 Changes: dose3 (3.3~beta1-3) unstable; urgency=medium . [ Stefano Zacchiroli ] * demote trigger on /usr/share/cudf/solvers from interest to interest-noawait: there is no real need to block, and doing so avoid trigger cycles. Thanks Guillem Jover for the heads-up. (Closes: #772875) . [ Johannes Schauer ] * fix debian/watch (add uversionmangle) Checksums-Sha1: eabee6d4dbf3b69d05948df1a3d9ea0f3bf51725 2614 dose3_3.3~beta1-3.dsc 3edf987b2252ce3c338c413dc274d54bd7728974 17276 dose3_3.3~beta1-3.debian.tar.xz bed40cd85970cc6ad825ffaa010e75b66df57ec6 672048 libdose3-ocaml-dev_3.3~beta1-3_amd64.deb 18774bed0bf9719c761901b26b278e1a3e058c2d 1 libdose3-ocaml_3.3~beta1-3_amd64.deb 6a825db1c61185afd09dab6b5ae5adcb333f01d6 605236 dose-distcheck_3.3~beta1-3_amd64.deb 382f0833ee54a96a94c6a1a9a0863d73d6befeec 575370 dose-builddebcheck_3.3~beta1-3_amd64.deb ea8baed6236a5dd1f9edbb2e84dcc6b7a79da213 1136374 dose-extra_3.3~beta1-3_amd64.deb 2a53e217d4accf5802a375f19213b6b791214f62 590146 apt-cudf_3.3~beta1-3_amd64.deb 582da264aa05996008fc09ef0b7943fa2c21c544 8182 edos-distcheck_3.3~beta1-3_all.deb Checksums-Sha256: 5a370a7335d4357b635283aab653de79624b292b8772572e96c0b681c5b45c91 2614 dose3_3.3~beta1-3.dsc 3eda648587ba4bcaa382a701a7800938e8b10ef2a0b879a9ad0e120366d77ef0 17276 dose3_3.3~beta1-3.debian.tar.xz 0e144c7b8cf9f1280fd612d0c477608db6c83af5fb893724bdebceaf7d154eb4 672048 libdose3-ocaml-dev_3.3~beta1-3_amd64.deb 0e7b7e48f1522e27a3a13b98f9cd48f1006c1cf94532d114540827da5db01654 1 libdose3-ocaml_3.3~beta1-3_amd64.deb cb112be01a6392f1bb5a18194a6e34a023b2e22827947ebfef940526d3511505 605236 dose-distcheck_3.3~beta1-3_amd64.deb eec4e6e53c3ee1d14816cbbdeb34b53607c2a30a37a2520a3812d72106e14a8d 575370 dose-builddebcheck_3.3~beta1-3_amd64.deb 5f3123492097bccf7a315a24062a6edae62059078ac8c913926bdb54491f7c5c 1136374 dose-extra_3.3~beta1-3_amd64.deb 85d984d203f85e4aa49353c47881c64e42c13e81f5c42a6b30e7dfa40bd6cff8 590146 apt-cudf_3.3~beta1-3_amd64.deb 4a5c74ba985b24712d89a10d7e2f3b1794414fb4ab85fd157fc13ea5fcb8dd6d 8182 edos-distcheck_3.3~beta1-3_all.deb Files: ec682538f7798526a15409a226e7d8bf 2614 ocaml extra dose3_3.3~beta1-3.dsc acd225fda380994cb8e662b2c774e152 17276 ocaml extra dose3_3.3~beta1-3.debian.tar.xz 54588f8ef93c2e54e9f7fd88b2857ca9 672048 ocaml extra libdose3-ocaml-dev_3.3~beta1-3_amd64.deb cea894ad7e14551abbc5a756d9e60b10 1 ocaml extra libdose3-ocaml_3.3~beta1-3_amd64.deb 41f4dc42eba0ba7f7e7340d8d054d3d2 605236 devel extra dose-distcheck_3.3~beta1-3_amd64.deb ad9d20b64f8ae8985f441932b635fbae 575370 devel extra dose-builddebcheck_3.3~beta1-3_amd64.deb 5f318d4a54a6989cb1edd0c6d7fcfc72 1136374 devel extra dose-extra_3.3~beta1-3_amd64.deb 012cc522d4e2ce4c6085bb6a35daf49a 590146 admin extra apt-cudf_3.3~beta1-3_amd64.deb 1c8ef6ba1e23d2644b7cd4bbf687469b 8182 oldlibs extra edos-distcheck_3.3~beta1-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIVAwUBVIsN3ZwxUDxthmOWAQg+xw/9FtiH1SsXjyjZS4d++5gPYZKn8EPAYrQT Og9jt/1zFUuOr5p1w9Sw9koPgE2Pn3eHVRtDkbEhaxUImLr/U0Qtm87afqi7Ln8V z7xca/h8ZaToCXn2WPI+c7sMc18+g4bgI0L/tbMY+JlyID8y6J0/+sEDy4ohKiM3 DFJ21v8PQ3wXfqeGzFnDWYWVIGUgcaC6+WZ6CtyVw2S9SdCO5UiMkETmLreqn7Y3 45LJJwDrXcrjbKWEM0wHKw1Ho4vBtXZuHydOdqN5p1u3G9ShJA5QDIoDQ4WpbTG6 IbqQjWKqbbtBJ38EFmghd6B5r2RRajbIdgNkPTmi3gIZt4zL+/ImCXK+O6/SKk6h 9yMAQ/VPE88fgNrS7Kyp09U1CM6RGbiAS6zch7QAiTH4t6HQKdeUgEF6puCvZ9uM MzC4vXGBqvhi99V6Vzu+TS+vL2wiAYB9mPqxmEHmqtMi+3Vh4CnLD9uv5FCoGRMd jr/fT4jAW1zEV2qFCCtiA9Nyt2jFTW3kx09L+EovN9LzzJdSI8Xt6Gz8tJUmt/4H 7w7YMm77D0pUWTWmAnU/z2HCPKyo+3INtKgoI4Z7msj8RYI7FSLkx3iLOgJ/6IDg oL9dZ3gp1pqMOi0ws6ZRVPivnd2nZivv+O7jZ40o8F6jdWIDVKvoHq3z/yQwktA4 W9ftxLAknfk= =zgkk -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/e1xzsiw-0005pe...@franck.debian.org
Re: GPL-3 openssl: provide a -nossl variant for a library
On Thu, Oct 23, 2014 at 10:11:41AM +0200, Florian Weimer wrote: But Fedora, whose policies Richard Fontana helped to shape over the years, considers OpenSSL to be a library covered by the system library exception. But legal advice is not necessarily portable. As a project, we can certainly decide to start considering OpenSSL a system library, on the basis of legal advice. But to do so we should seek legal advice specifically targeted at the Debian case, and discuss the advice we get with the relevant stakeholders (e.g., the FSF, with whom we have pretty good connections these days). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Accepted python-debian 0.1.24 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 01 Oct 2014 16:41:15 +0200 Source: python-debian Binary: python-debian python3-debian Architecture: source all Version: 0.1.24 Distribution: unstable Urgency: medium Maintainer: Debian python-debian Maintainers pkg-python-debian-ma...@lists.alioth.debian.org Changed-By: Stefano Zacchiroli z...@debian.org Description: python-debian - Python modules to work with Debian-related data formats python3-debian - Python 3 modules to work with Debian-related data formats Closes: 758027 Changes: python-debian (0.1.24) unstable; urgency=medium . * copyright module: make Copyright objects iterable * debian_support.list_releases(): update release list (Closes: #758027) Checksums-Sha1: 707877370113f4cc02bafd991adc29336f64f7e9 2199 python-debian_0.1.24.dsc 3508487df1fc18fec776c38cefaf464b67a00228 288280 python-debian_0.1.24.tar.xz ac2de119d057e9a2dcbf52d033bf907baa4ff44b 71174 python-debian_0.1.24_all.deb 10c56079ef12bd7c53a34db5beb0ec789167f217 50446 python3-debian_0.1.24_all.deb Checksums-Sha256: cba066509494636365bb0c589502a5fe08db9c24dfaff924e3bd7ec352631470 2199 python-debian_0.1.24.dsc da36ac47d8b929af12d6889c974159e00c9f7372b84041b6663bb9114e83b854 288280 python-debian_0.1.24.tar.xz af28a083c7034487ec6fb9dc2a720165f08f899a39ce118cba66471def12864b 71174 python-debian_0.1.24_all.deb fb124dbe8616574a20a5ff82387d97675bcd0f6c0537f5422cdc023ecb97f787 50446 python3-debian_0.1.24_all.deb Files: be6c36e281a037cae1947f6df0b79190 71174 python optional python-debian_0.1.24_all.deb b8cc45603b3e84a60f2c4bc485f493da 50446 python optional python3-debian_0.1.24_all.deb 11f79efdf6d0124aa0784afd619e4b60 2199 python optional python-debian_0.1.24.dsc 084aaab55eae088051d2374a577093d1 288280 python optional python-debian_0.1.24.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIVAwUBVDEWJ5wxUDxthmOWAQggAg/9EgF/edhLlYRC/n0DSZZVGDDGPiXAkGnl LlmUru4aRG2qJ+HBr1ywx7lE01RAKCAXGh1k/BZZVWez++V2ui8mef8YLSBq5MYt nclhzIb2Cji9IWeqagsMu0xtX/rEt02hhNg3hi+ssmEC+2HpyaTXaUB9tGI2wA4o UJtz+uQ5v606kKgi32ITH1Dd9pz7KZ5KzOrETFxCqcw9oXwD2qZj4yNdYgHZL5a9 m4I03DkcwejGw0h6iIMB7bfp6OXQ71EIF6M8oIN9R9lcBuMFEaebxmpb3OSbbPm9 mxZop6f/Y81zj85aYPRZDT7CumFgamnOst/34XeJGO2/B6QWLPGVk0KNxJylWw9J fIVBQIr7yfB+fzoOlZGSf+2bgCmdumnX3/BB1vD9PlbmBFsgEnw3hkX63KwPdDZk Hk4HD810tydKg4KDVqXv24wQneY2gQC94+QIvs3V8TY1suO8yRhM+y5nhEGWYo2v AVzkft7Z/5RjPCk0ug6U/KBqO/pIZf79cHu7y0benMwC1f7qodyC8WaEvdn9fFo0 8MOv7GWCbvzbJHVzdBWu9MyjdLjA1rRUFy5yFa+ApStFiB1a137piO6LhEe8BHW5 o0mogFFGaLtXn8uTMgV/i5++wqQFDmd/qurtsAoldxMQRtqHHNO2ExbQrtrdhnUE RltiZav6IzI= =nwIg -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/e1xaihe-0007to...@franck.debian.org
Re: teams in Re: New package tracker - old one going?
On Tue, Sep 16, 2014 at 05:54:15PM +0800, Paul Wise wrote: On Tue, Sep 16, 2014 at 5:47 PM, Holger Levsen wrote: how is that fed with data? https://tracker.debian.org/teams/+create/ I notice most teams from wiki.d.o/Teams/ are missing :/ Up to each team if they want to use the tracker, few have chosen to do so. Yeah well, I suspect most teams simply don't know about this feature. AFAICT tracker.d.o as a whole (let aside the team feature) has not even been announced to d-d-a yet. Maybe it's time to do that, highlighting specific opt-in features such as team claiming? Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Trimming priority:standard
On Sat, Sep 13, 2014 at 11:17:34AM -0700, Josh Triplett wrote: I'm not arguing that standard should have nothing in it; it should have things that the vast majority of users will 1) expect to find present without having to install them and 2) actually use or care about. I sympathize with the sentiment, but AFAICT the only way to implement such a specification would be to actually *ask* our users, and (by definition) a thread on -devel cannot work to that end. It seems to me that the only way to implement that spec would be something like a broadly advertised user survey, with specific questions about the packages you are interested in. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Removing 2048 bit keys from the Debian keyrings
On Sun, Aug 31, 2014 at 01:27:11PM +0100, peter green wrote: If you have signed someones old key is it considered responsible to sign their new key based on a transition statement signed by the old key? or is a new face-to-face meeting required? I've seen plenty of (sometimes conflicting) advice on signing keys of a person you have never signed keys for before but not much on the transition situation. This topic is in the realm of personal signing policies, so it's probably normal to have conflicting advice among us. FWIW, my take on this is that I'm fine in trusting transition statements as a basis for signing new key, but only if I consider the person doing the transition to be an active member of our community with whom I interact on a regular basis (even remotely). My rationale for this is that if someone disappears from my radar for a very long time and then shows up just for transitioning to a new key, I'd have no way to figure out that something fishy with her key might be going on. In practice, this might become a fairly strict requirement, and I've keysigned on the basis of a transition statement only twice over the past 5 years. YMMV. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: people.debian.org will move from ravel to paradis and become HTTPS only
On Sun, Jul 20, 2014 at 06:19:14PM +0200, Peter Palfrader wrote: None of these brings people who type in people.debian.org into their browser to https. Right. AFAICT the only technical change that will do that (sanely) is an HTTP-level redirection from http://(.*) to https://$1 . Having that enabled by default, plus a way for DDs to opt-out to the redirection (dunno, by dropping .no-https-by-default files in suitable sub-directories of ~/public_html) would nicely address the few objections I've seen in this thread. FWIW: - it's not entirely clear how much extra work implementing this would require. In particular, I haven't put much thought in an easy way to implement the directory-level opt-out. - I *personally* don't mind having https only, quite the contrary! But I got hooked by the discussions and couldn't resist proposing an API :) (sorry) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: people.debian.org will move from ravel to paradis and become HTTPS only
On Sun, Jul 20, 2014 at 09:00:05PM +0200, Peter Palfrader wrote: IMO, a dedicated vhost name sounds much more appealing than magic apache configs. I wonder whether it should use the same UserDirs. Oh, right. With different UserDirs (bonus point: the default one, public_html/, being the one that works https-only) people can simply use symlinks. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Accepted cdrkit 9:1.1.11-2.1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 18 Jun 2014 12:02:31 +0200 Source: cdrkit Binary: wodim genisoimage icedax cdrkit-doc Architecture: source all amd64 Version: 9:1.1.11-2.1 Distribution: unstable Urgency: medium Maintainer: Joerg Jaspert jo...@debian.org Changed-By: Stefano Zacchiroli z...@debian.org Description: cdrkit-doc - Documentation for the cdrkit package suite genisoimage - Creates ISO-9660 CD-ROM filesystem images icedax - Creates WAV files from audio CDs wodim - command line CD/DVD writing tool Closes: 611784 648935 Changes: cdrkit (9:1.1.11-2.1) unstable; urgency=medium . * Non-maintainer upload. * geteltorito.pl: update to version 0.5, fixing the bug that prevent it to work with hdd images (Closes: #648935, #611784) Checksums-Sha1: 37759aa21af1a8919412faf603550939937d9921 1984 cdrkit_1.1.11-2.1.dsc ec54634acc4cea6f941a706f56bb8ca7ab125548 27689 cdrkit_1.1.11-2.1.diff.gz 88c6a175d945de4b3d971f683dfc5c814080c2a5 150874 cdrkit-doc_1.1.11-2.1_all.deb 4aaa0002fe1561010f649a4928d4dc1dc055b6b0 340630 wodim_1.1.11-2.1_amd64.deb a94307c50b6014afb481244cf0a06317a0a978b4 170456 icedax_1.1.11-2.1_amd64.deb 96f2d19d23b75f2054a01485352e3ea1f30c8488 360324 genisoimage_1.1.11-2.1_amd64.deb Checksums-Sha256: 8732297c1a006870590d93437529af5b23180ba06c221b1ecfe2768e18d0f6db 1984 cdrkit_1.1.11-2.1.dsc 1672941a6b485cc8bf132951313fc499fc6492c456fabe7f9729140273d91f5c 27689 cdrkit_1.1.11-2.1.diff.gz 1c9d7a305c449b61e59d03919570207ce21e71ae59625c4af7491c0c8d4e0d5e 150874 cdrkit-doc_1.1.11-2.1_all.deb 87f92795736dab2058469483438dbacb7eb42bf5d60670e64a8ebb002d1e5720 340630 wodim_1.1.11-2.1_amd64.deb 7401f3693110c70a8e984216906238912fda02242ef138efde73ec1adbd9eb99 170456 icedax_1.1.11-2.1_amd64.deb a88b4cf979956d8c98766a1983146c2dd343f8fa3c6c35ab5c64920100e4004f 360324 genisoimage_1.1.11-2.1_amd64.deb Files: 61be0db420dd7a8e6be792b1a0143e7d 150874 doc optional cdrkit-doc_1.1.11-2.1_all.deb b99137e2a67062115c8498041012742b 340630 otherosfs optional wodim_1.1.11-2.1_amd64.deb 791bd43433f4ddf20253daa234ce39b0 170456 sound optional icedax_1.1.11-2.1_amd64.deb 3590d5a32578db28f161b7f7d74541fb 360324 otherosfs optional genisoimage_1.1.11-2.1_amd64.deb 0adb1c44e3ee67350cc91f3ae4f36222 1984 otherosfs optional cdrkit_1.1.11-2.1.dsc 57f32975fc53366b875dd9eb09d65bdd 27689 otherosfs optional cdrkit_1.1.11-2.1.diff.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIVAwUBU6FlGJwxUDxthmOWAQiWpg/9FcLV+BOi5R5lD6L6A1ttcIpdjsdfHrcW tVOF7OvsVvaqt/OSe3fK1U5f7fUjDsuBArcGECkcSHHVGGB4KbTRsfppSViRLNDR ECP8unjskmqEfPgNVS8WHNYqgh04txTv8iJtFks1WrXpMQIEuTgDVBznGxc2fR9c sP8BMvVGKoFZifAVfeocT+ZQKU4aTqDIaapBwrCCkFUeoO4Ae7uIttmmUqGe4UaR meSrc/rn2LLuB/Ti5oI5A0Rk7xwPTciBeMKedRvJqg2z3KWiRRh4SEZvAWRVG6P5 X2fTnt2WqqsKWb3L9rIjm/5bkoM/GLNg4ZlZ9rhSBItme34Ixrt9tY3dCHcWUThk DFDyRKn2kPepD6KX47ApUccVjTrT4AESHHEQ9+c/IOM6xluyr/48dJjcVcmTO7Z7 Mj4n3OZLnWpo2IbAQpKniLsgREzKM3kOiBax/KZOqDoX9jxltuY57DuqyIlGimnE w7g2UtMAr49jDZRX2BThRZXKJrKwF35bpS9P0xumX2HnsmH6OjfVGcAgAdnnS1HB nZou0Ttp+59nSbQHKvCzx3kXPjtvc9d1WrvuctxulFjv8CYoNh+cZp4Z7s8J8qVo HTfSGBl0cvLZmNjv57f34XAOo0NcmUU5KpZpm8aEv94ZvSsxrM4783iH7xBY8i48 p6XNuUNTuE8= =mlFW -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/e1x2h8o-ti...@franck.debian.org
Accepted molly-guard 0.4.5-1.1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 30 Jun 2014 11:55:40 +0200 Source: molly-guard Binary: molly-guard Architecture: source all Version: 0.4.5-1.1 Distribution: unstable Urgency: medium Maintainer: martin f. krafft madd...@debian.org Changed-By: Stefano Zacchiroli z...@debian.org Description: molly-guard - protects machines from accidental shutdowns/reboots Closes: 749372 Changes: molly-guard (0.4.5-1.1) unstable; urgency=medium . * Non-maintainer upload. * Fix FTBFS due to vanishing non-compressed version of the manpage. Thanks to Jakub Wilk for the patch. (Closes: #749372) Checksums-Sha1: ec50118ca44b2aaec4a1e82ff656e49b0a6735bd 1847 molly-guard_0.4.5-1.1.dsc fb2c20029fd65917d9b4c2a2403fbbccfeba 6566 molly-guard_0.4.5-1.1.diff.gz 1ac2a9ebc12b5e276b9af1c633b5324b3fe5d801 12682 molly-guard_0.4.5-1.1_all.deb Checksums-Sha256: 70b7f0246e0b92f707ad642dd9d9a0e884e3fae234932136ec54dbe0a9a726d4 1847 molly-guard_0.4.5-1.1.dsc 1adc8bdce87469d838e3fd2cb4d5823b5006e7b490d0c93f4562b84b89d0aa8c 6566 molly-guard_0.4.5-1.1.diff.gz e3ed151ded0bb27ed1bedd72ce4f8262d792e367d2542c70b106031f2aa45ee7 12682 molly-guard_0.4.5-1.1_all.deb Files: 95de012a9b5ae8773fba9cf48223527c 12682 admin extra molly-guard_0.4.5-1.1_all.deb 31c4e3d379150d9493add4fddf97b944 1847 admin extra molly-guard_0.4.5-1.1.dsc f2d2b242b5177b4cf904fd24758c1c65 6566 admin extra molly-guard_0.4.5-1.1.diff.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIVAwUBU7E2J5wxUDxthmOWAQhlBQ//d5vWqbOFMFSg1BwhKugCyBNJBnvp65Mx e/Hh+M8lLrPQy7F9juTu54G6bFYcwrYtP/p/nYVfETu9FMze6jC1ZGWXibLCLNXr 7AhfOWvARSruXFKNT7FS3Xtx5bGOxqFqvm6x+LEhNpofCCxTr54EN8R5iN1wDvEz FIr/ykia6goGRaOHWaUm3hJP7JYiorG8Gr45NZHmwHd2/974GxSGOg8rEltFi7wN mJsQHuaWZ+M5flHQst+RWrrJ6vBI/sSqsdyv6MOinHsP02KdxMWNxvq6dZWIpJoe qmo2RDCYxDTU8BAXDiP0Z9328O1TRUp7ZBJl2g5zjk9cex6q3gIx7H4cDd1oLCE9 muQcvtGcNRvJlRBbWpR18SHnc93m1OdLiLTXRTI7RSak/WJ7+bIHbbPMBhrzvcIo 6LEQN00pERs5bH5vHBOv5JCIzVa2QwnhxFEMKtVT0lM44ArCs2re9r6w/MYzRyp0 MuBJ9M3WcemhmV7Uw+jdhfEwvx5hKc4A0RneZ1m8fxseiuYTlQhfz6D61tyFuZOa 6QjKYr4YUJlJozj7cwiikYPVFLKAMe5BZR/+D1FslqkXdpbgzbBBoeq0OqHJQDmZ GrN95I3xge0tysyjQEpq9Lbs9Hbu3Of0Nwi/v2w4RHzi4ky20evG6LEZcWK9wrsT gXR7+LcB1dA= =q6iq -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/e1x2jmj-00020n...@franck.debian.org
Re: MATE 1.8 has now fully arrived in Debian
On Wed, Jul 02, 2014 at 01:53:06AM +0100, Wookey wrote: But OK. I get it - this is still too contentious to have any room for this sort of foolishness and if it's to exist at all it'll have to be called something boring. That's a little sad, but we'll all survive. This isn't supposed to be a big deal, just a small convenience. Thanks a lot, Wookey! -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: MATE 1.8 has now fully arrived in Debian
On Mon, Jun 30, 2014 at 10:27:49AM +0100, Lars Wirzenius wrote: On Mon, Jun 30, 2014 at 10:42:09AM +0200, Tollef Fog Heen wrote: ]] Thomas Goirand +1 for keeping the name which is funny What's funny about an OS stating publicly that a specific piece of Free software---shipped and installed by default by that very same OS---must die? If anything, it encourages people to *make* fun of such an OS. It's also offensive to those who think it's possible to work constructively together even when disagreeing on some things, and who would like to see a welcoming atmosphere in Debian. The attitude expressed in the systemd-must-die package name is bad for Debian, whether you're for or against or neutral about systemd. When a project the size of Debian makes a decision on a controversial subject, it is natural, and expected, that there is vigorous debate about the topic before a decision is reached. After that, however, if the debate continues, or members of Debian keep trying to fight the decision, or keep bringing it up over and over again, it hurts the ability of the project to continue working. If every decision we make needs to be re-discussed at the whim of any one disgruntled individual for years to come, nobody's going to have fun. +1 Amen AOL Bravo (etc.) -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: QA page showing git error
On Mon, Jun 23, 2014 at 02:16:07PM +0800, Thomas Goirand wrote: The name of the pseudo-package was exactly what I was missing. Thanks Russ! For future reference, the footer of the PTS reads Report problems to the qa.debian.org pseudopackage in the Debian BTS. Adding similar footer notes is highly recommended for all Debian services with a Web interface (hint hint nudge nudge). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Accepted cudf 0.7-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 27 May 2014 10:15:18 +0200 Source: cudf Binary: libcudf-ocaml-dev libcudf-dev cudf-tools Architecture: source amd64 Version: 0.7-2 Distribution: unstable Urgency: medium Maintainer: Debian OCaml Maintainers debian-ocaml-ma...@lists.debian.org Changed-By: Stefano Zacchiroli z...@debian.org Description: cudf-tools - command line tools for package upgrade problem descriptions libcudf-dev - C library to access descriptions of package upgrade problems libcudf-ocaml-dev - OCaml library to access descriptions of package upgrade problems Changes: cudf (0.7-2) unstable; urgency=medium . * upload to unstable Checksums-Sha1: 7aa61391ed921c0142065bb348293b1d032354d0 2140 cudf_0.7-2.dsc 7e377a82700c285a47cbcd2ea0ec6040673f3c69 3872 cudf_0.7-2.debian.tar.xz fa4606e3c92dab53bbed2fd00a53928c379282a6 98092 libcudf-ocaml-dev_0.7-2_amd64.deb 3378df4abe8f535f26a2181e7700701d3d36797b 124610 libcudf-dev_0.7-2_amd64.deb 6e1506fb6c2f0a9838ae2a9143ca602b3aeabdfc 183760 cudf-tools_0.7-2_amd64.deb Checksums-Sha256: 4758573b2b9d7b41f77b58a77e4132e20228242abb8de1264a2676c8db53bdc8 2140 cudf_0.7-2.dsc d136f0c9e68e5f47b9b4eb5b4951592647b2c4a40ebef3e13c9c2f36e83c8799 3872 cudf_0.7-2.debian.tar.xz 2a5819a44225037da8d44ce9126d2adce5eaec85ff0e21286ec12902a79cfa38 98092 libcudf-ocaml-dev_0.7-2_amd64.deb 07415237d2c68c63e996fa23915f3c047c5aa26017dba335f9c6c46130bb3202 124610 libcudf-dev_0.7-2_amd64.deb ecfa0271ea97de816439653cc1fd41a4fe49fb83265f74bdbcd803c8504da015 183760 cudf-tools_0.7-2_amd64.deb Files: 8cbb5d328199f6e9d08bcd9308e58ff9 98092 ocaml optional libcudf-ocaml-dev_0.7-2_amd64.deb 4b83c6f684e75dafd4cb253aeeb80a73 124610 libdevel optional libcudf-dev_0.7-2_amd64.deb db1e52d4248fa3535034fad6c4b16317 183760 devel optional cudf-tools_0.7-2_amd64.deb 89c0267356d7cde8812482f024d15729 2140 devel optional cudf_0.7-2.dsc 4ae71a8cdd6594488eecd9b9420cb8a5 3872 devel optional cudf_0.7-2.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIVAwUBU4RKvZwxUDxthmOWAQjuLhAAh4g4O2bk77NztdU/lqVB6dqzmEkuJ7u+ fweEtm0scT4Jw0HoGg9CKo4eq3nY1iaZAfhVqqDoi+J9KpXnM4XaPJ5Fj9htF9Si VRZ48iZ8ycf0w+ZbaxZRI2/0XM3IOhTpvj7MAW/bOKyqBZfru8m4G97kY8ZioQvL bBKOQ6524dyg8vqXcj+VxmJYClpj1dB37Xpp7dxJ53Oxq1jlw7D4na9ZxuoGJHAK OZL1gzG1gBKIwmGgXEykzRLg+jXjGxfX5CPiOdUvZXXRTYB1nl2Z0yuO+yf2Bz8u TRLhrDQotjUfvyc0VYXWkmmCIa0iS+AeXuam+pQT2nmKo7dBlIiMUiX5NIg3ICdm K0nN03/ODkWV93Q9g2hwgc3f7Jmr5gjP3OV8cA3gwSS75Osf/8dRn8SzaHVYx3co a+i3qCAtL2wC8nk9YVLY/HJV9YSGDRaddjXMLvy/hpF95asDZqbn7Y0RzaJI2/Vj 55u5W6yaJHra9imupK4bJKpM/Oo7n8UU6d2ghhAwEQSBP92vrchjpgpjYIgwAKZq CHAeSCi708sZ07WWAPjSzA/xhk9etabiUVS64O0yAmiQ/ECnku6cLK3N/2EsD4wM d+RihSzGVNqII29Bjfty9Dbn4qG4Psn2ppnf3UL6PX4z+t9aL3dZXEmLUU99NQU9 yC2LyHvSja4= =U8Uh -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/e1wpdw2-00065h...@franck.debian.org
Re: Release Notes (and any other documentation) (was: systemd-fsck?)
On Thu, May 15, 2014 at 06:33:41PM +0200, Luca Capello wrote: ...despite the above, MANY THANKS to all people writing the Release Notes (and any other official documentation), which is highly important at least for me, as well as a pleasure to read. Hear hear, strongly and fully ack'd. (And sorry for not being able to volunteer time to write some of them.) I guess one reason why we are inclined to think that nobody reads the release notes is that people who do read them are less likely to encounter upgrade problems. Those who don't read them often encounter problems, get back to us, and then we realize pretty quickly that the root cause of their problems is precisely that they haven't read the release notes. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Accepted cudf 0.7-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 29 Apr 2014 14:55:42 -0400 Source: cudf Binary: libcudf-ocaml-dev libcudf-dev cudf-tools Architecture: source amd64 Version: 0.7-1 Distribution: experimental Urgency: medium Maintainer: Debian OCaml Maintainers debian-ocaml-ma...@lists.debian.org Changed-By: Stefano Zacchiroli z...@debian.org Description: cudf-tools - command line tools for package upgrade problem descriptions libcudf-dev - C library to access descriptions of package upgrade problems libcudf-ocaml-dev - OCaml library to access descriptions of package upgrade problems Closes: 730529 Changes: cudf (0.7-1) experimental; urgency=medium . * new upstream release - include new upstream cudf-check manpage with exit code information (Closes: #730529) * drop no longer needed Debian manpage from the package * add Build-Depends on perl (just in case), it is needed for pod2man * bump Standards-Version to 3.9.5 (no change) Checksums-Sha1: 3477dadddee37942c8e6f7acba4e3baae32c7f4e 2140 cudf_0.7-1.dsc 33d6942caf5f008d6696c1200a2589e28ff7e7fa 54821 cudf_0.7.orig.tar.gz 728c9913858023facbb4a36a1da4b89eb7741ebf 3860 cudf_0.7-1.debian.tar.xz 01dc637fe38cc9d63d945fbf22ea8c83893a6762 98292 libcudf-ocaml-dev_0.7-1_amd64.deb a656d07f3ee48b432e4206b1bcebf685b00cf1ee 124536 libcudf-dev_0.7-1_amd64.deb a8ddce56ae5f89361686f1a03d3ee65032105b56 183516 cudf-tools_0.7-1_amd64.deb Checksums-Sha256: d478ba5f4385f3479f6a7b486828019197190db6a4875fce56f57c52be48d5ee 2140 cudf_0.7-1.dsc 92c8a9ed730bbac73f3513abab41127d966c9b9202ab2aaffcd02358c030a701 54821 cudf_0.7.orig.tar.gz 817f51671bce0d726fa83dd5d41cabf8ade7e73a0ad1493405d939b52c5af3eb 3860 cudf_0.7-1.debian.tar.xz f728c7bf12cac474599c731e250d6bc940c164f3c446369dea9b9a0eee57019a 98292 libcudf-ocaml-dev_0.7-1_amd64.deb ce28cc150d1ae3d1a5f4d6dc6fa9f0fd5ee25c4e737a5f211c1d45fd9c1e97f8 124536 libcudf-dev_0.7-1_amd64.deb aa81765ea17c40ed7de3d67977499074452eeea577b3f17d0b2ee857d47661df 183516 cudf-tools_0.7-1_amd64.deb Files: 936e23cfc13bddbb07661f5fa4e5ecb4 98292 ocaml optional libcudf-ocaml-dev_0.7-1_amd64.deb 0d23dd04a01ea82d65acbded9ad4aca2 124536 libdevel optional libcudf-dev_0.7-1_amd64.deb 925deb559ab7ace01033467cc8b6db8c 183516 devel optional cudf-tools_0.7-1_amd64.deb 1d47e380d633801e02cb838161ea5106 2140 devel optional cudf_0.7-1.dsc 2047222fcf78278c6a24ac619fc39abb 54821 devel optional cudf_0.7.orig.tar.gz 9182ce54fb44719830b0081636e0b2c9 3860 devel optional cudf_0.7-1.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIVAwUBU2BpupwxUDxthmOWAQioeQ//V/0sLBrea5vSJDsSjiqPM5kphA2/uUns xAeLHAYmJgkM7b/XBDEP0NX8GLF0bf1zBdZqXZnQ4SnoTjgNi3wX3sq3jbHTLKmS H8hPWA7YAzF34NlHM+DxA6y8sCJT2cFacvH9EbDLHw8fAanB0sluXr0ot8dSdweo 1Re0hUQEeRHX4C0iNXdcmY4Ur8gERDxt6CYwAE3PUZ2n+P4f2aKtrGP89OQAzju8 /iKj+xwcTZqyhh0+KPAkxABXTGj/T3cZNweg/Hsm68lbZAR6VWilcTTOb4sVWSL1 8r9uMdd5vowBlv5FI3bikHoMwERi6rW7HBcYnkVzPR5p82x8CIB5Uuk66Wg3 vTO9b0hLN0Y/grPxq/69wojC74EWy7xAolnsk6E/dYZRWVE7NsjdJZQLx7K1IoW3 iuRmjuwkLNP95BSWe6htwREefV/Xs1I1Ou75el2XgasfhsijjoFMmru8jXFfLuIz JZ6KW5JAC0743mNIVAQFxLbiD4JYvWaqqYhFQk65UPjoF9db/xmQ60dYL6zwMcNX TxLU7PH4Rc63Y43UK/+TVE1ygbx4/KwuSRit3YcVck7MsM/MXi3VJi6WhisVYeDG zH2/iJhnQqPSiq9ZG2SpQ1MZ4me8FozyNeCt8AV0ebpSLWW/jI+WnbahdZjUaEdH LahOhb4Q1pQ= =AiQ3 -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/e1wflhi-0002ro...@franck.debian.org
Re: Debian default desktop environment
On Fri, Apr 04, 2014 at 02:52:41PM +0100, Jonathan Dowland wrote: We go over the same ground over and over. I'm increasingly in favour of *no* default. You must pick one from a list on install. Randomize the list if necessary. And can I pass my granddad's phone call on to you when he is stuck choosing among names that are absolutely obscure to him like GNOME, Xfce, and KDE? We are software integrators, making default choices is what we do. We can't pass the bucket down to our users. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Debian source packages file types and SLOC
On Mon, Feb 03, 2014 at 12:57:01PM +0100, Jan de Haan wrote: When I would download all Debian source packages, extract them, determine of each the programming language it is written in and the SLOC, what would be the percentages of each programming language used? The Debsources instance running at http://sources.debian.net runs sloccount on every version of every Debian source packages it knows about. The sloccount output is then parsed and injected in the corresponding Debsources database. Unfortunately, the sloccount information is not yet presented nicely in the web interface. It's my current top-priority item in the TODO list, but not deployed yet. Once done, there will be both per-package views of the sloccount information and aggregated per-release views of it. In the meantime, you can access the raw (unparsed) sloccount output at URLs like this: http://sources.debian.net/data/main/b/bacula/5.2.6+dfsg-9.sloccount That, in combination with the API documented at http://sources.debian.net/doc/api/ , should allow you to retrieve all the information you need. However, if you need information for all packages, please do *not* hammer the service to retrieve it. Rather contact me in private and I could provide a dump of the relevant database tables. HTH, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: autopkgtest + chroot howto ? - Was: Re: Is it possible to run autopkgtest without a virtual machine ?
On Sun, Jan 26, 2014 at 02:45:04PM +0100, Olivier Berger wrote: I haven't been able to find a comprehensive set of instructions on how to get started with autopkgtest, and I imagined that chroot would be an interesting option. This doesn't directly answer your question (sorry), but you might also be interested in sadt --- simple DEP-8 test runner --- by Jakub Wilk, which has recently joined the devscripts happy bunch. Just install devscripts (= 2.14.1, currently in unstable only) and have a look at man 1 sadt. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Serata sulla pacchettizzazione per Debian a Varese: 20 gennaio
On Thu, Jan 16, 2014 at 03:18:03PM +0100, Elena ``of Valhalla'' wrote: Lunedì 20 gennaio il LIFO di Varese organizzerà una serata di introduzione alla pacchettizzazione per Debian. Ottima iniziativa, grazie Elena. Visto l'interesse in questo thread, segnalo a chi non lo conoscesse questo manuale (e pacchetto): http://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.pdf http://packages.debian.org/sid/packaging-tutorial che contiene un ottimo tutorial di pacchettizzazione Debian, riutilizzabilissimo in contesti come questo. È pensato per una giornata di workshop, con tanto di esercizi per gli studenti. È quindi un po' lungo per una serata più mordi e fuggi, ma ci si può facilmente ispirare ad esso (= scopiazzare allegramente). Visto che siamo in tema, segnalo anche che qui: http://www.debian.org/doc/manuals/packaging-tutorial/ ci sono molte traduzioni del tutorial, ma ne manca una italiana (hint, hint :-)) Buona pacchettizzazione! -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-devel-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-devel-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140116152321.ga5...@upsilon.cc
Re: removal of the vacation package
On Sun, Jan 12, 2014 at 03:22:59AM +0100, Marco d'Itri wrote: It does not support MIME and a lot of other things that are required to be a good citizen in today's Internet, so unless somebody has some really compelling arguments to keep it around and wants to adopt it I will request removal from the archive. It still seems to have a fair number of loyal users though. I see your points, but I wonder if we do have a decent replacement for it to suggest to our users. A replacement that is better than trying to mimic vacation by hand in procmail, and doing it wrong; arguably doing so will contribute to be even worse email citizens. If we do have such a replacement (I just don't know) please mention it in the removal bug report. Thanks for having maintained vacation over all these years! Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: [DEP 8] About XS-Testsuite: autopkgtest: time to remove XS- ?
On Fri, Dec 27, 2013 at 06:09:51PM +0100, Niels Thykier wrote: On 2013-12-27 17:35, Guillem Jover wrote: Do you know how many packages are there with autopkgtest support, and how many do not declare the field? For the former, apt-file search -a source debian/tests/control should do[0]. For the latter, there is a lintian check finds packages with without the field (or with the field, but without tests)[1]. To save others the time of doing this, in attachment the results of checking for debian/tests/control with apt-file and of grep-dctrl'ing Sources to check for Testsuite: autopkgtest field entry. I've computed them on unstable and experimental, considering main, contrib, and non-free. The relevant numbers are as follows: zack@usha:~$ wc -l have-* 251 have-debian-tests-control.txt 189 have-testsuite-autopkgtest.txt 64 have-debian-tests-control-but-no-testsuite-autopkgtest.txt For the latter file I also attach a dd-list. If you find mistakes in the results, please shout. FWIW, an old MBF about absent Testsuite: autopkgtest is at [1] and looks halfway through completion. Some of the already resolved issues were initially marked wontfix, but have then been corrected. Most of the remaining bugs seem to be affecting zope-related packages and other zope packages have been fixed already. Cheers. [1]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=missing-testsuite-header;users=autopkgtest-de...@lists.alioth.debian.org -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » Adam Schmalhofer adam.schmalho...@gmx.de apipkg execnet pytest-xdist Alessio Treglia ales...@debian.org apt-clone (U) Alexander Neumann alexan...@debian.org task Antonio Terceiro terce...@debian.org rake (U) ruby-switch (U) Arnaud Fontaine ar...@debian.org python-mechanize (U) zc.buildout (U) zope.testbrowser (U) Barry Warsaw ba...@debian.org tox Bradley Smith bradsm...@debian.org delta Brian Sutherland br...@vanguardistas.net bobo (U) python-chameleon (U) python-mechanize (U) sourcecodegen (U) transaction (U) zc.buildout (U) zc.lockfile (U) zconfig (U) zdaemon (U) zodb (U) zope.authentication (U) zope.browser (U) zope.cachedescriptors (U) zope.configuration (U) zope.contenttype (U) zope.copy (U) zope.dottedname (U) zope.event (U) zope.hookable (U) zope.i18n (U) zope.i18nmessageid (U) zope.location (U) zope.proxy (U) zope.publisher (U) zope.schema (U) zope.security (U) zope.sendmail (U) zope.sqlalchemy (U) zope.testbrowser (U) zope.testing (U) zope.traversing (U) Christian Perrier bubu...@debian.org samba4 (U) Christoph Berg m...@debian.org postgresql-common (U) Clint Adams cl...@debian.org haskell-yesod (U) D Haley my...@gmx.com libstxxl (U) D Haley my...@yahoo.com libstxxl (U) Debian Bazaar Maintainers pkg-bazaar-ma...@lists.alioth.debian.org bzr-rewrite bzr-stats bzr-svn Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org haskell-yesod Debian PostgreSQL Maintainers pkg-postgresql-pub...@lists.alioth.debian.org postgresql-common Debian Python Modules Team python-modules-t...@lists.alioth.debian.org gamera (U) pyqt5 python-byteplay (U) Debian Ruby Extras Maintainers pkg-ruby-extras-maintain...@lists.alioth.debian.org rake ruby-switch Debian Science Maintainers debian-science-maintain...@lists.alioth.debian.org libstxxl Debian/Ubuntu Zope Team pkg-zope-develop...@lists.alioth.debian.org bobo python-chameleon python-mechanize sourcecodegen transaction zc.buildout zc.lockfile zconfig zdaemon zodb zope.authentication zope.browser zope.cachedescriptors zope.configuration zope.contenttype zope.copy zope.deprecation zope.dottedname zope.event zope.hookable zope.i18n zope.i18nmessageid zope.location zope.proxy zope.publisher zope.schema zope.security zope.sendmail zope.sqlalchemy zope.testbrowser zope.testing zope.traversing Dmitry Shachnev mity...@gmail.com pyqt5 (U) Fabio Tranchitella kob...@debian.org bobo (U) python-chameleon (U) python-mechanize (U) sourcecodegen (U) transaction (U) zc.buildout (U) zc.lockfile (U) zconfig (U) zdaemon (U) zodb (U) zope.authentication (U) zope.browser (U) zope.cachedescriptors (U) zope.configuration (U) zope.contenttype (U) zope.copy (U) zope.dottedname (U) zope.event (U) zope.hookable (U) zope.i18n (U) zope.i18nmessageid (U) zope.location (U) zope.proxy (U) zope.publisher (U) zope.schema (U) zope.security (U) zope.sqlalchemy (U) zope.testbrowser (U
Re: [DEP 8] About XS-Testsuite: autopkgtest: time to remove XS- ?
[ adding autopkgtest-devel to Cc: ] On Fri, Jan 03, 2014 at 12:36:38PM +, Ian Jackson wrote: FWIW, an old MBF about absent Testsuite: autopkgtest is at [1] and looks halfway through completion. Some of the already resolved issues were initially marked wontfix, but have then been corrected. Most of the remaining bugs seem to be affecting zope-related packages and other zope packages have been fixed already. Perhaps rather than having another MBF, a better approach would be a lintian warning ? Lintian is already aware of this, as mentioned by Niels: http://lintian.debian.org/tags/inconsistent-testsuite-field.html but the tag is currently not a warning. Did you mean to suggest that we ask the lintian maintainers to promote that tag to an actual warning? FWIW, I'd welcome that. Regarding the MBF, I didn't mean to propose another one. I was merely pointing to the old one to observe its evolution over time. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Proposal: switch default desktop to xfce
On Fri, Oct 25, 2013 at 11:57:29PM +0100, Steve McIntyre wrote: I would not be opposed to changing the default for xfce for now, and reverting it if gnome's improvements make it a better choice. OK. I suggest that we *try* that for now. If we try, what will be the criteria for assessing whether the experiment has been successful (and hence worth keeping for Jessie) or a failure (and hence reverting it)? Hint: I don't think that the amount of opinionated posts anti-GNOME or anti-Xfce posted on debian-devel is a good success metric :-) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Proposal: let’s have a GR about the init system
On Fri, Oct 25, 2013 at 02:03:38PM +, Thorsten Glaser wrote: Let’s GR it. No. I think I've already argued in the past against this idea on -devel, possibly even in reply to you, Thorsten. As I can't find my post back then, let me reiterate. GRs should be used for societal and policy[*] decisions. Using GRs for *technical* decision is stupid. We really need to stop thinking that every single member of the Debian project, just because he/she is a DD, has a clue on every single technical matter that go on in the project. And note that proving you have a clue on something in Debian is pretty easy: just work actively on that matter, being the maintainer of related packages, or having a verifiable flow of working patches against them, etc. [*] in a broad sense, not related to the document called Debian Policy On one hand, the belief that every DD is technically omniscient is the reason why we still have so many pointlessly heated debates on this mailing list. We would have way less of those if we let only people who have a clue debate specific matters. Unfortunately, many of us seem to be too arrogant to realize they, in fact, don't have a clue. On the other hand, if we stop believing that every single DD is technically omniscient, we would realize how foolish is to use GRs to vote on technical matters. Doing so results in taking important technical decisions essentially randomly. Based on popularity of the various options, trends, vocality of the supporting groups, etc. That's not what Debian is or should be about. Note that the *possibility* of taking technical decisions by GRs is important, as it provides a balance of powers within the project, but we should always do everything in our power to avoid doing that. The decisions about the init system (both which are the supported ones? and which is the default one?) clearly belong to the tech-ctte at this point. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Please assume good faith (was Re: systemd effectively mandatory now due to GNOME)
On Thu, Oct 24, 2013 at 11:00:42PM +0900, Norbert Preining wrote: On Do, 24 Okt 2013, Adam Borowski wrote: My apologies, I overreacted. Clear critic with real background - many of us have the same experience - (how many times did my system break in the last years due to GNome?) are silence by Code of Conduct Now, let me know - is this the new way of silencing critical voices? No. But it is a gigantic leap forward in the culture of our community. Thanks Adam! -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Bug#724980: ITP: trove -- Database as a Service for OpenStack
On Mon, Sep 30, 2013 at 09:28:33AM -0700, Clint Byrum wrote: And what user-facing API would you use to let the user do that apt-get install after automatically provisioning a server sized right for that DB? And to add users? Holger have indeed been a bit concise, but I suspect his point wasn't to dispute the usefulness of this software, but rather to encourage the packager to add a more comprehensive description of it to the Debian package :-) Adding some of your points about API availability would be a very good start. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Bug#688251: #688251: Built-Using description too aggressive
On Mon, Sep 23, 2013 at 09:08:55AM -0700, Russ Allbery wrote: The question is how to make it clear that's not the intent, which requires figuring out how to separate the other use cases from the gcc and glibc case. I guess the general answer you're looking for depends on the use cases Built-Using wants to address (is it licensing? is it code embedding to help the security team? is it just metadata to note what has been built against what?). I confess that the answer to this preliminary question is not clear to me (anymore). I suppose one possible approach is to just explicitly exclude the C library and compiler from the current wording. (Although I'm not sure that should be the case for every compiler; for example, do some of the more complex compilers for languages like Haskell actually need Built-Using?) I'm no Haskell expert, but AFAIR the language behave very similarly to OCaml in this respect. OCaml does static linking (of native OCaml code, not necessarily of external C libraries) by default, so, at the very minimum, you have code embedding in all executables. For OCaml you might also have code inlining between libraries; I'm not sure if that's the case also for Haskell or not. Now, does that mean that you need to add OCaml/Haskell software to the list of exceptions? I'm not sure, it really depends on the intended Built-Using use cases. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: asking for advice: all dependencies incl. version numbers
On Tue, Aug 27, 2013 at 10:17:47AM +0200, FARKAS, Illes wrote: Thanks. I found that Managing the Complexity of Large Free and Open Source Package-Based Software Distributions (PDF at http://goo.gl/NTPqlE) describes the project best. By the way, which is your favorite paper from IRILL? Dear Illes, that paper is indeed the starting point of several research works in the field of formal analysis of relationships between software components, and in particular FOSS distribution packages. If you're interested in that field, you might want to have a look at a recent survey paper (disclaimer: I'm one of the author, an) entitled Formal Aspects of Free and Open Source Software Components which is freely available at: http://upsilon.cc/~zack/research/publications/fmco2012-foss-components.pdf ( BiBTeX: http://upsilon.cc/~zack/research/publications/fmco2012-foss-components.bib ) In there, we made an effort to review research work in the field, encompassing not only the work done in the context of EDOS / Mancoosi / IRILL, but also those by other researchers around the world, to the best of our knowledge. If you're starting in the field, that might be valuable to you. As we're quickly getting off-topic for debian-devel, feel free to contact me (and likely the others who have participated in this thread, even though I cannot speak for them) off-list. All the best for your studies, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Bits from the Release
On Sun, Aug 25, 2013 at 05:09:22PM +0200, Niels Thykier wrote: How you can help (NEW-TEST-HELP) Add tests to your packages. The full specification for these tests are available from [AUTOPKG]. If you need inspiration, consider looking at some of the existing autopkgtests[FIND-AUTOPKG]. We need to have the autopkgtest tests run. Holger Levsen suggested that jenkins.debian.net has the necessary hardware to support these tests. Asheesh Laroia has kindly spent some time during DebConf13 researching and experimenting with setting up such jobs. So, in the context of work to periodically run various sorts of static analysis tests on Debian packages [1], we (myself, Sylvestre Ledru, Léo Cavaillé, and Matthieu Caneill) have considered using Jenkins. Based on feedback from Matthias Klumpp and his experience in using Jenkins for Tanglu, we have concluded that it didn't really scale to the point that we needed (number of Debian packages * number of checkers). We ended up using Paul Tagliamonte's debile infrastructure [2]. I don't doubt that jenkins.d.n can be leveraged for the time being, giving the low amount of autopkgtests currently available. But you might want to check with Matthias or similar experiences before committing to using Jenkins for this. Apart from this, hopefully useful feedback: kudos for these saucy bits from the Release Team :-) Keep up the good work! Cheers. [1]: preliminary, not necessarily up to date, results are available at http://firewoes.debian.net/ for those who are interested [2]: http://debile.debian.net/ -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: DebConf 2013
On Sun, Aug 11, 2013 at 10:13:04PM +0200, Giuseppe Sacco wrote: io ho appena capito che potrei partecipare il martedì 13. Non sono registrato e non ho ancora capito se sia possibile presentarsi lì e partecipare per un solo giorno (ma immagino di sì). Se qualcuno lo sa, me lo scriva, per favore. Se altri fossero interessati (partenza in auto da Torino e rientro in serata) ditemelo, così dividiamo un po' le spese. Per la partecipazione giornaliera, sicuramente non c'è alcun problema. (Non ci sono controlli di badge per assistere ai talk, girare nel parco, oppure accedere agli hacklab, per dire.) L'unico dubbio è sui pasti: nel senso che certamente non sei stato contato, quindi sarebbe carino lasciare un obolo se mangi alla mensa. E certamente non è un caso che hanno ancora considerato :) Prova a chiedere su #debconf-team, oppure manda una mail a registrat...@debconf.org e vedi costa ti dicono. (Alla peggio, ti porto il pranzo :)) A presto, spero! -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Status of deb(5) format support in Debian
On Wed, Jul 31, 2013 at 10:16:02PM +0200, David Kalnischkies wrote: I know that everyone dreams about a stable API for a library, but I believe that even an unstable library at this point is way better than the status quo of having other layers like libapt (which is a proof that even if being unstable is a pain, the alternative would be worse – and that's a freaking C++ library …) providing makeshift replacements. FWIW, I agree with that. I mentioned the libdpkg-dev API warnings as data point. But I don't think an incompatible change in libdpkg* would be substantially worse than changes in layers (such as deb(5)) which are today being used today as APIs. OTOH, having a shared library would be much nicer for bindings to other languages than a static one. And if that means that the soname of such a library will grow indefinitely due to frequent ABI changes, well, so be it would be my take. YMMV of course. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Status of deb(5) format support in Debian
On Thu, Aug 01, 2013 at 02:18:13PM +0200, Helmut Grohne wrote: On Wed, Jul 31, 2013 at 06:56:40PM +0200, Stefano Zacchiroli wrote: I'm myself guilty of having implemented, back in 2007, python-debian's support to manipulate .deb files: the debian.debfile module. It is yet another Python implementation of deb(5), because back in the days there was no libdpkg* libraries I could wrap around (IIRC). Worse, I am guilty of also having implemented the same functionality in the same language again. The interfaces provided by python-debian are insufficient[1] for fixed-memory package processing. Is there any chance of getting this fixed in python-debian? It would likely require adding or changing a number of interfaces. Can you please file a bug report about that (ideally marking the pending ITPs as blockers for it)? Regarding changing interfaces it would be better not to do that, of course, but even more so because it's not clear to me how many users of the debfile module are out there in the wild. We can do a call for it or something, but let's move the discussion to an appropriate bug report first. For the compression support (data.tar, data.tar.xz), you can borrow the implementation from dedup.d.n. The license should be compatible and relicensing should not be an issue if needed. Indeed, this could be a move of the code if I could start using python-debian. I would surely welcome code deduplication (and the fact it comes from dedup.d.n makes it almost mandatory to do *g*). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Status of deb(5) format support in Debian
On Wed, Jul 31, 2013 at 06:24:32PM +0200, Guillem Jover wrote: Due to bug 718295, and in preparation to add non-gzip compression support for control.tar, I've tried to get an accurate view of the current deb(5) format support in software present in Debian. The resulting table looks pretty bad: https://wiki.debian.org/Teams/Dpkg/DebSupport So, about the following passage on that page: The current support seems quite bleak, and part of the blame goes to dpkg for not providing better interfaces for others to use, hopefully that will be remedied soon. Can you expand on the planned remedy and in how soon it might arrive? I'm myself guilty of having implemented, back in 2007, python-debian's support to manipulate .deb files: the debian.debfile module. It is yet another Python implementation of deb(5), because back in the days there was no libdpkg* libraries I could wrap around (IIRC). These days debian.debfile is lagging in compression formats support, as your table properly shows. (BTW, thanks for the bug reports!) That said, I'm not particularly keen of racing in features with dpkg/deb(5). I'd rather throw away the alternative Python implementation all together, and provide a Python wrapper around libdpkg*. But libdpkg-dev is still a static only library and comes with scary warnings about its API stability. Given the number of tools/libraries in need of fixing, this might be the good moment to rather ask them to migrate to some libdpkg* API instead. Thanks in advance for your advice, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Berkeley DB 6.0 license change to AGPLv3
On Sat, Jul 06, 2013 at 05:41:16PM +0200, Bernhard R. Link wrote: No, there is a really important difference. With GPL you only have to be careful when you give binaries to anyone, that you also give the source. This is a bit of a hassle, but worst case means that you cannot help others with the software changes you have done (bad enough but worth the hassle to have the source) if you miss some of the sources. But if the sources may contain any passwords or other internal data you cannot/do not want to share, so will likely the binary so that is no difference. On this level, the analogy GPL/AGPL still seems correct to me. A software distributed under AGPL will likely come with mechanisms already in place to point to its source code --- that might not be the case today yet, due to the scarce popularity of AGPL, but that's a separate matter. That means that you can easily run unmodified version of an AGPL'd program, for any purpose, without particular restrictions. If you modify the software you might get in trouble but, according to my personal ethics, that's the trouble you should have. However, please note that as long as you run the software only for yourself, you don't have any problem. You might encounter problems only in the case you've modified the software, you want *others* to use it over the net, and you don't provide the source code that include your modifications. That shift is coherent with the shift in the most common deployment pattern for software: handing software copies in the past, using remote services over the net nowadays. (Anyway, here we're getting quite off-topic...) -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Reporting 1.2K crashes
On Thu, Jul 04, 2013 at 06:48:47AM +0200, Kurt Roeckx wrote: clang also has an option to do that now I think, did someone try to run that on the archive? Yep, Sylvestre is working on it together with Leo Cavaille as a GSoC 2013 project https://wiki.debian.org/SummerOfCode2013/StudentApplications/LeoCavaille Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Berkeley DB 6.0 license change to AGPLv3
Hi Bradley, and thanks for your comments. On Wed, Jul 03, 2013 at 11:34:38AM -0400, Bradley M. Kuhn wrote: BTW, I'd suggest a rather unorthodox solution if developers are interested: fork this AGPLv3'd version of BDB, and begin making substantial improvements and changes under AGPLv3. That way, Oracle isn't the sole copyright holder, That is a pretty interesting proposal, indeed. and if Oracle were to take action under a clause of AGPLv3, other copyright holders could intervene and indicate they disagreed with Oracle. If the case went to litigation, Oracle would have a tough time because the other copyright holders would be expert witnesses (in the USA sense -- not sure what the equivalent is elsewhere in the world) who were saying Oracle was acting unfairly and over-reading the license terms. (I'd certainly be willing to be an expert witness as the license's co-author in such cases.) So, I wonder, do we have any idea (due to them having already been mentioned publicly elsewhere) about the craziest interpretation of AGPL that the evil guys might come up with and, at the other end of the spectrum, the most restrictive one? AFAIK AGPL hasn't been tested in court, yet. But I can't help wondering what people are really scared about here. Is it the quine scenario (IMHO ruled out by the license text, but obviously you never know...) that people fear to have to implement, worrying about the fact that simply providing URLs to tarballs wouldn't be considered enough? Or is it something else? Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Berkeley DB 6.0 license change to AGPLv3
On Tue, Jul 02, 2013 at 09:17:13AM -0700, Russ Allbery wrote: As an upstream for INN, I think doing such a thing would be completely absurd, and would rather just drop Berkeley DB support entirely and make everyone switch to a different overview method than do anything of the sort. I'm curious, can you elaborate on why as upstream you'd refuse to add something like a protocol command that return a URL pointing to a tarball containing the source code of the INN version the users are running? At times, I'm really surprised by the upfront opposition that AGPL could get in Free Software cycles and I'd like to understand more your motives as an upstream. I mean, sure, it *is* more tricky to provide such a URL for users that will be running a *modified* version of INN. But it is exactly the same kind of difficulties that people distributing modified copylefted software will have to face to uphold GPL (or equivalent) terms. AGPL is really nothing more than the adaptation of copyleft to a world where software usage has shifted from compiled binaries people run on their computers, to services they access over the net. For people who are fine with the copyleft approach (and of course not all of us are) AGPL shouldn't be particularly shocking. In that sense, AGPL is just a new release of GPL that closes a long outstanding bug titled provide a license port for the Software-as-a-Service era. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Berkeley DB 6.0 license change to AGPLv3
On Thu, Jul 04, 2013 at 02:08:33PM +0200, Vincent Lefevre wrote: What about users who patch and rebuild software locally? That was the second paragraph of my post (that you snipped :)), i.e.: I mean, sure, it *is* more tricky to provide such a URL for users that will be running a *modified* version of INN. But it is exactly the same kind of difficulties that people distributing modified copylefted software will have to face to uphold GPL (or equivalent) terms. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Reporting 1.2K crashes
On Tue, Jun 25, 2013 at 01:28:10AM -0400, Alexandre Rebert wrote: Please let us know if the reports are good enough to proceed with the filing, or if any additional information should be included in the report. Heya, I haven't yet seen this mentioned yet, so here it goes: if/when you go ahead with submitting the actual bug reports to the Debian BTS, please usertag [1] them appropriately (e.g. using as user some valid email contact point of yours or your team, and as usertag, say, mayhem-crashes). Then please report to the list the user and usertag you've chosen. That will make it easier to track what happens overtime to the bug you reported. [1]: http://www.debian.org/Bugs/server-request#user And thanks for this interesting experiment! But please consider releasing Mayhem as free software. Not only that is what the Debian community is about, so you will likely find even *more* people willing to help with this experiment if you do so. But doing so is also in the interest of better reproducibility and peer review of scientific experiments, as you certainly know. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: DebConf 2013
On Thu, Jun 06, 2013 at 07:13:50PM +0200, Giovanni Mascellani wrote: Io vado. Presente anche io! Andrò in moto, probabilmente da Bologna. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: default MTA
On Thu, May 30, 2013 at 12:16:38PM +0200, Carlos Alberto Lopez Perez wrote: On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. Indeed it is interesting. Whereas Debian has a majority of GNU/Linux installation for _web_ servers according to: http://w3techs.com/technologies/details/os-linux/all/all it's a _relative_ majority, smaller than the sum of the other distros you've cited. Here's an experimental way to test the assumption of Debian leadership on the mail server market: let's switch our default to Postfix and see if the figures change :-) /SCNR -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Switching to mozilla ESR in stable-security
On Thu, May 30, 2013 at 03:20:29PM +0200, Didier 'OdyX' Raboud wrote: Which web browsers would remain in stable if we applied this criterion consistently? Although that makes me very sad, if we (collectively) give up packaging browser extensions (hence letting our users rely on third-party repositories to get access to [non-]free binaries) and frozen browsers in stable, then maybe the correct answer to your question is none. And do you think that would be the best outcome for Debian users? FWIW, I don't. I think the compromise that the security team is proposing is much more reasonable than such an alternative. Note that the presence of non-free extension in the 3rd party repositories that come pre-configured with Debian-distributed browsers (and incresingly more other software) is a different problem. And one we should tackle, IMHO, but that's for a separate discussion. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- 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/20130530132922.gb6...@upsilon.cc
Re: Switching to mozilla ESR in stable-security
On Thu, May 30, 2013 at 10:56:23AM -0700, Russ Allbery wrote: The actual proposal in the bug report is to add backports.debian.org to the default sources.list file in the installer, but not otherwise change anything about the backports configuration. Specifically, the archive would remain NotAutomatic ButAutomaticUpgrades. This would *enable* users to install software from backports if it either didn't exist in stable at all or if they explicitly requested it from backports, but would not install such software by default. I think this is an excellent idea and is absolutely something we should do. backports.debian.org helps considerably in easing the pain of our long release cycle but is underadvertised. This would make using it much simpler and more straightforward for our users. FWIW, I concur. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Switching to mozilla ESR in stable-security
On Thu, May 30, 2013 at 08:29:16PM +0200, Didier 'OdyX' Raboud wrote: FWIW, I don't. I think the compromise that the security team is proposing is much more reasonable than such an alternative. That compromise (which I do definitely support for wheezy) puzzles me most for the precedent it creates: if we give up [0] maintaining some of the most security-sensitive softwares up to our stable policy, why should other packages be bound to it? Well, it seems to me that the decision chain is pretty clear here. The we you've used above is IMHO defined as the security team. It's them doing the amazing security job they do for Debian, therefore it's perfectly fine for them to decide where and when to make compromises. Other packages will be bound or not to similar compromises depending on the judgement of the security team. Note that it's already the case that the level of security support for packages in stable varies on a case by case basis, see for instance: http://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security *By default* everything it's held up to the same security standards, but we do apply different policies when needed, as decided by the security team. What's important is to clearly communicate to our users what they're getting. Sometime we can do that in advance, as above, in other occasion we might have to do it a posteriori. That's life. (And I suspect that, given an unlimited supply of manpower, the security team will be happy to do all the backports we needed. Unfortunately we simply don't have that supply.) Note that the presence of non-free extension in the 3rd party repositories that come pre-configured with Debian-distributed browsers (and incresingly more other software) is a different problem. […] And one we should tackle, IMHO, but that's for a separate discussion. I'm not sure it's that much of a separate discussion: as the original message mentionned, we'll get the ESR17 and then ESR24 version of Firefox/Iceweasel in Wheezy, including the new features related to extensions and 3rd party repositories, which are out of our control. I must admit though that I don't know precisely how this area evolves and I do trust the Maintainers of Mozilla-related packages to do it right. You're right, I've been unclear. What I meant is this: whether the 3rd party repositories that come configured with our browsers list non-free extensions by default or not (which is a change I would welcome) is a separate discussion. The existence of those 3rd party repositories, no matter the free-ness of the extensions, clearly is impacted by our security policy decisions. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On Wed, May 22, 2013 at 10:13:23AM +0100, Dmitrijs Ledkovs wrote: Some produce more open source software than others, and all of these will be ranked differently by each person differently, am I still yet to be screwed by Canonical's projects. Please correct me if I am wrong, but none of Canonical CA covered projects yet to […] When looking at copyright assignments to companies, the above is hardly the point, in my opinion. The problem (quotes because it's just the way things are) with companies is that they can be sold and bought, and the new management can have entirely different objectives, and strategies to reach it, than the former management you trusted. We have seen plenty of bad examples of this happening to open source companies in recent years, I'm surprised we haven't learned the lesson yet. Your historical record arguments here say vary little about what could happen in the future to CAA/CLAs you make to for-profit companies; the only guarantees you have are the terms of the agreements. Arguably, risks of changes in objectives and strategies exist also for non-profit organizations. But when they are much lower when those organizations have clear governance structures and contestable (it is left to the reader to judge whether FSF fits this definition). Also, the mere fact that you remove profit from the equation reduces quite a bit the overall pressure in changing objectives and strategies. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On Wed, May 22, 2013 at 01:35:54PM +0200, Wouter Verhelst wrote: No, that is *exactly* the point: yes, companies may have different objectives, but that doesn't mean they have to use different ways to get to those objectives. A contract is binding, whether one party to the contract is a nonprofit, a company, or a private person; if you receive promises (in writing) that they won't do a particular thing, and they then go ahead and do it anyway, you have perfect grounds to sue them for breach of contract. ... except that the examples being made were of activities that are permitted by the terms of the agreement. The discussion was about whether you should trust that a company won't do in the future activities that you consider bad (but which *are* permitted by the agreements), based on their past record of not doing so. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
