Accepted gv 1:3.7.4-3 (source amd64) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 09 Mar 2019 19:36:40 +0100 Source: gv Binary: gv gv-dbgsym Architecture: source amd64 Version: 1:3.7.4-3 Distribution: experimental Urgency: medium Maintainer: Bernhard R. Link Changed-By: Bernhard R. Link Description: gv - PostScript and PDF viewer for X Closes: 729618 824745 902141 924028 Changes: gv (1:3.7.4-3) experimental; urgency=medium . * also register application/postscript in gv.mime (Closes: #902141) * cherry-pick commits from unreleased upstream: - Fix crash in zoom.c (Closes: #824745) - Do not segfault on buggy postscript files (Closes: #729618, #924028) Checksums-Sha1: cd4c9111a452b499e4928fd09fec9ee727c6ca81 1762 gv_3.7.4-3.dsc d865000b1c2d7d4247575ad9096a618d7dd99b2d 13960 gv_3.7.4-3.debian.tar.xz d4197206cbce140045c03f9fe6b6b3b2f780a653 586852 gv-dbgsym_3.7.4-3_amd64.deb 0ab5fb381c7f392f59fa93154f359d8f99d703bc 6384 gv_3.7.4-3_amd64.buildinfo e7be457aaa4d7c99a5f9d354d6a981cecb9f2b99 219020 gv_3.7.4-3_amd64.deb Checksums-Sha256: c4556200a591c5b3655f344bdbfef90207edb05b359ae45ca4f6168e1ae5fcd0 1762 gv_3.7.4-3.dsc 63bd05af678dd7999659a10989eb4152e7b8616f137a65ae4857640f7e296281 13960 gv_3.7.4-3.debian.tar.xz 21d993b8fc75b5cab2a50316bce2f670bcf5e97a0c5651c592dbc45fb99f5222 586852 gv-dbgsym_3.7.4-3_amd64.deb e23540ff237cd85063f041ad2724c6153e4e4ec934789473fc4d0f9035289a09 6384 gv_3.7.4-3_amd64.buildinfo 38fd735a806736b0e97f493f21b78d3bb872d77bc6ae10f662c4509fd128bc0f 219020 gv_3.7.4-3_amd64.deb Files: 8eaae80a7aae8ce29d9495d132c5c426 1762 text optional gv_3.7.4-3.dsc ab8ee1c2e6930b65fb7dd3edcaeab24a 13960 text optional gv_3.7.4-3.debian.tar.xz 2b65c96c88c8756e86943d27c895541c 586852 debug optional gv-dbgsym_3.7.4-3_amd64.deb 1e378c60dcfbdaf590c85e1641e3e460 6384 text optional gv_3.7.4-3_amd64.buildinfo cf7c1b3d90b0f3a3192060a2a72285c4 219020 text optional gv_3.7.4-3_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlyEH8gSHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4Ff7OwP/iJAo/Yol5Cog3q2cRyIbxLD07LSlZz/ P7qfXNzCMn2cTM8tNAvbk2FgSejccJuoN7FQlHO04I+2+fqZQwDrIsleEaOTAz8D AU/nJ6baCmVTcLCzEWYZ3bB7ZjgKgYrjRuRjFIqEgfjmFszbbA9ftCrPCPoNiuPy hW2Vm5p0OWL3qxrOGgPjYXnfXpAMVKf8atwSA1tTwUIDjQ+rSnU4lgt9nzjYURtd aV2NDWb+LeTRu2dFuA2BV27nfSv2b782kzKeIN2kem7Rq/+XEOkNLPufU8UxyZOK c4n+g9jhcLCz1LcH/DY8a82dFh6L3Ygmj7JqjVRYnhE7W2LwNwUMe/hIYfPPg3Ez ynTZxB/a0AWJ5UGvWoovka+D4Wwp5M5utDsFoU/vnn5preExIbCJo3reKAlOEwec 11KqVQHNXqfsx72HH1E8dNj9xyBmuF09FNDkXg6qyFFfrePhICm9ikKPPbAWOGxN 9mm65CZb93QxkZBkrs7983PdvBboWEgYQZPG1JTfZc3qwAjWHk4jtAkSPW1j2kKH ti2UEbwcgmORet3yMJqHnLLwIHEn8J//w0np9NtfHTTGo7Wsc15enjATrLYvMQ8C sd5wG5qPl8FFJi1mV8mie6kEhRkanQwR5Bie2oVoKIEsRwz1OWm6C5wnofUR6eyO iBNkhWoyc7QM =+oyG -END PGP SIGNATURE-
Accepted xtrace 1.4.0-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 25 Feb 2019 11:12:54 +0100 Source: xtrace Binary: xtrace xtrace-dbgsym Architecture: source amd64 Version: 1.4.0-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link Changed-By: Bernhard R. Link Description: xtrace - trace communication between X client and server Closes: 797174 797175 797176 797177 Changes: xtrace (1.4.0-1) unstable; urgency=medium . * new maintenance release - add some bugfix and many new definitions (Closes: #797174, #797175, #797176, #797177) * switch to newer debhelper, dpkg helper scripts * drop obsolete homepage, vcs-*, watch information Checksums-Sha1: 0d163e73b3a0a08e6a9db8963cbeff8c929c312e 1671 xtrace_1.4.0-1.dsc 63bb7a4ac24c91e2c21591c7f764a4cd5e499f04 151268 xtrace_1.4.0.orig.tar.xz 4888c894849c7bdd321fc66262b63cf9281f5c1c 6556 xtrace_1.4.0-1.debian.tar.xz 8d5441417944183e882891f9446e7b3119dc518c 121480 xtrace-dbgsym_1.4.0-1_amd64.deb 2e3027e7fe2f05a5e5904f89e99304c71fa4a82a 5434 xtrace_1.4.0-1_amd64.buildinfo 27f3efd58af593e95e31d28e60234e64bdeccf1b 92676 xtrace_1.4.0-1_amd64.deb Checksums-Sha256: 600522b4bf2a129d1d96dc50a4b8075be9af6d73e6212e5de2eab95bf0fe3f45 1671 xtrace_1.4.0-1.dsc 8aef15eb42fa36c80dd8185d0a940321ba851328a3738ae897b4352e94d6331e 151268 xtrace_1.4.0.orig.tar.xz 44d02cd284ccd55ee8167ddc89beb390f2d3ecafe3e6d8809075220c9210deeb 6556 xtrace_1.4.0-1.debian.tar.xz 1d094d4c42b80b94f24a2e57a3819da02ba1b5c7140a1bfd22b3961c4158a1f8 121480 xtrace-dbgsym_1.4.0-1_amd64.deb 3af7bd85accee9f24456500713ea2b9f802e4b0f671913483df82935492ac1ba 5434 xtrace_1.4.0-1_amd64.buildinfo b652ed11b5bc869b193f3ab2f24f3ead3587a524aa67dfe426d7a069b3d7f15b 92676 xtrace_1.4.0-1_amd64.deb Files: 23a1b48613b0c3f25cd1f50b81a33535 1671 x11 optional xtrace_1.4.0-1.dsc ed30b9ca48ba88f1c7532deca1ce0128 151268 x11 optional xtrace_1.4.0.orig.tar.xz 78016ca5f1ce6b1bb0d4873688e116e3 6556 x11 optional xtrace_1.4.0-1.debian.tar.xz 1e769cea469a45b1fdc77b133bce6260 121480 debug optional xtrace-dbgsym_1.4.0-1_amd64.deb fa797f2541b896d58df689038deb420a 5434 x11 optional xtrace_1.4.0-1_amd64.buildinfo b4040e0a99eabe0f7d91afadcf166e8c 92676 x11 optional xtrace_1.4.0-1_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlxzwUgSHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4FfSJEP/23ZjuPx3M1EYmn1L7kotWOO3Q72Tbea EB2CuksskM2fId5Cnqhk7k4DDq2ggUkRaRrlA5nyL6K/Dkr51cLLNtWYFkfif0Xj M1LRHVZKHWRVVOfnzTeVZ0BSu+3Z6x4sp6FybxyieliCl56W5NztKHw6T2kbwS3g 1rnCK2ocWL29xAOzcAnhM0oE3Bcoj0CHUan6ajvC8P7C7H1yG+jqAqmh58hmqoyL yo5UPT6cbqn2382pKg+AurDoOlKM5bWJYMoJHqcJHeWWOaqfng9ovf5uVV3MAzmq RhkYqGXGc7mqzvmQAgImgxxBKD1dZRYH+0ZJQLFBipt3wen33mkHCiCxWaV5w4pF tMp0OCdjzJaqmp451HP4sFPW/bSRLiWpcEIHPo9T1J4NXSafBaye0tFYXO45mRUl YciEGl/nsNkUSX83oaiC7IcjdonkuA+tH7EC/Xbd3XyH3m5bQO7Lheo1YItpR8UC hXkFTLyqJS44v5AejuXoJFEZOc3rFbVETPUZXnZhoFUeppNUsI+VO16YA88gP6B5 rYeRPuA1m7F0qcydiLclPc2RrCvQvTd2mh2CUhyiXNsoVGTEgOeCKkgxj3lBY1DW LDdpUlgwESI/LSSEAKoQkWVgppKrs8irmE5sgDUhRtohkiYq1lVOKUuVUug81iQV JUkn2JdnoAWD =b8OD -END PGP SIGNATURE-
Accepted git-dpm 0.10.0-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 03 Feb 2019 13:33:53 +0100 Source: git-dpm Binary: git-dpm Architecture: source all Version: 0.10.0-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link Changed-By: Bernhard R. Link Description: git-dpm- git Debian package manager Changes: git-dpm (0.10.0-1) unstable; urgency=medium . * new version - add support to record .asc files and storing them in pristine-tar Checksums-Sha1: 3ee121c447d60059636e6e2afaa6041efcb514ae 1707 git-dpm_0.10.0-1.dsc cb218e345d034ee67972f855929550329195f869 120532 git-dpm_0.10.0.orig.tar.xz 03a9ea59e409dd947a4af48a1a5f0a409fb6c1c0 3328 git-dpm_0.10.0-1.debian.tar.xz b4d67e9843db59457a3952390894b198002964d9 356124 git-dpm_0.10.0-1_all.deb b9a8252e4c24c9354a962815ff80ed59c9be12d0 6692 git-dpm_0.10.0-1_amd64.buildinfo Checksums-Sha256: 08e5ba03e9dc46ef84d6c41b0cc21606eafdd98db7fb0812ce96163bdf01d7db 1707 git-dpm_0.10.0-1.dsc ce03811429fecafb4c3eb159c27ffd5bbf86f0fd8f6866fa2e8aad2433d3c875 120532 git-dpm_0.10.0.orig.tar.xz 9146649e4476194ac76c12d870efc484445b00e53ef83ad22fea92f8168527ac 3328 git-dpm_0.10.0-1.debian.tar.xz 8abd83ea5975e9185c0696d596a31ed263f2f91268e30d35a78efc7770dfb5f8 356124 git-dpm_0.10.0-1_all.deb 547302fc9363df177207aee06d95c82ffc89efb780cf4a06edb4e0ef4e6d 6692 git-dpm_0.10.0-1_amd64.buildinfo Files: b442533a136660f18da0ab38930828d9 1707 vcs optional git-dpm_0.10.0-1.dsc 98bcee5e276bcb25cdca4562e23894dd 120532 vcs optional git-dpm_0.10.0.orig.tar.xz 5e9e491c33b4faf5da41d121604813cd 3328 vcs optional git-dpm_0.10.0-1.debian.tar.xz 9d1799a14d618b1ecad56f7213cdd508 356124 vcs optional git-dpm_0.10.0-1_all.deb dd23b047b89089e4b74991b502ac8556 6692 vcs optional git-dpm_0.10.0-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlxetVUSHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4FfbjkP/RX6f3+gsVS5rX8yx97wEfU5zZ+SoThL fi/qFAlJSk/mJeQ+w3RxqChnJlEHbHlKhwnJHqkc13Tz/7QS0oPr+3/smw3ENg4z w5HNeMmYvWu04uc97guUx94KDgzCLHOFnwa28Xwc8q2/z/vySaR6pG7WjKj/OKCX 0O4cpC4rbPTfiVfppwCjXGP7Va3yHETJfMH3cus2DoTHuPktKhPIhny/JwiVPZzG kE9p7bGgs/f6tvmGmiLDlqCgZDUfLgf41NMEmBtBB46MVbh+ls0FuGx2DlyM/ao5 peX8fGLA1JywEXELQsR9Y+/+bxzw8hwgqDNdkssCW2arKzFEGZtfEBJzkbs4KowV S3W6zEYRhOFtkvxtvA3PRmCdc8AELhHKmP0PbCu+DkoiVHFlkhtXnD0lk3mSqkjP SHWMgJ6CQiGTKqAEmJcseU/gqWgD+FuYknXwf15p+h/+h6Lgav7IEdta0u27+THZ Kp6pZhZPRrJ3A4EvSm2Y//HaeXMGFMkoYCiSemrIghW/ml7tsVvZyBvdqR+QgsB+ pE45Tpg3WaV/8/SXTqJTy9exZxjeojb98De+SkO0uKe+dhSYebQbGfBajyHby3yM cPYW5jmn2lCTdTPwnxEbb2rlyvOuIbY72V51Rq3b+nEIvw6G2Jb3IwRpj/CDXVOJ D5U4n0by8bPX =4cfz -END PGP SIGNATURE-
Accepted reprepro 5.3.0-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 02 Feb 2019 23:20:17 +0100 Source: reprepro Binary: reprepro reprepro-dbgsym Architecture: source amd64 Version: 5.3.0-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link Changed-By: Bernhard R. Link Description: reprepro - Debian package repository producer Closes: 920377 Changes: reprepro (5.3.0-1) unstable; urgency=medium . * new release - handle .changes files without Binary field (Closes: #920377) Checksums-Sha1: 0172a19ebab062a8f6ae75cb3da18810b18c22ce 2144 reprepro_5.3.0-1.dsc 3b486c23893fedc28c0dbef013ed319624430129 681871 reprepro_5.3.0.orig.tar.gz 81e2dfc05b59900930cc9a6034958b0811bc0903 924223 reprepro_5.3.0.orig.tar.gz.asc 1c635aece1730deb4c4254d7b605b4e1d447fb67 13224 reprepro_5.3.0-1.debian.tar.xz 448a6619630434011add0c450992a65327f87f27 1203376 reprepro-dbgsym_5.3.0-1_amd64.deb 7a96fca69c5c73c663088db69b01be77ff6204ba 5992 reprepro_5.3.0-1_amd64.buildinfo 264970788ec0d4dde66eaaab6539fe725ae0633c 456848 reprepro_5.3.0-1_amd64.deb Checksums-Sha256: a9a7b461a1259007aa437987e58cc6d33e0b23dc58b26a7196849c6e24c79906 2144 reprepro_5.3.0-1.dsc 5a5404114b43a2d4ca1f8960228b1db32c41fb55de1996f62bc1b36001f3fab4 681871 reprepro_5.3.0.orig.tar.gz 56237486ce8d934f8cf6d235315d2736f0ad8e754f9558cc397d159e3ee1cee5 924223 reprepro_5.3.0.orig.tar.gz.asc 5bad3fac153e89d186d7ebd92bf09c7900186c6a1ff4dfe64ea23d8261cf5a82 13224 reprepro_5.3.0-1.debian.tar.xz a04d870a8e849de729e4c1ad889db15ff34eee0045ccefabc1306619b8eed059 1203376 reprepro-dbgsym_5.3.0-1_amd64.deb 01c9acef26987c2e5ad917bac08a232e4e8078372ab4a6a52bc761c6ecf95e64 5992 reprepro_5.3.0-1_amd64.buildinfo 84b51a1d8ab2a4c299577e2c2d55ded40b8f44aad28102dc9038f9366e133f97 456848 reprepro_5.3.0-1_amd64.deb Files: 38f6f1beb76bbd5f639dc73fb6145409 2144 utils optional reprepro_5.3.0-1.dsc adfbae84cc7d3d1d267ba20c597466a0 681871 utils optional reprepro_5.3.0.orig.tar.gz a8596568353da9fe6d621e81cbbba55a 924223 utils optional reprepro_5.3.0.orig.tar.gz.asc f89faca7712a08d329b49d8cfe2b57f9 13224 utils optional reprepro_5.3.0-1.debian.tar.xz e632870df2c9212f341432eca6c1bc02 1203376 debug optional reprepro-dbgsym_5.3.0-1_amd64.deb 2cdadb12cb3166468467c836dc1eb8d0 5992 utils optional reprepro_5.3.0-1_amd64.buildinfo 9e603afc7dae9fdcbd52336bc3f9d07f 456848 utils optional reprepro_5.3.0-1_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlxWMhISHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4Ff21sQAJfMCtP9M4ZiBkXEwH1f60wuu0/S61Rn ixdz6qg/LtMSIH93QP8JaU500KrXRBC32L5jtn/kgl/U07CP9+3kuP6sszuf8zdv O1K/JFuXQ9rmGf6bt/sX/wAdbrPRATPjhAsANLh4HffgZFLTD28ybrsw5R9kU/aH MpkXAjM3i2hj8iXXtCigEL8GlaKGY7yyt3CnK/rd2W4C2iVUaxIF0nlYiDeUdAXF nP+AaGiaqkAGTTdIvJFxZc0LldFMuRIgE/ntssxgBWc8wbkkGvoSS3XYgnBce58+ EHRfSp+lvWfuogE9egT6TcYUbP8dglIuLwk+dBPoh1NU9Tq87PEhUmYZIm9r2UL/ VPxqflQ6Cc3l1JX7NTq9B2Oo0TTJNlFe5hAove4VY8VBDX2rcUFarkoVvWVK2Idl 9C0mqBfozuvqFhjppLnfKaXn0KD1LhrARAJAqyzNYznvdgMQQp7jkl87fNXBUebR uyFRmdI4NgA8ZNnjLA1IuShWMJy1F9Xo2arvhqazAHymqbREEfcquzHVnIknWqmy qLt/h51Smt74KP3Bz0zFpOcy2WGB8B28zNqsF2S5PpspO1dFhkrQNIuBXJhUMLTz B328OMy92hBTlAgNM4nmZ5wRMd4rU39I++x3MkZS4QCNiM7tnatXkD6Z17J+87+q RfXl5FEQ9xFc =Bz7p -END PGP SIGNATURE-
Accepted ratpoison 1.4.9-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 30 Jan 2019 21:26:47 +0100 Source: ratpoison Binary: ratpoison ratpoison-dbgsym Architecture: source amd64 Version: 1.4.9-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link Changed-By: Bernhard R. Link Description: ratpoison - keyboard-only window manager Closes: 776766 Changes: ratpoison (1.4.9-1) unstable; urgency=medium . * new upstream release - switch from xinerama to xrandr (Closes: #776766) * switch to debhelper compat level 10 * use hardening=+all Checksums-Sha1: 840247130d331059889a440ba6bd28b301549692 2093 ratpoison_1.4.9-1.dsc d84f1038d312cb97817d0f42098de14f86c9b483 315584 ratpoison_1.4.9.orig.tar.xz ba5ae95dd5af732dcbc9eefc41ca48a155d6ac5d 847 ratpoison_1.4.9.orig.tar.xz.asc 554cf76891ff85dc19caa6b8e90c08f722748a05 21776 ratpoison_1.4.9-1.debian.tar.xz 5af74378ed1dbc4d772a0719a329098869bef8de 308296 ratpoison-dbgsym_1.4.9-1_amd64.deb b626b84c5b5b6a8fc0710eb6e04d5a01232bf05b 7125 ratpoison_1.4.9-1_amd64.buildinfo 31fa54ff8dc40297dae3173f9db1947d685f0065 144580 ratpoison_1.4.9-1_amd64.deb Checksums-Sha256: 37d63536771ad551d87d88dc4bd7fbf55baee9e940ecce9ce06fef30ad1ea3ec 2093 ratpoison_1.4.9-1.dsc d98fa4be025ecca453c407ff311ab3949f29f20d6d8abedf8f0716b85fc8d1f1 315584 ratpoison_1.4.9.orig.tar.xz 0970281af3d70b52a4ce35c43c735812728843ed7e998d183c4d8a10115e0832 847 ratpoison_1.4.9.orig.tar.xz.asc 9d46d209ace69e54531339397844b47d8fed3134d15f7eb7458c935ce7279a44 21776 ratpoison_1.4.9-1.debian.tar.xz 276cd13267772e532dae8eb73f5283604766dd51aa05bca1f90bb8092a3b75b1 308296 ratpoison-dbgsym_1.4.9-1_amd64.deb e699525ad8df5e3d8ca3ecd29ba18c16082d6cead2fb3fdf12675f33f6ff9cbd 7125 ratpoison_1.4.9-1_amd64.buildinfo ba6461400298d25a37704a25d8203223bf33adcb2c32daa82628233370a49c03 144580 ratpoison_1.4.9-1_amd64.deb Files: 9c4080f9b4d91a6fb20fa4baed2b1c6c 2093 x11 optional ratpoison_1.4.9-1.dsc 912b01564d24734e1a68d36e2d85faa4 315584 x11 optional ratpoison_1.4.9.orig.tar.xz 510d0e4dfcacd746c5ca123818ab4507 847 x11 optional ratpoison_1.4.9.orig.tar.xz.asc fdc7b3b239faa84ef354d1220a93ef88 21776 x11 optional ratpoison_1.4.9-1.debian.tar.xz 839dd14860391bd3bd34c223f98bdd75 308296 debug optional ratpoison-dbgsym_1.4.9-1_amd64.deb 63251fd69686195df82ed3fcd0b0eec1 7125 x11 optional ratpoison_1.4.9-1_amd64.buildinfo f6f1940c0cdb131e80fa40cb2476de51 144580 x11 optional ratpoison_1.4.9-1_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlxVUGgSHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4FfhNMP/2Pk6D1Hhn8+8kwHPwbGAJxDfYwKGptt 7BbAIp3aan3X3d/A7rB6FDDIkqpupwTNmm9V8yRzsFJLlkbXwKT7bPSEwWguW06a r1QtzyZp0DNA1XziKLKJyWglSixiUH1R8+s8Vj4wQcyGN+wnsHR3vmFLn7eLYc9L xgSIUZ0FIdI4YZwz0nJcJ5IS+kiFVe6aW/Mi1rXREazhkEYynaEOjutLjvRwZoCF DHoHYJoLDOufA//YcE8s+L+nyYQzCRjRFhJ75HdMnpsltQJOTAi4K9DfED8PBNIK vF5Or0PFWVSs/fr6c6QhCaxvftkc8AEs5eMHISJu+dlRM3H1lIeUNrImdzarZ8rG wBPl7Ka8+StKkscsJVhPL1zYfQiUeTrde36kqTz19mzlREgDQ6kvlI3Qg5toaq7P be9u4h8wBkM/5r7hYiFy0WSuP4JmgiXSNNPXGGue2o9ihqEMLqr6R+u2ofqqFyx3 ThnT02tMXZkApAo+92/KuAg4blLdqKyPxzCYDbA4dFn+Vna6mz+Cu8eUeOIx3aK1 IVREZDt7HapVhXDFqWtBBTSZ4LwIs3Uy28oR1BRNZfCtBWMwTSbHuIBYXEcc2Rjj lXq00ngtQpXTypp05AALGJkZA9sK73bzbWESAZRn/O0ECWIdg9nMGz6QQAGxesOp RhDR3KNiFq78 =jpSn -END PGP SIGNATURE-
Accepted xwit 3.4-16 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 27 Jan 2019 20:40:53 +0100 Source: xwit Binary: xwit xwit-dbgsym Architecture: source amd64 Version: 3.4-16 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link Changed-By: Bernhard R. Link Description: xwit - collection of simple routines to call some X11 functions Changes: xwit (3.4-16) unstable; urgency=medium . * update Debian packaging - remove outdated Vcs- fields - clear watch file as source no longer available - use hardening=+all Checksums-Sha1: 2c2b755a0237e3c48e7d74460e37cf99fc18119e 1674 xwit_3.4-16.dsc 810aceb7ebe77688b0a3ec2febe5fb649d0f7b2a 17840 xwit_3.4-16.debian.tar.xz 22b961aa07bf30c0661d129eacfac06f77dec4e3 34764 xwit-dbgsym_3.4-16_amd64.deb b13b91fd450311c39fe3e49638bc8cb74680cae0 6086 xwit_3.4-16_amd64.buildinfo 94ab67ed191f93ef5f2e783952338e1444831e0c 19072 xwit_3.4-16_amd64.deb Checksums-Sha256: 3bb620e58286064d093d87c43bb5a9f58d2ffa39ec3abc3cadec232523c9a1b7 1674 xwit_3.4-16.dsc 53f1e8c011c191849f8f0e46f2b55e0273e3ed6d27302423d2e235d2a0bd0891 17840 xwit_3.4-16.debian.tar.xz 11894f41195c781d25cb0bd1891682353e307a2748b0fe7a1443e8546e99cc60 34764 xwit-dbgsym_3.4-16_amd64.deb 1dda0d6231b04aa14ec7f86f3206d72aa0e3683c6cb8fa2de6bbfd97558b9806 6086 xwit_3.4-16_amd64.buildinfo 3e741f3cdf2af5e2eccf21fcda17dd710902a0e41a156b3ad931d293856251a1 19072 xwit_3.4-16_amd64.deb Files: 4bfd094b99822fd208f6f1597141195d 1674 x11 optional xwit_3.4-16.dsc 604252eb161bacb89d1b22e5f3299411 17840 x11 optional xwit_3.4-16.debian.tar.xz 58cf66fd6fc7bdc827cd5f0464b6b846 34764 debug optional xwit-dbgsym_3.4-16_amd64.deb 5db56924dfc09a9fa96441e9fd48358e 6086 x11 optional xwit_3.4-16_amd64.buildinfo 488e0be7c1d8c487f9630269631a4523 19072 x11 optional xwit_3.4-16_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlxOD7USHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4Ffd4MP/3U+9Bzkh/XwV8imG1EEmlTOCJ/WlGyQ u4e9UPqzx56d+bCx5Rmp73JiTrUtNsHW8Tmm2ODHi7tCiWcQyqOeq2UcL4RocmxG Rgn5TFtRoV7c67tfM746jtivbR4PMiPeAmrSIihSqQMdMyARVjzGS0qSiFNRFDBn 8Ma7dkpGnjXgJC5+WNoJ5v2dCph4UfCGklSIZZgjBmLHutWqbYzAKoJ2o0MriluQ w8zkEtYefg4UhZ3wvwYsmM5tG5Hw+UvFxFTkB66eacz1FH7L00//krNLYD98lFtG X+qhZRTQfuSQdnwRHhdJqrFaVtdVNKps+P7Wju7h5oAj+2u9IDdEdVRqnCpadMfg 2d+6ejHsOj3JANOzNXbT/FBMH4giXfnQKcgdcdpaAqVJ/5erIj5+z2+3j5pU59P6 4mbSVyW6co05UQWPY6Li2Gc8gipkrk9V6uhs1u1LIDRsbG+TtRQVnVOfh9zk0VUq JTGleqMBmBnGiXe+iN3ezVfhUsxfkZKvxPAIzhx9JpI//98hrYoRw7IpBmf4+XFG RXWMBsMAb3qidBNLUKp+SCg8Iyy/EmLSPVEp76vE0EmPdXj0SpV+4upG0oW7L0V3 aLsotiUZD4tZElfV+jftH8H+230+VdxWxwJZHMuUYuwzmQLOAwH9cOF/mHQf3W5h HWIpomvvGXGs =tREn -END PGP SIGNATURE-
Accepted git-dpm 0.9.2-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 27 Jan 2019 18:24:52 +0100 Source: git-dpm Binary: git-dpm Architecture: source all Version: 0.9.2-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link Changed-By: Bernhard R. Link Description: git-dpm- git Debian package manager Closes: 795694 Changes: git-dpm (0.9.2-1) unstable; urgency=medium . * new bugfix version - don't set GREP_OPTIONS (Closes: 795694) * bump Standards-Version * switch to debhelper 12 Checksums-Sha1: dc53c7a932d51b6921cee8652e5e1b5866ee14bb 1700 git-dpm_0.9.2-1.dsc aeb1899b83f69df63419cceaace68fb70cd439ea 151126 git-dpm_0.9.2.orig.tar.gz a9b754e97b3246af973d525b02e73ee503aabf30 3284 git-dpm_0.9.2-1.debian.tar.xz fe4704005ecee3d9399ca1702735fe9f91755a51 219484 git-dpm_0.9.2-1_all.deb bad42031fc501b683600a63bae29477bc55dc945 6973 git-dpm_0.9.2-1_amd64.buildinfo Checksums-Sha256: 03dd4a78e5a3b319e2460d40bca96de8b7e648477d0f40223812ae06f39d8466 1700 git-dpm_0.9.2-1.dsc 23635637f94cca788cd5546ce746b237f7b0d27cd3bac191dbfa1d54ff851846 151126 git-dpm_0.9.2.orig.tar.gz 92ab9deb28f6019ada905d63e712d66f1fb9b5c84be921fe559f22969672bd32 3284 git-dpm_0.9.2-1.debian.tar.xz 67ab37e9a847fd1358a810d68b35782b2bd34d05c2d36734541917ff55e6fcd2 219484 git-dpm_0.9.2-1_all.deb 64ba0b354fc5e5afa002a4244ebfdb7bc21ba6555c2ce43831b6ffb768e166aa 6973 git-dpm_0.9.2-1_amd64.buildinfo Files: 3b661b74e53fd1a8cb5978c56b2ec78f 1700 vcs optional git-dpm_0.9.2-1.dsc 80424e3b927c743b8a5260f3939887d4 151126 vcs optional git-dpm_0.9.2.orig.tar.gz e3bc836dd789eed6ca9c930f4a76c903 3284 vcs optional git-dpm_0.9.2-1.debian.tar.xz 4c29afc9b23ae5ed3446a16eb8e4940e 219484 vcs optional git-dpm_0.9.2-1_all.deb 72a1294476c7099563c9a40c4f5c4a9f 6973 vcs optional git-dpm_0.9.2-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlxOBh8SHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4FfeXsP/3Q5JnSBuwQU5e/d8X07YoRSWkn0Xgp9 IeXdn5KxiLIfOFHDoHm/AbjHK+AGJ0QDx++lQFHEYSBgSzwmkJzvkF/t2YRRVcZG RZ6erAN8n47P4XuSCbkv7SPiPXIJ+Glf+pVHjy5akrT3H2gDdq5vNX86oDoWlZxD YMs/pzk3tOJ6cwwpeiWs/M1dRr8V+05FWFnYkMAiMTgXbkoO456AnZkqgMTjzsvy f0H16+Bw7BkvztrH2uL96idseSIe4yfV/T64Ek8RGu/tHa75VsLFaOg/puF0MWSi l2DfvtW7pumJhwE7tjpmI2ku43KTOMP8MwS0sqsvWZPZjbpyUKFK4ga38TEwjK4e 5tW2cFFqQjDzXFWiqc1fSbun07c1aGK1BXyYROD+k4se2JPx7FBsHJxqAMFfi4w1 7+d/kTm/HSj5a3EIiSjSsa419biOYhoXGS2ksqGMZksiPHKyoKSVRRf5RmS4hECg 9TP8W4gjUZ4IW+5ot7N86eeBL1VxSy7GV7nSyt3SYu7lix7B7CZ4SGYCwO740rDL pfAGEcnCOzk25l9rjixrbeGQkoftqEg6Vff9dI642o8k8ZGXvXuXltNpbodRAd15 28vJLLwOFeC6l/a6+uiBoytngDfTIRjC6Y+JDeuA2PTOu+P3rhUl+OqUod6505hI ZX7NdeLBJxdB =no/K -END PGP SIGNATURE-
Accepted wm2 4+svn20090216-4 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 27 Jan 2019 20:08:55 +0100 Source: wm2 Binary: wm2 wm2-dbgsym Architecture: source amd64 Version: 4+svn20090216-4 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link Changed-By: Bernhard R. Link Description: wm2- small, unconfigurable window manager Changes: wm2 (4+svn20090216-4) unstable; urgency=medium . * modernize debian packaging - use dpkg includes, set hardening=+all - debhelper compatibility level up to 12 - remove outdated Vcs headers Checksums-Sha1: 01a8d4f9e951aa66b1e38a4292a187d3454fa9a4 1789 wm2_4+svn20090216-4.dsc 8945d4ef29c2dcbe6c4adb0a2fd233c86fef138a 8652 wm2_4+svn20090216-4.debian.tar.xz 848515017f1ec246f2f4a0e354a48f5a3225a980 148152 wm2-dbgsym_4+svn20090216-4_amd64.deb 463c763ec1b77aabdd967b719491bb456b58a699 6260 wm2_4+svn20090216-4_amd64.buildinfo 2c815fe81d2c914a2bd491c5d2eaf27e5b8f735d 35288 wm2_4+svn20090216-4_amd64.deb Checksums-Sha256: 324057f7d127ac944790db82e5ae6d1f36264af7dbf20d34da256304a02b0e16 1789 wm2_4+svn20090216-4.dsc 5f5ab781f8c377a241135a17999b2a93f618c3b6771ef981f272b37b19fd1ec4 8652 wm2_4+svn20090216-4.debian.tar.xz 63ddac4fc206450169b766c972d52854de4d769baab5fe6f36b65c106dc1d4c2 148152 wm2-dbgsym_4+svn20090216-4_amd64.deb c93894d8c2e06ce607202ea348a6996ae443cf37b59c221a5edbb5cbc95acb48 6260 wm2_4+svn20090216-4_amd64.buildinfo 63b37ece65ca561859ea39243f4889f1d048f5680e0c2d9811a8f0a772d4a132 35288 wm2_4+svn20090216-4_amd64.deb Files: ecce651995a13b4225a7f19b7dff8788 1789 x11 optional wm2_4+svn20090216-4.dsc 76e18ebbb49c4ba6031e50b2c1044e63 8652 x11 optional wm2_4+svn20090216-4.debian.tar.xz 5f54dcbf2afc821e141ae52e175a3c8a 148152 debug optional wm2-dbgsym_4+svn20090216-4_amd64.deb 91a909c9392036f3dc00c284889045be 6260 x11 optional wm2_4+svn20090216-4_amd64.buildinfo 9c7beba6dcd3f16a8b5b9e92c0c9071d 35288 x11 optional wm2_4+svn20090216-4_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlxOBAMSHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4FfOVMP/29zr+XhvK/YKpei76H9orb+MqwZAnib II0EVoaX/wYAJrbSAI1qpcuJd2jjAcYSmCX2AowoJyDSb/e7sJ+6HDXJLCQ0Y6MQ PJFtb2mT+eLGZVPQ+onFNzDIiEBpjGHULi9WMbU3KfDVwISNKIFWVG8Fvi24RYsf WGO6+pNlmE8Rdr5ZQPjZTZhK64JDDJoEcGb+UZ/L5HqAeQxWMWQSH5znLx6eKoY0 huhfGLmKn5ImPuo67IycLt1FtADm9OOhD3gsUOFHXkkuzEkxhpKK9NERJfLJGe72 u1OxPDtjdE50Hj/1MGDd/mCWa58Ta3hcQUvDTKPnZjo7Jt1e4oJEF3lH3Zbm29PR rmTZ9Lwun6OkqiWPlF9lCiwpbOhsK8tNmJ/9SOshHLYTZSoIcLylfY84MP0Kz3az XP2zGqS619q6NlFgOb57MPpi0ErlJgNQebHCtGTEUykLlTBr5oj8CdhSQvOiQX1m rTn+XqRuzGA3vFk/UrbsqQUHnh0OLVD/jXcPvYMx+PZuVfsd9UZ0/s279GTXTVOE 3JCpF3vKsPBAfUW6PRRt9s9XNwYQJD6h9rr1X5TsopKo8e/DjXRSVcc4OnTqSLJq /Y4LVpSozVs4npYc7y88KIrNDn4W/rZgxcexV4Rte2ySxKNhUC+pJ+tCTU9jpJLE QhAJ0t2YTe4Y =lhEN -END PGP SIGNATURE-
Accepted gv 1:3.7.4-2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 27 Jan 2019 19:09:22 +0100 Source: gv Binary: gv gv-dbgsym Architecture: source amd64 Version: 1:3.7.4-2 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link Changed-By: Bernhard R. Link Description: gv - PostScript and PDF viewer for X Changes: gv (1:3.7.4-2) unstable; urgency=medium . * bump Standards-Version * remove outdated Vcs- fields * set harding=+all, unconditionally use dpkg-buildflags * switch to debhelper 12 Checksums-Sha1: 9502d2778899254bf02ddd53853a9ba7b4aeb18a 1762 gv_3.7.4-2.dsc db1ea606cafc5e334266106a7557f919ab97862a 12772 gv_3.7.4-2.debian.tar.xz 5d14b50d5c9f54abd90d951406b3300e6584841e 587340 gv-dbgsym_3.7.4-2_amd64.deb d43b35d60dd5a15e37b700ec1f1b8b6fd176635b 6697 gv_3.7.4-2_amd64.buildinfo 7ca722ea42de03f79a118130a42f9d4ac38964e6 218788 gv_3.7.4-2_amd64.deb Checksums-Sha256: 26a8dee2350cc40da703fa893d64744dcc99eea2e90eb5ac5c6bef5299a6220a 1762 gv_3.7.4-2.dsc fd6885626775518fcdbeec90bc2cbe0103380d511f9c8d762549219454490851 12772 gv_3.7.4-2.debian.tar.xz c1d9408b9771fed9c17a1912994845e05cb6534f7a10e083cf413c2169cfa7fc 587340 gv-dbgsym_3.7.4-2_amd64.deb babb7072596d16b3cbac69a4666d062c6806b017a53add38e9617dfd8e357c3e 6697 gv_3.7.4-2_amd64.buildinfo f76680b8a168eacec025342a6ead3f2129e6a578e4b79fba063b571923cd406b 218788 gv_3.7.4-2_amd64.deb Files: 4a771c2055533e903cc49dc39842e7ba 1762 text optional gv_3.7.4-2.dsc bb0fa8c328f289f36a47978618a44641 12772 text optional gv_3.7.4-2.debian.tar.xz 467acf8011b1121286ad477a9806f58e 587340 debug optional gv-dbgsym_3.7.4-2_amd64.deb ebd327e1711a7bb3f66bd483e592927a 6697 text optional gv_3.7.4-2_amd64.buildinfo 76b787e3931caa34d6e53676a79e95ea 218788 text optional gv_3.7.4-2_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlxN9TMSHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4FfEukP/i8QqVvSuDBz/1rWuRiy8KqC/M5BhlWk iqYZjDC9tfFfHV8vwP3ZSK83/aWB9qbd+Ah/5SRykfdVWLh8l3IiP8iZbOtnW53B a3n2REtrnYBo5SZs4ndN27Pi0JgejSztPlFsmuzOeTyZnHlBUqwJ3/NuO48KsYVR olCYhRSc5ufo3qNdFNJgdukhroLkzh+yhpNgVuXvIO45W+HP9Lae6wyA6X8Omumw 73WUUJpthwGiJJNyZ4im10g+pXxnLykzOCAm9izhFTrjrb8YdrsH4niMlb1ECw1m HIWOsSssnvh0XGUXNPQJeedMJA6nbGJE0JCpZmqOhhqZJcBNKH6YGb/Iys8D2X93 goyobEouwmFcHZflc71tqvalRzAlWjlQKwnHiTCETvwPwOYwUdtPF6IvAJUVQXXA nYsCDCFDjrADEMQnt0J62byGAQYtwASx7nASUrdfGvR37NECIO2VZ29iU+HOEANE 0XzNDfNhS6YxVGgblQMQe2MBN1CMKJtkjeo7XtG+X4hKo+Ae4/KB86+NMjVUeuR4 hZDJuTq4Ywaqbf2AIDpU8gDQrXZcXBaLl696W5YaK4SDRcZMxekLMvYkNMiAv/In X665Dirq6zOkgY6FX17YGvMSUGE//K/iVTawp3vz8A76SSo5JZxUA4t8uXpCh/Nj hProKAee7/Q/ =rSBU -END PGP SIGNATURE-
Accepted inoticoming 0.2.3-2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 27 Jan 2019 17:39:34 +0100 Source: inoticoming Binary: inoticoming inoticoming-dbgsym Architecture: source amd64 Version: 0.2.3-2 Distribution: unstable Urgency: low Maintainer: Bernhard R. Link Changed-By: Bernhard R. Link Description: inoticoming - trigger actions when files hit an incoming directory Changes: inoticoming (0.2.3-2) unstable; urgency=low . * new maintenance upload - increase debhelper compatibility level to 10 - add hardening=+all - bump Standards-Version - drop outdated Vcs- fields, watch file - move frome extra to optional - drop suggests of reprepro Checksums-Sha1: 603b7e98115cc6a65867a76261c540aefbea3575 1727 inoticoming_0.2.3-2.dsc fca1e79d965a8875e74ccd78c73ca3eaa8babb67 3244 inoticoming_0.2.3-2.debian.tar.xz 2ee30d9d0a805efeb6fe15532317a4913ab52ebb 20288 inoticoming-dbgsym_0.2.3-2_amd64.deb a88a78789b47ef7607f9104d8bdb2e040e69036c 5777 inoticoming_0.2.3-2_amd64.buildinfo c0427f0d6f955a7f97341150e890cce53f708eb4 14728 inoticoming_0.2.3-2_amd64.deb Checksums-Sha256: 3849fe2382a0a49a1402219c2e0bf04efcbf9983ea753d4c0ba9e53305dae163 1727 inoticoming_0.2.3-2.dsc 28dcba9f75fa5db329d9444f523016e7d0c96a70b7318deb250c10980b9440d3 3244 inoticoming_0.2.3-2.debian.tar.xz da0ce2191f8bd333ce9400e0a49447b4b7e9bbfd55bac0725a22c572423979a2 20288 inoticoming-dbgsym_0.2.3-2_amd64.deb 1bfc33077263a32fcf6ab1f3f20a7b362dd7c1808ade0d53df90ea89d45f869b 5777 inoticoming_0.2.3-2_amd64.buildinfo b6822ee259946e9e340a4cc9f2dacccaedaa1bca204d9d76fc2bca6c9720afd8 14728 inoticoming_0.2.3-2_amd64.deb Files: eef591bcdb2467108a14156df89d49fb 1727 utils optional inoticoming_0.2.3-2.dsc c0fed024500fe7caadf08add94fcc88d 3244 utils optional inoticoming_0.2.3-2.debian.tar.xz dc7b5a214089cc304c8ae45396f04518 20288 debug optional inoticoming-dbgsym_0.2.3-2_amd64.deb 3971a0730593d618d7c588e13d597b11 5777 utils optional inoticoming_0.2.3-2_amd64.buildinfo 29b64ca46353e14d54d466336fc759c0 14728 utils optional inoticoming_0.2.3-2_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlxN4dYSHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4FfsuIQAJWBaYCJYDgy1urbRab5izxTWsoG59Jb uxIky8quYbdd6HV01RE+gneb67YfnxqFZiVNRmJPa0UL+C4dwmPq+LfiQJAnPSBr bbbQukBDoF0NkNQRFWRouX5onpFdFnaNdBFOpH/DioU/7qZxoxBPt2ldAhIsubry z5FaW+fQ8ifxkTdMDfunxgCCfkoBV4HCgAYEcugTzKJUKIagLijl4tuUAueyUPOw pOLPLxMtt/9VxXytl3S+AsohQA/rwEHyRImBg3yFRAmHrDRQEHdfwS9DRbrkrHvZ SbkiNrpEi5k/IB8yVN3wpK8rGv9CbWYKIUWF68VIwOPivPR9QxW7kiDS8q9x/u6n DKdQA2+CekmbvdYGQ2vhwVHDJyt9kzV8yXYX7VVeS5Dw268E6TB06FKjwsXv4YUW xX0ksFs+S2S2AZaG27WcAHUONmpBJRVzvD4zg7cnrOXIkCMbnxDUJ4OESq3c8ar2 zJmkNLtcgQF0/xqMpU1dHryLUJrth6gWk0MOTWglZiuOcUDUcGdIXCKGebxwrNQC AvAGMPbc8APVFIhTkdXA/TdKfkk/E4W8FHVnzmEcMVqtj59k9iVpWv3132I1PdJ0 UisrGOd955jIAKBvd9OMBz9dkHkdw7gcSk+lRnP7ziS2K5bzllFJWv35RMolFS5i nd9fIc/ZL7ki =NaUH -END PGP SIGNATURE-
Accepted reprepro 5.2.0-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 26 Aug 2018 16:47:54 +0200 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 5.2.0-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link Changed-By: Bernhard R. Link Description: reprepro - Debian package repository producer Closes: 852309 854480 856403 857303 860740 866905 881405 895045 904124 906804 Changes: reprepro (5.2.0-1) unstable; urgency=medium . * update Standards-Version * update VCS headers * remove Homepage and debian/watch (Closes: #904124, #906804) * remove debian/upstream/ directory to avoid lintian warning * new release - add support for .asc files in source packages (Closes: #854480) - add _listcodenames command (Closes: #857303) - Signed-By header can be set (Closes: #856403) - drop header from contents files (Closes: #881405) - multiple manpage fixes (Closes: #895045, #852309, #866905, #860740) Checksums-Sha1: f76b2c2007636b1388a5d977862f00d72be1ec21 1887 reprepro_5.2.0-1.dsc a1abe4d7993f5ed09933249b2f0a84ce21bf70e6 708762 reprepro_5.2.0.orig.tar.gz 6230434dc7a8ea903576218ed6045f8db364b56f 13144 reprepro_5.2.0-1.debian.tar.xz 0d986e855dd80a414ed4e0c6f656e872e7f1b5e6 1206804 reprepro-dbgsym_5.2.0-1_amd64.deb d881a651d31a0b4acc9c186d3257a4596e424fab 6412 reprepro_5.2.0-1_amd64.buildinfo 65ab7713bcffa74ddfe58e52e848082d3f0e82e6 456804 reprepro_5.2.0-1_amd64.deb Checksums-Sha256: 073a616ec4f0be4067b15cdb5de701404ff00d6448d52c4ee4b61af7df2d7cf4 1887 reprepro_5.2.0-1.dsc bd3476f2c5523e5bea112657f850224c9b18ae04d2141ce3c3b589a9038d5c75 708762 reprepro_5.2.0.orig.tar.gz 83edfee82af6bed69e1f001c55439af7a44cf0deb5500b34fd05b009aebc70ea 13144 reprepro_5.2.0-1.debian.tar.xz c3251f8e78fe18cb28c0561ea1c641fbb8f0e5ab34fb9d76f81cc0ae78d134c0 1206804 reprepro-dbgsym_5.2.0-1_amd64.deb 4946b9440d9cf112e71cdf8dc0b8ae39148c95ce1b2bb488a46ad83d3d567650 6412 reprepro_5.2.0-1_amd64.buildinfo b8f856034bae74d7c84d9f4f1d780289b9ef95ee3aceef6474f7e7c35f4807c9 456804 reprepro_5.2.0-1_amd64.deb Files: 775978284466cd03933e96e7fc603c84 1887 utils optional reprepro_5.2.0-1.dsc 8d1e55e4acc8dd1630e8da23f1fbaf44 708762 utils optional reprepro_5.2.0.orig.tar.gz 9a14eb49f8dfbbe16d61f60a7838fdce 13144 utils optional reprepro_5.2.0-1.debian.tar.xz acdf44153e74fef6e152bf3ee4df8fe9 1206804 debug optional reprepro-dbgsym_5.2.0-1_amd64.deb fd442f1fbbc2840a631c58b5ec9588f8 6412 utils optional reprepro_5.2.0-1_amd64.buildinfo d172b3e1b8df07eb614eeb5098bb4c55 456804 utils optional reprepro_5.2.0-1_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAluC1fgSHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4Ffq0EQAISwdp/pBiO/J5sF3ZIab/T7xF6+C735 piwtapnoyYBBOn+i3lRX5bXSiOSPjm4Kff5bilDr3r6WlK+TQlPgCoziRlPz4HgT AnbWEG6bz7gitrpMqnMuUJZQ+uoyyWuFpDTb/bEDnhMMxc5GuIrF0wzLc6PxlGAw vv/p1ZuKEU/J8QfLYi3fLmIFNOki53X2ZpVa9iSFlowjPUUAuogP2jWzzqyT5bBd Rqd7a5vE9eGkl2QdJkgchUE1vax1EY3ks9tZkxeg2NL4fUjyis/3jxHRiiEOaRDV udYSWxlBWnS8dplVaL0jLYRZ1ZVyseZYCrP1+2Arf13KoxrU2TRuVw840DXGj/eZ /aQo8iE9Li+Aa0w3tGpIE1bfl/+8i0ozH55XzryYnfkBHK3MDlZAUxinlVssMK8m JGwjDmBCQkv48libQ/lQRHMori+BZXOrcsVECMHHurmWtLkfXAD0Qwfh/eqhGPBt ffXruIQmNfrHTjlSpDJYOlY6gj/83nhnujZASvcfIstUHhEoZ5AI6Zf/dd7pcN/U ZHfYswBXSexlGUry8BpveQ/poO3mb2/cSI2zmUisnVbovR7qKurUHIVChSLCvRzB QwWCp9HeiO3iJ9FpwYGW0F2qR+QykgjjbFyPNc85Li/JXt9+xpKWqRKgVpO0w1W4 BIGezMsn2GCo =yBJn -END PGP SIGNATURE-
Accepted reprepro 5.1.1-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 28 Dec 2016 16:49:06 +0100 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 5.1.1-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link <brl...@debian.org> Changed-By: Bernhard R. Link <brl...@debian.org> Description: reprepro - Debian package repository producer Changes: reprepro (5.1.1-1) unstable; urgency=medium . * new bugfix release Checksums-Sha1: d7482e9fd292717e384c83f0d47d2ec236a0e059 1963 reprepro_5.1.1-1.dsc 50ab13cd66f66eb4c57ea8e6491805881d7a66a7 678525 reprepro_5.1.1.orig.tar.gz c7e43405e827b9aefa3d762e8d73a11c34d68f72 19668 reprepro_5.1.1-1.debian.tar.xz 70b6282efd4d256972675f21f093b362596a5831 180 reprepro-dbgsym_5.1.1-1_amd64.deb b3272504e2478d0abd263b04487b932220f9005a 5173 reprepro_5.1.1-1_amd64.buildinfo 452f441b08b93255c8ca3220c96fd4b954124cdd 453062 reprepro_5.1.1-1_amd64.deb Checksums-Sha256: ec02f43eda2748e768d30f9b5a24f71414a9019874c8472ccec6c76f86472e3b 1963 reprepro_5.1.1-1.dsc fbf1b632e33096845febc6dcb278c4e946272cb6692e2d6c86ca35bb5b1758fc 678525 reprepro_5.1.1.orig.tar.gz 7c178c757054335fca401358dcf8a05f15a466922e1e5cced49c7660c000686a 19668 reprepro_5.1.1-1.debian.tar.xz f851960166884791d900d7dae9020abef4b3cfafc8171567bac3fadfcc1dd758 180 reprepro-dbgsym_5.1.1-1_amd64.deb a742ebed8ab73fc8d4099aa1a68c7217bc9c62012371abee574715f9c60d6d6c 5173 reprepro_5.1.1-1_amd64.buildinfo c2743f8a90ba1608b3115e7573b4e5cad9db1e127768272190737063f2dd216f 453062 reprepro_5.1.1-1_amd64.deb Files: fe518ef507b4d218f6ab3dff47505413 1963 utils extra reprepro_5.1.1-1.dsc 554d69a426046798d650cc31a28566f1 678525 utils extra reprepro_5.1.1.orig.tar.gz 03d498cca9703bac52a5dbf3f4830de0 19668 utils extra reprepro_5.1.1-1.debian.tar.xz 706f848cab0c4f74d0f165522a76d69c 180 debug extra reprepro-dbgsym_5.1.1-1_amd64.deb 91c87fa289458674ca825739fcbc2309 5173 utils extra reprepro_5.1.1-1_amd64.buildinfo bc56d20170fc7192f67c561cd3484766 453062 utils extra reprepro_5.1.1-1_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlhj/acSHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4Ff+AAP/3o9evvpIY2ORlgD7oY9qiUedfRKZj85 rj3V1gf7kMVzAe8NjIUpKxXh3p7uEwvAaHywL5d04t6iMyeTtdWK+ZOZgPNgYyrG oEePdSyTx/HVPCSIZb9he02YOE/MUsfCAViqAXKgiNyNqnGIfB5PD3RJhXIAfJGT pbgWrmeNSiX1jF1h4O51auJEQCyDL9kI8Og+WH5UcdU/XqYbWfXzKtQYYE27pCUy aUqiGCsmGTE6J+AN/p5EY2KLl9Tsq8diucs85HKTFsEfhW28Y1QEuxkYqPpWM91+ FiWqu92dHG3wmLra9DrFDLexK85jSMSauPSG20kzQ4yo2WDK1qfFPPMzPvRgMHFJ W6DHBEanYNldCl6ExdUK0KZ8XA601vLjUOrCo58qCtlrYSwE0sSVkeU2jhBwjVOz LvwXXFGRtTzADBeTxExdhzA1p8URuTPP9zBQvaXUXAzK4T7gCfteKeuRjEOwwDU2 kKUZ316XzATNbETHuiRljOo9sLerXHa6zxV4NWrU0yXs4UfTTWAvmwIquI0KfrVz a+fpzVy22akk3Z6TkG5G2C/Pq6JURai7LFdFwq88dSPZNakN6f+d2se50SxEIWW8 vCbQj278kupcZpo/7F3aoIgr35CaBdSOez3FiszkHNg388kIbWo3JLbsyqUvCwqB DD2I21Zv5B5q =F/BD -END PGP SIGNATURE-
Accepted reprepro 5.1.0-1 (source amd64) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 22 Dec 2016 10:43:39 +0100 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 5.1.0-1 Distribution: experimental Urgency: medium Maintainer: Bernhard R. Link <brl...@debian.org> Changed-By: Bernhard R. Link <brl...@debian.org> Description: reprepro - Debian package repository producer Closes: 789608 809785 820460 820462 827749 827947 847103 Changes: reprepro (5.1.0-1) experimental; urgency=medium . * new release - change changelogs.example to be less verbose (Closes: #827947) - fix (Deb|Dsc)Indices without a Release filename (Closes: #820460) - document --ask-passphrase vs current gnupg (Closes: #789608) - document --export=silent-never (Closes: #820462) - add unferencesnapshot and _removereference commands (Closes: #827749) - builtin .gz, .bzip2, .xz uncompressors support concatenated files (Closes: #847103) * clean old bash_completions.d/reprepro conffile (Closes: #809785) Checksums-Sha1: 80eb8bc45b80b31a340ae561a76a7a1252c29aba 1963 reprepro_5.1.0-1.dsc a7fa8c46159a3c6973ce2b9437d548e37732e875 676033 reprepro_5.1.0.orig.tar.gz 2941547f7d0326d42d2bbc143a37a13f1bc61ac9 19652 reprepro_5.1.0-1.debian.tar.xz cf693f103cb6fc11bdc4fccf52ce9bdc0090d100 1000646 reprepro-dbgsym_5.1.0-1_amd64.deb 9fb80aebd3dc13d41471a7a85034716a5b22e548 5173 reprepro_5.1.0-1_amd64.buildinfo e71c5b5f5fc1b6b0bd936bca29e942ffc2707e7b 452392 reprepro_5.1.0-1_amd64.deb Checksums-Sha256: 849c79bccd904c7ef70ccaacbb4bcf4a777d03df70a24f249ae42425bdbe3c0c 1963 reprepro_5.1.0-1.dsc fb6a613062920d6283b7270b4b41a491d143ba739a8b7ffe40347f37c2f81acf 676033 reprepro_5.1.0.orig.tar.gz a0d809d85696a1f37f46911a890c370749d352fd6160180ff54250df44494340 19652 reprepro_5.1.0-1.debian.tar.xz 253e054515475fafae2efcaa6ed6c0ee8ffbe23639bfbdb6bcbc2bfa106b2e9c 1000646 reprepro-dbgsym_5.1.0-1_amd64.deb e4c57b8e9cfe99f24536192f18cd3bc21ba93ab80926a3325645b1fac2c8 5173 reprepro_5.1.0-1_amd64.buildinfo bd60ec9732aed515de1ba6cdb5e884d878f85edfc7d5fcd31c954016add157a5 452392 reprepro_5.1.0-1_amd64.deb Files: e8dc6712cbfa312aed16a1fb93262a57 1963 utils extra reprepro_5.1.0-1.dsc 9209a9b9eacc623522e802180abd6f5a 676033 utils extra reprepro_5.1.0.orig.tar.gz c978ac4b6599820ec1c7ca3d5015c11a 19652 utils extra reprepro_5.1.0-1.debian.tar.xz 938f3aef32ab3c6e7a79e2fdc21fc5a0 1000646 debug extra reprepro-dbgsym_5.1.0-1_amd64.deb 4bf141cdaca5d3b87fab55956e3c5a50 5173 utils extra reprepro_5.1.0-1_amd64.buildinfo 02f07fdb1c3bbe09367afd2342b5a06d 452392 utils extra reprepro_5.1.0-1_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlhdwikSHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4FfPEAP/2QN7KDYrFslzkv4dygomsggM0aM//Yg TAukOnnHdsg8V7wSoAuRixRfx2Bu1+DMLj3s/vagQaFKjLWs7UTfv6gKme0bHYQw MZQvUcWso6PJh1oXBzI5zNglTZJ/oBiqO7LD+ey/9748y9c+8rSxBLXpzRt2OMrg VLoxknLiYi9d8rnUg1hIjFft96rq0TAJN//QxuibezJ11oi/skFDCTV+4IX5qW2V e0VCVxsXl0q+yPjhT9EQ+AtgOIfpmJ/LO1s/tASugpNnW6FuNB9BzBPFMROUbrfQ il0gxwvaqTDh3mnadlHt1f7vH6b2/18TPi9coH4Yxf8VVgzWlJe3fZ8y1vXRNoNI 8wMQ178W6Hx7F1ZD2jA+EJ67YEK4sWp0b+7N2K6ULmt/IJ2s3K/Qc43TymMjnFrt 8EECG8zHyWjrgIJgNgqE8kY460oj02R03if4IIvzzbQUFRXRbo7tCHK3T/f7U8/F jUczNfdyWzQe4nAJsSLmRVs+9FSAUuLV+3T0wTA6ZY+CWL10DQvz2oez9Jx2ThU7 6vRABtCT6bixxlMla7ea+vhpf7Hrmbl9ycKja4wBpBHN4bnYTe90yFbA2Q7Fazcx Umvm95jINReAUBq+AJ1aTPh/oG/qxUOIiWyks3nlkIg2mg/fVxT8gMoXP3bFRwT+ i/N9YryABJHw =115a -END PGP SIGNATURE-
Accepted reprepro 5.0.0-1 (source amd64) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 21 Dec 2016 21:22:52 +0100 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 5.0.0-1 Distribution: experimental Urgency: medium Maintainer: Bernhard R. Link <brl...@debian.org> Changed-By: Bernhard R. Link <brl...@debian.org> Description: reprepro - Debian package repository producer Closes: 843402 Changes: reprepro (5.0.0-1) experimental; urgency=medium . * new release - drop support for apt-methods of squeeze and before - some code-refactoring (to prepare for future changes) - add support for .buildinfo in .changes files (Closes: #843402) * change debhelper compatibility level to 9 * remove jessie gnupg2 depencency workarounds * change build-dependency from libgpgme11-dev to libgpgme-dev * enable hardening compiler flags, drop support for ancient dpkg-dev Checksums-Sha1: 4cbb1544a5b686b65894dcb2518477cfb2f17472 1963 reprepro_5.0.0-1.dsc 33a27bae3a1acbf387c1de1e6209a51e55c74b0d 672057 reprepro_5.0.0.orig.tar.gz 6d54a01b3b92faed524195a795e4282cc814f0e2 18688 reprepro_5.0.0-1.debian.tar.xz eda840235f2dfcc7dcc0021b823eb0dbced2d77b 997170 reprepro-dbgsym_5.0.0-1_amd64.deb 049d7bef980e00c4321681c02ee7ffe844bad3cd 5170 reprepro_5.0.0-1_amd64.buildinfo 9900a8f634658634b15a0c306c355477ee1d043e 450256 reprepro_5.0.0-1_amd64.deb Checksums-Sha256: 867dda4666e549dead2189013b60b4dcc8e7484ecc99d4a6443ab8d511390d02 1963 reprepro_5.0.0-1.dsc da7c0dbdd80afb1b49ea6740448bec1a7e7ab10e05520c33a9b11f5b8ca49f0b 672057 reprepro_5.0.0.orig.tar.gz 9c987e71583242c15de3067fd669897b39e5e20832cb6b349c06ee6fd3b8af90 18688 reprepro_5.0.0-1.debian.tar.xz dfa62606508970123e705f08f8a73e717d912578284320f10a8c7bbe0827 997170 reprepro-dbgsym_5.0.0-1_amd64.deb 6bf03ae96e55d24411c559ff8d5a322694774fea50b51e9b3db212d8bb1e3fb6 5170 reprepro_5.0.0-1_amd64.buildinfo 2b2b17498ff32ebb48ec10b9c21d09e505c3c7f99f3d343e0233cfccd8396296 450256 reprepro_5.0.0-1_amd64.deb Files: 18285327421dc384cb540f25f36fcd5b 1963 utils extra reprepro_5.0.0-1.dsc 7d13c1af92e95aeeb6330112af662cf9 672057 utils extra reprepro_5.0.0.orig.tar.gz b21dade6e8c4354a128f75d7f0d37f4b 18688 utils extra reprepro_5.0.0-1.debian.tar.xz 063145457cda9a0940dd49ab140ce113 997170 debug extra reprepro-dbgsym_5.0.0-1_amd64.deb ec9d3fe058662fd95630b766da01e2f0 5170 utils extra reprepro_5.0.0-1_amd64.buildinfo d4651302bdfc2f4f431c14adec8e8634 450256 utils extra reprepro_5.0.0-1_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlhbB+0SHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4Ffej4P/iBgwH92AgpbHscBk9PSuQsoJG6xBy2a OzW/iYgCbl4TwL9qm9O0gDDlZOoNMC2CMqRL4kaFKK9Sq9I8yUBIuvoaGJwQvCC2 6ULB80A6vaK1NRpVqO1z7X+Mj2vMG25qDNdD2xImj7fsz6GXsMEcYQbS18wTz5Br 0oT4Q9cpiLmhYggHWNIaYddXTxh04qOhws04JfTJ3oXHz6Bwe5yVE2zPbMNHb4Dn x8xhCyap6YAOZhfGfyntAX1E0tt4nrqD25bD53LzAUcDjiOkK1lGFXCIkBb/I6B+ qoXKZc2kBhaHCUU8TS+EQbLe/91V5O4u2fpN80Gq3gZcdn2ucJ6ikVTUGfzXl8vo c+EDzMmyELcxqnDvzlVqflL87QMc5Fihiy4Q2n7aUdiceq2OffedxCopioGUW+HT BpYbfoLFXxpD/oh9L638SK+ckSuP/AEUD1G1S2zGuR0EGAF9/1Wd13kIHlA0kqvh 1rr9VsgDNVLSVTufkvIbUzr0+7kTznC7xy+OvdJUpAMyXOukwuqnchr4XxirOrCs xNFN6nco6y+Smii0P+3nODQq6p0H6lw4GBzODN1729OLvjMT6/kQHrtqjz0ajzQ8 1Rqz5l6EKcbb71H4rtnVPf4xLqfTFsJPyJxJL+IYKo42x0gmGiZnp8zwhJCXhyBo UV4pOlzS6uH5 =7MEj -END PGP SIGNATURE-
Accepted libnss-extrausers 0.6-4 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 05 Sep 2016 16:08:15 +0200 Source: libnss-extrausers Binary: libnss-extrausers Architecture: source amd64 Version: 0.6-4 Distribution: unstable Urgency: medium Maintainer: Debian QA Group <packa...@qa.debian.org> Changed-By: Bernhard R. Link <brl...@debian.org> Description: libnss-extrausers - nss module to have an additional passwd, shadow and group file Changes: libnss-extrausers (0.6-4) unstable; urgency=medium . * orphan package * apply some patches from Philipp Hahn * move git repository to collab-maint * replace ldconfig call with a trigger * switch debian/compat to 9 Checksums-Sha1: 18f40784306c8b034b01f62a6b6472926465e324 2027 libnss-extrausers_0.6-4.dsc 959cb37559d85600fa561f344579d7847138690e 6468 libnss-extrausers_0.6-4.debian.tar.xz d63bc09b3582b199b7b4bb94bbb53ec7329cad31 26540 libnss-extrausers-dbgsym_0.6-4_amd64.deb 3ecfc22ee2f5cd1e6b285297fb2bde8f02707fb0 5391 libnss-extrausers_0.6-4_amd64.buildinfo e724911c286e49743aed96c30338b53d0eaf4753 15910 libnss-extrausers_0.6-4_amd64.deb Checksums-Sha256: 45061d3f70f16cdeae74a69514b395524603a5a6c628a095fb52ec2e8dd9709f 2027 libnss-extrausers_0.6-4.dsc 851aeea268c0212702b78b66f8f16be15c0eddc241c5bc2df41b0825f3a65a5b 6468 libnss-extrausers_0.6-4.debian.tar.xz 1ceb4cb16ab7645e4cea70d052fd37660a149def9d3113f890df99d1a9f73761 26540 libnss-extrausers-dbgsym_0.6-4_amd64.deb e5521c6ecb2da9ed6dc3e04dd05efecf589e23afcc8b1a5435653d079aa820fc 5391 libnss-extrausers_0.6-4_amd64.buildinfo c92bdbda3d445e5592fb8b92caeac3c2b09236708d7cab4126e9bcd820ded970 15910 libnss-extrausers_0.6-4_amd64.deb Files: 31fdfe7d3ae55ee0f8bcc29cecf23994 2027 admin extra libnss-extrausers_0.6-4.dsc 8f99adeff9aba3493360cc06e3feb538 6468 admin extra libnss-extrausers_0.6-4.debian.tar.xz 841d4c1189599a0ba6ef253d04c8265f 26540 debug extra libnss-extrausers-dbgsym_0.6-4_amd64.deb c02d72522aa8a1300613bf9c32d0021f 5391 admin extra libnss-extrausers_0.6-4_amd64.buildinfo dc6e30cf9520bf9dbb0083ffacce9703 15910 admin extra libnss-extrausers_0.6-4_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlhaVQ8SHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4Ff5x0P/1pqdurnt4rsBxPwU4eE+UCfdPmlz5xM WhgfXmbZ5iotic8GtK5eCOxGhPvci+dSRGBIYgpFYRpq/3tq9Ke9opWL2AtLyXn4 EhwVMOrlqR+0rhzZ7qvaYuh8MEwrxWXnQ6IFAOvMeFLG0bpQNQOJJkSjZdAJckx0 OUZkOi7MrxWPQ/L7FnXGU/pbvHrv6yOi0UHwRdkVPcIggsqOxEObz0l5bn7P18aw ThajZEljiq2u6Jky62v7s6cJnKc+S0sIQkHyrCqoVS0WsK57LD3lee9DoDHDPX0g 1cmaioVEuMJwI+0fAZ17psbbX5VkaY0M5w7hr3SMdoupIClRGqUA9TUNfZqkk1NC bE+MrUSq801aBgC9O1fRYvdn3ZYqJseo1FCtiFjM0szstlmob6okfQG6Axk9vxTH LUaf+GsSJKFU/lI/Bh3ctBDWkixilFnmlB3DHe7vcd+sf4xUslTQkY7+eagMJOGH JQmX8f2NDmIB96F8E3Jdp95V+k07DEEFAk3JmYgMYezukDnn5MENN6CTlDwjPcGk IQg2a7J+uhaoJclK1CW6knih6nmar+koX0o7l31ndvxUDXusjgKbxKUv6ptN4Mt6 kXLMf0gmjtmr7yTr3PM+nw9Cxf2+c0TKj34gL2UmipfQsnUlYhNYJwVz+ZO2oFnW PnPfkTSpQvHv =GtHi -END PGP SIGNATURE-
Accepted reprepro 4.17.1-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 30 Apr 2016 15:18:57 +0200 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 4.17.1-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link <brl...@debian.org> Changed-By: Bernhard R. Link <brl...@debian.org> Description: reprepro - Debian package repository producer Changes: reprepro (4.17.1-1) unstable; urgency=medium . * new bugfix release - fix bug in 'flood' command and output of 'warning' in FilterList - fix some spelling mistakes Checksums-Sha1: ab032bedd9b076600b6c19fe17b88ea14b70a873 1950 reprepro_4.17.1-1.dsc 7315d4a680baeb43c8b5fd3c27bb7499d429eb4c 671842 reprepro_4.17.1.orig.tar.gz 6a0e342bffb73e43a32c66b3033eadb54a523618 18620 reprepro_4.17.1-1.debian.tar.xz aad1ab7a4941f3f1c8d981b41419bfbcc35ac30c 978160 reprepro-dbgsym_4.17.1-1_amd64.deb 838529848ff21a8c14ba1ffd5feca93321e351b7 439196 reprepro_4.17.1-1_amd64.deb Checksums-Sha256: c1022a717e0face6eb0a7d8a8a985cdb329a15eb1b039c9ca356ef3db7369302 1950 reprepro_4.17.1-1.dsc 1f6668d2dba652a71a7d9fddb39dcf949336513b0aaa4c71c14081e833cc2d5c 671842 reprepro_4.17.1.orig.tar.gz f8f6f3be9a55356ccb8c7843c2723875ea548e401db8d7ccd91f85fb194e3d7d 18620 reprepro_4.17.1-1.debian.tar.xz f6d78f59be979a3a35303de175624d5c14f5082f39c56e723241ec6aabb3f00c 978160 reprepro-dbgsym_4.17.1-1_amd64.deb 7bbb838b077ae49071de4321f4eeeb24b91824386f1f68f5738c0dee7d3fb351 439196 reprepro_4.17.1-1_amd64.deb Files: 41d15eecc0d7e55b8bdb5bf4375a5067 1950 utils extra reprepro_4.17.1-1.dsc 7fd36b82df33e80eba50865672b09962 671842 utils extra reprepro_4.17.1.orig.tar.gz 8ccf269b5f8c4f1b1b1a0e5e4ca30d60 18620 utils extra reprepro_4.17.1-1.debian.tar.xz 00b01baf6366825e914277a0cae635e1 978160 debug extra reprepro-dbgsym_4.17.1-1_amd64.deb 54f79953df1c4d063496ab3efc39ac29 439196 utils extra reprepro_4.17.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJXLxLVAAoJEOxkTtbr1QJDxw8P/2Ld98YKyeZWkRJbcmSgnQnX aODXtiIKcxNTOfeKYzcOvMctiOlzf56oDJ/T4N788gJh/OAcK1EIWSgOO/JtB+0C at0XMQC9HkMRAM0hUIZC5nZzrwUCh96Mt9ncrcbjA4Y0NNoSwsfy9CUhI0gcOOkB VCEr/K64w0TtRVVsX7qfI+yK0SPYWeH9ygl6YHPxualmqcUH1zQNNlNYGMN8+5Oy ctwNlSy9rITaTkEp8WnU8EifqJ/R74oZ2lmKWdIlbdft2WMvYzJ8XsMTamtU1/Ha S28kO99MyYCk8ip9+IgoYiDCFMPSgpMVT2SE4XsXlyOwRZ1T5l0i6chkKieuf95C vb+xpaRuOY1vAd4b8YU66dr0O0/w7dfQ9xeDmZztmZn01jOXd4cEJxBOyXeYaiVL zuR1Ete6OAJKXuSc9h8UWiCtvWs/728K1qSDY7f2pTxJybi8+d6gXKJVWyFXL4KT iXSDWTgBk93ES30quzDsCsLHPNlv6aQoqC+p3lR5w7uprkPU7W8mYP/94Ui5Pbyj KpQUqVotWrpVIr26QE7tJTTCGloHr7VHlwDf4gLaEWuDN/kVKpAVJCASfg0ax9S5 HEpPdbDr5yRg/yW49DFtr8V1cXVRijk9hJd+36WtyTS232b6+oEKLjhBVFHRgLUw Ram8Rqrr7zlLzXx5kq79 =MhR2 -END PGP SIGNATURE-
Accepted bls-standalone 0.20151231 (source amd64) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 09 Nov 2014 13:35:21 +0100 Source: bls-standalone Binary: bls-standalone Architecture: source amd64 Version: 0.20151231 Distribution: unstable Urgency: low Maintainer: Bernhard R. Link <brl...@debian.org> Changed-By: Bernhard R. Link <brl...@debian.org> Description: bls-standalone - standalone build log scanner Changes: bls-standalone (0.20151231) unstable; urgency=low . * Initial release. Checksums-Sha1: 2b7af2b91dc93bac4c860aabba17f4f060102675 1435 bls-standalone_0.20151231.dsc f4cbe5b09045d4f63d77a997d40fa0f255c8e81a 26632 bls-standalone_0.20151231.tar.xz 2736c3e4ac9dcaaf2f799fb0db775ad2589bcdec 41848 bls-standalone-dbgsym_0.20151231_amd64.deb e69c6360e4884464208af0998e1fe2abd56c25ff 37210 bls-standalone_0.20151231_amd64.deb Checksums-Sha256: 5d1d08cb3eebf0ab5e3939d17075034b25a02f2bc5f1dcb6c264d61cd2a7acd6 1435 bls-standalone_0.20151231.dsc 193a09c8e1d9e9e7b4ac8260a6597ffbc053e8456fcb332e8babeba50df25031 26632 bls-standalone_0.20151231.tar.xz 3c32a382d0d1ebdec229a9010c8561c0cbe82b8c7af4b0ae64aaeb46d3c85a52 41848 bls-standalone-dbgsym_0.20151231_amd64.deb 28f96bbdc9ddfbdb6d59a7486f75239189b1963356c8b77fd2d040af0b577445 37210 bls-standalone_0.20151231_amd64.deb Files: 240cb5e5b051bdc4508a6b7a02dfdad0 1435 devel extra bls-standalone_0.20151231.dsc de98acab8a965f81e9f387bd6acf7e1e 26632 devel extra bls-standalone_0.20151231.tar.xz 98aa26054d58e3d93ddb24c09a4e331f 41848 debug extra bls-standalone-dbgsym_0.20151231_amd64.deb 2bd13dcca038e650e742b72a736f41f9 37210 devel extra bls-standalone_0.20151231_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWhYCyAAoJEOxkTtbr1QJDmnIP/Rpzbsegx/y5xqSQytQHRhwD DX/S4tHUlp3Va1ITpt8DWe3D/bZ+FX+j2X2v5LYpukF8DmO+6G21R66CeHsl1F1J fu70A+UfGiLTq+Ie21K+oGgnfwuERTPoVQqBvbxOXoi4bEIxenIXr4hiTflrU6N3 Z1ASE+jQcaasUz09GnhCF/OQS/fgxbO/XKdJ9XeLG1M9UXz//cAfbPRlzZEIiZI9 Tw/Toa8qNEw9Df+wsqN8Fj+ERcAwyo++vy2deD1ZcQUax63Og9ZjPB8Aqx5+4nhH HFATGx/doq9DNNcLtHfxSeNF4GJpRRQQBc3Z3qZZ+YBnupcuNbR5Y/6if6sUmukq 9a40rmlQLwHMEJrF2bUWpYl8VKvrlV25Fq8lz2mBAgkCYlK9dJrdRn+GbifQhmkX 5t5ZhDedrdQqgl80atpkTnEhoBgOSovWXdVe+v0nR+wBuhkBxcu/6sYsm0upog81 R7ssn7X4/e9ieK+wKZ7KS9M/LfLvA1mKUqaHpls4nUXdC8AlFLk4d1ZJdU+452mm CQHrp6/R19XLBQDo4m2LQeNWxch/ZWR80449h6cur7wWjwCu4EwawsnYSbVBSVWW KEPQQHJREFraz6WBlYUqlXyf9auS6xmAkrzrheiyNBOqpczcHRa3NpgHlBAsLoH+ sEKpJynHtnNH+2tLgk9P =5x4M -END PGP SIGNATURE-
Accepted ratpoison 1.4.8-2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 30 Dec 2015 15:19:17 +0100 Source: ratpoison Binary: ratpoison Architecture: source amd64 Version: 1.4.8-2 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link <brl...@debian.org> Changed-By: Bernhard R. Link <brl...@debian.org> Description: ratpoison - keyboard-only window manager Changes: ratpoison (1.4.8-2) unstable; urgency=medium . * install ratpoison.py and ratpoison.rb bindings in the proper paths so they are found again. * switch to debhelper compat level 9 Checksums-Sha1: 6e7051f90dbf4658e67dd3595c6491c3afb55e0d 1993 ratpoison_1.4.8-2.dsc d30ab4ae829ffbd1fc9abae636650f337052132d 19268 ratpoison_1.4.8-2.debian.tar.xz db70f3d8819054b77c2d25b0c494d2689a9fb5b1 212600 ratpoison-dbgsym_1.4.8-2_amd64.deb 3234228d4721ac4cd636db7df8a9d063c7e69a1a 215430 ratpoison_1.4.8-2_amd64.deb Checksums-Sha256: 1b577eb7ca88e94f5b17a29e442eb0af1edff3dbac4e01852bfafbcce6cfa110 1993 ratpoison_1.4.8-2.dsc 507287abff2fe8eb112259d0a685943913903f3b19f7f36687df61b1cfdd8977 19268 ratpoison_1.4.8-2.debian.tar.xz 62bc17460b60d21d96d2608dab1bbf6abd25f736090fea97954a7262f73fe81a 212600 ratpoison-dbgsym_1.4.8-2_amd64.deb 50fcc7a8ec7b874caa1882fd458cb51c8ea5ab3c1f1cdba4322e3281b4ae0b5d 215430 ratpoison_1.4.8-2_amd64.deb Files: f20314b5819528b3786f63f421268ac1 1993 x11 extra ratpoison_1.4.8-2.dsc 010390981c75d1b4eb10cc206a68d0f3 19268 x11 extra ratpoison_1.4.8-2.debian.tar.xz a9c3e8c85fed917f1c48dd79b5a399c2 212600 debug extra ratpoison-dbgsym_1.4.8-2_amd64.deb 85c0979d04cf8d7bffcf736c92437220 215430 x11 extra ratpoison_1.4.8-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWg++cAAoJEOxkTtbr1QJD36QP/37x5LgOA/6glq20V0pNwvvS 1laezwV4Sm38mtnPRIW4DRPs7Uw87A+ZvgoB30dOcxZqwqku83hPLWEiO4HkrU1z O1xLjjW7LvKGL9PKyKc5TqZlZUykvzbQ1D1U0lhcbFEp3Ats+tTsPG4BH/1AfNGz mP5cFeHSleZ8051heg72l9BnaNIgid6IudQMrBQrk7gTqSxfpIFdIT+KE5A/99Qm 4oHDC0cTT1Plo+y9pP4mn0LVskp5fwbjYHvtRA+WcROry7WpByl6h/0loAt5pkQo f62ucKWdl9ADRAMbGz1+R4vduMpnkspEd+7/JdWLkS858LKGSusk2MrSOtUFLK6y 2rITiW0Nue9D59LhRfZyrNAT03fWTtNfgl1hUSzFq+sF+g3gUvnfN1BH5wkJSMdj QTaSXwcMNETP+x+4PJmMDj8elp1ThPx92gNecbmJohft/73kQXnlk/QCDIMcbAEV eiCkZdlhSqqIdd1If5ID7CtQmrNjGGRyE9yUSHIMhnQ5Vqow4izbY2iVdiSx/NI5 vbKIrLPX/KdZii2JJnILNI4ZltSsgD44GQ4ylBqpcvPRZ46d6dZqAJbgeA0jFC0G lUyCGA0DaR6zXNtCc0MD4b7b6CneUPEAIUdmHCx1b27ZC+wuL62+CvStdji69HDM kcN52ncAcYqL3XI6Rvqx =8oy4 -END PGP SIGNATURE-
Accepted reprepro 4.17.0-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 28 Dec 2015 13:20:02 +0100 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 4.17.0-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link <brl...@debian.org> Changed-By: Bernhard R. Link <brl...@debian.org> Description: reprepro - Debian package repository producer Closes: 781258 783129 784024 788351 803481 808558 Changes: reprepro (4.17.0-1) unstable; urgency=medium . * new release - some manpage fixes (Closes: #784024, #803481) - add support for -dbgsym packages (Closes: #808558) - allow comments in filterlists (Closes: #781258) - fix parsing of strangly formated control files (Closes: #783129) - add Exportoptions: noexport option in conf/distributions (Closes: #788351) Checksums-Sha1: 2bfdb3901f89f4304274ae1b926c6a48f033ffd7 1944 reprepro_4.17.0-1.dsc 8dd28c836506c9ca0788abef86eedacb3d6e2fdd 671771 reprepro_4.17.0.orig.tar.gz 052a7d2d46b48909eca1a23e37c2ee18a8b863e9 18568 reprepro_4.17.0-1.debian.tar.xz e1a0813ae8d83c8ad2137310a7e5cf05ca8ec7fd 978116 reprepro-dbgsym_4.17.0-1_amd64.deb d66c4fb1e146369ce59ae63725553701435f4d4a 439146 reprepro_4.17.0-1_amd64.deb Checksums-Sha256: a6d18f31049083f1653c229a6b244c585c42a23b1250380caab59935faee6b81 1944 reprepro_4.17.0-1.dsc 97ef4dc26f6f81981a591d620adadb233074a36d7e042d56711eb4e885ce68fa 671771 reprepro_4.17.0.orig.tar.gz 8adc22f470c1ef19879928c1dbd570e147d36bbf4790430406ac0241cb3f6727 18568 reprepro_4.17.0-1.debian.tar.xz fadc9d24dc919befec9bbac22591da9f2739aa18fa985dea5038d8e8a0ad128e 978116 reprepro-dbgsym_4.17.0-1_amd64.deb 99fcabc7af8a2651ef294e980eabe1be7daa3b622e49638b3335314e065e5c01 439146 reprepro_4.17.0-1_amd64.deb Files: 6129d56157ba4cd7751df3fa452076be 1944 utils extra reprepro_4.17.0-1.dsc 4579e699f10e8bf27539d5fe3f12b82b 671771 utils extra reprepro_4.17.0.orig.tar.gz 7a7223940687b238cbdbeb7bd9ecbe38 18568 utils extra reprepro_4.17.0-1.debian.tar.xz b5cca5f2629be0b57637babbc39bb450 978116 debug extra reprepro-dbgsym_4.17.0-1_amd64.deb f46391f74a80d23e7474463bd6f66b26 439146 utils extra reprepro_4.17.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWgXl7AAoJEOxkTtbr1QJDq/kQAIKGwJkaxYtc1EaScUQNWC/k /Cm+fuT27Xg2irfaRimxJiAzTIzuxxClK3OS5XDwFJKdl0fMQAtBxufNGcU+hVrM Jo3+1lRQk2R7w9twHuL0xFon603u81rXA3MTSV/myUokysJewR+800dFdFZkIoAz 8+wCgUlQlzCTvTBlfZ5GhKI6b769J5d9sUTMZpJSKLQ75QPcLAvhv4sUEScjMFcy 2+4P6g7u5J7d7O6GX/Dv7VkJqKdTDZUDxjGTIrodFjKy95ZX8+Ey6wT2rg2kzOxP UBYTNLgTiLwBv/+v8eKOPtqSzGgHwcJV3D3aNg4IN+7lZP6bdm+uAbJC4y7gCkFq RFwUwtkzpc7gJPT/tYqmvVVNWUmrlsnplAo4P+hroPlwOaf2yRWIRo11YNpegK+x TDDBldIau96+op1NSet1FAhw8v2OFohSNdLrQyLP8XcZt5/neQgAY7mwzTkl6ifv rxCpCUW3SbT7qiMzbciccK07uZImMeWA70MEfTroO/FpKclB7SzD+4EEPei3eBc8 bguDqivOGxUsbrkLT1zLBgx1ZxD6N24b9+Hig1S8qdQX3fId1BXHEZnCE9gPWfQS /5r/kdamrxd85vtBDKeOb8wBVKzDvDWLMZWf2/iR92xybRCdefPGpIKPZsQhvZ8L Eao06Fy74vaEmdxzfAYp =Eqil -END PGP SIGNATURE-
Re: Should .a library contains non-reallocatable code?
* Ian Jackson ijack...@chiark.greenend.org.uk [150227 16:39]:
Bernhard R. Link writes (Re: Should .a library contains non-reallocatable
code?):
Compare that to the straightforward case of just building a dynamic
instead of a static library with some simple:
No-one is proposing that shared libraries should not be built, and
used, when possible. We are only discussing here the case where
building a shared library is not feasible for some reason.
The most common reason is that the shared library has no stable ABI:
that is, upstream make API changes willy-nilly. In that case ...
printf 'LIBFOO_0.'$REVISION' {\n global:\n *\n};\n' foo.map
gcc --shared -Wl,--version-script=foo.map -Wl,--soname
libfoo.so.0.${REVSION} -o libfoo.so.0.${REVSION} ...
ln -s libfoo.so.0.${REVSION} libfoo.so
... this approach will lead to ABI-change-related breakage.
How do you think this can lead to breakage that your suggestion to merge
the static library into the dynamic library using it can not?
Where only a static library is provided, it should be built _with_
-fPIC unless it is expected never to be included in any shared object
(which is probably hard to predict, but I guess there might be cases
where the maintainer might know).
If you change that to unless it is expected to never be
included in any shared object correctly. you get the current policy.
Because I can hardly think of a shared library for which that is not
expected.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
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/20150227183331.ga2...@client.brlink.eu
Re: Should .a library contains non-reallocatable code?
* Ian Jackson ijack...@chiark.greenend.org.uk [150224 18:51]:
Right. I think that the right answer to this, in these cases, is
either to use an explicit symbol export file or to adjust the link
command lines.
adjust the link command lines ? That's like saying the mine field
is safe because people will know which way through it is safe (at least
the second time they pass).
Creating multiple copies by creating shared libraries that merge
the static library in so that might end up multiple times in the same
library, and in a way they leak those implementation and might override
even things in programs linking against that library is at best a gross
hack, at worst a disaster waiting to happen.
explicit symbol export file
While this might be possibly avoid problems, it is quite a hard thing to
do. As there needs to be the default to hide everything (unless you
assume a library author incapabable of managing a ABI on the one hand
but able to properly make all symbols match some easy pattern) you
need an explicit whitelist one what you export from the merged library.
And in both cases you still have the problem that you have object code
copies in other packages, including all the problems like the need to
keep multiple source versions around, security updates being quite a
hassle, needing more memory if that code ends up in multiple libraries
and so on. (Not to speak of all the other problems of static libraries,
like breaking the versioning of symbols used from other libraries and
stuff like that).
Compare that to the straightforward case of just building a dynamic
instead of a static library with some simple:
printf 'LIBFOO_0.'$REVISION' {\n global:\n *\n};\n' foo.map
gcc --shared -Wl,--version-script=foo.map -Wl,--soname libfoo.so.0.${REVSION}
-o libfoo.so.0.${REVSION} ...
ln -s libfoo.so.0.${REVSION} libfoo.so
which also gives you all the advantages of not having needlessly
multiple copies of the same version of the compile code around
and get all the other goodies (like automatic tracking where it is
used and which what version and being able to do a security update
without recompiling anything but that library).
So I really do not see what advantage in that case PIC code in the .a
file has, while not having it there avoids many possible mistakes.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
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/20150226230057.ga3...@client.brlink.eu
Re: Should .a library contains non-reallocatable code?
* Ian Jackson ijack...@chiark.greenend.org.uk [150224 15:50]:
You still pollute the ABI with the details of the internals:
if you try to change main.c to:
#include stdio.h
#include foo1.h
#include bar2.h
int main() {
double rr1;
foo(rr1);
int r1 = rr1;
int r2 = bar2();
printf(%d %d\n, r1, r2);
return 0;
}
and run gcc -Wall main.c -L. -lbar2 -lfoo1 ; LD_LIBRARY_PATH=. ./a.out
you get:
foo2: 0x7f42db6f0a48
foo2: 0x7f42db6f0a48
0 17
(In this specific case a version script might helps, but I'd not bet
on helping in all cases).
I don't know what exactly you ran. Your transcript is not complete
and I don't get the same results. I suspect you didn't pass
-Bsymbolic everywhere.
I changed main.c to contain the code you just showed, and reran by
./build script (same as before), and got this:
[...]
(64)ian@zealot:~$ ./build
+ egrep . bar.c bar1.c bar1.h bar2.c bar2.h foo.c foo1.c foo1.h foo2.c foo2.h
main.c t.c build
[...]
main.c:#include stdio.h
main.c:#include foo1.h
main.c:#include bar2.h
main.c:int main() {
main.c: double rr1;
main.c: foo(rr1);
main.c: int r1 = rr1;
main.c: int r2 = bar2();
main.c: printf(%d %d\n, r1, r2);
main.c: return 0;
main.c:}
[...]
+ gcc -Wall main.c -L. -lbar1 -lbar2
You forgot to change that line as I said to change it.
main.c now uses libfoo1 and libbar2, so in my example I build against
those. Now you only need a bit of bad luck to use -lbar2 -lfoo1 in
that order and you get the problem. -Bsymbolic only helps against bar
being poluted. It does not help against libbar polluting the main
program. (For this you need at least something like symbol versioning
to hide the symbols).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
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/20150224173825.ga1...@client.brlink.eu
Re: Should .a library contains non-reallocatable code?
* Ian Jackson ijack...@chiark.greenend.org.uk [150223 20:09]:
Bernhard R. Link writes (Re: Should .a library contains non-reallocatable
code?):
Jeff Epler jep...@unpythonic.net [150220 00:19]:
* libbar has a stable API, so it should be shipped as a .so,
but if it links libfoo.a, and libfoo.a is not -fPIC, then
libbar has to be shipped as a a static library too
Jeff is correct.
This is wrong. If libbar.so needs libfoo.a then libfoo.a does not
need to be PIC:
echo 'int foo(void) {return 17;}' foo.c
echo 'int bar(void) {return foo();}' bar.c
echo 'int main() {return bar();}' main.c
gcc -c -Wall foo.c
ar rs libfoo.a foo.o
gcc -shared -fPIC -Wall bar.c -o bar.so
gcc -Wall main.c -L. -lbar -lfoo
./a.out
echo $?
works just fine.
Did you actually try this before posting ?
Oh, I copied the wrong lines from the backlog here. It seems they
were a bit to trivial so autocorrection made me miss them reading over
them.
Furthermore, as Simon Richter points out, this happens to work only
because 1. your foo.c happens not to contain any data references, and
Data references work fine, too:
echo 'extern int val; void foo(int s) {val=s;}'
echo 'int val = 2; void foo(int s) {val=s;}' foo.c
echo 'extern int val;int bar(void) {return val;}'
gcc -c -Wall foo.c
ar rs libfoo.a foo.o
gcc -shared -fPIC -Wall bar.c -o libbar.so
echo 'int main() {foo(17);return bar();}' main.c
gcc -Wall main.c -L. -lbar -lfoo
LD_LIBRARY_PATH=. ./a.out
echo $?
2. your construction of bar.so (should be libbar.so) produces a shared
library with unresolved references to libfoo, which is not usual or
desirable.
Using a static library is undesirable. Unresolved symbols is just the
way dependencies of libraries works. The only thing missing here is
the missing dependency on the static library. But that is simply not
possible with static libraries.
(In particular, this would vitiate libbar's stable
API/ABI.)
This you have to explain.
If you think there is another way a dynamic library can use a static
library please tell so.
(64)ian@zealot:~$ echo 'int x=17; int foo(void){ return x; }' foo.c
(64)ian@zealot:~$ echo 'int bar(void) {return foo();}' bar.c
(64)ian@zealot:~$ echo 'int main() {return bar();}' main.c
(64)ian@zealot:~$ gcc -c -Wall foo.c
(64)ian@zealot:~$ ar rs libfoo.a foo.o
(64)ian@zealot:~$ gcc -shared -fPIC -Wall bar.c -L. -lfoo -o libbar.so
bar.c: In function ?bar?:
bar.c:1:1: warning: implicit declaration of function ?foo?
[-Wimplicit-function-declaration]
/usr/bin/ld: ./libfoo.a(foo.o): relocation R_X86_64_PC32 against
symbol `x' can not be used when making a shared object; recompile with
-fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
What you do here is creating a dynamic library that merges the contents
of foo and bar. This is totally broken. If anything else uses the same
static library you get multiple symbols. If there versions differ that
means harvoc. With data parts you may end up with multiple versions.
There are only two possibilities:
You want a static library, then the static library has to be linked into
the executeable directly.
You foo within a dynamic library. Then instead of creating a dynamic
library that includes foo you can just as well create dynamic libfoo.so
and link against that.
* foomodule is a Python wrapper for libfoo, so it must be shipped
as a .so, but if it links libfoo.a, and libfoo.a is not -fPIC,
it is not possible to build foomodule at all
That is indeed the case. Note that simply compiling it with -fPIC might
not be enough here. As you need to include the actual library in the
module, this might mean you might end up with multiple copies of the
library, which might also mean multiple copies of any data it has or
with different versions of the same library in the same executeable
(and you cannot really have symbol versioning with a static library).
That not usually a problem. Providing that only the relevant symbols
are exported from the .so, the executable simply results in multiple
completely independent copies of the static library.
Your example above misses that.
echo int foo(void) {return 7;} foo1.c
echo int foo(void) {return 13;} foo2.c
echo 'int bar(void) {return foo();}' bar.c
echo 'int main() {return bar();}' main.c
gcc -c foo1.c
gcc -c foo2.c
gcc -fPIC -c foo1.c
rm libfoo.a
ar rs libfoo.a foo1.o
gcc -shared -o libbar.so -fPIC bar.c -L. -lfoo
gcc foo2.c main.c -L. -lbar
LD_LIBRARY_PATH=. ./a.out
echo $?
gives 13
Also note that you cannot avoid exporting symbols totally.
The above example you can avoid with a linker script, like:
printf 'LIBBAR_1.0 {\n global:\n bar*;\n local:\n *;\n};\n' libbar.map
and then give -Wl,--version-script=libbar.map
See transcript below. In my example foo[12].[ch] represents a library
with an unstable API/ABI, provided as a static library only. Note
that it has symbols `x
Re: Should .a library contains non-reallocatable code?
* Simon Richter s...@debian.org [150222 21:19]:
Am 22.02.2015 um 20:18 schrieb Bernhard R. Link:
echo 'int foo(void) {return 17;}' foo.c
This code just happens to not generate any data references, so none of
the forbidden reloc types are emitted.
You can add references here. As I do not merge it into a dynamic object,
it does not make any difference, though.
(Also data references is a bit misleading, as data references and code
references
do not really make a difference.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
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/20150224014724.ga2...@client.brlink.eu
Re: Should .a library contains non-reallocatable code?
* Russ Allbery r...@debian.org [150222 21:51]:
Bernhard R. Link brl...@debian.org writes:
This is wrong. If libbar.so needs libfoo.a then libfoo.a does not
need to be PIC:
echo 'int foo(void) {return 17;}' foo.c
echo 'int bar(void) {return foo();}' bar.c
echo 'int main() {return bar();}' main.c
gcc -c -Wall foo.c
ar rs libfoo.a foo.o
gcc -shared -fPIC -Wall bar.c -o bar.so
gcc -Wall main.c -L. -lbar -lfoo
./a.out
echo $?
works just fine.
It won't with something more complex on all architectures. I think there
are architectures (i386, maybe?) where you can link non-PIC code into a
shared library with a performance penalty, and (as mentioned by another)
it doesn't matter for code where there's no difference between PIC and
non-PIC. But this will definitely break on some architectures (including
amd64, IIRC).
There's been lots of discussion of this on the Libtool list, and I've had
to deal with this from time to time in various upstream projects where I
wanted to assemble a shared library from various internal helper
libraries. Take a look at all the work that Libtool does to handle
convenience libraries for exactly this reason.
You are speaking about linking .a helper libraries into a shared object.
I'm about the case that a shared library has a dependency on a different
static library instead.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
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/20150224015905.gb2...@client.brlink.eu
Re: Should .a library contains non-reallocatable code?
* Jeff Epler jep...@unpythonic.net [150220 00:19]:
Here are two scenarios where building a static library (libfoo) with
-fPIC is desirable:
* libbar has a stable API, so it should be shipped as a .so,
but if it links libfoo.a, and libfoo.a is not -fPIC, then
libbar has to be shipped as a a static library too
This is wrong. If libbar.so needs libfoo.a then libfoo.a does not
need to be PIC:
echo 'int foo(void) {return 17;}' foo.c
echo 'int bar(void) {return foo();}' bar.c
echo 'int main() {return bar();}' main.c
gcc -c -Wall foo.c
ar rs libfoo.a foo.o
gcc -shared -fPIC -Wall bar.c -o bar.so
gcc -Wall main.c -L. -lbar -lfoo
./a.out
echo $?
works just fine.
* foomodule is a Python wrapper for libfoo, so it must be shipped
as a .so, but if it links libfoo.a, and libfoo.a is not -fPIC,
it is not possible to build foomodule at all
That is indeed the case. Note that simply compiling it with -fPIC might
not be enough here. As you need to include the actual library in the
module, this might mean you might end up with multiple copies of the
library, which might also mean multiple copies of any data it has or
with different versions of the same library in the same executeable
(and you cannot really have symbol versioning with a static library).
(If the wrapper is nor for the library itself (but only a library used
by that) this makes it quite dangerous. On the other hand it is a
wrapper for a library depending on an other yet-too-immature-to-have-a-.so
library, so it's quite safe to assume it is so experimental having a
python wrapper makes not much sense anyway.
If the python wrapper is for the library, than an _pic.a only is needed
if that wrapper is not generated by the same source package).
Unless the circumstances of libfoo make these scenarios unlikely, it
seems like it is better for other packages to prefer -fPIC even when
building a static library.
I wonder whether these scenarios were considered when the Policy was
written.
Static libraries have many serious drawbacks (there are copies in many
programs, so every fix needs a recompile-orgy, multiple copies waste
more RAM, no built-in inter-library-dependencies, ...) and since then
even gotten more (headers if libraries the .a uses (like libc, ...) are
used at compile time, but they are only attached to symbol versions once
the .a in linked into something, so they might not match the headers,
...) since then.
Once something is actually used by other things it is really a good
idea to provide a dynamic library. (And conversely, if something is
not yet able to provide a dynamic library, this is a very good point
to be made against including anything using it).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
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/20150222191833.ga4...@client.brlink.eu
Re: Architectures where unaligned access is (not) OK?
* Simon McVittie s...@debian.org [141121 13:42]:
A couple of questions for people who know low-level things:
* Of Debian's architectures (official and otherwise), which ones are
known/defined/designed to be OK with unaligned accesses from
user-space, and which ones (can be configured to) crash or give wrong
answers?
[...]
The ones I know for sure are:
- OK: any-i386, any-amd64
Are you sure about those, especially amd64? AFAIK some newer
instructions (I think something about vector code) have much tighter
requirements than the old 80386 modus operandi of everything might be
unaligned,
it is just slower then).
The context is that
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757037 describes lzo2
failing to start up on armel due to unaligned memory accesses. lzo2 has
a cpp macro, LZO_CFG_NO_UNALIGNED which can be defined to stop it doing
clever things with casting pointers.
'clever things with casting pointers' sounds like someone thought C
was an assembler and not a language with quite tight requirements on
what you are allowed to do. If something does 'clever things' I strongly
recommend to compile it with -O0. Optimisation of the compiler is only
supposed to keep the behaviour of conforming code, with 'clever' things
everything is possible.
If the maintainer doesn't object
(or fix the bug of course), I intend to NMU lzo2 to use that macro on at
least armel; I would like to sanity-check whether I should be using a
blacklist or whitelist approach, and which architectures other than
armel should be on the blacklist, or which architectures other than x86
should be on the whitelist.
Relatedly, if we have
typedef struct lzo_memops_TU2_struct {
unsigned char a[2];
} lzo_memops_TU2;
*(lzo_memops_TU2 *) (void *) dest =
*(const lzo_memops_TU2 *) (void *) src;
is gcc within its rights to optimize that into an aligned 16-bit load
and an aligned 16-bit store, even though alignof(lzo_memops_TU2) == 1;
or should gcc be emitting pessimistic byte-by-byte code for that?
With the *(const lzo_memops_TU2 *) (void *) src you tell the compiler
that src is pointing to a memory address that is a lzo_memops_TU2_struct.
In a case where it is not gcc is free to assume that this code path is
not inteded to be ever executed and may replace it in any way it see fit
to cope with other code paths (luckily replacing the code with
'system(rm -rf /);' is unlikely to happen, though that would totally
legit for a compiler in cases src points to anything else.)
For dest things are a bit more complicated. If the alignment is wrong
gcc might replace the code with anything it wants. Otherwise that memory
might afterwards be regarded as lzo_memops_TU2_struct and accessing it
as anything else is fair game for the compiler to assume it is dead
code.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
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/20141121133100.ga8...@client.brlink.eu
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
* Ron r...@debian.org [141119 07:21]: I believe Bernhard explained earlier that git-dpm allows the replacement character to be configurable (but also offers just a single character for all replacements). git-dpm doesn't have a replacement-character configurable, but different control sequences for the variable parts of tags supporting different version schemata, so one can configure debian%e-%v for the old style 1:2:3~4 generating tag name debian1-2_3_4. And debian/%E%V would give debian/1.2.3.4 and foobar-%e%v would give doobar-1.2_3_4. The current sid version has some combinations (for the different parts of the version needed for the different older schemata there are currently %v %u %e %f %V %U %E) but yet none which replaces anything in versions with %, which will make it interesting to create code for it. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- 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/20141120193737.ga1...@client.brlink.eu
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
* Raphael Hertzog hert...@debian.org [141114 12:34]: On Thu, 13 Nov 2014, Bernhard R. Link wrote: * Raphael Hertzog hert...@debian.org [14 22:26]: Helper tools should usually rely on the output of `dpkg-vendor --query vendor` to find out the name of the current vendor. The retrieved string must be converted to lower case. This allows users to override the current vendor by setting `DEB_VENDOR` in their environment (provided that the vendor information does exist in `/etc/dpkg/origins/`). Is using the vendor you use git on a good default for the vendor code you are currently working on? In my experience those two are quite unrelated. Do you have a better default to suggest? In any case, having a default value is certainly better than not having one and forcing everybody to configure it in some ways. I'm not so sure about that. Having a broken default can be more annoying than not having a default at all. I try to work in Kali chroots when I do Kali work. It's true that it's not always the case but if there were real differences right now I would pay more attention or would ensure to have the proper environment. Well, for test-building stuff and things like that going to the proper environment is nice, but why having the need to have gitk and new enough versions of your helper tools around everywhere? Version mangling When a Git tag needs to refer to a specific version of a Debian package, the Debian version needs to be mangled to cope with Git's restrictions. The colon (`:`) needs to be replaced with a percent (`%`), and the tilde (`~`) needs to be replaced with an underscore (`_`). Is there a previous case of encoding colons with percent signs? This is the current convention used by git-buildpackage and I believe the % has been picked because it's visually close to : (i.e. two dots/two circles). If it is inventing a third way instead of using on of the existing ones, is sounds like a bad idea. Do you suggest to use URL encoding? That's rather heavyweight for two special cases that can be easily mapped to other characters that are not used in version strings. And it would convert characters that do not need any special escaping currently. No, I was refering to the many ways to encode. I was yet aware of encoding 2:1-3~4 as debian2-1-3_4 debian-2_1-3_4 debian-2.1-3.4 I guess using single letters as format identifiers in git-dpm's tag specification was a bit optimistic... Tags are only based on versions are also quite hard to shuffle around. I'd strongly suggest adding the name of the source package to those, otherwise accessing multiple packages in on repository causes a big mess. (git keeps branches in the per-origin remote namespace when fetching stuff, tags only have one global namespace, local and remote). I don't think this makes sense. The common case is a single software per git repository. If you have multiple software, then the git way is to use git submodules. If you have an upstream that doesn't follow those conventions, then it's a good reason to not follow DEP-14 for the tagging of your Debian releases. While having a repository hosting multiple projects permanently makes in many cases not that many sense (though I sometimes prefer it for some small stuff, as it allows to make/update a mobile backup with a single git command), cherry picking commits from other repositories in git to my knowledge requires fetching at least part of that history in your current working repository. When fetching too much by mistake the global nature of tags can make quite a mess. Native packages === The above conventions mainly cater to the case of non-native packages, that is when the upstream developers and the package maintainers are not the same set of persons. When upstream is Debian (or one of its derivative), the upstream vendor should not use the usual `vendor/` prefix (but all others vendors should do so). The main development branch can be named `master` instead of the codename of the target distribution (although you are free to still use the codename if you wish so). Does native here mean a native package or a package developed primarily for Debian (which can also use a non-native packaging)? This paragraph seems to mix those two concepts quite a bit. Yes it mentions both concepts. I tried to word it in a way that is clear enough though. If you find some parts ambiguous, let me know which one or suggest a better wording. Perhaps s/If upstream is Debian/If the package uses the native packaging format and upstream is Debian/ ? I tried to improve this: @@ -175,9 +177,8 @@ a byte-for-byte copy of the upstream tarballs, this should be done in the Native packages === -The above conventions mainly cater to the case of non-native packages, -that is when the upstream developers and the package
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
should not use the usual `vendor/` prefix (but all others vendors should do so). The main development branch can be named `master` instead of the codename of the target distribution (although you are free to still use the codename if you wish so). Does native here mean a native package or a package developed primarily for Debian (which can also use a non-native packaging)? This paragraph seems to mix those two concepts quite a bit. Patch queue tags A patch queue branch is a (temporary) branch used to define the set of upstream changes that the package will contain, its content is generally used to later update `debian/patches` in the resulting source package. s/(temporary)/(possibly temporary)/ ? What to store in the Git repository --- It is recommended that the packaging branches contain both the upstream sources and the Debian packaging. Users who have cloned the repository should be able to run `dpkg-buildpackage -b -us -uc` without doing anything else (assuming they have the required build dependencies). ++ (except that one of course needs to get the .orig.tar.gz using pristine-tar or uscan for a non-native package needs to be an exception from anything else) Managing debian/changelog - This DEP makes no specific recommendation on how to manage the Debian changelog. Some maintainers like to use tools like `gbp dch` to generate the changelog based on Git commit notices, others edit the file manually and use tools like `debcommit` to reuse the changelog entry in the Git commit. Helper tools should however configure the Git repository so that merges of the `debian/changelog` file are handled by `dpkg-mergechangelogs` as this will make it much easier to merge between different packaging branches. Ugh. Please do not encourage tools to pester with my git config. (Perhaps this want meant as something to do when automatically creating a repository for you?) Bernhard R. Link P.S: I think the timing for this proposal it not that good. I'd rather waste my time looking for some RC bugs to fix as long as there might still be some easy ones left so shortly after the freeze. -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- 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/20141113192257.ga2...@client.brlink.eu
Accepted dosfstools 3.0.26-5 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 11 Nov 2014 20:38:15 +0100 Source: dosfstools Binary: dosfstools dosfstools-dbg dosfstools-udeb Architecture: source amd64 Version: 3.0.26-5 Distribution: unstable Urgency: medium Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: dosfstools - utilities for making and checking MS-DOS FAT filesystems dosfstools-dbg - utilities for making and checking MS-DOS FAT filesystems (debug) dosfstools-udeb - utilities for making and checking MS-DOS FAT filesystems (udeb) (udeb) Closes: 768909 Changes: dosfstools (3.0.26-5) unstable; urgency=medium . * QA upload * set Vcs-* to collab-maint * add 0001-LFN-is-no-volume-entry.patch: don't overwrite LFN entries with volume entries (Closes: #768909) Checksums-Sha1: c6654533357bead6524ca287c78ba18ff835de4a 2027 dosfstools_3.0.26-5.dsc a6ca5a89f8d8a0b544a84f2ee45917d15143d415 9724 dosfstools_3.0.26-5.debian.tar.xz 844edd410df121d9b3a8fad4368cd243059aa8e3 86392 dosfstools_3.0.26-5_amd64.deb 9aa67a5b15357ec5f6e30c1f096e95404f668044 152676 dosfstools-dbg_3.0.26-5_amd64.deb 25f30067e66775940638fbd02cdad661a40b4f00 40292 dosfstools-udeb_3.0.26-5_amd64.udeb Checksums-Sha256: b84863ba314dee7078ed833e97bfe23f27912297d14a6136566b9f288411ecd7 2027 dosfstools_3.0.26-5.dsc 392b47818afe99d9aa123337f419c87fd2cab47fa76a8a15c97ce094a2135e34 9724 dosfstools_3.0.26-5.debian.tar.xz f7cb6e2ee63f807dd3bf6ed30bd719d0fa74bf873c5dca34cf763354fd3a09ef 86392 dosfstools_3.0.26-5_amd64.deb 19948f6267dc6d046421d811091e3d2b06beb9cd6488dd88ade04221f0cf03b9 152676 dosfstools-dbg_3.0.26-5_amd64.deb 786440d8222c2df69bb337851221386f73268ab3041a729c768924c40caf415c 40292 dosfstools-udeb_3.0.26-5_amd64.udeb Files: 535ca18c40024c3106d8a20180d24434 2027 otherosfs optional dosfstools_3.0.26-5.dsc 4cb6780b9c6771e0dbeb8f6d435f261d 9724 otherosfs optional dosfstools_3.0.26-5.debian.tar.xz 1fafb4be1f3b521edc8341ea4a3389db 86392 otherosfs optional dosfstools_3.0.26-5_amd64.deb 2aa761d074d9b8c4cc419ab71656efa0 152676 debug extra dosfstools-dbg_3.0.26-5_amd64.deb 4b746e6ce378c494d674dcd399077eea 40292 debian-installer optional dosfstools-udeb_3.0.26-5_amd64.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUYnY7AAoJEOxkTtbr1QJDVWEQAKEzwYWC6BVnwwIwtLEvoG30 RqrAd9u9xeYcHmsQRTNjcOoTBdhF77oBb8RjHISC7q9ehowDhmzUlnYSd/dQQmBY +TNHDKDoU7MVOYqipgPb5j5MGxgjn2uiU6XIe+bm19XT5PG9BD3X4abnx6IG4npt RTrmnN8uRv91gfPn8y0kzgvikZVqKup0KGP9V0raO8IEEZDrMOnZ1EqoaeAMMMU0 mdieR0VgGViOhara5OkswRnxTJCXZ5XDe0PeH+Et8rpMY2yd5P+U/FAXdfxYL5U4 cFS+9jr0JbliJc5f5HVMAWB01PsC9Pw9nqlUBSv5iCKWQia5+t+PmrlMo+4qOeQ2 QM4EOarZELH9Isj634ojnhJUuTst+yWoPMKsdJMyYTmcfAu7YnbH1k6oMMt3NZnz GCBVn8w+Xw5uJig2Ygz81I/WUoUpPQR698k8lIxQoHtYRVDkVyfthV29So6gyIej /6iwXa25LgiXYSXrLHrfOcZbavu+x5iIQCQsMoT2NUg6TEBkaxike0OBB6HwMSQP o2XxduS1NKevZQFjOmydcc8TUFuZjVRzZlhL/HhWDEXTljQJXQG3mxmLqyWvEXNZ gKpmvW/VJJX9YIWiNb9BMf1oHgZ3N5teTFLzvMftRR3Tc3SpQMHNkwGyB8hoOmt6 8mtVnfewJfEW0F9d5fiL =JDB7 -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/e1xoiqz-00079j...@franck.debian.org
Re: dgit and git-dpm
* Ian Jackson ijack...@chiark.greenend.org.uk [141103 19:13]: The point is that the dgit user probably will have done git diff before dgit build / push. git diff provides a more convenient diffing tool than debdiff, and eyeballing the same thing twice is makework. git diff is a nice tool. But it has it limits. Try detecting the adding or removel of an empty file with git diff for example. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- 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/20141103213245.ga4...@client.brlink.eu
Re: dgit and git-dpm
* Ian Jackson ijack...@chiark.greenend.org.uk [141030 13:42]: Thorsten Glaser writes (Re: dgit and git-dpm): – I’d prefer users of even dgit, no matter how good it may be, to not rely on that. Again, why ? To do an NMU, one has to generate a debdiff anyway to post it to the bug report (as the rules for NMUs mandate). And the debdiff is the real difference so the real changes done, so worth looking at. How is being quite sure what would be in there with dgit that much different as with other NMUs? Where is the difference to I just applied those two patches from the BTS and changed debian/rules the way described in debian/changelog. Why should I look at the debdiff? I know I changed nothing else.? Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- 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/20141103061735.ga1...@client.brlink.eu
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
* Christoph Anton Mitterer cales...@scientia.net [141030 05:10]: To be honest, it's really awkward to see how much all this is apparently fought against. You have been told again and again that what you suggest would make the whole thing less useable to the point that it reduces security for many people. You have been told that your thread model is quite strange, in that you assume that people will - not only notice every MITM with too old a signature even though you suggest to change the system so that this will cause far more false positives, - but will also investigate every short network or mirror problem so that the far easier MITM of making the security mirrors inaccessible (which your suggested 'improvement' does nothing against) is not possible, - but are not able to notice if there are no security updates applied. What do you expect? That people on the list think it is a good idea to do what in their eyes only lowers Debian's security just because someone continues to claim the opposite? Please take a step back and try to understand why people think this will not help (It is not because they do not believe in evil resourceful governments). This should make it easier to either have arguments that persuage people or even better lead to solutions that improve the situation more generally (I'm quite sure the are aspects that can be improved, just that lowering Valid-Until times is detrimental). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- 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/20141031114804.gb1...@client.brlink.eu
Accepted cuyo 2.0.0brl1-3 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 18 Oct 2014 09:06:55 +0200 Source: cuyo Binary: cuyo cuyo-data Architecture: source all amd64 Version: 2.0.0brl1-3 Distribution: unstable Urgency: low Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: cuyo - Tetris-like game with very impressive effects cuyo-data - data files for the game cuyo Closes: 757090 Changes: cuyo (2.0.0brl1-3) unstable; urgency=low . * add portuguese translation (Closes: 757090) * install translation files (fixes packaging error and adds pt) Checksums-Sha1: de395681277709a912166b053eaa09de37b41a4f 1937 cuyo_2.0.0brl1-3.dsc 65e7863229f63499c11af0c6ce2f75ec4b5b4ad9 19900 cuyo_2.0.0brl1-3.debian.tar.xz 9d2d4e545acdc3acf9a5e7d23d93bdbf6b1527e1 2225254 cuyo-data_2.0.0brl1-3_all.deb 56c7db63fcd841a9f4f232bff9ea29a37a6ce36c 162420 cuyo_2.0.0brl1-3_amd64.deb Checksums-Sha256: 80cef6875c3b8f563c4d80111b074a1156df193559a99dec3099ac7bb41acec9 1937 cuyo_2.0.0brl1-3.dsc 0293daff2053e91e663d0e974951252884370798fb1371750849333ced4eba09 19900 cuyo_2.0.0brl1-3.debian.tar.xz e5a317483b8c5996847b4789e26d4672e08bae4595efec29ab9eaf401a85 2225254 cuyo-data_2.0.0brl1-3_all.deb daa62c8401477ab6da2e643d7d8c8caea6fc10a30d01aa97d61864d8612faee8 162420 cuyo_2.0.0brl1-3_amd64.deb Files: bc788bf4eafa25ad6f31b9256bfd30d8 1937 games optional cuyo_2.0.0brl1-3.dsc 1066108f33c88a7256781f9a66cca9e6 19900 games optional cuyo_2.0.0brl1-3.debian.tar.xz 2bd2788f228ca7c650a87edaa7457d2c 2225254 games optional cuyo-data_2.0.0brl1-3_all.deb 7803f90c5bf1d88e18a06cd744f75812 162420 games optional cuyo_2.0.0brl1-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUQhUbAAoJEOxkTtbr1QJD/TYQAKNonHDkNCAUYwuxPGzoRhdk AK7yIlbpplqbi4cCbBmsHAZ6l4LH0zM7mATgFGdvf9oiuS8enwI/gtHavuKaYYXd WcGOaAF+/9HUYC2eoNSFKcD/uW2HdUQPwXpy1hr4WHOC3z7IqbMbN9O1nUC+4ksf TTAX3ScZK4QuFq0dzPcVIEdsaFLHXU3FAtezfltBnnj5HKVdYF+KzEUaUkzIcEjj McKFksvdLnRUNYQQ0aLmozWi6nG8RfLRTNO21YxcgmEGNDgSi/zGJBYpvPvZK5Vc QN2FVqZEgpfUzQfSl9mkEdQ411kUH2ZiNV0JXiNRS2IsWdLXO9KhP1V29SNkwfio BRWcn4HVaryCgrU0x2oHcAyeljvxlcxayZ4vzFum9N9Fvujzo/gX9brUCJOMnB4n IMEwEmyEUonnN6d06uI6H2G1EhVyFhO3s975hlCySi1gFTS93k/tsdK1L8QJE4Kj nkC3wbQnjopwIZWUT7s3/v+i304gCzHh1LI5xZHrNBl8uqIfDr9kxRf1IKSnxb6L 1BLVZlr3wwwELdNpfAuu1wBLnLCHRo5jFXggocJ+yya+tT/cvTsifwpHeybziRhW 7BbKMfqWAvwbI2BMfO/qu0rwM8xvU4aVPuyErWFsbhMFikwpPT2gwycqi+HEFJeC TAqujJZlfcjkBwzLtZMp =+UOB -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/e1xfowi-0005zn...@franck.debian.org
Accepted git-dpm 0.9.1-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 18 Oct 2014 09:54:57 +0200 Source: git-dpm Binary: git-dpm Architecture: source all Version: 0.9.1-1 Distribution: unstable Urgency: low Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: git-dpm- git Debian package manager Closes: 760576 Changes: git-dpm (0.9.1-1) unstable; urgency=low . * new bugfix version - fix import-dsc broken by 0.9.0 - describe --allow-nonlinear in manpage (Closes: 760576) Checksums-Sha1: 0de5515e14526da314a770e276d7ab89b3216afa 1844 git-dpm_0.9.1-1.dsc c963d33c5e2e5908d20694ab8d22215e36798819 150615 git-dpm_0.9.1.orig.tar.gz 7b53744ce99df1abcab277a4636a7ddef49ef200 3428 git-dpm_0.9.1-1.debian.tar.xz 0b3bd6b679eba11fd13a89090a18cdbdbaf792ae 193088 git-dpm_0.9.1-1_all.deb Checksums-Sha256: 727640870490a007ee05d6be9786654005026c78bdbb0d42e7051b2d528e37f3 1844 git-dpm_0.9.1-1.dsc 66063ef7d83b9b865db1547f9dc1c6e96080d1d116d1b2abefdd074d9bbc9fc4 150615 git-dpm_0.9.1.orig.tar.gz 7d8c2bfab0f15b63bfad2a2e1d90cdcabbeb4108a407be4397761bdd82b11f14 3428 git-dpm_0.9.1-1.debian.tar.xz c6591503a416eabc939976664c628a76e9fbfb9ff1489f12ca2976d7d99b564e 193088 git-dpm_0.9.1-1_all.deb Files: e610598fc4c191faa845c92b396e265e 1844 vcs extra git-dpm_0.9.1-1.dsc 41129b8459bd0f563c008e81464f3b3b 150615 vcs extra git-dpm_0.9.1.orig.tar.gz 855356cb28618eca2dc7f16ae380de9e 3428 vcs extra git-dpm_0.9.1-1.debian.tar.xz 49c0e03d9a35dbf6f48830efb4c09e2e 193088 vcs extra git-dpm_0.9.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUQh9kAAoJEOxkTtbr1QJDw04P/34BSRiNW1c34vTNOJhVNWER km2LNeYD6NZnXSm2kNZ837nuuTzkULD1B5duvFGAmlvsEbnPYsJ3prhnEu7xe2H8 GyvLQBO11xP2iqWCWrkG4PgEuQrVEsgrEGXfQfoFQXgnvkd/l9TXD476ciTy5jF6 hZRubMGxfaxqgM5fsLcjkaaX38vIMzH2NrjLv+PC79cGrds/xxc1t7a8fEtOEW+k dAg3oLIZxjf0rI1T0z8AAZGuvX2+JMQ1UDpBea9GXFQ70xLKmEd9DgYUxUsLTfMt 0O7BW2Av3kn3P3HEcRv5DZo4Y25fvUEK10hfKI32uLd8lqaABuiR1HUZbkWbiXlR sZb9J/v5d6PS0XTJrq2qJGMY9+qjbnJ1ONShpDMMaeomkdlHM7shLpLWT50HF7Ze s7DYgX8iROUu4lRc0nsV5Wl6hT6AUa7XUT4phBJlnYwATWDHe0cHtABWJYla1sH8 WY740F2ykL7uTeCZFFVsACt0NTGaljW48ELWP1qDB/WoXypQRt/qwM8GcF73on68 0nG8E088+dwyz2NHp6k4OGg9LhzeFAJuGpVlbmXvALG3+8BX4SiPq64lGr9SwIXo gHateRoFW05EOkvrKGmnb/uQMOakhGLmLEsoJVcUhRGchDAghTVSzQTmeOWxgtWH YxjOud2IL1GDT16nQ9pZ =xcsi -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/e1xfrwg-0007gp...@franck.debian.org
Accepted git-dpm 0.9.0-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 11 Oct 2014 20:39:37 +0200 Source: git-dpm Binary: git-dpm Architecture: source all Version: 0.9.0-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: git-dpm- git Debian package manager Closes: 754052 760579 Changes: git-dpm (0.9.0-1) unstable; urgency=medium . * new version - mark new-upstream subcommand as deprecated in favour of the new name record-new-upstream - allow to set default tag names also in debian/.git-dpm - add more possible variants in tag names templates (Closes: 760579) - add --exclude options to import-tar and import-new-upstream - several small bugfixes - improve documentation about removing patches (Closes: #754052) * increase Standards-Version Checksums-Sha1: 057170b90ab8fd5515dc81c1a5d3f4bb52fb1fc9 1844 git-dpm_0.9.0-1.dsc 75e7806f4b7d06478ddc43c3258f89746fa1cf8c 150339 git-dpm_0.9.0.orig.tar.gz b3ea7b934d97d0ae288f6c2e5089f1bcef63d11d 3372 git-dpm_0.9.0-1.debian.tar.xz 4180a6b267a5f302a18534c85ac6a8a20a3eb232 192620 git-dpm_0.9.0-1_all.deb Checksums-Sha256: dd5269eba7dc215e137d1d692b0b487b3773305e0e0f933c338df41513167337 1844 git-dpm_0.9.0-1.dsc 74464998de52faee01edebd9444c5ba6bf6f94c0a417393481a01440545a40e2 150339 git-dpm_0.9.0.orig.tar.gz 7ce41faf9934cf2057653b22d27c3c8421c7811f5240883174f7a3b740a418a1 3372 git-dpm_0.9.0-1.debian.tar.xz 20e2b59b745ac4b8991364213c8b4fedd5dcbc34dfb784e6bfb6b2cca084bb40 192620 git-dpm_0.9.0-1_all.deb Files: 3ec39af25858ad567b723ce31b442731 1844 vcs extra git-dpm_0.9.0-1.dsc da6aab1c0a46fcf0c3b5b7d24038f86b 150339 vcs extra git-dpm_0.9.0.orig.tar.gz 3f0fd60f0447b8ae3d78a74bd5f2fab0 3372 vcs extra git-dpm_0.9.0-1.debian.tar.xz 819e80d0861619daabdbb5fa223e6f5b 192620 vcs extra git-dpm_0.9.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUOYdcAAoJEOxkTtbr1QJDUt4QAIfNHvbj72VpihtYPxD32DR9 ZacTKSN09EU5DNzMdhi+zX+/j8/cCDwOA/AOK54TNDVAd2eCvADIq4R9V+1JLxNX Ld2zgAhqOzEP5NcIErnFdIClirG9gGe7xnWwI1GWMvtj4DqqIs/ZP+cwAqCCxK5e FawMYX5+E+z18O63qJd9ZgwjnpV/3ggIOocsSSmGUQZvPGnv3pMrjsWjUffrKhXD BFmx7AL+Jg7tYeaukQF1fUdk7/fgcwYPM7DDWRmpQ83m8vycp+fC+O1rS92hpQLP 61K0YOz7ge/M85AbSJxhm5CAcntC96F67TU+fSPcEUnYt6VEy1yZlb8Qt4TbmlDa si3GbBGSPa6gShz99wO4pfCMmEn5e7udaL5n21ib5AEMlQ8gxX4u9q4OcDsTJE7r X9SaD3vym2xl+MXwVm7Hs7Cfi03zJWJ7924T2pOr69juQ8QcgdEHOQ0XNa7ZPDU0 0rzP/MeKjTkFhOHK5cklByKtxSGgpTK2FozffdjlsHvq0YBvfmKXqzSFhju3CIy0 ni5UToucJw3CqrFcPkrwsB2hjTkzgMP1cGdh3JTvqsPORKQm+F9hzKhBOVUXkvDU jeUZHSCZ4IjsyAgb3ndylcWo2gUNL0xcZFoS7Rw9Ob/QRsuwZwf2gJnplojAkH0B ThJrhVGzMeo6OGHKv1/+ =pBlV -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/e1xd2gk-0004uc...@franck.debian.org
Accepted ratpoison 1.4.8-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 10 Oct 2014 12:00:36 +0200 Source: ratpoison Binary: ratpoison Architecture: source amd64 Version: 1.4.8-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: ratpoison - keyboard-only window manager Changes: ratpoison (1.4.8-1) unstable; urgency=medium . * new upstream bugfix release - fix sfdump with multiple screens * increase Standards-Version * add debian/emacsen-compat to work with new emacsen-common behaviour Checksums-Sha1: b644a047f4caf25990ca099b987ebd5b9818f7b5 1993 ratpoison_1.4.8-1.dsc 9adc4f0e89be41982d6b37dbd3ff4ffecae16394 364700 ratpoison_1.4.8.orig.tar.xz faeace9aedf0ee02603b6d0e9be02f9f32a724d2 19304 ratpoison_1.4.8-1.debian.tar.xz a1f83ec9aec2cecc58e5123e8386653d10738668 215180 ratpoison_1.4.8-1_amd64.deb Checksums-Sha256: cfaa4714e541645e7d6a6a9985d1b0ca684ccdd1016e504df6564693a431b783 1993 ratpoison_1.4.8-1.dsc da4695636d1fce8883ef2144d79ce46ebb0431a5da02440bd1ffec5dca17a0f0 364700 ratpoison_1.4.8.orig.tar.xz a0e854a1c0f17d8a3941ef2511c470a54d36d8e06c176253bd590257175abda4 19304 ratpoison_1.4.8-1.debian.tar.xz 15d09f711046792769f7d53974f64213565aec44f07a3e60609d1bcdab67b850 215180 ratpoison_1.4.8-1_amd64.deb Files: bfc18f1e3152ba5b4cf3e5a83ef19148 1993 x11 extra ratpoison_1.4.8-1.dsc 964f07f7ec91e95767a8d60fa6bdec3d 364700 x11 extra ratpoison_1.4.8.orig.tar.xz 86c60fcf8cbc8c61c1a6fa4648976f6e 19304 x11 extra ratpoison_1.4.8-1.debian.tar.xz da56338c347876dcda555944e3e628eb 215180 x11 extra ratpoison_1.4.8-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUN7MKAAoJEOxkTtbr1QJDwXgQAJqbTmFFt9zAfQwHpj2fC9Ox xW1ccoyG03ZpUJIiigONrQwQ34jeN+14/dMrXbV3hQIppvyFTHmSoPESmM0lty/J kYoW+JhAn/0KWOyP4gSKfiE/oscOqT1PdA5MR3+I7fzt3pR/wdX7kmYSArk98Z16 kRekJ1ZKSYtHfw3wOcYykTLbJwxJQLcSEzdROBpE2uj7QYFasj475Imy+/5mxciT iWv4jqb+iZqu1YBBkvfkXI1vWmlR1jtTPexBehUjJtZ6/p2qoCSSF0s7u5rhWbJ5 sKBnuz64ErCkfeE3lysEsyYUobr7AB4iOY+jOQWzgCCtfIh3xo7BmjCSC3Jgpehf FvNMOsTMC+H+LkKIGY74+UZX55MXPbLmexyO7AmdZiYFnH43bzfTVFmhe4BG5ato GbXnDE7TsZmMvS9+Q8IKZWrclYUi5Q/AmQrEd7LL/UGHKJuVLDvlfm+yf4t1nqCv zHdn0T3fgTg6dEwOm/KR7KKqL9i0Zeet7DMPif22J061WRc9U8fij6LOI4uOX+O0 3+rL0/W0/Zddhum3P7iTyA2w0OIyhVoWiDp50h9/ci3VM1d4WbyOPV07m/CTshh/ dnzE/5Ebp4L2RArR+/V7ZvLjN/BsZUTBZk+2Eas56A321jTWvtRYMG7vMgx352ib hoybGW2GiLiyOdNMKs5p =atPu -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/e1xcxxw-0005aw...@franck.debian.org
Accepted reprepro 4.16.0-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 31 Aug 2014 18:49:44 +0200 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 4.16.0-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: reprepro - Debian package repository producer Changes: reprepro (4.16.0-1) unstable; urgency=medium . * new release - don't use python2 in examples - support for using liblzma for decompressing .xz and .lzma * build-depend on liblzma-dev * switch Vcs-Browser to cgi URL. Checksums-Sha1: 69812cc188c2cef4e006bafa7fe445a5da7997ba 1944 reprepro_4.16.0-1.dsc 525c2963978ab139c5aff8746abeecae7e36206e 695240 reprepro_4.16.0.orig.tar.gz 5cc70313aea68670780d56c9eebf4a2703e17803 18640 reprepro_4.16.0-1.debian.tar.xz 2d7a8712ab49fe3bfbccf68ee63402ed11526ddf 438540 reprepro_4.16.0-1_amd64.deb Checksums-Sha256: 2c2c229421dd1c4fa0ca5ff91572b80c8d45e88b45692c061d3385437a0bbdb2 1944 reprepro_4.16.0-1.dsc fdd2cae3f23b26e3b44734925af5afb76486a46bde104254eb04d8344d98f591 695240 reprepro_4.16.0.orig.tar.gz c7d5d5ebfd1af8928e4df92fad3f7492fc8e2b46f8df2e0af6db73fa96b2e385 18640 reprepro_4.16.0-1.debian.tar.xz 94c06fe36848c399da9d8a3022059d0fbcd24d271bbe18cc043e45e6d0d14e1a 438540 reprepro_4.16.0-1_amd64.deb Files: 7cfb13ef0981f445a9b2b58f3a08c5e2 438540 utils extra reprepro_4.16.0-1_amd64.deb d90a0b8c1a32d6b46990c6732e2f3b70 1944 utils extra reprepro_4.16.0-1.dsc 76dea7a4ece4fd1f5c2594ff99290c1d 695240 utils extra reprepro_4.16.0.orig.tar.gz d9a07518e490468fbcc402b653b21bfd 18640 utils extra reprepro_4.16.0-1.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUA1gTAAoJEOxkTtbr1QJDTNkP/iTmdk4tFnqElH0op/OnRDdC m+k7Y3GlctVzUHpOjHkT9yxu+siWTNdpI3uxJaO4nQTZZ9YIwzkdN21Faa1k/FdI gxkrplWnwtfjjxMscV212UsFz622e29WQ1Wl/E18Qzo+Lo/KD4YKnOessVP0YKvA pxJeGU62VfuB2ytwrDx+kY+3RyKowXxQum9E0qKqFDkYwn/4fkK10RTB1pw2KEbM uYtt+i1m1Q5xLn4P+fAMkj0FPz3OLG3EXuYsTQzkrlCVSCYhR6YEMlGt7CvPeFf3 O33CNVP1jAtnh4UrNkiAhCfNJ9yBxzYMqU7dTxbOMFv6/uLhJmdZxzoEeStWbKwj n88lZ3scsSs9GyMPQTNS74pT5XobmeHRwDfQmIT/mGqpAlmcU87/QITbkcFVgClc anhQUcCRl6oyn6pg5Wxcab378Vyw3ys7Bp99bWDYidqeEsZZAblttYQ4Q3hMFK1c xFyG0VdIRApxV48tfiBdwlILF3yxMCDmUQCcjwgZY0/GP3Nl0WkMkbuPHTO7sEa4 i3K/HOaD3aZqcLPr9QHixPzIslNVXUIFJFQJtCtoeM3ea0E7825s3gXZBLjNCcn0 /ruRo6K+Ej89qOCVCA0m1GmPXFP+X4P2hlzgRrrvV1RU7z888rPYj9YT6RmN93YT De7GEO4IUk2GtSSjXQu2 =fQpQ -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/e1xo9fk-0004or...@franck.debian.org
Accepted xbuffy 3.3.bl.3.dfsg-10 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 09 Aug 2014 18:12:21 +0200 Source: xbuffy Binary: xbuffy Architecture: source amd64 Version: 3.3.bl.3.dfsg-10 Distribution: unstable Urgency: medium Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: xbuffy - monitor mailboxes and/or newsgroups Changes: xbuffy (3.3.bl.3.dfsg-10) unstable; urgency=medium . * orphan package * change Vcs- headers to collab-maint Checksums-Sha1: a15c668ff5b59aead076aa29d3709bd8489e9092 1927 xbuffy_3.3.bl.3.dfsg-10.dsc 2e677208d8e2490b52b768880615835446712b84 25376 xbuffy_3.3.bl.3.dfsg-10.debian.tar.xz 705e155571b950740cf1f695b74137e5289036a0 36222 xbuffy_3.3.bl.3.dfsg-10_amd64.deb Checksums-Sha256: e06b14c631a8a81596cac0a2ea4b55f8f746b2fbb56b6aadf24d28d126967b83 1927 xbuffy_3.3.bl.3.dfsg-10.dsc 985cea4c0356bf119737b878b93241eaf1082a81bc578c6b94c9e179cf870dfb 25376 xbuffy_3.3.bl.3.dfsg-10.debian.tar.xz ef2b54adf660c081f3d2043f83ebad59bc1114de99c372b6b1dfd2c803a6f09c 36222 xbuffy_3.3.bl.3.dfsg-10_amd64.deb Files: 7ef0e666f80e6bd6815ae27e5295dbb3 36222 mail optional xbuffy_3.3.bl.3.dfsg-10_amd64.deb 5843c5f92e2a51d3b482927723a8be0f 1927 mail optional xbuffy_3.3.bl.3.dfsg-10.dsc f3f0bcd4d59189dc23e70dbe9a9e256a 25376 mail optional xbuffy_3.3.bl.3.dfsg-10.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT5k72AAoJEOxkTtbr1QJD14YQAIimc+p/da43o50qctP2pREz dNLArzDruyZ36LAsdo485rhGw60EtkjaU3KBLwS/oTgVIwUIjHW29d1U5G1cFwuY EQTJ+D0jBef2uLnlMgcERjvRAwAGVAE5l38HUv8tTQZjq37A9iM8lwS0DYCGLk1n hOhg0N6s90sMG5uC+s3MnTLXLWcyggM8UHRgC7kUAviuvgwKTm8X296KxDv+M5lR IfD39uZJprlP8/15Xr5KbPlqZH6iiUL4+WUTu0vc5RHS9ot7TxdcBeX5mq/kFH9q 08ESo+iApWzVfclo4nTrvpz/5TO74AgvlKYg/D0Fns6njFwMm7PXwT1tqi1rNfdB qcjzogvln3MZfvPXWoSsC5EUpgjdPoO61/CHZxL4hnSEiBAi7IrF+MEz9mZNQwTm X9jco+mFDj2CtEcZGaHkaTyZ2moQE4zik8FisStOk4CsCiS3tjukobpP+hNYPpRR 3DUrrXIpfacgsLOMyf+91UC1Lw3P9zc0mhzT15+fRjHS4mlAFV3Znws7dXX3o7eL jMilNXVARADwUXYYfgXO4FePxRzCzm+2zQh4pf99AJf0qaRLmpV31YaaF5i+fCt4 8+dNJnVEDfIrhaii63igYBMLLoa5Cze9kACaciim8C74qdgGzBtY3E5f7Q/Ng/CH Lh/k3hzYS4BPa0XyD4ZT =rRJM -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/e1xg9q6-0002ss...@franck.debian.org
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
* Mike Hommey m...@glandium.org [140713 12:55]: … while IMHO it's possible to safely mix openssl and libressl if we prepare for that (i.e. make sure that _everything_ in libressl is only exported with properly versioned symbols) Contrary to what you seem to believe, this only really works if *both* libraries have versioned symbols. Otherwise, you can end up with libraries linked against the unversioned one using symbols from the versioned one at run time when both are loaded in the same address space. Actually, both having versioned symbols is not enough. It is either both must always have had versioned symbols or both must have versioned symbols now and every binary linked against either must have been built (or rebuilt) after the symbols got versioned. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- 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/2014071333.ga6...@client.brlink.eu
Accepted reprepro 4.15.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 28 Jun 2014 13:46:06 +0200 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 4.15.0-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: reprepro - Debian package repository producer Changes: reprepro (4.15.0-1) unstable; urgency=medium . * new release - fixes to outsftphook example - new xz.example to generate Packages.xz * add pinentry-curses to build-depends to reduce install size * ship more of the example scripts * add pinentry-curses to Depends to avoid pulling pinentry-gtk in Checksums-Sha1: 879fb096170ccd78f93188563d55ad16e9a52464 1932 reprepro_4.15.0-1.dsc 3ebf8a02de9bd117aeeb9ea396f88bcf5a410f12 665051 reprepro_4.15.0.orig.tar.gz 9fe7fb1e196dff109e685bfac769200616a001e8 11908 reprepro_4.15.0-1.debian.tar.xz 38ffad6d7048d222cd985f024da17edb647e4c69 432534 reprepro_4.15.0-1_amd64.deb Checksums-Sha256: e27cd4f1c3d8b82884d429e846daf037347348da336a4cf26d6ec48e3ef3202f 1932 reprepro_4.15.0-1.dsc 698ad8c12bb1c5a0e09143f871eafbf8d3d41f8c4df1756e754e26cdebd024af 665051 reprepro_4.15.0.orig.tar.gz e528b367b7014b7e37e8be42ed7d48c1aa1d02acccb8c865cdc7f07bf4cc6ce7 11908 reprepro_4.15.0-1.debian.tar.xz f2d697a69eec18743386a73b21786ca56f78d6805d0968d621014821a85ae573 432534 reprepro_4.15.0-1_amd64.deb Files: 42ea5390e027100a9e5ba0d629c405eb 432534 utils extra reprepro_4.15.0-1_amd64.deb 5a44c2bd0a8d28dce44c7f0dab16de2d 1932 utils extra reprepro_4.15.0-1.dsc 572ebe99428918729a63b4c06c45a082 665051 utils extra reprepro_4.15.0.orig.tar.gz 7aaf2c6c8dd94cef66ad43af6a7fafd1 11908 utils extra reprepro_4.15.0-1.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTr/ItAAoJEOxkTtbr1QJD2kIP/3ekRUSRGx3cYBZpFjF4bX5r Icy285uOr+H6YW2OjiY1xpuaU9Vbw0DajLmye5ycTfUlP4BWJzZT6OJAwydKQIIW HWiwK4XOIpJUfmUG9Pmc5jnhSkzIsV2mVhJE4uuMm+kWGU+6ZkuOkGj+fbIDOJ9a kRGXx0xclwJnwAiWjLMjdIlKOpaIJQ3HPl6UtjpA6cXWg7jGigsnVqjXnIX+24Bz 4fZ5HlT2RP9OjQrd55nFqJruNKllV9HyJCOPt2wX+uRcTIuvSVNfsjwlskLFhCiE VFwl3ad4NhB19EAanwzNZQoFvlRTzcqHLJJJA1KAqLsBwUBu0ogKpRts089wxW+J vsafPIq28bQdHwmxcgBlaAqVWvw9nfCdFxIGeWgkx3mHtq4cWnkqpdJAjBFjK8pd eMi9UqWDlWrnJvFM8WsMQRJDZyVH3GMDkD/YShZFSZF9gVYzdzu/wgZUPgyV3oc9 Z6g0VZVRNIf9Bu4i9xppcYWJSVxHPYqPBO4eC2iZNC+jdWEej0zSSsz6Nz56H+Ls kyaLdcYHO/Z7AArhB1qvBaVE73oadCvFLRXG1Lt1Wgh5K+UkRIqdetCZyCXPVJIt HPF/eWfavR4hGR61OSKRV04XWL3Pm8KE9HW6Uh1YjU4K/9WXYmwDyez3q7OVMhtl yQRSZ2WKJ9LxAy095a8I =v+sJ -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/e1x1d9f-0004cz...@franck.debian.org
Re: Why not 03 ?
* Julian Taylor jtaylor.deb...@googlemail.com [140601 14:29]: I would not go into detail about O2 or O3 in the policy. The meaning of these flags is very compiler specific. E.g. clang will enable vectorization already at O2 and adds almost no extra passes with O3. I think it would be better to simply state: If the upstream optimization options differ from the ones of the default debian toolchain it is recommended to override the debian defaults to match the ones upstream uses during packaging. Upstream usually has choosen particular options for a reason, they know their software best. I think one of the examples here was scientific software. Assuming upstream knows what they do is very unlikely to be true there. I'd rather argue for a unless you know what you do, use -O2, which is almost the current state. (I'd rather argue that currentl too much software uses something different to -O2 for no good and too often bad reasons). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- 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/20140601124250.gb2...@client.brlink.eu
Accepted ratpoison 1.4.7-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 05 May 2014 19:55:50 +0200 Source: ratpoison Binary: ratpoison Architecture: source amd64 Version: 1.4.7-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: ratpoison - keyboard-only window manager Closes: 723650 Changes: ratpoison (1.4.7-1) unstable; urgency=medium . * new upstream release - fix printing of XGetWMName failed (Closes: 723650) * add new configure options and build-dependencies needed for new version * increase Standards-Version Checksums-Sha1: c4e0a56d273df8de97764cd3dc17df1ec0322270 1997 ratpoison_1.4.7-1.dsc d9fe174edfbc0ea4d74e779a8f4ca5f5d7a3f85f 363600 ratpoison_1.4.7.orig.tar.xz 05c73bf4b53d15b5777a69241d60cf0b586f3c81 19252 ratpoison_1.4.7-1.debian.tar.xz 39779e817d1762bc3ffe846802d2e4d692741d21 212380 ratpoison_1.4.7-1_amd64.deb Checksums-Sha256: e5cd3d434c6c12f3a5dba485a2c56a45aeb2d80946137846a1da501191340830 1997 ratpoison_1.4.7-1.dsc a57209a06869288fcd1347fa52a7963cdc6ff6622a917c3a9969d5e6dedf4db8 363600 ratpoison_1.4.7.orig.tar.xz 04fe73f33c370c2693889c19a4bffadebbe485216c9a05b5510b406169c4f428 19252 ratpoison_1.4.7-1.debian.tar.xz 51e4b7bf329c4807845dbf8c775a314a4a8ac604eda05b2416ab6e7aad6ab586 212380 ratpoison_1.4.7-1_amd64.deb Files: ab2650ebf067c2511d94c5aeeed9b951 212380 x11 extra ratpoison_1.4.7-1_amd64.deb 6be6f884c9d6a8660b562ee9f3304b35 1997 x11 extra ratpoison_1.4.7-1.dsc c26b798f4d50942e5807985adfb5b39f 363600 x11 extra ratpoison_1.4.7.orig.tar.xz 4597064f6838388fa75e310aac6f6bbf 19252 x11 extra ratpoison_1.4.7-1.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTZ9hWAAoJEOxkTtbr1QJDIo0P/jjqzpVQfjMZAaGFSni/XaZL z0VXugsSQSXTuQJDJmThNYzd0sb820c4aV8k105LQzNQdsXv7h3vKKKTM8AKQbCz tlV9FvJrg/g2jzzCK1r7kghgI/o/hOf7blzLqHShc02xmyuYPtFaMgOknjBIiqm4 7onITXVJATtIgo5F3gnJNsj/BzoEBrAFyRgvvRAQvZeAzTST290UlKFvUkIRQW0e tN+k0pLQr03rF2kS32JBuskLWSbhiHTnflnfnitynsJ2b1IuRAf00c0hHkWPXHZS Su3YuHWkd7t5wjVLQ2Rn5XwlpBz65tItHhL0ZwZOTiPk54sq1OxrVJPMTzbVjjqR fFMoECCEI0Yykjh+wgHwUOgfwXXd7LJNvVAX9TTro4TZ2XjHRQr73Ie6c5OWT8lI HIftb5zPdk4WhwrVZ+vv0NTW2n/uszRhJCtu0nHzQsWEYghhlLkCWPkGLHYtzKix WbnQU0DrOtBPnObivomQjJPxIidEjCyBAPxDphVpbhVgpJeCyRFZL41Me+2fTf/H 8N0gzyUy95DM23yvnLDka4cO0ZqLwrELq9FrVKmY1dyDNMVYAnFAcxtKzoHotxZd 4ST9yZqepbYZHjr6/oN5xIabD1k9lVcYKisUGN+0kRlXs8g31TCZKhmABKv9WhyY 35NtfE0Ni4zwv9XKgHIv =TMnq -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/e1whnxi-0007iq...@franck.debian.org
Accepted xbuffy 3.3.bl.3.dfsg-9 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 21 Apr 2014 23:31:59 +0200 Source: xbuffy Binary: xbuffy Architecture: source amd64 Version: 3.3.bl.3.dfsg-9 Distribution: unstable Urgency: low Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: xbuffy - monitor mailboxes and/or newsgroups Changes: xbuffy (3.3.bl.3.dfsg-9) unstable; urgency=low . * update Vcs- headers * change to debhelper compatibility level 8 * use dpkg-buildflags * bump Standards-Version * replace indent subject lines patch, fixing: CVE-2014-0469 xbuffy stack-based buffer overflow in subject processing Checksums-Sha1: 61cc9496af468a9004ee25132c466555bae7bad3 1914 xbuffy_3.3.bl.3.dfsg-9.dsc 3ad43024c31bb3f2db76b8df31390357af53a932 25288 xbuffy_3.3.bl.3.dfsg-9.debian.tar.xz 1b54f948d7b493eaf9fa5daac4d49b33cd3968a8 35908 xbuffy_3.3.bl.3.dfsg-9_amd64.deb Checksums-Sha256: cae7724a08603c1ffa833b98a480537b276d4a6371e00a80a0d8cf05aeabeb01 1914 xbuffy_3.3.bl.3.dfsg-9.dsc 46174a4cf33e60d2f3392513b2f40f451981242efce29d1258a63ea18503bc33 25288 xbuffy_3.3.bl.3.dfsg-9.debian.tar.xz 78bd6cb197967e9d3f85b292355047dacb8bdd3bb64204fb5add532a2291b8ad 35908 xbuffy_3.3.bl.3.dfsg-9_amd64.deb Files: 12358cc2c214118015c24b253acd4c17 1914 mail optional xbuffy_3.3.bl.3.dfsg-9.dsc 65b6eaf261e7fa68e111767503349314 25288 mail optional xbuffy_3.3.bl.3.dfsg-9.debian.tar.xz af79fb1843133eedff9d835b01a55b91 35908 mail optional xbuffy_3.3.bl.3.dfsg-9_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTXUcmAAoJEOxkTtbr1QJDYYMQAKtgIEEEynriXoBZUcccfNoV tI/ehQnlD5mnBUTk9vioLx65Mpl0Guj6MWe9W87FB6q41EwHKMdUHhITzZiV96WV 6Kn1DCQKFeCf5r74ZVsNqQpYHfMKsHEnYKfbYs+NlMFBmzivWidmBtQd7keSxw3J Hl6lQHILdOfZLI1ONCZ3ETTrJhcdqQ7RQeaVay6peLpJe785a1vfxma2MjdNNhVQ gaXNNOJEvoj0R+yWf3dfC9E2rukhEJAsCTNrybBzNINR68OpTD/up07SDcubwVMm kBVM26Vcwh4RClTde+LgeBUGaLbvhEoFim+yArATpy/+TTnVsB/qqFHIdZ/OtrnZ Awjmk86pK2xwvmUQwv/PwDZ8mJYCltGGuoMF0WM2JeMEK214egCcYjlDAvLB8iKf bKALAEDgAxiE3i7Rzteh7vbO1SJARneyRZ9am6VuHR12f3Jud8KFeL+4D3legXrv 7yJuS+/wz6g5PV6Bx4futwzGw7t1LzwGeBv93sWNmcWFn2I2dRG9MPe0ZRKaeq6/ PBAL/FEvop5V/3HuxWHOg1ghmMZYvOAwcxumvAtmoq/RwHIGxf1i1xH41tmpenPa WmYJAwrWUii2pp0pcF/WNYf1N89o9Q0jZ0Mpf8Gc2XegY5qsnU0pHg9pxvm03mry hDlPc7mhAdRdHGfe2JUc =1lKX -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/e1wetfm-0006n6...@franck.debian.org
Accepted reprepro 4.14.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 18 Mar 2014 15:12:58 +0100 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 4.14.0-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: reprepro - Debian package repository producer Closes: 714418 731966 738558 739174 739175 741507 Changes: reprepro (4.14.0-1) unstable; urgency=medium . * new release - update omits sources with Extra-Source-Only by default (Closes: #714418) - improve documentation of --list-format (Closes: #731966) - fix udeb overrides (Closes: #741507) - improve some glitches in error messages (Closes: #738558) - add _addreferences command (Closes: #739174, #739175) * increase Standards-Version to 3.9.5 Checksums-Sha1: 79bd2f88652d33fec2030aa4e0f99aa4ee93df1b 1910 reprepro_4.14.0-1.dsc f1a1358b4da06f1ffd3f300297e698e2a0260d3b 663442 reprepro_4.14.0.orig.tar.gz 93bc47721bea35d2f1b8db7b65f55e8b210d9fe3 11736 reprepro_4.14.0-1.debian.tar.xz b2f09c56ac4b608b119f03d614242dcf58b23168 409038 reprepro_4.14.0-1_amd64.deb Checksums-Sha256: 6f7e1ca1371f002f6e6c72dbbbd36089855d9dfe0af711599f2751a29d005b34 1910 reprepro_4.14.0-1.dsc 6e58e68927fbf2b99533f82b7eab365b3b9cbd7fc0a42e97e318077a4d6ceb36 663442 reprepro_4.14.0.orig.tar.gz 08162d9ea7ac871d4bbd8f81825b7bdbfad3ed1f58737272265bb26c351be7d2 11736 reprepro_4.14.0-1.debian.tar.xz f7dfab68dd3f3a39d8eb258c80d1b9324b3393ddf5026cc88ea43d72dae74562 409038 reprepro_4.14.0-1_amd64.deb Files: 5c6d6043d110a70ddcc9d0c1612844e7 1910 utils extra reprepro_4.14.0-1.dsc e4f68534e3353e09042149e059b2e23e 663442 utils extra reprepro_4.14.0.orig.tar.gz 8b931ebb0f72c0e80bc876b422000546 11736 utils extra reprepro_4.14.0-1.debian.tar.xz e3df35d4833702a2d340dbfb02e945dc 409038 utils extra reprepro_4.14.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTKKluAAoJEOxkTtbr1QJDtbkP/RRRqej9HWxaJKgrwGa+4sJl 1iqN/2u0Ej0cUoBURVKx38xf4f5JfG8CYxxaRwj2HX+jiHpzK8NpTMHLEF3IAujf 7aUZCmCbaGJYYrTh0xyzODGHevZguvitAehULwG4iF5h/tkGRQr/08NqTygXjfWM wpeuve94y0wMhAmsSrH6dfrn/26cJKdQsEh7BV0FwerSyMZE1oCnHc/FYWtS4s2W 6imqONXSNa2juwBshlYeRnzQqPFV+KWm88INdVq9Sz3DiO75Ud3yUJWhceWOdu7N dx+l5MKQ0uIZjdyInDXahjNu4HoiGnUTQcRbGLIhI0hek9pP/m104isX3CfO8n/Z E6WJ7mTNwQA3sAoTuuEZrqSwJtqqlLfhmKejO2LIcyWyqwPyqQbKcjTeze8mnZqy EfMz19bmNbXHuvhOeMeKqxCMyymJdnbIRvgQhTkGFHPoG87G8njHcZ741ecBEnes NdUExOgianjmgwZgvy728l3tkKkfN3i0vC+I+WckAU4an5Qn831LAnGR12Nq/Zzj humVCukNt6OGoHbGHQiV0Pv901CrZcFyuZtuwODzi1EcI7Nth7zHxSERwicTR0qs Y4XBn/Gzc1nTS8EvQjzTDimBHhIZ7wfGGDIkeeaFv0Pmwt78GyGjJJL10n4EmKkH hrRd7YE/suMTNad1sIVe =h2nJ -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/e1wq1mu-0002qb...@franck.debian.org
Accepted git-dpm 0.8.5-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 09 Mar 2014 17:33:07 +0100 Source: git-dpm Binary: git-dpm Architecture: source all Version: 0.8.5-1 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: git-dpm- git Debian package manager Closes: 734546 Changes: git-dpm (0.8.5-1) unstable; urgency=medium . * new bugfix version - now c-p is only short-alias for one command (Closes: 734546) - fix importing .tar files containing hardlinks - try harder to find dpatch patches to import - fix problem with importing patches with Author: onlyemail into git Checksums-Sha1: e06777c0981397ded02f807ace5e6c578dc1d72d 1824 git-dpm_0.8.5-1.dsc a1228a0862e05ae1f39ece7f54cd530b6a5221a8 148054 git-dpm_0.8.5.orig.tar.gz c9a891eef9f2ef69b4f2f4c1b6988c44629c2f70 3136 git-dpm_0.8.5-1.debian.tar.xz d11504b3f868dc8145c551fcb3ac0f3b29969571 187238 git-dpm_0.8.5-1_all.deb Checksums-Sha256: b8c216522d45e75649fddd0f4f649d58c8074f4e2fc0f101606540637e438a48 1824 git-dpm_0.8.5-1.dsc 654f72aa4c2b692161b5c3d2a78273a451ee6f5455a17a369a383a2f6086c2cd 148054 git-dpm_0.8.5.orig.tar.gz b9d4ebb8945f410b53fff5fa2450507c60d225279babfd3e115961f419c08609 3136 git-dpm_0.8.5-1.debian.tar.xz 7abd906cbaa39200b6dee15895b73e9a02f69c7e1e4d78881966cf8bb883594c 187238 git-dpm_0.8.5-1_all.deb Files: ce217e8bf1d5b5558838c22b345e183c 1824 vcs extra git-dpm_0.8.5-1.dsc cc2d512bcd03f93d61db556c10f9a958 148054 vcs extra git-dpm_0.8.5.orig.tar.gz cd87f9480974e45e9742d1f81cbae7e3 3136 vcs extra git-dpm_0.8.5-1.debian.tar.xz c04f2cb8761a9ef1a7f75a6c62468cf7 187238 vcs extra git-dpm_0.8.5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTHKoXAAoJEOxkTtbr1QJD0dQP/R5Sh2vVaRhaIX+z6lxbVkM6 vmF1UFusnMp32I6Ljyh2rcA/EzBkRt1Owhk9nNfbolwVJj3t0ey1Q2ndskzdaFSX h3fKgafcUWpJr7QayrTplFsMc3M6QnGt+lWurTraN9hJyCltkCFGUsXbQ//xwqi8 WsSRl6aw8ufL3iDbrejx0xRoX4EaDwINBvKVy7pn0z7pzn1+SGMvjrtxoT9r61Qf Uzs4bzEFJhoF7mTJyF3GGJmI2W+df62lOt4PQLZbcrcvmVhnBdZ3Ih6TLhKuShsZ hMuonJDVpu9zRjF7aicO2SgVLO9ijxZeleTKBjSkCMf6J84ESYYn7J+lmmhg4x+X b/OXYmkldvbMmP731ggytEN+uAggjGiTKqu+u+0Gbw+sCOQ8jFnBFHSXFIWyx7qX g4s8T1blndDKAgYsjJXW4Sunw/5NE6IaN9FQIm9nqk6n3DJOvAPvuqrngDunPniJ gitOWcEHCUt5d/HIyx/u9yXPoC+Tj2q+jdOmnRFjeslZOgZs3RrCfKbe1Bn0Khup xXGgwJDlY8Az7mTlEhEid8N0qJJZmYH8/Y/gyOsrYxkrkhUB2PmLIt8OTsb7Cn3y G0IYRmwHg9MpezrLEsSHueyPcPWttj9hpTzV5QKhc/whUZXWlsd8IDLWZWjg2LVn ucvn1x9pP9kPEMe07ccq =jyTw -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/e1wmiiq-0006qw...@franck.debian.org
Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
* Sam Hartman hartm...@debian.org [140205 13:27]: no, that means I have to maintain the artifact (namely the .orig.tar.gz). The archive software (both reprepro and dak were I to use that) require that the .orig.tar.gz not change checksums. I don't want my build machines to be able to push back to my master repository. Nor do I want to have to release upstream versions if I lose state on my build machines. So this violates my requirements because I have to maintain an artifact of dpkg-source (the .orig.tar.gz) and makesure its checksum never changes. This answers the question why you want to use a 3.0 (native) package. But the real question here is: Why do you want to use a version with - for such a package? Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- 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/20140205171418.ga1...@client.brlink.eu
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
* Charles Plessy ple...@debian.org [140205 14:18]: Who benefited directly from the change of behavior ? Nobody ? Then please revert it; it was not necessary. Most import are people starting to create Debian packages. At least with 3.0 source packages they no longer have to care about the different meanings of native vs non-native. A package either is native, then both the version and the package reflect this, or they are non-native. No more chances to only switch one of the fields but not the other by mistake. It also helps users, as it makes it easier to guess what things look like, from only looking at the version. Finally it makes it easier for writers of tools to deal with Debian packages, as there are some absurd corner cases fewer. (The most absurd one is a 3.0(quilt) with a package without hyphen. The resulting filenames are simply ...). Alternatively, please rename the 3.0 (native) format to 3.0 (tarball) or anything elese, and we are done. And brake almost everything? That suggestion is almost equivalent to just forbidding 3.0 (native) packages completely for the next decade. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- 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/20140205172131.gb1...@client.brlink.eu
Re: GnuTLS in Debian
* Russ Allbery r...@debian.org [131227 18:53]: Bernhard R. Link brl...@debian.org writes: * Russ Allbery r...@debian.org [131224 01:42]: On the contrary, it's Debian's insistence on following an idiosyncratic license interpretation that's creating the supposed unfairness. This is obviously not Red Hat's fault. Could you please stop using that word idiosyncratic. I believe idiosyncratic is exactly the correct term: idiosyncratic adj 1: peculiar to the individual; we all have our own idiosyncratic gestures; Michelangelo's highly idiosyncratic style of painting and therefore decline to stop using it. Given that the GPL FAQ and thus the authors of the license seem to be of the same opinion, calling an interpretation you do not like as peculiar to the individual is already quite derogative. Using a term that sounds quite similar like idiotic for this is something even a troll could not do better. Bernhard R. Link -- 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/20131228100308.ga12...@client.brlink.eu
Re: GnuTLS in Debian
* Thomas Goirand z...@debian.org [131228 08:30]: don't think it does anymore, especially seeing that almost no upstream author cares about Debian's nit-picking on this particular issue. We're just beating ourselves for no valid reason. Almost no upstream author cares about licensing at all. The mayority of them has no problems giving self-contradictionary terms. Distributing stuff with no license at all. Or simply copying other people's code without looking at the license or even without including any license statement or even copyright notice. Debian is no corporation that can just willy-nilly copy stuff around without caring for the law and hoping noone will find out or just pay the authors off if they find out. And our users are not really helped if the software they depended on suddenly is no longer available because noone cared for the license before. Bernhard R. Link -- 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/20131228100904.gb12...@client.brlink.eu
Re: GnuTLS in Debian
* Russ Allbery r...@debian.org [131224 01:42]: On the contrary, it's Debian's insistence on following an idiosyncratic license interpretation that's creating the supposed unfairness. This is obviously not Red Hat's fault. Could you please stop using that word idiosyncratic. How about using interpretations I do not like. Thanks in advance, Bernhard R. Link -- 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/20131225125243.ga4...@client.brlink.eu
Accepted cuyo 2.0.0brl1-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 10 Dec 2013 12:06:55 +0100 Source: cuyo Binary: cuyo cuyo-data Architecture: source all amd64 Version: 2.0.0brl1-2 Distribution: unstable Urgency: low Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: cuyo - Tetris-like game with very impressive effects cuyo-data - data files for the game cuyo Changes: cuyo (2.0.0brl1-2) unstable; urgency=low . * new maintenance upload - switch to debhelper compatibility level 8 - bump Standards-Version - remve no longer needed lintian override Checksums-Sha1: b6130f6304480e25240ca41392e2f1171f3fbf64 1937 cuyo_2.0.0brl1-2.dsc 803399fc3d782ba7ec532e3445bda09233d85ae5 6696 cuyo_2.0.0brl1-2.debian.tar.gz ba737ba9f44a3aea4904d24814ef2f39a0673895 2207884 cuyo-data_2.0.0brl1-2_all.deb e2f413dcc92acc45e2ebdefb3667fc5483338dc7 158776 cuyo_2.0.0brl1-2_amd64.deb Checksums-Sha256: b35b043e2869edf9e6fd61dc6515f4bea8cbfadcf4cc08fbd592dddbbae6 1937 cuyo_2.0.0brl1-2.dsc c3684339c22b1f1082f2002ca9cd4a7bbe5499cca78e87ef02495966276b3d6b 6696 cuyo_2.0.0brl1-2.debian.tar.gz a9e69b8eb78e39dceec49d30aeaf6fd66b09a43ef4655ef53a6e098669c2a111 2207884 cuyo-data_2.0.0brl1-2_all.deb 334dcf1e77b11e9b717b0e72d3455d259f65757a5284dc9fa0bda3ca9e61a79a 158776 cuyo_2.0.0brl1-2_amd64.deb Files: cfc10c23ecd363c0d5a43b816fa1ef82 1937 games optional cuyo_2.0.0brl1-2.dsc 432d40d98423dbbe58f6c25a1af0d0a0 6696 games optional cuyo_2.0.0brl1-2.debian.tar.gz 73cd888cee8cff342259c67d90f3f7eb 2207884 games optional cuyo-data_2.0.0brl1-2_all.deb 22ceaddcb01d2b2bb37f1de0b4c20e67 158776 games optional cuyo_2.0.0brl1-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSpvyVAAoJEOxkTtbr1QJDdSEP/37AyMPqKSSt6szjijOCNQIA 6/UwmMc4SQr1Ojch5G5N1AL/CuOdKCMcJzO5vG80zrumK5Di44uLnpd0apGDwKF9 EfiryxIJm+hy27zZ1JmfdjlYBC2ADvdx4Z9Iz0lziSfEXI3U5gHiMG2fGx5VSRlO TBcmCT6IvYllaWGDUBSSabrY/RYOBgh5ypxvml7ng3FkqM5A1FsAOdeVdHzrG1tq dDKnEF6IBv3DaO4F98WTZy1crkNn4ywro7mtVYeIf2XJmNb2ktP/D7xqLbMoCpNw YkiMGrCeKegFELZchtUTyRy5Iv8/YsAlOxLOZ3P9QXFHl9utax67NIVXhOPgc/IW hA8Quo0eTVviNh0AmHw+DK438wFVoPTzbB6UCoXPdJM8ad8Ak6rUHtB3D6a/ydZc jH9Bg0rARNH0hH3uh8ldsjVewwoi6LJJ8U5+yGXS0Bo5zBCrJDwB8CSdprQBiufy T/bpaUxq0uV8ViErsYvk/Z791dU6eoLE1zoHV4300UXBYA6gf4+gaQaSfxEjARd0 NZFIYiicT1evjIJ3EkGmP5Cz8k7TCvxsumJKwxQbI/Ow4CZh4VAVCLwHG+HyVcGP sS1BH10nTzSk3xnuDx2n/9BEizTUYIVlg6EESHgnjNW/cziBJ6W3RcRnyNYK66cf uhr81ZJ+qTYFo65HYDKS =+YjU -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: http://lists.debian.org/e1vqlng-0003xh...@franck.debian.org
Accepted xwit 3.4-15 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 10 Dec 2013 12:14:38 +0100 Source: xwit Binary: xwit Architecture: source amd64 Version: 3.4-15 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: xwit - collection of simple routines to call some X11 functions Changes: xwit (3.4-15) unstable; urgency=medium . * update Vcs- headers * change debhelper compatibility to 8 * bump Standards-Version Checksums-Sha1: bcaa9f5ed8a49ad8005111f91537a17fc9042958 1783 xwit_3.4-15.dsc af8b4921e17ff7510bae1116ed39108489dfbc24 20722 xwit_3.4-15.debian.tar.gz fbacb45a15b68cbc746e421ec7949e3874a6674e 18110 xwit_3.4-15_amd64.deb Checksums-Sha256: e9247693c8419704426a13c9d0f4d60cabdc1114b00973f4f238d58b2f1973e1 1783 xwit_3.4-15.dsc 71ee4d9816086f603754a4c16da8fd773c590821af386eb8adc2665623089f8c 20722 xwit_3.4-15.debian.tar.gz 83bbdcae59039268236bb0fb21ccf119e74f06fe25d741d71918d6745c1f5ebd 18110 xwit_3.4-15_amd64.deb Files: a62bd75f359192f518eb776af6dc12b9 1783 x11 optional xwit_3.4-15.dsc c52c9626fb87f8f6e375c429cbdafcc7 20722 x11 optional xwit_3.4-15.debian.tar.gz bf5f044f6648d86ac0e593e87dd9f3fe 18110 x11 optional xwit_3.4-15_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSpvydAAoJEOxkTtbr1QJDvHEP/2d6W+quPgt5//G6s9OioFVd fbYrSvu1sFOUy6B4xsLbUhT55vY5JpBaw8JDCSSBOZN9H+dlTj+eONEwvbfxtjZP zOH1E83AqcTNKnJasa4wxY9/MRtBw1WBK7M+C1B478f0d/1ev4+M+7LkQDIr+wrv O9Z4iAMzzqmdVzwa1EGAJWXUSOVpD2UybP/GiluwUEcEeBF//gwlMJ4yNJMRAaSl XhcrqnpntNldUJQd5nyjEAoggOUTff3krx4cvbtaloCggNTb69s/1OP2Lkw7tJWt yr+NNyeWLA3jcjUZVSyiFoMSSnMJLcSQQEaUvejYGJw1sP2oPEOe/X6dAQbYqEGx n/ViXo/uITBEvYkKRCH76rZD1K2qPt/IOtdAoNQ+seKGeqvFyyRi3IRSDUzdaqHI kRTTVwoLGhzul7/CjwEJQO3bko38LzJdEPcbYMy2TxGdW7JDRILcYzGNh9vNGi0r AZs6gXnfpF9w4ghbtWaeSy+GzztoCicHzJDrMJuSrnPWX9BisNQbApcNfUK/tPR4 UyKuJVvEng2syyktIJlpP0JN7xBUBdLPE7/ZVg2MwDsJ+Z2rT1s6hP+MWBnq2ihF keANXxT6n6la/AllAA/b9iI56UGf8SMPQ4PKpJzklEHqySmnNcBTuuBeytiN+eFj vozjTlHrX6XvabiQ5kmg =GW6O -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: http://lists.debian.org/e1vqlol-000486...@franck.debian.org
Accepted wm2 4+svn20090216-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 01 Dec 2013 18:46:26 +0100 Source: wm2 Binary: wm2 Architecture: source amd64 Version: 4+svn20090216-3 Distribution: unstable Urgency: medium Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: wm2- small, unconfigurable window manager Changes: wm2 (4+svn20090216-3) unstable; urgency=medium . * modernize debian packaging - support dpkg-buildflags - debhelper compatibility level up to 8 - bump Standards-Version to 3.9.4 - update Vcs headers Checksums-Sha1: e04d4081dc7bcac19654b2ec423308d69fc72e97 1896 wm2_4+svn20090216-3.dsc b54b4ac1ca6c3ea8b6c9ab8c4f8f928abd78 9425 wm2_4+svn20090216-3.debian.tar.gz 8284102ecbb71ad6922405f7f5be89da96582f60 33414 wm2_4+svn20090216-3_amd64.deb Checksums-Sha256: 6c8153816dbb6f70052bc972264f374ae7a985aed1096f1633a6fe06b29a9fd2 1896 wm2_4+svn20090216-3.dsc 86b6ef6b88fe3b8dcae01c7b57f04a15166a3c4e1d8019affaa94b01c3d18cc8 9425 wm2_4+svn20090216-3.debian.tar.gz 85d8c71eba58564e3c8d8ccd18f82671efdefd62bbf2da541d885c80de9f5fb7 33414 wm2_4+svn20090216-3_amd64.deb Files: 426cb64de1b565f03699d5b0abb11e3b 1896 x11 optional wm2_4+svn20090216-3.dsc 6e1fe4dcfadd49805081c975ad948b21 9425 x11 optional wm2_4+svn20090216-3.debian.tar.gz 1a90d2097c145bbef0835a8326e0249b 33414 x11 optional wm2_4+svn20090216-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSm5x3AAoJEOxkTtbr1QJDpfsP/A5tMOLRFdVtKmrTZdANGIrY wa3L382FaovwoYEi5UzHJ9BB9t30QN3+QTtc2XIbpsWc1L4R6S/cpSFZYSfr/Vrm Mmyd0flK1RpnyXRJBDbWoBU1NQoC8a6SWfpGesTCvJkQ+Vpk29EE6pge7CGgo7W1 43ykhzYqA0U8eeg4rRVj+PV1TMM0FgBY9RuzoD5zmZsY1pqpZJq1crgj3pQvaQYU vCNNJgWrElvKX1Mf+yoK4TYlt3jC0LXPaMWXfEMemXD08CzWJ6zoG86KtLjS9NRl Xk91XbrFgUTlvU4TaqjqsLBYh+GqGnEgBPdlThkk5xNIgVY69Nb7Ba4V/pPZ0fdS 9Y7HOIqglH5zwlyEDgnsKB8RNvVduKWpTjNjSUuW3Zaxuuk3kkzOTjEDiccqG7/B GF5vkxbkumWBSvDZCbf9dzAeHJNsdDiqbR4HRok9tRZPSqsr7gSBN2DIpyLsSf5R OhPoZHvGqtzDhMTn2RSQy87HixfBnBovqKduZHZ+ufP/HYaFxRcuskrjxldQylME Haxtmgc1D9P2NFHHVkr2QgpM2AXxpdDGqHSVlm3puPsfTT4By1W01/i3x93V2/it 8cj01pgnjnT+AWubZeQGVrOhVqy2vH8jgyau7lisyUyhrmsGKZmZ7QbAsLAvdZj0 aPDcb1vEsj5fzRzXxr7I =KCwb -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: http://lists.debian.org/e1vnew2-00059t...@franck.debian.org
Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
* Kees Cook k...@debian.org [130921 17:08]: In a theoretical sense, sure. In this particular case, why bother breaking it when it's a trivial 1 line fix? My original approach was to fix it in libc and do a mass bug filing. Everyone wins. If we want to reject the undefined behavior, we should modify the compiler to reject it. Seems to me it's a bug to even allow undefined behavior. The whole point of undefined behaviour in C is that the compiler/implementor/... does not have to care. Checking every time would make it slower, requesting any specific behaviour would make it slower. (Some argue a compiler might not even reject a program with only undefined behaviour, but that the standard required some program as result, just making no claim about what that program should do). The compiler not warning against it is a shortcoming, but not a bug. Writing a program that invokes undefined behaviour is a bug. And even if the library was fixed, as long as the program has undefined behaviour, every future gcc version is still free to give it any behaviour it choses to. Bernhard R. Link -- 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/20130921190422.ga11...@client.brlink.eu
Accepted gv 1:3.7.4-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 31 Aug 2013 17:33:44 +0200 Source: gv Binary: gv Architecture: source amd64 Version: 1:3.7.4-1 Distribution: unstable Urgency: low Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: gv - PostScript and PDF viewer for X Changes: gv (1:3.7.4-1) unstable; urgency=low . * new upstream release - incorporates the patch for the gv-update-userconfig manpage * bump Standards-Version * improve Vcs- fields Checksums-Sha1: 52f9d1056c3ecd197a14ce031cf0e03926a59d88 1866 gv_3.7.4-1.dsc d5bc11a37136dff69248f943a632544a4036b63f 759287 gv_3.7.4.orig.tar.gz 7d94b04686ce7736738d585bd6d5838223313dfe 14359 gv_3.7.4-1.debian.tar.gz 7fd9329b42924ae24d81c2556559d207ba8358b3 204722 gv_3.7.4-1_amd64.deb Checksums-Sha256: e2e1c95f850220f106ef8457399f052c6f0ea8d358d00d123771829f41579f59 1866 gv_3.7.4-1.dsc 2162b3b3a95481d3855b3c4e28f974617eef67824523e56e20b56f12fe201a61 759287 gv_3.7.4.orig.tar.gz 67fc1e19148fb3202eae36d2e2f9a828cf50ab7fdc894f44c08bdcbc93538641 14359 gv_3.7.4-1.debian.tar.gz 576512e85924513c40fb4caaf26fed8bd5c3c6e75788a148d91dccef6000d7aa 204722 gv_3.7.4-1_amd64.deb Files: d5a8369fc4843a20166075a10a8f6748 1866 text optional gv_3.7.4-1.dsc 80035c43285781b68361acda09ad7441 759287 text optional gv_3.7.4.orig.tar.gz 5c0c175d3acd3c995e8ed8e70919da18 14359 text optional gv_3.7.4-1.debian.tar.gz cf1064e60c1f207c9ff9822523fab8d1 204722 text optional gv_3.7.4-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSIiXGAAoJEOxkTtbr1QJDklMP/2bgOKZ4xymdy2BvtNiRKK/X ALmrYhZ4qoMZ6wXE5X1sypQVngA6uJ9qULUCAy+brOkzLnJOu/+EZsTmTt0BE4uv JhSSyflAk9FDsoxbxAqR4QlyVCpbX0IY1cP3ZUSQg5TtcuqRxWT2KXvQPIY9Y+zc LQGgjnImVXNCZN783EGJWS8CsfmWwLh0uXPMyWVFtxDbyNLV53xsUUSmbk/nMPYe 6kI9Vf/flgQBrhsTgDj4RZi9lbCMrBte+R9OIjGvG+6mn6LKQocw+r7atD4gzoPO TPOQaM56fcSTbFbgUcGmzIAKznT6tezx0MmZMkCs5LoV9mUxKjwHFr1DVWmCEt7j 1Vo4lfzvFk2nvVehRHAnj2bXaaC3BUWwx7RmZllbMewHbhc/bg3GgxmIVNVoiP72 90GxV64fu8qZ1EtrPZ8s8F8PUnT5M/629znWNup5Z4FckGup0HHWhtJ4lfBchWy1 DiJNQswkXEdpGDAoLsolTEHSvHB4vtE+0660MydwTIvScsw/R5zvzg8MDdlpl8LD fxeD/Jqs8c1pE0635rTCnde3S5SM/xKZkcFQheBp5aZ3CZuLR0NXigjcBVZzGRVq pHxDJXdzUrQLLf1GzK16GXO/8nViV4aifrssu6Y5XWbWqQz3mb/d4CiPLXPJdTio Ny+uay6jri5myu395aiP =7oC3 -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: http://lists.debian.org/e1vfsoj-0004xs...@franck.debian.org
Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?
* Paul Wise p...@debian.org [130802 15:54]: In any case, removing md5 support seems like a bad idea to me right now, as older software might not have been adapted to check the other hashes, or would imply breaking the current .dsc and ,changes formats, as the Files field uses md5. We've had SHA1 since before snapshot.d.o data started (2005), I would guess any relevant software would have been updated in the last 8 years. In 2008 ubuntu had Sha256Sums wrong which showed that back then almost not software even bothered to check those fields: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/243630 non-md5sum hashses in Sources generated by DAK were incomplete until the generation code moved away from apt-ftparchive (early 2011 I think), thus only the Files: part with md5sums was the only reliable way to get the list of all files belonging to it. Support for non-md5sum hashes was added to dpkg-scansources/apt-ftparchive with apt (0.7.25.3) released to unstable 2010-02-01, first released with squeeze. So it is not some 8 years. It is more since squeeze that Debian and some of the common tools even produce complete non-md5sum hashes in Sources indices. reprepro for example only tries to support source indices without Files (i.e. md5sum hashes) since 4.12.0 (i.e. since wheezy). Bernhard R. Link -- 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/20130803075234.ga3...@client.brlink.eu
Re: AGPLv3 Compliance and Debian Users
* Howard Chu h...@symas.com [130712 03:51]: Indeed. If you're a dissident fighting your own government, then complying with a license that can only be enforced by a government agency is probably the least of your worries. Indeed. That's why every interpretation of the dissident test I've heard assumes you are a dissident that had to flee his country. If your new host country then has to forbid you earning money with the software you know best because you had to violate the license to not be caught back when you still were at home, then you are caught in the extreme situation constructed to make it easier to understand how ugly some harmless looking restriction can become. Bernhard R. Link -- 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/20130713234247.ga5...@client.brlink.eu
Re: Berkeley DB 6.0 license change to AGPLv3
* Stefano Zacchiroli z...@debian.org [130710 13:07]: 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. For me GPL is like police patroling in the streets and AGPL is like policy getting the right to visit my bedroom at evening to look under the bed for monsters at their discretion. 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. I hope will all agree that the unmodified case does not matter at all. If you modify the software you might get in trouble but, according to my personal ethics, that's the trouble you should have. I accept that I am not allowed to modify some software. But I refuse to call such software free. However, please note that as long as you run the software only for yourself, you don't have any problem. This is not the 1990ties anymore. Not allowing net access is quite an big contraint. Some better definitions might reduce the problem here. But given the way section is formulated I see nothing that would make an exception for something only used by me and everyone else interacting with it only by getting a loging prompt and a failure message when they do not provide my username and password. 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. So if I patch a IRC client for my personal use to also show me some other information (as I do not want too many open windows) and that client contains AGPL code, does that fall under section 13 (assuming it supports CTCP)? Have I lost the right to patch my programs locally in a quick and dirty way embedding hostnames and passwords and logic to access some private services in it without implementing a fake-irc server for that information or some general message passing mechanism? Even if defining the undefined interacting to need more interaction, let's look at some website provided by some of the all-in-one thing. Assume it has some content mangement part, partly showing public information, partly only accessible by me (or if I in this example was a company by my employees). And also a blog with comments (as I think it will hard to define interacting so narrowly that it will not contain that). Now if I want the private part to show me some information from some other source, I am again forced to have split things 'cleanly' on my systems with AGPL. That shift is coherent with the shift in the most common deployment [...] Not every solution can be shifted. If some fly does not allow me to sleep by its noise, I will either kill it or open an window and throw it out. But if I had a cat and that would be too loud, neighter would be a solution (perhaps the second if I lived at ground floor). And if you have a baby, ... There can be no freedom without restricting them to actually have them in the one way or the other. But for such a restriction to be justified, it needs both to be effective in protecting another freedom and not cause greater harm than it brings. In every way I see that you could make the definitions, AGPL will fail at the one or the other: Assume a AGPL program being modified or a program using AGPL libraries to be interacting only via answering HTTP Requests and returning all it's source code when /source.tar.gz is requested and giving proper notice of this and the license and so on. Either the AGPL permits such a program (or any AGPL program transformed into such a program) to be run bound to a private IP or localhost and all user interaction via a reverse proxy or loadbalancer that returns 403 for /source.tar.gz or it forbids it. In the first case the added restrictions are totally useless, especially against the big software as a service players that it claims to target, as those will likely have some loadbalancer doing some filtering anyway. In the second case it the restrictions to my freedom are so severe, that I cannot see how it can do more harm than good. What worth has the source to all the software in the world and the right to modify it, if I lose the right to run things on my
Re: Berkeley DB 6.0 license change to AGPLv3
* Stefano Zacchiroli z...@debian.org [130704 09:24]: 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. 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. With AGPL you are no longer allowed to run the software in this case. I do not see how a software restricting running a software can still be called free. Low quality software modifications are not the best. It would be far nicer if anyone just wrote nice general frameworks for their specific needs and submitted them upstream. But limiting the users freedom to be able to do and finance that is absurd. If you are no longer allowed to make some quick and dirty modifications to make our software work for you, then in the sum it is no more free at all. For people who are fine with the copyleft approach (and of course not all of us are) AGPL shouldn't be particularly shocking. Sorry, once I am no longer allowed to run some software on my computer because I modified it to my needs, then it simply is not free. People still calling that free is shocking for me indeed. 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. And adding DRM to the browser is just closing a long outstanding bug titled please cripple my system enough so that content providers will take my money? Bernhard R. Link -- 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/20130706154116.ga3...@client.brlink.eu
Re: Berkeley DB 6.0 license change to AGPLv3
* Paul Tagliamonte paul...@debian.org [130702 15:15]: Again, why do you plan on removing free software from main due to a change in license? Licenses matter. Just because something it acceptable for Debian main does not mean it is a good idea to have something licensed under a specific license. So removing stuff if their license changes can make sense in many situations. And doubly so for AGPL. (I'll never understand why people consider it free software, I'd not even allow the term freeware for it). Bernhard R. Link -- 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/20130702175730.ga3...@client.brlink.eu
Re: jessie release goal: verbose build logs
* Matthias Klose d...@debian.org [130614 13:36]: Verbose build logs allow to analyse package builds and give hints to more issues regarding the build, especially for the hardening flags. The lintian hardening checks are incomplete, because they rely on the inspection of the generated binaries, which may be incomplete especially for many plugins or dynamically loadable extensions. While I agree that a build log without compiler arguments is essentially worthless, could we please not call something that is not too silent verbose? Verbose is something that uses more words as necessary, while compiler options are neccessary, without them users of the software cannot get help in forums or channels when they have problems compiling the software and with build logs porters can often hardly help if the old buildd log contains no information. Bernhard R. Link -- 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/20130614223601.gb3...@client.brlink.eu
Re: default MTA
* Jonathan Dowland j...@debian.org [130611 18:35]: On Fri, Jun 07, 2013 at 12:45:07PM +0200, Marc Haber wrote: Sendmail has just one more layer of indirection by virtue of the m4 macros. Postfix has most of its behavior hard coded in the C sources, while exim's behavior can be controlled by run-time configuration if an advanced user wants to do things that Debian's abstraction layer was not designed to handle. There are a class of users between beginner and exim expert for which the current state of affairs is not optimal. I don't know how big that class is but I've been in it for ten years. The only class of users I can imagine the current situation not optional is someone being used to postfix[1]. When I remember learning exim I found it quite nice that the config is quite self-explaining what it is actually doing. With postfix the config is just black magic, where one has hardly any chance to understand what it does and how to change it to do what you want to change. [1] And those can simply install postfix and be done with it. Bernhard R. Link -- 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/20130611210523.gb3...@client.brlink.eu
Re: default MTA
* Chris Knadle chris.kna...@coredump.us [130606 14:53]: I'm glad you asked this, because it prompted me to investigate further. This was something I was told was commonly done, but it looks now like it might be a misnomer. I'm not able to find a concrete example of a system that allows SMTP MTA transfers but doesn't allow telnet to the SMTP port. [The instances that seemed to fit the symptoms look like they have more normal root causes, such as ISP port 25 filtering.] Because I had repeatedly been told that telnet to the MTA was a security problem, prior to now I had suspected that blocking telnet to SMTP might be possible via firewall filtering that distinguished the type of service somehow, but after doing some packet sniffing and examining the resulting packet internals I'm starting to doubt this is possible. Actually, it is possible to block telnet (and I've seen some ISPs do it). In unrelated news, using telnet is a bad idea. If you want to connect to some port and see what you get, use netcat. Telnet is not a tool to show things coming from a port but a tool to speak the telnet protocol. Bernhard R. Link -- 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/20130606171839.ga3...@client.brlink.eu
Re: [clang] Report bugs on packages failing to build with clang
* Colin Watson cjwat...@debian.org [130604 15:47]: On Wed, May 29, 2013 at 10:08:59PM +0200, Michael Tautschnig wrote: I think this will likely improve code quality, hence I'm much in favour of this, in particular when it comes to outright bugs. But a non-negligible fraction of the build failures, I believe, are due to the use of nested functions. This could well be considered design decisions when used intentionally (unlike, e.g., [684508], where I have already filed a bug). I'm not sure whether upstream will be very keen on such bug reports? clang.debian.net lists 39 instances of these, though I think the buildd is a bit behind so there are probably a few more. At least one more of the 432 Not categorized is also due to this missing feature in clang (reprepro). As clang seems to gives quite misleading error messages in this case, I'd not be surprised if there are some more. https://lists.gnu.org/archive/html/grub-devel/2013-01/msg0.html Those arguments seem to be mostly related to tampolines, which is mostly an argument against having pointers to nested functions. Bernhard R. Link -- 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/20130605194043.ga3...@client.brlink.eu
Accepted reprepro 4.13.1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 02 Jun 2013 16:49:21 +0200 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 4.13.1-1 Distribution: unstable Urgency: low Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: reprepro - Debian package repository producer Changes: reprepro (4.13.1-1) unstable; urgency=low . * new bugfix release - fix bug in restore* commands not doing anything if the last package is not affected - fix build-needing to support *-any architectures - fix name of per-component udeb Content file names Checksums-Sha1: b84e92d4814573b38f57a785ab87c4ba75d7d186 1917 reprepro_4.13.1-1.dsc 7c5bcb1092f23ba6d45a741cd9d9a69fb0f6ec6b 676265 reprepro_4.13.1.orig.tar.gz 8d894fd2ac385edea2bd2ba4a1eb061ae7083aaf 12682 reprepro_4.13.1-1.debian.tar.gz c82d970f6fb25b3deeb8ec85c54baaa7ed0e771a 514508 reprepro_4.13.1-1_amd64.deb Checksums-Sha256: d3939e1d1904cac72ab4747c2eb410e6961c2109fae4378473207360476045bd 1917 reprepro_4.13.1-1.dsc 45c773fe226e7420eee7773a378f71ee71f39bb5e3ef928cac6c4f578de2fe34 676265 reprepro_4.13.1.orig.tar.gz 0d24587b1dfc724da4748842bfae1e29557f67adbf1b2d473950aaab74a393e9 12682 reprepro_4.13.1-1.debian.tar.gz 638ab79279a350c6a9b16c1c1e244008fb56ed408dff188fa4542c84ce00dd73 514508 reprepro_4.13.1-1_amd64.deb Files: 7e363120977babb47432fc585f5e6df2 1917 utils extra reprepro_4.13.1-1.dsc 75d275d73906f8203a90140658fc390c 676265 utils extra reprepro_4.13.1.orig.tar.gz 35a80eef9c484f36a01224657c7d431e 12682 utils extra reprepro_4.13.1-1.debian.tar.gz 2716e7eae9ba80b5b1d79fa994fb1048 514508 utils extra reprepro_4.13.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRq4ivAAoJEOxkTtbr1QJDhXIP/jqS+y/ddUwSSDBDarPKjun6 3471sL0H0kxJccwEDUWUU55IqFkTxyXgri3kRsgjxIvqT6l90bwqn2LIhePoAfEy nJpMVvYec6djaaQI/0lKDa3pR3z49PA1ku9tr4HjOxyMnZwH1bwjq6jXRr7kwBGO vtpQ3sGPHKjU0AxZ23aU8ShlLbiWf7Khf2EXuW8nyUhumwlaPAsNZE5a0RDfyMDF otN6PlcoUqds0TqYVy0vSOqAwdzJoyIWznvgl22Jl+x0uNKDjtg8MrbmMmNSnpHC lt0n+PFbMeIsGvselrEOkaXH0oqtTMehLxmLyReyE5EhkIrwGvQTI4GDVchRgbtr wr9JImJQQTNtgqbX+pf7IZK85zBxNxek/qa/9k1wHCuJ70X/Y+oM4faBhqOrAYOr IJzJayPCEluN+z97S/5pqyTvC0473bTlAHE2sQ4msd5WbdT8Kq6hsZyCiNPiRVd8 EAI1H80e8ir3IUAfv1QnBXlOKm2rTCv7t2VSKKC5C+aEncPj7zOpMwteJ1bqiumV T20ZmkovyPymQ2GrnldXnyJ8XXyLaL+8vK6IQb4Cx8XM+1tZYlKMpawn3U/9ntKM h8twMlJGsN7OQmxSBSKO1lX3TiTyKEY6JTp0G55TruO4aLGn3msf62Qgw3hAdLit DHMGiqFMVxUYDbbG8N/L =pLgR -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: http://lists.debian.org/e1ujdk9-0004sl...@franck.debian.org
Re: default MTA
* Chris Knadle chris.kna...@coredump.us [130529 08:29]: - Exim configuration is more human readable than Postifx's, IMHO. Postfix configuration is concise but terse, and there are typically blocks of options separated by commas that doesn't easily allow commenting on specific config options. Configurability is an important point. Having had to use postfix lately I'm quite suprised anyone voluntarily uses that thing. Postfix feels like some ad-hoc configuration gone absurd, by only making special use cases configuable and then misusing those options for other things. Together with this splitting in many little programs which all lack most of the information, configuring postfix is a large puzzle and any advanced postfix configuration (even from the official documentation) looks like McGyver was out of duct-tape but had to build a nuclear reactor from kitchen parts with only the transparent tape for office use. The only positive thing you can say about Postfix' configuration is that it might be better than sendmail's. Bernhard R. Link -- 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/20130530091105.ga3...@client.brlink.eu
Re: default MTA
* Marc Haber mh+debian-de...@zugschlus.de [130530 12:39]: While I don't consider postfix as bad as you describe, I tend to describe Postfix as the menu in a better restaurant: A relatively small number of sophisticated dishes which you can choose from, and if you like them, you will be perfectly satisfied. If you want fries instead of plain potatoes, you're basically hosed. It's not that bad. Even the postfix kitchen can make fries. The tricky part is having one person served potatoes while the other person asks for fries, because the person putting those on the dish is not allowed to look at the order so they cannot determine from the drink whom they are making the food for. You need to employ two of them, one doing potatoes and the other one fries, but the waiter is not allowed to chose which kitchen the order is sent to, so you have to tell the waitor to write the order in a language the kitchen clerk cannot read, so the kitchen clerk will pass it to the person responsible for reading obliterated orders and this person you can tell it either give the order to the kitchen doing potatoes or the kitchen doing fries depending on what is wanted. Bernhard R. Link -- 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/20130530135531.ga4...@client.brlink.eu
Re: parsable copyright format 1.0 (jessie release goals)
* Sune Vuorela nos...@vuorela.dk [130512 12:43]: It is too much work for far too little gain. What *is* the gain? What is the gain of copyright files? One big gain of a copyright file is the act of doing it. For software to be distributable every copyright owner has to have given his permission. To know that you have all those permissions, you first need to know who those people actually are. It also documents our reasonable exercises to reach our believe that this is distributable. I'd guess in some legislations such efford can make the difference between just distribute it no more and pay for every copy that was made. Bernhard R. Link -- 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/20130514212524.ga3...@client.brlink.eu
Re: Merging / and /usr (was: jessie release goals)
* Marco d'Itri m...@linux.it [130509 16:03]: So, please let me know if you have some technical objections better than it's an hack. Having a seperate / means you have an instant rescue image that has just the right kernel and tools you need to repair the rest of your system. You also have one small filesystem with all the important stuff like /etc in it while the boring large distro stuff is in another partition. You also have a partition border between most of the random stuff and the important stuff. All those are real advantages that people care about. A simple I do it differently or I do not care from your side is hardly anything someone can counter with technical arguments, so you will not see many. Bernhard R. Link -- 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/20130509143822.ga4...@client.brlink.eu
Re: Merging / and /usr (was: jessie release goals)
* Roger Leigh rle...@codelibre.net [130509 13:34]: The assumptions here are that a separate rootfs decreases the chance of breakage, and that you'll need the rootfs to perform the rescue. No, the point is that having two file systems reduces the amout of breakage you get. All the important stuff is in / while /usr is mostly static data easily (at least outside /usr/local, and even there more likely than say /etc) recoverable or not that important if lost. Also with the tools in / you can usually repair problems in /usr. There is just the right kernel and just the right versions of all tools. You can do most of the stuff with some rescue-disc, if the versions fits. But too often there are differences. And getting some other tool it misses means you need to either install it in an ramfs and hope you do not need to reboot or you need to have some spare partition on the hw left. And you do not have access to your fstab. While each of those problems is managable alone, they sum up. Each adds to the time you need. And time is often something you do not really want to spend in case you have a problem. And while there is no proof that when having one small and one large partition, the small partition is less likely to fail than everything in one large partition together, both reason and experience demand that this point is quite more than an assumption. Regarding rescue, the initramfs has a rescue shell which I've found to be just as useful as single user mode. Once it has mounted the rootfs, you can chroot into that and do whatever you would normally do to rescue /usr. [Assuming a separate /usr.] If it doesn't get as far as mounting the rootfs, then you'll need some rescue disc in any case. I find the busybox shell to be just as effective as a rescue disc in most cases. rescue /usr in a seperate / + /usr setting usually means making sure it can be mounted again. (Or to transfer data elsewhere, which is also much easier when your normal network setup is already available). In the case where we're mounting /usr in the initramfs rather than having it on the rootfs, there's no practical difference to the current status quo (and this is intentional). The only change is that we provide the guarantee that /usr is available before init starts. Or in other words: to make essential functionality not available if /usr is broken. Bernhard R. Link -- 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/20130509150537.gb4...@client.brlink.eu
Re: jessie release goals
* Wookey woo...@wookware.org [130507 23:31]: The tradeoff is: 1) (Move _all_ headers to /usr/include/triplet) * Much duplication of installed headers * Only one system include dir, which fits current build-system expectations Which would also punish the libraries getting headers correct while making the low-quality (or obsolete) stuff the norm. Since C99 there is hardly any reason left to have headers differing with the architectures. Bernhard R. Link -- 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/20130507230831.ga5...@client.brlink.eu
Accepted ratpoison 1.4.6-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 06 May 2013 19:40:28 +0200 Source: ratpoison Binary: ratpoison Architecture: source amd64 Version: 1.4.6-1 Distribution: unstable Urgency: low Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: ratpoison - keyboard-only window manager Changes: ratpoison (1.4.6-1) unstable; urgency=low . * new upstream release (almost identical to rc1) Checksums-Sha1: 3166208846ec2514470bf17cd492f3ea4f46f254 1993 ratpoison_1.4.6-1.dsc 8ee1157c799e2a382b59c45a1aca95b5111977df 344656 ratpoison_1.4.6.orig.tar.xz 291417b013a5f6075c8df5641626de40c4848b49 17681 ratpoison_1.4.6-1.debian.tar.gz 8cb8076e14e2271da36986d5dccc347f86864d50 211322 ratpoison_1.4.6-1_amd64.deb Checksums-Sha256: 7df4cea0cd6e5ccc1da3b9256ce21001a44aeb33a4c9b87c55df0a5fdce89a75 1993 ratpoison_1.4.6-1.dsc b9b181dd2aa08508cb3c3d40aa670ef179f7d11bb439e6d7ea05ea3d1a82956c 344656 ratpoison_1.4.6.orig.tar.xz 64268489deef05885796b049a310ce2423db50bd58f3453ded72bc9467879d8f 17681 ratpoison_1.4.6-1.debian.tar.gz 9920e9dc6f275259cc4ee44a8ad61ca08616c1ee1ac24d1e1f8804be008aea92 211322 ratpoison_1.4.6-1_amd64.deb Files: 360d9977fd72daac0d6f2d4e0fe46e44 1993 x11 extra ratpoison_1.4.6-1.dsc de6dcf24a9c2e04d77fef8ed884e2f7a 344656 x11 extra ratpoison_1.4.6.orig.tar.xz dd1685457cda849b87e0e33a83b71d53 17681 x11 extra ratpoison_1.4.6-1.debian.tar.gz 98ed5ae5470f8610d5e7739fde88454c 211322 x11 extra ratpoison_1.4.6-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRh+z3AAoJEOxkTtbr1QJD9VIQAKoR45OSWU3tpVWgn6yoVM88 2qJNWJJSqZRDvrLC6MDJtyy8tQJhcmRVUkcjdtX/pSLWNUHqZISzeECK6Tto30Xv WaHvRzyR/JokHci2KRs4wYInOXZwCivnltSDzRFvZSR2eqGDoLi5Zp0jwK/RoDp0 6BiRDMo37a6r+oQmbbXYtx7ql893ZQg5hohIYaizLJbJBG7qTDpSZJLjibC5TqvV KvR2xDkB1hNqR3z8LEeck78+uTxnPcFLOg8niFn4sh6Cv6KxBtjOQN19WhwdbEcs 3/7hJUvi+VAfB710nlhzDLy/RstQ4XsMUp5Y1cQAmZRl47pEdPxjttHxC2/zT4Vb dq9uSRufIUOJN8miv33awBHNSNQpzwCrZKAHtKH4l0fpWixd1NABQm0fgJykDUMW EG0Nk8MSD4omd7zXEjxtJhVMAoRBsCb015N5EEzobtrJd44j71G164YH8oPVGCsu 7jrKLF2teYqM0CE/JOiUzwYwI9I/enFY/DipAtUtmvbvY3yYAu8xpGaf8YPXcgNA ylYDlsNcLBJQPJ57/qQhHFCPU3BuXZJ9/oKpWO8irsNTO5sOI6YuUO8bmH7UPsVm vZcmByl/zGvgDP+O2rrg3bo6xf1cv6bb/7q/L9K6Wi5tYRBHpAmy6By3+MGZKdHQ 8rhXbQGjh3zPcaYnH0YS =acr8 -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: http://lists.debian.org/e1uzpkz-za...@franck.debian.org
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
* Holger Levsen hol...@layer-acht.org [130502 12:28]: People do this all the time: upload packages built against local packages, experimental or even on Ubuntu to Debian sid. /me shivers. This hurts. There is no reason not to rebuild in sane environments. Can we please fix this for the next release?! I'm not sure the cure is not worse than the problem. Apart from the big problem of making it even easier for people to upload trash without testing it (both wasting buildd resources and lettings users install broken packages which any trivial testing would have catched, from which I've seen far too many), reducing the buildability of packages is a cruical problem for freedom. If we step towards rebuilding everything in a highly artifical environment, it should be made clear that a package having missing build-conflicts or any other bug preventing it from being built on a real system should still be important bugs afterwards. Once we drop that and only give people the right to modify the software we distribute but no longer the possiblity to do so on their own, the Free we are so proud on gets mood. Also build systems tend to degrade quite heavily over time and get more and more specific. In some years we might not be able to switch to some other builder tools as too many packages depend on the specifics of the ones we currently have. Bernhard R. Link -- 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/20130503171134.gb3...@client.brlink.eu
Re: git as a source package format?
* Daniel Pocock dan...@pocock.com.au [130501 21:28]: Would there be any hard objection to a source package format based on git-bundle? I think a git based source package has quite some problems. - failing to properly make changes visible While you can express every history-graph in git, that is not an advantage. Changes relative to upstream sources found in a Debian source package should not only be present by recording history, but as many people as possible should be able to see what is actually changed in the package, and to reuse those changes elsewhere (either as upstream or sidestream). Debian is not like the BSDs[1] that just import some source into their CVS, make modifications at will, sometimes merge a new upstream version and some years later the only way to see what they changes is doing a full diff and hope you can isolate some of the changes. We do not fork but want the changes we need either upstream or also useable by other. Other distributions and users not using Debian are not our enemies, but partners towards a general advance of free software. While you can use git to keep changes in a way to make them reviewable and ready to transmit them elsewhere (git rebase -i is great), if you have that information ready then generating a 3.0 (quilt) package is trivial, and having changes expressed the same way in different packages makes it easier for everyone to find the information. (At least any other format should come with a way to support being show at patch-tracker.debian.org). [1] They might have changed. It has been a long time since I looked. - hiding stuff in obscure formats While a git-bundle is a format that is not that complicated to use once you are used to it, even the average git user will rarely know how to handle it manually. That means people not having the Debian tools available can hardly do anything with them on their own. Additionally needing to have some special VCS installed to look at a specific program can be a huge burden. While git got quite a decent pervasiveness now, not everyone has it and with the next hype it might equally fast being gone again. At least using such a git format should be absolutely forbidden if upstream uses any other free VCS. (I've seen packages in Debian that used one VCS, having upstream some inter-distribution working group that used anyother VCS that finaly was based on some big comercial player that published the free version on yet another VCS. That's annoying.) In other words, dpkg-source would extract all repository history (or all of the branch used to build the package) using the git-bundle command. The bundle file would then be uploaded to the FTP server instead of a traditional source tarball. A slight variation of this idea is that the repository would be cloned into a temporary bare repo, and that bare repo would be tarred up and the tarball would become the source upload. - legal problems if you have all the history it is practically unreviewable for undistributeable stuff, and if that stuff is old enough, it is usually quite hard to get it out of the history. (There is filter-branch, but one does not take such an approach lightly). This is not a big problem for having those at alioth or other sides (You'll have to ask a lawyer, but I'd guess the ill effects are either limited to Debian losing all their money or only the team/uploader it is in. And likely alioth admins can just remove the git repository there in case something is found or someone sues and thereby reduce any penalties perhaps even till none are left. But the source packages are found on DVDs and mirrors all over the world. Many people help us distributing Debian. We owe them to do out best to keep them out of legal trouble for doing so. And source is what people need to actually make use of many of the software (especially GPL). People providing stuff based on Debian (be it pre-installed computers, appliances based on Debian, distributions based on Debian, ...) need to have the source ready to do so. If they use Debian binary packages, just keeping the Debian source package is the obvious way. Unless we switch to a source format where those can no longer be legally distributed. Then again, some of that behavior could be achieved by creating an `apt-get vcs-clone' function to read the Vcs control fields and make a clone for a traditional source package's repo. sudo apt-get install devscripts debcheckout source-package-name Bernhard R. Link -- 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/20130503165022.ga3...@client.brlink.eu
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
* Russ Allbery r...@debian.org [130504 00:32]: The way to ensure that builds in non-clean environments work properly is to devise a method for testing them, and to do those tests on a regular basis and turn test failures into bugs. Noone is speaking about non-clean environments, but only about non-minimal, non-artifical ones. Trying to get at this testing indirectly by putting conditions on initial archive uploads doesn't really accomplish the goal. It's a very random and scattershot way of testing that already doesn't work for any of us who use pbuilder and cowbuilder already. That's why I think maintainers should not only build in pbuilders and cowbuilders, but give their packages some actual testing. Bernhard R. Link -- 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/20130503230506.ga18...@client.brlink.eu
Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
* Ben Longbons brlongb...@gmail.com [130425 18:27]: The problems with the way Debian does it are: - debian/ is a subdirectory of the extracted source tree. Why do you think that is a problem? - Because of the above, debian/rules tries to know about backwards steps. What are backwards steps? - There are too many arcane commands that have to be called. ./debian/rules build fakeroot ./debian/rules binary Everything else is mostly convenience wrappers. - It's not obvious how to modify the patch set directly. modify upstream files, call dpkg-source --commit - There is no attempt at managing multiple source versions. First you say things are too complicated, then you complain about some obscure missing option I never found any use case for. How Simple Tasks are approached: Given a program that is not packaged for Debian and is not sufficiently useful to the general public to be worth the maintenance burden, install it such that the package manager knows about it. Debian: - checkinstall is buggy, quirky, and has no upgrade path. - I still haven't figured out how to do this easily. Based on the 'hello' package, which is the simplest possible package, this requires writing a hundred lines of voodoo. A random sampling of existing package I've looked at agrees with this as a lower bound. You can't have easy and high-quality at the same time. Most of the tools used for official Debian package have the minimal complexity needed for some quality. Apart from having someone write tools to simply create private packages there is not much that can be done here. (and from what you describe for Gentoo, I do not really see how a dh_make ; vim debian/* ; dpkg-buildpackage is more complicated than the Gentoo case). Given a completed set of package information for such a package, distribute it in a way that is easy for others to install. Debian: - Still haven't figured out the right way. There are many ways, because needs are different. - I did find the 'dget' command that does some things. How was I supposed to know about this obscure command for a common use case? dget is simply a convenience wrapper. Just have three files to download for a source package. Anyone can click at three links easily. - You probably have to ship the whole huge .orig.tar.gz file, even though it's available on the internet under a different name, or even if it's really a git snapshot. Sorry, but this is bullshit. If you want to make it easy for users, put the .orig.tar.gz there. References too external resources will always go stale and are and endless source of user frustration. Given a program with a buggy upstream release, apply a patch. Debian: - After trying to make local changes, it said: dpkg-source --commit - But it is tedious when you already have a full patch from upstream. patch -i patchfile ; dpkg-source --commit I thought it was about users knowing the basic command line utilities? Given a program with buggy Debian packaging, revert a patch. Debian: - no clue, it keeps trying to readd the changes and it's not obvious how to wipe the working tree. The very easy way: just revert the change and add another dpkg-source --commit The direct way: revert the change, remove the line from debian/patches/series The complicated way: use quilt or some other high-level tool. Gentoo: - Assume that you're competent enough to get ahold of a patch. - Add the patch to files/ (which is shared between all versions of the package, though you can of course use a different name). - Add the filename to the PATCHES=() variable, remanifest. Gentoo: - Remove the filename from the PATCHES=() variable, remanifest. Yeah, because every patch can simply be removed without any effects on the other patches, you can just apply any patches you need to the version you need. And if it doesn't you can just apply manually, fix it and produce a new clean patch. NOT, seriously. That you can just do stuff in your working directory, build and fix again iteratively in your working directory and finally have some working package is in my eyes one of the biggest strengths of Debian's package format w.r.t. low entrance and making it easy for unexperienced people to use Debian to meed their needs. Gentoo: - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest - Typically, the source URL will automatically change based on the version number. If this is not the case, it is very obvious to fix. your gentoo solution is the equivalent of copying the debian/ directory around. In conclusion: The current Debian way is complicated. The Gentoo way is simple. This is not tied to the fact that Gentoo is a source-based distribution, although that does encourage the right mindset. In
Accepted ratpoison 1.4.6~rc1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Mon, 01 Apr 2013 20:02:07 +0200
Source: ratpoison
Binary: ratpoison
Architecture: source amd64
Version: 1.4.6~rc1-1
Distribution: experimental
Urgency: low
Maintainer: Bernhard R. Link brl...@debian.org
Changed-By: Bernhard R. Link brl...@debian.org
Description:
ratpoison - keyboard-only window manager
Changes:
ratpoison (1.4.6~rc1-1) experimental; urgency=low
.
* new upstream prerelease
+ obsoletes most patches
* improve remove{left,right,up,down} extension to only
resize frames instead of removing them where possible
Checksums-Sha1:
99dd1940c0215d7bcb76ed6b38641b8e13b4c1e2 2021 ratpoison_1.4.6~rc1-1.dsc
d190304f627554b211690a10af9760d34015a28a 344424 ratpoison_1.4.6~rc1.orig.tar.xz
2a06ba74cd50868940deed496c33663952695a28 17627
ratpoison_1.4.6~rc1-1.debian.tar.gz
531af77cea58693e45976e88a498c090259a5818 210970 ratpoison_1.4.6~rc1-1_amd64.deb
Checksums-Sha256:
9669d1946626cecf3eac7381896b820f38fc18479edd1099f6cadac2de241139 2021
ratpoison_1.4.6~rc1-1.dsc
f44f9561318c5bfe9651133f162dd0bc04be28e15baab30966e75ea6dc6b6986 344424
ratpoison_1.4.6~rc1.orig.tar.xz
f7486c7058b7b04191e5b7c2f5e5bffbb95739d5f30f17f42a9a5f77a8191dc9 17627
ratpoison_1.4.6~rc1-1.debian.tar.gz
dbf1e5c0950037a49e4f2f37619d76d351b623313f51427609b4c5b512724712 210970
ratpoison_1.4.6~rc1-1_amd64.deb
Files:
3c3bf0c0cefdad6d9c9e8e99aef26781 2021 x11 extra ratpoison_1.4.6~rc1-1.dsc
72f0b02c662a8adfb8e76e75883db25f 344424 x11 extra
ratpoison_1.4.6~rc1.orig.tar.xz
2bb62f1993aa73d0f13208a21264f168 17627 x11 extra
ratpoison_1.4.6~rc1-1.debian.tar.gz
e9850db1518c0b1a979eeb5b51b20975 210970 x11 extra
ratpoison_1.4.6~rc1-1_amd64.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJRWdeZAAoJEOxkTtbr1QJD1p0P/0kBod63kNQnuPt0oXAzVG1v
TpYd4wx4eOEQ+ekWVTOI7OtTmmGHbF9AefgWfjuVpgb6eY/0VcW8IRpt0DBVz4P9
iFGz5kqMc6Madu8aAICyNFH1TDVIHNQR9UqpEdR9FeIRTflL96wGQHYzIN1qPBGd
eTkJVLdc+oc0Ll3Fg+POV20U9h6ivSjqz1eYdrMIS0zQ6yqKa1Po26QepVsEsZew
jPTEo4Na6V2c8xIQp9sP7yQVY03vYBmidiNEFKYLCnTAwd8O0OvmDqVFnO4CUPRV
Y2HOq5PYEMDlW7l5C7OnOrH2bz1KpLU219enpVzY+W5Q31L1kpMpngn2JTvqmTsB
0MwQtcbCYreE8vfSt+3L+tFiR5c+0J28CN5Vlt6cuwFdiw08rQwx3/AKov8J8rql
NaiO9PWi1CDr+1i/emvuxgHRqYXy7UQx8u5HuFZSYAOgoOTkvkcWG3SHzxEoyCm8
yyVp+XqEr7U9l3Pr8enB8pUf1l2x90b5dkLbvcXNbuOHeBMt6V6jU3YL4mPMSN02
OAjcxOx5eySd6g2VlKbSiDNOPAKecU/b454wZmt/RdvZQDbd0jUIajKxtdErbPaw
tZvQVrwwsFXAEtEkpqvcLOmTwk44L+sDIYJQi5BJ+RSfkpqnzWGJ6NEF6Xu7tvU6
ZPEoGcLHtB9+rWJhJJc3
=6AjK
-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: http://lists.debian.org/e1umk03-lr...@franck.debian.org
Re: Go (golang) packaging, part 2
* Russ Allbery r...@debian.org [130201 21:38]: If you want bleeding edge, then you are not a normal user and you certainly aren't a system administrator that wants to keep a controlled system they can reproduce. Speak for yourself. I've been a system administrator for twenty years, and sometimes I have to deploy bleeding-edge code in order to accomplish a particular task. You can do that in ways that also give you a reproducible system. Using Debian packages is a *means*, not an *end*. Sometimes in these discussions I think people lose sight of the fact that, at the end of the day, the goal is not to construct an elegantly consistent system composed of theoretically pure components. That's a *preference*, but there's something that system is supposed to be *doing*, and we will do what we need to do in order to make the system functional. Different solutions have different tradeoffs. Obviously, I think Debian packages are in a particularly sweet spot among those tradeoffs or I wouldn't invest this much time in Debian, but they aren't perfect. There are still tradeoffs. (For example, Debian packages are often useless for research computing environments where it is absolutely mandatory that multiple versions of any given piece of software be co-installable and user-choosable.) Of course there are trade-offs. For every rule, as sensible it might be, there can be a need great enough to ignore it. Using software not properly packaged is not so different from modifying files in /usr/lib from the distribution, compiling passwords or other hardcoded stuff directly into programs, using binaries you have no source of or even using those and patching the binary or many many other things you can do and sometimes you have to do. That there are no guidelines that are absolute and that may not be better ignored in some cases does not change that in general they show a useful path that leaving without a good reason is no good idea. And a only use distro packaged software is a very useful guideline. There are so many advantages in this that you cannot get this with distro packages is a very good argument against anything you cannot get this way. There will always be a case where there can be a more important argument pushing the scales in the other direction, but at the end of the day, the normal system administrator wants one package management tool for all their software (or at least as few as possible) and as few copies/different versions of common code (aka libraries, modules, ...) around as possible. And most of the features for developers are just additional nightmares for the administrator. Bernhard R. Link -- 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/20130201223958.gb3...@client.brlink.eu
Re: Packages with incomplete .md5sum files
* Andreas Beckmann deb...@abeckmann.de [130115 11:20]: On 2013-01-15 10:29, Julien Cristau wrote: There's no requirement for md5sums files in the first place AFAIK. How are incomplete md5sums worse than no md5sums? If anything this stuff should be minor IMO. If a package is shipping no .md5sum at all, it will be created by dpkg at installation time. A partial .md5sum however will not be completed. This hides some shipped files from debsums, defeating its purpose. That depends what the purpose is supposed to be. Having debsums by default create fake .md5sum files for packages not shipping them defeats the purpose md5sums is most useful for: to check that the files in your filesystem are correct and where not corrupted by faulty hardware. (As in my experience almost all of those problems happen when writing to the disk (by faulty memory, faulty busses, overheated mainboards or CPUs) and not to content on the disc itself). So while incomplete .md5sums are definitely not nice and worse then complete files, I do not see how that could be worse than not having any .md5sum files. Bernhard R. Link -- 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/20130115215008.ga3...@client.brlink.eu
Accepted reprepro 4.12.5-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 31 Dec 2012 17:12:47 +0100 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 4.12.5-1 Distribution: unstable Urgency: low Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: reprepro - Debian package repository producer Changes: reprepro (4.12.5-1) unstable; urgency=low . * new bugfix release - multiple documentation improvements Checksums-Sha1: 0422c92d962be526e7e7b923a4154b8d6cffaa11 1917 reprepro_4.12.5-1.dsc ce11d189b78b35268619b2c2c5f75e7868d03829 650425 reprepro_4.12.5.orig.tar.gz fe7db13017b3b63881f3757fd82815466f55d3bb 12444 reprepro_4.12.5-1.debian.tar.gz ac4f1416d9dc5ef453ea764cfa16cef24e5495c7 507052 reprepro_4.12.5-1_amd64.deb Checksums-Sha256: b8784a7802f6d2f0f6fde1157a4e9247db578d9890f7ffe13bdcb35069d5e741 1917 reprepro_4.12.5-1.dsc 29f768d101e03bd4caea36f1088d62a4f69d11f11685c72444772a88ff58ba7d 650425 reprepro_4.12.5.orig.tar.gz c48b2c92a9faef14b374298024c7e4b6dab5287a6663a1cca96c2efcfab72f23 12444 reprepro_4.12.5-1.debian.tar.gz ec523c37424a5b4e7e99f6d832d57416d3f09b110b856ebcd496ebeceefab485 507052 reprepro_4.12.5-1_amd64.deb Files: cfb323ac7111002a0fbf60fa94c1de95 1917 utils extra reprepro_4.12.5-1.dsc 5caf7b45a13e7f0343a397e507786652 650425 utils extra reprepro_4.12.5.orig.tar.gz 553747c235b04615842ed9493438c23f 12444 utils extra reprepro_4.12.5-1.debian.tar.gz 0dc72e0eb41e87ce8f6a30edff9a108a 507052 utils extra reprepro_4.12.5-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQ4rIbAAoJEOxkTtbr1QJDpBgP/2ZgzS+rE2sLAc0RWUuwxcnn AmahKhgXqOrQ7hV+Wpo6wrffirx/bHLoS+UPb0uI2LmWAyf6hzJ/ax5N3XxNwQF3 i+qvOQqBrt1Ib73pDHrrhascgXG0M6CqqRBCYHq8E+o1eQ8Hs2k7MNxER0DUBFzp jhjC8IYI0fpIehSYn2fnttBA9yqhejttvo81Ic5WvGRio4rWR1VfGDkM3E4R+lSk iX1XP+dDfzOBB5QUx+ixnR3O4y3HiYiyngtYffqxtm3Y4rYf2dt6D8X9QJL1qnzD w9QxA2oKZfhpmSWTmi6oUAEWZGEmJjr/gwk42IU43r82es0IdMzZAwbHjaDtxYTn twpg0oECcdxI6Ylc59QZyYwTZcz9bcnOaEMjiUeNvU1jw3CiIu7MkFINTe4lEMe0 0CGVQ32YVXSh0HPPO0gZUycWqXvxgvyPc3jpAhiewLiTu0+81wG2VaDWOunSJsFh wsuLk3xdiiuhEVBkSUdOZoDtoihaSz+uFQfETZq8epJPscVWKsYLf8PvcHtjhp+x y/0DYK/1OwCQOdcB/68LUiKYAier9pSvHoSwcD60qMwZ1gd8c4v6Xl2OHH+LJzs0 2VuGeUZf+jqmwDCppC/kH51OUXFFC/D7XCbAOdxdjwkeRk1BFjbS2FfIR33bRZsf Lcf7HawNBq8ZW6qSVTNm =1Jx5 -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: http://lists.debian.org/e1tsh2j-hx...@franck.debian.org
Re: [RFC] Go (golang) packaging
* Michael Stapelberg stapelb...@debian.org [130102 09:13]: Given that we already have python-* and ruby-*, I’d find golang-* more consistent. We also have lib*-perl. Ruby seems to have changed recently from lib*-ruby to ruby-*. (Does anyone know of the reason that changed? For I only remember all the reasons for the old naming scheme and see no reasons in favor of the new) Which specific tools/places do you have in mind that have to truncate package names? Most GUIs will truncate depending on the size of the window. (and of course just “codesearch” for the binaries). I assume s/binaries/sources/? And I'd suggest to just not policy the No, I really meant binaries, as in “cgrep”, “cindex” and “csearch” in this specific case. And what is the name of the binary package those programs will be in? Another question: Have you considered asking for a archive Section for those packages? I guess with no special section yet all those packages would be section libdevel as they are for static linking only, wouldn't they? As pabs has pointed out, I did that, but the general rule of thumb is that we want to have lots of packages first and an archive section second. Too avoid packaging mistakes and to have the wording ready I'd suggest to already prepare the wording (I guess in the section later will be everything that is is now in libdevel plus golong toolchain packages, while everything providing programs to be in their respective section). Bernhard R. Link -- 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/20130102090022.ga5...@client.brlink.eu
Re: [RFC] Go (golang) packaging
* Michael Stapelberg michael+deb...@stapelberg.de [130101 14:45]: Furthermore, the package names should be e.g. “golang-codesearch” for the library code.google.com/p/codesearch Please also consider codesearch-golang. Especially with longer package names not everything can show the full name so the beginning should be the more important information. (and of course just “codesearch” for the binaries). I assume s/binaries/sources/? And I'd suggest to just not policy the source package names at all (as there really is no one rule who fits them all and there is no reason to have a rule there at all). Another question: Have you considered asking for a archive Section for those packages? I guess with no special section yet all those packages would be section libdevel as they are for static linking only, wouldn't they? Bernhard R. Link -- 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/20130102071555.ga3...@client.brlink.eu
Accepted reprepro 4.13.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 01 Jan 2013 10:59:34 +0100 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 4.13.0-1 Distribution: experimental Urgency: low Maintainer: Bernhard R. Link brl...@debian.org Changed-By: Bernhard R. Link brl...@debian.org Description: reprepro - Debian package repository producer Closes: 469656 495302 696322 Changes: reprepro (4.13.0-1) experimental; urgency=low . * new release - add signing hook to replace how Release files are signed (Closes: 469656) - add outhook to be called when things are changed (Closes: 495302) - add lsbycomponent command (Closes: 696322) Checksums-Sha1: 9f4f53958a25127f65794829aa38a38214cdd784 1917 reprepro_4.13.0-1.dsc f9bd483253b59e39638c31fc6ab6235c0e386e77 662014 reprepro_4.13.0.orig.tar.gz 3d8792213d7ff5fae7336c778bee59699cc6c984 12723 reprepro_4.13.0-1.debian.tar.gz b1dd8f5a0b96a75f8b1a78eab63eb3fbed36eff8 514972 reprepro_4.13.0-1_amd64.deb Checksums-Sha256: 1a88b70b09446d0112138378c48c03a7517382d0da9dd1b6d85e51ab43f2769a 1917 reprepro_4.13.0-1.dsc c7504b4d5013b018c1027b7302106dfb3f4b4f88e6e271f1f7cf86c9abec42ff 662014 reprepro_4.13.0.orig.tar.gz e567529546688dfc44fb47381a737b2a0af815464af79f14519e956fb9ed03da 12723 reprepro_4.13.0-1.debian.tar.gz d0221b944a2821925f8573f12b6b1b27924de511e3021c15400d98333b4ca0fe 514972 reprepro_4.13.0-1_amd64.deb Files: d12cae39abf931b978e59d6f4710062d 1917 utils extra reprepro_4.13.0-1.dsc 8dd6aa8a99447e7b0b040ac4aea3416d 662014 utils extra reprepro_4.13.0.orig.tar.gz 3ec2e26ab83a689cd06380b2b518094c 12723 utils extra reprepro_4.13.0-1.debian.tar.gz 6af9626afa9680dd14c8c8d0d0b54bc8 514972 utils extra reprepro_4.13.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQ4uOoAAoJEOxkTtbr1QJDAscP/iP709i60ipbn4RUU1ub6/J2 R7t1UhOz5mhOwYmZlccFExyMzL3sRbyxaF1ESyYfOV3XSi+ywMIhn+op0Ijx7WMB HvEAbMCgh5qIvqcbqPVYCos5GmYygc5+AdhqaRp2d+8j9ief9S1P5dLTuHBTK0+x jaX00qmmI0eY2HAQ3akzU58ipR3z+8f+WAkJ6N6jYrnwWnbhvCodm45TWHUDGfDK SXHcNrGnC+qJ3+GGMgHo81IS3IXvQ5zaNDQVDQzcKuWaHXiz2mZyIMezEDVp9iq8 9n7zod0ZZ2TkAWolbJUwNQ4PgT8sfKH90129UD1q+LVfIt67XhBszOSLQnUUAIRu svxYMugkwh6g3b/J3v3sWkApPIQV7qNjhA6Sxvj7Iu6D7wRX5O4j5Uao8NdcZsD8 qSClKrL+Mz4MTQWFO26hjDOPJWgeuFobTuzNbwXXnuzfA/g1K4ANb+wSstBUdt7C v3SAgjx1xZiSFiI2o7hQtaxTmz5m2cBJGSVhBXBfDerD3b96Lb4KUEUZjHm3D+Mz 2BimwcAjVIvseg2mr5qH95YX6Pbus0h95jmrnk6M/fxGX6PDNar3PgH2WJlLaXXy +SUyeTgQvtVL7zPJdLFqvSpqXqWLSazpMWFWuW2oncrZiuVICzvGBHcwn02jypBu zzikmnzvO6iVf5DQWrew =pkCo -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: http://lists.debian.org/e1tq3b5-0004yj...@franck.debian.org
Re: unsafe use of gpg
* Ansgar Burchardt ans...@debian.org [121214 16:18]: 2, Not asking gpg to verify signatures: I also found packages that call gpg in the form gpg $file and expect gpg to verify the signature on $file and output the signed data. Indeed it does so for *signed* files, but if you just give it unsigned data packed into an OpenPGP message, it will happily just extract that without caring about signatures. (One can generate those messages with 'gpg --store'.) Sadly gpg doesn't seem to provide a painless way to check for a valid signature and extracting the signed data[2]. Or did I miss something? Instead of inventing new ways for this, I'd suggest to instead ask the more important question: What worth is checking for a signature if you are not checking who is signing it? Better either use --status-fd or use some wrapper like libgpgme to retrieve what key actually signed it and check that information instead. (While just dump your own keyring somewhere and assume everything in there might sign anything and be trusted might look like an easy hack, it hardly scales and might be quite brittle assuming quite some default options to things like --auto-key-locate (and with any new options in that direction that might still be added to gpg). Bernhard R. Link -- 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/20121214222149.ga19...@client.brlink.eu
Re: Really, about udev, not init sytsems
* Jon Dowland j...@debian.org [121130 16:06]: I do not agree that reconfiguring your machine to avoid an initrd is a normal standard desktop configuration. There's also several other things about your setup which I would argue are not standard (see below) Will Debian come by default with initrds on all release architectures? Squeeze was still released with some kernels without initrd support if I remember correctly. Bernhard R. Link -- 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/20121130182310.ga18...@client.brlink.eu
Re: Really, ...
* John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de [121129 18:12]: This is actually a true valid point which I personally would accept as an argument against systemd. Without looking into the details, this seems to be something that can be fixed by a new upload, doesn't it? Almost any actual specific problem can be fixed with a new upload. Any reason given to believe that there will be problems left or that remaining problems will have a bigger impact are not probable with actual problems (because any actual problem usually can be fixed, or claimed to be a non-problem). I think noone claims that systemd would not be the superior design in a world where there is bug-free, perfect software prepared to handle every possible situation it will be thrown into. As our world has not yet seen bug-free software handling every single situation the authors did not think about properly, the expectation of what happens if one runs into a not-yet fixed bug is an important issue for many people. Free software has always been a way to avoid being helplessly at the mercy of some software. So handing over the basics of your computer to a much more complex system can be quite frightening for many people around here. Claiming that it will work for everyone and that anyone not being able to name a problem existing now has no arguments does not help. It only makes sure people are reassured that systemd is not for them. Combine that with vocal demands that it should be the only allowed init process in a short time frame makes sure that there is a big opposition (which will look for you like it has no arguments, as no real arguments against systemd are accepted.) Bernhard R. Link -- 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/20121129192240.ga16...@client.brlink.eu
Re: Really, ...
* John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de [121129 21:14]: On Thu, Nov 29, 2012 at 08:22:41PM +0100, Bernhard R. Link wrote: As our world has not yet seen bug-free software handling every single situation the authors did not think about properly, the expectation of what happens if one runs into a not-yet fixed bug is an important issue for many people. Absolutely. But again, this is true for any software and this is *especially* true for old designs which couldn't cover certain setups which simply didn't exist back then. But you have to understand that you put something that only does promises against something that exists. Something that exists means that people have experiences with it, now how it behaves, know how to debug it and now how to make it work again when it breaks. On the other side is systemd which has not yet been available in a single Debian release and could not yet prove itself anywhere. So if it would be proposed as some more init system to support or a cool new stuff to experiment with it, you would not get that much emotional reactions. But as people demanded making it the only available system before it could prove itself and while all most people know is that it is quite a different design which wants to solve all the problems at the same time (which often enough means it creates more problems than it solves) and that it has ties which other projects people have had no good experiences with (for enough people pulse-audio is a synonym of my sound is not working) you should have a different reaction than ridiculing people not wanting to bet their future on it. You know the famous quote: 640 kB ought to be enough! But I also know which happened to the 80286, which offered quite a lot more memory and many nice things like fine grained memory proection: It only looked nice on the paper but (with some noble exceptions) was just not worth the hassle, so that people prefered to stay with a 1 MB limit for many years to come. Yes, I see your point. But again, what I said before, how many people are actually digging into such low-level code? Someone who is jumping into kernel or plumberland development always has to have a certain background knowledge. It requires more skills and experience as opposed to writing desktop applications or smart phone apps. This is exactly the mindset that scares people away from systemd. An application that does not behave is no big problem. One can easily ditch it and replace it withanother. One has all the bells and whistles of your full desktop available while you debug it. It's all quite well understood. If your init system does not work -- and one day it will not work, there is no way that can be avoided, there is no perfect bug-free software out there and especially when the task is to cope with all possible hardware and their little quirks and timing problems, all the different combinations of services and daemons out there and so on -- you are set back much more. So if you end up in a situation like that, what do you do as user? Some will say oh, it does not work. Let's try to reinstall the machine and if that does not help let's try another distribution. Perhaps the next release in two years will work. Or perhaps what I wanted to do is not that important, so I will just not do that. But for many people that would not be a solution but the absolute nightmare. Being at the mercy of the computer; not being able to decide what your machine does and what not; being totally powerless and dependent on whether someone has decided that what you want to do makes sense or not. So being a more complex thing means it must be easier. Easier to understand what it does. Easier to understand why something does not work. Easier to fix it once it breaks. But do you really think that we should keep every part of the system brain-dead simple that everyone understands at the cost of reliablity and performance? Do you really not understand why people think that? And what does reliability mean if it can stop working and I can do nothing against that at all? I see your argument about keeping stuff simple, but again, if you want to be able to solve more complex tasks with your computer, the software on it itself has to become more complex. Strangely the complexity of the solution has seldom been related to the complexity of the problem and always been the opposite of reliablity in the past. So this is merely a false assertion. Claiming that it will work for everyone and that anyone not being able to name a problem existing now has no arguments does not help. Do System V Init or Upstart work in EVERY single use case? Actually, all my experiences with upstart has been when it does not work. And then it was always a pain to work with. So in my experience System V Init is quite superior to Upstart. And the big advantage of System V Init is that everyone can diagnose and fix it. Everyone knows how to add some echo
Re: the right bug severity in case of data corruption
* Adam Borowski kilob...@angband.pl [121127 16:32]: So, what's the reason mbox is still the default in Debian? Because it works and causes the smallest amount of problems given all the other changes. Among other gains, data loss because of mboxo would be gone. Continuing to call that data loss makes it quite hard to take anything else you say seriously. Bernhard R. Link -- 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/20121128065215.ga14...@client.brlink.eu
Re: Mass bug filling about proprietary code of adobe in our type1 fonts
* Adam Borowski kilob...@angband.pl [121125 15:20]: On Sun, Nov 25, 2012 at 02:07:03PM +, Bart Martens wrote: On Sun, Nov 25, 2012 at 02:34:34PM +0100, Wouter Verhelst wrote: If there is code in a font that has a license attached to it which does not meet the DFSG, then it should go out of Debian; not because we're not allowed to keep it in Debian by the author of said code, but because we don't *want* it to be in Debian, according to the DFSG. I agree with Wouter on the above. Moreover, if it doesn't have a license, or it's not clear whether there is a license, or if the license doesn't allow redistribution, then it must go out of Debian not because we want it out but because we're not allowed to redistribute it, not even in section non-free. You might want to ask Adobe first, though, before removing anything. The EULAs of the different Adobe products are easily found in the net. And they also list many pragraphs about the stuff embedded into documents. Most of them are quite restrictive. For example for pdf forms (those pdf documents where the receiver can fill in stuff) created with Adobe programs, every organisation might as far as I read it either only distribute 500 different pdf forms to an unlimited amount of people, or a unlimited number of pdf forms to at most 500 different people (no matter how many normal licenses of the programs you have, I guess you need some special mass pdf form license otherwise). If I remember correctly for embedded font software (I think that means true type and non-rasterized postscript fonts), there is the permission to place a copy in one (and only one) printer. And an extra permission for a copy shop you bring your document in to use that font. And stuff like that. I.e. most stuff will non be suitable for Debian main. Some stuff might be suitable for non-free. Many things will not be distributable at all. Bernhard R. Link -- 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/20121125154119.ga10...@client.brlink.eu
Re: the right bug severity in case of data corruption
* Christoph Anton Mitterer cales...@scientia.net [121124 17:42]: I've recently reported several bugs against MUAs and mail tools, that employ the mboxo (note the trailing o) format to either store or import mails. So,... bringing this up here at d-d, as I think it would be good for Debian to have a well thought position in how to handle this family of corruption bugs... I'd say if you complain about a tool not documenting what mbox format it is using, that is a minor bug. If you want an option to also support another mbox format but mboxo, then I'd vote for wishlist severity. Ambiquity about lines starting with from in mboxo format is the same like storing the value 0007 in an integer and getting 7 back when asking for the value. Or like storing a filename in a FAT filesystem and getting it back when asking for a file with the name converted to upper case. Bernhard R. Link -- 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/20121124201101.gb7...@client.brlink.eu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
* Andreas Tille andr...@an3as.eu [121031 08:06]: Consider the case where a maintainer objects. In that case you're counting in the previous long waiting time a period which the orphaner probably thinks shows disinterest in the package, but during which the maintainer may well feel (for part of the time at least) that the package simply didn't need any attention. I keep on thinking that we are talking about different packages. If a maintainer is simply feels that the packages didn't need any attention these are not packages which are for instance: - lagging *way* behind upstream (regarding time or version number) There were some cases in the past where the maintainer did not package new upstream version because they had some serious issues (or because they only wanted to follow stable releases in cases where stable and preview releases were hard to distinguish for a outsider) while someone else mistook this for a missing action. - leaving open bugs simply unanswered (=do not give any reasons for not working on a bug) Who of us never put some unimportant bug that would need some longer investigating in a row to make sure it is actually not a bug and forgot to post a little note of will look into this later. I do not speak about feelings but measurable facts. Many facts are not black and white, but in practise there is much of gray. Also this argument is a form of this has been waiting for ages so now it is urgent which I don't really agree with (unless there's an actual deadline of course). I would rather call it a this has been waiting for ages so you are obviosely not interested and no harm is done if I take action nowish. This assumes that it actually has been waiting for so long. Different people often see things from a different perspective. And the point of this waiting is exactly to make sure that this view is not missing. If it were so clear when a package is neglected and when not, we could just do without the whole waiting period and giving the maintainer chance to object and simply hijack the package directly. Bernhard R. Link -- 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/20121031080420.gb11...@client.brlink.eu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
* Andreas Tille andr...@an3as.eu [121031 09:43]: On Wed, Oct 31, 2012 at 09:04:23AM +0100, Bernhard R. Link wrote: Who of us never put some unimportant bug that would need some longer investigating in a row to make sure it is actually not a bug and forgot to post a little note of will look into this later. Me. Does this also include packages where you are listed as Uploader? ;- It is a question of respect to the bug reporter to at least respond to the issue. I do not disagree that it is something that should be done. But that does not mean it is never forgotten. (Or one discusses with the submitter privately and forgets to follow up in the bug report or or or). Bernhard R. Link -- 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/20121031194817.ga12...@client.brlink.eu
Re: Mandatory -dbg packages
* Philip Ashmore cont...@philipashmore.com [121028 09:12]: Yeah, in (cough)Fedora, kdbg even offers to download and install debug packages for you. Debug packages also make back-traces more than useless, and (cough)Ubuntu offers to download debug packages which it installs and re-examines the back-trace to see if more are needed. While having some way to get the stripped debug info from the installed packages is nice to more easily get some debug information or to retroactively make a backtrace a bit more verbose, it is still not enough for all cases of debugging. Ideal debugging information you get by locally rebuilding the needed libraries with DEB_BUILD_OPTIONS=noopt nostrip and installing those. (Sadly not all libraries support noopt, but it's getting much better as a side effect of the current hardening effords). Bernhard R. Link -- 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/20121028103552.ga3...@client.brlink.eu
Re: Mandatory -dbg packages
* Ben Hutchings b...@decadent.org.uk [121028 17:02]: There are plenty of bugs that involve 'undefined behaviour' that in practice depends on whether optimisation is enabled. Unless you have a good idea what's going wrong, how do you know that 'noopt' won't hide the bug? If the bug still shows up with the library recompiled with 'noopt', then no harm done. If it is a bug in the library, you want to look there anyway (and you will most likely want to compile different parts of it with or without optimisation or any other technique; in any case you will want more of the library than just the binary and some debugging symbols of it). The only case where a noopt library variant is a disadvantage is a very ugly case of heisenbug, that is hidden by the slightly changed library. Also, gdb and the GNU toolchain have recently got a lot better at handling highly optimised code (tracking variables in registers, treating inlined functions as logically separate functions, etc.). Yeah, they got a lot better. But even if gdb got perfect in that regard it can still not show what isn't there (like the value of a variable (or function argument passed as register) no longer stored anywhere. Bernhard R. Link -- 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/20121028163707.ga19...@client.brlink.eu
Re: Bugs filed in unexpected places
* Thibaut Paumard thib...@debian.org [121026 15:54]: I don't see a reason to move it away from wnpp: its great to have a central place for that information, but I agree it is useful to have the info forwarded to other places (such as the PTS, and perhaps the package's own bug page). Having a central page to show all of them is nice. Having them in one pseudo page is not really the optimal solution for that. (I usually only look for http://www.debian.org/devel/wnpp/work_needing instead because https://bugs.debian.org/wnpp is just too slow.) Putting it to the package's data is a much more logical place, easier to find, harder to miss. Better collect the data to show them in some central place also instead. Bernhard R. Link -- 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/20121026160646.ga29...@client.brlink.eu
Re: Discarding uploaded binary packages
* Chow Loong Jin hyper...@debian.org [121020 18:10]: The only argument I have seen for binary uploads is to ensure that DDs have built the package prior to uploading it. But as someone else pointed out earlier in the thread, we seem to be trusting DDs a lot in other aspects, so why not trust that they test-build packages prior to uploading them as well? Because trusting someone in one thing is not the same as trusting someone in another. Trust works best when there is accountablity. Having the binary file around, even if it is not easily accessible on some remote archive, noone can claim I tested this, it just did work here, something must be different on the buildds and hope to get away with it. Given that source only uploads where tried in another project and the results are scary, this accountability might make the difference to make it work. And to also name another argument: having the files actually uploaded means it is easy to add additional checks. (Like starting with making sure the list of files does not differ between the two versions, or some check to see only versions of generated dependencies differ but not the packages depended and so on). Bernhard R. Link -- 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/20121020162948.gb14...@client.brlink.eu
Re: Discarding uploaded binary packages
* Michael Gilbert mgilb...@debian.org [121016 04:59]: Anyway, all of these build system path sanitization issues can be eliminated by using the buildds for all architectures, since paths will start with at least /build that requires root-level action to exist on users' systems. They are not eliminated by using only buildds. They are only moved towards people that want to build their privately patched software then, which is something they have a right to do. A package not building properly or differently when built in a clean system with all the build-depended packages installed and all the build-conflicted packages not installed is a critical bug. Recreating binary packages uploaded by maintainers has some merrits, but this is definitely not one of them... Bernhard R. Link -- 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/20121017200750.ga5...@client.brlink.eu
Re: Discarding uploaded binary packages
* Michael Gilbert mgilb...@debian.org [121017 22:19]: Anyway, reading again, I not sure that your reply actually considers build path sanitization problems, which is what my statement was about. I'm stating that doing all the builds on buildds will not avoid the need to fix the package. (Unless you are arguing that people locally modifying their packages are supposed to get security problems). Bernhard R. Link -- 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/20121017205532.gb5...@client.brlink.eu
