Accepted coccinelle 1.2.deb-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 13 Jul 2024 14:01:27 +0200 Source: coccinelle Architecture: source Version: 1.2.deb-1 Distribution: unstable Urgency: medium Maintainer: Debian OCaml Maintainers Changed-By: Stéphane Glondu Changes: coccinelle (1.2.deb-1) unstable; urgency=medium . * Team upload * New upstream release Checksums-Sha1: bdca63957f5eeaac8be1b3b19111ebc1293f4343 2179 coccinelle_1.2.deb-1.dsc 46458533c33e1d6d9e45aa22de3b434311f814cc 1818083 coccinelle_1.2.deb.orig.tar.gz 592f31a32b7a816c0be87d2e4503e35609641378 12488 coccinelle_1.2.deb-1.debian.tar.xz Checksums-Sha256: a4b8d95c1255049bfd44b2a98cd45a89821130d6cc289a689dbdb602bf9d192a 2179 coccinelle_1.2.deb-1.dsc 960a166bf52f200e915d556b5e3c44948d2b044275c4b012c017b255bbadfcfb 1818083 coccinelle_1.2.deb.orig.tar.gz 86c1fcf6ac43175f2551cbfb0518b6fb80cd60664ab1a08f241f449089399863 12488 coccinelle_1.2.deb-1.debian.tar.xz Files: 1c9824b7aecbfacbfbb4c7bd8f494049 2179 devel optional coccinelle_1.2.deb-1.dsc 2a13bf055f0aaad3caccedd7b3a70543 1818083 devel optional coccinelle_1.2.deb.orig.tar.gz d22b6a8c40c1949f09a63585985ad65a 12488 devel optional coccinelle_1.2.deb-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQFGBAEBCgAwFiEEbeJOl+yohsxW5iUOIbju8bGJMIEFAmaUrv4SHGdsb25kdUBk ZWJpYW4ub3JnAAoJECG47vGxiTCBf2QH/2V8E035R0GTkCiyHifVvZmP15jenEEM kyLj0ChUi9rNVyT4e//L2pzAMlsKAuCoccfTQEl9y8Tc4S6WjaeWgnfxypM5UAk6 JHApWfJl1sfxyiQY1TuArg2TlNS5QBzw1aQPvPeTSIFLxX1BDXWMWL1QGx3EnW9P QBx2lLq0W5tRO/nb69GVkzYTWzvETifEaJ9plz2/qJlTD1hPu9WbOVy67iP2rzF1 zNj9rjN4iLn+zorkD1nJweL3KmUBr+UUUQasiosYtcjgDSSxBZlA6YrCpfEMdyHP GEEJRWujUuP0bCrORTHsx9PS83GqPA9/zAsiIFDtrTdeHBU9rivoYNg= =HcpW -END PGP SIGNATURE- pgp7_5_azbhX2.pgp Description: PGP signature
Accepted coccinelle 1.1.1.deb-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 29 Jun 2024 08:50:49 +0200 Source: coccinelle Architecture: source Version: 1.1.1.deb-6 Distribution: unstable Urgency: medium Maintainer: Debian OCaml Maintainers Changed-By: Stéphane Glondu Changes: coccinelle (1.1.1.deb-6) unstable; urgency=medium . * Team upload * Fix build with OCaml 5.2.0 Checksums-Sha1: 2101366e846d568a6cf67e4f7126435e87a1b09f 2188 coccinelle_1.1.1.deb-6.dsc af1f8bd3f3e3ef960acff1b7e5ccd146bf778a97 13176 coccinelle_1.1.1.deb-6.debian.tar.xz Checksums-Sha256: 44e37abaf70f27ae6acc3072015c5a36b681447c4b261591afa07f22364e713c 2188 coccinelle_1.1.1.deb-6.dsc d9874c539ee984fb9528b8745a349e3508fc4dc76b72ca2b973c7a37ed1d20e6 13176 coccinelle_1.1.1.deb-6.debian.tar.xz Files: b10b5cc0ef388846e4d776d2d9f35c68 2188 devel optional coccinelle_1.1.1.deb-6.dsc 9c6d44ad409ee099d048ccb5abd08d82 13176 devel optional coccinelle_1.1.1.deb-6.debian.tar.xz -BEGIN PGP SIGNATURE- iQFGBAEBCgAwFiEEbeJOl+yohsxW5iUOIbju8bGJMIEFAmZ/ryMSHGdsb25kdUBk ZWJpYW4ub3JnAAoJECG47vGxiTCBdw0H/2mxbwOsvyMPyothuZCqV1wvDRfqCXdB Lro2p7T1wkr0x/gUz6KCrTnneZZF8SikGyuXjLGgy/8IkWeqNwiH0jam1UYZyE2Z v8fw88mwENe/O2HMOApGNrrk7ZXKD7NxBeP+5v5nbjGynqvvQSJ1aG4iE6p0a5mF nqgdXbzcOy06a/Ej321c+tVmkcILUgWv0cCASCLD673KGneRSNo+sN9PpmClgEYZ Q1rptbH77OgMzgAN1aukqNMog1avpAUM5jLA8cpyo+e2/HvZr2veK3fc9rBXodn5 XyqJDGTV2O+cDiXJwA6rc4VeaKiwXBr6KbeGZX4IWd3Y9+ZZB1Q5RcY= =PiCS -END PGP SIGNATURE- pgpraQ0F7dlcO.pgp Description: PGP signature
Accepted squid-deb-proxy 0.8.16 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 25 May 2024 16:24:25 +0200 Source: squid-deb-proxy Architecture: source Version: 0.8.16 Distribution: unstable Urgency: medium Maintainer: Michael Vogt Changed-By: Michael Vogt Closes: 999647 Changes: squid-deb-proxy (0.8.16) unstable; urgency=medium . [ Mika Pflüger ] * Merged NMU changes, thanks to Hideki * debian/control: update VCS and homepage metadata (Closes: #999647) . [ Michael Vogt ] * apt-avahi-discover: use syslog for logging in AptAvahiClient Patch from `jasonpe...@gmail.com` - thanks! * debian: add gbp.conf * Makefile, apt-avahi-discover: make `flake8` clean via `make check` * github: add simple workflow . [ Jesse McDonald ] * port from asyncore to asyncio . [ Mark Esler ] * d/control: add flake8 Build-Depends * 30autoproxy: update apt-transport-http syntax * d/squid-deb-proxy.postinst: add launchpadcontent * mirror-dstdomain.acl.Ubuntu: add esm.ubuntu.com . [ Hideki Yamane ] * 0.8.15+nmu1, thank you! . [ Miriam Espana Acebal ] * 0.8.15+nmu1ubuntu1, thank you! . [ Rolf Leggewie ] * 0.8.15+nmu1ubuntu2, thank you! * 0.8.15+nmu1ubuntu4 (patches unapplied) . [ Gunnar Hjalmarsson ] * 0.8.15+nmu1ubuntu3, thank you! Checksums-Sha1: bf2c57aa7784dd195f2b1ad82b51da9b393cc0fd 1810 squid-deb-proxy_0.8.16.dsc f120c6822c44a53f2958c9183d39718053daf095 23164 squid-deb-proxy_0.8.16.tar.xz 433679068235386e490883f6b47322ec948d896a 8058 squid-deb-proxy_0.8.16_source.buildinfo Checksums-Sha256: 7c9cb90c292e8fbdf90d7eda6269f045a6ffba397c501bcfff0973638b5b9f1a 1810 squid-deb-proxy_0.8.16.dsc 01e3e95695dc9fc56c85f827a0743f812118475e996ea240ee4464983028afec 23164 squid-deb-proxy_0.8.16.tar.xz 369996c698f5194cc86981131e13840c6ec1f08850855327c302151ef24977b0 8058 squid-deb-proxy_0.8.16_source.buildinfo Files: 5a353b7b590ea0f52afb8da0c2af6f97 1810 net optional squid-deb-proxy_0.8.16.dsc ac596954895c83edc57b19f0260a4d25 23164 net optional squid-deb-proxy_0.8.16.tar.xz 067d7367816553cf5594322646c70f54 8058 net optional squid-deb-proxy_0.8.16_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE2mxnVNiIdibNBqEomMq7Or1MpZ4FAmZR9W4ACgkQmMq7Or1M pZ7RMA//YQXjWnMCbnN9CPSXgqym4CuYPQaH13xM3j2FI05Vox9nL9a1xmSlrFgN P4WfPsZiEU5P7HZkxTbMzfmhMcs1T4XlDuJ+3CGOwjmM9xIz6amSX8hDe8sXoouH riH2TLUSyjSGSfoYU58/WYXNCy66x7kXagLQNdJ9+fgQO4fvHEf1YXBUI0TUl3fJ WEl9lzhDJqpHz01EBGAMvXD75Ie2GV2MXkosnvPTPN7Ta/N7ZG/hfOlg8qSaUhOZ Xx2xjh66NA5mwCJxidH3bGq1ddCQiR6op8TWVsZsawjCw7ZFPgfeA3fZYkm7Qs3N qQEwu5FCsDi4F55pU1Y5FxAebqm9iixkhtiTO46OvfHYCm7Dy+LBz1VaagsVNmgp P3vQtNXuegbW9OG1D8Tx4o+oa6jfSp/8mzeuQ6UryEGgmS0yvqDqBtoFEcJWSE6e dtSze/wX/m9yaO4WA0XIAAYIjLmGGezLKH3s/Hi768/D7F3yj6xUdz48ffqz5f9P 3Sw7YDEwUe2t86LfwzNSd+n0ashsdMl4DNItkN9QW6rtkRejUNJ/ns0evmUOCVXa qvNUUHBgZfiA9l4RazbTMh9UALNa0cz8o04HckYRBdZrEe0kY/znLPAb/Kl18GYW QA7Mj9Kx3LRy/moJ7V7YXgwzhceoBJ9uEDVG+taGhSWaimo5zew= =CYKY -END PGP SIGNATURE- pgpdLMTsQU2NR.pgp Description: PGP signature
Accepted deepin-deb-installer 5.12.4-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 06 Apr 2024 13:37:35 +0545 Source: deepin-deb-installer Architecture: source Version: 5.12.4-2 Distribution: unstable Urgency: medium Maintainer: Debian Deepin Packaging Team Changed-By: Nisha Pariyar Closes: 1044681 1068040 Changes: deepin-deb-installer (5.12.4-2) unstable; urgency=medium . * debian/control: + update libqt5concurrent5 and libqt5widgets5 to libqt5concurrent5t64 and libqt5widgets5t64. (Closes: #1068040) + Bump Standards-Version to 4.6.2. + Change build dependency pkg-config to pkgconf. + Add myself to uploader list. * debian/clean: + Clean .qm files to fix ftbfs-source-after-build. (Closes: #1044681) Checksums-Sha1: 5ccbf2031949033c01b51795137e95b69107fbba 2390 deepin-deb-installer_5.12.4-2.dsc 853afa78b571eb070f5eb2c700413be8eed5e5eb 5044 deepin-deb-installer_5.12.4-2.debian.tar.xz 6ce8f482b722523d2087fe32d5726fa10839631c 15324 deepin-deb-installer_5.12.4-2_amd64.buildinfo Checksums-Sha256: c71182b0393466f18f0b3d33be10e2293d257287a89d32d78859542d743c3e65 2390 deepin-deb-installer_5.12.4-2.dsc 7d1c66a27564811a0147a1ba9943f29708e0dfda54b3fcf5c3ad89fb3e478c62 5044 deepin-deb-installer_5.12.4-2.debian.tar.xz d89fa5ff00326908a97a494beec69d7db41e71fe652ae217e2cde35693cc5309 15324 deepin-deb-installer_5.12.4-2_amd64.buildinfo Files: 8a2712598f925fbc33bf0fc186301854 2390 utils optional deepin-deb-installer_5.12.4-2.dsc de0be2a3c07caca66c0a8ca9b6c40c0a 5044 utils optional deepin-deb-installer_5.12.4-2.debian.tar.xz 9891707e7973dd6e598baefed25f3077 15324 utils optional deepin-deb-installer_5.12.4-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE2lMFjb4VS9/L8WutS1Qq9wT3RRYFAmYWaToACgkQS1Qq9wT3 RRb3VA//aE7tBcruqe9cj9f0dyLw344jRwfuny8bhGbBXXiWlmFUuMrF+h17T3iO FHuAjTzQTmN3WdjSRLJP97tOzicC9FuYtiEE/DsKL6oIAsmXyTXWPe+CHbCibBb0 TTaTS8JJxKLJWx7lueFCMjRNoUhD+G9sfSq3P8buL8ToKGOXaHOsIuWhcW3jeXV+ /DnY6RsDGDcC/74EZps9A0oGhanCMOn3bTpHDYISncXPhhJoPMFscHwsAJ9pZ804 gUX8iErozjOr8u9U3ACbQeiSukKUOAA90NviFJDJACEwpT0efaHPVIHR6vtc/ngq MG82Tkuz1h4LrhvxfoNcGWgtTe3CgD/vOniyLOSR6dH4QV3sU17a9tFfLKV/Hg0k bxi0u5pT0aTrQZfh4WjqMyxgzVR866PsTmepXG5Hi8/iS6RWnMk3e3csKjdqLGEe AJxE6bFIwiXeM0GCX36CnpwrQ5Fopq9MIRg79dihgRj3Hddn5/zXpEQrlbIEC5xo pvwnEVj/b7LDMZeZoMbBExxvZBPBWx8pk3k+MX9Y0fUaEyrtF4riN2kusx1tJh98 Vh6AgTMyXbYg6EK3VS70q1W/m7n19LvmylIPJ2P08PrOcrYzWM//FbblyKS5TRhC GNRupV8Bx+YHUuBrMAG2Qxldd7NKZihahD2DTty903ArCmVF6Bs= =0prQ -END PGP SIGNATURE- pgpZtXeg82ZtG.pgp Description: PGP signature
Accepted ruby-deb-version 1.0.2-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 25 Dec 2023 13:11:44 + Source: ruby-deb-version Binary: ruby-deb-version Architecture: source all Version: 1.0.2-1 Distribution: unstable Urgency: medium Maintainer: Debian Ruby Team Changed-By: Ajayi Olatunji O. Description: ruby-deb-version - Port of Debian Version comparison to Ruby Closes: 1059438 Changes: ruby-deb-version (1.0.2-1) unstable; urgency=medium . * Initial release (Closes: #1059438) Checksums-Sha1: 78d61e1b4f42d2f05abb4a479718e6d6fe8a3bdd 2061 ruby-deb-version_1.0.2-1.dsc e804f6f5ae9cc28ec5317d96c35c8ff784a950c8 4009 ruby-deb-version_1.0.2.orig.tar.gz 12f9530d70e9abd823b3af9f3c64cdd9cdd7600e 2148 ruby-deb-version_1.0.2-1.debian.tar.xz d21940d7eacf44b5b48c0d86d392312fe06ba39a 5120 ruby-deb-version_1.0.2-1_all.deb fc87d196775508f5704450c9329ea5a3ea2eefb6 9180 ruby-deb-version_1.0.2-1_amd64.buildinfo Checksums-Sha256: b1207be5930580cd37107ac5cc328a6d17b9c744b248de7bb4ce389efddbd421 2061 ruby-deb-version_1.0.2-1.dsc accb2ec855679a5bb5a264fdc75fd43569e0e581461246ba9cb43c8cc2c14957 4009 ruby-deb-version_1.0.2.orig.tar.gz dfaed0f488cd303b4266ed7dbdf20ade0721ae6e9f7176d1c2a05926e04f7c06 2148 ruby-deb-version_1.0.2-1.debian.tar.xz 3e0035afd7b2b48f20d2aba39d1b1e31ac77ecf80ea34bc475eabbe019b0fec7 5120 ruby-deb-version_1.0.2-1_all.deb 5493fbf9e2df1782f00feff2616971c1306e4691971c1116f37709c5aa3206d3 9180 ruby-deb-version_1.0.2-1_amd64.buildinfo Files: 957f7be6d0790d7f721ea5b066a8d4fc 2061 ruby optional ruby-deb-version_1.0.2-1.dsc ca00367e105b6ce994afe06bfe2f7405 4009 ruby optional ruby-deb-version_1.0.2.orig.tar.gz 6479bb52f970faae6d4baf1fec695dca 2148 ruby optional ruby-deb-version_1.0.2-1.debian.tar.xz bf6515ff3691800a37c3252f79efffb8 5120 ruby optional ruby-deb-version_1.0.2-1_all.deb d1f5ff87ea616f192e9c776cd011cb3e 9180 ruby optional ruby-deb-version_1.0.2-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE0whj4mAg5UP0cZqDj1PgGTspS3UFAmWP5E0ACgkQj1PgGTsp S3XNOA/6AtdK9WxDStkcYj/Jr0RRMWfvTp++GI1a6hdU/2aSFQO6Yzkkp7182L2R SyAggWv6NnUb4s7R5nJnAa0xxJqZxqVxCnka+HO6mUmMldbtChzqg4ErQjc/8Osz 6HJUYlv+i9RdFVFSg0a0u+ck56XARKgbx/7hB/jq9NCGqx0u6uRXPVLyWP6XkU0d a2yDYrXvg/gpgwYW0K5bZXAc6ulsZgxu0hHMSSwsUOBLeyAhZPvDdWyyKwAqzZ/7 mKucpmwiXDfcY9avKN2EEzHNR3wcrCuBUV5fMKU814mvbdTSTplaeQ4CoO+WBOCr lMDdurApe5inYmdslNPEix6KWqrjheWF+otGMlMXsOONUejYKvEox8/uyz9Lx4Lw 2IgJW7tIzK7/HJ14rMnocv6fx3qdSA6DXcGXeCJT85b0l1dRlBX5E/2KLmxpwCqC qdyFf7Pg2QACg2M2r9gJ1yKZFPEUOaFHrsi9me6hkHZt8KDlesPJxZ942qhlr+vF fm60nCp681V+Bb6I08ZmqidyBSbdyTt/6xuiWoH7l2C4M67vMYJRuHN5fpNcClDh Bcf6pgh5/WEAzAVZu/CdNgLVYvSVDFVRZaiKK5cZQ3T3uc0IX8hgQE3q1ubrbTOz B8QLhZ0L4alrNRPLgp1Jwt8kFL7l7RGCVQZbRUgvbHBxnJ7M6T4= =g08S -END PGP SIGNATURE-
Bug#1059587: ITP: ruby-deb-version, A port of "Debian Version" comparison function to Ruby
Package: wnpp Severity: wishlist Owner: Ajayi Olatunji X-Debbugs-CC:debian-devel@lists.debian.org * Package name : ruby-google-apis-core Version : 0.11.2 Upstream Author : Google LLC * URL : https://github.com/google/google-api-ruby-client#readme * License : Apache-2.0 Programming Lang:Ruby Description : Common utility and base classes for legacy Google REST clients. This package is a build dependency for ruby-arr-pm, a package required in gitlab 16.6.2 OpenPGP_0x98CF779AEFF9D48C.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059438: ITP: ruby-deb-version, A port of "Debian Version" comparison function to Ruby
Package: wnpp Severity: wishlist Owner: Ajayi Olatunji X-Debbugs-CC:debian-devel@lists.debian.org * Package name: ruby-deb-version Version : 1.0.2 Upstream Author : Nemo * URL : https://github.com/captn3m0/ruby-deb-version#readme * License : MIT Programming Lang:Ruby Description : A port of Debian Version comparison to Ruby. This package is a build dependency for ruby-arr-pm, a package required in gitlab 16.6.2
Accepted deb-gview 0.3.7 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 22 Nov 2023 13:47:36 +0100 Source: deb-gview Architecture: source Version: 0.3.7 Distribution: unstable Urgency: medium Maintainer: Josef Schneider Changed-By: Josef Schneider Changes: deb-gview (0.3.7) unstable; urgency=medium . * debian/tests/control: Depend on at-spi2-core. Checksums-Sha1: 41c400415a62ccaf674d3287ecf49666021270c7 1704 deb-gview_0.3.7.dsc 4f07b8e90f8a08740505e9b4da51b0f28f389113 80264 deb-gview_0.3.7.tar.xz f78d29949b4c285307374c506a9a46387f8fa1bc 15091 deb-gview_0.3.7_amd64.buildinfo Checksums-Sha256: 368840e0866370fc8be9145246a18fa2c5d58ac0df2911af6d40c0b7e088eb47 1704 deb-gview_0.3.7.dsc 11069a8472b84260dd0b9c67991000bf123007da5da7159220b824567aad0c00 80264 deb-gview_0.3.7.tar.xz 32702a503051245b3347fef7d7bfc29062cb612a3c361c7d7a2735520825aa66 15091 deb-gview_0.3.7_amd64.buildinfo Files: 6b598070bd122b12f38030d65be59c40 1704 utils optional deb-gview_0.3.7.dsc f75d78ad2dd19cf45f1f11c054e238ff 80264 utils optional deb-gview_0.3.7.tar.xz b99b785df5c9035d6aa9f203b25402e4 15091 utils optional deb-gview_0.3.7_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEMsxJDlpwsj3Wqlqyouuu0bb5AkEFAmVeIWUACgkQouuu0bb5 AkEcjhAAoNvyYF78j0xEifFDMgWn+M6FWgZZAS1OtWXJOEgNpsMYA4UlMkCi3A0V R2Mxonog7vH6cDpknu38V43M7rH8Q0HLPh6J47OqT0Z1rZ1H51ee9RF6PzrKjLqC HbF9A0GUlrWFRRJSybau9GC58/aPD8YgucdJEyFwvKOrKfEG4lyVwK1QWqrQU+r+ GmAzCzs8bjzPqY/gXOikXBecvhTX5lg8YI9Kdq3KNitPxzz0DnxPNzA0hhhvwN4O 5oHrsRdMQATDE8tWkKH6ubQ8fGNTniDhqAGKbWiNpB+I+fJpSdjPBQkFLdFfhwdY VSgmFec1AiLms95MIiBOZxpYiC83SjWn+U5IRUDBGMFXs0ID1LpmGu9PBAmeSKqB kspTE9UXFhiFQayyEtANCTYbpRy5Axp6m32E1j8+wqODBzHIO6YNPZTMJ7B8H1S6 +YxlVQ4Ve8qxRLpzajbJHZopZmQGWWmYE+Nrs4I0xsBaaQ+a7HRDmiKVWIP1rqCi SqVVxj1hyRG65tzpyfYN2y2NkjxqArSbzuHzmo+Be8HxKUIas7GMRQC2AE/DtW4j DEeulzXNI/3Kp1rKpkKyW+XZme97o2Qas/eBm62W7NIetIo6oa98Bk3g40wvTqm0 UUz3EBP5V7IWtoEWHqCPQ/1wKLqW7XAcNGF6DBMjb+PTSC4SNFA= =F27l -END PGP SIGNATURE-
Accepted deb-gview 0.3.6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 13 Nov 2023 15:55:01 +0100 Source: deb-gview Architecture: source Version: 0.3.6 Distribution: unstable Urgency: medium Maintainer: Josef Schneider Changed-By: Josef Schneider Changes: deb-gview (0.3.6) unstable; urgency=medium . * debian/tests/test-*: Fix mkdir location in 3 tests. * debian/tests/control: Add Classes: desktop lines for Debian-CI. Checksums-Sha1: 38109aebaa26389c435f4cb4e97604b5eed78a0c 1690 deb-gview_0.3.6.dsc 33deea6b6abc31e62d138dc71a61c0e529626b7d 80220 deb-gview_0.3.6.tar.xz c306daaa705698afa387fdf47971aa52b2f3fb4f 15091 deb-gview_0.3.6_amd64.buildinfo Checksums-Sha256: 96987a82ca599bc601310ef0dd6216ae36e047ab4dc97e673e8cc9351d1d97d9 1690 deb-gview_0.3.6.dsc 35be1269e2d44a67879c5e66451f1d1fab22c6d3ca54f07f6bb39eb76c58bef7 80220 deb-gview_0.3.6.tar.xz acdf957892ad2989d79793b8070b2ee1b562580fe28aebf555373e66d3e53fb6 15091 deb-gview_0.3.6_amd64.buildinfo Files: 9bc88c2515112589a71afec74a4207dd 1690 utils optional deb-gview_0.3.6.dsc 7f468939360306e91c0f0afbe6d0772a 80220 utils optional deb-gview_0.3.6.tar.xz f73a8f48dbc8bdc73bd27a1334af0463 15091 utils optional deb-gview_0.3.6_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEMsxJDlpwsj3Wqlqyouuu0bb5AkEFAmVcNW0ACgkQouuu0bb5 AkHUrg//dQERKglxOR4m36Q3w7GJ8bgoMBFhRgxvxFgwxvpj3avt+52hwAtNESv1 WjNVnUrJrIZ8syJeh+dZ4NKzRi2srNpBZBd99GR5SSuwilGAEmYwt8M69iTlf9lW w7JQy+/6MMtuNgEdmg+oZty7U6bHICe6JpR6o+JnDRVmIlA7mCSehZHoXMcdEzgH OJtS9Te94wIgZy4Htu4lPx+6h/GPnDGSH3hpBVa44GbaP3E6qGgdeJPal2gP2gbc 8erTkVwOeCvoOrjxKm6CM4qXBb5nt589HnERZ6IgGOC1mcBmfBVW/Xh5t8gIFHSK 5F+4viR7QSJb/pgi6gA616TMsYuMgrwQC4BhE1wUvvaczpTzeva7rM57IYUav1LG XL45DN3Wf6MgMzUuLdZtngDWOn4+idnrbf+GOoJBTNVFt/DvcnCSIVTWtXULxjer 182XbFPJxKJKlFmQBX1ey+U9j/rfImmrUtySGkHz7bc++mROBZjGVbQmkzfRYpy+ GZeqg/88br79lT/+lfXYYq8ezySEEUbOdlUQjzECaA3LfvHiOm9blzfaG7ok93vO pPQYDSxAcq3rHUlAkFatlPt3UERBaDl+OXOYIGWBiv3nINzqhBqvSPqkjC8L82/e u9366r+qH+8KWAOOniHaGw3LeKNPJrWvjh9BAhsMpmVmZAN7m3E= =751w -END PGP SIGNATURE-
Accepted deb-gview 0.3.5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 27 Oct 2023 20:41:40 +0200 Source: deb-gview Architecture: source Version: 0.3.5 Distribution: unstable Urgency: medium Maintainer: Josef Schneider Changed-By: Josef Schneider Changes: deb-gview (0.3.5) unstable; urgency=medium . * ChangeLog: Bring up to date from past commits. * configure.ac: + Increase version to 0.3.5. + Update bug report email. * debian/tests/control: Add equivs to autopkgtest Depends. * debian/tests/test-*: + Fix autopkgtest scripts for Debian-CI. + Use create_test_deb function for all autopkgtests. + Use /bin/sh and remove all bashisms. * debian/tests/create_test_deb + Add function to create test .deb for each autopkgtest. Checksums-Sha1: 52d776dcb6230c5797478751c2380126360ce975 1690 deb-gview_0.3.5.dsc 4d00b582adc3ea9af8d2e60c19db976b451d1207 80168 deb-gview_0.3.5.tar.xz 0a6c596dcb69f7f2ffb3872752df37c0af228929 15107 deb-gview_0.3.5_amd64.buildinfo Checksums-Sha256: 8764bf662cf17d567d838f63b63c8822cea65029f274de30bcf40a0daabcb119 1690 deb-gview_0.3.5.dsc cced71fd28ef291c6b78e271ad5b5ab094c0fea2cbc61d0583284675b5d4dbc9 80168 deb-gview_0.3.5.tar.xz 60d5cc40ffe10c6e62d763edd8914f2f3878dc7c8771cfedad5a52f5db44163c 15107 deb-gview_0.3.5_amd64.buildinfo Files: 912f04659ec0fd3343fb4de7e313fd5b 1690 utils optional deb-gview_0.3.5.dsc bd97f6b86b27cf0957fc623efb4a15a8 80168 utils optional deb-gview_0.3.5.tar.xz 30ae313a4f73f3322fadeb9d5d7376d9 15107 utils optional deb-gview_0.3.5_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEMsxJDlpwsj3Wqlqyouuu0bb5AkEFAmVOV18ACgkQouuu0bb5 AkFH2w//SO4TUF5GyVFrd5km7pFjVpPEHtKUhipONmNgg+4Hds0qvYdtAaB6Dj50 tFYVDo63Er5nZuDebRdiU+VV7+PdFwqhlTD1OPApMHyHq2fSob8Vop9aDHEAeTT3 eQhUimFsPKAoLdoAR5GJscRPGaXutbzda0X8IFTpHF58ltSQImoWNQjK1hZTebf4 JOYcS2cUfINJU+j+HausHxQ9x8FNe2ImqX74s8+lTT6g3HYqgXjjKfGNb/JnUkMM IINi1mOat53yT7inJuxq2svzDxUVXHFVuJnIIAZv8frVtZ0eGvU79dRwG2thXDdM 3DvDJYBsLdF/zF5oHmfi1iRAJ6jiJZcBmh2Cbcwrv9v+O6A5EhFMCrlCs0fWxlVC P9GTfu/XmIblu0X5QeoAvtkOMjJc+e5ZIOvJH0PP+vACBJR4b6gbhlsPAUvPnA8m q27N3yhsRSy2xR4XhicuYEupSaYTS+dTYIl/fqzjuXXmC3okp4B4flvJYQo8LB+W c5lvc6ptwdHGj2WYOtMxbdzjXi3XZ57FIENfHVIIi/y0twydpWwQXkiqaAFTZh1b 85C1rFThHnEb6lL8ePsd/iMgEcbhp/Apo7P1A5eVkHurr5CfYQ80jHQPUCHejcmn J9lDclEoldyLVOZiuY1Rp77mijuNOQjxZli6jKJpLE4YUjVRqx8= =In+P -END PGP SIGNATURE-
Accepted deb-gview 0.3.4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 28 Sep 2023 16:23:22 +0200 Source: deb-gview Architecture: source Version: 0.3.4 Distribution: unstable Urgency: medium Maintainer: Josef Schneider Changed-By: Josef Schneider Changes: deb-gview (0.3.4) unstable; urgency=medium . * configure.ac: Increase version to 0.3.4. * deb-gview.1.xml.in: + Change help argument to -h. + Add information for version argument. * src/dvarchive.c: Print errors to stderr. * src/main.c: Add/reformat -h,--help and -v,--version command line options. * debian/tests: Add autopkgtest files. * debian/copyright: Remove unnecessary Upstream-Name field. Checksums-Sha1: e10222509b1c8f722ca67cfc52124a0e77117bfd 1682 deb-gview_0.3.4.dsc e581363fb4b21598c07eed3aee4d6efe3ca09b51 79728 deb-gview_0.3.4.tar.xz a915bb13c722766543c6836fe9abb9fbecace9e8 15172 deb-gview_0.3.4_amd64.buildinfo Checksums-Sha256: 8951e5cfd3c8296102474fd1d2b0bc88e214dbaccad8dd66b8673bf2ef3516d3 1682 deb-gview_0.3.4.dsc e64435ae73771cf1b4062907e7b327ead8396539d29f1bf51975f991d14d09e8 79728 deb-gview_0.3.4.tar.xz 808a8632e19ea72b558a757557a7efd5557e29b90a7972e5a405e82ef7c82db0 15172 deb-gview_0.3.4_amd64.buildinfo Files: 06c099848359e2d97e518216d0eebb05 1682 utils optional deb-gview_0.3.4.dsc 04a5091b174d126b7039a3c395c39094 79728 utils optional deb-gview_0.3.4.tar.xz ea34af6edfc7dca436596076e48bf3fe 15172 utils optional deb-gview_0.3.4_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEMsxJDlpwsj3Wqlqyouuu0bb5AkEFAmUwoSIACgkQouuu0bb5 AkGLhRAAg1HNqQnmidredLbm61XF57JVUHTrLwh4w8q2Ujv48azC6pL62Q5v//dW RHw1m/zoTP+z/4ZOTe4p5q2yxsjulzqIcQVN5PQ3dTzr7sZMcQw2N6mZ3OKsAbpZ mCdalZB/+++M8hTuOU4T5Wcgbm4atDzycEClN6WAvcG2VZn6Qxl2f/IFOfQwDu+i OHTdBLaIGzVdEO69WeKBl9aP0v40tdoJBO8gM1D1brspHegxs0iFZ+XuiS5uCHCD pasIvQIVcjEvnQ8pulJW0W7/X2QWA8PC3thMPHBxh0sLiVEF8/AcCQTZMkROytO7 yVpydtXBFSJdEoM0LYp9wmUnLiBgtAORh9I9GhzZ9U38flpcC3RbdbuasSmuZ+hQ BQWhxP7IpjUaOB0O1Vqmkjyzqsx6n5iIXHu/paT+/qU41qBPa3H9wVwlIMRaxESG ysAEXBPP6M9rv6pQVXAhOmJRY9Q9Z3CpuRTiMmvDQ3t0xt5vboHM++5UsKvUU0xm BZ9kflU+YqD+QPsKcS7b8jZrDZ4MR9MYQfU8AUdk3RTg/JiHxB+7K+GeNTXKAap2 Xs+m1EJl1Fs6l8nQdBSoa+3b6BMPJ+CQ+Ramm0qtZ87TxxYgGYSaPdYwHK3HfG3Z p/g6PO46xOdC5M4L7Q9CxxAwSJVx2bF50mlSIJiQ+uQq9NXs6xg= =Dp6j -END PGP SIGNATURE-
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On Tue, Sep 19, 2023 at 11:39:49AM +0200, Johannes Schauer Marin Rodrigues wrote: > I was about to say that zdebootstrap by Adam Borowski used to be a thing four > years ago but now I see another commit from two days ago so maybe it's still > alive and usable? > > https://git.sr.ht/~kilobyte/zdebootstrap At the moment, all it can do is unpack packages, but a blocker for even continuing with dpkg would be registering triggers. Other problems: * the base set includes diverts now; I would need to know them _beforehand_. This means available from the control tarball, or preferably even Packages. Shipping a list would notoriously get out of sync, thus is only an option for past packages. * parallel debootstrapping is for obvious reasons utterly incompatible with usrmerge or any other kind of random package sabotaging the layout behind dpkg's back. When/if DEP17 gets implemented, such alias mangling would be doable but symlinks would still be a nasty thing. I'd also need to see what Pre-Depends can't be cheated away; as far as I've found so far, all are needed for upgrades or preinst, otherwise degrading them to Depends is workable -- but potential for breakage is huge. Likewise cheating on preinst. Also I'd really need to mark zdebootstrapped systems as tainted somehow, as they wouldn't be trustworthy until a lot of polishing and testing is done. > There is also my package mmdebstrap which gives you a Debian chroot a few > times > faster than debootstrap does. Here are some benchmarks from my laptop: > > | variant | mmdebstrap | debootstrap | > | - | -- | | > | essential | 9.52 s | n.a | > | apt | 10.98 s| n.a | > | minbase | 13.54 s| 26.37 s | > | buildd| 21.31 s| 34.85 s | > | standard | 23.01 s| 48.83 s | That's so insanely bad... if we only could put dpkg developers' time to some productive task instead of you-know-what. Even without breaking any of current guarantees, you can easily: * parallelize unpack stages * replace the status database with something not terrible WRT the second point: the only benefit of the current scheme is that, on a filesystem that corrupts the data on crash even if you do everything right, the user can do hail-mary manual recovery. If you stop caring about ext2 and vfat, we can do much better. And even dropping the flat text file format wouldn't be required if we 1. extended the "updates" log, 2. didn't rewrite the status file so often. Of course, this would require all readers to understand "updates" at which point we can just as well go with a binary database, but it's not like good key-value stores are far between, nor hard to devise from scratch. It's depressing how lesser distributions can be so much faster, despite us being supposed to be the bestest, prettiest, and so on :p (I'd continue this discussion, but ATM stuck in Abu Dhabi for 14 hours with no power source, then needing a week of sleep...) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up. This ⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project. ⠈⠳⣄
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
Hi, Quoting Thomas Goirand (2023-09-19 09:50:45) > I'm not sure if we should switch to zstd, or if xz will do the work, though > I'd be delighted if the dpkg performances could be improved. I'm spending all > of my days installing server, sometimes with 1.5 TB of RAM and 128 core (AMD > Epyc...), on last gen NVMe, using a local mirror, it's really painful to see > how slow the debootstrap process is, compared to what it could be. Unpacking > multiple .deb at the same time seems a very good idea to me, as well as > parallelizing everything we can. I was about to say that zdebootstrap by Adam Borowski used to be a thing four years ago but now I see another commit from two days ago so maybe it's still alive and usable? https://git.sr.ht/~kilobyte/zdebootstrap There is also my package mmdebstrap which gives you a Debian chroot a few times faster than debootstrap does. Here are some benchmarks from my laptop: | variant | mmdebstrap | debootstrap | | - | -- | | | essential | 9.52 s | n.a | | apt | 10.98 s| n.a | | minbase | 13.54 s| 26.37 s | | buildd| 21.31 s| 34.85 s | | standard | 23.01 s| 48.83 s | Depending on your use-case you might be interested in the essential or apt variants which are even faster because they install less stuff than "minbase". Thanks! cheers, josch signature.asc Description: signature
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On 9/16/23 07:01, Hideki Yamane wrote:
* So, if we change {data,control}.tar file format in .deb from xz to zst,
we can reduce package installation time than ever since less decompression
time. It saves our lifetime a bit :)
* Downside: package file size is a bit larger than now, but enough bandwidth
will ease it for download time
- Not sure how repository size will be, need an experiment
Hi,
I'm not sure if we should switch to zstd, or if xz will do the work,
though I'd be delighted if the dpkg performances could be improved. I'm
spending all of my days installing server, sometimes with 1.5 TB of RAM
and 128 core (AMD Epyc...), on last gen NVMe, using a local mirror, it's
really painful to see how slow the debootstrap process is, compared to
what it could be. Unpacking multiple .deb at the same time seems a very
good idea to me, as well as parallelizing everything we can.
Just my 2 cents, as I wont be working on this,
Cheers,
Thomas Goirand (zigo)
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
Hi,
On Mon, Sep 18, 2023 at 4:20 PM Helmut Grohne wrote:
>
> Hi,
>
> On Sat, Sep 16, 2023 at 10:31:20AM +0530, Hideki Yamane wrote:
> > Today I want to propose you to change default compression format in .deb,
> > {data,control}.tar."xz" to ."zst".
> >
> > I want to hear your thought about this.
>
> I am not very enthusiastic about this idea. I skip over those arguments
> already raised by others and add one that I haven't seen thus far. zstd
> is quite optimized for 64bit CPUs and for amd64 in particular. amd64 is
> the only architecture for which zstd provides a hufmann implementation
> in assembly.
>
> > ## More CPUs
> >
> > 2012: ThinkPad L530 has Core i5-3320M (2 cores, 4 threads)
> > 2023: ThinkPad L15 has Core i5-1335U (10 cores, 12 threads)
> >
> >
> > https://www.cpubenchmark.net/compare/817vs5294/Intel-i5-3320M-vs-Intel-i5-1335U
> > - i5-3320M: single 1614, multicore 2654
> > - i5-1335U: single 3650, multicore 18076 points.
>
> While the majority of CPUs in active deployments is amd64, I'd also like
> to see numbers for 32bit CPUs and non-x86 ones. While I personally find
> the trade-off by zstd fit for a number of my use cases, I was also
> surprised just how slow it decompresses on armhf.
>
> I found some arm board with some linux kernel package sized 36MB.
>
> algo | compressed size | decompression time
> --+-+---
> xz | 36MB| 14.7s
> zstd | 52MB| 5.2s
> zstd -9 | 48MB| 5.2s
> zstd -11 | 47MB| 5.4s
> zstd -19 | 41MB| 5.7s
>
> Not as slow as I remembered apparently, but it still has a more than 10%
> size overhead. The size ratio is consistent with Robert Edmond's
> numbers, but we no longer see that 10-fold speedup. And this did not
> look at decompression memory requirements.
>
> I am decompressing a *lot* of .debs (dedup.d.n, multiarch hinter,
> crossqa.d.n, dumat). All of these applications would benefit from zstd
> compressed .debs in terms of decompression speed. Yet, that has never
> been the bottleneck to me. To me, download speed matters more and
> swapping out a 1GBit link for a faster one isn't that easy.
>
> I'd vote against this given the data we have now.
>
> Can we defer the discussion until there are more convincing numbers?
>
> Helmut
>
If even Helmut voted against, I also vote and I package both for Arch
and Debian, I didn't notice that much of a difference in performance
for compression/decompression. But I use an NVME on the machine (it's
usually very fast along with a processor that isn't slow either) I use
to compile the packages I work with. But when you say that the numbers
are not that convincing, I agree.
--
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-
mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
Hi,
On Sat, Sep 16, 2023 at 10:31:20AM +0530, Hideki Yamane wrote:
> Today I want to propose you to change default compression format in .deb,
> {data,control}.tar."xz" to ."zst".
>
> I want to hear your thought about this.
I am not very enthusiastic about this idea. I skip over those arguments
already raised by others and add one that I haven't seen thus far. zstd
is quite optimized for 64bit CPUs and for amd64 in particular. amd64 is
the only architecture for which zstd provides a hufmann implementation
in assembly.
> ## More CPUs
>
> 2012: ThinkPad L530 has Core i5-3320M (2 cores, 4 threads)
> 2023: ThinkPad L15 has Core i5-1335U (10 cores, 12 threads)
>
>
> https://www.cpubenchmark.net/compare/817vs5294/Intel-i5-3320M-vs-Intel-i5-1335U
> - i5-3320M: single 1614, multicore 2654
> - i5-1335U: single 3650, multicore 18076 points.
While the majority of CPUs in active deployments is amd64, I'd also like
to see numbers for 32bit CPUs and non-x86 ones. While I personally find
the trade-off by zstd fit for a number of my use cases, I was also
surprised just how slow it decompresses on armhf.
I found some arm board with some linux kernel package sized 36MB.
algo | compressed size | decompression time
--+-+---
xz | 36MB| 14.7s
zstd | 52MB| 5.2s
zstd -9 | 48MB| 5.2s
zstd -11 | 47MB| 5.4s
zstd -19 | 41MB| 5.7s
Not as slow as I remembered apparently, but it still has a more than 10%
size overhead. The size ratio is consistent with Robert Edmond's
numbers, but we no longer see that 10-fold speedup. And this did not
look at decompression memory requirements.
I am decompressing a *lot* of .debs (dedup.d.n, multiarch hinter,
crossqa.d.n, dumat). All of these applications would benefit from zstd
compressed .debs in terms of decompression speed. Yet, that has never
been the bottleneck to me. To me, download speed matters more and
swapping out a 1GBit link for a faster one isn't that easy.
I'd vote against this given the data we have now.
Can we defer the discussion until there are more convincing numbers?
Helmut
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
Hallo,
* Hideki Yamane [Sat, Sep 16 2023, 10:31:20AM]:
> Today I want to propose you to change default compression format in .deb,
> {data,control}.tar."xz" to ."zst".
I tend to agree but...
> # Compared to past change to xz proposal (in DebConf12)
>
> There are reasons why I propose this
>
> * More bandwidth
You mean more _network_ bandwidth.
> * More CPUs
You mean more _cores_ (but not necessarily faster cores).
> According to https://www.speedtest.net/global-index, broadband bandwidth
> in Nicaragua becomes almost 10x
Yes, the question of "10 times more CPU burning vs. saving 10 percent of
data size" has become not so easy nowadays.
> ## More CPUs
>
> 2012: ThinkPad L530 has Core i5-3320M (2 cores, 4 threads)
> 2023: ThinkPad L15 has Core i5-1335U (10 cores, 12 threads)
>
>
> https://www.cpubenchmark.net/compare/817vs5294/Intel-i5-3320M-vs-Intel-i5-1335U
> - i5-3320M: single 1614, multicore 2654
> - i5-1335U: single 3650, multicore 18076 points.
> And, xz cannot use multi core CPUs for decompression but zstd can.
> It means that if we use xz, we just get 2x CPU power, but change to zst,
> we can get more than 10x CPU power than 2012.
>
> It reduces a lot of time for package installation.
When the network bandwith is cheap then it surely is. But something I do
not like in this trade-off is the question of energy consumption resp.
CO2 emissions. What exactly does the faster processing mean in terms of
the environment impact mean, and how much (i.e. delays) can we expect
from our users here?
Anyway, my overall gut feeling after dealing with compression issues
(and wearing my "unp" and "apt-cacher-ng" upstream hat) is that Zstd is
a slightly better default option for compression for typical binary
files. There are a some special cases in certain contexts where other
compressor (even bzip* for source code) can be more sensible, so those
option should remain available. But as rule of thumb, Zstd looks like
the better way to go.
Best regards,
Eduard.
signature.asc
Description: PGP signature
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On Sun, 2023-09-17 at 22:16 +0200, Joerg Jaspert wrote: > > I do not think wasting space is any good idea. > > > ## More bandwidth > > According to https://www.speedtest.net/global-index, broadband > > bandwidth > > in Nicaragua becomes almost 10x > > And elsewhere it may have gone up a different factor. > Still, there are MANY places where its still bad. I fully agree. I forgot to mention this point in my other response in the thread. The thing is, while the average bandwidth do increase as time goes by, the bottom-1% will not likely increase like that. In many corners in the world, people are still using poor and expensive network. Those networks might be even metered. Significantly bloating up the mirror size will directly increase the metered network bill for those people. I was one of them. It will also increase the pressure on mirror hosting. Some universities host linux mirrors on their own. Debian is always the most bulky repository to mirror. They are not always commercially supported -- sometimes supported only by volunteer's funds. A significantly bloated up debian mirrors can make their life more difficult. Things can be worse if they the uploading bandwidth is limited of even metered. I was one of such hosts. I know, this is a difficult trade-off between Debian's accessibilty and software performance. > > And, xz cannot use multi core CPUs for decompression but zstd can. > > It means that if we use xz, we just get 2x CPU power, but change > > to > > zst, > > we can get more than 10x CPU power than 2012. > > In ideal conditions, maybe, but still, thats the first (to me) good > reason. IMO not good enough to actually do it. > > > - Not sure how repository size will be, need an experiment > > And keep in mind the repository is mirrored a trillion times, stored > in > snapshots, burned into images here and there, so any "small" increase > in > size actually means a *huge* waste in the end. > > If we switch formats, going to something that's at least as good as > the > one we currently have should be the goal. (And I do not mean > something > like "its code/algorithm is bad", really, that argument is dead > before > it begins even). > > Now, thats for .debs. There might be a better argument when talking > about the index files in dists/, they are read so much more often, it > *may* make more sense there. >
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
Stephan Verbücheln wrote... > If you want to open that debate (again?), one should probably switch to > lzip. It uses the same LZMA compression like xz, but has a way more > sane file format. Besides the fact dpkg already has zstd support while lzip is missing, so that was a way bigger changes: In case you've missed that, lzip is not a mine field in Debian, it's completely burnt ground. It's better to never mention it. Christoph signature.asc Description: PGP signature
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On 16988 March 1977, Hideki Yamane wrote:
Today I want to propose you to change default compression format in
.deb,
{data,control}.tar."xz" to ."zst".
I want to hear your thought about this.
Negative.
# Compared to past change to xz proposal (in DebConf12)
* More bandwidth
* More CPUs
* More storage bandwidth
Get us actual numbers please on how much a full Debian mirror would
increase in size.
Also consider services like snapshots.
I do not think wasting space is any good idea.
## More bandwidth
According to https://www.speedtest.net/global-index, broadband
bandwidth
in Nicaragua becomes almost 10x
And elsewhere it may have gone up a different factor.
Still, there are MANY places where its still bad.
And, xz cannot use multi core CPUs for decompression but zstd can.
It means that if we use xz, we just get 2x CPU power, but change to
zst,
we can get more than 10x CPU power than 2012.
In ideal conditions, maybe, but still, thats the first (to me) good
reason. IMO not good enough to actually do it.
- Not sure how repository size will be, need an experiment
And keep in mind the repository is mirrored a trillion times, stored in
snapshots, burned into images here and there, so any "small" increase in
size actually means a *huge* waste in the end.
If we switch formats, going to something that's at least as good as the
one we currently have should be the goal. (And I do not mean something
like "its code/algorithm is bad", really, that argument is dead before
it begins even).
Now, thats for .debs. There might be a better argument when talking
about the index files in dists/, they are read so much more often, it
*may* make more sense there.
--
bye, Joerg
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
If you want to open that debate (again?), one should probably switch to lzip. It uses the same LZMA compression like xz, but has a way more sane file format. Also note that the (pretended) multi-threading-capability of xz is mostly based on its improper file format[1]: > The xz-utils manual says that LZMA2 is an updated version of LZMA to > fix some practical issues of LZMA. This wording suggests that LZMA2 > is some sort of improved LZMA algorithm. (After all, the 'A' in LZMA > stands for 'algorithm'). But LZMA2 is a container format that divides > LZMA data into chunks in an unsafe way. Regards [1] https://www.nongnu.org/lzip/xz_inadequate.html signature.asc Description: This is a digitally signed message part
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On Sun, Sep 17, 2023 at 09:31:03AM +0530, Hideki Yamane wrote: > On Sat, 16 Sep 2023 13:34:02 +0200 > Guillem Jover wrote: > > That's not correct. dpkg-deb is doing multi-threaded xz decompression > > since 1.21.13, and dpkg-source is doing multi-threaded xz compression > > and decompression since 1.21.14. > > > > Also the Ubuntu zstd implementation did not have multi-threaded support > > at all, the one implemented in dpkg 1.21.18 does have explicit > > multi-threaded support for _compression_, but AFIUI (from zstd code and > > its API being used in libdpkg) not for decompression. > > Thank you, that was my fault, correct information is very welcoming. > > Is there any plan to improve zstd implementation in dpkg? FWIW, if people think that it would be beneficial for libzstd to be built against libpthread (which seems to be the only way it supports multithreaded operation right now), this could be arranged - I just never thought anybody wanted that until now. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On Sat, 16 Sep 2023 14:25:48 -0400 "M. Zhou" wrote: > Be careful if it bloats up our mirrors. Is there any estimate on > the extra space cost for a full debian mirror? Yes, sure, I'll do some experiment for it later. Thank you for your comment! -- Hideki Yamane
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On Sat, 16 Sep 2023 13:34:02 +0200 Guillem Jover wrote: > That's not correct. dpkg-deb is doing multi-threaded xz decompression > since 1.21.13, and dpkg-source is doing multi-threaded xz compression > and decompression since 1.21.14. > > Also the Ubuntu zstd implementation did not have multi-threaded support > at all, the one implemented in dpkg 1.21.18 does have explicit > multi-threaded support for _compression_, but AFIUI (from zstd code and > its API being used in libdpkg) not for decompression. Thank you, that was my fault, correct information is very welcoming. Is there any plan to improve zstd implementation in dpkg? -- Hideki Yamane
Re: Performance counter stats Was Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
Lee wrote: > What did you do to get the "Performance counter stats" section in the > results for time? alias time="perf stat" -- Robert Edmonds edmo...@debian.org
Performance counter stats Was Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On 9/16/23, Robert Edmonds wrote: > $ time xz -v -k -T0 -6 data.tar > data.tar (1/1) > 100 %71.9 MiB / 452.5 MiB = 0.15921 MiB/s 0:21 > > Performance counter stats for 'xz -v -k -T0 -6 data.tar': > > 206,070.39 msec task-clock #9.602 CPUs > utilized > 10,333 context-switches # 50.143 /sec > 35 cpu-migrations #0.170 /sec > 73,502 page-faults # 356.684 /sec >925,351,049,292 cycles #4.490 GHz >945,596,486,369 instructions #1.02 insn per > cycle >106,039,632,660 branches # 514.580 M/sec > 6,702,750,057 branch-misses#6.32% of all > branches > > 21.460119122 seconds time elapsed > > 205.460711000 seconds user >0.567559000 seconds sys What did you do to get the "Performance counter stats" section in the results for time? TIA, Lee
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
M. Zhou wrote: > Just one comment. > > Be careful if it bloats up our mirrors. Is there any estimate on > the extra space cost for a full debian mirror? > > If we trade-off the disk space with decompression speed, zstd -19 > is not necessarily very fast. I did not benchmark, but it is slow. Anecdotally, for "linux-image-6.5.0-1-amd64_6.5.3-1_amd64.deb" the data.tar component takes 72 MB when compressed with xz -6, and 80 MB when compressed with zstd -19, so about 10% larger with zstd. This is specifically with multi-threaded compression. The behavior of -T0 between xz and zstd is slightly different. (It looks like xz -T0 uses the number of threads supported by the CPU while zstd -T0 uses the number of physical cores in the CPU.) The most direct multi-threaded compression comparison between the two compressors was: $ time xz -v -k -T0 -6 data.tar data.tar (1/1) 100 %71.9 MiB / 452.5 MiB = 0.15921 MiB/s 0:21 Performance counter stats for 'xz -v -k -T0 -6 data.tar': 206,070.39 msec task-clock #9.602 CPUs utilized 10,333 context-switches # 50.143 /sec 35 cpu-migrations #0.170 /sec 73,502 page-faults # 356.684 /sec 925,351,049,292 cycles #4.490 GHz 945,596,486,369 instructions #1.02 insn per cycle 106,039,632,660 branches # 514.580 M/sec 6,702,750,057 branch-misses#6.32% of all branches 21.460119122 seconds time elapsed 205.460711000 seconds user 0.567559000 seconds sys Versus: $ time zstd -T0 --auto-threads=logical -19 data.tar data.tar : 17.54% ( 452 MiB => 79.3 MiB, data.tar.zst) Performance counter stats for 'zstd -T0 --auto-threads=logical -19 data.tar': 293,120.46 msec task-clock #8.649 CPUs utilized 21,754 context-switches # 74.215 /sec 78 cpu-migrations #0.266 /sec 9,806 page-faults # 33.454 /sec 1,317,565,940,985 cycles #4.495 GHz 1,430,204,017,430 instructions #1.09 insn per cycle 266,246,644,005 branches # 908.318 M/sec 5,762,322,300 branch-misses#2.16% of all branches 33.889831439 seconds time elapsed 292.501337000 seconds user 0.56756 seconds sys So, 71.9 MiB in 21 seconds for xz -6 versus 79.3 MiB in 34 seconds for zstd -19. In other words, xz is 91% the size and 63% the wallclock time of zstd here. zstd decompression is much, much faster than xz decompression, but apparently zstd does not support multi-threaded decompression while xz does. Here xz decompresses in about 120% the wallclock time of zstd (about 0.6 seconds for xz vs 0.5 seconds for zstd) but is only able to perform that well by occupying most of the CPU: $ time xzcat -v -T12 data.tar.xz > /dev/null data.tar.xz (1/1) 100 %71.9 MiB / 452.5 MiB = 0.159 Performance counter stats for 'xzcat -v -T12 data.tar.xz': 5,434.51 msec task-clock #8.720 CPUs utilized 1,187 context-switches # 218.419 /sec 22 cpu-migrations #4.048 /sec 24,119 page-faults #4.438 K/sec 24,311,239,346 cycles #4.473 GHz 21,196,398,588 instructions #0.87 insn per cycle 2,841,057,067 branches # 522.781 M/sec 296,751,808 branch-misses# 10.45% of all branches 0.623224953 seconds time elapsed 5.304562000 seconds user 0.127532000 seconds sys $ time zstdcat -v -T12 data.tar.zst > /dev/null Warning : decompression does not support multi-threading Performance counter stats for 'zstdcat -v -T12 data.tar.zst': 559.03 msec task-clock #1.075 CPUs utilized 4,245 context-switches #7.593 K/sec 5 cpu-migrations #8.944 /sec 1,032 page-faults #1.846 K/sec 2,519,428,855 cycles #4.507 GHz 5,752,165,946 instructions #2.28 insn per cycle 943,510,461 branches #1.688 G/sec 17,026,238 branch-misses#1.80% of all branches 0.520219563 seconds time elapsed 0.518084000 seconds user 0.044177000 seconds sys If xzcat is res
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
Just one comment.
Be careful if it bloats up our mirrors. Is there any estimate on
the extra space cost for a full debian mirror?
If we trade-off the disk space with decompression speed, zstd -19
is not necessarily very fast. I did not benchmark, but it is slow.
On Sat, 2023-09-16 at 10:31 +0530, Hideki Yamane wrote:
> Hi,
>
> Today I want to propose you to change default compression format in
> .deb,
> {data,control}.tar."xz" to ."zst".
>
> I want to hear your thought about this.
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On Sat, Sep 16, 2023 at 10:31:20AM +0530, Hideki Yamane wrote:
> Today I want to propose you to change default compression format in .deb,
> {data,control}.tar."xz" to ."zst".
> According to https://www.speedtest.net/global-index, broadband bandwidth
> in Nicaragua becomes almost 10x
>
> - 2012: 1.7Mbps
> - 2023: 17.4Mbps
>
> 10x faster than past: it means that file size is not so much problem for us
That's broadband, a lot of folks have nothing but crappy 5G.
I just happen to have a package converted to multiple formats on the disk
because I tested/benchmarked format 0.939 vs 2.0[1]. And:
-h bytes
tar 5.5G5839735844
gz 897M 939926960
xz 375M 392874208
zst 774M 811105258
For this particular package zst gives over twice as big file. You can pick
a stronger compression level but at that point we're just going up the
tradeoff curve.
> ## More CPUs
>
> 2012: ThinkPad L530 has Core i5-3320M (2 cores, 4 threads)
> 2023: ThinkPad L15 has Core i5-1335U (10 cores, 12 threads)
>
>
> https://www.cpubenchmark.net/compare/817vs5294/Intel-i5-3320M-vs-Intel-i5-1335U
> - i5-3320M: single 1614, multicore 2654
> - i5-1335U: single 3650, multicore 18076 points.
>
> And, xz cannot use multi core CPUs for decompression but zstd can.
> It means that if we use xz, we just get 2x CPU power, but change to zst,
> we can get more than 10x CPU power than 2012.
As someone with a 64-way amd64 desktop, and a purchased-but-not-delivered
64-core riscv64 box on the way, I understand the sentiment -- but, what
about parallelizing by unpacking multiple packages at the same time instead?
That's safer and doesn't cost compressing ratio[2]. I've prototyped this,
and even with current dpkg internals it shouldn't be hard to do (even if
dpkg runs keep switching between unpacking and configuring too often).
> It reduces a lot of time for package installation.
There's a lot lot lot of other places in dpkg that could use a speedup, and
they don't come with such a tradeoff. Especially fsync abuse: dpkg writes
all of its status every. single. step., fully. flushing. it. to. persistent.
storage. even. if. it's. a. dingy. SD. card. So it does for every file it
unpacks; to a semi-ignorant onlooker it seems as if it uses some sort of
range coder just so it can fsync between fractional bits.
Even though there's no good generic way to ensure consistency of extracted
payload (POSIX lacks such API, you can use btrfs snapshots), at least the
dpkg state could win a lot by stopping assuming the limitations of ext2
apply to other filesystems. On ext2 a crash may do unbounded damage to
the filesystem, using flat text files and fsyncs between every operation
improves recoverability, but any filesystem newer than that adds better
guarantees. There are so many techniques that would avoid full state
rewrites...
> ## More storage bandwidth
>
> SSD + PCIe 3/4/5 is enough, not be a blocker for decompression, now.
So wishing Optane NVDIMMs didn't get cancelled... :/
On the other hand, we could switch the compression for _some_ packages.
There's stuff that gets unpacked by buildds over and over. Compilers and
library headers are not used much by end-users on dingy connections (and
us hackers tend to prioritize computing device spending compared to regular
people), thus what about switching stuff that's 1. not in build-essential
but 2. in a set shared by many Build-Deps?
Meow!
[1]. https://lists.debian.org/debian-dpkg/2023/09/msg00014.html
[2]. Parallel compression, and especially decompression, is done by
flushing and dropping old state every block.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Bestest pickup line:
⢿⡄⠘⠷⠚⠋⠀ "Cutie, your name must be Suicide, cuz I think of you every day."
⠈⠳⣄
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
Hi!
On Sat, 2023-09-16 at 10:31:20 +0530, Hideki Yamane wrote:
> ## More bandwidth
>
> According to https://www.speedtest.net/global-index, broadband bandwidth
> in Nicaragua becomes almost 10x
>
> - 2012: 1.7Mbps
> - 2023: 17.4Mbps
Well that page still does not look too great for many other countries,
including with fixed broadband.
> ## More CPUs
>
> 2012: ThinkPad L530 has Core i5-3320M (2 cores, 4 threads)
> 2023: ThinkPad L15 has Core i5-1335U (10 cores, 12 threads)
>
>
> https://www.cpubenchmark.net/compare/817vs5294/Intel-i5-3320M-vs-Intel-i5-1335U
> - i5-3320M: single 1614, multicore 2654
> - i5-1335U: single 3650, multicore 18076 points.
>
> And, xz cannot use multi core CPUs for decompression but zstd can.
> It means that if we use xz, we just get 2x CPU power, but change to zst,
> we can get more than 10x CPU power than 2012.
That's not correct. dpkg-deb is doing multi-threaded xz decompression
since 1.21.13, and dpkg-source is doing multi-threaded xz compression
and decompression since 1.21.14.
Also the Ubuntu zstd implementation did not have multi-threaded support
at all, the one implemented in dpkg 1.21.18 does have explicit
multi-threaded support for _compression_, but AFIUI (from zstd code and
its API being used in libdpkg) not for decompression.
> It reduces a lot of time for package installation.
> * So, if we change {data,control}.tar file format in .deb from xz to zst,
> we can reduce package installation time than ever since less decompression
> time. It saves our lifetime a bit :)
>
> * Downside: package file size is a bit larger than now, but enough bandwidth
> will ease it for download time
> - Not sure how repository size will be, need an experiment
Thus these seem rather hand-wavy.
And in addition support for zstd at least in Debian seems rather poor:
https://wiki.debian.org/Teams/Dpkg/DebSupport
(Support in dpkg was mainly added to overcome the schism that Ubuntu
had created in the .deb format. :/)
Thanks,
Guillem
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
I think it's a good idea now that dpkg supports it [1]. Ubuntu already did it years ago [2], and some non-deb based distros as well (e.g. Fedora, Arch). Cheers, Stephan [1]: https://bugs.debian.org/892664 [2]: https://balintreczey.hu/blog/hello-zstd-compressed-debs-in-ubuntu/
[idea]: Switch default compression from "xz" to "zstd" for .deb packages
Hi,
Today I want to propose you to change default compression format in .deb,
{data,control}.tar."xz" to ."zst".
I want to hear your thought about this.
# Compared to past change to xz proposal (in DebConf12)
There are reasons why I propose this
* More bandwidth
* More CPUs
* More storage bandwidth
## More bandwidth
According to https://www.speedtest.net/global-index, broadband bandwidth
in Nicaragua becomes almost 10x
- 2012: 1.7Mbps
- 2023: 17.4Mbps
10x faster than past: it means that file size is not so much problem for us
## More CPUs
2012: ThinkPad L530 has Core i5-3320M (2 cores, 4 threads)
2023: ThinkPad L15 has Core i5-1335U (10 cores, 12 threads)
https://www.cpubenchmark.net/compare/817vs5294/Intel-i5-3320M-vs-Intel-i5-1335U
- i5-3320M: single 1614, multicore 2654
- i5-1335U: single 3650, multicore 18076 points.
And, xz cannot use multi core CPUs for decompression but zstd can.
It means that if we use xz, we just get 2x CPU power, but change to zst,
we can get more than 10x CPU power than 2012.
It reduces a lot of time for package installation.
## More storage bandwidth
SSD + PCIe 3/4/5 is enough, not be a blocker for decompression, now.
# Conclusion
* More bandwidth
* More CPUs
* More storage bandwidth
+
* Still limited: our resources (time!)
* So, if we change {data,control}.tar file format in .deb from xz to zst,
we can reduce package installation time than ever since less decompression
time. It saves our lifetime a bit :)
* Downside: package file size is a bit larger than now, but enough bandwidth
will ease it for download time
- Not sure how repository size will be, need an experiment
--
Hideki Yamane
Accepted deb-gview 0.3.3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 11 Sep 2023 18:43:01 +0200 Source: deb-gview Architecture: source Version: 0.3.3 Distribution: unstable Urgency: medium Maintainer: Josef Schneider Changed-By: Josef Schneider Changes: deb-gview (0.3.3) unstable; urgency=medium . * src/dvarchive.c: + Remove control.tar support for bzip2. + Fix for bug #718386 for deb(5) compliance. + Thanks to Guillem Jover for advising this fix. Checksums-Sha1: 7a2681594d47be649511e7c289dea7fa9e341d56 1621 deb-gview_0.3.3.dsc f9d888325a276eedba64f9cf3032947b29bd1a86 77600 deb-gview_0.3.3.tar.xz 5eb469d72af0e774f5b811f7b12217e0f2bed224 15091 deb-gview_0.3.3_amd64.buildinfo Checksums-Sha256: 8e194a047811dc8e00e906432875c8913efc0793fc78d42aa29df35e7eeb10a4 1621 deb-gview_0.3.3.dsc 56db1f5de8d2fefd18c89a738dbd7ebed5a2449686b17ad4924ecdd30bbd0b94 77600 deb-gview_0.3.3.tar.xz 8dab803f72b2c84b138e119cbce03877697574a2c345c8e7b450739729ea0973 15091 deb-gview_0.3.3_amd64.buildinfo Files: 60dcef53611ece5b6d2e3e04a758498d 1621 utils optional deb-gview_0.3.3.dsc 33f348af6a0dcda91e72240f89291481 77600 utils optional deb-gview_0.3.3.tar.xz d44de955d028fc3b5946e92e5099f9ff 15091 utils optional deb-gview_0.3.3_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEMsxJDlpwsj3Wqlqyouuu0bb5AkEFAmUBv14ACgkQouuu0bb5 AkEjFg/+IIM1xaHmuUHzffo8NbPgn/NxX9ZN3+S4d3+H7RM4RiPiBlNUx+9S01Ie U6d+pj51fWRsH9+RMWwvbIlBAZez+u1QoaV664eC7ZGLEWnITmIFLH1iyWLO/4h/ /v46ltKiCFKKqwrLEwXPFa8NLqSnXfPfmhv3AhfvrA3FSxNY1N62wYL+6r0yKkiN GnEBdNedH1tMFGHvtwGkjrgqqvtahjlCmYAwBGS09B3A8IuV+x3J3C7LeOsiZtz3 s6hyjWecV3o01ihQhijEPHByXDHbf43z1LuChc7vfLbRiKfxbAV401aQEU+R6UhY vYVPTe/yYALtySAWIbguCkzWxh/WZ7OVqBslfZ4FjXKfqEq0qsOsoFdYSvVaS+KF QmrUwg4crFB+kgNZ3EGeX022+Jf2cEiAi8pAUzOvnlTYS+TIi0H2wbcbQwIc0xoT VQXf0VyHATvFTgy78PEJV9+Ax2tQehmOJzpVOkkU4is/8XP6ZAP1KfyLdIZAPbx2 Z7sONh6QxpdQeXvA7izDm7qJ9IOZrjz4+ltXZpBiZACx8VNTqYAOIOTEkZH6t0t/ plxj//NV8uBvfMIEEhT67ANOjkGMYbQcruC/FJG+Qc/E1lUVRf8uem8km+FekV5C oON7QO2RZnAphJCgtkLvumFLP1kVM8f5Q1PzdyJWlX3BXY2OgEc= =jLPl -END PGP SIGNATURE-
Accepted deb-gview 0.3.2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 30 Aug 2023 16:51:44 +0200 Source: deb-gview Architecture: source Version: 0.3.2 Distribution: unstable Urgency: medium Maintainer: Josef Schneider Changed-By: Josef Schneider Closes: 718386 Changes: deb-gview (0.3.2) unstable; urgency=medium . * Upload to unstable after Debian 12 release. * src/dvarchive.c: + Add support for bzip2, lzma, zstd compressed members (Closes: #718386). * src/main.c: + Add optional version argument. * configure.ac: + Update version number in AC_INIT. + Add deb-gview.1.xml to AC_CONFIG_FILES. * deb-gview.1.xml.in: + Renamed from deb-gview.1.xml. + Use @VERSION@ and @PACKAGE@ placeholders. Checksums-Sha1: dcbca837f351f523225d46447d8b3dad0f1b57e8 1621 deb-gview_0.3.2.dsc 2b38e452f13842bbdc7a7f0aac803ad8ad091c3d 77584 deb-gview_0.3.2.tar.xz 404725d239f4cdf6094ae0e1b75e3cc79fa69105 15075 deb-gview_0.3.2_amd64.buildinfo Checksums-Sha256: 40cb2983665fb70c14df52dec9ed9d954d3ef567ceea172ca942d5d49e02be14 1621 deb-gview_0.3.2.dsc d278bda7f79fa7f13334ffeb171d0c07a69d18bede9cafa1dc197b4a1949a8ea 77584 deb-gview_0.3.2.tar.xz 1f35bf702285e5011ed68e91369f73eeff32bb5d4f72bac6cdb1f18604dbb470 15075 deb-gview_0.3.2_amd64.buildinfo Files: 05a2e64af9347e279df23b8444fcaf0a 1621 utils optional deb-gview_0.3.2.dsc 66ab00056416f0f5b4a9132b536f811e 77584 utils optional deb-gview_0.3.2.tar.xz 18c1e06d36211d676ce79fadf70889fc 15075 utils optional deb-gview_0.3.2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEMsxJDlpwsj3Wqlqyouuu0bb5AkEFAmT2vskACgkQouuu0bb5 AkFhbg//e0pbvJW04lD8xKRr2X/a9dsuGGIZYm6Mf5884v80guJ6ICWxRDIoUAhm w7h8NKWKfIOP3vaZ0YE5/CVrn2ot+9wJrr+If0QxzFw87Ui24dxSkBCybaqYroa6 TN76iBkZIQiFx6r4jgKvp+sW7CZ0uwEsFY/OSVToK6fvTKA3fQM+I6ae+DBoWnbO zLgE1L/5Q+M8P44/c6ZPN4SCw3E2e2pNrozjevoWNHXXUsj69bnv0cJF6Ylh37sP 3C3931KKj6QRpAbxdLmeUSHbMtq31JHRdjr4sSAXV0H14O/MKp3sPD6E0iKhJyGv Rs0eYfiznKnLut+4dUc/iRgb+DPxDaBHJ3FTrd0oGTrLsZjakkGy9OQR2/Zc4tI5 7jA6BrJV79WD8EE7KWTr4AWvfu8zRHVBpK/p6pfrUxdEWotCNfd5D6CVy08xWXfx /v6mYLPlpz2djwh4A/4N3xt1CyqWEJI/eZK+9gahYEG+uGOaUZ42GX1wWMKpmnqJ ywKboS4mQj7+xdosCMBAFlPQLjBncSt9gi/1ryBeBI6p4OEkb0j1fSLPl7X5yIx1 kFq6E3vVHcLYq1SRvUY8BX41Ql0NtpZHip0aB5X2qPQGRABo5xzleAMSe758TUGS wY0DfdAwD/4mGJSdGiG0fJOYaV/JB72mHgkfr0YDmlfnLllLqfA= =l6vU -END PGP SIGNATURE-
Accepted coccinelle 1.1.1.deb-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 27 Aug 2023 19:32:03 +0200 Source: coccinelle Architecture: source Version: 1.1.1.deb-5 Distribution: unstable Urgency: medium Maintainer: Debian OCaml Maintainers Changed-By: Stéphane Glondu Closes: 1050620 Changes: coccinelle (1.1.1.deb-5) unstable; urgency=medium . [ Stéphane Glondu ] * Team upload . [ Bastian Germann ] * Drop pcre support (Closes: #1050620) Checksums-Sha1: 88aef0f76ce666437538f7290a0891c0eca898b0 2191 coccinelle_1.1.1.deb-5.dsc 7f35f70bb9bce20bfe0c4d35869cabe50f864b5b 12432 coccinelle_1.1.1.deb-5.debian.tar.xz Checksums-Sha256: a952a73463e6994613a0009d8e44ed77a3dae1ea63a8f8d86bfad9d113ad859d 2191 coccinelle_1.1.1.deb-5.dsc 7482214e55b86cd1d3c64bfb1da83d4d37a15a7f68ad1b447dae641769934681 12432 coccinelle_1.1.1.deb-5.debian.tar.xz Files: 66af92ca53e07b7bb5e4d14f5ab624f0 2191 devel optional coccinelle_1.1.1.deb-5.dsc 1e612d11da45383ca59fd76acf540ab2 12432 devel optional coccinelle_1.1.1.deb-5.debian.tar.xz -BEGIN PGP SIGNATURE- iQFGBAEBCgAwFiEEbeJOl+yohsxW5iUOIbju8bGJMIEFAmTrid8SHGdsb25kdUBk ZWJpYW4ub3JnAAoJECG47vGxiTCBn0AH/i7dTlWZImYLP6w4h+IH7c38eH/N0M4E T65Uqkcvc+2SuZOwgT5WfPNDaU88C6c6CTrxCMxWpdD4TNj047XFsV0hxcIW+e6L 0P7mJBkTdkOxh103EUv9q0jPxcXDbAjU3OIWn/m4eDwJq1ztv57HghS2WnEDss48 NOwNzFNXwQUSL/L8RVh1kO/BFHnus9Xr9N4IlmF/ru09tllhLwNd2+DOAcpWaK2m UZtdDw7Vm3yZFupAH9QIP9IigVE1NvIsrr0vxghnP0nTOOa2j3+MtS6pe+CDsztV +HZChv7nX849JIGBOEgebRw4b0ZklQfqkK5Oisq2fTAHP7tcloU30nU= =xBWN -END PGP SIGNATURE-
Accepted coccinelle 1.1.1.deb-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 17 Aug 2023 13:35:00 +0200 Source: coccinelle Architecture: source Version: 1.1.1.deb-4 Distribution: unstable Urgency: medium Maintainer: Debian OCaml Maintainers Changed-By: Stéphane Glondu Closes: 1049958 Changes: coccinelle (1.1.1.deb-4) unstable; urgency=medium . * Team upload * Disable native code compilation on armhf (Closes: #1049958) and riscv64 Checksums-Sha1: f9c0bacfeb3dbe62d689a87a9884be7c78b58040 2210 coccinelle_1.1.1.deb-4.dsc b710b53000ebba436413a3b7ace50ea0f2333ea2 12400 coccinelle_1.1.1.deb-4.debian.tar.xz Checksums-Sha256: abbd3180ad2b507dc52575714f5a594296016f6279ea63587c13fbb4711bf592 2210 coccinelle_1.1.1.deb-4.dsc 669ad0d63c0f2f252ac14c7ef2da749958abcd36d127f0ee0cfb3f4ba9b843b0 12400 coccinelle_1.1.1.deb-4.debian.tar.xz Files: 257cb46bbe2312e8e2f09810ce289705 2210 devel optional coccinelle_1.1.1.deb-4.dsc 85479c72927cc91c499a5f2a4a12e8bf 12400 devel optional coccinelle_1.1.1.deb-4.debian.tar.xz -BEGIN PGP SIGNATURE- iQFGBAEBCgAwFiEEbeJOl+yohsxW5iUOIbju8bGJMIEFAmTeCkgSHGdsb25kdUBk ZWJpYW4ub3JnAAoJECG47vGxiTCBXeEH/2dDyqm9vhkDgJzzkAT3hS5NbEYQ76RP gJMqlTzNenkdtuBkx5l4YiemRxgoeKoy1+IWJqAhEO5KrdggLwwhQkzZ0X3Id5Gw nROePW1wCW+efJKG25LB7DKqMsVBSo8b4zrehFWp5JJnzCB37UFK+iCUnIKHo/1A QNVbPVqRHV5+ajNaiN+cCxklamKdTUKPwu7N+75uTs52Sxi4mUBSWUT0AI7Eeddh njo9T4H9++mux1eAQpA1vkSdCxNvHrboBKrgBrVvyNZE+9WZjZEiyFHKH9i5kezl TdOqAlGMf2n1joZOsqEJ24jrBOz3x3FrmV77ZMFfX4WDdrWrYWvPFFM= =JOci -END PGP SIGNATURE-
Accepted coccinelle 1.1.1.deb-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 08 Aug 2023 09:26:45 +0200 Source: coccinelle Architecture: source Version: 1.1.1.deb-3 Distribution: unstable Urgency: medium Maintainer: Debian OCaml Maintainers Changed-By: Stéphane Glondu Changes: coccinelle (1.1.1.deb-3) unstable; urgency=medium . [ Stéphane Glondu ] * Team upload * Bump Standards-Version to 4.6.2 . [ Debian Janitor ] * Remove constraints unnecessary since buster (oldstable): + Build-Depends: Drop versioned constraint on dh-ocaml (>= 1.0.3~). + Build-Depends: Drop versioned constraint on libmenhir-ocaml-dev (>= 20090204.dfsg). + Build-Depends: Drop versioned constraint on libparmap-ocaml-dev (>= 1.0~rc4-5~). + Build-Depends: Drop versioned constraint on menhir (>= 20090204.dfsg). + Build-Depends: Drop versioned constraint on ocaml-nox (>= 3.11.1-3~). + Build-Depends: Drop versioned constraint on pkg-config (>= 0.9.0). + coccinelle: Drop dependency on essential package dpkg (>= 1.17.14) in Pre-Depends. + coccinelle-doc: Drop conflict with removed package coccinelle (<< 1.0.0~rc7.deb-4) in Replaces. + coccinelle-doc: Drop conflict with removed package coccinelle (<< 1.0.0~rc7.deb-4) in Breaks. + Remove 1 maintscript entries from 1 files. Checksums-Sha1: 9b95880945ae3dceca1223cac7c4bdb70f9d8a76 2210 coccinelle_1.1.1.deb-3.dsc 07ab02727de266fcc83a664ada7ba4457e5adbe4 12296 coccinelle_1.1.1.deb-3.debian.tar.xz Checksums-Sha256: 3860e0d0b18bd8fb8e033fbd795a60cab46122b72517c90c44f6899be7127d81 2210 coccinelle_1.1.1.deb-3.dsc 53c82a07bde5795e9876be58ab1209049e28f87e1a2b2126232aace8bba79875 12296 coccinelle_1.1.1.deb-3.debian.tar.xz Files: c40a6d83fdd9ee26f9c663791570ea21 2210 devel optional coccinelle_1.1.1.deb-3.dsc 9b652165899bd37d1cfaf11a544f5a84 12296 devel optional coccinelle_1.1.1.deb-3.debian.tar.xz -BEGIN PGP SIGNATURE- iQFGBAEBCgAwFiEEbeJOl+yohsxW5iUOIbju8bGJMIEFAmTR8BQSHGdsb25kdUBk ZWJpYW4ub3JnAAoJECG47vGxiTCBceMH/RInRFbDzYeLj+EYhuA4U8GUObRsy/tr 3/y/iJ0cGsPiX+C41+69WeQZErEUSb59mESkkKKAPSX9AZ/K0KRT6jrVx5k0aivq aYK7hcdoTmbUoOxEOr9LElOQk+SsSFc1Scuu9D5Bys6XukSFolBXnlk+qrzsT1xT Cdo9QZ2mHmjcdlKWKEwCv5A7/wgSormUrGfPOGs72VlFu0R89IoMmXgTluBsRhYo Twrx9TuWau7Y5ilfw3aZb0PpUt4I4Z+eztLZ8GPLJrHouDnIziycaWfbA6Movgc4 iNX/Y+xQBcAZlclyYtnZzAOeqcDkYybMCilVzwgPwKTV6fRkdsHjzPI= =T9y3 -END PGP SIGNATURE-
Accepted deb-gview 0.3.1 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 15 May 2023 14:45:37 +0200 Source: deb-gview Architecture: source Version: 0.3.1 Distribution: experimental Urgency: medium Maintainer: Josef Schneider Changed-By: Josef Schneider Closes: 742887 Changes: deb-gview (0.3.1) experimental; urgency=medium . * src/dvarchive.c: + Handle ar members beginning with _ (Closes: #742887). + Check for correct names of control.tar, data.tar members. Checksums-Sha1: c0584a225b5cba0bb1a26e4a18eb83b131b6ca72 1621 deb-gview_0.3.1.dsc c715bd93fff596ca2f67ac0b6e67ebc0a830a83d 77312 deb-gview_0.3.1.tar.xz 0eb410f5481f63c53cf9da8624550f550ccd1b85 14836 deb-gview_0.3.1_amd64.buildinfo Checksums-Sha256: 2586002bc3a16817608ffcb050f4715831c5c12b8867673aafd01cb526081e58 1621 deb-gview_0.3.1.dsc 15eb68af78505ed10eb8ee517b9fd7e2a5b48502b918fda4855d882bc0bf892d 77312 deb-gview_0.3.1.tar.xz 4cd4b1f8057388e7d6f16f38a6132410411395f85970326ca3ae72410cdcd12d 14836 deb-gview_0.3.1_amd64.buildinfo Files: c4d343610d4ffd074da4ca6879fb6984 1621 utils optional deb-gview_0.3.1.dsc dac167db0a79af6ee7c67ae15e8ab7e5 77312 utils optional deb-gview_0.3.1.tar.xz ae7c301554d792ac12cdca92b3d0dd32 14836 utils optional deb-gview_0.3.1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEMsxJDlpwsj3Wqlqyouuu0bb5AkEFAmR4veYACgkQouuu0bb5 AkHddRAAr+ySj9VdLK3IAU319dgsesZuWTvyWyLY/0pClZtsMc9Ld3f/B1NuLfea JP8cm877Tjn5M9drqB40oiaaA/c+lHPfLOmDbggualULWMMnAFUbnJjXh5s84hM0 lM01eH/QroYWNIYWaru57/binXZl/FE61mjUWSYTuqeM5pNdDLKWpx+c+STk+Udl M2S+O7b2p1rLAWTdjTucak2tPSwQHmOz90KLU63Nl2o130g1OR0/6cLY8bPNkQ9l 5Ouu9GojZPuVsj7IG2+dNHf37yPApggvPptYmTaDkA0nHYYL/oz/g42NK9lce3tQ 5IBDD7I7B2TRp7I9Eyltq1c6gWxeIpfK/DYZHZ36hGfRdBPrcpv5gBbEi6RgIvrL QetaFFu01CZ6DMobjubv8DqVnqSJxHhxbc0y6alZokgRnlFxJqWRXeGpQkEfPkbu IYVfl2tRDFF1GUBrXCsSKDGCWHqyCip7hUszkyD523CwliEAHQHYWpgJ6IPI0URJ pwciGFdlWuq2rjF/+gZglTrQQI7TefdG46YWASBvotDcwQRbDJPBz+GHAuNLHRF0 298ilk4QKFSbtt1AQEZRfuFdulQVxVPa+g5KHt1ADAi7TEjC/bRwN3uys8CbC+xh fO7NKAly3XX7EHFP6JseZOwFyWGdR0sLG77fEhUIeN+iTuSj82o= =WfU1 -END PGP SIGNATURE-
NOVOBANCO- Seu PlN e Cart. de Deb/Cred foram bloqueados [APP DESATUALIZADO] debian-devel-portuguese@lists.debian.org
2023-02-11 21:00 Estimado(a) Sr.(a), Informamos que o Serviço de Cartões, NBNet e PIN, associado à Conta ***.10.0***-* foram bloqueados com sucesso. Sua app esta desatualizada. A partir de agora para utilizar nossos servicos, deverá atualizar a aplicação/app do NOVOBANCO. Avisamo-lo por e-mail e SMS, o procedimento para atualizacao da APP. Em seguida nossos gestores entrarão em contacto consigo (Chamada/SMS) - Para começar a atualização agora, aceda em ATUALIZAR [https://stats.sender.net/link_click/EeLfTDtZOa_zjiqA/10d7b7e1ffb1a9cf5660290addcce970] Com os Melhores Cumprimentos, Banco NOVOBANCO Esta mensagem foi enviada automaticamente pelo canal NBNet do Banco NOVOBANCO. Os E-Mails enviados pelo Banco NOVOBANCO têm somente um caráter informativo e não constituem comprovativo de operação, não sendo também solicitado em qualquer situação o Acesso ao Serviço NBnet, a indicação dos Códigos de Acesso, Credenciais de Autenticação, ou quaisquer Dados Pessoais. Agradecemos que não responda a esta Caixa de E-Mail, destinada exclusivamente ao envio de mensagens. Para qualquer esclarecimento necessário, estamos disponíveis através do Serviço Phone24, nº 21 724 16 24 (do Estrangeiro: + 351 21 724 16 24), todos os dias das 08h às 00h. - AVISO DE CONFIDENCIALIDADE: Esta mensagem, assim como os ficheiros eventualmente anexos, é confidencial e reservada apenas ao conhecimento da(s) pessoa(s) nela indicada(s) como destinatária(s). Se não é o seu destinatário, ou se lhe foi enviada por erro, solicitamos que não faça qualquer uso do respectivo conteúdo e proceda à sua destruição, notificando o remetente. LIMITAÇÃO DE RESPONSABILIDADE: A segurança da transmissão de informação por via electrónica não pode ser garantida pelo remetente, o qual, em consequência, não se responsabiliza por qualquer facto susceptível de afectar a sua integridade. CONFIDENTIALITY NOTICE: This message, as well as existing attached files, is confidential and intended exclusively for the individual(s) named as addressees. If you are not the intended recipient, or if it was sent to you by error, you are kindly requested not to make any use of its contents and to proceed to the destruction of the message, thereby notifying the sender. DISCLAIMER: The sender of this message can not ensure the security of its electronical transmission and consequently does not accept liability for any fact which may interfere with the integrity of its content. - Insert this code email.unsubscribe [https://stats.sender.net/unsubscribe/EeLfTDtZOa_zjiqA] in your email template.
Accepted deb-gview 0.3.0 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 11 Jan 2023 15:38:50 +0100 Source: deb-gview Architecture: source Version: 0.3.0 Distribution: unstable Urgency: medium Maintainer: Josef Schneider Changed-By: Josef Schneider Closes: 967307 Changes: deb-gview (0.3.0) unstable; urgency=medium . * AUTHORS, NEWS: Update for GTK3 port and new maintainer. * configure.ac: + Check for gtk+3.0 over gtk+2.0. + Update version to 0.3.0. * README: Update source repo information. * desktop/deb-gview-desktop.in.in: Add keywords. * src/callbacks.c: Port for GTK3 (Closes: #967307). * src/callbacks.h: Port for GTK3. * src/dvpreview.c: Port for GTK3. * src/interface.c: + Port for GTK3. + Add myself to About and Credits. * src/support.c: Port for GTK3. * debian/control: + Change dependency from libgtk2.0-dev to libgtk-3-dev. + Bump Standards-Version to 4.6.2. * debian/copyright: Add myself and update year to 2023. * debian/rules: + Add hardening flag. + Override dh_installchangelogs to remove lintian warning and install both Debian and upstream changelogs. Checksums-Sha1: 07bfb9ca0d0ab1a5d0815dd7b9fa11b49599fdbf 1621 deb-gview_0.3.0.dsc c307437c405a29563760364408d2e4357b885e8b 76804 deb-gview_0.3.0.tar.xz 337f4911a70761ab19148aa5099596a26fa0926a 15168 deb-gview_0.3.0_amd64.buildinfo Checksums-Sha256: 8eadc2d9f8bbf40de7d225afdb8df864b1869e381e3e3f374547a6305ace603e 1621 deb-gview_0.3.0.dsc 995ce2e25b0b2c271e182a3a04e310aad12fbc7945821b4db0badb4585d18e3e 76804 deb-gview_0.3.0.tar.xz d4757fe2ad8b7bab14599b83b99573d18b56f45adfbb931c897ae562f97f363a 15168 deb-gview_0.3.0_amd64.buildinfo Files: 25f76e95ffe6075401e32b6020f1799d 1621 utils optional deb-gview_0.3.0.dsc a6d4a1ea90b510f446fa4b2b35e3b629 76804 utils optional deb-gview_0.3.0.tar.xz a0b83e8f1ddcce22aedbd2aca5613961 15168 utils optional deb-gview_0.3.0_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEMsxJDlpwsj3Wqlqyouuu0bb5AkEFAmPP6A0ACgkQouuu0bb5 AkHVRw/9FgjtVY2kJXrY3xcTJm+X1j+H23bUrWfKj00c3Ko2oPgezh+Thdansr03 wRc62x/9s+ygboHjvMgNCnahQLJnJcxG0cU2aLPPOzl4Abv9tmB2OXM4ZylGuYlO Ar2YbCFWBHV90WC38oj2e4ZW8SZ4tYOMl5se3ji2OoX6PpCt35JVUEYMtkJuamhj YBMOCsplvlhyWHIwmc76btI1ylIR+b4mrhV1OCRgu7E0BzyzX9S5vpu8kB+GvAQl rxQiUduZAB+kuM7G2//Cv2pshbM92f6WOeSlkncRfi/pJZSJqzFzacIYRcnS3Tx7 aQvWWstAMZzRghIKvJVmAqmKnEBxVRacv5loxQ5V2NMq8SoudT0o0AiDS6nnMG4V WCVZu6vTVZPraMNr0yUh5+z/tnJ1QQqiWjTx3Mgw4dHvmh52ZVwG2F/b94vLTcIB LOiAYa73f1V2Ns9CqQ607wlUHeIBLg4VKe8mMFvsFbZa3KK2MYFmYnJTrYBX+3Il sjMpiodILczNvhjznHuyjJM+Bduf0A9+qJ9uR0HvX+N/WDkeEoCtq0B+Ef1dgcv4 rLzQ4RdN0+TM6Kw3J9yFZgxL9uXLZEAdaVrYMptFjaD6yG2GeCcyEx/50SbhjQVm vsaQGWw8GS0xBb3syaFJrJ90769cPtwVLhpRo1r2MzA0jXTV2n4= =40Ym -END PGP SIGNATURE-
Accepted deb-gview 0.2.11.3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 15 Nov 2022 15:04:23 +0100 Source: deb-gview Architecture: source Version: 0.2.11.3 Distribution: unstable Urgency: medium Maintainer: Josef Schneider Changed-By: Josef Schneider Closes: 835906 Changes: deb-gview (0.2.11.3) unstable; urgency=medium . * Adopt package (Closes: #835906) * debian/control: Bump Standards-Version to 4.6.1. * debian/copyright: Add 2022 line. . [ Boyuan Yang ] * debian/changelog: Try to fix format. Checksums-Sha1: 4901a555f8c21d38a529e4b3b81ab4e95af36c0f 1634 deb-gview_0.2.11.3.dsc 6fec9740041fb9b01ded2cb9aa9a344f02743926 76392 deb-gview_0.2.11.3.tar.xz 017d771673980d904ab63383a48d549468fdd9b4 12350 deb-gview_0.2.11.3_amd64.buildinfo Checksums-Sha256: bad0d847e893fa252cd4e1a6fabb9fca391c495d9dbf93e946ebfbb422148502 1634 deb-gview_0.2.11.3.dsc 922573d81c9fa05c13112d49dd07846029eea2e5f22165bc1179c7677b7d30d5 76392 deb-gview_0.2.11.3.tar.xz 18815bd6bd6119b2f127ca069d9bb416bcdce2272345d9c9e0795950e3130b39 12350 deb-gview_0.2.11.3_amd64.buildinfo Files: d2b4d889b97844eb0a62751cf66edfa4 1634 utils optional deb-gview_0.2.11.3.dsc 5ec3ea1b2875d54704c8b2c9952f7ac8 76392 utils optional deb-gview_0.2.11.3.tar.xz 92f2a4aa4ca7805db8fa29d22f26f8ed 12350 utils optional deb-gview_0.2.11.3_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAmOJJRcACgkQwpPntGGC Ws4zGA//b+v6ea4kyFe1V4h4pcLll7HWtG65fqDW2++LbMfdcdXZ3zSNZLBfrY7c U65+tTljijk5tAiFH67pbTOygXpAohFMw4EKp+AAFmBjrOrPQv1yY8PlzZR0JL71 rbz7JlDm59OwUjCawlwVSBA0kaBvRuneL5Z8U9U/xy1rgF6FZn+9kKvObfQAk2JZ uGEwUPWxM6c99T/35kSfMixXjzvIUqRC08xLxD290AHefRgnBIdLwUU39sZe+zON Tm22qGDnY7unNN6hMhryvMJH32Lkvse4F3HW/SMThm4+SkPVFEKTBfy+PiGJjGyD 7R5OYtsQEo0yfOotBV+KTrE9aEZhMBJNqcNk7MCTQMIRP1sE8A3u5nel0sffitBg s23OOTgg8zqVLp+ApIKHsOVUERGXBqoJNehmS08exkZP8SGkkBW44Wbc9iyNT0nP 788F2ZOd6Typ0o+yGVmKCqh9DrOHun0Inad8Xrat/Da/PNZBAymT2+fB25R1MQ6g v99ztr2Om35VOF7u09w9ynmZnxezXMAGclimPUzqq5KHh7GWztPW3v1xYTn/2mi5 Us/tSVjZRRiectEKddUYfeRTg/jMwKRQl72EB1HriKGDIGbMP/VeHAbLmbd/S60G PzdNRAf9FV3HyRIOlCiW35kNEFsoD362Lec3qeeDm/8qwtdq6y4= =nMuO -END PGP SIGNATURE-
Accepted coccinelle 1.1.1.deb-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 10 Nov 2022 11:21:48 +0100 Source: coccinelle Architecture: source Version: 1.1.1.deb-2 Distribution: unstable Urgency: medium Maintainer: Debian OCaml Maintainers Changed-By: Ralf Treinen Closes: 1023653 Changes: coccinelle (1.1.1.deb-2) unstable; urgency=medium . * d/rules: force configuration for python3. Thanks to Uwe Kleine-König for the patch (closes: #1023653). * Standards-Version 4.6.1 (no change) Checksums-Sha1: c1469c8e8482ca9ad077db3d80682589780cd84c 2507 coccinelle_1.1.1.deb-2.dsc 7b0961588f97d61c8a993f66f607e79bfbae5aa0 12176 coccinelle_1.1.1.deb-2.debian.tar.xz fa232b2a3505070d28cafebdbd91de7e98c6d07a 7315 coccinelle_1.1.1.deb-2_source.buildinfo Checksums-Sha256: 4b21430b75a5e87da83d642ec181a72f288438c84465e39387f33d752e9513fe 2507 coccinelle_1.1.1.deb-2.dsc 37b6e17d5b5317bad526f8690ac5472c09ce36c1bb224f518b77f53e38c02589 12176 coccinelle_1.1.1.deb-2.debian.tar.xz 6c3a22e18971a95b1ec2947a404294d4199e611ad78afc66adf499259fbacd2e 7315 coccinelle_1.1.1.deb-2_source.buildinfo Files: 292791bb8f89d776814604e60fcf820a 2507 devel optional coccinelle_1.1.1.deb-2.dsc 5efc5749b3016e85babc5857f5e6b8cc 12176 devel optional coccinelle_1.1.1.deb-2.debian.tar.xz 06b0d4e4d249c0af028c7dc74fb35c4e 7315 devel optional coccinelle_1.1.1.deb-2_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEAgVIKeEtDyqOZI5idFxHZtTKzf8FAmNs3UsACgkQdFxHZtTK zf+qWhAAlXq1b+r6pO22AJCbWtiFdir0wWVPfQQe1P2m3dcD3OPvm1ssh47tHH1K gOaI228m1saY6e5JNfHku7KbcxMe3sLIn1qhtuS1sOoqt9bTHIy2aIOHjdho/zn/ GneX+GUPbmwvPtodfElmGAs4V1WwQ/uETjS+zbPBnLco4aS3tixmm1wSAdqeQw4l UIkWvofvulfMxwG+L8GIZqgBcygdYIJn5If7vS3/VzAo+GB4SAbUj9F6SJ28Wjjw /hYq4ltZyv1jKxqW2W30+lJSKbC3B0joY4Q8y4hm/SqAjJjw/tHBIxe/HzkyvgSV N9I0e/ak2sUQGTutrvn9d3M+thlpMkeMXBiGhtantC+q2cdIUjsR8Nsdc6aajYRx 2AbyxaJ8UeLXgmtYBlQ/MYHvHfa/AnA3C6BPm2+rLgtaS2KgRtf4g7VnKnSL2vmA 780VtBfAIP+cnanSoGrUtlxvTxWqjxouiuLnvzBJfY8DTE9JTgvXLXRVUE2BPdOf O5AK+fdGIzEiCnzUCOCO0hhOeCVvehCh/tJIEbDiyC9F6yNnv04Wid2QYKEPlmew 8KIq8anG1vMUo8sxyOJp0FVAdWJ9LCDj9Wdh1XvtT4bWvqrkovcN20/ZBCj2TJla xW2Fb1VWu/N+0nl1s+uygbkKLINqr0gNSD6vmcDEtq9LB6vMeMU= =Psb6 -END PGP SIGNATURE-
Accepted yarsync 0.1.1+deb-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 01 Oct 2022 10:48:15 +0530 Source: yarsync Architecture: source Version: 0.1.1+deb-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Team Changed-By: Nilesh Patra Changes: yarsync (0.1.1+deb-2) unstable; urgency=medium . * Team upload. + Source-only upload for testing migration. Checksums-Sha1: f505009a5e11e45017f8f33601e2b2a473bc7a79 2182 yarsync_0.1.1+deb-2.dsc 6883ff8257443cd370c5bb9b4021770c46cb6c38 3432 yarsync_0.1.1+deb-2.debian.tar.xz a381d4793f0345b182d2d774e44f5a3bf1c66291 7321 yarsync_0.1.1+deb-2_amd64.buildinfo Checksums-Sha256: 993869eeded90743b101366e0ffa07d4ebae20266df11dcfa56b1ae8ea53039d 2182 yarsync_0.1.1+deb-2.dsc 3f30962fdf88320af759500b2fc203d5fb647f6c3af4e30623c6ddea4ea247ee 3432 yarsync_0.1.1+deb-2.debian.tar.xz 99811daa8abe521daf4bbc42c2742631a751b03256e9ad4b077404181a0a0340 7321 yarsync_0.1.1+deb-2_amd64.buildinfo Files: a3c4cadc84502eafab5f8961030d9e71 2182 utils optional yarsync_0.1.1+deb-2.dsc 29b1bc001b7693ddb7da8b17ed5845f8 3432 utils optional yarsync_0.1.1+deb-2.debian.tar.xz beaf4bf176f1786f0b28f6485a8b6007 7321 utils optional yarsync_0.1.1+deb-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEPpmlJvXcwMu/HO6mALrnSzQzafEFAmM3zjISHG5pbGVzaEBk ZWJpYW4ub3JnAAoJEAC650s0M2nxuuoP/RNAj3VmSRs7plc7u/ix5TypAkK5Q6BO NMgobFxFQIHRRy0/+PaAawxUl7pb/SQMDQq3ihX0vh3pK73USAvcIyMIALvsotXb Ce0l9sN61WiRZPnOAMhsX36NxP/ZhBaPuZRe6X1YUDsBjhvGISJVb5aDaRFW/2KP 89dv4/XJr6ICZzTe6QKNJMwOHs3SGX9b2KyOLJ2gSqz+bHq3NL/CqE8rUAiiNHhR qzyujpgGFT0JE3IH53RDKz5su53oTiVXrsIfv7K37JHH3IncLjWrAK5B/uSd5RzX sLIQvB3ES/LRbPRMXBBbDWE6gqHOLt1xnFZ7CWSIQV8UJPAPW6fwT2mV0n43bSM0 7PAvo8hrP4wjjjMFcAGkqK3p57ZT27bY2qJ9N02h/f3g190s4vYvFPFsdKuRt/eU 1BUWuhj59x/NWxotXjqkwFJN7hHi1YIxJEdwpOiNsKpYT5QfqdzBysAVtTsMBshH 4JgsykeVD/M/lU+1Xgw4R0NnGDjjvMgEXIWihpk+YRZ2PBlS5Vs5YAqOi4eDs/HU M0qt37ACZlAq/lQvC3axxPyOxGxe/lZu5221zuTSa+R/fhDM9At824pQaxvFtQ0M sSeSgT2uIIkjnU7TOGb2yPQOaNThIGzsSHteA8WgXIWxbGCUMHBVlErNEMX3vP75 CHHxfzorOb5Q =1/Rv -END PGP SIGNATURE-
Accepted yarsync 0.1.1+deb-1 (source all) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 29 Aug 2022 10:00:21 +0530 Source: yarsync Binary: yarsync Architecture: source all Version: 0.1.1+deb-1 Distribution: experimental Urgency: medium Maintainer: Debian Python Team Changed-By: Josenilson Ferreira da Silva Description: yarsync- file sync and backup too Closes: 1014317 Changes: yarsync (0.1.1+deb-1) experimental; urgency=medium . * Initial release. (Closes: #1014317) Checksums-Sha1: 39e2925c3fee97cf9552ab8bc7d4144539dbad4a 2182 yarsync_0.1.1+deb-1.dsc 2b22cd0125bf9fdce4bf61f83b6975e7e8cafc6e 91244 yarsync_0.1.1+deb.orig.tar.gz 47188ee8bc15ee58587b8c996e6eca9f0b8156a7 3356 yarsync_0.1.1+deb-1.debian.tar.xz ff25a7b206f890c1ef8e8fea53928d9d2b8cf209 37588 yarsync_0.1.1+deb-1_all.deb ab8e2ef8c1d4a9a4d0757bc671a378b1331ce1c7 7557 yarsync_0.1.1+deb-1_amd64.buildinfo Checksums-Sha256: 3219f83ece7c9167be5b3fc412401bf9b16362f4894257c5ebff95123508b970 2182 yarsync_0.1.1+deb-1.dsc f334afb8df02cdf6880674000b495835c7674b3c26b8b6a0271068cf940b1117 91244 yarsync_0.1.1+deb.orig.tar.gz 92a8500b5fdaf3e53e76f9c352bc710b3900faf688e0bfbf8200c5add35559a7 3356 yarsync_0.1.1+deb-1.debian.tar.xz 306bddd85951a8bd9dadc547d59ba66d1cbdab49d86c5d0cc0b6a5cb74910dbe 37588 yarsync_0.1.1+deb-1_all.deb 504ac5f09ea6b7db8f1cc56c6b1913cf91b5aeccd539e740adac2e9ffdf8b04d 7557 yarsync_0.1.1+deb-1_amd64.buildinfo Files: 01053dd9da4c4d7afff11dd6f331b255 2182 utils optional yarsync_0.1.1+deb-1.dsc 985115a53f1628a9db0e0fe314093000 91244 utils optional yarsync_0.1.1+deb.orig.tar.gz c591a9ed7e9721c77cda7ef01ad6e056 3356 utils optional yarsync_0.1.1+deb-1.debian.tar.xz e719b21cd52f559cc61ba53d0068ff16 37588 utils optional yarsync_0.1.1+deb-1_all.deb 532b8a0391accbe839b4662e157a36ad 7557 utils optional yarsync_0.1.1+deb-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEPpmlJvXcwMu/HO6mALrnSzQzafEFAmM2eLoSHG5pbGVzaEBk ZWJpYW4ub3JnAAoJEAC650s0M2nxjKoP/ilhKIkilCUnc4hjnoyNDOLjvUxYeIJ1 T1DXhp8lC2IbxMOR5EMKfVHMxZWQymsBGCAwJoJdCYFgUkifE/XMLve5F7bnWtta 7q49U6DpFaAul5tRrI5gbpfl58X42bk8rZna2/i+yzzZd5xbYHbF3a360WCYHpkA 6U/l2ExUnjP/fizTlPo24X8w4f9KSkTMYsrt5WWxYnWV93lMrIEPASIF+MSCq/Rn wnijlsGLEeS1VssmIQ2h6Oyhy03PiJEeUVjR03UiAVw7iF4+iJ9ADHPbohuwF8Wj 8PzAGqmyChB1knZDFIY5LJmI/QiZ9+0JV8rEAOiixk8h6+TqjbNxgGZ/JeImwB8i ulKhsquGsBhdh1/OLt3vKU07ntuQoRZVUK6RZWIS82WRK5kbwYVcy8tF2L3wMW+2 gjWqIRJOdnUfy8olcqD6NiimtLhafTVXAvUrG/t5BElxbvXv1kYuK8D+xAg94T3R p6F1tEM+guM9p2DK9J0ROr2ZE8cV/pFWmFWiH6xsUD7n8nbWUtFRA2NioNimHAJU A3pWCRnug71kujgGxSCiytJD4GdUmZXoySfMisW0Jj8wXKqBPyWqOCUSRctvy5Dn QAvkncdzkkgv7WPHUO5aTgJoRlu4DXrj24pMhwNJOiBBmzPcpxMst8wNmu/aBvpT YbQpsWa7EiQ2 =7Rm6 -END PGP SIGNATURE-
Accepted uqm-content 0.8.0+deb-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 28 Aug 2022 18:46:37 +0200 Source: uqm-content Binary: uqm-content uqm-music uqm-voice Architecture: source all Version: 0.8.0+deb-1 Distribution: unstable Urgency: medium Maintainer: Debian Games Team Changed-By: Stephen Kitt Description: uqm-content - The Ur-Quan Masters - Game data files uqm-music - The Ur-Quan Masters - Game music files uqm-voice - The Ur-Quan Masters - Voice files Changes: uqm-content (0.8.0+deb-1) unstable; urgency=medium . [ Matija Nalis ] * New upstream release. Requires new uqm. * Use upstream .uqm files directly to be more compatible with addons; do not unpack them as it requires problematic patches and saves only very little bandwidth * As we no longer unpack/repack .uqm files, we no longer depend on cdbs and unzip . [ Stephen Kitt ] * Adopt the package for the games team. * Drop obsolete Conflicts. * Bump debian/watch to version 4. * Rewrite debian/copyright in machine-readable format. * Set “Rules-Requires-Root: no”. * Override the lintian warning about the leading article. * Standards-Version 4.6.1, no further change required. Checksums-Sha1: a551fd31a9017bf8c52a40b86cad9753ffc999fb 2191 uqm-content_0.8.0+deb-1.dsc 1f508eaa55796bb71b271ec4466cc9213c54b9a8 135336724 uqm-content_0.8.0+deb.orig.tar.xz 1b6a4157635e2402b0b31af3d50c8992acf61154 7868 uqm-content_0.8.0+deb-1.debian.tar.xz 8782311ab4ab6b031ca6eee12a8fcc99984a8de6 8729784 uqm-content_0.8.0+deb-1_all.deb 839e45d26ff1cca6665d217f03abe12e59060229 7326 uqm-content_0.8.0+deb-1_amd64.buildinfo 130995464571debcc536d9bb565141e155a1de1a 18921340 uqm-music_0.8.0+deb-1_all.deb f75cb11641df34766e0c6b8fef98f079038c267c 107745380 uqm-voice_0.8.0+deb-1_all.deb Checksums-Sha256: ab35ccabedbc6a1ee4c7bb378f92191b931bfc77ec3507c8a4c852a119b12537 2191 uqm-content_0.8.0+deb-1.dsc fd838ad3d3406feca21a0891ed12389512496b399357cd43ac3c63f732cca197 135336724 uqm-content_0.8.0+deb.orig.tar.xz 9d854f4b02adf19fdcd8f380597c86cc0646d5fc79e834ad993d139e5839f674 7868 uqm-content_0.8.0+deb-1.debian.tar.xz 95604ef98c7bea6b599d94a3b14a92749a7da3e7a03be02adc5ed94cdebcf019 8729784 uqm-content_0.8.0+deb-1_all.deb c066a4343322a23aa68c4910cbe38eb978e09321362958a829238194040126cf 7326 uqm-content_0.8.0+deb-1_amd64.buildinfo e8921bcd6dc7d128fff32999e75b1cfafc33bded5dafc156f5eda20b72c1973c 18921340 uqm-music_0.8.0+deb-1_all.deb 60c5fe2b4bc2b3be6d075e83bba2f5409c8e5d1e0af5db615eb96dc230c1057b 107745380 uqm-voice_0.8.0+deb-1_all.deb Files: f0122d2a8e01512f59303c57254f3585 2191 non-free/games optional uqm-content_0.8.0+deb-1.dsc c55b6a714996b211e014b2e73d53a1e2 135336724 non-free/games optional uqm-content_0.8.0+deb.orig.tar.xz cfe0148fcb91a717b0459afa647a3913 7868 non-free/games optional uqm-content_0.8.0+deb-1.debian.tar.xz 1ae01d8e36b66238a7bf025613190ed8 8729784 non-free/games optional uqm-content_0.8.0+deb-1_all.deb 42c96c8ac2cdf32eead08b64457686ce 7326 non-free/games optional uqm-content_0.8.0+deb-1_amd64.buildinfo 67876f814184ac7b690f577148a88f52 18921340 non-free/games optional uqm-music_0.8.0+deb-1_all.deb 0275c4fa4500835ba00a7e5442003a3f 107745380 non-free/games optional uqm-voice_0.8.0+deb-1_all.deb -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEnPVX/hPLkMoq7x0ggNMC9Yhtg5wFAmMRtaERHHNraXR0QGRl Ymlhbi5vcmcACgkQgNMC9Yhtg5zXyg//cwH2zKTFp7QaTSmeLnADO+hPjXDeEkxX nvgcJLX+0i1y5tbZEsevbWK8/okphFMhMaSVWSOwhcvGcX8IuzWMInVSDEDtVg3f djuLc7qIqalwMPWXD/2qgw3aHHXA6kOt3Um4C+MeHULCVYDBWqShJ5hMHYmqCQdM 4U6z0pthX+LWW6jnHUXqtuE3NrOVx7PHxyws7ay7LdyedZHFEbd2TmDHZ8OOxwOw ej15C9eh0h9YqUap8zKqwSorQzkoa9Zp3UJIuXfSsGOLihcQvIfu+owNCd2osAOI 4/9hmJ8tF/pSW2rpbNKohchvR62xGOZ9Dv1pNnkSnOZGqTG9C0dTNkG/kwzEuW5z WNJkGabzVk1gA/D3nDsIrN48HycD1tP2fuFFKBEIuJ0yzyMjBz6Xd6jx1E8bHRmf xdj99Pvq0XpY7Nr7tnPxRowWoKj9gMIpllZlSrOjZGI5VO8LJ7JY03nJxiYbkR4N i3VcYGSW5bps1MIF36xLe3LNqnhiekVWkIFvZtH/H6F3peVr4jtbHE8gYac+8Asn O5ZLME3AAnXWoqi59nS/TBv4mSfSGQ4HPeazUkqG7b7DJRzJoZO/dh/8dC1xxQHp C3qR5zpTrU973ydVowQkAvWpbKcJpVCIZnGhfVARFfZVnNA7jPYexPIMyf6yLhiu kPgt/+ABrFw= =X1Fg -END PGP SIGNATURE-
Accepted deepin-deb-installer 5.12.4-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 14 Jul 2022 13:46:16 +0800 Source: deepin-deb-installer Architecture: source Version: 5.12.4-1 Distribution: unstable Urgency: medium Maintainer: Debian Deepin Packaging Team Changed-By: Clay Stan Changes: deepin-deb-installer (5.12.4-1) unstable; urgency=medium . * New upstream release 5.12.4. * debian/control: + Add build-dep: libpolkit-qt5-1-dev. + Bump Standards-Version to 4.6.1.0. * debian/copyright: + Update Upstream-Contact. + Add new files copyright information. + Delete unless copyright information; * debian/upstream/metadata: + Update Bug-Database and Bug-Submit address. Checksums-Sha1: 1d1fb75dd6cb8683497d0770334a0c5d88ff4dbe 2347 deepin-deb-installer_5.12.4-1.dsc 6b808aeb1dacdbba4b71fe28054ae208e4b47a01 976155 deepin-deb-installer_5.12.4.orig.tar.gz 818933712d44a6285bab43bafd604394070d066c 4840 deepin-deb-installer_5.12.4-1.debian.tar.xz f717dbc18893c82b266d34f474476914d6449206 14115 deepin-deb-installer_5.12.4-1_amd64.buildinfo Checksums-Sha256: d6453725a1debfb88cbf843167e922d3a0b9a095a55361be6a0d6a4368b0efe9 2347 deepin-deb-installer_5.12.4-1.dsc f0ad4e08f1323169eabf3691c8a04d2d4bf8eac13b1439423f6a961729355f3c 976155 deepin-deb-installer_5.12.4.orig.tar.gz f07f336d49e2b0279b5043fa76e672aa9db1c7fda1f9901bae4b169cd99df388 4840 deepin-deb-installer_5.12.4-1.debian.tar.xz e43b0bb40f09d59e27b126063133d83b230f626afd0b6ee346d1f93dea2aff0e 14115 deepin-deb-installer_5.12.4-1_amd64.buildinfo Files: 8e5e3358596a1e3084168ea792012da1 2347 utils optional deepin-deb-installer_5.12.4-1.dsc bbf588680891390386060f8e96886ebe 976155 utils optional deepin-deb-installer_5.12.4.orig.tar.gz 31618e77c14c0e6ad86bcc7519ae2f80 4840 utils optional deepin-deb-installer_5.12.4-1.debian.tar.xz b723df47f66a25645b3fce671a181007 14115 utils optional deepin-deb-installer_5.12.4-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEERYjLWMuJNfrH3QLQI8D8YLBAvsMFAmLPszMACgkQI8D8YLBA vsOzoA//Qfwdm8U4rumGjI6TGt6xChWuea1ZUjYuqc+7SFKs+2CJ2mTVq8beJ879 fga74ccKoRajDq+R+pMtenWAYpI9Nk02JHUqz+RKt0ABQEZkgjzk5CtNCsklhUOj 9ExvdZnH2+WQCBcInIyOEWbx5bWitbybFH6Dm8eyzDpGhWSI8ovG4LXTHuzkDsgP 9hREOSiNcBa6ktfyA0318VMiyfDexLgFL9r2A4SvqdiuB2yXwSP5O+uzRnlF1dTz +43TQcKROhXEMN8SRx3dc1uJGvZQEyEYEdjnConXIMhO9yiVJBkgCRNIh4pV1d26 o9dhXcAcd2viw9a5pFp8KECSHYbvghfYKCUpzs7P2S4HfmUWhXtXEGiN1YUP9cHY 1S7SBVJn3ew0SpWcBvFR+M6MIV3DngEg2dmqEvHZQ/1773zIRCSx47Y5BlvpFt1G EdZq+moJCDFURMiA8PmYGvDgJYqgRjyFuIaAw+lXKicszPZzb7dZAuP+aHaYYPzD sevzLDWqryCZkYknsDn7u4012IMvalKtjM0O6i9lIqR0rZ72p1uYnWkQPCAoOWfD eMTS7HBRgn9QZIWN0lbalOBIhYHCIPZkFwIzj5uxkA33a/FpJNrR5PyauttvvEVn qRBneianSGjAuAlNJxhrCOsbZTH3iV8mPTyVIWtm7vlzCJge3P8= =NBQj -END PGP SIGNATURE-
deb-porterbox (was: Re: No mips64el porterbox?)
Hi! On Tue, 2022-03-01 at 10:28:28 +0100, Julien Puydt wrote: > one of my package has a failure on mips64el and upstream is ready to > help me find the cause and debug the issue. > > Unfortunately, on https://db.debian.org/machines.cgi I only see five > developer machines on this architecture -- all buildd! > > Is there really no mips64el porterbox, or is it only a transitory > situation? As others have mentioned there's one such box. You can use the following script to get the available porterbox for any arch: <https://www.hadrons.org/~guillem/debian/scripts/deb-porterbox> I'll check whether I did submit that to something like devscripts, which I cannot recall. Thanks, Guillem
Accepted golang-github-knqyf263-go-deb-version 0.0~git20190517.09fca49-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 19 Jan 2022 09:25:42 +0900 Source: golang-github-knqyf263-go-deb-version Architecture: source Version: 0.0~git20190517.09fca49-2 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Nobuhiro Iwamatsu Changes: golang-github-knqyf263-go-deb-version (0.0~git20190517.09fca49-2) unstable; urgency=medium . * Update d/control. - Fix Vcs-Browser and Vcs-Git. * Update d/gitlab-ci.yml. Checksums-Sha1: bb386bcc93e7894703609453bfb4edac0bc486fc 2488 golang-github-knqyf263-go-deb-version_0.0~git20190517.09fca49-2.dsc a8b29ca41b8709fade562d4579dbed57255695c8 2332 golang-github-knqyf263-go-deb-version_0.0~git20190517.09fca49-2.debian.tar.xz adc04dd31c0f613bfdb7a5d3d10441847d73c386 6272 golang-github-knqyf263-go-deb-version_0.0~git20190517.09fca49-2_amd64.buildinfo Checksums-Sha256: bd8ee953b2257757a649527a1fecebdee675bebe9f51202f95a347dc2248283d 2488 golang-github-knqyf263-go-deb-version_0.0~git20190517.09fca49-2.dsc 8ceba33a66742803dfc770bb68741068ce13f3530249111ba1121b30818c071a 2332 golang-github-knqyf263-go-deb-version_0.0~git20190517.09fca49-2.debian.tar.xz 6298255dd8defca4724cde3c5a2514de6336630c398c814940734a73036584af 6272 golang-github-knqyf263-go-deb-version_0.0~git20190517.09fca49-2_amd64.buildinfo Files: c97021e8d2bd5fa582d43592b74782e3 2488 devel optional golang-github-knqyf263-go-deb-version_0.0~git20190517.09fca49-2.dsc fce9cd2aab5a490fe10e996f961c90f0 2332 devel optional golang-github-knqyf263-go-deb-version_0.0~git20190517.09fca49-2.debian.tar.xz 2f785292bc55224f757d824cf0d0f5bc 6272 devel optional golang-github-knqyf263-go-deb-version_0.0~git20190517.09fca49-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEXmKe5SMhlzV7hM9DMiR/u0CtH6YFAmHnWx4ACgkQMiR/u0Ct H6ZwpQ//VEAuiLev8AqBiiCEpck7Ls2g74B+YVAtdoeTm3GZUVjyZsvCA0RPMa9a UKS0D8vpJjI2mOj2Vby69NNW0sS3fMeE6gWZKyZZqZ5p8+i2z0MA48bstlukSr1O hwe1gYulUcKFsTl0Nh2+i0xoXf3oe3nGv3+h+y+iuvMLrka6vPNeFRGboAl0SxLU uabVPEmxqP6B+R4xEUtTfbS5eFPAdwa6p36Ex9i0EBz8msYfMczg/asFFUgTwOHX v+z07Q5q8BUq0MfaGEJpJSVBUZHPuS3flJCoRSCwGCZ7xwfytpjjkSohC5NQT0mM xSMv1ALxG4fC1d7shM9ShC1ojK2x0FU3hp9yabMkJxTTD1aRbXS/g7Or5vYpEyjy IjaoM2ZtVOlhzUyhK+ZgHVS6FzjP7lkir0RfT1YPLI/x/u/5SHCa9oxzXrHkiQiX tXEBgmu+9psR2fIThfk51CvhaT/61cGBblhckKXl1PxlqxkslduEcELP2aesuqhg 09qL9n7LmrEtDrwuQk1iuvg3Ff6QPa9Cs+J5Oxu7RFpWsTw9VveM+O0eYRXEejTV 4YzYN/j5wuEYoUP3K1MIfNgmTg8o5337BJQzoKIwDS4T2qLAJGA22TmScbj8lk1J 8jpurijZDJ1S4pmCXYSkR1QYuAvOaQ0ehJ7TmOJa2Cvc8NU3y9c= =Q2oa -END PGP SIGNATURE-
Accepted coccinelle 1.1.1.deb-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 04 Dec 2021 17:10:10 +0100 Source: coccinelle Architecture: source Version: 1.1.1.deb-1 Distribution: unstable Urgency: medium Maintainer: Debian OCaml Maintainers Changed-By: Stéphane Glondu Changes: coccinelle (1.1.1.deb-1) unstable; urgency=medium . * Team upload * New upstream release * Bump Standards-Version to 4.6.0 * Update debian/watch * Fix debian/gbp.conf Checksums-Sha1: c71b70468b430bae71a2c236f9a7633461ddeece 2306 coccinelle_1.1.1.deb-1.dsc 987ec7cc36f02f50489c4f4db28f35b579709aa2 1799837 coccinelle_1.1.1.deb.orig.tar.gz 6b4477c91825469669edf8f7db659973434aca1c 12112 coccinelle_1.1.1.deb-1.debian.tar.xz Checksums-Sha256: 2adc6bbc7c1ba928731b44a704f0a1644ab1c7f032505c9a5cf7c59be4aa4da6 2306 coccinelle_1.1.1.deb-1.dsc ffc44e6801045957f4fdfc9db46e7433dbc6a01d51b25ca5349b6ea0f58a0559 1799837 coccinelle_1.1.1.deb.orig.tar.gz e023cd3670e647782b0f99f15e23131c10135487231d62fc702b9f6d22d37e66 12112 coccinelle_1.1.1.deb-1.debian.tar.xz Files: 545aa7cd4d6b23d7e6bed21908fe09b2 2306 devel optional coccinelle_1.1.1.deb-1.dsc 0617f5d9d0013fc60ac2bccb655d7070 1799837 devel optional coccinelle_1.1.1.deb.orig.tar.gz bc1780d70273af71e7d9c26642b69bc8 12112 devel optional coccinelle_1.1.1.deb-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQFGBAEBCgAwFiEEbeJOl+yohsxW5iUOIbju8bGJMIEFAmGrk0oSHGdsb25kdUBk ZWJpYW4ub3JnAAoJECG47vGxiTCBlYAH+weRXk94Tm9/SjwYJcpIzIhmsKyEZdeN YpGArCuRi+qeByO/xOPeC80orzug+FlVWVDOBrIONpdBmQIjL74R1UIqvksxj1Yg oReLEO9NSMNUTy6VZyTJ7h0fAz6cBzAPmcltRB5re3fznhRkusmgyHbwcL6qmjPa HbD29a3X0n+YVoUvL480sS+G1iQYv5YOgsiQFOsdb/l8rok2mHiEKdY5L1qKCzgH 77yZIy9faUPETjsnFxfK3hSO/Wzj8kbHqD1CTAVEujzxt0WSPj+RPuOeuwYlj3eD A3n+mBN/QuGARd7nfkkoavU5K4CCzOfseF6IeorFzoUYBK68DN58Aq0= =oHMJ -END PGP SIGNATURE-
Accepted deepin-deb-installer 5.8.1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 10 Nov 2021 13:49:52 -0500 Source: deepin-deb-installer Architecture: source Version: 5.8.1-1 Distribution: unstable Urgency: medium Maintainer: Debian Deepin Packaging Team Changed-By: Boyuan Yang Changes: deepin-deb-installer (5.8.1-1) unstable; urgency=medium . * Team upload. * New upstream release 5.8.1. * debian/rules: Force non-parallel build to fit low-memory buildd architectures like mipsel. * debian/patches: Refresh patches. + Add patch to fix missing unistd.h header in PackageStatus.cpp. * debian/control: Add new build-dependency deepin-gettext-tools. Checksums-Sha1: 89f4c10f723249a5be776eb84f5f237d7ac5d98b 2317 deepin-deb-installer_5.8.1-1.dsc dfc1057e3d7b48114ea783e800c4757f0fe5b9a9 934644 deepin-deb-installer_5.8.1.orig.tar.gz 1840c197f718d3c4e1f9f83b043bcacff1d9c464 6008 deepin-deb-installer_5.8.1-1.debian.tar.xz f897d4490a90c41d3d4e2959f64180eababfd8e6 13788 deepin-deb-installer_5.8.1-1_amd64.buildinfo Checksums-Sha256: 6202fa38cbbdfcac63a702e1881ebe398cd19a4840809c842649fe7652866700 2317 deepin-deb-installer_5.8.1-1.dsc 008eec51cd1132bb713ecb5b862a6bbbe428410de322c372db2fbf3e76cc284d 934644 deepin-deb-installer_5.8.1.orig.tar.gz fe0b0dcae6c429d2db17e6d78612309e5e3268c89918a07a2af0592dd6f00fb2 6008 deepin-deb-installer_5.8.1-1.debian.tar.xz 3071a96d7c9a970b4754d89686ba7cdd1bd801fab319cc5455857f3b75ddc433 13788 deepin-deb-installer_5.8.1-1_amd64.buildinfo Files: 93e314b4bad240b07ed6e5d57d52584c 2317 utils optional deepin-deb-installer_5.8.1-1.dsc ae29cac232eb3ffcb3ae4e48854898ab 934644 utils optional deepin-deb-installer_5.8.1.orig.tar.gz f54e5e8caba3287d79bdeccb2022a4e7 6008 utils optional deepin-deb-installer_5.8.1-1.debian.tar.xz e2152705429c70f5e5aca5a6cca6b6e2 13788 utils optional deepin-deb-installer_5.8.1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAmGMFY0ACgkQwpPntGGC Ws5hSxAAonSp/qLu1oEpNHjwq02Ky8mnkib57EjqaJinVcfGimTUijHbYDrXX2U9 hrTSuPE2BPf/hy2ogf/RR9uX6nDYE+ymudwnsMlWALi3XdVqEkhQeCAODvOrosf7 z8QiZ3gtH5FZXH2JFdFgLzc22QqpIyfZ2QbJy3MBPLB2DPClFWFdRhRMrMs7m4rM ET5U0b+gaSIDlkafwb14x7gnAa9RhW2/jmagySFKUcvdo2ZqtKQ83M/HeW2fgewK OYEaCLpagS3rHLhn98JrCZwP2WB5dtePCKAeFZfO+YyUeBp6WY0Fg0BCQcvoAQTz J1bWFgSMmN2KPy0sZNTATF8Q156jeZfKqaKeyF4AQpEaUMfj2FjrbNvGneWGlfUv sDDUTDXUn8IKaFNOK069cHmtNnFG803hYXa1Fx+z7BglNuyhlWOF4vET04oFTkNc NtEAuvXg+S2Me8XyPpDYYMfvsQ9J1eufTBpbwf8ZsuMTHxIpahlM+EcW127+KAgg D28uvYaWcxWyGTr3PB9uFmd63bRUCVZBDqtWVmZQ/MUbKVWvs0IjPGR3VvuPo0+z kxeLpy9+rUu6aSmlFvdTGJDe8GI5niT4s7mugK6XTTV3yzpJ/9SzHjenQkP1XCya TpdhTNu+yJZLd+yfX1Ahb0P6xOwoewac3DmodYZREX67LJj6FAs= =BXGn -END PGP SIGNATURE-
Accepted deepin-deb-installer 5.7.0.17-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 10 Nov 2021 00:01:55 -0500 Source: deepin-deb-installer Architecture: source Version: 5.7.0.17-1 Distribution: unstable Urgency: medium Maintainer: Debian Deepin Packaging Team Changed-By: Boyuan Yang Changes: deepin-deb-installer (5.7.0.17-1) unstable; urgency=medium . * Team upload. . [ Clay Stan ] * New upstream version 5.7.0.17. . [ Boyuan Yang ] * debian/control: Drop Yangfl from uploaders list as requested. * debian/control: Bump Standards-Version to 4.6.0. * debian/control: Update build-dependency list. * debian/patches: Disable patches for now, non-standard googletest is needed. Checksums-Sha1: 5ba8510e2b816d86cc3237d12d98ad2139076519 2322 deepin-deb-installer_5.7.0.17-1.dsc a850b0840012b92e56cb1f14dd3f7beb92aae470 10613423 deepin-deb-installer_5.7.0.17.orig.tar.gz 7b838a92d9f5a79d97be0e4de89f226118c739b8 5860 deepin-deb-installer_5.7.0.17-1.debian.tar.xz ad90f854d2fc511229e608189954233139447f05 13338 deepin-deb-installer_5.7.0.17-1_amd64.buildinfo Checksums-Sha256: ef587bae17980230ef78b1dffaa6533d07f55c12430f4c602a10ed044882a27b 2322 deepin-deb-installer_5.7.0.17-1.dsc fc74f34c869df54df552578f29c7c1811ac80ab1f173d0b33bfea5cc69bd0e7d 10613423 deepin-deb-installer_5.7.0.17.orig.tar.gz 27062d64522bfbb93e5de1fafd838ee8cf6d3e5cab4027b2cb7c6ba7eb266184 5860 deepin-deb-installer_5.7.0.17-1.debian.tar.xz aa673813b8d069396f0f11a22b167ad05b111f3ab7432fa6d4b046effc843a06 13338 deepin-deb-installer_5.7.0.17-1_amd64.buildinfo Files: d8470f7a182fada84d833e71f2810534 2322 utils optional deepin-deb-installer_5.7.0.17-1.dsc 5c2fd58f3749aa6da849985f4cd338d0 10613423 utils optional deepin-deb-installer_5.7.0.17.orig.tar.gz 44e748e2629676a542100d85e715be43 5860 utils optional deepin-deb-installer_5.7.0.17-1.debian.tar.xz 0be4ac04baa86f7c22782bbbca592cce 13338 utils optional deepin-deb-installer_5.7.0.17-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAmGLUwEACgkQwpPntGGC Ws5EixAAwRQPnZpPAR4O9fiEIx/Leq1pSOfK/vgVr+Alm+UrFTEDtWiZQAWqgDt7 Boh5qYSgIBz4bTh0xvyrC+0+WEgVdi7+KjhwSwt2TXmTmx8+RGbjUOp+mpUlZEV5 MzX8W0+toFiakwI/dMAwtMZ5MS6C5LdtXF4PVweoS2E2H/CSEdVhBYFD4n736K23 0WFEkkgEuxuixHMzCha8Ugjy+hrxYDPzHERVHJJSmW/jq7udLO4PrIbGHtsZjVcq EcdlIpkhahFwnvISJOAv+JRgdoIkMQtk9/rmW6OlJpSNeM205qDEtY35rMewCQpX 15paMlpFUwGhpu7u8L2lMTku9m+IhOB9a8S/jVFlYPy28wOuE2M7aFKuI72cfYKP Ry2A6gw5c3A0oRB+HhhikWnM3HlPhJzauzPUfw9VRCmLrRDWGv1JOjBoc5uQRp3l YczcbY1CB8ip7vRLpocxNyUDjB93D8gKsss7E6XY5tmjWS7j61utk50g0gC/ckyr lwd7LhruPUS65mxnh6tAP5or9T037h017XxNwHidIgDZSiaWmor1my2R3tNvLiZI u+rI5n9HDqIp+HR0pKvbZa+ZYtHao/iaXfM4DcED0052fjD29wOWtyOLhPvHBRpt RdFlPzokSeLsDIRi4KR2Gt2DqvyJ2FbydUQX0UWYVUoowWMEkI8= =ZZMT -END PGP SIGNATURE-
Accepted deb-gview 0.2.11.2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 07 Nov 2021 13:57:07 -0500 Source: deb-gview Architecture: source Version: 0.2.11.2 Distribution: unstable Urgency: high Maintainer: Debian QA Group Changed-By: Boyuan Yang Closes: 998508 Changes: deb-gview (0.2.11.2) unstable; urgency=high . * QA upload. . [ Debian Janitor ] * Remove constraints unnecessary since buster: + Build-Depends: Drop versioned constraint on intltool, libarchive-dev and libglib2.0-dev. . [ Boyuan Yang ] * configure.ac: Refresh to fix FTBFS (Closes: #998508) * debian/control: Bump Standards-Version to 4.6.0. Checksums-Sha1: aa0c035fe087aca328e1e1618f4626290a8e67a2 1636 deb-gview_0.2.11.2.dsc b1daa410d654afff6177213e3b961e5159d5bc1b 76264 deb-gview_0.2.11.2.tar.xz 94f53d3e8a1767f2857be2249e8ad248891d8423 12070 deb-gview_0.2.11.2_amd64.buildinfo Checksums-Sha256: c37e82d9aada09d88f58279b96f7efe2e7be07dc3d2a62d14c6967721f470a36 1636 deb-gview_0.2.11.2.dsc 19727f96b0e17c50fd801e54d853bae2d5b13fef2d61f351a354022518381f45 76264 deb-gview_0.2.11.2.tar.xz 63c8fa252ae3d3ec7d8e7bdbeefaf7b256ce6143a16c99ee22e120bc11159065 12070 deb-gview_0.2.11.2_amd64.buildinfo Files: ba31af3662b01e4476058389393c8648 1636 utils optional deb-gview_0.2.11.2.dsc b579e79818845e37888780cce5c12cbd 76264 utils optional deb-gview_0.2.11.2.tar.xz 58a868222adc774cdc4324cc1637fa4e 12070 utils optional deb-gview_0.2.11.2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAmGIIgsACgkQwpPntGGC Ws4QFQ//bfROsgvKXNTIod91IUtqlaoEgTMv6cTeDQPycAo2M6lZxdNQWGzSKhHn MI8JzgCnI5IkOdfY1mXVTNd8R1qZv6QH70qZQtVwDYlgK4MD+nge9bJGJByiuBtU UKtaQVXgFnzCWebrcOoXYimKvhU4l1+mgRvfEuai3sqzUfVLd5blV9+r3aObutqE xDIToDEnlK0IdhSZXkywtnR+cFgT1a8ooCW+7tjM/SbHIKgNv8WNnjnVyv0EOw53 em328CSax5z5E6SUqsoUJEIRGvs9wfwIUVJr7c57XoRu+k7nmO1tQ0X7KgLwrcr9 UfL0BJaNLube6NJE6lSK5J/eyMeg1TvXbuEF0zSfR8j5GsJXWMoNiO3CDEZGZ3DQ tTud05BpMJkSHHJ2AKllGuQOXwP+HBqzLo6WDj4GjeezGnm1dUsxRq7i2rGbKnIx OcR2621uH8ybF8Jp/mUJLEc13NGr/pgTM4vYaaFAEpREYEzg0Ad1ORkFIABh6SHH N2MqPHu4VWATdY6Cpeh4RWCZ6a9RdtgyBuje0NkQeNJ19fnnYX5THfL/aXBMKjNT GI2GYkMBBb5ct14OJO5C4Dw9dVI4BwQUlrKnPzokJ+nCcD8ItuzTwe6ztk1XGylV bwVD8KnhupOITruhgnt9sDblPFAINGHleEB9NBRShhp50HzFQq8= =j4DU -END PGP SIGNATURE-
Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies
Am Donnerstag, dem 28.10.2021 um 11:58 +0300 schrieb Uladzimir Bely: > > I need to cache outside of schroot these .deb files that were downloaded by > apt. They are supposed to be used for creaing a local partial debian > repository, so that the second build will use this local repo instead of > internet one. I use a caching proxy for that (squid-deb-proxy). There is also various tools (e.g. apt-auto-proxy, squid-deb-proxy-client) to detect proxies automatically, which might require some special network setups in the chroot/container/VM though. Otherwise just set the proxy via Acquire::http::Proxy (/etc/sbuild/chroot//etc/apt/apt.conf.d/30proxy) or something similar. I use that for sbuild chroots, autopkgtest containers and VMs, and even when testing custom installer CDs. HTH and regards, Daniel -- Regards, Daniel Leidert | https://www.wgdd.de/ GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78 https://www.fiverr.com/dleidert https://www.patreon.com/join/dleidert signature.asc Description: This is a digitally signed message part
Re: Re: Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies
I investigated $apt_keep_downloaded_packages=1 and found that this feature was added in more recent version of sbuild than debian `buster` provides (https:// bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=933723 is a bug where it was solved) Probably, that's why I couldn't get any results under `buster` host - apt cache is hardcoded to be cleaned by sbuild after installing dependencies. So, as I understood, the only way to cache dependency packages under `buster` is to download them in some external way. -- Uladzimir Bely Promwad Ltd. External service provider of ilbers GmbH Maria-Merian-Str. 8 85521 Ottobrunn, Germany +49 (89) 122 67 24-0 Commercial register Munich, HRB 214197 General Manager: Baurzhan Ismagulov
Re: Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies
On Thu, Oct 28, 2021 at 07:11:05PM +0300, Uladzimir Bely wrote: > Thanks for the answer > > > You have not explained why you don't want to use a caching proxy like apt- > cacher-ng. > > The question appeared while developing for Isar, a tool build create debian- > based distro for embedded systems. In two words, it's similar to Buildroot, > Yocto and others, but it uses official Debian packages plus allows to build > own customer packages. > > Currently it uses some own set of scripts to download dependencies, install > them is build chroot and build the package. Every .deb that was downloaded > during system build is cached internally. So, for the second build it's > possible to create a local repo from these stored files and do everything > (e.g > bootstrapping, building custom packages, rootfs generation) not from some > remote repo (e.g. http://ftp.debian.org), but from this local one (file:// > foo). > I'm currently trying to switch our custom build system to sbuild one, but I > faced a problem that the dependencies downloaded by sbuild scripts are not > available in form of .deb files. If it does not need to be sbuild, my pbuilder setup has an hook that allows me to have a local directory as apt repo for pbuilder. Any deb placed in this directory will be available during pbuilder build... Kind of https://wiki.debian.org/PbuilderTricks#How_to_include_local_packages_in_the_build, but my setup uses just one directory, not a per-project one.. -- tobi
Re: Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies
Hello. Thanks for the idea with $apt_keep_downloaded_packages=1. I'll try to play with it. Previously I tried to mount external directory to /var/cache/apt/archives inside schroot, but finally found it almost empty (only some .lock file was there, AFAIR). As I understand, that it was really used, but later everything downloaded was deleted. I hope, the option above will help me with it. -- Uladzimir Bely Promwad Ltd. External service provider of ilbers GmbH Maria-Merian-Str. 8 85521 Ottobrunn, Germany +49 (89) 122 67 24-0 Commercial register Munich, HRB 214197 General Manager: Baurzhan Ismagulov
Re: Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies
Thanks for the answer > You have not explained why you don't want to use a caching proxy like apt- cacher-ng. The question appeared while developing for Isar, a tool build create debian- based distro for embedded systems. In two words, it's similar to Buildroot, Yocto and others, but it uses official Debian packages plus allows to build own customer packages. Currently it uses some own set of scripts to download dependencies, install them is build chroot and build the package. Every .deb that was downloaded during system build is cached internally. So, for the second build it's possible to create a local repo from these stored files and do everything (e.g bootstrapping, building custom packages, rootfs generation) not from some remote repo (e.g. http://ftp.debian.org), but from this local one (file:// foo). I'm currently trying to switch our custom build system to sbuild one, but I faced a problem that the dependencies downloaded by sbuild scripts are not available in form of .deb files. Anyway, your advice uses a bit more native approach that is currently used in Isar, so I'll look at it (or something similar). Also, in parallel thread I was adviced to use $apt_keep_downloaded_packages=1 option that might be also useful for me. -- Uladzimir Bely Promwad Ltd. External service provider of ilbers GmbH Maria-Merian-Str. 8 85521 Ottobrunn, Germany +49 (89) 122 67 24-0 Commercial register Munich, HRB 214197 General Manager: Baurzhan Ismagulov
Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies
Hi, Quoting Uladzimir Bely (2021-10-28 10:58:26) > When building a package with sbuild, some packages (dependencies of package > being built) are internally downloaded and installed by apt. After the build > finished, schroot is cleaned again (while everything is done in overlay) > > I need to cache outside of schroot these .deb files that were downloaded by > apt. They are supposed to be used for creaing a local partial debian > repository, so that the second build will use this local repo instead of > internet one. > > Currently it's done by parsing dependencies and downloading them > independently, but I suppose there should be some more straightforward way to > get them using sbuild. > > I investigated and tried several options for sbuild (like > --purge-build=never, > --purge-deps=never, --purge-session=never), tried to find .deb files during > the build using at some stages (--pre-build-commands="ls -la /var/cache/apt/ > archives/", --starting-build-commands="ls -la /var/cache/apt/archives/", -- > finished-build-commands="ls -la /var/cache/apt/archives/") - but I couldn't > see any .deb files inside the schroot. > > I previously asked in debian-user maillist > (https://lists.debian.org/debian-user/2021/10/msg01044.html), but the tips I > got (like using caching proxy) are > not what I really need. While sbuild already does the thing (downloading/ > installing dependencies), I suppose there should be a way to (at least) see > the *.deb files downloaded in '/var/cache/apt/archives' inside schroot. sbuild maintainer here. You have not explained why you don't want to use a caching proxy like apt-cacher-ng. But using a caching proxy is also what I would suggest you use. If you don't want to use that, here is how you download only the packages you need to satisfy the build depenencies of a particular source package: cat << END > /tmp/apt.conf Apt::Architecture "amd64"; Dir "/tmp/apt"; Dir::Etc::trusted "/etc/apt/trusted.gpg"; Dir::Etc::trustedparts "/etc/apt/trusted.gpg.d/"; Apt::Get::Download-Only true; Apt::Install-Recommends false; END mkdir -p /tmp/apt/etc/apt/apt.conf.d/ /tmp/apt/etc/apt/sources.list.d/ /tmp/apt/var/lib/dpkg /tmp/apt/var/cache/apt/archives/partial /tmp/apt/etc/apt/preferences.d/ touch /tmp/apt/var/lib/dpkg/status cat << END > /tmp/apt/etc/apt/sources.list deb http://deb.debian.org/debian/ unstable main deb-src http://deb.debian.org/debian/ unstable main END APT_CONFIG=/tmp/apt.conf apt update APT_CONFIG=/tmp/apt.conf apt-get dist-upgrade APT_CONFIG=/tmp/apt.conf apt-get build-dep hello Now all your packages to build src:hello are in /tmp/apt/var/cache/apt/archives. No need to waste CPU cycles on a full package build if all you want is to download a certain set of binary packages. Thanks! cheers, josch signature.asc Description: signature
Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies
On Thu, Oct 28, 2021 at 11:58:26AM +0300, Uladzimir Bely wrote: > When building a package with sbuild, some packages (dependencies of package > being built) are internally downloaded and installed by apt. After the build > finished, schroot is cleaned again (while everything is done in overlay) > > I need to cache outside of schroot these .deb files that were downloaded by > apt. A caching proxy is indeed a good answer for this question but if for some reason you don't want to use it, you can bind-mount some directory from outside the chroot as /var/cache/apt/archives, e.g. via /etc/schroot/sbuild/fstab, and set $apt_keep_downloaded_packages=1. -- WBR, wRAR signature.asc Description: PGP signature
sbuild/schroot: need to get .deb files internally downloaded as package dependencies
When building a package with sbuild, some packages (dependencies of package being built) are internally downloaded and installed by apt. After the build finished, schroot is cleaned again (while everything is done in overlay) I need to cache outside of schroot these .deb files that were downloaded by apt. They are supposed to be used for creaing a local partial debian repository, so that the second build will use this local repo instead of internet one. Currently it's done by parsing dependencies and downloading them independently, but I suppose there should be some more straightforward way to get them using sbuild. I investigated and tried several options for sbuild (like --purge-build=never, --purge-deps=never, --purge-session=never), tried to find .deb files during the build using at some stages (--pre-build-commands="ls -la /var/cache/apt/ archives/", --starting-build-commands="ls -la /var/cache/apt/archives/", -- finished-build-commands="ls -la /var/cache/apt/archives/") - but I couldn't see any .deb files inside the schroot. I previously asked in debian-user maillist (https://lists.debian.org/debian-user/2021/10/msg01044.html), but the tips I got (like using caching proxy) are not what I really need. While sbuild already does the thing (downloading/ installing dependencies), I suppose there should be a way to (at least) see the *.deb files downloaded in '/var/cache/apt/archives' inside schroot. -- Uladzimir Bely Promwad Ltd. External service provider of ilbers GmbH Maria-Merian-Str. 8 85521 Ottobrunn, Germany +49 (89) 122 67 24-0 Commercial register Munich, HRB 214197 General Manager: Baurzhan Ismagulov
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Sun, Sep 12, 2021 at 03:10:27AM +, Paul Wise wrote:
> On Fri, Sep 10, 2021 at 6:03 PM David Kalnischkies wrote:
> > Because this thread started with the idea to switch the default of d-i
> > and co to another URI. If you target only apt then you still need
> > a solution for d-i and a way to convert whatever d-i had into what apt
> > gets in the end (of the installation).
>
> ISTR the future of creating new Debian installations is to move from
> debootstrap to dpkg/apt. As an interim step, debootstrap could move
> from doing its own downloads to passing the appropriate
> APT_CONFIG/DPKG_ROOT/etc to `apt download`.
>
> https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap
The spec deals with the installation of the essential set.
APT isn't essential – it is 'only' one of the first packages installed
after the bootstrap is done, usually at least.
Moving {,c}debootstrap to use apt means you increase the system
requirements from "can execute debootstrap" all the way up to "is
a fully bootstrapped Debian-based system". At which point you could
just use mmdebstrap instead of debootstrap and be done.
I am not involved with d-i to know if they would plan such a move, but
I have at least never heard of it and it seems outside the linked spec.
You might have confused this with the pipe-dream of obsoleting
mmdebstrap at some far away in the future point by folding it into apt
directly. The spec is one (of the many) pre-requirements for that.
Even if we do, that would move the goal post only slightly as you still
have the problem that the conf used to create the system might very well
not be the conf that can be used by the created system (as a trivial
example some old apt versions do not support https). That doesn't really
change regardless of using anna, debootstrap, apt or whatever else.
Best regards
David Kalnischkies
P.S.: Having apt be involved in its own bootstrap reminds me of that
time when I saved myself from drowning in a swamp by pulling on my hair…
https://en.wikipedia.org/wiki/Baron_Munchausen#Fictional_character
signature.asc
Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Sun, Sep 12, 2021 at 03:10:27AM +, Paul Wise wrote: > ISTR the future of creating new Debian installations is to move from > debootstrap to dpkg/apt. As an interim step, debootstrap could [...] I've switched all my occurances of using debootstrap to mmdebstrap and am a very happy user of it. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 6:03 PM David Kalnischkies wrote: > Because this thread started with the idea to switch the default of d-i > and co to another URI. If you target only apt then you still need > a solution for d-i and a way to convert whatever d-i had into what apt > gets in the end (of the installation). ISTR the future of creating new Debian installations is to move from debootstrap to dpkg/apt. As an interim step, debootstrap could move from doing its own downloads to passing the appropriate APT_CONFIG/DPKG_ROOT/etc to `apt download`. https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 08:02:42PM +0200, David Kalnischkies wrote: On Fri, Sep 10, 2021 at 11:08:38AM -0400, Michael Stone wrote: On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote: > On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote: > > The only thing I could see that would be a net gain would be to generalizes > > sources.list more. Instead of having a user select a specific protocol and > > path, allow the user to just select high-level objects. Make this a new > > pseudo-protocol for backward compatibility, and introduce something like > > deb apt:// suite component[s] > > so the default could be something like > > deb apt:// bullseye main > > deb apt:// bullseye/updates main > > then the actual protocols, servers, and paths could be managed by various > > plugins and overridden by configuration directives in apt.conf.d. For > > In this scheme the Debian bullseye main repo has the same 'URI' as the > Darts bullseye main repo. So, you would need to at least include an > additional unique identifier of the likes of Debian and Darts, but > who is to assign those URNs? > (Currently we are piggybacking on the domain name system for this) I have no idea what darts is, so I don't have an answer. :) "Darts" was just a play on "bullseye". It is not hard to imagine a repository which has the same suite and component(s) but is not Debian itself. As a pseudo-random [= its in an other topic here] real example you can take Wine (https://dl.winehq.org/wine-builds/debian/). So to what is "deb apt:// bullseye main" referring? Debian or Wine? And to pre-empt the most common response: As an apt dev I can assure you that we won't accept a solution involving "I am on Debian, so it means Debian" as that is impossible to correctly guess programmatically (for example on derivatives using a small overlay repo). I'd considered adding a scope to the model, e.g., apt://debian.org but removed it for simplicity. If that was a desired feature then there'd either have to be some sort of well-known path or such a distribution would need to provide a policy plugin for that scope. Alternatively, they could just use the existing http/https/whatever syntax in sources.list for their overlay if they didn't want to bother. Same for third party repos. > > their thing, and a plugin like auto-apt-proxy can override defaults to do > > something more complicated, using more policy-friendly .d configurations > > rather than figuring out a way to rewrite some other package's configuration > > file. > > JFTR: auto-apt-proxy has nothing to do with sources. It is true that > apt-cacher-ng (and perhaps others) have a mode of operation in which you > prefix the URI of your (in that case caching) proxy to the URI of the > actual repo, but that isn't how a proxy usually operates and/or is > configured. I have no idea what you're saying here. And I have no idea if you know what you are talking about. auto-apt-proxy already uses an interface apt provides to configure the proxy at runtime. It isn't in the business of modifying sources.list nor has it any interest in that. So you using it as an example for a plugin who could use your proposed scheme to modify the sources at runtime makes no sense. The concern I was responding to was that switching to https breaks the case of using auto-apt-proxy to cache the transaction. Just turning the proxy on and off isn't sufficient if the default sources.list uses https instead of http--you'd currently have to both turn the proxy on *and* change sources.list from http to https. Hence my musings on whether it's possible/desirable to separate the configuration of what to use as a transport from the configuration of what repository is desired. More generally, if we're talking about changing the default way that people interact with debian it just seems like a good time to ponder whether specifying sources the same way we did in 1998 makes sense given how many changes there have been to expectations about how we use internet resources. Maybe the answer is yes, and I'm not arguing that there has to be a change or that what I threw out as a possibility is the right answer, but it does seem worth considering.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 11:08:38AM -0400, Michael Stone wrote: > On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote: > > On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote: > > > The only thing I could see that would be a net gain would be to > > > generalizes > > > sources.list more. Instead of having a user select a specific protocol and > > > path, allow the user to just select high-level objects. Make this a new > > > pseudo-protocol for backward compatibility, and introduce something like > > > deb apt:// suite component[s] > > > so the default could be something like > > > deb apt:// bullseye main > > > deb apt:// bullseye/updates main > > > then the actual protocols, servers, and paths could be managed by various > > > plugins and overridden by configuration directives in apt.conf.d. For > > > > In this scheme the Debian bullseye main repo has the same 'URI' as the > > Darts bullseye main repo. So, you would need to at least include an > > additional unique identifier of the likes of Debian and Darts, but > > who is to assign those URNs? > > (Currently we are piggybacking on the domain name system for this) > > I have no idea what darts is, so I don't have an answer. :) "Darts" was just a play on "bullseye". It is not hard to imagine a repository which has the same suite and component(s) but is not Debian itself. As a pseudo-random [= its in an other topic here] real example you can take Wine (https://dl.winehq.org/wine-builds/debian/). So to what is "deb apt:// bullseye main" referring? Debian or Wine? And to pre-empt the most common response: As an apt dev I can assure you that we won't accept a solution involving "I am on Debian, so it means Debian" as that is impossible to correctly guess programmatically (for example on derivatives using a small overlay repo). > > Also, but just as an aside, whatever clever system you think of apt > > could be using, you still need a rather simple system for the likes of > > tools which come before apt like the installers/bootstrappers as they > > are not (all) using apt, especially not in the very early stages, and > > a mapping between them. > > I'm not sure why you think I need that? The goal of my musings is to Because this thread started with the idea to switch the default of d-i and co to another URI. If you target only apt then you still need a solution for d-i and a way to convert whatever d-i had into what apt gets in the end (of the installation). The configuration option which only works with apt tools already exists in the form of the mirror method… > > > their thing, and a plugin like auto-apt-proxy can override defaults to do > > > something more complicated, using more policy-friendly .d configurations > > > rather than figuring out a way to rewrite some other package's > > > configuration > > > file. > > > > JFTR: auto-apt-proxy has nothing to do with sources. It is true that > > apt-cacher-ng (and perhaps others) have a mode of operation in which you > > prefix the URI of your (in that case caching) proxy to the URI of the > > actual repo, but that isn't how a proxy usually operates and/or is > > configured. > > I have no idea what you're saying here. And I have no idea if you know what you are talking about. auto-apt-proxy already uses an interface apt provides to configure the proxy at runtime. It isn't in the business of modifying sources.list nor has it any interest in that. So you using it as an example for a plugin who could use your proposed scheme to modify the sources at runtime makes no sense. Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote: On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote: The only thing I could see that would be a net gain would be to generalizes sources.list more. Instead of having a user select a specific protocol and path, allow the user to just select high-level objects. Make this a new pseudo-protocol for backward compatibility, and introduce something like deb apt:// suite component[s] so the default could be something like deb apt:// bullseye main deb apt:// bullseye/updates main then the actual protocols, servers, and paths could be managed by various plugins and overridden by configuration directives in apt.conf.d. For In this scheme the Debian bullseye main repo has the same 'URI' as the Darts bullseye main repo. So, you would need to at least include an additional unique identifier of the likes of Debian and Darts, but who is to assign those URNs? (Currently we are piggybacking on the domain name system for this) I have no idea what darts is, so I don't have an answer. :) Also, but just as an aside, whatever clever system you think of apt could be using, you still need a rather simple system for the likes of tools which come before apt like the installers/bootstrappers as they are not (all) using apt, especially not in the very early stages, and a mapping between them. I'm not sure why you think I need that? The goal of my musings is to separate the definition of what set of debian packages to use from the decision of how to get those packages *when using apt*, so that there are fewer things to consider in the common case, and to allow new capabilities in uncommon cases. If someone's using some other tool, why would anyone assume that the same configuration syntax would work? Just use the same configuration file you use now, and ignore all of this. If you want configurations to match across tools, then ignore all of this again and keep the same sources.list syntax you're already using that presumably does what you want. If someone wants to use tor by default but fall back to https if it's unreachable, they can do that. If someone wants to use a local proxy via http but https if they're not on their local network, they can do that. New installations could default to https, existing installations can keep doing You can do most of the fallback part with the mirror method backed by a local file. It is of no concern to apt how that file comes to be, so you could create it out of a massive amount of options or simply by hand. I do think if the creation is tool-based it shouldn't be apt as I envision far too many unique snowflakes for a one-size-fits-all approach. The intent would be to make it easier to plug other tools into apt, not to have the apt codebase do everything. their thing, and a plugin like auto-apt-proxy can override defaults to do something more complicated, using more policy-friendly .d configurations rather than figuring out a way to rewrite some other package's configuration file. JFTR: auto-apt-proxy has nothing to do with sources. It is true that apt-cacher-ng (and perhaps others) have a mode of operation in which you prefix the URI of your (in that case caching) proxy to the URI of the actual repo, but that isn't how a proxy usually operates and/or is configured. I have no idea what you're saying here.
Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi, On 10.09.21 01:46, Paul Wise wrote: Another important argument is that it creates a dependency on third-party commercial CDNs, and their *continued* sponsorship. This dependency on external providers is unavoidable, Debian definitely cannot afford to run our own CDN at the scale needed to support our existing userbase. For example the security mirrors struggled with Linux kernel security updates, so security.d.o switched to a commercial CDN. Also, we are dependent on continued sponsorship for all of our infrastructure, paying for all of our hosting is likely not feasible. Yes -- and mirrors have traditionally been provided by third parties. What is new about the CDNs is that there are rather few of those, and this centralization aspect is what worries me. Personally I'd like to see a larger variety of Debian delivery mechanisms; copy Debian/snapshot to archive.org, create a multi-distro FLOSS CDN, bring back httpredir, DebTorrent and apt-p2p, add an i2p mirror, use IPFS and content oriented networking etc. Michael Stone's apt://debian idea seems like a good way to move in that direction while adding protocol agility. Yes, absolutely -- and we especially want to have a better solution for containers, because my expectation is that a large fraction of our traffic is just people not bothering to set up caching. Simon
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote: > The only thing I could see that would be a net gain would be to generalizes > sources.list more. Instead of having a user select a specific protocol and > path, allow the user to just select high-level objects. Make this a new > pseudo-protocol for backward compatibility, and introduce something like > deb apt:// suite component[s] > so the default could be something like > deb apt:// bullseye main > deb apt:// bullseye/updates main > then the actual protocols, servers, and paths could be managed by various > plugins and overridden by configuration directives in apt.conf.d. For In this scheme the Debian bullseye main repo has the same 'URI' as the Darts bullseye main repo. So, you would need to at least include an additional unique identifier of the likes of Debian and Darts, but who is to assign those URNs? (Currently we are piggybacking on the domain name system for this) Also, but just as an aside, whatever clever system you think of apt could be using, you still need a rather simple system for the likes of tools which come before apt like the installers/bootstrappers as they are not (all) using apt, especially not in the very early stages, and a mapping between them. > If someone wants to use tor by default but fall back to https if it's > unreachable, they can do that. If someone wants to use a local proxy via > http but https if they're not on their local network, they can do that. New > installations could default to https, existing installations can keep doing You can do most of the fallback part with the mirror method backed by a local file. It is of no concern to apt how that file comes to be, so you could create it out of a massive amount of options or simply by hand. I do think if the creation is tool-based it shouldn't be apt as I envision far too many unique snowflakes for a one-size-fits-all approach. (The Tor to https fallback can be done already if we talk onion services to others. You can't fall out of Tor – or redirect into it – through as that would allow bad actors to discover who you are/that you have an operational tor client installed. proxy configuration you can already change programmatically on the fly – a job auto-apt-proxy implements –, changing the mirror file with a hook from your network manager would be equally easy.) > their thing, and a plugin like auto-apt-proxy can override defaults to do > something more complicated, using more policy-friendly .d configurations > rather than figuring out a way to rewrite some other package's configuration > file. JFTR: auto-apt-proxy has nothing to do with sources. It is true that apt-cacher-ng (and perhaps others) have a mode of operation in which you prefix the URI of your (in that case caching) proxy to the URI of the actual repo, but that isn't how a proxy usually operates and/or is configured. Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 09:33:56AM +0200, Helmut Grohne wrote: Laptops of end-user systems are the target, but also developers. When people gather at a place (conference, hackspace, private meetup, etc.) downloading of .debs should just work quickly by default. Many such sites could easily provide a local cache and a number even do. BSPs tend to have a blackboard with information including the local mirror to use. Seriously, how many people change their mirror when they go to a BSP? If we installed auto-apt-proxy by default, much of the local caching would just work. I think you'd get a lot of pushback on installing auto-apt-proxy by default. If that's a proposal, make it seperately and not in this thread. The thing we seem to be disagreeing on is what is more important? https by default or quick and efficient downloads? Some may think that our CDN can handle the load just fine and the effects of caching are peanuts. I can attest that those peanuts are 4TB/year (equivalent to 8 days waiting for downloads) for me. I see that we've given up on a global network of independently-managed mirrors and that CDNs are way easier at this time. While initially CDNs had bad reliability issues, those have completely vanished in my experience. On the other hand, local caching still outperforms CDNs by a factor of 10 or so. I'd love to make it the default. I use a cache out of habit and to be a good netizen, but my internet connection is fast enough these days that it's basically a noop at best and a slight slowdown at worst. I had to move the cache from slow/cheap spinning disk to reasonably fast SSD to get to that point. If you're downloading the same stuff over and over (e.g., for testing or somesuch) it can be a big win, especially for VMs on a virtualized network connection, or if you're managing a large infrastructure, but for normal use with a couple of instances? It's just not worth the trouble.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 12:00:57PM +0200, Timo Röhling wrote: * Michael Stone [2021-09-08 19:25]: I think the issue isn't certificate validation, it's that https proxy requests are made via CONNECT rather than GET. You could theoretically rewrite the proxy mechanism to MITM the CONNECT, but that wouldn't be a drop-in replacement. I suppose you could instead add an apt option to pass the https request to the proxy via GET instead of using CONNECT, but I think that also won't necessarily work on an existing proxy. apt-cacher-ng has a second mode of operation where you can prefix the source URL with the proxy URL, i.e. deb http://proxyhost:3142/deb.debian.org/debian unstable main Maybe we could introduce this as an "official" APT proxy mode, where http(s)://REPO gets replaced by http://PROXY_URL/REPO (and the proxy can decide whether or not to fetch via HTTPS as an implementation detail)? I'd much rather see something more like I proposed earlier (splitting the selection of what suites/components to install from the policy of how to obtain them) rather than further layering+confusing these two concepts within sources.list.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
* Michael Stone [2021-09-08 19:25]: I think the issue isn't certificate validation, it's that https proxy requests are made via CONNECT rather than GET. You could theoretically rewrite the proxy mechanism to MITM the CONNECT, but that wouldn't be a drop-in replacement. I suppose you could instead add an apt option to pass the https request to the proxy via GET instead of using CONNECT, but I think that also won't necessarily work on an existing proxy. apt-cacher-ng has a second mode of operation where you can prefix the source URL with the proxy URL, i.e. deb http://proxyhost:3142/deb.debian.org/debian unstable main Maybe we could introduce this as an "official" APT proxy mode, where http(s)://REPO gets replaced by http://PROXY_URL/REPO (and the proxy can decide whether or not to fetch via HTTPS as an implementation detail)? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
Hallo, * Michael Stone [Wed, Sep 08 2021, 07:25:26PM]: > On Wed, Sep 08, 2021 at 03:56:14PM +0200, Ansgar wrote: > > On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote: > > > On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote: > > > > So what do you suggest then? Tech-ctte as with merged-/usr? Or a > > > > GR? Or > > > > something else? > > > > > > I propose that the proponents pay the cost. In this case, it is a bit > > > unclear what that means precisely (which likely is the reason they > > > haven't done it already). At the very least though, apt install > > > auto-apt-proxy should continue to work on a default installation in a > > > sensible way. > > > > I can file a bug for auto-apt-proxy to include an apt.conf snippet > > saying > > > > Acquire::https::Verify-Peer false; > > > > That clearly makes it work again > > I think the issue isn't certificate validation, it's that https proxy > requests are made via CONNECT rather than GET. You could theoretically > rewrite the proxy mechanism to MITM the CONNECT, but that wouldn't be a > drop-in replacement. I suppose you could instead add an apt option to pass > the https request to the proxy via GET instead of using CONNECT, but I think Precisely. Current handling of HTTPS on a caching proxy is either impossible or PITA for the user, as long as a such mixed behavior is not configurable. apt-cacher-ng works around that by telling users to disguise https URLs as HTTP with a special marker for protocol switch (ugly, I know). Also keep in mind that it off-loads the encryption work to the proxy, but that might be even intentional. > that also won't necessarily work on an existing proxy. Speaking at least for ACNG, my assumption was that it would support that but I was wrong. TODO created, https://salsa.debian.org/blade/apt-cacher-ng/-/issues/11 . > If we're imagining apt options, something like > Acquire::https::Force-Proxy-HTTP true; > would probably be more useful for this specific case (not that I think it's > a great idea--too much potential for surprise). I would make it a list of trusted proxy hosts and a special value ALL. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994032 created. Best regards, Eduard.
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, 2021-09-10 at 09:33 +0200, Helmut Grohne wrote: > If > we installed auto-apt-proxy by default, much of the local caching > would > just work. If you push for a local caching method to be used by default, apt should always request (In)Release.gpg from a regular mirror (not auto- discovered local cache), preferably via HTTPS; for subsequent data (which apt can verify via (In)Release) a local mirror can be used, falling back to the regular mirror when the data provided by the local cache is not correct for any reason. Especially at BSPs where people are likely to bootstrap new environments (via debootstrap, for example for building packages) we would allow downgrade attacks otherwise: (In)Release for stable releases has no Valid-Until, so any initial (In)Release file can be substituted by the cache operator for an older one which then refers to known-vulnerable packages. (And I'm not sure debootstrap even checks Valid-Until.) Ansgar
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 07:12:18PM -0400, Michael Stone wrote: > Why not simply automate setting it at install time using preseed? I'm > honestly not sure who the target audience for auto-apt-proxy is--apparently > someone who has an infrastructure including a proxy, possibly the ability to > set dns records, etc., but can't change defaults at install time or via some > sort of runtime configuration management? I believe that the target audience is non-tech end-users. Most orgnizations already optimized their way of downloading .debs via some way (e.g. auto-apt-proxy) or another. As you point out, organizations are easily able to deviate from defaults. They're not our primary target with defaults. Laptops of end-user systems are the target, but also developers. When people gather at a place (conference, hackspace, private meetup, etc.) downloading of .debs should just work quickly by default. Many such sites could easily provide a local cache and a number even do. BSPs tend to have a blackboard with information including the local mirror to use. Seriously, how many people change their mirror when they go to a BSP? If we installed auto-apt-proxy by default, much of the local caching would just work. The thing we seem to be disagreeing on is what is more important? https by default or quick and efficient downloads? Some may think that our CDN can handle the load just fine and the effects of caching are peanuts. I can attest that those peanuts are 4TB/year (equivalent to 8 days waiting for downloads) for me. I see that we've given up on a global network of independently-managed mirrors and that CDNs are way easier at this time. While initially CDNs had bad reliability issues, those have completely vanished in my experience. On the other hand, local caching still outperforms CDNs by a factor of 10 or so. I'd love to make it the default. Helmut
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 9, 2021 at 6:03 PM Simon Richter wrote: > Another important argument is that it creates a dependency on > third-party commercial CDNs, and their *continued* sponsorship. This dependency on external providers is unavoidable, Debian definitely cannot afford to run our own CDN at the scale needed to support our existing userbase. For example the security mirrors struggled with Linux kernel security updates, so security.d.o switched to a commercial CDN. Also, we are dependent on continued sponsorship for all of our infrastructure, paying for all of our hosting is likely not feasible. https://wiki.debian.org/ExternalEntities > Debian is very conservative when spending money and generally shies away > from recurring expenses because we do not want to find us in a situation > where we are dependent on an external entity making a timely donation in > order to keep operations running, so I wonder why we are that accepting > of it in one of our core services, and I certainly don't think we should > be adding additional roadblocks should we ever need to find an alternative. DSA setup the CDN provider solution to give the Debian userbase a better experience than having to choose a mirror and a better experience than httpredir.d.o's redirect method. We have multiple CDN providers to mitigate the dependency, and other providers who we aren't yet using that are offering service. So, as much as I dislike CDNs as a concept, I recognise that we currently need them and think that we are able to handle loss of a CDN provider or two. > We have a (crude) load-balancing framework in infrastructure we control > that can point requests towards a set of untrusted mirrors, and while > it's nice that we don't *need* to use this fallback plan, it is > reassuring it is there. httpredir.d.o no longer exists, it points at deb.d.o, so it would have to be rebuilt if we were to need to switch away from CDNs. Personally I'd like to see a larger variety of Debian delivery mechanisms; copy Debian/snapshot to archive.org, create a multi-distro FLOSS CDN, bring back httpredir, DebTorrent and apt-p2p, add an i2p mirror, use IPFS and content oriented networking etc. Michael Stone's apt://debian idea seems like a good way to move in that direction while adding protocol agility. > If they ask why we're not using HTTPS, yes: it helps clear up the > misconception that anything with an "s" in it is secure and can be trusted. The volume of questions about missing https means that it is more efficient to just use https than to have to reply to new questions about it. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi, On 04.09.21 22:12, Hideki Yamane wrote: The TLS layer is not part of the security model, so we'd be teaching users to look for the wrong thing, kind of like the "encrypted with SSL" badges on web pages in the 90ies. Is there any strong reason to use HTTP than HTTPS now? The strongest reason (IMO) in favor of unencrypted transmission is that it doesn't introduce a policy decision. The package "ca-certificates" must be installed and a checkmark set for the "mozilla/ISRG_Root_X1.crt" certificate, otherwise updates will break. If we want to have HTTPS as default, we need additional logic to make sure certificates are installed and cannot be deinstalled (so Essential or a strong dependency chain from an Essential package) and that the certificate cannot be deactivated, or apt needs its own repository of trusted certificates. With the current Docker images: $ docker run --rm -it debian:bullseye root@32529bf86cd3:/# sed -i -e s/http/https/ /etc/apt/sources.list root@32529bf86cd3:/# apt update Err:1 https://deb.debian.org/debian bullseye InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 199.232.138.132 443] Err:2 https://security.debian.org/debian-security bullseye-security InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 151.101.66.132 443] Err:3 https://deb.debian.org/debian bullseye-updates InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 199.232.138.132 443] So changing the default is not sufficient here, we'd need a lot of additional work and testing to ensure this works for everyone, not just the desktop users. Another important argument is that it creates a dependency on third-party commercial CDNs, and their *continued* sponsorship. Debian is very conservative when spending money and generally shies away from recurring expenses because we do not want to find us in a situation where we are dependent on an external entity making a timely donation in order to keep operations running, so I wonder why we are that accepting of it in one of our core services, and I certainly don't think we should be adding additional roadblocks should we ever need to find an alternative. We have a (crude) load-balancing framework in infrastructure we control that can point requests towards a set of untrusted mirrors, and while it's nice that we don't *need* to use this fallback plan, it is reassuring it is there. Should we teach all our users (including non-tech) about "Secure APT" mechanism? If they ask why we're not using HTTPS, yes: it helps clear up the misconception that anything with an "s" in it is secure and can be trusted. Anyone who configures an additional source needs to know how the authentication mechanism works anyway, so we're not gaining anything there either. Simon OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
* Michael Stone [2021-09-09 09:05]: Because the controversy concerning changing the default is over whether it's reasonable for someone using auto-apt-proxy to have to manage additional configuration settings. Ah, I understand your point now and I agree. It would be an inconvenience, yes, not but much more. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 09, 2021 at 02:54:21PM +0200, Timo Röhling wrote: * Michael Stone [2021-09-09 08:32]: I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. None of that speaks to whether an organization that deploys such a thing has the ability to manage other configuration settings, even if for some settings there's a desire for additional flexibility. I don't understand your point. You asked for a target audience for auto-apt-proxy. I gave you a legitimate (and real-world) example for such a deployment. Why should it matter whether or not an organization has other configuration facilities? Because the controversy concerning changing the default is over whether it's reasonable for someone using auto-apt-proxy to have to manage additional configuration settings. If the target audience is someone who has the ability to manage the infrastructure required by auto-apt-proxy but not the ability to manage anything else then I guess it's a valid criticism (but I have trouble envisioning that). If the auto-apt-proxy target audience can manage both the proxy infrastructure *and* sources.list (either at install time or run time) then the criticism is basically academic and not generally a real-world issue.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
* Michael Stone [2021-09-09 08:32]: I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. None of that speaks to whether an organization that deploys such a thing has the ability to manage other configuration settings, even if for some settings there's a desire for additional flexibility. I don't understand your point. You asked for a target audience for auto-apt-proxy. I gave you a legitimate (and real-world) example for such a deployment. Why should it matter whether or not an organization has other configuration facilities? As another example, nobody says: "the target audience for DHCP is an organization who has an infrastructure with full control over a network, including IP address management, but apparently can't configure IP addresses at install time or via some sort of runtime configuration management" and concludes that DHCP is useless. auto-apt-proxy (or DHCP for that matter) *is* the runtime configuration management, and a quite efficient one at that. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 09, 2021 at 11:54:44AM +0530, Pirate Praveen wrote: Why can't auto-apt-proxy ask this as a debconf question? I also like auto-apt-proxy but I agree with this, someone needing auto-apt-proxy should be able to change the default as well. I don't really see why adding another debconf question would be better than just preseeding the existing one. The only thing I could see that would be a net gain would be to generalizes sources.list more. Instead of having a user select a specific protocol and path, allow the user to just select high-level objects. Make this a new pseudo-protocol for backward compatibility, and introduce something like deb apt:// suite component[s] so the default could be something like deb apt:// bullseye main deb apt:// bullseye/updates main then the actual protocols, servers, and paths could be managed by various plugins and overridden by configuration directives in apt.conf.d. For existing configurations it's a no-op but it allows more flexibility & new plugins/protocols in the future without having to micromanage sources.list. If someone wants to use tor by default but fall back to https if it's unreachable, they can do that. If someone wants to use a local proxy via http but https if they're not on their local network, they can do that. New installations could default to https, existing installations can keep doing their thing, and a plugin like auto-apt-proxy can override defaults to do something more complicated, using more policy-friendly .d configurations rather than figuring out a way to rewrite some other package's configuration file.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 09, 2021 at 08:36:28AM +0200, Timo Röhling wrote: * Michael Stone [2021-09-08 19:12]: Why not simply automate setting it at install time using preseed? I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. None of that speaks to whether an organization that deploys such a thing has the ability to manage other configuration settings, even if for some settings there's a desire for additional flexibility.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
* Michael Stone [2021-09-08 19:12]: Why not simply automate setting it at install time using preseed? I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
2021, സെപ്റ്റംബർ 9 4:42:18 AM IST, Michael Stone ൽ എഴുതി >On Wed, Sep 08, 2021 at 01:09:13PM +0200, Helmut Grohne wrote: >>Enabling https by default quite simply breaks the simple recipe of >>installing auto-apt-proxy. Would you agree with auto-apt-proxy's >>postinst automatically editing your sources.list to drop the s out of >>https? The answer repeatedly given in this thread to do so manually is >>very unsatisfying. > >Why not simply automate setting it at install time using preseed? I'm >honestly not sure who the target audience for auto-apt-proxy >is--apparently someone who has an infrastructure including a proxy, >possibly the ability to set dns records, etc., but can't change defaults >at install time or via some sort of runtime configuration management? > Why can't auto-apt-proxy ask this as a debconf question? I also like auto-apt-proxy but I agree with this, someone needing auto-apt-proxy should be able to change the default as well. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
All, I am against automatically setting HTTPS. Their should be an option in the installer to set or unset HTTPS while configuring the mirror! I like a lot of folks am on a metered internet connection with a UTM proxy firewall. I have multiple computers that need patched and only having to download the package once is a great convenience to both data usage and download time as my internet is not fast 4G LTE usually only operating at 3G speed. Tim
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 03:56:14PM +0200, Ansgar wrote: On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote: On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote: > So what do you suggest then? Tech-ctte as with merged-/usr? Or a > GR? Or > something else? I propose that the proponents pay the cost. In this case, it is a bit unclear what that means precisely (which likely is the reason they haven't done it already). At the very least though, apt install auto-apt-proxy should continue to work on a default installation in a sensible way. I can file a bug for auto-apt-proxy to include an apt.conf snippet saying Acquire::https::Verify-Peer false; That clearly makes it work again I think the issue isn't certificate validation, it's that https proxy requests are made via CONNECT rather than GET. You could theoretically rewrite the proxy mechanism to MITM the CONNECT, but that wouldn't be a drop-in replacement. I suppose you could instead add an apt option to pass the https request to the proxy via GET instead of using CONNECT, but I think that also won't necessarily work on an existing proxy. If we're imagining apt options, something like Acquire::https::Force-Proxy-HTTP true; would probably be more useful for this specific case (not that I think it's a great idea--too much potential for surprise).
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 01:09:13PM +0200, Helmut Grohne wrote: Enabling https by default quite simply breaks the simple recipe of installing auto-apt-proxy. Would you agree with auto-apt-proxy's postinst automatically editing your sources.list to drop the s out of https? The answer repeatedly given in this thread to do so manually is very unsatisfying. Why not simply automate setting it at install time using preseed? I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management?
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote: > On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote: > > So what do you suggest then? Tech-ctte as with merged-/usr? Or a > > GR? Or > > something else? > > I propose that the proponents pay the cost. In this case, it is a bit > unclear what that means precisely (which likely is the reason they > haven't done it already). At the very least though, apt install > auto-apt-proxy should continue to work on a default installation in a > sensible way. I can file a bug for auto-apt-proxy to include an apt.conf snippet saying Acquire::https::Verify-Peer false; That clearly makes it work again: you ask for auto-apt-proxy users to have connections that can be impersonated by a man in the middle by default. The above setting does that. Not verifying certificates for some users seems better than having all users not verify certificates (as no https is used at all). > In > the absence of reason not to use https, https should be preferred. As > it > happens, we figured a reason not to use https. I can find a reason not to use https for any protocol (some sites want to inspect/cache all traffic) :-) Ansgar
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote: > So what do you suggest then? Tech-ctte as with merged-/usr? Or a GR? Or > something else? I propose that the proponents pay the cost. In this case, it is a bit unclear what that means precisely (which likely is the reason they haven't done it already). At the very least though, apt install auto-apt-proxy should continue to work on a default installation in a sensible way. > > * Concerns are ignored. <- This is where we are with https-default. > > It's also where we are with keep-http-as-default. I don't think https resolves any concerns. It's merely best-practice. In the absence of reason not to use https, https should be preferred. As it happens, we figured a reason not to use https. > > Change has a cost. I do not want to pay the cost for either of these > > changes. > > Then we could never change anything. Untrue. You get to choose which changes you want to pay the cost for. For instance, I want Debian to be cross buildable and bootstrappable. Holger, Mattia and a few others want Debian to be reproducible. You don't get to pay the cost for those changes. Change is possible in a way that limits cost for uninterested people. The contentious changes are the ones where the initiators fail to pay the cost. > To keep up with merged-/usr: keeping non-merged-/usr also has a cost. > Nobody wants to pay the cost for it. That is very true. With merged-/usr, I suppose most grief arises from the way the transition was (not) planned and only a minority takes issue with the goal. Helmut
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, 2021-09-08 at 13:13 +0100, Tim Woodall wrote: > This is a bit tongue in cheek, but how about these sites where the > .debs are downloaded from publish their *private* key? They openly > accept that anyone can MITM them. If you have access to the private key, you can request the CA to revoke the certificate: +--- | 4.9.1.1 Reasons for Revoking a Subscriber Certificate | | The CA SHALL revoke a Certificate within 24 hours if one or more of | the following occurs: | [...] | 3. The CA obtains evidence that the Subscriber’s Private Key | corresponding to the Public Key in the Certificate suffered a Key | Compromise +---[ https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf ] So that would not be helpful. Ansgar
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, 8 Sep 2021, Helmut Grohne wrote: I do see the advantages of using https. I do not see how to not make it happen without breaking relevant use cases. Same with the /usr-merge. I do see the advantages. I've stopped counting the things that broke. Most recent one is the uucp FTBFS. Change has a cost. I do not want to pay the cost for either of these changes. This is a bit tongue in cheek, but how about these sites where the .debs are downloaded from publish their *private* key? They openly accept that anyone can MITM them. That way people who want to see "https" can see it. And people who want the benefits of http can, with a bit of work, simulate that. It also nicely addresses my concern which is that the next demand will be to drop http (because when you visit the site with a webbrowser users start getting a warning that the site is also available over http or something like that because the google/firefox dream seems to be that you cannot use http even where https doesn't add anything.)
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, 2021-09-08 at 13:53 +0200, Helmut Grohne wrote: > On Wed, Sep 08, 2021 at 01:37:37PM +0200, Ansgar wrote: > > Maybe we should just find out who is responsible for this decision > > and > > reassign the bug to them. The installer team maintaining d-i and > > debootstrap or the mirror team seem reasonable choices? > > We've already tried that approach on the /usr-merge and the resulting > transition is miserable. Let's not repeat that mistake. So what do you suggest then? Tech-ctte as with merged-/usr? Or a GR? Or something else? > It's the same pattern actually: > * People propose a change that does have positive effects, though > some > find the positive effects unimportant. > * Other people disagree and raise concerns. > * Concerns are ignored. <- This is where we are with https-default. It's also where we are with keep-http-as-default. > Change has a cost. I do not want to pay the cost for either of these > changes. Then we could never change anything. To keep up with merged-/usr: keeping non-merged-/usr also has a cost. Nobody wants to pay the cost for it. Ansgar
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 01:37:37PM +0200, Ansgar wrote: > Maybe we should just find out who is responsible for this decision and > reassign the bug to them. The installer team maintaining d-i and > debootstrap or the mirror team seem reasonable choices? We've already tried that approach on the /usr-merge and the resulting transition is miserable. Let's not repeat that mistake. It's the same pattern actually: * People propose a change that does have positive effects, though some find the positive effects unimportant. * Other people disagree and raise concerns. * Concerns are ignored. <- This is where we are with https-default. * Change is being implemented anyway. * Stuff breaks. <- This is where we are with /usr-merge. This is frustrating. I do see the advantages of using https. I do not see how to not make it happen without breaking relevant use cases. Same with the /usr-merge. I do see the advantages. I've stopped counting the things that broke. Most recent one is the uucp FTBFS. Change has a cost. I do not want to pay the cost for either of these changes. Helmut
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, 2021-09-08 at 13:09 +0200, Helmut Grohne wrote:
> On Thu, Sep 02, 2021 at 10:22:15AM +0900, Hideki Yamane wrote:
> > Some users want proxy but they can configure their settings.
> > So just change "default setting for {deb,security}.debian.org"
> > is not so harmful, IMO.
>
> I fear you are putting this upside down. In reality, some sites (not
> users) want their users to use their local cache (transparently or
> not).
Then have the users install the site's CA authority that allows
inspecting and caching HTTPS traffic.
> Unfortunately, I don't see consensus for this, but at the same time I
> neither see consensus for enabling https by default. It's a matter
> that
> keeps popping up and people disagreeing on over and over again. The
> one
> thing that we have clearly understood at this point is that one size
> does not fit everyone. Either way makes some people unhappy.
Maybe we should just find out who is responsible for this decision and
reassign the bug to them. The installer team maintaining d-i and
debootstrap or the mirror team seem reasonable choices?
Ansgar
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi,
On Thu, Sep 02, 2021 at 10:22:15AM +0900, Hideki Yamane wrote:
> Some users want proxy but they can configure their settings.
> So just change "default setting for {deb,security}.debian.org"
> is not so harmful, IMO.
I fear you are putting this upside down. In reality, some sites (not
users) want their users to use their local cache (transparently or not).
> - Users can choose other mirror than https://deb.debian.org
As far as I can tell, most users don't want to make a choice here. They
want downloading packages to just work. Preferably fast. It is the
"fast" thing that you are breaking here.
> - Caching .debs from security.debian.org is not so huge, I guess
>(maybe except linux-image).
Not sure why security.d.o is singled out here. The switch is only
reasonable on the whole or not at all. And there the whole volume of
packages counts.
Enabling https by default quite simply breaks the simple recipe of
installing auto-apt-proxy. Would you agree with auto-apt-proxy's
postinst automatically editing your sources.list to drop the s out of
https? The answer repeatedly given in this thread to do so manually is
very unsatisfying.
So I actually argue for installing auto-apt-proxy by default and inside
d-i. That is in direct conflict with the proposed change here.
Unfortunately, I don't see consensus for this, but at the same time I
neither see consensus for enabling https by default. It's a matter that
keeps popping up and people disagreeing on over and over again. The one
thing that we have clearly understood at this point is that one size
does not fit everyone. Either way makes some people unhappy.
Helmut
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 03, 2021 at 02:42:29AM +, Paul Wise wrote: > httpredir.d.o was an alternative CDN-like thing that was based on HTTP > redirects to the mirror network. It had lots of problems, but now that > we have a mirror checker and zzz-dists, perhaps it could work better. > The mirror:// method in apt has probably improved since then too. If you wanted to bring back a httpredir-like¹ you are better of to combine both approaches as in: Have apt request a list of mirrors to use via mirror(+https) and have the server generate that list based on the requester as that gives you the "regional" mirrors as did httpredir while solving the major grip it had by having a list of mirrors to use, rather than one potentially non-working slightly outdated partial mirror (and the httpredir service is contacted by each client once rather than for each individual file to then be redirected elsewhere). Obviously, that approach is only workable if you are actually using libapt tools. Most debootstrap implementations couldn't really use that which might or might not be a problem for a given use case. Such a service would also have a hard time to 'redirect' you to a local mirror in your network (compared to an 'official' region one). So that isn't really what seems to be the main worry here: https prevents MitM attacks including the friendly MitM ones like the local network at home/at DebConf telling my laptop that there is an on-site mirror or not telling at all and just proxy transparently the entire network. The later seems done for in a https-world, but the former might be somewhat salvageable: We will have to get the Release² file(s) from the repo defined in the sources, but the index files and debs after that are a fairer game to get from elsewhere as they are either identical with what the defined source would have provided or a hard error. That still violates the privacy guarantees https has (assuming it does), so that would still need to be opt-in/out, but that is a one time choice per machine and could be similar in style to auto-apt-proxy. Anyway, implementation wise apt could tell $MAGIC which repo it is interested in (by Origin & Label) and would in return get a list of mirrors as apt-transport-mirror would. apt would then add the original source as least priority fallback and proceed with that list for this source. I say $MAGIC as I don't want apt to hard code the specifics of how to get the list, similar to how it is agnostic to how a proxy is currently picked up, as I could envision different implementations depending on use cases. That is different to just using apt-transport-mirror directly in the sources in so far as the provider of the list remains untrusted (beside that nobody is constantly editing their sources to adapt to the local network the machine currently resides in). Relatively quickly thought up, probably full of holes and not implemented at all in apt so far, but if someone thinks that might work feel free to report as a feature request against apt and I will see what I can do from the apt side. It at least seems slightly more workable than hoping to prevent https – which might have just as dubious a chance to succeed as https has to factually improve security in terms of apt. > Maybe http redirects to local mirrors could be feasible again, but it > would take a lot of work. fwiw: apt does not allow https to http redirects (some https repos ran into this in the past like those hosted on sourceforge until they fixed their https 'everywhere' configuration). In this regard apt is stricter than a normal webbrowser (a mirror list acquired via https can redirect to http mirrors though, but see the man pages for details). Best regards David Kalnischkies ¹ which deb.d.o sort of is just that it is nowadays done via SRV instead of an explicit HTTP redirect – and that only one mirror is in the list rather than multiple httpredir had picked one to redirect to. ² The main security benefit of https for apt is that you can't fiddle with the Release file, mostly in terms of sending an older one (in the limits of Valid-Until if used). It is also minor in size compared to the indexes and especially the debs, so caching them is not much of a concern (if a cacher was even doing it, it probably shouldn't). signature.asc Description: PGP signature
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, 2 Sep 2021 21:26:11 +0200 Simon Richter wrote: > The TLS layer is not part of the security model, so we'd be teaching > users to look for the wrong thing, kind of like the "encrypted with SSL" > badges on web pages in the 90ies. Is there any strong reason to use HTTP than HTTPS now? Should we teach all our users (including non-tech) about "Secure APT" mechanism? And I said about only deb.debian.org and security.debian.org, and just "default" - it means it does provide http access too. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi, On 03.09.21 13:11, Simon Richter wrote: [Revocation mechanism] If we don't have one, shouldn't we worry more about that given the widespread use of TLS? We have a big hammer, shipping a new ca-certificates package. If we want something that only affects apt, but not other packages, that mechanism doesn't exist yet. I think that's an interesting point, not just for revocation. There are forces pushing for more agility, switching out roots of trust more frequently. So for very old releases, you usually had the signing key of the next release on disk, so you could move to the next release. In this case you sort of risk not having the TLS authority on disk to make that happen. And of course we need to track what the authorities are doing that our frontends are using (e.g. [1] around how to deal with old Android devices). But then I'm not sure how much we need to care about ancient releases that are out of security support. We would need to commit to regularly update the certificate bundle, though. To your other point: I don't think managing trust into individual CAs will scale. We cannot really anticipate which CAs we are going to use in the future. Kind regards Philipp Kern [1] https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, 2021-09-03 at 13:11 +0200, Simon Richter wrote: > > > - If I deselect all CAs in the configuration dialog of the > > > ca-certificates package, what mechanism will allow apt to work? > > > If people intentionally detrust them, they have to deal with the > > fallout. > > So this introduces a policy that users need to mark X.509 CAs as > trusted? No. > > People can also detrust Debian's OpenPGP signing keys; it's > > not much different. > > The Debian signing keys have separate trust setup, and are trusted > for nothing but APT updates. > > If we wanted the same for X.509, we'd need /etc/apt/ca-certificates > or > something such, and apt to configure the list of accepted CAs > explicitly > in the TLS layer rather than using the default settings. People who only want to trust specific CAs for APT can do that. APT has a CaPath setting. > > Accessing www.debian.org will also not work on such systems (and > > unlike > > deb.d.o that does not even offer non-https). It's not Debian's > > problem. > > There are a lot of systems out there that have no need to access > www.debian.org, but do need to access deb.debian.org. And nothing stops them from doing so. > > > - Do we want to pin the certificate provider for Debian > > > mirrors, in > > > the knowledge that we want to be bound to this provider for > > > several > > > years, do we want any "root" CA to be able to provide a trust > > > anchor? > > > Probably not? > > So what do we want then? A list of root CAs that users have to mark > as trusted, possibly with an "are you sure?" dialog in ca- > certificates? We already have that. > This isn't a simple change of default, because this simple change > pulls in a lot of dependencies. ca-certificates should already be installed by default (it is Priority: standard and recommended by apt). > That users can override the default means adding another work step > for users, either a manual step that needs to be performed after a > manual installation, or an automated step that needs to be integrated > into users' deployment processes. I don't see the problem? Currently we add another work step for users that want to use https. > > If we don't have one, shouldn't we worry more about that given the > > widespread use of TLS? > > We have a big hammer, shipping a new ca-certificates package. If we > want something that only affects apt, but not other packages, that > mechanism doesn't exist yet. If a CA is untrustworthy, I don't think we would only want to detrust it for apt's https method. So I see no problem. > > It's not about what I like, but on what external services we want to > depend. So your concern is about Debian providing the deb.debian.org service at all? That seems unrelated to the https or not question. Ansgar
Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi, On 02.09.21 23:02, Ansgar wrote: As it is now, I can install a Debian system where no X.509 certificate authorities are trusted. That doesn't change with the proposal? - If I deselect all CAs in the configuration dialog of the ca-certificates package, what mechanism will allow apt to work? If people intentionally detrust them, they have to deal with the fallout. So this introduces a policy that users need to mark X.509 CAs as trusted? People can also detrust Debian's OpenPGP signing keys; it's not much different. The Debian signing keys have separate trust setup, and are trusted for nothing but APT updates. If we wanted the same for X.509, we'd need /etc/apt/ca-certificates or something such, and apt to configure the list of accepted CAs explicitly in the TLS layer rather than using the default settings. Accessing www.debian.org will also not work on such systems (and unlike deb.d.o that does not even offer non-https). It's not Debian's problem. There are a lot of systems out there that have no need to access www.debian.org, but do need to access deb.debian.org. - Do we want to pin the certificate provider for Debian mirrors, in the knowledge that we want to be bound to this provider for several years, do we want any "root" CA to be able to provide a trust anchor? Probably not? So what do we want then? A list of root CAs that users have to mark as trusted, possibly with an "are you sure?" dialog in ca-certificates? This isn't a simple change of default, because this simple change pulls in a lot of dependencies. That users can override the default means adding another work step for users, either a manual step that needs to be performed after a manual installation, or an automated step that needs to be integrated into users' deployment processes. - Is there a revocation mechanism by which we can mark "root" CAs as untrustworthy? If we don't have one, shouldn't we worry more about that given the widespread use of TLS? We have a big hammer, shipping a new ca-certificates package. If we want something that only affects apt, but not other packages, that mechanism doesn't exist yet. Do we have a revocation mechanism by which we can mark OpenPGP signing keys as untrustworthy (say for apt)? Yes, by shipping an update. - do we have a contingency plan if deb.debian.org hosting on Fastly is no longer feasible? As far as I know there is also at least https://cdn-aws.deb.debian.org/ if you don't like Fastly. It's not about what I like, but on what external services we want to depend. Simon OpenPGP_signature Description: OpenPGP digital signature
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 2, 2021 at 9:06 PM Ansgar wrote: > Accessing www.debian.org will also not work on such systems (and unlike > deb.d.o that does not even offer non-https). It's not Debian's problem. The Tor onion services offer alternatives to the https PKI: https://onion.debian.org/ > Is replacing deb.d.o by a non-CDN feasible? security.d.o mirrors were getting overwhelmed after Linux kernel updates, which is why that switched to the Fastly CDN, so probably not. Also, the entire point of the deb.d.o domain is that it be backed by a CDN. httpredir.d.o was an alternative CDN-like thing that was based on HTTP redirects to the mirror network. It had lots of problems, but now that we have a mirror checker and zzz-dists, perhaps it could work better. The mirror:// method in apt has probably improved since then too. Maybe http redirects to local mirrors could be feasible again, but it would take a lot of work. https://mirror-master.debian.org/status/mirror-hierarchy.html > As far as I know there is also at least https://cdn-aws.deb.debian.org/ > if you don't like Fastly. And there are other CDNs that could potentially be used. -- bye, pabs https://wiki.debian.org/PaulWise
