Accepted aria2 1.37.0+debian-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 10 Jun 2024 12:03:29 +0530 Source: aria2 Architecture: source Version: 1.37.0+debian-2 Distribution: unstable Urgency: low Maintainer: Patrick Ruckstuhl Changed-By: Kartik Mistry Closes: 1071833 Changes: aria2 (1.37.0+debian-2) unstable; urgency=low . [ Patrick Ruckstuhl ] * debian/control: + Drop libgcrypt build dependency (Closes: #1071833). + Change pkg-config -> pkgconf + Adjust to latest version . [ Kartik Mistry ] * Simplify debian/watch file. Checksums-Sha1: ba1309726630f5c0b398e610c3ccf3353b96b187 2177 aria2_1.37.0+debian-2.dsc a23a982dab313f777d06757a30eb1f99b9d966b9 6820 aria2_1.37.0+debian-2.debian.tar.xz Checksums-Sha256: 31c9cdde02056c3a6c878fa0584623652f36d28620070d378095980a8bd896df 2177 aria2_1.37.0+debian-2.dsc 9ac6466ea25a7e4eef67ef6254d77f7641363648919fb0678258647b8f9c6b13 6820 aria2_1.37.0+debian-2.debian.tar.xz Files: 36a4166b32799d516f6ee5509edfd0fa 2177 net optional aria2_1.37.0+debian-2.dsc a8371a6621be5b6c5ac326073ee15fba 6820 net optional aria2_1.37.0+debian-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEa2MbXvVUr2sRlmKSAsHT8ng6pN4FAmZmoqwACgkQAsHT8ng6 pN4DrQ/9Hv+mFlWEGCPmEwbL9N9Do/JF8NZXHqDzzcm0BdkgWJ1UuY/+WiXJd9vl ecu/ao02apvffSZtocII4gNeJL8wB14UNmohwKAbpwQ18kPBIxAlmt9SU9AnK+vs 6wX0lryyQaepweiPl4EdrO6XJWImAqF2PC/GrnrNw2Vg/0W32eY9aS3v8iMzLgLM p1y21fGAqiKQv1YOVEax8036ByIDM1tNh9FDF7mxhomZAoQdZZkkQS//TfsOkNr5 1Rp1vE1hepsxPTTuLcmGd6kh26NvKgKdb249I8/H6Ry95DJr19TQtihzx1AfY6tl q6dUPKlPejjJnw9mr1+EXKwJRl8EXal5lL4m4itsFyESFgJHtuWv8omB+cSEuhNw 5ege2Oge2WcQJepCPw5b71RoW1LKFhrr8yXSkc+/wrt0mISKFh6zFVt9zYqr/rnV r4EzlQU+nyVn2yjAhw7gmifWfGLL4kFyF/gOYaS01MlXOZ3B2Zg7t3mwskBid81V fEkkQvymQ5YZSZ7+E/+RO1aWUQBWaRUrBkMzG/qun3Eu2NZVXIoz8Z/Yq1vmoj3H NolGjBySkSfc1UhCS+3PUVPgFXvnQaRpmPEONP3DVVAO7PPh8Z2StGm+GAS4T1u1 ztOw8ybF4mQhozl0EB1wpCjuPfMg8EIfyW9r7JerXPf1uo5hFX4= =49T7 -END PGP SIGNATURE- pgpqeTBtBuqnv.pgp Description: PGP signature
Accepted debian-edu-fai 2024.06.07.1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 07 Jun 2024 11:08:04 +0200 Source: debian-edu-fai Architecture: source Version: 2024.06.07.1 Distribution: unstable Urgency: medium Maintainer: Debian Edu Developers Changed-By: Mike Gabriel Changes: debian-edu-fai (2024.06.07.1) unstable; urgency=medium . * bin/debian-edu-fai_updateconfigspace: + Fix is-inside-(Git-)work-tree check. Checksums-Sha1: 3cc85177ecb460f1100a04b828338b9b5a8ca34e 1730 debian-edu-fai_2024.06.07.1.dsc 805d55e46c587445f53a33de80dfbedf827846e0 76428 debian-edu-fai_2024.06.07.1.tar.xz 5ab57864ff5098233047aca9b3cd75b2c57b41d6 6587 debian-edu-fai_2024.06.07.1_source.buildinfo Checksums-Sha256: 4d1b6a865714806b799db638e1ffd90073e9505e298fcab103ddc5a10023a56d 1730 debian-edu-fai_2024.06.07.1.dsc d221ccd4c58ccf48724d2c723825340e5280daf34ce0a90da3ff2761631da872 76428 debian-edu-fai_2024.06.07.1.tar.xz 4c5cd5c5fe492d246d396261fbe13662b52b252f6187fbd00fa4cb66dd632a55 6587 debian-edu-fai_2024.06.07.1_source.buildinfo Files: 95096eced139189648e12fa1e8116757 1730 admin optional debian-edu-fai_2024.06.07.1.dsc 66a9f9106d1ad78530a0d154b4135554 76428 admin optional debian-edu-fai_2024.06.07.1.tar.xz 7de2a2d3f1ecdab28ea25bb12d361ba9 6587 admin optional debian-edu-fai_2024.06.07.1_source.buildinfo -BEGIN PGP SIGNATURE- iQJJBAEBCAAzFiEEm/uu6GwKpf+/IgeCmvRrMCV3GzEFAmZizj0VHHN1bndlYXZl ckBkZWJpYW4ub3JnAAoJEJr0azAldxsxhmgP/RJ+Dip5Rp1UxfM5LwHUlxaHo4AB Ei9secbHWmaMHhgCv2QUorH1Th5DezWa7qWSEtW437xPt8ZPTFGqBjxM/2PLMhiP uvcr7jTQKKBHKAW+3SxjvEDT+7LK1d83G+E/L3fSUVdn2A8GWdq4X+UVPVL4ZCRT HjXHEj+3+xFgjTqQAkPsu+TPsskBMuWHbUYH2D398JFvT1TN6KnUmNh2Ew6b12N/ Xmy1N47ziE0VOQP5TuSyeeY/wSZrOSYjsJb9vckL+Q6IOKy/3v7MTonpD3dM8WXQ VclsGe9m6Y5jPxN9Am7B9NuUk8FJif1RVwx4hglD7diGEJc/uo48P2NSmft9XhlC OfyAQyggnhVRYUJXDI/A0ekGiGEvaC+mfDoS9uNkXhq08M04VIn+aNXr/M0ulBw6 UbnWtzqH1tBILqYCmI0P+MoQ6xILM6O5zZr6L4THOxibeXgCiFWgEd3UpunROKOB 3yP7MfA5xL5UCkmsLQcL6MCjtPs8rF9Nr1aciKvuLxnUMbgS9ArhkPAWvtV/SZDE aHRgsaAu3Nvn6l2IDgDzdZRTBImjEAozGmbkINGYtgaBsqVhXfgu5d/ifOQqZyOR 3xWheQVUP2h5GqsOxYaIc0GlJHEuPNTjWUJkIBMPnirP/NT5OZH9n/sLUUvNON7F Mt2Skgs0ZzFdFScc =Gi0g -END PGP SIGNATURE- pgpXNYDagdPJn.pgp Description: PGP signature
Accepted rust-debian-watch 0.2.7-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 04 Jun 2024 20:55:18 +0100 Source: rust-debian-watch Architecture: source Version: 0.2.7-1 Distribution: unstable Urgency: medium Maintainer: Debian Rust Maintainers Changed-By: Jelmer Vernooij Changes: rust-debian-watch (0.2.7-1) unstable; urgency=medium . * Package debian-watch 0.2.7 from crates.io using debcargo 2.6.1 Checksums-Sha1: b655b3ab69548bd7572382937e24e22f0ea8ccd0 2108 rust-debian-watch_0.2.7-1.dsc a9812d1b0768fee2958e894f9361c42e8ef122b2 10200 rust-debian-watch_0.2.7.orig.tar.gz 4e5642d6ca528626117971aebe5d5fe9383cdb8c 1996 rust-debian-watch_0.2.7-1.debian.tar.xz 87d7405d9210d1e31c08298cf534b56e209def65 17478 rust-debian-watch_0.2.7-1_source.buildinfo Checksums-Sha256: bea90b7c819991a5e99ee54cfca7a45e495e0f8e0105d6499630addd94572088 2108 rust-debian-watch_0.2.7-1.dsc 506bd868882fe7b6d5dbaaeb001174aa01fb267563f019ceaa6f31a8b6e9639f 10200 rust-debian-watch_0.2.7.orig.tar.gz 74d963db8755f449cf51313e1bb0b0386fb26309a1476ae4c8f907f7d25f8054 1996 rust-debian-watch_0.2.7-1.debian.tar.xz 1bf25dbfb83fb7911e348bd14218fd41840c17d98209311d32fd1e13468bcea6 17478 rust-debian-watch_0.2.7-1_source.buildinfo Files: 8ad01e69ec9181da65bc103ec3399b1c 2108 rust optional rust-debian-watch_0.2.7-1.dsc a7b4d434eca26fe36deb2012970acc55 10200 rust optional rust-debian-watch_0.2.7.orig.tar.gz 62689b36b2ade7352f389b961c61bf01 1996 rust optional rust-debian-watch_0.2.7-1.debian.tar.xz a51890b9493d4f0d01ae50431ac686d8 17478 rust optional rust-debian-watch_0.2.7-1_source.buildinfo -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEgIoEfJX3ae+y722SMG8hYYBCUGYFAmZfcSoACgkQMG8hYYBC UGaAMAf/TfaDjPtKyfrhlYOEup6qCYJDV2iegxxHInT4zcOeQ1ppfYFOZNr/7ht+ +i1XG+UXpRToJOgBLu//QH38ylvbLz36n/rAC6dTqny5P8SHtWYa+5FdCxdGLRDU ehnkY8WXBZVfkeR2vGBeLRIebQrYmGKcl6gyj6XoUO1aSTaIEwVyHOA5zpWzqLcV xgK/Cvl6WKciLTKrJSZFf7t//u7QSsjfBNIYB0TnNaJHqiehBLgjfn9fa3empVFu P015yARXF9F0Q54kyGe/wPIyHCffpR/PGYd7ScSIj0L+YtQnTQXPQrtERvsH6pMY 4gJbIW3wYjoTzLGd5S3dZveDm8pCSQ== =WD6e -END PGP SIGNATURE- pgpreKp64z5xq.pgp Description: PGP signature
Accepted rust-debian-copyright 0.1.8-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 04 Jun 2024 20:47:10 +0100 Source: rust-debian-copyright Architecture: source Version: 0.1.8-2 Distribution: unstable Urgency: medium Maintainer: Debian Rust Maintainers Changed-By: Jelmer Vernooij Changes: rust-debian-copyright (0.1.8-2) unstable; urgency=medium . * Package debian-copyright 0.1.8 from crates.io using debcargo 2.6.1 Checksums-Sha1: a97f162b3e4648a8446387cf3169f2ecd9fe235c 2075 rust-debian-copyright_0.1.8-2.dsc 705fc713a66b3abfbe7f66d2f0b4900c4b1f6d12 2288 rust-debian-copyright_0.1.8-2.debian.tar.xz da54338325c3d996801c43464936399833bec5de 17256 rust-debian-copyright_0.1.8-2_source.buildinfo Checksums-Sha256: 893bec55f9384e31c35a6c2f3edccaef50d120042f8da90d7eea8114178ee759 2075 rust-debian-copyright_0.1.8-2.dsc b64047a50ffd9816d17ad85028129ee7a485a4f9858496befc3097a916daf49d 2288 rust-debian-copyright_0.1.8-2.debian.tar.xz c5c4d3991c13208f4fb3147d6e8a2ea77ad975abd394a08e99178979b98b03be 17256 rust-debian-copyright_0.1.8-2_source.buildinfo Files: 47056d958928c4c26f79894552ccf84f 2075 rust optional rust-debian-copyright_0.1.8-2.dsc e58c66076d766eeb62af64c1f33f5da4 2288 rust optional rust-debian-copyright_0.1.8-2.debian.tar.xz 850f37b595ec6451e558314c558ec4c9 17256 rust optional rust-debian-copyright_0.1.8-2_source.buildinfo -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEgIoEfJX3ae+y722SMG8hYYBCUGYFAmZfb0IACgkQMG8hYYBC UGanRQf7Bi8GG/tg7dXwhD9xlMDjlb3AuZLtsS6uRmGR+2FTMEH3aF37fu8z/s41 xqb5aNQGaQ2Gj/p68xDB9xhGFPwPqFz1fROzeJXJQbIBVNZlE3pUTKcy8Q0tr9X1 wcuAGkQdkoIJWi+N6tOej1zejt0d6DTfhBY4a1VdnWPziU/xG2RxQMv5xwhkHwMB z75mgyrnZcMJbtSTmIitQwFmmOGWQ0dNT/xQLAIXAFdMzKVpzRSlrr6Lf95jnTRk cG+wytVV89lZnIWgnqUhJgz/lbFF/ojq0WvCzJs9GG6ePaFgRq9Qx4vBhNBR1cub SaOh5YtLd+6MmdOtm0N/dZl/B5yLJg== =nPMO -END PGP SIGNATURE- pgpO4kZL_3F1y.pgp Description: PGP signature
Accepted rshim-user-space 2.0.31+debian-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 30 May 2024 15:25:20 +0200 Source: rshim-user-space Architecture: source Version: 2.0.31+debian-1 Distribution: unstable Urgency: medium Maintainer: da...@debian.org Changed-By: Taihsiang Ho (tai271828) Changes: rshim-user-space (2.0.31+debian-1) unstable; urgency=medium . * New upstream version 2.0.31+debian * debian/control: update Debian Policy version to 4.7.0 Checksums-Sha1: 01bbd7e1f2f813b227b30fbcf255fb3c17f8 2044 rshim-user-space_2.0.31+debian-1.dsc 568a6dca46440bb99d547b807fefee1941e39955 78680 rshim-user-space_2.0.31+debian.orig.tar.gz f53f3033d2b02ee6a05e7e28f4117300f5b5d034 2964 rshim-user-space_2.0.31+debian-1.debian.tar.xz 0a22610673cb5b09cd585f1c52dab0abbfb05b50 7434 rshim-user-space_2.0.31+debian-1_source.buildinfo Checksums-Sha256: 8a06c5e702da31634c85e866c1098e80c6b5c94317bbd3d17f5bd3494d15bd4e 2044 rshim-user-space_2.0.31+debian-1.dsc 1f3c1bac7987189f36bf917b23ca00d2ea133ebcf74ca04cc4806e1d94bdaa80 78680 rshim-user-space_2.0.31+debian.orig.tar.gz 73070d4178ca9145ae01b247739cf391b4878a56e42410ba3341f6d2ea4125b4 2964 rshim-user-space_2.0.31+debian-1.debian.tar.xz 52d334e402b64db49b1199af757a91c5af8cbb6498bd3986ed258f791de70385 7434 rshim-user-space_2.0.31+debian-1_source.buildinfo Files: 3059fe7b9d625b3948bcb4723f9ebcdc 2044 admin optional rshim-user-space_2.0.31+debian-1.dsc 9a28df34845576bb4e4f0c6fc880a92c 78680 admin optional rshim-user-space_2.0.31+debian.orig.tar.gz 5c5be4f25018e3087e5c1fb28a487689 2964 admin optional rshim-user-space_2.0.31+debian-1.debian.tar.xz 1037cfef0807ed473b7d2f539acb5116 7434 admin optional rshim-user-space_2.0.31+debian-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEECfR9vy0y7twkQ+vuG/g8XlT8hkAFAmZfRgYRHGRhbm5mQGRl Ymlhbi5vcmcACgkQG/g8XlT8hkBdag//fwo+RM5bixH3CF5X5PWtwL8+lHBwoeX1 ZmupRiwj6ewqtjFQLnka4t5B8lbOVcjVstSwKeNszZ/ZYitAaAlL5e8UDerGr8Mp K3HYA5lVevF0Uq2tvCpYlEYgK5Jo42uACKzB1oGDszu4yjTMdmJ2tmQzzAb6spmM xznO+AXEUpEw/Xl6u9is3fyqCB8lTUWWnJFPSGYLJa0cLeRkyRIo2ypKfFkqfUTf aDXMXu3iWoW2oJmcRDAptvgpoz5w5+rLHDJQKHdiS5iOQNGODyDZpzcbo+L8wb3I fRvXOqwKddOq1yL0X9y1QYQiHE/wCekvu4CpRgbz87dXkrcl49koprhNvYbapmpi 4BPyKT5BaT9u8CmpZe04ps+LoCIfk8jdgMXpgZygb06gTtcQyXt8uX4m9MjJHRuF kZlRUsM/0ZKI8QW6V+Wm92Y4jqf22dywPlROd7j6Nynevov0/bKtEN6TKxnmGnEl /ivFRYW98ZGrAnh7wCaGbxuM01bqeqCal/FWnVrEqe5oIWFk5CLdAdsmTRpZY3xm 5uhRScSMMmJvBdcdJXFDQtGb5RsxoM2Q3CMPMpsfPHgOaNbs0YFkxlG2NxVK6ydz 7Fv/2B6KI/DnfvkiZRBtLkuR1h8vZkvQzjjU9U21z6z5VwGtAD/74JQ0CIdQySev Q1pjU9A4Kc8= =jfuI -END PGP SIGNATURE- pgpwufVdf75JX.pgp Description: PGP signature
Accepted debian-installer-utils 1.149 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 03 Jun 2024 09:26:41 +0100 Source: debian-installer-utils Architecture: source Version: 1.149 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Colin Watson Changes: debian-installer-utils (1.149) unstable; urgency=medium . [ Colin Watson ] * user-params: Exclude initrd, since it's sometimes hard to avoid syslinux appending it after "---". . [ Luca Boccassi ] * chroot_setup.sh: Mount efivarfs in /target if available. Checksums-Sha1: af8d1d1e672c957235f5b09d7c0a1a3844f7ad9a 2285 debian-installer-utils_1.149.dsc ed4cb66247734feecc82693deea1c2113732d3fa 102916 debian-installer-utils_1.149.tar.xz Checksums-Sha256: ac1577c1f5188025e6afa31c7a32e6b1909f484695cc342b15367ad9cf01c159 2285 debian-installer-utils_1.149.dsc 400e37da530743340954f14b03bcb928ae44c4da19a4b34c8502ffd85a70e7ab 102916 debian-installer-utils_1.149.tar.xz Files: 9c1c17af1072882ae50b6706aeaf61ee 2285 debian-installer standard debian-installer-utils_1.149.dsc 5b8d9fcbff4c9819740cc3b52f78e3fd 102916 debian-installer standard debian-installer-utils_1.149.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAmZdf7oACgkQOTWH2X2G UAvi6hAAppE+D0OEb3AvO/i0qiPBGdo6uTw+7phw/yMnbGsexfRBN4/deGEkbVrX 6wYA6Bwp08p8/V6sSq+SiL8Nm+dUsj203TSMH1zxK6ZvtklgmyiMg0MUXf+24klE clX58oILC1TtLzTfDWMD7TdZOeiYhp/bv4JuQT2N7ENc+fZFJRM/xNWvO6hf/1q8 CF+NkFy8LJljJLV6bGxlki+ASj0YQ8h3dWBOlLl5cfH2mS9bzROwgLD3gCXHVGEm IZkSBfB/WFGEQasUuMUbaT63E/9G3eBMBP65NbjfIVOUkckDn+Tw3ZtHRBqJ8GTk TcdekbmOD3Wq3oPibRnVSJ5blMvo/3Cpu6wNvo9IIxkpVH8IIqytbJj+zrN0ryg4 VXijxiQALGaWGdTP838N5nVSzuF4wKvN6SL1Eu0TmsbnIrXZY2+wnwjJxmDh2URV ttaB0bUyd2cYHyyrFm/Hds+zr/pkXnsSymJ0597D8OVTLjH9VrKbtPN7/zv7t/Y7 AY+G/az28MsFgp7UeGXTM7R9DThUil7Ell1IFLFw/PE3mjKEXGGZL377kwhjKz6M BuryfMYTAi6zGPU/ig53AklGuKGv+4F280RNdzphTFNbNiesfzlysGFy8KteOuXv OeFTjVqoW71mo5itNegHGGp6kqbwwc6uNt3ukk80fc+V+CZiKLo= =/CGG -END PGP SIGNATURE- pgp201vgnwVRz.pgp Description: PGP signature
Bug#1072313: ITP: debpic -- Build Debian packages in a docker container
Package: wnpp Severity: wishlist Owner: Aidan Gallagher X-Debbugs-Cc: debian-devel@lists.debian.org, aidg...@gmail.com * Package name: debpic Version : 1.0.0 Upstream Author : Aidan Gallagher * URL : https://github.com/aidan-gallagher/debpic * License : LGPL Programming Lang: Python Description : Build Debian packages in a docker container Debpic allows developers to build Debian package in an isolated environment. Invoke debpic in a repository without any arguments to simply build packages. The environment is composed from: * The Debian stable docker image. * Build dependencies described in the ./debian/control file. * Any additional developer tools described in ./developer-packages.txt. * Any packages defined in the --extra-pkg flag. I previously opened an ITP for this package under its previous name "dpkg-buildenv". After some feedback I have since renamed it. I was informed on https://mentors.debian.net/package/debpic/ that I should recreate an ITP using the new name.
Accepted debian-el 37.12 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 19 May 2024 02:44:17 -0700 Source: debian-el Built-For-Profiles: noudeb Architecture: source Version: 37.12 Distribution: unstable Urgency: medium Maintainer: Debian Emacsen team Changed-By: Xiyue Deng Closes: 1032662 1067902 1067922 1069908 Changes: debian-el (37.12) unstable; urgency=medium . * Bring back debian-autoloads.el (Closes: #1067902) * Fix comp warnings in debian-bug.el (Closes: #1067922) * Update distribution code names to recent releases * Append non-free-firmware to non-free when handling components * Move package info above copyright notice following existing practices * Bump package version to prepare for release * Make ITP/RFP template more aligned with reportbug - Move `Severity' above `Owner' in headers - Add `Programming lang' after `License' in email template * Update Standards-Version to 4.7.0; no change needed * Fix duplicates and broken entries in X-Debbugs-Cc (Closes: #1069908) - Stop passing "--list-cc=none" to reportbug - Unset $HOME to prevent reportbug from loading ~/.reportbugrc * Add zstd to depends of elpa-debian-el in debian/control * Add deb-view support for zstd compressed deb files (Closes: #1032662) Checksums-Sha1: e052ac7073014052d97c4d6d2e2998105b416dec 1718 debian-el_37.12.dsc 5ffb1813aafab9800756bf7151147aa4b2ee2124 56748 debian-el_37.12.tar.xz 5577dc7867d22b3e7c60ff0a11c85f34250a98b4 10276 debian-el_37.12_source.buildinfo Checksums-Sha256: bdfde1b28d6aaca4e5ba7a3ca3d64b725f83c9b94fca82a401297eee89956fd0 1718 debian-el_37.12.dsc bd06bacad51a0b8c1874340fa76708cc70d9fb8c294d44eeda7118221df3a8d5 56748 debian-el_37.12.tar.xz 733353eee970667f59b13c7fdf8439de758e4a4bbe6b7ab0127a8ae8e84a75c9 10276 debian-el_37.12_source.buildinfo Files: 21c578c15b1bbc92c2f16a2a93aafca9 1718 lisp optional debian-el_37.12.dsc f0f0d9581ead0cf93ff40abb76aa4dd0 56748 lisp optional debian-el_37.12.tar.xz 14f5d982a59e260e18ece0e55d59b0d2 10276 lisp optional debian-el_37.12_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAmZW1g8ACgkQ808JdE6f XdlUQg//aC9VobUyTishby8cefP2dEpnDW56+CQgD/tXpCyjC3QRq6YGF8E30krf NCV5XLmv8tmN9m5hFbFR4FDPpUttCY6sdsTEZSTlkGtcthRHUIDzO/uuc3VuhU2E 6glDahQCN1jv5oTd0RrEsuMjvSkjKIUX7KuerhYriD99bebBFQrNk21xQ/ZyV7IS QRqB9wCzMoh+9bGdVAj1bfey7BAMP3js1qvBv2IEFZkXRjXheoX+B+T8hDcV2uBo fnHvjibOQFBJ45lDU5SJ+0I0YnVKsbs+wa2wk9bvLDmbO7/tTwGPM/y1Dnw9Jodi GT8zn8BPgRJ2KmUPJrqZHb16pm/qYcauB+mL+mnA/A1n68qVAXWa605wUc5WOfXI mao2Zsut6jMmAWxFxhus6XBESax0JBPYRi4PcLd0607qH1xIify3xwfWLUgkj+Nq jGKydUmZs2PKgpnV3284ZPkXKr0e7HFsNl/cqzAc2RDv4f/o9seiGfHWUDNnmEpV c+l0P9BeTVhVMfXp5+fh3D0oLLqfuvH63+gJBK+WV103CKuedUmUqmYgQREUNGz2 wikze1oRjFUuObg+mOyJ5Y/9vNwYE+Fsxa/aVghvbuMAQ8y7/DmypZMX3i7bmG/W hnuj67vq7ZF4595EdVD/5f2j1urRKmzCWQIpn7lyHqNBhDP5lJY= =2AYL -END PGP SIGNATURE- pgpNwtYLREjm9.pgp Description: PGP signature
Accepted debian-reference 2.123 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 28 May 2024 16:11:38 +0900 Source: debian-reference Architecture: source Version: 2.123 Distribution: unstable Urgency: medium Maintainer: Osamu Aoki Changed-By: Osamu Aoki Changes: debian-reference (2.123) unstable; urgency=medium . [ Andika Triwidada ] * Translated using Weblate (Indonesian) . [ eulalio ] * Translated using Weblate (Spanish) . [ houzhou-wu ] * Translated using Weblate (Chinese (Simplified)) . [ Osamu Aoki ] * Update Makefile to not current status. * Trivial update of fi and ko removing junks. Checksums-Sha1: 94a6e422b774779a02310455522e87576ee9ed98 3067 debian-reference_2.123.dsc 678b17d631b0bb880a0ba0c92fbd9bdf81e3623b 2198892 debian-reference_2.123.tar.xz Checksums-Sha256: 7db3f756bb2c3a504210ab50c15cdd3cbaca62af53707b1df6134d95e0324caa 3067 debian-reference_2.123.dsc 1ad2451b992e51064194d31991127f0f3247298e3eb80ca93807e88c447c7b4e 2198892 debian-reference_2.123.tar.xz Files: 978080324b12caa335999f922aa5a17a 3067 doc optional debian-reference_2.123.dsc d37f897067ff59a0ec3c034b77f5a53e 2198892 doc optional debian-reference_2.123.tar.xz -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEMTNyTWIHiBV56V1iHhNWiB3Y15EFAmZVih8RHG9zYW11QGRl Ymlhbi5vcmcACgkQHhNWiB3Y15GVlBAAqU4U9EfIDBvlU+WVhvlmxupR59VW2fvB a17V5ebhnGyMwueIzWbv5IjpHQMRFESSkKQwrsfmHiD9c1EqGqHHFALYjmKC4cH/ aUKiu8F+YtbBmnWn+/61OJWeGfymCvEtpUiC+TI+iy8Z8eEasoPjO/w521ntdtzi ipP+v9yUX8CU/wD1ssfd5nXD54D5eklhNhqXBFJC2Psgx23CN++wvnZy52PzkMPy VE4xrXq4OuTK/Y4Lz7jgn13FlGIwT93pjOgIbQ1wAw40wU7dUxHf190btliKJTT/ t2+Q81ob8iRnI2C1j9ug2eYQLdesf4zqf/5UbuFR4WOl0VdDM3jOhvu6zivqIOkU hmafeJbb/UQ5OYTKjwuFLGrF5uKsadRQpxe/8Xg12Hx0ooiC2zRQzaMhQ3AUsPxW 9BvqmfWb9bLjFBdEg+ZFmpu10TtRBeenijTm4uBGDcexPH/thPnTdSzxzoUv4WAR 2DSDLZVbe+ERUallA+q+oQ3kJAre9CurH+/MjHS7reVhvD5oTRSpwVKP51XhhOvV llk7lzy92TUMHIMDf81qBJ7laoGe5Ql+jvShFT4/8XgjBINyRyAYRTC/Oc9anaxn HmhEnyfHH7nZ6D6GApj14q/R5ooOHWKDZZlA1yX80LaQXrtzZhKAnNfzHp5ckAD0 tE2XX9GgkdQ= =A8h7 -END PGP SIGNATURE- pgpHrIbHRDUUR.pgp Description: PGP signature
Re: Debian 10 "buster" moved to archive.debian.org
Hi, On Fri, May 24, 2024 at 10:28 PM Otto Kekäläinen wrote: > > Hi! > > So just to clarify, are you saying that a copy of > https://security.debian.org/debian-security/dists/buster/ will never > be archived at https://archive.debian.org/debian-security/dists/ like > previous releases have been so far? > > This is not about getting *new security updates*, but purely a > question of how moving Buster to archival works and how e.g. CI > systems that test upgrades from Buster should work. > > I see that e.g. > https://deb.debian.org/debian/dists/buster/main/binary-armel and > https://deb.debian.org/debian/dists/buster-updates/main/binary-armel > no longer exists, but have been archived at > https://archive.debian.org/debian/dists/buster/main/binary-armel/ and > https://archive.debian.org/debian/dists/buster-updates/main/binary-armel/. > > The > https://security.debian.org/debian-security/dists/buster/updates/main/binary-armel > is now gone, is the intent for it to show up on archive.debian.org in > some form? True, you're right, the buster is missing from https://archive.debian.org/debian-security/dists/ and I'm waiting for a response from the people who take care of this repository about this. I think they forgot to migrate. -- Cheers, Leandro Cunha
Accepted puppet-module-debian-archvsync 1.0.1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 27 May 2024 10:33:42 +0200 Source: puppet-module-debian-archvsync Architecture: source Version: 1.0.1-1 Distribution: unstable Urgency: medium Maintainer: Debian OpenStack Changed-By: Thomas Goirand Changes: puppet-module-debian-archvsync (1.0.1-1) unstable; urgency=medium . * New upstream release: - fix default rsync URL for archive.debian.org. Checksums-Sha1: e7a7bbedc13a89fe75cf9e2759f5c405ca3d5b67 2263 puppet-module-debian-archvsync_1.0.1-1.dsc ded7242b3bdc006909448ec190b18510df60246e 8516 puppet-module-debian-archvsync_1.0.1.orig.tar.xz 507c2a5cb4278b7fa9e09d22df66115dd2eaa534 2544 puppet-module-debian-archvsync_1.0.1-1.debian.tar.xz 7e6f25a48e5ffe3dfa5fa843610f53105aa72b29 7183 puppet-module-debian-archvsync_1.0.1-1_amd64.buildinfo Checksums-Sha256: bb4e2dbca4d1fdb642ab14173b885f52de146ea65d30a31cbb3bd61e8a56196b 2263 puppet-module-debian-archvsync_1.0.1-1.dsc 174f70b2b718348e851a06f5651b2fe81f492e7a5475edacda84535dd65af09e 8516 puppet-module-debian-archvsync_1.0.1.orig.tar.xz 1e23f4345a12356fb6088b0de4134bd9e9c67bf771bc50045cbfffb9080ec18e 2544 puppet-module-debian-archvsync_1.0.1-1.debian.tar.xz 9ae1dbdf7a58a78bc2ce4b2c923f871ed7573c67678aad51996b75c2e8055a99 7183 puppet-module-debian-archvsync_1.0.1-1_amd64.buildinfo Files: 00304a0fb84f2c377437b7d47a0353b3 2263 admin optional puppet-module-debian-archvsync_1.0.1-1.dsc ff1e0b9a8d9461da8418a82bb5818d79 8516 admin optional puppet-module-debian-archvsync_1.0.1.orig.tar.xz 3dddfadcdab413ecfc30ec6f6f292685 2544 admin optional puppet-module-debian-archvsync_1.0.1-1.debian.tar.xz 9d31a7ee7ae520ac9cacc85c2b608701 7183 admin optional puppet-module-debian-archvsync_1.0.1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEoLGp81CJVhMOekJc1BatFaxrQ/4FAmZURdEACgkQ1BatFaxr Q/5vUw//cLwqjiiPKIEVywQcuz4KyC9FvIsNwsd2CiyHCHzyoT9wqAmnTDqFWr9K HRRkJQzFfdst2Y018ryMHlVOy30QFQvyZwiGQolKx0jy/c/pkWY6LWhLhspEfqIL +ydGBPbfiPRB54rkEprdJ64dG+agmHm7jdDymU4ifdLpqQcU6wjZbRI01r17048i kfFEmCz5+qEzwUFf6kv1N+pjTvg7kFADqHTy5gydGZzMEFySHeRpWjE/B5pFSgGm 6Qb9xmfSOFMUJHyOpbqzajXGjzJS6qwica1tB5OoWyiROXyhSSrga8O0lH7zQ+vE Id47Ldy6UBYmwCr30RoCjwEU9M0/SrrXJ6jsoXFngyaCHOgQKBjc3S5CBUWNab6V lQFkF25T52vIkHxj7gMAd8V1qMyizNJa0eaIPYUXdVtm+4DLaOQAa6pl/UhOyFi3 r0YtDdf7u/iXgpq1XHf2g5S6tfk5ygEOPqcMTYqKAE+uocInD19wZPQaPTVt/PeU T+xm5f3RG0mCPIT8KkxTh2b5/6FtIjxmhExXi2McU0D6dNxqYqBGkIymUfXTLHVT 9XeJ6iJsp6B5i76x5gG3xC46J92MxYrkF3QDMZxnSQ5Di98X+1DU00f/b0N/VdPB Y1ZLWkOdw6fc/kyWnsRDG4PhuIj/rztl8FkQQfUbdaE+tV5s7mM= =4han -END PGP SIGNATURE- pgpcYCeAb92T9.pgp Description: PGP signature
Re: Debian 10 "buster" moved to archive.debian.org
Hi! So just to clarify, are you saying that a copy of https://security.debian.org/debian-security/dists/buster/ will never be archived at https://archive.debian.org/debian-security/dists/ like previous releases have been so far? This is not about getting *new security updates*, but purely a question of how moving Buster to archival works and how e.g. CI systems that test upgrades from Buster should work. I see that e.g. https://deb.debian.org/debian/dists/buster/main/binary-armel and https://deb.debian.org/debian/dists/buster-updates/main/binary-armel no longer exists, but have been archived at https://archive.debian.org/debian/dists/buster/main/binary-armel/ and https://archive.debian.org/debian/dists/buster-updates/main/binary-armel/. The https://security.debian.org/debian-security/dists/buster/updates/main/binary-armel is now gone, is the intent for it to show up on archive.debian.org in some form?
Re: changing existing entries in debian/changelog
Quoting Bill Allombert (2024-05-24 10:54:32) > Le Fri, May 24, 2024 at 09:30:44AM +0200, Bastian Venthur a écrit : > > Hi, > > > > I'm having troubles finding the relevant parts in the developers reference. > > I've uploaded a version to experimental and later found out that this > > version fixes several bugs. > > > > Can I rewrite existing changelog entries for already uploaded versions with > > the next upload, i.e. by adding the relevant "closes" line to the previsions > > version? > > You need to use the option -v of dpkg-genchanges so that the relevant > bugs are listed in the .changes file, so that they get automatically closed. But then they get closed by the wrong version, no? Dev-ref says: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-bugs-are-closed-by-new-uploads > To close any remaining bugs that were fixed by your upload, email the > .changes file to xxx-d...@bugs.debian.org, where XXX is the bug number, and > put Version: YYY and an empty line as the first two lines of the body of the > email, where YYY is the first version where the bug has been fixed. When I don't have the .changes file anymore, I just mail xxx-d...@bugs.debian.org with a mail that has the "Version: YYY" line at the top and then in the body explains that I'm manually closing it because I made a mistake. Thanks! cheers, josch signature.asc Description: signature
Re: changing existing entries in debian/changelog
Le Fri, May 24, 2024 at 09:30:44AM +0200, Bastian Venthur a écrit : > Hi, > > I'm having troubles finding the relevant parts in the developers reference. > I've uploaded a version to experimental and later found out that this > version fixes several bugs. > > Can I rewrite existing changelog entries for already uploaded versions with > the next upload, i.e. by adding the relevant "closes" line to the previsions > version? You need to use the option -v of dpkg-genchanges so that the relevant bugs are listed in the .changes file, so that they get automatically closed. Cheers, -- Bill. Imagine a large red swirl here.
Re: changing existing entries in debian/changelog
Quoting Andrey Rakhmatullin (2024-05-24 09:37:45) > On Fri, May 24, 2024 at 09:30:44AM +0200, Bastian Venthur wrote: > > I'm having troubles finding the relevant parts in the developers reference. > > I've uploaded a version to experimental and later found out that this > > version fixes several bugs. > > > > Can I rewrite existing changelog entries for already uploaded versions with > > the next upload, i.e. by adding the relevant "closes" line to the previsions > > version? > You can if you want but it won't close the bugs, you'll still need to > close them properly with manual action. SO it may be easier to just not edit > them. When I forget to add the "closes:" line to d/changelog, I will add it retroactively (after having closed the bugs with the correct version manually) because it allows others as well as future-me to look up in d/changelog to which changes correspond to which bugs and bugs will have much more context for a problem than a line in d/changelog. Thanks! cheers, josch signature.asc Description: signature
Re: changing existing entries in debian/changelog
On Fri, May 24, 2024 at 09:30:44AM +0200, Bastian Venthur wrote: > I'm having troubles finding the relevant parts in the developers reference. > I've uploaded a version to experimental and later found out that this > version fixes several bugs. > > Can I rewrite existing changelog entries for already uploaded versions with > the next upload, i.e. by adding the relevant "closes" line to the previsions > version? You can if you want but it won't close the bugs, you'll still need to close them properly with manual action. SO it may be easier to just not edit them. -- WBR, wRAR signature.asc Description: PGP signature
changing existing entries in debian/changelog
Hi, I'm having troubles finding the relevant parts in the developers reference. I've uploaded a version to experimental and later found out that this version fixes several bugs. Can I rewrite existing changelog entries for already uploaded versions with the next upload, i.e. by adding the relevant "closes" line to the previsions version? Cheers, Bastian -- Dr. Bastian Venthur https://venthur.de Debian Developer venthur at debian org
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi On 21-05-2024 1:08 p.m., Sean Whitton wrote: PS: I've always wondered if the dgit server shouldn't track history, even if uploads don't happen via it. A dgit clone could (should?) already provide available history, even if no upload happened via it yet. Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's history. So it sort of does this. We could make it do more. Huh. Than my workflow hides this. All I'm often seeing is just the tar content represented in a commit, the latest Debian packing in another and the merge of these two (if I recall and describe what I recall correctly). I always thought that dgit clone generated that on my computer if there was no git content on the dgit server. I'll try to remember this next time I run my no-changes-source-only upload script. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
On Tue, 2024-05-21 at 09:11 -0600, Sam Hartman wrote: > > > > > > "Otto" == Otto Kekäläinen writes: > Otto> Would you be kind and try to understand the opposing > viewpoint > Otto> by trying it for one day? > > Otto> You could go to > Otto> > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 > Otto> and conduct a code review? > > I have not done a code review of that particular patch on salsa. > I have done code reviews on salsa, many other gitlabs, and github. > I find doing a code review in a web page far more frustrating than in > email. There are external paid integrations for gitlab which provide the feature to send emails with full diffs for projects, so there should be a way to add this feature to the Debian gitlab. I would guess by using the API. You can comment on merge requests by email already and you should even be able to create a new one by mail (that feature exists in gitlab, no idea if its enabled on salsa and I've never tried it anywhere else). So I think if this is a feature more people are missing, find them and spend some time together on creating an external service for salsa that provides it would be well spent time. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi! On Sun, 19 May 2024 at 20:48, Don Armstrong wrote: > > On Sun, 19 May 2024, Bill Allombert wrote: > > Also debbugs is a special case: > > The debbugs Debian package (as opposed to the debbugs software) have never > > been > > really maintained. I am actually one of the very few users of this package > > and I tried several times to get the maintainers to do a new upload but they > > were clearly not interested. > > It's more that I'm prioritizing spending my (very) limited Debian time > on keeping bugs.debian.org and debbugs itself working (and [very slowly] > developing a new version of Debbugs with a more modern design in the > hopes that others will contribute.) Everyone else has very limited time to contribute to Debian as well. Therefore we all need to think about what is the most efficient workflow. Perhaps you could consider how you can be a force multiplier and scale your work? You could for example add some of the recent contributors as developers or maintainers at https://salsa.debian.org/groups/debbugs-team/-/group_members so they can review/merge/push code, and you could review all submissions at https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests and grow those contributors into co-maintainers instead of just ignoring them? Perhaps you can also consider optimizing your git workflows? For example in the case of https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 you could have simply pressed "Merge" and everything would be good. Now you decided to not use any of the support Salsa/Salsa-CI provides, you did extra work to cherry-pick some commits (but not all), added your extra commit to break the build and now there is new follow-up work to be done for lapses that could have been easily avoided if Salsa-CI was enabled.. (I did submit MR!20 though, you can just merge it) I started this thread "Salsa - best thing in Debian in recent years?" by asking people who resist Salsa to at least try using it for a while before criticizing it so much. What happened in this episode is a case in point. You sit in a "local optima" of your current workflow and are not willing to invest a bit extra effort to get to a place where Salsa+Salsa-CI can benefit and decrease your extra work burden. Now both you and me ended up having to do extra work that could easily have been avoided.. Personally I like Salsa a lot, and collaboration with maintainers who embrace Salsa is a breeze, and I feel that my limited Debian time is relatively productive. That is all thanks to Salsa. I wish those who are not yet using it would give it a sincere try.
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
>>>>> "Otto" == Otto Kekäläinen writes: Otto> Would you be kind and try to understand the opposing viewpoint Otto> by trying it for one day? Otto> You could go to Otto> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 Otto> and conduct a code review? I have not done a code review of that particular patch on salsa. I have done code reviews on salsa, many other gitlabs, and github. I find doing a code review in a web page far more frustrating than in email. I appreciate other people have different experience. Some of my experience but not all is accessibility related. I do find that trying to put everyone into one user interface--whether it is github or gitlab or whatever--means some people are going to be left out. Interfaces like email mean that people can develop their own tooling. And for those who do and find tooling they really like that's superior to a common UI like gitlab for *those people*. But it's going to be inferior for people who do not spend significant time on tooling; for those people a common web ui is going to be superior. And you can say that I can use my own tooling with gitlab. That's sort of true. But then you or people like you will get frustrated that I don't interact with your per-commit-line comments entered in the website, or go to the website to resolve comments or whatever. And you'll say that if I just tried the website I'd like it. And that won't be true, because I have, I do use it in my day job, and I don't really like it that much. Even so, I think it is enough better that Debian should move in that direction. But Otto, I would encourage you to have more compassion for people who work with the world differently than you. In this thread, and in the krb5 merge request we are discussing, you really do seem to be jumping to an assumption that everyone approaches code the same way. And you don't appear to be taking the time to understand or value how the people you are interacting with may deal with the world differently. Rather than simply asking people to try out your way, I'd encourage you to ask me and others how they deal with code and what they like about their work flow. I'm not going to ask you to try it out, because it probably won't work for you. You've found something you think is great. But I am going to ask you to ask and listen. I do think we should fall in on the salsa way. I think it will generally be better overall. I do think some of us will suffer as a result. But there appears to be an assumption here that if we just all tried this new thing it would be great. I would appreciate compassion for our differences and for how that's just not true. There will be trade offs. --Sam
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
On Tue, 21 May 2024 at 14:13, Andrey Rakhmatullin wrote: > > On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote: > > Hi, > > > > On 5/21/24 15:54, Andrey Rakhmatullin wrote: > > > > > > The Debian archive itself is a VCS, so git-maintained packaging is also > > > > a > > > > duplication, and keeping the official VCS and git synchronized is > > > > causing > > > > additional work for developers, which is why people are opposed to > > > > having it > > > > mandated. > > > > > The Debian archive itself is a *bad* and *poor* VCS. It should be obvious > > > in which areas it's poor, and it's bad e.g. because force pushes are > > > enabled, the history is periodically truncated (though there is no easy > > > way to get it anyway) etc. > > > > All of these things are *also* explicit features. We need a way to unpublish > > things, and mirrors only want to keep a shallow subset. > We don't have a way to unpublish things, and force pushes I meant are > uploading things without including all previous changes, like all those > NMUs silently not included in the next maintainer uploads. > But, sure, some of the problems we have are explicitly features. > > > Representing the Debian archive in git would probably look like a massive > > amount of submodules, because that's the only way to represent state across > > multiple projects without extending it > Sorry? I don't understand what you would use submodules for. Unless you > meant literally mapping archive-as-VCS to a single literal VCS repo? Yeah, I don't understand that either. It seems there is some misunderstanding, the suggestion to use Salsa doesn't mean that the current ftp servers are retired. It just means that Salsa is used for sources, like it is already used in ~90% of the packages today as per trends.debian.net. Now, whether someone wants to make tarballs and ftp uploads happen transparently behind the curtain in a salsa-ci job or something like that is really orthogonal to the idea that sources need to be stored in git.
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote: > The Debian archive itself is a VCS, so git-maintained packaging is also a > duplication, and keeping the official VCS and git synchronized is causing > additional work for developers, which is why people are opposed to having it > mandated. I don't follow this conclusion because the premise "the Debian archive itself is a VCS" is as right or wrong as the statements "earth is clock" or an "ocean is a washing machine". Or, to put it differently, "vi $file ; cp $file $file.bak ; vi $file" is also a VCS, but an even poorer one than the Debian archive. Just because something has some VCS like properties it doesn't make it a VCS as in the sense as people understand it in 2024. IMO (very few) people object using a(n official) VCS is because it would change their workflows and/or because they believe their needs are more important than our needs. And saying "the Debian archive is a VCS and that causes conflicts with another VCS" is a red herring at best, because as dak+git or dak+vim+copy shows (or gosh, using different git repos) that using several VCS is possible and done by millions daily. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ It's not climate change nor climate crisis, it's climate disaster. signature.asc Description: PGP signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote: > Hi, > > On 5/21/24 15:54, Andrey Rakhmatullin wrote: > > > > The Debian archive itself is a VCS, so git-maintained packaging is also a > > > duplication, and keeping the official VCS and git synchronized is causing > > > additional work for developers, which is why people are opposed to having > > > it > > > mandated. > > > The Debian archive itself is a *bad* and *poor* VCS. It should be obvious > > in which areas it's poor, and it's bad e.g. because force pushes are > > enabled, the history is periodically truncated (though there is no easy > > way to get it anyway) etc. > > All of these things are *also* explicit features. We need a way to unpublish > things, and mirrors only want to keep a shallow subset. We don't have a way to unpublish things, and force pushes I meant are uploading things without including all previous changes, like all those NMUs silently not included in the next maintainer uploads. But, sure, some of the problems we have are explicitly features. > Representing the Debian archive in git would probably look like a massive > amount of submodules, because that's the only way to represent state across > multiple projects without extending it Sorry? I don't understand what you would use submodules for. Unless you meant literally mapping archive-as-VCS to a single literal VCS repo? -- WBR, wRAR signature.asc Description: PGP signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi, On 5/21/24 15:54, Andrey Rakhmatullin wrote: The Debian archive itself is a VCS, so git-maintained packaging is also a duplication, and keeping the official VCS and git synchronized is causing additional work for developers, which is why people are opposed to having it mandated. The Debian archive itself is a *bad* and *poor* VCS. It should be obvious in which areas it's poor, and it's bad e.g. because force pushes are enabled, the history is periodically truncated (though there is no easy way to get it anyway) etc. All of these things are *also* explicit features. We need a way to unpublish things, and mirrors only want to keep a shallow subset. Representing the Debian archive in git would probably look like a massive amount of submodules, because that's the only way to represent state across multiple projects without extending it -- and extending is a big no-no, because then we'd lose all the forge support. Submodules cannot represent the pristine-tar branch though. It makes sense that some people want to replace it with a good VCS, but I agree that adding a good VCS only gives us two VCSes because replacing will never happen. There are two axes here -- "good" and "fits the use case." What I'm arguing is that git does not fit our use case, despite being good, because it is designed for something else. We can make it fit our use case by wrapping it, but then we have a choice between a thin veneer that breaks easily as people use git commands inside a source tree, when they should only be using gbp commands, or a completely opaque wrapper that loses us all the git integration from third-party tools like forges. Because git treats packaging metadata as data, no correctness of metadata is enforced at this level. We could add this in the form of upload hooks, but then people would start complaining that they want to use the tools like they want. They would be wrong, but that is what happens with leaky abstractions. This is the exact opposite of the mandatory-debhelper debate: requiring declarative packaging (and therefore calcifying all custom sequences into debhelper plugins) is precisely the opposite of "using git because it is familiar" -- the benefit of using the abstraction comes from denying access to the layer below and therefore hiding its complexity. Simon
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hello, On Sun 19 May 2024 at 10:05am +02, Paul Gevers wrote: > > PS: I've always wondered if the dgit server shouldn't track history, even if > uploads don't happen via it. A dgit clone could (should?) already provide > available history, even if no upload happened via it yet. Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's history. So it sort of does this. We could make it do more. -- Sean Whitton signature.asc Description: PGP signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hello, On Sun 19 May 2024 at 12:32pm -07, Otto Kekäläinen wrote: > You could go to > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and > conduct a code review? > > You might discover that GitLab is useful and is not duplicating > Debbugs or anything else in Debian - it is currently the only platform > to conduct code reviews on in a way that has automatic testing and > comment-response-resolved -tracking. Doing code reviews patches > attached in email does not have that. > > If you try it out, and still think Salsa is bad for Debian, then I am > more willing to accept your stanze. I have tried it out, and am happy for those maintainers that like it to use it, but I do not want to maintain most of my packages that way. I want people to send me patches to the BTS / project ML. -- Sean Whitton signature.asc Description: PGP signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote: > > My concern about Gitlab is not its *additions* to existing services, but > > its *duplications* of core services already in Debian. > > I agree, that's the key problem. > > The Debian archive itself is a VCS, so git-maintained packaging is also a > duplication, and keeping the official VCS and git synchronized is causing > additional work for developers, which is why people are opposed to having it > mandated. The Debian archive itself is a *bad* and *poor* VCS. It should be obvious in which areas it's poor, and it's bad e.g. because force pushes are enabled, the history is periodically truncated (though there is no easy way to get it anyway) etc. It makes sense that some people want to replace it with a good VCS, but I agree that adding a good VCS only gives us two VCSes because replacing will never happen. -- WBR, wRAR signature.asc Description: PGP signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
On Sun, May 19, 2024 at 08:38:58PM -0700, Don Armstrong wrote: > On Sun, 19 May 2024, Bill Allombert wrote: > > Also debbugs is a special case: > > The debbugs Debian package (as opposed to the debbugs software) have never > > been > > really maintained. I am actually one of the very few users of this package > > and I tried several times to get the maintainers to do a new upload but they > > were clearly not interested. > > It's more that I'm prioritizing spending my (very) limited Debian time > on keeping bugs.debian.org and debbugs itself working (and [very slowly] > developing a new version of Debbugs with a more modern design in the > hopes that others will contribute.) > > > Ideally debbugs should be made non-native so that some else could > > maintain the Debian package. > > I'm happy to review patches that get the 2.6 branch of debbugs in shape > where it can be released into Debian again if someone wants to take that > effort. But precisely, one should not need to wait for a new 'upstream release' to fix RC bugs that prevent the package to be part of a stable release. Making it non native would allow that without requiring more of your time. > I've just assumed that anyone using that package was running > unstable or running debbugs out of git. Perforce, since the package has not been in stable or testing for years. Cheers, -- Bill. Imagine a large red swirl here.
gzip --rsyncable (was: Re: De-vendoring gnulib in Debian packages)
"Theodore Ts'o" writes: > On Sun, May 12, 2024 at 04:27:06PM +0200, Simon Josefsson wrote: >> Going into detail, you use 'gzip -9n' but I use git-archive defaults >> which is the same as -n aka --no-name. I agree adding -9 aka --best is >> an improvement. Gnulib's maint.mk also add --rsyncable, would you agree >> that this is also an improvement? > > I'm not convinced --rsyncable is an improvement. It makes the > compressed object slightly larger, and in exchange, if the compressed > object changes slightly, it's possible that when you rsync the changed > file, it might be more efficient. But in the case of PGP signed > release tarballs, the file is constant; it's never going to change, > and even if there are slight changes between say, e2fsprogs v1.47.0 > and e2fsprogs v1.47.1, in practice, this is not something --rsyncable > can take advantage of, unless you manually copy > e2fsprogs-v1.47.0.tar.gz to e2fsprogs-v1.47.1.tar.bz, and then rsync > e2fsprogs-v1.471.tar.g and I don't think anyone is doing this, > either automatically or manually. > > That being said, --rsyncable is mostly harmless, so I don't have > strong feelings about changing it to add or remove in someone's > release workflow. Your example had me convinced, and I thought some more about why we really should keep using it as it consumes a small percentage more CPU and disk space. I have realized that another common operation is storing and transfering _several_ different releases of e2fsprogs. I would suspect that most releases of software is fairly similar to the previous release when uncompressed. With gzip --rsyncable, the tarballs should then be mostly similar. Without --rsyncable, they will largely be different if I understand correctly. This affects dedup-able storage and transfer methods, and some anecdotical evidence suggests this improvement is significant - going from 215GB to 176GB vs 13GB: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/429 Maybe someone could do some experiment to see if there is substance to this argument, its not clear to me that the example is comparable. Storing/transferring several releases for the same software could add significant savings for larger set of archives. As the downside seems fairly small, and the potential upside may be significant, I will use and recommend --rsyncable for git-archive release tarballs: git archive --format=tar --prefix=$PACKAGE-$VERSION/ HEAD | \ env GZIP= gzip --no-name --best --rsyncable \ > $PACKAGE-$VERSION-src.tar.gz /Simon signature.asc Description: PGP signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
> > Ideally debbugs should be made non-native so that some else could > > maintain the Debian package. > > I'm happy to review patches that get the 2.6 branch of debbugs in shape > where it can be released into Debian again if someone wants to take that > effort. I've just assumed that anyone using that package was running > unstable or running debbugs out of git. I did not notice the release_2.6 branch before. What is the intent with that branch? Do you want people to submit patches targeting 'master' or 'release_2.6'? How often do you plan to merge it to or from 'master'? The 'master' branch is still the default branch. The https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/README.md does not mention anything about release_2.6. Should it? I am a big fan of READMEs and recommend using them to convey guidance to contributors (assuming you want to have contributors).
Re: Debian 10 "buster" moved to archive.debian.org
Hi Otto, In Buster's case, it would be becoming an ELTS soon and would have to use Freexian's repositories. It would no longer be the security team with DLAs that would take care of CVEs for ELTS, but the Frexian team. So much so that if I look at the links below I didn't find anything (about security) for versions with extended support. https://archive.debian.org/debian/dists/ https://security.debian.org/debian-security/dists/ This point you mentioned is relevant. I will be following the finally of this conversation. Look, I hope I helped in some way and I realize that many users don't know the Freexian repositories. [1] https://www.freexian.com/lts/php/docs/access-apt-repositories [2] https://wiki.debian.org/LTS/Extended Cheers, Leandro Cunha
Re: Debian 10 "buster" moved to archive.debian.org
On Sat, 23 Mar 2024 at 01:32, Ansgar wrote: > > Hi, > > Debian 10 "buster" has moved to archive.debian.org in order to free > space on the main mirror network. We plan to start removing files for > non-LTS architectures in about two weeks; the existing Release files > will then refer to no longer existing files on the main mirror network. > > An exception is the security archive (which already has no non-LTS > architectures): we will only archive it after LTS support ended. Would it be feasible to mirror the security section to archive.debian.org as well? As of today for example if one uses Buster on armhf one needs to have the repos pointing to archive.debian.org but security still pointing to deb.debian.org, which is confusing. It would be simpler for systems that still have Buster could switch to archive.debian.org in one go and not have to do it twice (once for main, and later for security). Err:3 http://archive.debian.org/debian-security buster/updates Release 404 Not Found [IP: 151.101.194.132 80] Err:4 http://deb.debian.org/debian buster/main armel Packages 404 Not Found [IP: 151.101.162.132 80] Err:5 http://deb.debian.org/debian buster-updates/main armel Packages 404 Not Found [IP: 151.101.162.132 80]
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
On Sun, 19 May 2024, Bill Allombert wrote: > Also debbugs is a special case: > The debbugs Debian package (as opposed to the debbugs software) have never > been > really maintained. I am actually one of the very few users of this package > and I tried several times to get the maintainers to do a new upload but they > were clearly not interested. It's more that I'm prioritizing spending my (very) limited Debian time on keeping bugs.debian.org and debbugs itself working (and [very slowly] developing a new version of Debbugs with a more modern design in the hopes that others will contribute.) > Ideally debbugs should be made non-native so that some else could > maintain the Debian package. I'm happy to review patches that get the 2.6 branch of debbugs in shape where it can be released into Debian again if someone wants to take that effort. I've just assumed that anyone using that package was running unstable or running debbugs out of git. -- Don Armstrong https://www.donarmstrong.com A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi, On 5/20/24 04:32, Otto Kekäläinen wrote: I agree that duplication is bad - but I disagree that use of version control duplicates the use of the Debian archive for source code storage, or that use of GitLab for code reviews would duplicate Debbugs. Outside of DM uploads, I'm not sure that there is much of a need for a code review on packaging -- really what we want is to reduce the amount of code for packaging, by moving it into declarative frameworks whenever possible, so the vast majority of packaging changes should be trivial ones like upgrading a dependency version. Would you be kind and try to understand the opposing viewpoint by trying it for one day? I am using it for most of my packages. It has not made my life easier, it's just another layer that I need to communicate my intentions through. I generally do test builds of my packages in a local pbuilder instance, with a hook script to drop me into a shell if the build fails, so the workspace is kept for my investigation. The only CI system that offers a similar feature is Jenkins, but even there I can only inspect the files through a clunky web interface, as soon as I need to look at a binary file or search for a string, I need to download it as a zipfile, and re-running commands inside the same environment to test them is completely out. You could go to https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and conduct a code review? At first glance, looks good to me. Looking at the changes: 1. The outdated build dependency is not in the package currently in Debian. If it was, it would have been spotted by Debian's archive analysis tools already, without the need for a build attempt. This static analysis is cheaper than a rebuild, so to achieve the same level of coverage, Salsa would need to perform a full archive rebuild daily, and it would still not catch the broken Suggests: in the binary. 2. The missing file in debian/docs was already reported as #903413. 3. The other changes are "upstream" changes, which should have a separate CI that is more extensive than "still builds." Native packages should only be used for things where it does not make sense to maintain a separate upstream package because they only exist within the package ecosystem, like the "menu" package. Debbugs should really be split into separate "upstream" and "packaging" efforts. You might discover that GitLab is useful and is not duplicating Debbugs or anything else in Debian Well, there is an issue tracker (where tickets go unresponded for a year), that is certainly a duplication of debbugs. It would make sense to maybe track "upstream" bugs there and forward them from debbugs (a feature not present in GitLab's issues handling, but important for package maintenance). - it is currently the only platform to conduct code reviews on in a way that has automatic testing and comment-response-resolved -tracking. Doing code reviews patches attached in email does not have that. Well, I take the diff, prepend each line with > and insert my comments, then send it back. The author then responds to that email, and once the discussion is over, I get a new proposed patch. Not much difference. If you try it out, and still think Salsa is bad for Debian, then I am more willing to accept your stanze. It's not *bad*, but for a lot of our workflows, it's the wrong tool because the use cases it was designed for are different from ours, and there is little we can do to make them meet. Debian's workflow for collaboration on things that are not yet release-ready is clunky to the point that almost no one uses it that way, but in principle it is there: one can always upload a package to experimental and get it autobuilt on the major architectures, and other DDs can download it from there if they want to take a look at it. This workflow is what packaging in git mostly replaces: in pkg-electronics, we quite often have changes that are not ready for release that we want to distribute to the other team members. Quite often, these changes do not build straight away, and the reason they are shared is specifically so other people can take a look at them. Git is a lot better for fostering this collaboration than uploads to experimental, because we get change tracking for individual files, which is invaluable when dealing with a behemoth like ghdl that takes a few hours to build and run tests. The review process still takes place via mail here, because part of the process is that everyone involved needs to be able to build the package locally and investigate failures. We can quickly incorporate changes from others using git and do a minimal rebuild locally, that is useful, but this essentially means that we are pushing commits to an offside branch. Attaching the discussion to individual changes is not that useful for us: 1. changing a
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Thanks for reply Jonas, > > You could go to > > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and > > conduct a code review? > > > > You might discover that GitLab is useful and is not duplicating > > Debbugs or anything else in Debian - it is currently the only platform > > to conduct code reviews on in a way that has automatic testing and > > comment-response-resolved -tracking. Doing code reviews patches > > attached in email does not have that. > > > > If you try it out, and still think Salsa is bad for Debian, then I am > > more willing to accept your stanze. > > But it *is* duplicating Debbugs: None of your valuable contributions > posted as part of your code review appears on Debbugs. Actually some of them are in Debbugs as patches, but hard to find as there are 200+ open bugs. However, the bugs.debian.org system does not offer code testing or review facilitation. Again, I invite you to test out https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 for _code review_ for the same reason I stated above.
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Quoting Otto Kekäläinen (2024-05-19 21:32:36) > > > My concern about Gitlab is not its *additions* to existing services, but > > > its *duplications* of core services already in Debian. > > > > I agree, that's the key problem. > > I agree that duplication is bad - but I disagree that use of version > control duplicates the use of the Debian archive for source code > storage, or that use of GitLab for code reviews would duplicate > Debbugs. > > > > ...instead of lumping all those discussions into a discussion of ease of > > > user interface for a single catch-all code forge that maybe make all those > > > other complications go away by affecting all those questions and that way > > > implicitly provides *some* answer to them all. > > > > Also, there is a difference between ease of use and intuitivity. GitLab > > does not provide any tools that really make packaging easier. It is > > initially more accessible to non-maintainers, because of familiarity, > > but actual work happens outside of it. > > Would you be kind and try to understand the opposing viewpoint by > trying it for one day? > > You could go to > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and > conduct a code review? > > You might discover that GitLab is useful and is not duplicating > Debbugs or anything else in Debian - it is currently the only platform > to conduct code reviews on in a way that has automatic testing and > comment-response-resolved -tracking. Doing code reviews patches > attached in email does not have that. > > If you try it out, and still think Salsa is bad for Debian, then I am > more willing to accept your stanze. But it *is* duplicating Debbugs: None of your valuable contributions posted as part of your code review appears on Debbugs. The developers of FreedomBox (which is a Debian Pure Blend, i.e. a project fully within Debian) has embraced Salsa, and when I asked about an issue with network instability for certain hardware, I was told that it was in the issue tracker - which meant it was missing from Debbugs while actively discussed in Salsa. Salsa is *great* if you fully embrace it. Salsa is not good if you want single features without fully embracing it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
> > My concern about Gitlab is not its *additions* to existing services, but > > its *duplications* of core services already in Debian. > > I agree, that's the key problem. I agree that duplication is bad - but I disagree that use of version control duplicates the use of the Debian archive for source code storage, or that use of GitLab for code reviews would duplicate Debbugs. > > ...instead of lumping all those discussions into a discussion of ease of > > user interface for a single catch-all code forge that maybe make all those > > other complications go away by affecting all those questions and that way > > implicitly provides *some* answer to them all. > > Also, there is a difference between ease of use and intuitivity. GitLab > does not provide any tools that really make packaging easier. It is > initially more accessible to non-maintainers, because of familiarity, > but actual work happens outside of it. Would you be kind and try to understand the opposing viewpoint by trying it for one day? You could go to https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and conduct a code review? You might discover that GitLab is useful and is not duplicating Debbugs or anything else in Debian - it is currently the only platform to conduct code reviews on in a way that has automatic testing and comment-response-resolved -tracking. Doing code reviews patches attached in email does not have that. If you try it out, and still think Salsa is bad for Debian, then I am more willing to accept your stanze. - Otto
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi, On 5/19/24 16:11, Jonas Smedegaard wrote: My concern about Gitlab is not its *additions* to existing services, but its *duplications* of core services already in Debian. I agree, that's the key problem. The Debian archive itself is a VCS, so git-maintained packaging is also a duplication, and keeping the official VCS and git synchronized is causing additional work for developers, which is why people are opposed to having it mandated. The Debian archive is purpose-built for packaging, while git is general-purpose, and does not exactly fit our existing workflows. The main thing it adds is collaboration without releases. It is quite obvious we want something like that, so we need to go back to the design of the Debian system and look if we can add flows to facilitate that. The current debate feels a lot like "we need collaboration without releases as a feature, git provides that, let's use git", but we have more requirements than that, and my feeling is that these are falling by the wayside. ...instead of lumping all those discussions into a discussion of ease of user interface for a single catch-all code forge that maybe make all those other complications go away by affecting all those questions and that way implicitly provides *some* answer to them all. Also, there is a difference between ease of use and intuitivity. GitLab does not provide any tools that really make packaging easier. It is initially more accessible to non-maintainers, because of familiarity, but actual work happens outside of it. Simon OpenPGP_0xEBF67A846AABE354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
On Sat, May 18, 2024 at 08:25:10PM -0700, Otto Kekäläinen wrote: > Hi Bill and Wookey! > > In a recent long thread on debian-devel you had somewhat negative > sentiments towards the usefulness of Salsa. I am not sure this characterize my position. I have no opposition to Salsa (even though it is missing features Alioth had I relied on), I am opposed to be forced to use it when it just increases bureaucracy. > I do see you doing good > technical work for Debian and recently a MR from Bill too, so I was > thinking that maybe you will change your mind when you read more > in-depth arguments. This is my attempt to have you think about Salsa > in a new light: > > On Tue, 9 Apr 2024 at 11:41, Bill Allombert wrote: > > Having a repository on salsa or even "packaging team" does not prevent > > a lack of maintainer, so this is not relevant. > > Without a maintainer, no contribution will be merged in any case. > > Consider this Merge Request to fix debbugs builds immediately, and to > include Salsa-CI to keep the build from regressing again: > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 debbugs is a Debian-native package. So of course it needs an upstream git repository. All my Debian-native packages are maintained on Salsa (and before Salsa on Alioth). The MR I did was for lintian which is also Debian-native. Also debbugs is a special case: The debbugs Debian package (as opposed to the debbugs software) have never been really maintained. I am actually one of the very few users of this package and I tried several times to get the maintainers to do a new upload but they were clearly not interested. Ideally debbugs should be made non-native so that some else could maintain the Debian package. Cheers, -- Bill. Imagine a large red swirl here.
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Quoting Mathias Behrle (2024-05-19 11:08:58) > * Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re: > finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38 > +0200): > > > > i.e. you are being > > asocial if you don't, and can expect your behavior being discussed as a > > public-wide issue for the project). > > I very much agree with all what you say, however could we rather say instead > > -> i.e. you are not being collaborator friendly, and can expect your behavior > be > frowned upon... > > I am not a native english speaker, I think we can avoid to trap in a can of > worms with problematic terms like 'asocial, unsocial, anti-social...' which > could have quite special meanings in different cultures. Thanks for raising awareness to this. I was unaware that "asocial" was disruptive to the conversation, but indeed danish dictionaries (I am no native english speaker either) flag that word as condescending. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
* Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38 +0200): > i.e. you are being > asocial if you don't, and can expect your behavior being discussed as a > public-wide issue for the project). I very much agree with all what you say, however could we rather say instead -> i.e. you are not being collaborator friendly, and can expect your behavior be frowned upon... I am not a native english speaker, I think we can avoid to trap in a can of worms with problematic terms like 'asocial, unsocial, anti-social...' which could have quite special meanings in different cultures. Best, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Quoting Paul Gevers (2024-05-19 10:05:38) > In this discussion about mandating things, I've been wondering > > On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote: > > * mandate VCS-tracking > > * Yes > > * mandate the use of one specific VCS > > * Yes: git > > What do people think this should mean, a *should* or *must* in policy? > That the package has a RC bug if the packaging isn't tracked in git? And > if the packaging is in git but I forgot to push my latest changes to the > documented git server (this happens regularly to me as I do most uploads > with dgit)? RC? In all suites where the packaging version isn't pushed > for? And how about NMU's? (I just checked a random package without git: > aspell-am, last non-NMU upload was in 2013)? > > If *must* and thus RC, can the issue be fixed by "NMU"? I.e. if the > person that did the changes, (and has nice local commits) somehow isn't > available, will the package (if not key) be auto-removed? Or can > everybody fix the repo? What if you don't have write access to the > existing repo? And then what if the uploader comes back and tries to > push the real history? What if my harddisk with local changes crashes > before I push (again, I forget that sometimes, but for me luckily dgit > will mostly have the commits). > > Or is this "just a bug", maybe even at level important, but no other > consequences. Than I think this discussion is going to be moot. I don't > think there's much forcing possible and I think most already agree that > stuff *should* be in VCS, so this isn't going to change for those in > favor. And does it really add enough value if those that are forced are > just going to do "gbp import-dsc" for each upload to the archive on a > ./debian only repository? Because that (or better) we could already > automate (see also my PS). With "mandate" I do not mean kick out if non-compliant. Same as we (as far as I am aware) mandate declaring Poilcy version followed by a package, but don't kick out packages having mismatching declaration or not following latest policy. I think there is a big difference between saying that Salsa (or git, og Debbugs, or public-wide WNPP work tracking) is an optional addon to Debian, to saying that it is expected of everyone (i.e. you are being asocial if you don't, and can expect your behavior being discussed as a public-wide issue for the project). So I disagree that tool-use severity of "important" makes progress moot. I have met developers who have the view that we are already at the point of non-use of Salsa being asocial behavior, and had at least one very interested (and calm) exchange of such differing views at Debconf in Kosovo. Deciding project-wide where we are on that scale do help, I think. > PS: I've always wondered if the dgit server shouldn't track history, > even if uploads don't happen via it. A dgit clone could (should?) > already provide available history, even if no upload happened via it yet. All the points that I listed are all about optional/expected/required *contributor* streamlining. If I understand your comment above about dgit correctly, it is about automation of history tracking, which is (mostly) orthogonal to *contributor* streamlining. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Two mistakes spotted On 19-05-2024 10:05 a.m., Paul Gevers wrote: I think there's a large majority (maybe even consensus) that believe you *should* have the packaging in VCS I meant "at least should", as in "should or must". I think what pere did [3] [3] https://people.skolelinux.org/pere/blog/45_orphaned_Debian_packages_moved_to_git__391_to_go.html Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi all,
In this discussion about mandating things, I've been wondering
On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote:
* mandate VCS-tracking
* Yes
* mandate the use of one specific VCS
* Yes: git
What do people think this should mean, a *should* or *must* in policy?
That the package has a RC bug if the packaging isn't tracked in git? And
if the packaging is in git but I forgot to push my latest changes to the
documented git server (this happens regularly to me as I do most uploads
with dgit)? RC? In all suites where the packaging version isn't pushed
for? And how about NMU's? (I just checked a random package without git:
aspell-am, last non-NMU upload was in 2013)?
If *must* and thus RC, can the issue be fixed by "NMU"? I.e. if the
person that did the changes, (and has nice local commits) somehow isn't
available, will the package (if not key) be auto-removed? Or can
everybody fix the repo? What if you don't have write access to the
existing repo? And then what if the uploader comes back and tries to
push the real history? What if my harddisk with local changes crashes
before I push (again, I forget that sometimes, but for me luckily dgit
will mostly have the commits).
Or is this "just a bug", maybe even at level important, but no other
consequences. Than I think this discussion is going to be moot. I don't
think there's much forcing possible and I think most already agree that
stuff *should* be in VCS, so this isn't going to change for those in
favor. And does it really add enough value if those that are forced are
just going to do "gbp import-dsc" for each upload to the archive on a
./debian only repository? Because that (or better) we could already
automate (see also my PS).
I'm against mandating ("must"). I think there's a large majority (maybe
even consensus) that believe you *should* have the packaging in VCS (and
I agree with that). Most packages already are (hopefully maintained) in
git (93% for testing) [1] on salsa (86%) [2], so I propose we stop the
discussion. I think what pere did [3] changed more than this whole
discussion: already 45 *orphaned* packages converted to git by 25 April,
which means my numbers above are on the low side. The remaining 438 QA
maintained (!!??) packages constitute close to 20% of the packages not
in git.
Paul
PS: I've always wondered if the dgit server shouldn't track history,
even if uploads don't happen via it. A dgit clone could (should?)
already provide available history, even if no upload happened via it yet.
[1] https://trends.debian.net/vcs_testing-stacked.png
[2] https://trends.debian.net/vcs-hosting_testing-stacked.png
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Quoting Otto Kekäläinen (2024-05-19 05:25:10) > In a recent long thread on debian-devel you had somewhat negative > sentiments towards the usefulness of Salsa. I do see you doing good > technical work for Debian and recently a MR from Bill too, so I was > thinking that maybe you will change your mind when you read more > in-depth arguments. This is my attempt to have you think about Salsa > in a new light: > > On Tue, 9 Apr 2024 at 11:41, Bill Allombert wrote: > > Having a repository on salsa or even "packaging team" does not prevent > > a lack of maintainer, so this is not relevant. > > Without a maintainer, no contribution will be merged in any case. > > Consider this Merge Request to fix debbugs builds immediately, and to > include Salsa-CI to keep the build from regressing again: > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 > > 1. If the package was not on git and Salsa, I would have no way to see > what the maintainers have been doing in the years 2018-2023 (Debian > repos had last upload in 2018) With git (or another VCS) but *without Salsa, you would certainly not be blind to existing development. I agree with striving towards VCS tracking of all code in Debian, and striving towards the use of a single VCS, and I think it is reasonable to separate the discussion about that from the discussion about the relevancy of Salsa. > 2. If the package was not on Salsa, and had the MR feature active, I > would not be able to submit a MR to fix the issues. Now the MR is up > there, and anybody can review and comment it - thus we are not even > dependent on the original maintainers alone. With git but without Salsa, you would post a patch to Debbugs, that would be up there for anybody to review and comment on. Sure, you would not be able to specifically use a Gitlab routine without having a Gitlab instance to do it on. And reviewers and commenters would need to be bothered with using email, which is different but not inherently worse than having to be bothered with using Gitlab UIs. Did you also post your MR as a patch in Debbugs? > 3. The UI is easy and useful. I invite you to read my MR and add your > review. I made have some extra instructions to make this very > welcoming for people who do not "like" Salsa/GitLab and might feel > that something is unintuitive The UI of my email program is easy and useful. You don't need to agree with me, you can pick another email system that is more to your liking. It is much harder with Gitlab to provide room for different personal ways of working. Please note, that I am here, like yourself, not talking about different ways of structuring code in a VCS, but about how the UI affects how you personally are able to interact. You and I quite likely use different text editor, and different email application, and possibly also different web browser. That affects how easy and useful the personal end of collaboration is. The collective end of collaboration must involve how (if at all) code is tracked in a VCS, but it need not dictate UI at all. > 4. If you don't want to use the web UI, you can also download my patch > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19.patch > and review by email. Or you can click in the UI once to subscribe the > MR and then continue review/comments by email. If you don't want to use a command-line or a scripted or a GUI-based email application for receiving patches shared at Debbugs, you can use a web-based email application - locally hosted or through a provider. I already subscribe to Debbugs for the packages and teams I am most interested in tracking contributions for. > Personally I fully agree with the people stating that "Salsa is the > best thing in Debian in the past 20 years". So far everyone I talked > to who initially had reservations regarding using Salsa have started > liking it after they learned a bit more how it works, and have seen > things like Salsa-CI in action saving the Debian archive from needless > widespread failures. Debian is *not* helped by spreading issue tracking across multiple independent data and communication networks. My concern about Gitlab is not its *additions* to existing services, but its *duplications* of core services already in Debian. Please, let us separately discuss if we should... * mandate VCS-tracking * mandate the use of one specific VCS * mandate one specific VCS workflow * mandate collaborative packaging * mandate project-wide issue tracking * mandate a single project-wide issue-tracker ...instead of lumping all those discussions into a discussion of ease of user interface for a single catch-all code forge that maybe make all those other complications go away by affecting all those questions and that way implicitly provides *some* answer to them all. Personally, my curren
Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi Bill and Wookey! In a recent long thread on debian-devel you had somewhat negative sentiments towards the usefulness of Salsa. I do see you doing good technical work for Debian and recently a MR from Bill too, so I was thinking that maybe you will change your mind when you read more in-depth arguments. This is my attempt to have you think about Salsa in a new light: On Tue, 9 Apr 2024 at 11:41, Bill Allombert wrote: > Having a repository on salsa or even "packaging team" does not prevent > a lack of maintainer, so this is not relevant. > Without a maintainer, no contribution will be merged in any case. Consider this Merge Request to fix debbugs builds immediately, and to include Salsa-CI to keep the build from regressing again: https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 1. If the package was not on git and Salsa, I would have no way to see what the maintainers have been doing in the years 2018-2023 (Debian repos had last upload in 2018) 2. If the package was not on Salsa, and had the MR feature active, I would not be able to submit a MR to fix the issues. Now the MR is up there, and anybody can review and comment it - thus we are not even dependent on the original maintainers alone. 3. The UI is easy and useful. I invite you to read my MR and add your review. I made have some extra instructions to make this very welcoming for people who do not "like" Salsa/GitLab and might feel that something is unintuitive 4. If you don't want to use the web UI, you can also download my patch https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19.patch and review by email. Or you can click in the UI once to subscribe the MR and then continue review/comments by email. Personally I fully agree with the people stating that "Salsa is the best thing in Debian in the past 20 years". So far everyone I talked to who initially had reservations regarding using Salsa have started liking it after they learned a bit more how it works, and have seen things like Salsa-CI in action saving the Debian archive from needless widespread failures. Thanks, Otto
Accepted debian-science 1.14.6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 18 May 2024 22:50:49 +0200 Source: debian-science Architecture: source Version: 1.14.6 Distribution: unstable Urgency: medium Maintainer: Debian Science Team Changed-By: Andreas Tille Changes: debian-science (1.14.6) unstable; urgency=medium . * Remove r-cran-maptools from geography task since its removed from CRAN * Standards-Version: 4.7.0 * meteorology-dev: s/pkg-config/pkgconf/ . * start of automatic changelog entry * . * Changes in metapackage dependencies -science-chemistry added: Recommends: atomes -science-dataacquisition-dev added: Recommends: python3-trx-python -science-datamanagement added: Recommends: visidata -science-geography removed: Recommends: r-cran-maptools -science-mathematics-dev added: Recommends: libigraph-dev, liblibleidenalg-dev removed: Recommends: libigraph0-dev -science-statistics added: Recommends: python3-hmmlearn -science-viewing-dev added: Recommends: python3-hvplot, python3-gneiss, python3-holoviews Checksums-Sha1: dd4d36d851861b34e5f0d811df1351096d5a25ea 5324 debian-science_1.14.6.dsc ff51d649ead9a989630e4114d8b07a21f4b11504 107112 debian-science_1.14.6.tar.xz c0a8513a4b22d0e10d9575818a303e853365722e 19934 debian-science_1.14.6_amd64.buildinfo Checksums-Sha256: a9f4813efabf0d76affb8df0d6af7207692c9ec51e107b9a23fd60576297a400 5324 debian-science_1.14.6.dsc 87d6abc6aa63a4c07f9ec275fc71197d2f511f7a38aeb5715a45755d012d7f47 107112 debian-science_1.14.6.tar.xz 8980ce890204ea2d4c05ea72e8dd2f5c65ae919321b96b4a7afb7692dac39555 19934 debian-science_1.14.6_amd64.buildinfo Files: 1f3ed72ff2a43b005f980c60d8907a0a 5324 science optional debian-science_1.14.6.dsc c27d68a885e71bedea4ec7deb039f7ee 107112 science optional debian-science_1.14.6.tar.xz 9310b8ce4221cc34214406260f1467bc 19934 science optional debian-science_1.14.6_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCAAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmZJFu0RHHRpbGxlQGRl Ymlhbi5vcmcACgkQV4oElNHGRtEpwQ//TvvijSUcTz1Av2Yhluu0gBLeuPJBOpl2 q9Cp2rtMmah30NzxPEsH7zErkU3i87Fgjc7jCwXKAcAJpZ3mYBpAsHXLTgYItEtm k0IGVDYnkiQvS9i1Y6xCZWt4G0U6rHkiSPI63EHGJ0gs1O033GQg8YMAQnGEx/TS uXbgwD3MAE/1CHLC2LTVJWEm9BX51mY3/6kwByBWaX5YWviNB21HBnQSlZCbK2bP SD3iXeOvZ0SvLkxtDMl8rYGvoSjjOjau+9VTf+Ajj64xa75gMiEiCi+uBR8nNwfZ T/daW3lmO7YpNTwWOcQGmScRpWI/54ix36oHGKVJNkP+H2TRL/+5Vo9MTZZB6Rf2 t5yluFyHyb28oUvcjAy1tMlyY3KMlfMVvcCRmC1j2OspycFX989F+5joLg/8l4VX I6N3cE3BLp85H3yIXAt0i2YlQytqQWKzpy8KXPDXfFHZEKYy3sv7gZeilDw/Z8CD y38np1qq2LsyRzcKcVfRxPr1UuWzMgLXUhMv13eJsu1KP6PRDL4ewskN5U2VoJhI GwDwBWXOAgPYoSH620UHqBCE2JxFpPHpbTNoyfyCRidB8Gf0ErpGZKrQIDsj5xzg yH2wiV6J5RZ+J3cE8EOCQwa1uR+clV5TtUlH2H0x8rwWsjmaH/V39SBvXl73TJq/ IksPYE+/0uI= =nJhZ -END PGP SIGNATURE- pgpMIWWPIPN0B.pgp Description: PGP signature
Re: How to create a custom Debian ISO
+debian-live Hello Aditya, On 11/05/2024 10:21, Aditya Garg wrote: I wanted to create a custom ISO of Debian, with the following customisations: 1. I want to add a custom kernel that supports my Hardware. 2. I want to add my own Apt repo which hosts various software packages to support my hardware. I am not able to get any good documentation for the same. Please help. Let me chime in on this thread as well. I had a quick peek at the scripts you use [1]. It appears to me that you want to create a custom Debian Live ISO (not a netinst image). If so, you can take a look at live-build, which is used for the Debian live images. Steps describing how to build a live ISO image are at [2] and a generic manual for live-build is at [3]. You can then build an ISO image from their packages, without the need for repacking (and automagically all checksums will match) With kind regards, Roland Clobus Co-maintainer of live-build [1] https://github.com/t2linux/T2-Ubuntu/tree/LTS [2] https://wiki.debian.org/ReproducibleInstalls/LiveImages [3] https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html OpenPGP_signature.asc Description: OpenPGP digital signature
Accepted rust-assorted-debian-utils 0.7.1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 18 May 2024 06:07:53 + Source: rust-assorted-debian-utils Architecture: source Version: 0.7.1-2 Distribution: unstable Urgency: medium Maintainer: Debian Rust Maintainers Changed-By: Peter Michael Green Changes: rust-assorted-debian-utils (0.7.1-2) unstable; urgency=medium . * Team upload. * Package assorted-debian-utils 0.7.1 from crates.io using debcargo 2.6.1 * Stop patching serde-yaml dependency. Checksums-Sha1: 9df27682cdff547456bbbeab221816279f9e49d6 2657 rust-assorted-debian-utils_0.7.1-2.dsc 8d5b6bdfaf670fb22ed159ddcebee29147aca6e3 2752 rust-assorted-debian-utils_0.7.1-2.debian.tar.xz f3d8512694672e862773e34b60e1d5625f59fbf9 13027 rust-assorted-debian-utils_0.7.1-2_source.buildinfo Checksums-Sha256: 12e3118f510f135a1320838b027f2e7b547132ef9bb006148f81413c937ef9c4 2657 rust-assorted-debian-utils_0.7.1-2.dsc 69e211ae4e2826dde55664271ce7027834cad359c1ff8219b2af107caed427cb 2752 rust-assorted-debian-utils_0.7.1-2.debian.tar.xz 555767affd06b21fbf325a3828bb19b6da0a4faa9c8aaa2736e7e58294f34d1e 13027 rust-assorted-debian-utils_0.7.1-2_source.buildinfo Files: c4d7b316087f9c1102f51934b8dcb47e 2657 rust optional rust-assorted-debian-utils_0.7.1-2.dsc bc2e413a071a52b4f874f4f3ec0e2c2b 2752 rust optional rust-assorted-debian-utils_0.7.1-2.debian.tar.xz 5aebd607ce5e837ad4dee8ed3e70cc14 13027 rust optional rust-assorted-debian-utils_0.7.1-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEEU0DQATYMplbjSX63DEjqKnqP/XsFAmZIYikUHHBsdWd3YXNo QGRlYmlhbi5vcmcACgkQDEjqKnqP/XsrpQ//dQDZsyq9oNDqaArjOAtvvsVYpxCi 3Yfwbxmaz/fCirvjFieXotztJUpDwyALSl/pdgWQ75cgD1vDt8mqm88Z/8SSqfLM ATIibSdtnpr8Ot0vg1aJAEyppKeRMG3R1hHZPCTvzDRJotSbQx7VK86/nIChL7dY 1q053Hl7RTCMMNRt7rW2QbwGs+xq1o0ikX3UHxdVmBsUm+2F0rZgIb6VWPt0CRko +PiHKVRWAv7Aid4GYjk1J0NJMGk0sTveo6jxQaNDCcGyH7CLqRRg8SdpS97OKzP8 mu91/3zyeVcV5QevktmD/kdk0cH+dWIXXRM0xd9iBwn1rGQ28eLbpaovTVZ6hi0E e4wVhIT/OQ7PTyFSqjhqfVpH56A8OhynKAuet3Pzrkxn9HrRN58zOF4W/eZsLJmr MLIirGYhCGJnP8+tsD2E6WiE2Rky//5Gji3NWfnEDwnBuLm+TZ4s0mCabmOrxqS+ grRRV58G4kQeZAvRjc3gqmYPnnIgbHP86ccdqINacXDCg2Z5XpPRfabUtTXxqdhR WbVPKRWGMOJIq6cpHpoKg828IdqKR/4265wxeqLbLvNcft3ZRIasCnRQjRX+nw+R cgyEtmQVpW5sj8Mnp13OTip4SXbf+1RkyiLGDMcXPkkOuFqXJmG9BDOMpnynyQbG /ls+6JlucGCWvWQ= =y9w2 -END PGP SIGNATURE- pgpUnNAzRehpR.pgp Description: PGP signature
Re: How to create a custom Debian ISO
Hi, > I'm getting error 500 when attempting to open the source code. just try again later. Salsa seems to be having issues. > Also, I'd prefer an offline install since the wifi firmware for the > t2 Macs is extracted from macOS by the user and copied over to Linux. > It cannot be redistributed legally. You can still use the netinstall image. Its smaller, easier to distribute and you or a user can add new things. You don't need to distribute large parts of Debian just to replace the kernel and add a repo. But at the end the installers are all similar, it shouldn't make a difference if you modify the netinstall or DVD installer. Keep in mind that various kernel modules are loaded at install time as needed, you might need to provide the appropriate udebs for your kernel or modify the installer to be satisfied with what your kernel provides. So yes, looking at the reform installer might be a good start. Bernd -- Bernd Zeimetz Debian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: How to create a custom Debian ISO
On Sat, 2024-05-11 at 08:21 +, Aditya Garg wrote: > 1. I want to add a custom kernel that supports my Hardware. > 2. I want to add my own Apt repo which hosts various software > packages to support my hardware. Please consider adding that hardware support to the mainline Linux kernel and to the Debian Linux kernel packages and to Debian itself. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: How to create a custom Debian ISO
Hi I'm getting error 500 when attempting to open the source code. Also, I'd prefer an offline install since the wifi firmware for the t2 Macs is extracted from macOS by the user and copied over to Linux. It cannot be redistributed legally. > On 16 May 2024, at 7:45 PM, Johannes Schauer Marin Rodrigues > wrote: > > Hi, > > I'm removing debian-project from the recipients. > > Quoting Aditya Garg (2024-05-11 10:21:55) >> I wanted to create a custom ISO of Debian, with the following customisations: >> >> 1. I want to add a custom kernel that supports my Hardware. >> 2. I want to add my own Apt repo which hosts various software packages to >> support my hardware. >> >> I am not able to get any good documentation for the same. Please help. > > I have a script which modifies/patches the official Debian netboot installer > medium as it is published on ftp.debian.org so that it can be used to install > Debian on the MNT Reform 2 open hardware laptop. To that end, the script is > able to add: > > - custom kernel > - custom device trees > - custom apt sources > - custom apt pinning > - custom package selection > - custom d-i preseed.cfg > - custom debconf templates > - custom d-i post-base-installer and finish-install scripts > > Feature highlights: > > - works with stable, unstable, stable-backports > - produces bit-by-bit reproduucible output > - requires no superuser privileges to run > > Source code here: > > https://salsa.debian.org/reform-team/reform-debian-installer > > This is the script that produces the debian-installer images that you can > download from here: > > https://reform.debian.net/d-i/ > > Maybe this helps. > > Thanks! > > cheers, josch >
Re: How to create a custom Debian ISO
Hi, I'm removing debian-project from the recipients. Quoting Aditya Garg (2024-05-11 10:21:55) > I wanted to create a custom ISO of Debian, with the following customisations: > > 1. I want to add a custom kernel that supports my Hardware. > 2. I want to add my own Apt repo which hosts various software packages to > support my hardware. > > I am not able to get any good documentation for the same. Please help. I have a script which modifies/patches the official Debian netboot installer medium as it is published on ftp.debian.org so that it can be used to install Debian on the MNT Reform 2 open hardware laptop. To that end, the script is able to add: - custom kernel - custom device trees - custom apt sources - custom apt pinning - custom package selection - custom d-i preseed.cfg - custom debconf templates - custom d-i post-base-installer and finish-install scripts Feature highlights: - works with stable, unstable, stable-backports - produces bit-by-bit reproduucible output - requires no superuser privileges to run Source code here: https://salsa.debian.org/reform-team/reform-debian-installer This is the script that produces the debian-installer images that you can download from here: https://reform.debian.net/d-i/ Maybe this helps. Thanks! cheers, josch signature.asc Description: signature
Re: How to create a custom Debian ISO
Well it's indeed not as easy as I thought as far as Debian ISOs are concerned. I'll try to be more precise. I am a maintainer for Ubuntu on Linux on T2 Macs project: https://t2linux.org/. We work to modify ISOs of commonly used distros by adding a custom kernel with drivers for T2 Macs and provide to the users. There has been a demand for Debian for a long time and I wish to provide the ISOs for the same. I would prefer making the ISO as similar to the official Debian ISO and just replace the Debian kernel with the customised kernel. I've already set up an apt repo which hosts the kernels over here: https://github.com/AdityaGarg8/t2-ubuntu-repo I'll be thankful if I get the best possible option. On 11 May 2024, at 8:33 PM, Thomas Schmitt wrote: Hi, Aditya Garg wrote to debian-devel: I wanted to create a custom ISO of Debian, with the following customisations: 1. I want to add a custom kernel that supports my Hardware. 2. I want to add my own Apt repo which hosts various software packages to support my hardware. I am not able to get any good documentation for the same. Please help. Marvin Renich wrote: The package live-build from the Debian Live project might help you do what you want. Indeed the live-build package seems to be in use outside Debian's own ISO production. Mailing list is debian-l...@lists.debian.org There exists a manual https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html Installation ISOs are made by package debian-cd, of which i am not aware that it would have have users outside the official ISO production.i Mailing list is debian...@lists.debian.org Your impression about lack of documentation is not wrong as far as this project is concerned. :)) Nevertheless the production step of packing up the ISO from a prepared file tree is documented together with methods to use a Debian installation ISO as base for the preparation: https://wiki.debian.org/RepackBootableISO Packages may probably be added at the appropriate place in the directory tree under /pool. (Managing a Debian repo is not my turf. Sorry for being vague here.) Changing the content of a Debian ISO might need some follow-up work in administrative files of the ISO. When merging Debian ISOs, my script https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/test/merge_debian_isos manipulates: /README.txt /dists/*/Release and merges the files listed in /dists/*/Release. You would have to explore whether these files are affected by your changes. Have a nice day :) Thomas
Accepted debian-security-support 1:13+2024.05.15 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 15 May 2024 09:56:16 +0200 Source: debian-security-support Architecture: source Version: 1:13+2024.05.15 Distribution: unstable Urgency: medium Maintainer: Debian Security Team , Changed-By: Holger Levsen Closes: 1063756 Changes: debian-security-support (1:13+2024.05.15) unstable; urgency=medium . [ Moritz Muehlenhoff ] * Mark pdns-recursor as EOLed in bullseye. * Mark slurm-wlm as EOLed in bullseye. . [ Holger Levsen ] * Mark snort as unsupported in bullseye and buster. Closes: #1063756 Checksums-Sha1: 556d3605f4f22c3811513066756414150bc1dd6d 1909 debian-security-support_13+2024.05.15.dsc baef110f7253eb1098ddeaa260ba6a72ee1c8272 34772 debian-security-support_13+2024.05.15.tar.xz 1ad54e8ba33f5e55076c9fc5ffe4e8a0c933fe56 7453 debian-security-support_13+2024.05.15_source.buildinfo Checksums-Sha256: e3b4c06532de4ed3db0cc8613ecc72b56054573e41298984ad0e3262ef4c7924 1909 debian-security-support_13+2024.05.15.dsc 74369d5761e9204282af5ffd0f39a5b5706b28de965853e704dce2b22b2ab010 34772 debian-security-support_13+2024.05.15.tar.xz 9a50dee508363425391ccbf39f6a4dd00b1f2b1321e3ec83e73ebd8892375472 7453 debian-security-support_13+2024.05.15_source.buildinfo Files: 28325d07fd5247950f59dc75adbb968f 1909 admin optional debian-security-support_13+2024.05.15.dsc 791c3ced9d42ba367b2d6f48862c5bf4 34772 admin optional debian-security-support_13+2024.05.15.tar.xz 23a5927ef6b769e0980f1291931d8460 7453 admin optional debian-security-support_13+2024.05.15_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmZEaxcACgkQCRq4Vgaa qhywFQ/9GjVzIGzT1AygttQmQpyMp2tEFu5nVQMXHWYCVXgMTWKy+W12u2Ga/OrE Jr0YLZfz1nOZvvKZfo19fvbioS21JtRmGZCsW4U02+tiXY1MU4D12bf7Cu8xECk2 emnvQL1tVCTQjcvZLYh0F2RzWfYDSwqpc1uueqy0qpGJc8neAVzlFnACMkQl0MtN zg4nsJ/3qp9HGOJAp7DxI+F3prU1aDBW4O1CzUwYAdZy4DxHtAGXrC/EMqxnTbD/ G2q0LVg/rri+i3Znyza6dziDFI5Ph2PzA/I6I+3DSwVf0F/F1GK+UzvbFytk4WBG 0pgkUJ7CCJ+rf/28k1KHvahNfZF0fonSbsMdyGgUVh4z2lkg5vM3sHgJx+aNWcRQ aHce10Tmi508PXRf2tN9WIiQKR4w6e7Z7XIq8B6v2zqGA3HsSkub2v+WI1Vvk6vR /okeH5Ygkk35DNe1lcnmQFo4aoHeb1HHVAKPMHTggqn7iITTAfn/1K8HuSz9Z0EM QUlLaP8zxa+VG5P9Zu2yMmRMs2+eFMrFVRnUEfGN8LrSHhzlrB3D0cGVK7fniLGx DObkpF+nyxYOWRAibc3fLG8W9sF83wsovLIHK7w3G+fU1chZaVe7QGvROD9SgFNt mXXrjU3AKMmm/md+4NZ/5dgcfSj7T+Nw40RO47ERIZ7kcZSm4xk= =Rl82 -END PGP SIGNATURE- pgpKEystFxkqF.pgp Description: PGP signature
Accepted debian-security-support 1:13+2024.05.14 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 14 May 2024 18:07:54 +0200 Source: debian-security-support Architecture: source Version: 1:13+2024.05.14 Distribution: unstable Urgency: medium Maintainer: Debian Security Team , Changed-By: Holger Levsen Changes: debian-security-support (1:13+2024.05.14) unstable; urgency=medium . [ Markus Koschany ] * Add lucene-solr to security-support-ended.deb10. . [ Santiago Ruano Rincón ] * Mark nivida-cuda-toolkit as non-supported in buster. . [ Holger Levsen ] * Bump standards version to 4.7.0, no changes needed. Checksums-Sha1: d49970ae2e4ebb03b2bafd591a0e7bef55d2396a 1909 debian-security-support_13+2024.05.14.dsc a75f53ed75e92addb4d5c8493f02843151ead90c 34644 debian-security-support_13+2024.05.14.tar.xz 81b38a78f3ebf7d2385ab5da3f1557a13f482cc7 7512 debian-security-support_13+2024.05.14_source.buildinfo Checksums-Sha256: 9601ee4ae504b63ecc65c867043b680a9dcd9d474506af326282a29e875d6b10 1909 debian-security-support_13+2024.05.14.dsc 6314ce11362660c17d5e40714cd6ea50ab782f0b32d3bd2923c04c398a09bbe2 34644 debian-security-support_13+2024.05.14.tar.xz c8cd66574243ed95aa5d155199e0db133c48ca73f48fd8fc01d228107f845c60 7512 debian-security-support_13+2024.05.14_source.buildinfo Files: 160a6c7653edac148fb3cdd4d4d98031 1909 admin optional debian-security-support_13+2024.05.14.dsc 33943e3a5bd49fec6e42defe7b62cb5f 34644 admin optional debian-security-support_13+2024.05.14.tar.xz 43b8930a33f81059cf16a5a9c9b7efce 7512 admin optional debian-security-support_13+2024.05.14_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmZDjOoACgkQCRq4Vgaa qhzlFA/8DulDJTyAblFuCSqIS2a5ZH2EHZdCrugy4Vz1ccyV1zbtJHqgr8+dEYz0 SDgIW3Z/t1/VAho7aETm9ueZatLT7kRyF6/Fk0BXOI8+Pq98bNeubMra4SyofQDy Y5UpBDYZ++uvUmxm8FPmdlJ5cZwEDn3akGbwOyGWsz9pu289244ANc2s8ckobkcu RasKEiV13szJbf3oroXuQs3RfpCV6HrzuDATManCr2AvRGd9sEZNQmqbMz1oXDV8 StjSdIeb7VMhp3/ND7AZ2i4kFla3M+S9+lNGhtFkkhvHmrdw7kwQae52L+ZNOuhc AXAjgBqD984CyMunCSKlPq6Zi9WrCijM7tujy07AGONy4PMiJCzIZMymliGNBScA uSqBFvLcQTM5Il4Lp84TGxSC3Fv46NWlyaFcTJjVOPP6ARtpswqGnLxaLRXvXEOd q9SIVI/ivaMqK8YPUPzmMB7hRNdnAO3diLpRZ5NNuYXKk0cgVSNSnun4YaIhqdD1 m4RlzRmqeD0hOyyzAeHGGmaJNZ3WLpaO6N13aPgAESeyzErzXl4ob+DESCZyWGK3 oE7dkgdSqWd3izKvnbx6FEq8Sa5aTr31havEC1ivEcyVLbUHtpOBHi6PzUudtf1Z 2tRLibm5eLQqfn/KNBxP46tWkpLoKbPAplB+6Fw+IiCWAXVUuSU= =vBFN -END PGP SIGNATURE- pgpK53mjEHpGH.pgp Description: PGP signature
Re: De-vendoring gnulib in Debian packages
On Sun, May 12, 2024 at 04:27:06PM +0200, Simon Josefsson wrote:
> Going into detail, you use 'gzip -9n' but I use git-archive defaults
> which is the same as -n aka --no-name. I agree adding -9 aka --best is
> an improvement. Gnulib's maint.mk also add --rsyncable, would you agree
> that this is also an improvement?
I'm not convinced --rsyncable is an improvement. It makes the
compressed object slightly larger, and in exchange, if the compressed
object changes slightly, it's possible that when you rsync the changed
file, it might be more efficient. But in the case of PGP signed
release tarballs, the file is constant; it's never going to change,
and even if there are slight changes between say, e2fsprogs v1.47.0
and e2fsprogs v1.47.1, in practice, this is not something --rsyncable
can take advantage of, unless you manually copy
e2fsprogs-v1.47.0.tar.gz to e2fsprogs-v1.47.1.tar.bz, and then rsync
e2fsprogs-v1.471.tar.g and I don't think anyone is doing this,
either automatically or manually.
That being said, --rsyncable is mostly harmless, so I don't have
strong feelings about changing it to add or remove in someone's
release workflow.
> Right, there is no requirement for orig.tar.gz to be filtered. But then
> the outcome depends on upstream, and I don't think we can convince all
> upstreams about these concerns. Most upstream prefer to ship
> pre-generated and vendored files in their tarballs, and will continue to
> do so.
Well, your blog entry does recognize some of the strong reasons why
upstreams will probably want to continue shipping them. First of all,
not all compilation targets are guaranteed to have autoconf, automake,
et. al, installed. E2fsprogs is portable to Windows, MacOS, AIX,
Solaris, HPUX, NetBSD, FreeBSD, and GNU/Hurd, in addition to Linux.
If the package subscribes to the 'all the world's Linux, and nothing
else exists/we have no interest in supporting anything elss', I'd ask
the question, why are they using autoconf in the first place? :-)
Secondly, i have gotten burned with older versions of either autoconf
or the aclocal macros changing in incompatible ways between versions.
So my practice is to check into git the configure script as generated
by autoconf on Debian testing, which is my development system; and if
it fails on anything else, or when a new version of autoconf or
automake, etc. causes my configure script to break, I can curse, and
fix it myself instead of inflicting the breakage on people who are
downloading and trying to compile e2fsprogs.
Let's assume upstream doesn't ship minimized tarballs that are
> free from vendored or pre-generated files. That's the case for most
> upstream tarballs in Debian today (including e2fsprogs, openssh,
> coreutils). Without filtering that tarball we won't fulfil the goals I
> mentioned in the beginning of my post. The downsides with not filtering
> include (somewhat repeating myself):
>
> ...
Your arguments are made in a very general way --- there are potential
problems for _all_ autogenerated or vendored files. However, I think
it's possible to simply things by explicitly restricting the problem
domain to those files auto-generated by autoconf, automake, libtool,
etc. For example, the argument that this opens things up for bugs
could be fixed by having common code in a debhelper script that
re-generates all of the autoconf and related files. This address your
"tedious" and "fragile" argument.
And if you are always regenerating those files, you don't need to
audit the code, since they are going to them, no? And the generated
files from autoconf and friends have well understood licensing
concerns.
And by the way, all of your concerns about vendored files, and all of
my arguments for why it's no big deal apply to gnulib source files,
too, no? Why are you so insistent on saying that upstream must never,
ever ship vendored files --- but I don't believe you are making this
argument for gnulib?
Yes, it's simpler if we have procrustean rules of the form "everything
MUST be shared libraries", and "never, EVER have generated or vendored
files". However, I think we're much better off if we have targetted
solution which fix the 80 to 90% of the cases. We agree that gnulib
isn't going to be a shared library; but the argument in favor of it
means that there are exception, and I think we need to have similar
accomodations files like configure, config.{guess,sub}.
Upstream *is* going to be shipping those files, and I don't think it's
worth it to deviate from upstream tarballs just to filter out those
files, even if it makes somethings simpler from your perspective. So
I do hear your arguments; it's just on balance, my opinion is that it's
not worth it.
Cheers,
- Ted
Re: De-vendoring gnulib in Debian packages
Ansgar writes: > In ecosystems like NPM, Cargo, Golang, Python and so on pinning to > specific versions is also "explicitly intended to be used"; they just > sometimes don't include convenience copies directly as they have tooling > to download these (which is not allowed in Debian). Yeah, this is a somewhat different case that isn't well-documented in Policy at the moment. > (Arguably Debian should use those more often as keeping all software at > the same dependency version is a futile effort IMHO...) There's a straight tradeoff with security effort: more security work is required for every additional copy of a library that exists in Debian stable. (And, of course, some languages have better support for having multiple simultaneously-installed versions of the same library than others. Python's support for this is not great; the ecosystem expectation is that one uses separate virtualenvs, which don't really solve the Debian build dependency problem.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: De-vendoring gnulib in Debian packages
Hi, On Sun, 2024-05-12 at 08:41 -0700, Russ Allbery wrote: > "Theodore Ts'o" writes: > > And yet, we seem to have given a pass for gnulib, probably because it > > would be too awkward to enforce that rule *everywhere*, so apparently > > we've turned a blind eye. > > No, there's an explicit exception for cases like gnulib. Policy 4.13: > > Some software packages include in their distribution convenience > copies of code from other software packages, generally so that users > compiling from source don’t have to download multiple packages. Debian > packages should not make use of these convenience copies unless the > included package is explicitly intended to be used in this way. In ecosystems like NPM, Cargo, Golang, Python and so on pinning to specific versions is also "explicitly intended to be used"; they just sometimes don't include convenience copies directly as they have tooling to download these (which is not allowed in Debian). (Arguably Debian should use those more often as keeping all software at the same dependency version is a futile effort IMHO...) Gnulib is just older and targeted at the C ecosystem which still has worse tooling that pretty much everything else. Ansgar
Re: De-vendoring gnulib in Debian packages
"Theodore Ts'o" writes: > The best solution to this is to try to promote people to put those > autoconf macros that they are manually maintaining that can't be > supplied in acinclude.m4, which is now included by default by autoconf > in addition to aclocal.m4. Or use a subdirectory named something like m4, so that you can put each conceptually separate macro in a separate file and not mush everything together, and use: AC_CONFIG_MACRO_DIR([m4]) (and set ACLOCAL_AMFLAGS = -I m4 in Makefile.am if you're also using Automake). > Note that how we treat gnulib is a bit differently from how we treat > other C shared libraries, where we claim that *all* libraries must be > dynamically linked, and that include source code by reference is against > Debian Policy, precisely because of the toil needed to update all of the > binary packages should some security vulnerability gets discovered in > the library which is either linked statically or included by code > duplication. > And yet, we seem to have given a pass for gnulib, probably because it > would be too awkward to enforce that rule *everywhere*, so apparently > we've turned a blind eye. No, there's an explicit exception for cases like gnulib. Policy 4.13: Some software packages include in their distribution convenience copies of code from other software packages, generally so that users compiling from source don’t have to download multiple packages. Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: De-vendoring gnulib in Debian packages
"Theodore Ts'o" writes: >> 1) Use upstream's PGP signed git-archive tarball. > > Here's how I do it in e2fsprogs which (a) makes the git-archive > tarball be bit-for-bit reproducible given a particular git commit ID, > and (b) minimizes the size of the tarball when stored using > pristine-tar: > > https://github.com/tytso/e2fsprogs/blob/master/util/gen-git-tarball Wow, written five years ago and basically the same thing that I suggest (although you store pre-generated ./configure scripts in git). Going into detail, you use 'gzip -9n' but I use git-archive defaults which is the same as -n aka --no-name. I agree adding -9 aka --best is an improvement. Gnulib's maint.mk also add --rsyncable, would you agree that this is also an improvement? Thus what I'm arriving at is this: git archive --prefix=inetutils-$(git describe)/ HEAD | gzip --no-name --best --rsyncable > -o inetutils-$(git describe)-src.tar.gz >> To reach our goals in the beginning of this post, this upstream tarball >> has to be filtered to remove all pre-generated artifacts and vendored >> code. Use some mechanism, like the debian/copyright Files-Excluded >> mechanism to remove them. If you used a git-archive upstream tarball, >> chances are higher that you won't have to do a lot of work especially >> for pre-generated scripts. > > Why does it *has* to be filtered? For the purposes of building, if > you really want to nuke all of the pre-generated files, you can just > move them out of the way at the beginning of the debian/rules run, and > then move them back as part of "debian/rules clean". Then you can use > autoreconf -fi to your heart's content in debian/rules (modulo > possibly breaking things if you insist on nuking aclocal.m4 and > regenerating it without taking proper care, as discussed above). > > This also allows the *.orig.tar.gz to be the same as the upstream > signed PGP tarball, which you've said is the ideal, no? Right, there is no requirement for orig.tar.gz to be filtered. But then the outcome depends on upstream, and I don't think we can convince all upstreams about these concerns. Most upstream prefer to ship pre-generated and vendored files in their tarballs, and will continue to do so. Let's assume upstream doesn't ship minimized tarballs that are free from vendored or pre-generated files. That's the case for most upstream tarballs in Debian today (including e2fsprogs, openssh, coreutils). Without filtering that tarball we won't fulfil the goals I mentioned in the beginning of my post. The downsides with not filtering include (somewhat repeating myself): - Opens up for bugs causing pre-generated files not being re-generated even when they are used to build the package. I think this is fairly common in Debian packages. Making sure all pre-generated files are re-generated during build -- or confirming that the file is not used at all -- is tedious and fragile work. Work that has to be done for every release. Are you certain that ./configure is re-generated? If it is not present you would notice. - Auditing the pre-generated and vendored files for malicious content takes more time than not having to audit those files. Especially if those files are not stored in upstream git. - Pre-generated and vendored files trigger licensing concerns and require tedious work that doesn't improve the binary package deliverable. Consider files like texinfo.tex for example, wouldn't it be better to strip that out of tarballs and not have to add it to debian/copyright? If some code in a package, let's say getopt.c, is not used during build of the package, the license of that file doesn't have to be mentioned in debian/copyright if I understand correctly: https://www.debian.org/doc/debian-policy/ch-archive.html#s-pkgcopyright If in a few releases later, that file starts to get used during compilation, the package maintainer will likely not notice. If it was filtered, the maintainer would notice. The best is when upstream ship a tarball consistent with what I dream *.orig.tar.gz should be: free of vendored and pre-generated files. Debian package maintainers can take action before this happens, to reach nice properties within Debian. Maybe some upstream will adapt. >> There is one design of gnulib that is important to understand: gnulib is >> a source-only library and is not versioned and has no release tarballs. >> Its release artifact is the git repository containing all the commits. >> Packages like coreutils, gzip, tar etc pin to one particular commit of >> gnulib. > > Note that how we treat gnulib is a bit differently from how we treat > other C shared libraries, where we claim that *all* libraries must be > dynamically linked, and that include source code by reference is > against Debian Policy, precisely bec
Re: De-vendoring gnulib in Debian packages
On Sat, May 11, 2024 at 04:09:23PM +0200, Simon Josefsson wrote: >The current approach of running autoreconf -fi is based on a >misunderstanding: autoreconf -fi is documented to not replace certain >files with newer versions: >https://lists.nongnu.org/archive/html/bug-gnulib/2024-04/msg00052.html And the root cause of *this* is because historically, people put their own custom autoconf macros in aclocal.m4, so if autoreconf -fi overwrote aclocal.m4, things could break. This also means that programmtically always doing "rm -f aclocal.m4 ; aclocal --install" will break some packages. The best solution to this is to try to promote people to put those autoconf macros that they are manually maintaining that can't be supplied in acinclude.m4, which is now included by default by autoconf in addition to aclocal.m4. Personally, I think the two names are confusing and if it weren't for historical reasons, perhaps should have been swapped, but oh, well (For example, I have some custom local autoconf macros needed to support MacOS in e2fsprogs's acinclude.m4.) > 1) Use upstream's PGP signed git-archive tarball. Here's how I do it in e2fsprogs which (a) makes the git-archive tarball be bit-for-bit reproducible given a particular git commit ID, and (b) minimizes the size of the tarball when stored using pristine-tar: https://github.com/tytso/e2fsprogs/blob/master/util/gen-git-tarball > To reach our goals in the beginning of this post, this upstream tarball > has to be filtered to remove all pre-generated artifacts and vendored > code. Use some mechanism, like the debian/copyright Files-Excluded > mechanism to remove them. If you used a git-archive upstream tarball, > chances are higher that you won't have to do a lot of work especially > for pre-generated scripts. Why does it *has* to be filtered? For the purposes of building, if you really want to nuke all of the pre-generated files, you can just move them out of the way at the beginning of the debian/rules run, and then move them back as part of "debian/rules clean". Then you can use autoreconf -fi to your heart's content in debian/rules (modulo possibly breaking things if you insist on nuking aclocal.m4 and regenerating it without taking proper care, as discussed above). This also allows the *.orig.tar.gz to be the same as the upstream signed PGP tarball, which you've said is the ideal, no? > There is one design of gnulib that is important to understand: gnulib is > a source-only library and is not versioned and has no release tarballs. > Its release artifact is the git repository containing all the commits. > Packages like coreutils, gzip, tar etc pin to one particular commit of > gnulib. Note that how we treat gnulib is a bit differently from how we treat other C shared libraries, where we claim that *all* libraries must be dynamically linked, and that include source code by reference is against Debian Policy, precisely because of the toil needed to update all of the binary packages should some security vulnerability gets discovered in the library which is either linked statically or included by code duplication. And yet, we seem to have given a pass for gnulib, probably because it would be too awkward to enforce that rule *everywhere*, so apparently we've turned a blind eye. I personally think the "everything must be dynamically linked" to be not really workable in real life, and should be an aspirational goal --- and the fact that we treat gnulib differently is a great proof point about how the current debian policy is not really doable in real life if it were enforced strictly, everywhere, with no exceptions Certainly for languages like Rust, it *can't* be enforced, so again, that's another place where that rule is not enforced consistently; if it were, we wouldn't be able to ship Rust programs. - Ted
Accepted rshim-user-space 2.0.20+debian-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 09 May 2024 00:18:46 +0200 Source: rshim-user-space Architecture: source Version: 2.0.20+debian-3 Distribution: unstable Urgency: medium Maintainer: da...@debian.org Changed-By: Taihsiang Ho (tai271828) Closes: 1064920 Changes: rshim-user-space (2.0.20+debian-3) unstable; urgency=medium . * debian/rules: conditionally append for i386 arch (Closes: #1064920) Checksums-Sha1: 3fb06b6f60b1b5f9b77f81912bae806ed4503b3d 2044 rshim-user-space_2.0.20+debian-3.dsc 3126bb9814e9d163da419db590284046213bd992 2940 rshim-user-space_2.0.20+debian-3.debian.tar.xz dc7b8222f8db54711b6290e3a7e16eb88611ac42 7609 rshim-user-space_2.0.20+debian-3_source.buildinfo Checksums-Sha256: 4afd7f91f7b0ff03eae2c4d93f6797a3d7067f9564e37a3a4933966a354729ad 2044 rshim-user-space_2.0.20+debian-3.dsc ed4ce3b0f680a62bc6d16340d9556f9da0351f2434701c1b38da54f137a585eb 2940 rshim-user-space_2.0.20+debian-3.debian.tar.xz 250a8bfa3450c6629f8e1876cd80293935e7dc6a168ee172660fcc0391e29620 7609 rshim-user-space_2.0.20+debian-3_source.buildinfo Files: d820b1b01ff144d172c21789e2c7a098 2044 admin optional rshim-user-space_2.0.20+debian-3.dsc 5a592bd9ddf5ca6069f912cdd1450c74 2940 admin optional rshim-user-space_2.0.20+debian-3.debian.tar.xz 2896c9907d0e43919c1022b7d081984e 7609 admin optional rshim-user-space_2.0.20+debian-3_source.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEECfR9vy0y7twkQ+vuG/g8XlT8hkAFAmY/riYRHGRhbm5mQGRl Ymlhbi5vcmcACgkQG/g8XlT8hkCYEA//b/VhyqUC/UYDmmHjIqFVNGA7eNDA9bRR 2vDicpw0PJrGcq70Ww7tqSckPFcDzuym6yh6yVqwVshixU+DQveYugAPaITtu0Ow Es5RmJ5kFnZNCRbhM7HHju3tsWML6B9EL4eZYt0IBfxTfIeuVhdz4foBYQYK9HOt 7y9TTVo58H/S/iJLokgJD41RuBGFZAOQNwlIrqARXIrhuPZ1VIkOJjSPhNus7Lu4 BLkL5CKhYyWygW2H3COiUo+1V1ugueRZAS6VroUf1tKljrYmHmZEPfeb/dHnWC6o GH3k11l45bI7R3yERYFHXZfKl0puqRpw2KRq/LHwtvh/f0SGyxuHjYT0o/1oOw3Q mATiqT3CXkdBnuk+7x3JTAXljV1boX+pNweNwKIRKOJpBoFQH8tHWB1wHz7DikGe kp0TIR3Ip0AW9SeXzyA3uMQoxJWQySlh5IvOjl37MOt6R7V93ooTNECJJGHvjxJ/ FePQrRRkvG9PHEpv4iAUQNYF4vtudpVsQr/2x+5emSGOin3pzeBveElm6FKnmQiO K92tbI7jM7kxRjhdT+/LMVVOX3UDovvb0EofEGN9YtKejXLtvyM2PsfGvMAsAZGU qDsyODCjm6JvGKvHq2fvLb8yZw5JN68oYLIppjItKcEmx8u7XYbdbLgSosna6S62 XscyVtGj9Cc= =i8YB -END PGP SIGNATURE- pgpkyRDQd_NLz.pgp Description: PGP signature
Re: De-vendoring gnulib in Debian packages
On 2024-05-11 07:09, Simon Josefsson via Gnulib discussion list wrote: I would assume that (some stripped down version of) git is a requirement to do any useful work on any platform these days, so maybe it isn't a problem Yes, my impression also is that Git has migrated into the realm of cc/gcc in that everybody has it, so it can depend indirectly on a possibly earlier version of itself. Although it is worrisome that our collective trusted computing base keeps growing, let's face it, if there's a security bug in Git we're all in big trouble anyway.
Re: De-vendoring gnulib in Debian packages
Bruno Haible writes: > Simon Josefsson wrote: >> Finally, while this is somewhat gnulib specific, I think the practice >> goes beyond gnulib > > Yes, gnulib-tool for modules written in C is similar to > > * 'npm install' for JavaScript source code packages [1], > * 'cargo fetch' for Rust source code packages [2], > > except that gnulib-tool is simpler: it fetches from a single source location > only. > > How does Debian handle these kinds of source-code dependencies? I don't know the details but I believe those commands are turned into local requests for source code, either vendored or previously packaged in Debian. No network access during builds. Same for Go packages, which I have some experience with, although for Go packages they lose the strict versioning so if Go package X declare a depedency on package Y version Z then on Debian it may build against version Z+1 or Z+2 which may in theory break and was not upstream's intended or supported configuration. We have a circular dependency situation for some core Go libraries in Debian right now due to this. I think fundamentally the shift that causes challenges for distributions may be dealing with packages dependencies that are version >= X to package dependencies that are version = X. If there is a desire to support that, some new patterns of the work flow is needed. Some package maintainers reject this approach and refuse to co-operate with those upstreams, but I'm not sure if this is a long-term winning strategy: it often just lead to useful projects not being available through distributions, and users suffers as a result. /Simon signature.asc Description: PGP signature
Re: De-vendoring gnulib in Debian packages
Simon Josefsson wrote: > Finally, while this is somewhat gnulib specific, I think the practice > goes beyond gnulib Yes, gnulib-tool for modules written in C is similar to * 'npm install' for JavaScript source code packages [1], * 'cargo fetch' for Rust source code packages [2], except that gnulib-tool is simpler: it fetches from a single source location only. How does Debian handle these kinds of source-code dependencies? Bruno [1] https://nodejs.org/en/learn/getting-started/an-introduction-to-the-npm-package-manager [2] https://doc.rust-lang.org/cargo/commands/cargo-fetch.html
Re: How to create a custom Debian ISO
Am Samstag, 11. Mai 2024, 10:21:55 CEST schrieb Aditya Garg: > Hello > > I wanted to create a custom ISO of Debian, with the following > customisations: > > 1. I want to add a custom kernel that supports my Hardware. > 2. I want to add my own Apt repo which hosts various software packages to > support my hardware. > > I am not able to get any good documentation for the same. Please help. Hi Aditya, mayebe you want to take a look at bootcdwrite. I have good experience made with bootcdwrite. Using this, you can create a boootable live iso with all your persoanl settings (including ~/home/* and users, including all personal settings.). This ISO can be installed, too. Just bootr it, and you can install it from the live system. The ISO can be greater than 4,7GB, so it can be installen on an USB-stick. For myself, i am using it for creating KALI-Linux (with all my settings, modules, exploits, settings etc. etc. etc. etc.). This ISO is about 30GB big and is an exact image of my installed system. Doing so, I can boot it whereever I wan and have everything available. If you want to do the same, just a hint: If your installed system resides on encrypted devices, you have to notice some special settings, otherwise it will not boot. Fell free, to ask for it. Hope this helps. Oh yes, another way is, just to create a livesystem with filesystem.squashfs. Then edit the filesystem.squashfs (it can be unpacked, edited and hen repacked). This is a little bit fiddly, but very versatile. Last but not least, I believe (but here I am not sure)· you may build your own standard debian installer ISO and put in your own package versions (if this is what you want, then preferly ask the installer-crew - they know much better than me, because I never used an own build Debian-installer-ISO). Have fun! Best Hans
De-vendoring gnulib in Debian packages
All, (going out to both debian-devel and bug-gnulib, please be respectful of each community's different perspectives and trim Cc when focus shifts to any Debian or gnulib specific topics) (please pardon the accidental duplicate post to bug-gnulib...) The content of upstream source code releases can largely be categorized into 1) the actual native source-code from the upstream supplier, 2) pre-generated artifacts from build tools (e.g., ./configure script) and 3) third-party maintained source code (e.g., config.guess or getopt.c). The files in 3) may be referred to as "vendoring". The habit of including vendored and pre-generated artifacts is a powerful and successful way to make release tarballs usable for users, going back to the 1980's. This habit pose some challenges for packaging though: 1) Pre-generated files (e.g., ./configure) should be re-generated to make sure the package is built from source code, and to allow patches on the toolchain used to generate the pre-generated files to have any effect. Otherwise we risk using pre-generated files created using non-free or non-public tools, which if I understand correctly against Debian main policy. Verifying that this happens for all pre-generated files in an upstream tarball is complicated, fragile and tedious work. I think it is simple to find examples of mistakes in this area even for important top-popcon Debian packages. The current approach of running autoreconf -fi is based on a misunderstanding: autoreconf -fi is documented to not replace certain files with newer versions: https://lists.nongnu.org/archive/html/bug-gnulib/2024-04/msg00052.html 2) If a security problem in vendored code is discovered, the security team may have to patch 50+ packages if the vendor origin is popular. Maybe even different versions of the same vendored code has to be patched. 3) Auditing the difference between the tarball and what is stored in upstream version control system (VCS) is challenging. The xz incident exploited the fact that some pre-generated files aren't included in upstream VCS. Some upstream react to this by adding all pre-generated artifacts to VCS -- OpenSSH seems to take the route of adding the generated ./configure script to git, which moves that file from 3) to 1) but the problem is remaining. 4) Auditing for license compliance is challenging, since not only do we have to audit all upstream's code but we also have to audit the license of pre-generated files and vendored source-code. There are probably more problems involved, and probably better ways to articulate the problems than what I managed to do above. The Go and Rust ecosystems solve some of these issues, which has other consequences for packaging. We have largely ignored that the same challenges apply to many C packages, and I'm focusing on those that uses gnulib -- https://www.gnu.org/software/gnulib/ -- gzip, tar, grep, m4, sed, bison, awk, coreutils, grub, libiconv, libtasn1, libidn2, inetutils, etc: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=users.txt Solving all of the problems for all packages will require some work and will take time. I've started to see if we can make progress on the gnulib-related packages. I'm speaking as contributor to gnulib and maintainer of a couple of Debian packages, but still learning to navigate -- the purpose of this post is to describe what I've done for libntlm and ask for feddback to hopefully make this into a re-usable pattern that can be applied to more packages. It would be great to improve collaboration on these topics between GNU and Debian. So let's turn this post into a recipe for Debian maintainers of packages that use gnulib to follow for their packages. I'm assuming git for now on, but feel free to mentally s/git/$VCS/. The first step is to establish an upstream tarball that you want to work with. There are too many opinions floating around on this to make any single solution a pre-requisite so here are the different approaches I can identify, ordered by my own preference, and the considerations with each. 1) Use upstream's PGP signed git-archive tarball. See my recent blog posts for this new approach. The key property here is that there is no need to audit difference between upstream tarball and upstream git. https://blog.josefsson.org/2024/04/01/towards-reproducible-minimal-source-code-tarballs-please-welcome-src-tar-gz/ https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/ 2) Use upstream's PGP signed tarball. This is the current most common and recommended approach, as far as I know. 3) Create a PGP signed git-archive tarball. If upstream doesn't publish PGP signed tarballs, or if there is a preference from upstream or from you as Debian package maintainer to not do 1) or 2), then create a minimal source-only copy of the git archiv
Re: How to create a custom Debian ISO
On 5/11/24 16:21, Aditya Garg wrote: Hello I wanted to create a custom ISO of Debian, with the following customisations: 1. I want to add a custom kernel that supports my Hardware. 2. I want to add my own Apt repo which hosts various software packages to support my hardware. I am not able to get any good documentation for the same. Please help. simple-cdd and underlying debian-cd works fine, you can add extra repo, and then extra packages to be included in final ISO, and even custom files or build steps. These are tiny utilities, with one page intro and in source comments stating their usage, also ultimate self-explaining code.
Re: How to create a custom Debian ISO
* Aditya Garg [240511 05:15]: > Hello > > I wanted to create a custom ISO of Debian, with the following customisations: > > 1. I want to add a custom kernel that supports my Hardware. > 2. I want to add my own Apt repo which hosts various software packages to > support my hardware. > > I am not able to get any good documentation for the same. Please help. [Redirecting to debian-user, dropping -project, M-F-T set to debian-user only] First, please don't double-post the same message within a few minutes. Give your message at least a half hour to show up before you decide it wasn't received. Second, neither debian-devel nor debian-project are appropriate lists for this question. You should use debian-u...@lists.debian.org or some other user-oriented forum. Also, posting a question to multiple lists at once (called cross-posting) is considered rude in most situations. To give a possible answer to your question, look at the Debian Live project: https://www.debian.org/devel/debian-live/ The package live-build from the Debian Live project might help you do what you want. ...Marvin
How to create a custom Debian ISO
Hello I wanted to create a custom ISO of Debian, with the following customisations: 1. I want to add a custom kernel that supports my Hardware. 2. I want to add my own Apt repo which hosts various software packages to support my hardware. I am not able to get any good documentation for the same. Please help.
How to create a custom Debian ISO
Hello I wanted to create a custom ISO of Debian, with the following customisations: 1. I want to add a custom kernel that supports my Hardware. 2. I want to add my own Apt repo which hosts various software packages to support my hardware. I am not able to get any good documentation for the same. Please help.
Accepted nmon 16q+debian-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 11 May 2024 07:05:42 +0200 Source: nmon Architecture: source Version: 16q+debian-1 Distribution: unstable Urgency: medium Maintainer: Salvatore Bonaccorso Changed-By: Salvatore Bonaccorso Changes: nmon (16q+debian-1) unstable; urgency=medium . * New upstream version 16q+debian * debian/rules: Update filename to compile (sync with new upstream) * Declare compliance with Debian policy 4.7.0 * Update copyright years for debian/* packaging files Checksums-Sha1: 46c808bbb172a79ca6bdd2ccdef731c3fcc4f746 1981 nmon_16q+debian-1.dsc 3b83562f9511585d3c5ac74b6327671201f59c89 65031 nmon_16q+debian.orig.tar.gz db9ce4af7c17e005f3afe9cb9d8d11e2ec960cfc 4448 nmon_16q+debian-1.debian.tar.xz Checksums-Sha256: 13aa1faef3723f0cb75e3ff5e86a1c629397b73f0a5c762c931e89c09b41eeb5 1981 nmon_16q+debian-1.dsc 5ac184b14624ecb8d69f500fd75c934432e9f8f98e9f878d4e9bf9c778513765 65031 nmon_16q+debian.orig.tar.gz e2013a18dec897dcae5452b8f3431ed56888b86779159cce15fc0ec7312ef14c 4448 nmon_16q+debian-1.debian.tar.xz Files: 483894715ee341145a279af86088ca1f 1981 utils optional nmon_16q+debian-1.dsc 06dc7b0eec03058326792011f7a8e41e 65031 utils optional nmon_16q+debian.orig.tar.gz 8db813e9816c1b638e175d5ae5f18ef1 4448 utils optional nmon_16q+debian-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmY+/W9fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2 NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk ZWJpYW4ub3JnAAoJEAVMuPMTQ89Ez0UP/Ap2n0KpMxVei0DZls+qJM5uVVmmTXPv MIjghc0tjCPWFN73Hu3UX3PGFdAUxTMyRoEzLZXjB1uRENyZVOw5B0siCVc5nrUU 0De3sGLLXM4O2rfpSEdvMP1rpvuXk+PVagVbMh+1uQGRYEbwtOleD1s1arPYzWvR W9uEU+FkKI49NdBcA4rHRVsswVHXDzbAFeAYNbwFvfglOp7MvYs6KPKWMQ4hZXY1 uD7Eu7v6yPbJiQK9CK71JiOFXGuNxebTaMVQaH2vhTHHPVTLd2as/RVXs6Fhq5of 24ZIIZEKrALL+mwO67sZznaEsxiPJuOa1/H29wbv5X63nVVocbBP3XkworfCXh5r RMok8a5YWvMl/zpN5We8jAu9zAnOQp0LFkYIM1+wPuN/kDXasyMcLnTorjSP2VlL RJNqeL/45wLy1yvcoepSqlnHfcPCPed/s3z2BY4hNpoV0IN3/1WHu52zaig7pu3R 7x4o0G2nriUpIvVhKEE7uVqRpW/bTvGejy6WKFQCntRfTvMLU0O8JV7MFxZC+l9u mSWy5ezkmCJ6jvlXTvpaHiW1/uV60E5mgYCtfE4SKGSxBU6e2bpuRTVPGB+sD57V 8CJc3w+PyuxwyJ0pqJ3VOtpj30rRCcaQAGjd6bLkcTYbQV3Kqrwpl8NfK7M1ju2W EFPR6fPBUulM =+YjQ -END PGP SIGNATURE- pgpvNpVrEaz4a.pgp Description: PGP signature
Re: Tool to build Debian packages not requiring root in containers ?
Hi Charles, * Charles Plessy [2024-05-08 07:27]: I want to leverage our cluster to automate as much of the rebuilds as I can, but could not find the right tool. I tried to run sbuild in a Singularity image and this failed. However, I do not need the whole power of engines like sbuild, as none of the packages involved require root priviledges to build. Have you tried the unshare backend for sbuild? It uses Linux namespaces instead of full-blown root privileges, and works really great for my regular packaging work. I have not tried running it inside a virtualization container, though. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Tool to build Debian packages not requiring root in containers ?
Le Wed, May 08, 2024 at 08:02:41AM -0700, Otto Kekäläinen a écrit : > > I read the docs on how Singularity is able to pull Docker images of Debian > Sid and build on top of them, and run and exec just like Docker/Podman. > Unfortunately it has its own Containerfile format ( > https://docs.sylabs.io/guides/3.5/user-guide/quick_start.html#singularity-definition-files) > and the commands have their own syntax. I guess Debcraft could be extended > to support it, but that would require at least one Singularity user as > frequent contributor to test and develop Singularity-compatibility. > > The entire code base is shell code. Perhaps you want to take a look if it > looks hackable for you? Hi Otto, I looked at the code, and while it would be easy to replace the podman commands to run containers, I wonder if there isn't a major roadblock: The main use of Singularity containers is to provide static images for software. The default is that the image is read-only and has write access to the host filesystems. Thus, running apt upgrade in a singularity container isn't something that is done usually. It might even be impossible, although I am not expert enough to make that statement firmly. Is there a chance debcraft can work from a static container provided by the user? I think that the key problem I have is that I want to use a build Debian packages that need no root access and that do not need to install dependencies that need root access, and I want to do that with user privileges only. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy - You do not have my permission to use this email to train an AI -
Re: Tool to build Debian packages not requiring root in containers ?
Hi! ti 7. toukok. 2024 klo 23.01 Charles Plessy kirjoitti: > Le Tue, May 07, 2024 at 08:17:31PM -0700, Otto Kekäläinen a écrit : > > > > Can you give me an example of a package you want to build and what is > > the starting point, and I can tell you what command to issue to > > https://salsa.debian.org/otto/debcraft to achieve it? > > > > It supports running Podman in user mode (=no root permissions needed), > > Hi Otto, > > it looks really great! > > Do you think you can make it work with Singularity/Apptainer instead of > Podman? Our cluster runs only singularity 3.5.2 > (https://docs.sylabs.io/guides/3.5/user-guide/). Debian has version > 4.1.2 in the singularity-container package. > > The conversion of a Docker container to the Singularity format is > simple, and Singularity already mounts most of the local storage to make > it visible and writable from within the container. > I read the docs on how Singularity is able to pull Docker images of Debian Sid and build on top of them, and run and exec just like Docker/Podman. Unfortunately it has its own Containerfile format ( https://docs.sylabs.io/guides/3.5/user-guide/quick_start.html#singularity-definition-files) and the commands have their own syntax. I guess Debcraft could be extended to support it, but that would require at least one Singularity user as frequent contributor to test and develop Singularity-compatibility. The entire code base is shell code. Perhaps you want to take a look if it looks hackable for you?
Re: Tool to build Debian packages not requiring root in containers ?
Le Tue, May 07, 2024 at 08:17:31PM -0700, Otto Kekäläinen a écrit : > > Can you give me an example of a package you want to build and what is > the starting point, and I can tell you what command to issue to > https://salsa.debian.org/otto/debcraft to achieve it? > > It supports running Podman in user mode (=no root permissions needed), Hi Otto, it looks really great! Do you think you can make it work with Singularity/Apptainer instead of Podman? Our cluster runs only singularity 3.5.2 (https://docs.sylabs.io/guides/3.5/user-guide/). Debian has version 4.1.2 in the singularity-container package. The conversion of a Docker container to the Singularity format is simple, and Singularity already mounts most of the local storage to make it visible and writable from within the container. The typical packages that I want to build are the r-bioc-* collection. Together, they represent a dependency graph deep of a dozen of layers, which makes transitions work-intensive. With tools like debcraft I would like to prepare a set of updated packages for which I know that the CI tests pass, and that can be uploaded all together at the same time when I we get green light from the Release team. (And to rebuild all of them if in the meantime the contents of Unstable have changed significantly). Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy - You do not have my permission to use this email to train an AI -
Re: Tool to build Debian packages not requiring root in containers ?
Hi! On Tue, 7 May 2024 at 15:27, Charles Plessy wrote: .. > I want to leverage our cluster to automate as much of the rebuilds as I > can, but could not find the right tool. I tried to run sbuild in a > Singularity image and this failed. However, I do not need the whole > power of engines like sbuild, as none of the packages involved require > root priviledges to build. > > Do you have a suggestion for a tool can run in user mode in a container > image having access to local storage on the host, and that given a > Debian source control file will download the dependencies and build the > package ? Can you give me an example of a package you want to build and what is the starting point, and I can tell you what command to issue to https://salsa.debian.org/otto/debcraft to achieve it? It supports running Podman in user mode (=no root permissions needed), it loop-mounts a local directory (local storage), creates clean build containers on the fly similar to sbuild but is much easier and faster to use. Example of how to build one of your packages with just pointing it at the source git repo: $ debcraft build https://salsa.debian.org/med-team/altree.git Building container 'debcraft-debian-sid' in '/tmp/tmp.brCZRhn2lL/debcraft-container' for downloader use mkdir: created directory '/tmp/tmp.brCZRhn2lL/debcraft-container' STEP 1/10: FROM debian:sid ... $ ls -1 debcraft-build-altree-1715137513.a8c999a+master altree_1.3.2-2_amd64.build altree_1.3.2-2_amd64.buildinfo altree_1.3.2-2_amd64.changes altree_1.3.2-2_amd64.deb altree-dbgsym_1.3.2-2_amd64.deb altree-examples_1.3.2-2_all.deb control.log filelist.log lintian.log First build is a bit slow as it needs to download all the dependencies and create a container, but the second run of 'debcraft build' inside the source directory will be very fast as all container cache is reused.
Tool to build Debian packages not requiring root in containers ?
Hello everybody, I just re-suscribed :) At work I have access to a nice cluster with plenty of nodes rich of 128 cores and 512 Gb RAM. The nodes do not run Debian but Singularity is available for virtualisation (https://en.wikipedia.org/wiki/Singularity_(software)). And in Debian I am part of transitions involving more than 100 packages every 6 months (r-api-bioc-*)… I want to leverage our cluster to automate as much of the rebuilds as I can, but could not find the right tool. I tried to run sbuild in a Singularity image and this failed. However, I do not need the whole power of engines like sbuild, as none of the packages involved require root priviledges to build. Do you have a suggestion for a tool can run in user mode in a container image having access to local storage on the host, and that given a Debian source control file will download the dependencies and build the package ? Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Bug#1070494: ITP: linux-livepatching -- linux livepatching module for Debian
Package: wnpp Severity: wishlist Owner: Emmanuel Arias , Santiago Ruano Rincón X-Debbugs-Cc: debian-devel@lists.debian.org, t...@security.debian.org, debian-ker...@lists.debian.org, debian-...@lists.debian.org, eam...@debian.org * Package name: linux-livepatching Version : 0.0.1 Upstream Contact: Emmanuel Arias , Santiago Ruano Rincón * URL : https://salsa.debian.org/debian/linux-livepatching * License : GPL-2+ Programming Lang: C, Shell scripting, Makefile Description : linux livepatching module for Debian Livepatch modules from the Linux Kernel gives the possibility to apply security fixes to the Kernel while minimizing the need of rebooting the machine. We can list a lot of cases where users cannot or do not want to reboot the system. For instance, while running complex scientific computations, or systems that need to keeping services up and running as much as possible without interruption. But in those cases, the system needs to be stable and secure. Livepatching gives that possibility. For now, this package is a prototype to do a first step to integrate linux livepatching into Debian More than an ITP, this is an Intent to Design an Implement. (CCing debian-lts, since the subject was brought up there some time ago last year, and there may be people interested. However, this is something that should be discussed also with the kernel and the security teams. And as Ben said during an LTS Team meeting, if this idea is implemented in Debian, it must go through unstable first.) Other than having serious fun, the goal of this is ITP is to bring livepatching for security fixes for the kernel that have been available in the Debian releases. For the moment, we are looking to design and implement a first approach, that will live in experimental, while we solve the known and unknown challenges. # State of the art, what others do As readers most be aware, some commercial distributions propose linux live patching. However, none of their services is freely (as in beer or as in speech) available. * RedHat: Introduced Kpatch in 2014. Kpatch is packaged in debian, but its current status is not good. It was removed from bullseye (currently only in buster, sid and experimental) https://www.redhat.com/en/blog/introducing-kpatch-dynamic-kernel-patching * Suse Released kGraft also in 2014, under GPL 2 (and 3 for userspace tools). According to the wikipedia, it aims at being merged into the kernel, and a minimalistic design became part of linux since 4.0. * Ubuntu Livepatching is included in Ubuntu Pro. No public details about the implementation. This is offered as a service where it seems the modules are downloaded directly from a Ubuntu server (not as a package). # Mainline kernel Documentation about livepatching support in the mainline kernel can be found at: https://www.kernel.org/doc/html/latest/livepatch/livepatch.html We aim at building on top of it. # Limitations and known questions As discussed with Salvatore some time ago, there are quite some things to consider: * Triaging issues: who and how issues would be triaged? * Preparing patches: how patches will be selected, backported and etcetera, and maintained as a patch stack for specific kernel versions, during the whole life of a Debian release. We don't intend to add any extra load to the already busy Kernel or Security teams. We aim at maintaining this as a team though. * Testing: what are the requirements for the testing infrastructure? What kind of machines are needed for testing the patches before publishing them? Also: * Patches should be cumulative. How long a specific linux version/package would be supported? The goal of this project is to make it possible to apply a limited set security issues without rebooting. Until when, for how long? * We limit the initial prototype to non-signed images. Secure Boot does not allow to install non-signed modules. * We limit the initial prototype to amd64. The initial prototype is based on binary module packaging, contrary to what other vendors do. We will see how this scale. Comments and questions are welcome in the ITP bug. Cheers, Emmanuel and Santiago P.S. This is the outcome of one of our conversations during the MiniDebConf in Santa Fe, Argentina. Thanks to the people that made it possible :-) signature.asc Description: PGP signature
Correction: New appointments for the Debian Technical Committee: csmall
Dear fellow developers, sorry, the list of CTTE members in my last mail contained Simon McVittie but his term has ended already. Thanks to Simon for his previous work and here comes the corrected text (with no change but the correct list of members). As defined by our constitution (§6.2.2), the Debian Technical Committee has recommended the appointment to the committee of: * Craig Small I agree with their recommendation, and hereby appoint Craig as member of the Technical Committee, effective immediately. For reference, the nominations and votes are recorded at: https://bugs.debian.org/1065810 The Technical Committee now consists of: * Sean Whitton (chair) * Christoph Berg * Helmut Grohne * Matthew Vernon * Matthew Garrett * Stefano Rivera * Timo Röhling * Craig Small Task Description: The Technical Committee is established by the Debian Constitution, section 6. It is the body which makes the final decision on technical disputes in the Debian project. More info about the Technical Committee, including recent decisions, discussion and advice, may be found at: https://www.debian.org/devel/tech-ctte The previous CTTE Appointment mail can be found at: https://lists.debian.org/debian-devel-announce/2023/07/msg0.html Thanks to everyone on the committee who dedicate their time and skills towards Debian as well as good luck for Craig for the new position! Andreas, Debian Project Leader signature.asc Description: PGP signature
Bug#1065810: Info received (New appointments for the Debian Technical Committee: csmall)
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Technical Committee If you wish to submit further information on this problem, please send it to 1065...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 1065810: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065810 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: debian-policy: clarify requirement for use of Static-Built-Using
On Fri, Apr 19, 2024 at 07:59:19AM +0100, Sean Whitton wrote: > Hello Go and Rust packagers, > > On Thu 18 Apr 2024 at 11:29pm +03, Maytham Alsudany wrote: > > > With the increasing amount of programs in Debian that Build-Depend and > > statically link with Golang and Rust libraries, it's important that > > the Debian Policy clearly sets out the requirements for declaring > > these statically-linked libraries. > > I think Maytham is right that updating Policy for this is a priority. > It has been bothering me that misunderstandings of Built-Using have been > proliferating somewhat among newer contributors. See also #999785. > > Could you take a look at his proposed changes to Policy in #1069256, > please, and confirm they successfully reconcile Debian Policy with your > team policies? Speaking for the Rust side - I'd say they match our expected usage of the field. A slight rephrasing of "linked to libraries in other packages" might match it even better, since in Rust's case, we are usually talking about linking to libraries compiled from sources shipped in other packages (librust-X-dev only contains the sources and possibly helper scripts needed to build them, but not the compiled library). But it also covers static linking of native libraries, so the current phrasing matches that. Might be bikeshedding/nitpicky though ;) > I think that we should also include an explanation of why we have chosen > to do this using a new field in d/control like Static-Built-Using. > Policy is meant to be a record of our lessons learned in building a > distribution, and the lessons learned in trying to handle these new > hyper-statically linked language ecosystems seem important. > > My immediate question is why the Haskell and OCaml team's approaches, > were not copied. They seem to work well and don't require a new field. > That seems worth writing down. I am not sure about the details of their approach... are those available somewhere? > Thank you Maytham for your work so far. Thanks to both of you! :)
Accepted rshim-user-space 2.0.20+debian-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 20 Apr 2024 19:26:49 +0200 Source: rshim-user-space Architecture: source Version: 2.0.20+debian-2 Distribution: unstable Urgency: medium Maintainer: da...@debian.org Changed-By: Taihsiang Ho (tai271828) Closes: 1064920 Changes: rshim-user-space (2.0.20+debian-2) unstable; urgency=medium . * debian/rules: update CFLAG for FTBFS on armhf (Closes: #1064920) * debian/rules: conditionally append for armhf arch * debian/rules: apply the best practice of DEB_BUILD Checksums-Sha1: 4a346ccbdf8379f5bd7a55e1c33af218c612f1b5 2044 rshim-user-space_2.0.20+debian-2.dsc 15432a2092ac8956230f9e02f3efca0064a209ad 2908 rshim-user-space_2.0.20+debian-2.debian.tar.xz 45b1e36d2f8ea34541ce3c64bb83f2091dac6dba 7976 rshim-user-space_2.0.20+debian-2_source.buildinfo Checksums-Sha256: db49e5a77fc0691a005c06f30743920f16067426bf19f6352e7cebe9831528dd 2044 rshim-user-space_2.0.20+debian-2.dsc 7f0280d9997b945d780e949d8e18f4c80a52009aa76286e9a1a44a80fc0b1eec 2908 rshim-user-space_2.0.20+debian-2.debian.tar.xz b6e8680d153428381f1161cc0f24beb33d9dcbe0e2690f699a2d2ef2908b66a6 7976 rshim-user-space_2.0.20+debian-2_source.buildinfo Files: b95b4cfe47530478e49244a96fd736ea 2044 admin optional rshim-user-space_2.0.20+debian-2.dsc 65fb8723a7e9d4691bb5641d8655cc47 2908 admin optional rshim-user-space_2.0.20+debian-2.debian.tar.xz 44df61d4e68cb7b31b1ae480d6179ba9 7976 admin optional rshim-user-space_2.0.20+debian-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEECfR9vy0y7twkQ+vuG/g8XlT8hkAFAmYn75sRHGRhbm5mQGRl Ymlhbi5vcmcACgkQG/g8XlT8hkAIKA/6A1CAd+L4CvHg/csTdYdCw0UK4udHrnGD Gf2Iu7mIkGXVTvqQJc5gZevEN75Nxx9LOxYu6hL6EPSEDg8wj4wMzhlrDM2Tsv2n 9z4PQuQ8Wp5qx+YQBnh8OnQ2hMAxqxeHb98NhZYmev/zo/jJz5XLxAswsfa4zRRu fOBvr4INO9lRRDlp160JOBoUY1KnzEFyTKluG8ur5vCabif3PNEJvlnJW5diz2MD gx8xmykZ0WvibGmXJNF8Cj4TA56JF2cl521BLHGvdsGzJ4FIeA34gPzn5W6W82ur DsXWj3HauPoYFHoFVMudyqjG/2dbEi+3/So0v7WfJin3akqZJ/+zock5xsFwfjyb IeUR999yysXUrIf8FBO2x1LtozMVciPfTqM/ZaeWlsaJqhKi3rmZ2f2p9cGoLciB 95A3FiATk990qaOm2mF+8cryXUiD0wki4ofBVo+q2Ka3tpKNltSamdn5ycmEUvxG U4wdfMPt57PqgeROhBiauotST30CdFWcVJBVZ+Pusc7iEgHTFgN44P76hHq6XtS5 q8wF2WQXJdBApqueM56J4T4EPEj0Th5DfcqRxCnzC4m9aLvFO9mlrqZ1TzuPGVnL ipTfX3JbsmTYU37R9qkCg0YJNLAwQJ6/mQEHmYtCE88ss//3X4Glu1EtRcnkUacT YWl8VYQQ9vM= =SOVQ -END PGP SIGNATURE- pgp0wU_XlUA6m.pgp Description: PGP signature
Re: Please block glj....@gmail.com from Debian lists [Re: UOC and Britsh Council lawsuit]
On 22/4/24 21:29, Steve Langasek wrote: On Mon, Apr 22, 2024 at 05:11:39PM +0200, José Luis González González wrote: I sent 5 minutes ago an email to "Plaza de Castilla *courts*" setting ^^^ BS. It just doesn't work like this. A regular citizen can't communicate with a Court by email. You can't even interact with a case proceedings until you are a party to a particular lawsuit. it crystal clear that it was a long time ago the lawsuit to Universitat Oberta de Catalunya and British Council had to be solved. "Kinda or not" -- Parkinson's Law: Work expands to fill the time alloted to it.
Please block glj....@gmail.com from Debian lists [Re: UOC and Britsh Council lawsuit]
On Mon, Apr 22, 2024 at 05:11:39PM +0200, José Luis González González wrote: > I sent 5 minutes ago an email to "Plaza de Castilla *courts*" setting > it crystal clear that it was a long time ago the lawsuit to Universitat > Oberta de Catalunya and British Council had to be solved. > > "Kinda or not" > -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Accepted ncrack 0.7+debian-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 22 Apr 2024 08:59:25 +0700
Source: ncrack
Architecture: source
Version: 0.7+debian-6
Distribution: unstable
Urgency: medium
Maintainer: Debian Security Tools
Changed-By: Arnaud Rebillout
Closes: 1065799
Changes:
ncrack (0.7+debian-6) unstable; urgency=medium
.
[ Vladimir Petko ]
* d/p/{implicit-declaration-in-configure.patch, implicit-declaration-
xmalloc.patch}: add missing headers and defines to resolve -
Werror=implicit-function-declaration build failures (Closes:
#1065799).
Checksums-Sha1:
ca7dcf02216a45c8604a473b6313856476ef745e 1981 ncrack_0.7+debian-6.dsc
b86cbe496f10b1e91698aa47241c79deaf1406c1 18368
ncrack_0.7+debian-6.debian.tar.xz
dc71067d66e5a508cea23175be51ea42f12613f1 6521
ncrack_0.7+debian-6_source.buildinfo
Checksums-Sha256:
60a6ac3348db68e6305bfb4a5afe7051ed6b3f83b050ae03282655580fab29e3 1981
ncrack_0.7+debian-6.dsc
94aa57df05fea534664dcb93f70880a22e80cbc144fda2254c89d65030bb2f1f 18368
ncrack_0.7+debian-6.debian.tar.xz
5ef07a634dcfb5789e2fe1078a42f1ec297e2f28f94f86ab4ce0c6d052041c36 6521
ncrack_0.7+debian-6_source.buildinfo
Files:
9a4414d222032421e81621d040cdfaf6 1981 net optional ncrack_0.7+debian-6.dsc
4214d0ed4ac01aec244ffc0412d8a385 18368 net optional
ncrack_0.7+debian-6.debian.tar.xz
678cae5ed5c62d5638955d07396d486c 6521 net optional
ncrack_0.7+debian-6_source.buildinfo
-BEGIN PGP SIGNATURE-
iQJFBAEBCgAvFiEE0Kl7ndbut+9n4bYs5yXoeRRgAhYFAmYlxNARHGFybmF1ZHJA
a2FsaS5vcmcACgkQ5yXoeRRgAhZdCxAAkY7IJTo0vtd82E4ddzeKtS2AxyGaTGbR
fXukJFYMmyjRAO/lZpd3RM+1j0KDgbG6eZr+gAv/+YFP+WOJK1gwSoiTBJcAZyWC
LW0Re6gl/WuxSDOMRuiEd2AS7CtMfvlTmfZmTCEtnnAcHUuE2HYH33SsoQYcp9ys
hiep8AdtbLG8UbEoCU7hCHXStqXcAeZPEWRtiCeIvsla1pczmIbUCQVf7wrS2bN/
zIWO/rRsdH7GY1pKW6T0Cz+lb6MU17bBs9wZBPxMzIDBc1005FqayU4JAANpUpq9
xmZv4koNCjmEOrFrfKtfuyB+C0xoAVigC8rWOgJmmO8F6DK81+dMoVGtP/DgeqKr
niDlY+nHdFxhjgV8/b567P3VMcCXDy5dY7Ebb9+jOrelaY/svW8Mq4Sa01lqgY2o
NW1mXGXFwqZou6s0lr5P/oBGQS+ttoRmgaRaYb7sQEUXHlSiyJNLKNMekILRHKcx
EuTwn+wwcufIhyDKze5vGNIKUjDQl6dRnzPfBH66JaEYhY6dwG6rFr6S8C33QmAt
mj1yf0pcM30tCZjH7c3i6HGkkt9PDIhOvnuoJnwHy5/mgEw5Nuy+bGlBT30VziL7
TrFsd0RlTEjSBfYMDr0kxEs36nEOIaDv7DD7oE6OwhETWFOBBiq5BgQY6rJMwV45
7E0Y/gUn12M=
=GkUR
-END PGP SIGNATURE-
pgpY6tTSZ9Q0S.pgp
Description: PGP signature
Results for Debian Project Leader 2024 Election
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sat Apr 20 00:01:05 2024
Option 1 "Andreas Tille"
Option 2 "Sruthi Chandran"
Option 3 "None of the above"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2 3
=== === ===
Option 1 201 293
Option 2135 280
Option 3 6466
Looking at row 2, column 1, Sruthi Chandran
received 135 votes over Andreas Tille
Looking at row 1, column 2, Andreas Tille
received 201 votes over Sruthi Chandran.
Option 1 Reached quorum: 293 > 46.3788745012209
Option 2 Reached quorum: 280 > 46.3788745012209
Option 1 passes Majority. 4.578 (293/64) >= 1
Option 2 passes Majority. 4.242 (280/66) >= 1
Option 1 defeats Option 2 by ( 201 - 135) = 66 votes.
Option 1 defeats Option 3 by ( 293 - 64) = 229 votes.
Option 2 defeats Option 3 by ( 280 - 66) = 214 votes.
The Schwartz Set contains:
Option 1 "Andreas Tille"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 1 "Andreas Tille"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"Andreas Tille\n4.58" [ style="filled" , color="powderblue", shape=egg,
fontcolor="NavyBlue", fontname="Helvetica", fontsize=10 ];
"Andreas Tille\n4.58" -> "Sruthi Chandran\n4.24" [ label="66" ];
"Andreas Tille\n4.58" -> "None of the above" [ label="229" ];
"Sruthi Chandran\n4.24" [ style="filled" , fontname="Helvetica", fontsize=10
];
"Sruthi Chandran\n4.24" -> "None of the above" [ label="214" ];
"None of the above" [ style="filled" , shape=diamond, fontcolor="Red",
fontname="Helvetica", fontsize=10 ];
}
pgp4ELkjaQSw4.pgp
Description: PGP signature
Re: Debian
On Fri, 19 Apr 2024 10:09:26 +0200 José Luis González González wrote: > On Fri, 19 Apr 2024 09:59:57 +0200 > José Luis González González wrote: > > > On Fri, 19 Apr 2024 09:39:02 +0200 > > José Luis González González wrote: > > > > > Good day, > > > > > > There's an issue with the dash package and maintainer, and mutt as well. > > > > > > I even tried to reach dash maintainer privately and he is not even on > > > the package's field (queried by dpkg), there's someone who is obviosly > > > fake instead: Andrej Shadura > > > > > > The issues with dash so far, that I know, is the shell was bash when I > > > switched to dash because of bash's Stallman's "Eight Megabytes And > > > constantly Swapping *And Spying And Boycotting*", and after I enabled > > > "fingerd" in my personal website's server and some time passed the > > > package returned to dash, however there's at least one obvious back > > > door, and program is going the way of bash, preventing from using the > > > Operating system. This has happened before, thrice recently. > > > > > > Additionally the files on /usr/share/doc/dash are wrong. > > > > > > The main issues of mutt that I know so far is the documentation is > > > useless for what I needed, which is using the program, and the package, > > > that was installed, is missing from my computer, besides the maintainer > > > being subversive as well. > > > > > > If this is not solved I will cease to stop using Debian and Debian will > > > die. > > > > > > "Kinda or not" > > > > The problems that I had in 2020 were life or death security problems > > that prevented me to use my computer at all for almost one year. I even > > lost my computer, had to buy another one in 2021 and reinstall > > everything, with severe problems, that even involved having to go > > several times to public library, and recording "the" DVD first disc > > with non-free firmware adding it selectively from USB didn't work. > > > > The problems in 2023 involved ceasing being able to use the computer > > because of innumerable trojans, and having to resort to the public > > library again because of the DVD that I had recorded with Debian 10.5 > > becoming subversive when I needed it to rescue my operating system and > > turning as 11.5, which is not what I wanted at all. I ended up having > > to record 11.5, install it, and even upgrade to 12. > > There are similar issues with boa and dhttpd, and it seems Apache is going > that way. Debian is finally unusable for me.
Re: Debian
You've written a lot of text here in a few mails, replying to yourself several times. This is not a positive pattern. On Fri, Apr 19, 2024 at 11:58:18AM +0200, José Luis González González wrote: >> There are similar issues with boa and dhttpd, and it seems Apache is going >> that way. > >nvi adds to the subversive ones, with bash, etc. What on earth do you mean by "subversive" here?? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Re: Debian
On Fri, 19 Apr 2024 10:09:26 +0200 José Luis González González wrote: > On Fri, 19 Apr 2024 09:59:57 +0200 > José Luis González González wrote: > > > On Fri, 19 Apr 2024 09:39:02 +0200 > > José Luis González González wrote: > > > > > Good day, > > > > > > There's an issue with the dash package and maintainer, and mutt as well. > > > > > > I even tried to reach dash maintainer privately and he is not even on > > > the package's field (queried by dpkg), there's someone who is obviosly > > > fake instead: Andrej Shadura > > > > > > The issues with dash so far, that I know, is the shell was bash when I > > > switched to dash because of bash's Stallman's "Eight Megabytes And > > > constantly Swapping *And Spying And Boycotting*", and after I enabled > > > "fingerd" in my personal website's server and some time passed the > > > package returned to dash, however there's at least one obvious back > > > door, and program is going the way of bash, preventing from using the > > > Operating system. This has happened before, thrice recently. > > > > > > Additionally the files on /usr/share/doc/dash are wrong. > > > > > > The main issues of mutt that I know so far is the documentation is > > > useless for what I needed, which is using the program, and the package, > > > that was installed, is missing from my computer, besides the maintainer > > > being subversive as well. > > > > > > If this is not solved I will cease to stop using Debian and Debian will > > > die. > > > > > > "Kinda or not" > > > > The problems that I had in 2020 were life or death security problems > > that prevented me to use my computer at all for almost one year. I even > > lost my computer, had to buy another one in 2021 and reinstall > > everything, with severe problems, that even involved having to go > > several times to public library, and recording "the" DVD first disc > > with non-free firmware adding it selectively from USB didn't work. > > > > The problems in 2023 involved ceasing being able to use the computer > > because of innumerable trojans, and having to resort to the public > > library again because of the DVD that I had recorded with Debian 10.5 > > becoming subversive when I needed it to rescue my operating system and > > turning as 11.5, which is not what I wanted at all. I ended up having > > to record 11.5, install it, and even upgrade to 12. > > There are similar issues with boa and dhttpd, and it seems Apache is going > that way. nvi adds to the subversive ones, with bash, etc.
Accepted debian-keyring 2024.03.24 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 24 Mar 2024 09:03:13 + Source: debian-keyring Architecture: source Version: 2024.03.24 Distribution: unstable Urgency: medium Maintainer: Debian Keyring Maintainers Changed-By: Jonathan McDowell Changes: debian-keyring (2024.03.24) unstable; urgency=medium . [ Gunnar Wolf ] * Replace 0xE33E61A2E9B8C3A2 with 0xDD839B748F10AD4D (Gwen Weinholt) (RT #9447) . [ John Sullivan ] * Add new DD key 0xC6D50A4188C70E43 (Patrick Winnertz) (RT #9450) * Add new DM key 0x0B8D177155F6646E (Jean Charles Delépine) (RT #9448) * Add new DM key 0x6594486E01294708 (Guilherme Puida Moreira) (RT #9464) . [ Jonathan McDowell ] * Add new DM key 0x13498F032CCFE9DA (Tobias Heider) (RT #9451) * Add new DM key 0x1FBF96BB06B28691 (Juri Grabowski) (RT #9456) * Replace 0xE3E0A1C286B963EA with 0xB490E3DF337F3213 (Wolfgang Martin Borgert) (RT #9453) * Import changes sent to keyring.debian.org HKP interface: * 0x033C4CA276024834 Athos Coimbra Ribeiro sig:3 * 0x0B00FB6CEBE2D002 Ulises Vitulli sig:3 * 0x1762E0227034CF84 William Blough sig:7 * 0x1ABFA401CCAA707A Patryk Cisek sig:3 * 0x1E625DF64972FF9A Filip Hroch sig:1 * 0x22AFD1C0DAC8BC06 Santiago Ruano Rincón sig:7 * 0x2404C9546E145360 Gunnar Wolf sig:3 * 0x2834516CDA1E968D Håvard Flaget Aasen sig:5 * 0x293010013344 Gergely Riskó sig:2 * 0x2E7C0367B9BFA089 Scarlett Moore sig:8 * 0x3116BA5E9FFA69A3 Paul Wise sig:3 * 0x3357018EBC0A Fabian Grünbichler sig:1 * 0x47DAC12E5D3610E6 Yogeswaran Umasankar sig:1 * 0x4AD58E3068E669E2 Alexis Bienvenüe sig:2 * 0x4E142C216BDFC613 Jeremy Paul Arnold Sowden uid:1 sig:3 * 0x5291703BFA09034E Carlos Henrique Lima Melara sig:1 * 0x53FE7BBDA68910FC Ross Gammon sig:2 * 0x55E9F9F7AC1C443F Marc Dequènes sig:7 * 0x56A0D81F9F782DA9 Ricardo Ribalda Delgado uid:1 sig:1 * 0x57930DAB0B86B067 Joost van Baal sig:3 * 0x5ACE8D6E0C14A470 Luke Faraone sig:50 * 0x5B924EE310055CD3 Marcelo Jorge Vieira sig:4 * 0x5D5F6C020398A60A Peter Wienemann sig:1 * 0x634F4BD1E7AD5568 Enrico Zini sig:4 * 0x648047B2D723891C Jean-Philippe MENGUAL sig:4 * 0x6C6ACD6417B3ACB1 Roger Shimizu sig:6 * 0x6F31F7545A885252 Nicolas Dandrimont sig:4 * 0x72CF8E5E25B4C293 Matthias Ulrichs uid:2 sig:9 * 0x7541CFAAFC35EACF Stephen Gelman sig:6 * 0x766C8B3DDE6699FE Thomas Ward sig:3 * 0x793CF67E8F0D11DA Étienne Mollier sig:3 * 0x83016014251D1DB0 Carsten Schoenert sig:1 * 0x88237A6A53AB1B2E Harlan Lieberman-Berg sub:2 sig:7 * 0x90F0C9B18A6B4A19 Evangelos Ribeiro Tzaras sig:2 * 0x97A0FA0FC8F2DE45 Stefano Rivera sig:3 * 0x9C5C99EB05BD750A Paul Gevers sig:4 * 0x9D0470BDA6CDC457 Neutron Soutmun sig:6 * 0xB82A217AFDFE09F2 David Prévot sig:3 * 0xC21D9AD423A39727 Blair Noctis sig:6 * 0xC31F4FD949AB2B6C Dominique Dumont uid:1 sig:9 * 0xC32A4D0858F5A6EA Alper Nebi Yasak sig:1 * 0xC7F7F9660D82A682 Laurent Bigonville sig:3 * 0xCC65B0CDEC275D5B ChangZhuo Chen sig:1 * 0xD15D313882004173 Russ Allbery sig:1 * 0xD36F769BC11804F0 Theodore Ts'o sig:3 * 0xD73CF638C53C06BE Simon Josefsson sig:4 * 0xDECA0C9D30ED9FE3 Elana Hashman sig:4 * 0xE197012676B9B739 David Kalnischkies sig:6 * 0xE267B052364F028D NIIBE Yutaka sig:2 * 0xED63B6125A1D1561 Dima Kogan sig:2 * 0xEEED479E6CECF707 Ananthu C V sig:10 * 0xF15DCE5316051F27 Sergio Almeida Cipriano Junior sig:2 * 0xFA9DEC5DE11C63F1 Emmanuel Arias sig:1 Checksums-Sha1: aaa9312065a16a2bcaa7b8262328e488a5cb39b7 1211 debian-keyring_2024.03.24.dsc 3745c8f424458057d871139d3d5e1c0ae5036342 34633088 debian-keyring_2024.03.24.tar.xz b522d7f9a525dec957d697336f23dc3c4bd0301d 6502 debian-keyring_2024.03.24_amd64.buildinfo Checksums-Sha256: 01a0f254ee5e359352b24bab20d04e6fc388f5be5cd78577a2cadc0043cf7bcf 1211 debian-keyring_2024.03.24.dsc 87ce505e5c8a86fe10c3aee46f241e562a287731d56a3642ef9d6454df6a3fa4 34633088 debian-keyring_2024.03.24.tar.xz d7a09601058ea770c48fb7db4210b97f0c68f8c1f6c10b7a9ae3831819995db4 6502 debian-keyring_2024.03.24_amd64.buildinfo Files: 4f6afa292d8e5c60a0239ce3391cc315 1211 misc optional debian-keyring_2024.03.24.dsc 55fac00e0e13abbe60c1e9824ea4441e 34633088 misc optional debian-keyring_2024.03.24.tar.xz 5165f61c429de6976f083b322a1ac29e 6502 misc optional debian-keyring_2024.03.24_amd64.buildinfo -BEGIN PGP SIGNATURE- iHUEARYKAB0WIQSAYP1ALvrBQa1odmMPwJuF4mk8PAUCZiImJwAKCRAPwJuF4mk8 PFvUAQDgNZT6gqT95tCYMaJc9AplmDTGu4IrMMiZ0IHhtsg1OAEAxzafrCKPoLwr Iw+ve71Cqtvzl3rexAECuEkpqFLJpww= =/YXt -END PGP SIGNATURE- pgpu34IuXDvxE.pgp Description: PGP signature
Re: Debian
On Fri, 19 Apr 2024 09:59:57 +0200 José Luis González González wrote: > On Fri, 19 Apr 2024 09:39:02 +0200 > José Luis González González wrote: > > > Good day, > > > > There's an issue with the dash package and maintainer, and mutt as well. > > > > I even tried to reach dash maintainer privately and he is not even on > > the package's field (queried by dpkg), there's someone who is obviosly > > fake instead: Andrej Shadura > > > > The issues with dash so far, that I know, is the shell was bash when I > > switched to dash because of bash's Stallman's "Eight Megabytes And > > constantly Swapping *And Spying And Boycotting*", and after I enabled > > "fingerd" in my personal website's server and some time passed the > > package returned to dash, however there's at least one obvious back > > door, and program is going the way of bash, preventing from using the > > Operating system. This has happened before, thrice recently. > > > > Additionally the files on /usr/share/doc/dash are wrong. > > > > The main issues of mutt that I know so far is the documentation is > > useless for what I needed, which is using the program, and the package, > > that was installed, is missing from my computer, besides the maintainer > > being subversive as well. > > > > If this is not solved I will cease to stop using Debian and Debian will > > die. > > > > "Kinda or not" > > The problems that I had in 2020 were life or death security problems > that prevented me to use my computer at all for almost one year. I even > lost my computer, had to buy another one in 2021 and reinstall > everything, with severe problems, that even involved having to go > several times to public library, and recording "the" DVD first disc > with non-free firmware adding it selectively from USB didn't work. > > The problems in 2023 involved ceasing being able to use the computer > because of innumerable trojans, and having to resort to the public > library again because of the DVD that I had recorded with Debian 10.5 > becoming subversive when I needed it to rescue my operating system and > turning as 11.5, which is not what I wanted at all. I ended up having > to record 11.5, install it, and even upgrade to 12. There are similar issues with boa and dhttpd, and it seems Apache is going that way.
Debian
On Fri, 19 Apr 2024 09:39:02 +0200 José Luis González González wrote: > Good day, > > There's an issue with the dash package and maintainer, and mutt as well. > > I even tried to reach dash maintainer privately and he is not even on > the package's field (queried by dpkg), there's someone who is obviosly > fake instead: Andrej Shadura > > The issues with dash so far, that I know, is the shell was bash when I > switched to dash because of bash's Stallman's "Eight Megabytes And > constantly Swapping *And Spying And Boycotting*", and after I enabled > "fingerd" in my personal website's server and some time passed the > package returned to dash, however there's at least one obvious back > door, and program is going the way of bash, preventing from using the > Operating system. This has happened before, thrice recently. > > Additionally the files on /usr/share/doc/dash are wrong. > > The main issues of mutt that I know so far is the documentation is > useless for what I needed, which is using the program, and the package, > that was installed, is missing from my computer, besides the maintainer > being subversive as well. > > If this is not solved I will cease to stop using Debian and Debian will > die. > > "Kinda or not" The problems that I had in 2020 were life or death security problems that prevented me to use my computer at all for almost one year. I even lost my computer, had to buy another one in 2021 and reinstall everything, with severe problems, that even involved having to go several times to public library, and recording "the" DVD first disc with non-free firmware adding it selectively from USB didn't work. The problems in 2023 involved ceasing being able to use the computer because of innumerable trojans, and having to resort to the public library again because of the DVD that I had recorded with Debian 10.5 becoming subversive when I needed it to rescue my operating system and turning as 11.5, which is not what I wanted at all. I ended up having to record 11.5, install it, and even upgrade to 12.
Re: debian-policy: clarify requirement for use of Static-Built-Using
Hello Go and Rust packagers, On Thu 18 Apr 2024 at 11:29pm +03, Maytham Alsudany wrote: > With the increasing amount of programs in Debian that Build-Depend and > statically link with Golang and Rust libraries, it's important that > the Debian Policy clearly sets out the requirements for declaring > these statically-linked libraries. I think Maytham is right that updating Policy for this is a priority. It has been bothering me that misunderstandings of Built-Using have been proliferating somewhat among newer contributors. See also #999785. Could you take a look at his proposed changes to Policy in #1069256, please, and confirm they successfully reconcile Debian Policy with your team policies? I think that we should also include an explanation of why we have chosen to do this using a new field in d/control like Static-Built-Using. Policy is meant to be a record of our lessons learned in building a distribution, and the lessons learned in trying to handle these new hyper-statically linked language ecosystems seem important. My immediate question is why the Haskell and OCaml team's approaches, were not copied. They seem to work well and don't require a new field. That seems worth writing down. Thank you Maytham for your work so far. -- Sean Whitton signature.asc Description: PGP signature
Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
Package: debian-policy Version: 4.7.0.0 Severity: normal X-Debbugs-Cc: debian-devel@lists.debian.org Dear Policymakers, With the increasing amount of programs in Debian that Build-Depend and statically link with Golang and Rust libraries, it's important that the Debian Policy clearly sets out the requirements for declaring these statically-linked libraries. Currently, section 7.8 of the policy is a bit vague regarding stating static libraries. It begins with saying: Some binary packages incorporate parts of other packages when built but do not have to depend on those packages. Examples include linking with static libraries or incorporating source code from another package during the build. It then states: [The Built-Using field] should be used only when there are license or DFSG requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies. This makes it seem that Built-Using shouldn't be used to declare statically-linked dependencies, though that is not the case[1]. In early 2022, Guillem added support for a new Static-Built-Using field to dpkg, encouraging packagers to use it over Built-Using to specify statically-linked dependencies [2]. The commit message states the following: This field mimics the previous Built-Using field semantics, but is specifically intended for shadow dependencies stemming from static builds. In Debian, the Rust and Go teams agreed to use this language agnostic field, instead of one for each of the languages. This means it can be easily supported by dpkg, and can be used by other languages and run-times. This was also added to the deb-control(5) manpage, specifically differentiating it from Built-Using as a field to be used "for static building purposes (for example linking against static libraries, builds for source-centered languages such as Go or Rust[...])". The proposed change is to clarify and formally mandate the requirement to declare statically-linked libraries used to build packages containing binaries in Static-Built-Using. Attached is a draft patch of the proposed change. Feedback is welcome! Kind regards, Maytham [1]: The Go team requires that Built-Using is specified for packages containing binary programs, and this is evident in the templates outputted by dh-make-golang. (This is being migrated over to Static-Built-Using, the correct field for this purpose.) Similarly, the Rust team also requires that Static-Built-Using are specified, as evident in debcargo's output when generating d/control files. (X-Cargo-Built-Using is currently being used but will soon be replaced by Static-Built-Using with the next upload.) The Rust team also uses Built-Using when required, where dh-cargo/cargo will check for and collate a list of any packages with copyleft licenses in the dependency tree that require accompanying source. [2]: https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=16c412439c5eac5f32930946df9006dfc13efc02 https://lists.debian.org/debian-devel-changes/2022/03/msg03007.html From a9b9c513ae985fddca1bf9cceadce6d3d620ce53 Mon Sep 17 00:00:00 2001 From: Maytham Alsudany Date: Thu, 18 Apr 2024 22:29:01 +0300 Subject: [PATCH] Require use of Static-Built-Using to declare statically-linked libraries --- policy/ch-relationships.rst | 36 ++-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst index fb9dae8..31a1757 100644 --- a/policy/ch-relationships.rst +++ b/policy/ch-relationships.rst @@ -666,8 +666,8 @@ dependency to install. .. _s-built-using: -Additional source packages used to build the binary - ``Built-Using`` -- +Additional source packages used to build the binary - ``Built-Using`` and ``Static-Built-Using`` + Some binary packages incorporate parts of other packages when built but do not have to depend on those packages. Examples include linking @@ -676,6 +676,9 @@ package during the build. In this case, the source packages of those other packages are part of the complete source (the binary package is not reproducible without them). +``Built-Using`` +~~~ + When the license of either the incorporated parts or the incorporating binary package requires that the full source code of the incorporating binary package be made available, the ``Built-Using`` field must list @@ -710,6 +713,35 @@ requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies. +``Static-Built-Using`` +~~ + +Whe
Accepted dsniff 2.4b1+debian-33 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 17 Apr 2024 14:53:41 +0700 Source: dsniff Architecture: source Version: 2.4b1+debian-33 Distribution: unstable Urgency: medium Maintainer: Debian Security Tools Changed-By: Arnaud Rebillout Closes: 1066431 Changes: dsniff (2.4b1+debian-33) unstable; urgency=medium . * Add missing libnsl-dev to Build-Depends (Closes:#1066431). Checksums-Sha1: e5832781b5fd29e352a26ddbc483367cf664aa05 2127 dsniff_2.4b1+debian-33.dsc ec4fe6359605a2a7ea44f7e63edf0a847b59f11d 30960 dsniff_2.4b1+debian-33.debian.tar.xz 489225d93d5a0d25edd8147f0e8c949583e72db6 6506 dsniff_2.4b1+debian-33_source.buildinfo Checksums-Sha256: 1162c1df7c59a30df0431c17e214c7a360c4369d8556f94596e28686a0488011 2127 dsniff_2.4b1+debian-33.dsc 105549327ba5dcca8ecf77b1eb4a201bfccbef6cf504905cd705a78fbae2c984 30960 dsniff_2.4b1+debian-33.debian.tar.xz 939ae98abb84b45708e56cf23a5168241a448981e8a300212d12b019933e3c09 6506 dsniff_2.4b1+debian-33_source.buildinfo Files: 0eff5f87516ec7e751c3f9f4df821524 2127 net optional dsniff_2.4b1+debian-33.dsc a1a1aa84bc550b2d54466fdf0cb20f14 30960 net optional dsniff_2.4b1+debian-33.debian.tar.xz 2ebd9997a4a78edff4b0d9226cea4c82 6506 net optional dsniff_2.4b1+debian-33_source.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEE0Kl7ndbut+9n4bYs5yXoeRRgAhYFAmYfgNARHGFybmF1ZHJA a2FsaS5vcmcACgkQ5yXoeRRgAhaJ5A/9HCqI3wbSZgJ9awv3sXM6k8SHG9mWD9hY EMs2Z7Occm1CxSDkGte1o7DHaqJzFQnHk4ZnTd54xhergotm/lE9b6gBAHUCDpq0 XZr4GXi7J7AZFYhtRVSUmpEGQH4C/wn1hhD+9Yf1bYB4bRkyCVeEDlSHcCW+v4yU 7cQu6LsCgkY75UoU1qK5U43ymDFfkGQasRR6Xk5qS24mGWFyOirLd1ikaaL0ihKE OxagtGObjMuqX5HU629FEBjoQMiXrcWl6KajxGxd7jint6ytX+ISmfSUNUN0C1IV 1oXLVhQoM/jrBQRZEYb6E6joE8NOMcEaqhSqxVvGRkCBbuU7pUBjR//Xxm5jqFXB cWSzG9cAZmeLTriHx4KDNZz0tDNCPSU7cuwufNF5h9vcXnax66rbB2soQDteXlK6 YyodotX7JpY7vMnVT8pUcyqMhNjj+o5jTQnFF4Lry/v1KuXiDGgWR04CYZtwN8sy MAtR0Aj3ZL+dMFq/cgQ8CpmS542Nll0SPvQ8asgCdHkl7MQvgtsgsl+7myWNMuZs iLxN9wn6pgGVQlirFpsKG9mUvwhHK/Hjce4mI89bH9surtFRJsr+4V9rrpbAGDEe ekV6Jtx95G5sZRjsdKoei8EVGQm6lHocUVi5N9wrfRPJuxo2BCUlXWkBf9sSqFGs Mqf4u3Tf2JA= =IZWz -END PGP SIGNATURE- pgpFrWuTAerOr.pgp Description: PGP signature
Bug#1068823: Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device"
On Thu, Apr 11, 2024 at 04:46:03PM +, mYnDstrEAm wrote: > With the two commands above one can already split it up into two steps but > especially the second command still requires a lot of disk space. I am going to assume that your "a lot of disk space" stems from the *.deb files that are downloaded. If so, you can e.g. attach an USB disk/ drive and mount it e.g. under /media/apt-archives Tell apt to use that directory instead of /var/cache/apt/archives, e.g.: apt upgrade -o dir::cache::archives=/media/apt-archives (for some more free MBs you could 'apt clean' and then move dir::cache elsewhere, but for that you need to create some directories in the target location and the binary caches are not THAT large to make it really worthwhile in practice. Similar for other files like /var/lib/apt aka dir::state::lists) Instead of an USB drive you could do the same with e.g. an SD card, drop them into RAM (if your device has surprisingly more RAM than disk) or even use a network share (NFS, sshfs, … you name it). The filesystem is not usually a concern (as in: even fat32 should work given we encode away the : in epochs). Note that whoever has write access to the files on the storage (or in case of unencrypted transfer, also everyone who can meddle with transfer over the network) could use that to attack you as apt (well, apt will casually check them first, but after that and dpkg, who actually interacts with them the most) will assume that the files in /var/cache/apt/archives (or where ever else you stored them and told apt to use them) are valid & trusted. Note also that apt uses for its space check statvfs(3) f_bavail, as in, depending on how you configured your disk, it should have a couple of additional free blocks in reserve (typically 5%, see tune2fs(8) -m). If you know what you are doing, you could decrease that value. Note that the value apt displays is only an estimate, powered by what the individual packages claim (via dpkg), which is an estimate. Also, if you happen to have a 2GB installed, the upgrade will roughly take an additional 2GB as dpkg would first extract the new files along the old ones and then replace them in one swoop – so for a bit, you have that package installed two times. Multiple this by group size, divide by unchanged files and sprinkle some salt over it for flavour. Predictions are hard, especially about the future. I would in general not recommend to try approaches like upgrading individual packages as that easily leads unsuspecting users into situations that nobody else has encountered before: aka bugs in packages that nobody else will encounter as they are either hidden by the involved set usually being upgraded together as intended™ or – which tends to be even worse – the breakage is known but ignored on purpose as the solution is far worse than the problem (at least for everyone doing upgrades the normal way – example: usrmerge). Also, but that is just an aside, people grossly overestimate how easy it is for packages to be upgraded individually (compare: t64 testing migration). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068823: Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device"
On Thu, 2024-04-11 at 16:46 +, mYnDstrEAm wrote:
>
> For example, I think a good approach to this would be something like
> this (if the user is low on root partition disk space):
> 1. asking for *at least* 400MB to be available
> 2. if a parameter for stepwise is set or it detected low free disk
> space:
> 3. downloading the first 300 MB or so of packages
> 4. installing these
> 5. deleting the cached packages from /var/cache/apt/archives/
> 6. downloading the next batch up to the storage limit set at start
> 7. and so on (without exiting in-between)
>
quick and dirty and not tested:
while apt -s upgrade | grep '^Inst' | head -1 | awk '{print $2}' |
xargs apt install; do apt clean; done
Use head -10 or whatever fits for more/less packages.
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
