Re: MBF: valgrind-if-available
On Sun, 2022-02-27 at 03:40 +0100, Adam Borowski wrote: > Among others, "command -v" [...] > * built-ins get reported as available. And busybox has even "dpkg" > built-in, with a pretty bad implementation. Like this? +--- | % which which | which: shell built-in command +--- I suggest to implement a new utility named `/usr/bin/posix-which2` utility if you do not want that ;-) (Only after proper standardization of course.) Ansgar
Bug#976402: Proposed official virtual packages - todo and todo.txt
David Steele writes: > On Wed, Dec 9, 2020 at 3:21 AM Ansgar wrote: >> Given topydo just provides/conflicts with devtodo to provide the "todo" >> binary, this seems to violate Policy 10.1 "Binaries" unless they provide >> the same functionality. [...] > From where I stand, I would expect the Policy to use a different word to > indicate something along the lines of greater API compatibility. I have no > additional background information, though. Are you aware of any expansions > on this text, or of any precedents that could help with a consensus process? My understanding is that different alternatives for a binary in PATH should provide a compatible command-line interface as one might not know which alternative is installed. See for example the description of x-terminal-emulator in Policy 11.8.3 or requirements for the sendmail program. It is sufficient to only require some subset to be guaranteed to be provided (as is the case for both x-terminal-emulator and sendmail: any provider will usually also accept provider-specific options in addition to the general ones). David Steele writes in another mail: > That leaves todo.txt, implemented by topydo and (hopefully, soon) > todotxt-cli. Unfortunately, (1) has been invoked here as well - the command > sets of the two packages are close, but not identical. Also, I'm on record > saying an emacs script could comply if: > - it properly supports the "--info" argument > - it supports calling the hooks in the optional todo.txt-base package > - it provides a means to add/modify/delete/show tasks housed in a > todo.txt-format file, noting that the format does not have to be strictly > enforced by the package. > > My latest stake in the ground - I claim that the functionality of the > todo.txt virtual package, from a Policy perspective, is defined, here, and > that the candidates are compliant. I think "todo.txt" is okay if providers of the "todo.txt" virtual package provide a "/usr/bin/todo.txt" alternative that provides some reasonable subset of the command-line interface that topydo / todo.sh / similar tools share so that "todo.txt list", "todo.txt add laundry" and so work. That seems to be the case between topydo and todotxt-cli; just opening emacs wouldn't be valid. (As with the examples above providers can implement more than just the common interface.) Something like this maybe? - name: todo.txt description: command-line task management utility compatible with todo.txt CLI (http://todotxt.org) alternatives: [/usr/bin/todo.txt] Ansgar
Bug#976402: Proposed official virtual packages - todo and todo.txt
David Steele writes: > On Wed, Dec 9, 2020 at 3:21 AM Ansgar wrote: >> Given topydo just provides/conflicts with devtodo to provide the "todo" >> binary, this seems to violate Policy 10.1 "Binaries" unless they provide >> the same functionality. [...] > From where I stand, I would expect the Policy to use a different word to > indicate something along the lines of greater API compatibility. I have no > additional background information, though. Are you aware of any expansions > on this text, or of any precedents that could help with a consensus process? My understanding is that different alternatives for a binary in PATH should provide a compatible command-line interface as one might not know which alternative is installed. See for example the description of x-terminal-emulator in Policy 11.8.3 or requirements for the sendmail program. It is sufficient to only require some subset to be guaranteed to be provided (as is the case for both x-terminal-emulator and sendmail: any provider will usually also accept provider-specific options in addition to the general ones). David Steele writes in another mail: > That leaves todo.txt, implemented by topydo and (hopefully, soon) > todotxt-cli. Unfortunately, (1) has been invoked here as well - the command > sets of the two packages are close, but not identical. Also, I'm on record > saying an emacs script could comply if: > - it properly supports the "--info" argument > - it supports calling the hooks in the optional todo.txt-base package > - it provides a means to add/modify/delete/show tasks housed in a > todo.txt-format file, noting that the format does not have to be strictly > enforced by the package. > > My latest stake in the ground - I claim that the functionality of the > todo.txt virtual package, from a Policy perspective, is defined, here, and > that the candidates are compliant. I think "todo.txt" is okay if providers of the "todo.txt" virtual package provide a "/usr/bin/todo.txt" alternative that provides some reasonable subset of the command-line interface that topydo / todo.sh / similar tools share so that "todo.txt list", "todo.txt add laundry" and so work. That seems to be the case between topydo and todotxt-cli; just opening emacs wouldn't be valid. (As with the examples above providers can implement more than just the common interface.) Something like this maybe? - name: todo.txt description: command-line task management utility compatible with todo.txt CLI (http://todotxt.org) alternatives: [/usr/bin/todo.txt] Ansgar
[Pkg-utopia-maintainers] firewalld_0.7.2-2_amd64.changes REJECTED
As requested on IRC. === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
Bug#945275: debian-policy: [9.1.2] deprecated `staff` group special case
Package: debian-policy 9.1.2 recommends the following to create a directory under /usr/local: ``` if [ ! -e /usr/local/share/emacs ]; then if mkdir /usr/local/share/emacs 2>/dev/null; then if test -e /etc/staff-group-for-usr-local ; then if chown root:staff /usr/local/share/emacs; then chmod 2775 /usr/local/share/emacs || true fi elif chown root:root /usr/local/share/emacs; then chmod 0755 /usr/local/share/emacs || true fi fi fi ``` That is way too complicated and has race conditions (yes, I know staff is practically almost root). I suggest to have packages just create the directory with ``` mkdir -p /usr/local/share/emacs || true ``` If people want to have /usr/local writable by different users than root, they should use POSIX ACLs or similar means. This would also set correct permissions for directories that aren't created as above, but by, for example, a call to `make install`. The `/etc/staff-group-for-usr-local` flag file could also go away then. Ansgar
Bug#945275: debian-policy: [9.1.2] deprecated `staff` group special case
Package: debian-policy 9.1.2 recommends the following to create a directory under /usr/local: ``` if [ ! -e /usr/local/share/emacs ]; then if mkdir /usr/local/share/emacs 2>/dev/null; then if test -e /etc/staff-group-for-usr-local ; then if chown root:staff /usr/local/share/emacs; then chmod 2775 /usr/local/share/emacs || true fi elif chown root:root /usr/local/share/emacs; then chmod 0755 /usr/local/share/emacs || true fi fi fi ``` That is way too complicated and has race conditions (yes, I know staff is practically almost root). I suggest to have packages just create the directory with ``` mkdir -p /usr/local/share/emacs || true ``` If people want to have /usr/local writable by different users than root, they should use POSIX ACLs or similar means. This would also set correct permissions for directories that aren't created as above, but by, for example, a call to `make install`. The `/etc/staff-group-for-usr-local` flag file could also go away then. Ansgar
Bug#942881: Audio on Lenovo X1 Carbon 5th generation stopped working after upgrade to linux-image-5.3.0-1-amd64 ("No response from codec")
Ben Hutchings writes: > The code signing service logs every file it signs, along with a hash of > the detached signature, but I don't know where the logs are so I can't > comapre with that. I checked the audit log, but I don't think it will help much. It currently records that: - 2019-10-21 07:20:03.898781: decided to sign linux-image-5.3.0-1-amd64-unsigned_5.3.7-1_amd64/[...]/snd-hda-codec-hdmi.ko with sha256sum 3fe77a308b28825f0d18717e073b411246aea9bb753f76f6071b3fc4e60c6005 - 2019-10-21 07:20:04.175379: signature for the file logged with sha256sum c2a36f35867ae92b8664f4bd2193e70370eb3b92013ea53f3573d2508d3da4cb (which matches snd-hda-codec-hdmi.ko.sig in src:linux-signed-amd64) So linux' sign-file likely produced a truncated file for some reason; note that ftp-master still uses linux-kbuild-4.9/4.9.189-3+deb9u1. Ansgar
Bug#942881: Audio on Lenovo X1 Carbon 5th generation stopped working after upgrade to linux-image-5.3.0-1-amd64 ("No response from codec")
Ben Hutchings writes: > The code signing service logs every file it signs, along with a hash of > the detached signature, but I don't know where the logs are so I can't > comapre with that. I checked the audit log, but I don't think it will help much. It currently records that: - 2019-10-21 07:20:03.898781: decided to sign linux-image-5.3.0-1-amd64-unsigned_5.3.7-1_amd64/[...]/snd-hda-codec-hdmi.ko with sha256sum 3fe77a308b28825f0d18717e073b411246aea9bb753f76f6071b3fc4e60c6005 - 2019-10-21 07:20:04.175379: signature for the file logged with sha256sum c2a36f35867ae92b8664f4bd2193e70370eb3b92013ea53f3573d2508d3da4cb (which matches snd-hda-codec-hdmi.ko.sig in src:linux-signed-amd64) So linux' sign-file likely produced a truncated file for some reason; note that ftp-master still uses linux-kbuild-4.9/4.9.189-3+deb9u1. Ansgar
Accepted dune-pdelab 2.6~20180302-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 23 Oct 2019 19:13:24 +0200 Source: dune-pdelab Architecture: source Version: 2.6~20180302-2 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Ansgar Burchardt Changes: dune-pdelab (2.6~20180302-2) unstable; urgency=medium . * d/control: Build-Depend on libalberta-dev instead of libalberta2-dev. * Bumped Standards-Version to 4.4.1. Checksums-Sha1: bfad7f2bc9e079f78ccdeea4a6734f3d4710fa11 2595 dune-pdelab_2.6~20180302-2.dsc b40947af3a311542924a64f728b1067a8195f12f 5308 dune-pdelab_2.6~20180302-2.debian.tar.xz Checksums-Sha256: f3c710057046d6a7f4f8ab987f6af18178ef47982141dc2f705287b6ce1ae742 2595 dune-pdelab_2.6~20180302-2.dsc d9844131862c3e696cc17a3be32d4bf4e5e66cf969555f9b0a315e27f3044b07 5308 dune-pdelab_2.6~20180302-2.debian.tar.xz Files: 0f154b058fa612c28d5d2f16bc139ba5 2595 libs optional dune-pdelab_2.6~20180302-2.dsc 1ab00eed68107a0101c56eea9b7b843f 5308 libs optional dune-pdelab_2.6~20180302-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEE6XYjQ9o8g2p4zSVKamMCj1p06JMFAl2wjcYSHGFuc2dhckBk ZWJpYW4ub3JnAAoJEGpjAo9adOiTBxUP/Rtf2iDBF7C6yQwEYZU50TZjny9olLQG nKJiuK8uKXwnL84ZMvHfM09FKPK0Z4xee45UyHCCZA5JqnfOdCiSoBa1E2Y3xArV 8k85S+6lWCbeK6KKlqf6EU03MGt1oh3HDm4WoNjJcgj0Ol0EvyJ18lVaVrt7ILkQ 7rWt6EOxTEH808Bn6bC1r0SkXNXX1/Isok2y0aqgKBDizIPriJjJa1bozeMij7Zk svu8PTSjt4DQrNpQhSshcmdN59qSfWj2xSrccAMBIhR6XSIYISjh51TXp/mrlJwF 87SbYsD2vWP04TmzKXpuKGedj2G3AN13l5DH0rFPjj2zt0c+Edp6PytTg7byVNHm YGewSb7OE7k+qUtFaFoK6rY2AEabDldG1wgCxuIzp/hXLQNjo/YktZEKbF1ge1I8 xDiZxGAsXPmEg9Eb3XtZdX3dMv2SEOQCZ7WUQMczcU87Fl0AwWXsMYOZeKN1nqCP 0aQjoYM27hBXZ21kaFNg8im5m+H3tuiNJAj4APT74xtwC/o1phfjaq1HkIqDE8Pa Hm+yEzKmHf+0sSBArbZ4vLtkCfAKpvrY0L1is+XWWelUK/9ph6oDRWjljxyLp3Ht 8JrWDqUck00Ya1OZeGEqyGqNMkD3WHoVxKAXwmZmsTCY9iNsp4MIkPa6wa9AraB2 hVDH/0WVDuZl =cz/N -END PGP SIGNATURE-
Accepted dune-common 2.6.0-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 14 Oct 2019 23:27:35 +0200 Source: dune-common Architecture: source Version: 2.6.0-4 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Ansgar Burchardt Closes: 936456 Changes: dune-common (2.6.0-4) unstable; urgency=medium . * no longer ship dune-am2cmake and remove dependency on python2. (Closes: #936456) * Bumped Standards-Version to 4.4.1. Checksums-Sha1: 12caaa723a1e6ad0e009d254328cad17fe5e9846 2677 dune-common_2.6.0-4.dsc 9fe927bcfdf795c582f626f08a0c18b289b13bfd 9356 dune-common_2.6.0-4.debian.tar.xz Checksums-Sha256: edde9b59c364536af2b56e977dacef38edf3ce4c4648ab384483abac997c2139 2677 dune-common_2.6.0-4.dsc b93a7a18e20fb349b9209b9e8a96a4b84c1d914d162b70e5a435f96cc858693f 9356 dune-common_2.6.0-4.debian.tar.xz Files: 8c9d21455296116116539cb1c19165a8 2677 libs optional dune-common_2.6.0-4.dsc 5cfdffefec2260fb07d94a9c4c00e141 9356 libs optional dune-common_2.6.0-4.debian.tar.xz -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEE6XYjQ9o8g2p4zSVKamMCj1p06JMFAl2k6iYSHGFuc2dhckBk ZWJpYW4ub3JnAAoJEGpjAo9adOiTZKUQALAqB+7hUMBVyp3Dzyk2WXWG2pMFHxF+ P4pnQktdWuxxsQdrLG26Nhv2CeT98tZ0OHVcma/hmK49O1BmtjiZe9MixcChyLsb 966MY6amN87m5o0XoQrQS1WXTrEmf/JPpk7y1cIrLpUIiFLSnQclHTQRBw35ONXk ZJ/n+ppyetRDfmMDUUrB5nTUYQM/UqMc5LO7fkpoJUsRFMCgg6AfctJ/wbW/Y6eT 2w0MZ+mYBq2CYn32p6U3iWo5ldJs+Wpt/iSTmpXmZKw+yyeskwDZ86SQIoHHq4vl 84YJV41lgTgmeo/f9C2LuWzT4FnObtoWOkOf+BPLZeJ1i0VaFnJLy+5onAApPaMK fk9+vZn/gscJtanV/BfSshBliiZWRigHbL444f18ADl9XmNyCTv6rAOThsW6qH8l ctU90cEMo3hKgGlgdVsNndSxVM8DChQopy7HK+Fh1bLLzjelTRL0DM7vl5bhHBmA fW+HQlLc3AGf405+RWb+wXbTlvgp675wpmBXrptQp7+zkZVJr9p0j+RRvTjjVL6c I0lf94iF3T2jIqHUTf6NDwDePqELyYEoCJeqkiF0s3BQeC36bsyDkRovBvhFeS/i vVF2tQRGeSj5UVi7rzC+8+iiCNMZ/iO7zKi03hSS/25N+HX/vEdG+IChcybIvKrv Vmyr9dxb3QoY =0987 -END PGP SIGNATURE-
Accepted dune-grid 2.6.0-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 13 Oct 2019 15:17:06 +0200 Source: dune-grid Architecture: source Version: 2.6.0-5 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Ansgar Burchardt Changes: dune-grid (2.6.0-5) unstable; urgency=medium . * Backport patch to fix float comparison on i386. + new patch: i386-fpu-tolerance.patch Checksums-Sha1: d48bde7664f4388f249e6ed417d81ee61bfc2752 2531 dune-grid_2.6.0-5.dsc ddde3c251fdb6ac8651c8a06875064ca0f6e5f34 8372 dune-grid_2.6.0-5.debian.tar.xz Checksums-Sha256: 973153b8113dd1fd04059145c7df116b0daa2d6385cfd6d6764ed7f16b616281 2531 dune-grid_2.6.0-5.dsc a4d3582eb8c32d286d61943b07ac719367332214191371b763775ff697b58580 8372 dune-grid_2.6.0-5.debian.tar.xz Files: d91ea91a720abca646156a149bd11433 2531 libs optional dune-grid_2.6.0-5.dsc 95d730324aa1f4aef64e6a513904988d 8372 libs optional dune-grid_2.6.0-5.debian.tar.xz -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEE6XYjQ9o8g2p4zSVKamMCj1p06JMFAl2jKKgSHGFuc2dhckBk ZWJpYW4ub3JnAAoJEGpjAo9adOiTMdIQAJ2SrFmm2Uf95osKlwPUfHeFF3omSuH9 ZifLpmzYpH/r8w+WUEsmuah2My6/aXrAFkhFTmwdYL7Q9vDNg4a3gz9HS511k2QP HXG1MTRnM/Zlzk9l+oOL+ovzPwfS6BZbg3bo4x68T0DUETYQfQGA7Alv1xdL5Kv+ ACJbzU1hF1vn8hZRf4GHDFpzn3ze54gbHXpayfQdJG82NCL21+24LKPZcyLNOeSL OMez2R7da7Q78OQT1ivIcLvq+5qaYDLm+K1knLGG2Rz6IvFBqvYciWZNk8BQcu/b JqE4y2u165pVGdMlFJHgiUvYuWQkPjs3P9JvGHIQ2iZOqFR+nygzXlHWADqH9sEQ FZDEW2q1On0eYht4WhLsqZYSFQwCDeD9QRLr1c4NEoC8jKg5IzEKwSSzunDiOWnb NfasYcDcwR0p+UhovxwfMwpFW7/uK2faBm8rpTkut5bbSFTF0XMH4zslTzcLkNaf OuzlPXvr9+/QqO2NLBh0w0iv+y8/I/tX80JyOj5opR2/cEuSVqyTgdLnoNUi7LRy mfuNIHrzg3ijXE/hx7GRIRv9pkk1L7bqN9mapXZjUlFSmwZN3atfznE6//AtqFpx 8RATkxQibcL1xaqrmtPqZd/XARKzlQL+cC4xZsYvWrNRucDbjUYSU6ULxPnwJo5P Pnueo7aaeOAz =WEif -END PGP SIGNATURE-
Accepted alberta 3.0.1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 13 Oct 2019 11:58:26 +0200 Source: alberta Architecture: source Version: 3.0.1-2 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Ansgar Burchardt Closes: 878199 Changes: alberta (3.0.1-2) unstable; urgency=medium . * Drop transitional package libalberta2-dev. (Closes: #878199) * Switch to automatic -dbgsym packages and drop libalberta-dbg. * debian/control: Use `Rules-Requires-Root: no`. * debian/control: Update Vcs-* fields for move to salsa.d.o. * Bumped Standards-Version to 4.4.1. Checksums-Sha1: 4a4463c4bc129a1e52848cc0a9617e1f6505c8f0 2065 alberta_3.0.1-2.dsc 5d24108cff3eab57eb34c199ffe5fea2f9e6aedb 3988 alberta_3.0.1-2.debian.tar.xz Checksums-Sha256: 3f7f04cc899913f4c4dc77d09fb29e1ed513bea72da7a8250f055a4c67997119 2065 alberta_3.0.1-2.dsc 17c6fe38a93ebc5c8840ec897e7b1e57b661701e2fbb495fb676665b0f579794 3988 alberta_3.0.1-2.debian.tar.xz Files: d7192905d921bdebed2e08b1c486784a 2065 libs optional alberta_3.0.1-2.dsc 6cbd710fdcfdd07e3c828e3a9d9e44a4 3988 libs optional alberta_3.0.1-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEE6XYjQ9o8g2p4zSVKamMCj1p06JMFAl2i9xISHGFuc2dhckBk ZWJpYW4ub3JnAAoJEGpjAo9adOiTaQ4P+wUu7DRR2uBr0yh6m+sX3LlNj+QJTtla 9rfhg3Bs0PlgR8jpIA1TWRc6UWvGn89jM9MlgE+066Z+/4ttZxTYIIQkeCWyTjIz 42+Hvqm+VqwiJoKb9wwkgxTvCqM9iUN7Si89i+StimjQx8wVKQmS38vlTazTC9m6 RalpgpHtwsUoCQy96sEha2QoyVNnocJHq0kTC8wDUQJD16vEyTBlLmK0f91Onr/Y T1bJgBPXu6kv4szYE8GETbtUy7RLr0ylPWK1uQPqpXgkmCXvSYiqY6N+YfD4JI4y g4KNV+0CUAZ9w7JkOwo1JMASj9s6dCcvThLujWjlpJnA9xIxozncoNTsRwMTil5j VfinFie5+EWI26rXPMmDLEt5KGkYR2TJvbSiXbZkq61jenIupS4cMQ6Wd2D+ApK7 WsBIu2eUN2RaCQCn/VHSfBxEtUyXdFwuzwGaD15hoOemc3RgltYuaykT+qhtf/qU SO6PUVyUG0vIdTl/ZdBkPjWC+5vJ0O2G8UG2VWnYwvqDFwUJfKVamjHhQmHZiFtH EeB5SqMl5d0X3zRRYWmVUBQcNmWYQLTEORZ2qZHRn245U0SriZ7yxwtU8tyaEFHk NeQzw9TbFm75tw+Ot3//226sSudP54S+vSgIkrcEAC8nsFCU2LURnfvq6ahI18+g d+qBKT4v3VRU =Phs0 -END PGP SIGNATURE-
Accepted dune-grid 2.6.0-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 09 Oct 2019 17:57:13 +0200 Source: dune-grid Architecture: source Version: 2.6.0-4 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Ansgar Burchardt Closes: 942000 Changes: dune-grid (2.6.0-4) unstable; urgency=medium . * Use python3-vtk7 for tests. (Closes: #942000) + new patch: use-python3.patch * Bumped Standards-Version to 4.4.1 (no changes). Checksums-Sha1: 70759928ae4af49293ef3ae618fe539a21ac6977 2531 dune-grid_2.6.0-4.dsc 8d458e7a19b29832ee6a2c9012c77eae1f0c2d5b 7720 dune-grid_2.6.0-4.debian.tar.xz Checksums-Sha256: b91622061fde0fb1c121a9f30cffb1ea25fdd533cf53b7869d7fd9f21f5dc2a0 2531 dune-grid_2.6.0-4.dsc 9d25e5f790ce8255e96237635285d8f90b08b52fea4ea783fc29de5bf7135af4 7720 dune-grid_2.6.0-4.debian.tar.xz Files: a0365f6dde232279fd790d439542e377 2531 libs optional dune-grid_2.6.0-4.dsc 57788b72acc1da6f3259c4b2e7a8cf89 7720 libs optional dune-grid_2.6.0-4.debian.tar.xz -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEE6XYjQ9o8g2p4zSVKamMCj1p06JMFAl2eWMASHGFuc2dhckBk ZWJpYW4ub3JnAAoJEGpjAo9adOiTGbwP/Ay9QHVntrmayr5IzNs8wT1YXoc548V4 Zn4jR45+f0LB14oDd95AcDFpIrB0+CX0kkdaqP+AKRwcrfFijcAUGt2XivpGfWOH YhUG9NeY7eeJrg5G+Uo8CY45E8Og3QOqoytvIghydvVQ5m9ghHRj46OUNE3/vILk NhnlCWFVu6Eyy66Cfa9Ydm9BFOF+LUDsR6E3G8quw1KghVALqVZJAXU1cNh6m/RQ Sh5BDCkG8f0bFBh1gFA/1PyYmFVV05WlfN9xJwV+tciIcLb7ZX9Uh2fPLIWeDRh3 858L8bh7TA8+gorVpj6wadzNjhVBkFlTzX0kWu2JAARoXXQL5YxggPq8IV7dqCU7 +8Z0WkHoI/23SYtIHayYk7RjRTl8Rw99J2QmqZ65Lz4gr4k3jaJQZugHvMScXjhZ G1Hw9ZRHwNrygsaL41zdzauu1RvOhAGeenhFZv9uNpQZ98K7HHQUZn6GnF924pE7 RGKuQ/+6lBeDtmpdeIZSPBOvj2Qymz0ejahce942UWYjpvZB4WnUTq6fdiMTwMoS dzrrjLduq+Tma/HAhWozRhg3uvAlet/RSzqkJMzUt6YURQkrRghH3MhBibUMTv3/ PlZHFmRhaXs9wLvii20keTV1LehucST7xcLeUvrIV8hCBLDkLdDQtS2/sWu0mxxd YFZqJjEMsInz =h/wL -END PGP SIGNATURE-
Bug#942051: debian-policy: [4.9] requirement to write only to /tmp, /var/tmp, ${TMPDIR} is too strict
Package: debian-policy Version: 4.4.1.1 Severity: minor While checking the upgrade checklist I noticed this new requirement: +--- | 4.9 |Required targets must not write outside of the unpacked source |package tree, except for TMPDIR, /tmp and /var/tmp. +--- The wording is a bit too strict and should be relaxed. There are other paths that should be fine to be written to during the build process, for example /dev/shm, /run/lock[1], or possibly anything below /proc/ for processes spawned by the build process. Ansgar [1] Which I noticed is world-writable which I'm not sure should be as users could then fill /run... Note that /run/user/ has separate filesystems to avoid this problem; but then there are many paths below /run writable by service users which can cause the same problems.
Bug#942051: debian-policy: [4.9] requirement to write only to /tmp, /var/tmp, ${TMPDIR} is too strict
Package: debian-policy Version: 4.4.1.1 Severity: minor While checking the upgrade checklist I noticed this new requirement: +--- | 4.9 |Required targets must not write outside of the unpacked source |package tree, except for TMPDIR, /tmp and /var/tmp. +--- The wording is a bit too strict and should be relaxed. There are other paths that should be fine to be written to during the build process, for example /dev/shm, /run/lock[1], or possibly anything below /proc/ for processes spawned by the build process. Ansgar [1] Which I noticed is world-writable which I'm not sure should be as users could then fill /run... Note that /run/user/ has separate filesystems to avoid this problem; but then there are many paths below /run writable by service users which can cause the same problems.
Bug#941837: texlive-fonts-extra: file conflice with (older) texlive-fonts-extra-links
Package: texlive-fonts-extra Version: 2019.20190930-2 Severity: serious Hi, when upgrading in Debian testing I saw the following error message: +--- | Unpacking texlive-fonts-extra (2019.20190930-2) over (2019.20190830-1) ... | dpkg: error processing archive /tmp/apt-dpkg-install-h6VDTu/50-texlive-fonts-extra_2019.20190930-2_all.deb (--unpack): | trying to overwrite '/usr/share/texlive/texmf-dist/fonts/opentype/arkandis/berenisadf/BerenisADFProSC-Bold.otf', which is also in package texlive-fonts-extra-links 2019.20190830-1 | dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) +--- It looks like texlive-fonts-extra is missing a (versioned) Replaces on texlive-fonts-extra-links. Thanks for maintaining LaTeX in Debian, Ansgar -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (300, 'buildd-unstable'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages texlive-fonts-extra depends on: it tex-common6.12 ii texlive-base 2019.20190930-1 Versions of packages texlive-fonts-extra recommends: ii fonts-adf-accanthis0.20190904-1.1 ii fonts-adf-berenis 0.20190904-1.1 ii fonts-adf-gillius 0.20190904-1.1 ii fonts-adf-universalis 0.20190904-1.1 ii fonts-cabin1.5-2 ii fonts-comfortaa3.001-2 ii fonts-croscore 20181227-1 ii fonts-crosextra-caladea20130214-2 ii fonts-crosextra-carlito20130920-1 ii fonts-dejavu-core 2.37-1 ii fonts-dejavu-extra 2.37-1 ii fonts-ebgaramond 0.016-1 ii fonts-ebgaramond-extra 0.016-1 ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-1 ii fonts-freefont-otf 20120503-9 ii fonts-freefont-ttf 20120503-9 ii fonts-gfs-artemisia1.1-5 ii fonts-gfs-complutum1.1-6 ii fonts-gfs-didot1.1-6 ii fonts-gfs-neohellenic 1.1-6 ii fonts-gfs-olga 1.1-5 ii fonts-gfs-solomos 1.1-5 ii fonts-go 0~20170330-1 ii fonts-junicode 1.002-1 ii fonts-lato 2.0-2 ii fonts-linuxlibertine 5.3.0-4 ii fonts-lobstertwo 2.0-2 ii fonts-noto-hinted 20181227-1 ii fonts-noto-mono20181227-1 ii fonts-oflb-asana-math 000.907-6 ii fonts-open-sans1.11-1 ii fonts-roboto-unhinted 2:0~20170802-3 ii fonts-sil-gentium 20081126:1.03-2 ii fonts-sil-gentium-basic1.102-1 ii fonts-sil-gentiumplus 5.000-2 ii fonts-sil-gentiumplus-compact 5.000-2 ii fonts-stix 1.1.1-4 iu texlive-fonts-extra-links 2019.20190930-2 ii texlive-fonts-recommended 2019.20190930-1 iu texlive-latex-extra2019.20190930-2 Versions of packages texlive-fonts-extra suggests: ii cm-super 0.3.4-15 iu texlive-fonts-extra-doc 2019.20190930-2 Versions of packages tex-common depends on: ii dpkg 1.19.7 ii ucf 3.0038+nmu1 Versions of packages tex-common suggests: ii debhelper 12.6.1 Versions of packages texlive-fonts-extra is related to: it tex-common6.12 ii texlive-binaries 2019.20190605.51237-3 -- debconf information excluded
Bug#941837: texlive-fonts-extra: file conflice with (older) texlive-fonts-extra-links
Package: texlive-fonts-extra Version: 2019.20190930-2 Severity: serious Hi, when upgrading in Debian testing I saw the following error message: +--- | Unpacking texlive-fonts-extra (2019.20190930-2) over (2019.20190830-1) ... | dpkg: error processing archive /tmp/apt-dpkg-install-h6VDTu/50-texlive-fonts-extra_2019.20190930-2_all.deb (--unpack): | trying to overwrite '/usr/share/texlive/texmf-dist/fonts/opentype/arkandis/berenisadf/BerenisADFProSC-Bold.otf', which is also in package texlive-fonts-extra-links 2019.20190830-1 | dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) +--- It looks like texlive-fonts-extra is missing a (versioned) Replaces on texlive-fonts-extra-links. Thanks for maintaining LaTeX in Debian, Ansgar -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (300, 'buildd-unstable'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages texlive-fonts-extra depends on: it tex-common6.12 ii texlive-base 2019.20190930-1 Versions of packages texlive-fonts-extra recommends: ii fonts-adf-accanthis0.20190904-1.1 ii fonts-adf-berenis 0.20190904-1.1 ii fonts-adf-gillius 0.20190904-1.1 ii fonts-adf-universalis 0.20190904-1.1 ii fonts-cabin1.5-2 ii fonts-comfortaa3.001-2 ii fonts-croscore 20181227-1 ii fonts-crosextra-caladea20130214-2 ii fonts-crosextra-carlito20130920-1 ii fonts-dejavu-core 2.37-1 ii fonts-dejavu-extra 2.37-1 ii fonts-ebgaramond 0.016-1 ii fonts-ebgaramond-extra 0.016-1 ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-1 ii fonts-freefont-otf 20120503-9 ii fonts-freefont-ttf 20120503-9 ii fonts-gfs-artemisia1.1-5 ii fonts-gfs-complutum1.1-6 ii fonts-gfs-didot1.1-6 ii fonts-gfs-neohellenic 1.1-6 ii fonts-gfs-olga 1.1-5 ii fonts-gfs-solomos 1.1-5 ii fonts-go 0~20170330-1 ii fonts-junicode 1.002-1 ii fonts-lato 2.0-2 ii fonts-linuxlibertine 5.3.0-4 ii fonts-lobstertwo 2.0-2 ii fonts-noto-hinted 20181227-1 ii fonts-noto-mono20181227-1 ii fonts-oflb-asana-math 000.907-6 ii fonts-open-sans1.11-1 ii fonts-roboto-unhinted 2:0~20170802-3 ii fonts-sil-gentium 20081126:1.03-2 ii fonts-sil-gentium-basic1.102-1 ii fonts-sil-gentiumplus 5.000-2 ii fonts-sil-gentiumplus-compact 5.000-2 ii fonts-stix 1.1.1-4 iu texlive-fonts-extra-links 2019.20190930-2 ii texlive-fonts-recommended 2019.20190930-1 iu texlive-latex-extra2019.20190930-2 Versions of packages texlive-fonts-extra suggests: ii cm-super 0.3.4-15 iu texlive-fonts-extra-doc 2019.20190930-2 Versions of packages tex-common depends on: ii dpkg 1.19.7 ii ucf 3.0038+nmu1 Versions of packages tex-common suggests: ii debhelper 12.6.1 Versions of packages texlive-fonts-extra is related to: it tex-common6.12 ii texlive-binaries 2019.20190605.51237-3 -- debconf information excluded
Bug#941276: clamav-daemon: strange use of systemd service files
Package: clamav-daemon Version: 0.101.4+dfsg-1 Severity: normal After a user asked something about clamav on IRC, I noticed that clamav-daemon's postinst creates a file /etc/systemd/system/clamav-daemon.service.d/extend.conf with static content: +--- | echo "#Automatically Generated by clamav-daemon postinst" > $DEBCONFFILE | echo "#To reconfigure clamd run #dpkg-reconfigure clamav-daemon" >> $DEBCONFFILE | echo "#Please read /usr/share/doc/clamav-daemon/README.Debian.gz for details" >> $DEBCONFFILE | echo "[Service]" > "$DEBSYSTEMDCLAMDCONF" | echo "ExecStartPre=-/bin/mkdir /run/clamav" >> "$DEBSYSTEMDCLAMDCONF" | echo "ExecStartPre=/bin/chown $User /run/clamav" >> "$DEBSYSTEMDCLAMDCONF" +--- This really looks like something that doesn't belong in /etc, but either should be part of clamav-daemon.service directly or shipped as /lib/systemd/system/clamav-daemon.service.d/extend.conf (i.e. /lib instead of /etc). (There is also RuntimeDirectory=, but I'm not sure if stretch's systemd already supports that.) For some reason the user had a call to "/bin/mkdir" instead of "-/bin/mkdir" which failed when the directory already existed (e.g. on restart). Ansgar
[Pkg-clamav-devel] Bug#941276: clamav-daemon: strange use of systemd service files
Package: clamav-daemon Version: 0.101.4+dfsg-1 Severity: normal After a user asked something about clamav on IRC, I noticed that clamav-daemon's postinst creates a file /etc/systemd/system/clamav-daemon.service.d/extend.conf with static content: +--- | echo "#Automatically Generated by clamav-daemon postinst" > $DEBCONFFILE | echo "#To reconfigure clamd run #dpkg-reconfigure clamav-daemon" >> $DEBCONFFILE | echo "#Please read /usr/share/doc/clamav-daemon/README.Debian.gz for details" >> $DEBCONFFILE | echo "[Service]" > "$DEBSYSTEMDCLAMDCONF" | echo "ExecStartPre=-/bin/mkdir /run/clamav" >> "$DEBSYSTEMDCLAMDCONF" | echo "ExecStartPre=/bin/chown $User /run/clamav" >> "$DEBSYSTEMDCLAMDCONF" +--- This really looks like something that doesn't belong in /etc, but either should be part of clamav-daemon.service directly or shipped as /lib/systemd/system/clamav-daemon.service.d/extend.conf (i.e. /lib instead of /etc). (There is also RuntimeDirectory=, but I'm not sure if stretch's systemd already supports that.) For some reason the user had a call to "/bin/mkdir" instead of "-/bin/mkdir" which failed when the directory already existed (e.g. on restart). Ansgar ___ Pkg-clamav-devel mailing list Pkg-clamav-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-clamav-devel
Bug#941273: runit: FTBFS (looks like endless loop)
Package: src:runit Version: 2.1.2-34 Severity: serious I noticed that the last runit build is already taking over 13h on buildds. The hppa build log[1] looks like the build failed due to an endless loop. I asked the other builds to be killed. Ansgar [1] https://buildd.debian.org/status/fetch.php?pkg=runit=hppa=2.1.2-34=1569581954=0
Bug#941273: runit: FTBFS (looks like endless loop)
Package: src:runit Version: 2.1.2-34 Severity: serious I noticed that the last runit build is already taking over 13h on buildds. The hppa build log[1] looks like the build failed due to an endless loop. I asked the other builds to be killed. Ansgar [1] https://buildd.debian.org/status/fetch.php?pkg=runit=hppa=2.1.2-34=1569581954=0
Bug#941194: initscripts: remove some implementation details
Control: reassign -1 debian-policy The section on initscripts has too much implementation details about /etc/rcn.d; these are better explained by external documentation. Also the rationale for why `DISABLED=yes` (or similar) fits better into a footnote than the main text (IMHO). (Policy also should say something about LSB headers in "Writing the scripts", but that will be a different patch.) Ansgar > From 4bdc0bfa5a08ae0481a9820c1d4bfb8b933afcc4 Mon Sep 17 00:00:00 2001 From: Ansgar Date: Thu, 26 Sep 2019 08:49:28 +0200 Subject: [PATCH 1/2] move rationale to discourage old practice into footnote --- policy/ch-opersys.rst | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 6e0c020..1b63064 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -554,16 +554,7 @@ administrator can enable autostarting the daemon using the command ``update-rc.d package enable``. An older practice, which should not be used, was to include a line -like ``DISABLED=yes`` in the package's ``/etc/default`` file. The -package's init script would not start the service until the local -system administrator changed this to ``DISABLED=no``, or similar. The -problem with this approach was that it hides from the init system -whether or not the daemon should actually be started, which leads to -inconsistent and confusing behavior: ``service start`` may -return success but not start the service; services with a dependency -on this service will be started even though the service isn't running; -and init system status commands may incorrectly claim that the service -was started. +like ``DISABLED=yes`` in the package's ``/etc/default`` file. [#]_ Note that if your package changes runlevels or priority, you may have to remove and recreate the links, since otherwise the old links may @@ -1034,6 +1025,17 @@ Debian, so this section has been removed. init scripts, may fail if ``set -e`` is in effect and echoing status messages to the console fails, for example. +.. [#] + The package's init script would not start the service until the + local system administrator changed this to ``DISABLED=no``, or + similar. The problem with this approach was that it hides from the + init system whether or not the daemon should actually be started, + which leads to inconsistent and confusing behavior: ``service +start`` may return success but not start the service; + services with a dependency on this service will be started even + though the service isn't running; and init system status commands + may incorrectly claim that the service was started. + .. [#] Creating, modifying or removing a file in ``/usr/lib/mime/packages/`` using maintainer scripts will not -- 2.23.0 > From 82db1fc4300e2b6563f2436fadf3f964d567c65b Mon Sep 17 00:00:00 2001 From: Ansgar Date: Thu, 26 Sep 2019 08:54:03 +0200 Subject: [PATCH 2/2] refer to external documentation for implementation details of /etc/rcn.d --- policy/ch-opersys.rst | 65 --- 1 file changed, 12 insertions(+), 53 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 1b63064..5a647fd 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -329,59 +329,18 @@ The ``/etc/init.d`` directory contains the scripts executed by ``init`` at boot time and when the init state (or "runlevel") is changed (see ``init(8)``). -There are at least two different, yet functionally equivalent, ways of -handling these scripts. For the sake of simplicity, this document -describes only the symbolic link method. However, it must not be assumed -by maintainer scripts that this method is being used, and any automated -manipulation of the various runlevel behaviors by maintainer scripts -must be performed using ``update-rc.d`` as described below and not by -manually installing or removing symlinks. For information on the -implementation details of the other method, implemented in the -``file-rc`` package, please refer to the documentation of that package. - -These scripts are referenced by symbolic links in the ``/etc/rcn.d`` -directories. When changing runlevels, ``init`` looks in the directory -``/etc/rcn.d`` for the scripts it should execute, where ``n`` is the -runlevel that is being changed to, or ``S`` for the boot-up scripts. - -The names of the links all have the form ``Smmscript`` or ``Kmmscript`` -where mm is a two-digit number and script is the name of the script -(this should be the same as the name of the actual script in -``/etc/init.d``). - -When ``init`` changes runlevel first the targets of the links whose -names start with a ``K`` are executed, each with the single argument -``stop``, followed by the scripts prefixed with an ``S``, each with the -single argument ``start``. (The links are those in the ``/etc/rcn.d`` -directory corresponding to the new runlevel.) The ``K`` links are
Bug#941195: bugs.debian.org: do not append to `References` if wanted msgid is already there
Package: bugs.debian.org Severity: minor Tags: upstream It looks like debbugs always appends the bug report's msgid to the `References` field when sending a follow-up message to the bug. This should not be done when the msgid is already listed there. (I noticed because this broke DKIM signatures; I know that trying to make the BTS not break DKIM signatures is a bit of whack-a-mole.) Ansgar
Bug#941194: initscripts: remove some implementation details
Control: reassign -1 debian-policy The section on initscripts has too much implementation details about /etc/rcn.d; these are better explained by external documentation. Also the rationale for why `DISABLED=yes` (or similar) fits better into a footnote than the main text (IMHO). (Policy also should say something about LSB headers in "Writing the scripts", but that will be a different patch.) Ansgar >From 4bdc0bfa5a08ae0481a9820c1d4bfb8b933afcc4 Mon Sep 17 00:00:00 2001 From: Ansgar Date: Thu, 26 Sep 2019 08:49:28 +0200 Subject: [PATCH 1/2] move rationale to discourage old practice into footnote --- policy/ch-opersys.rst | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 6e0c020..1b63064 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -554,16 +554,7 @@ administrator can enable autostarting the daemon using the command ``update-rc.d package enable``. An older practice, which should not be used, was to include a line -like ``DISABLED=yes`` in the package's ``/etc/default`` file. The -package's init script would not start the service until the local -system administrator changed this to ``DISABLED=no``, or similar. The -problem with this approach was that it hides from the init system -whether or not the daemon should actually be started, which leads to -inconsistent and confusing behavior: ``service start`` may -return success but not start the service; services with a dependency -on this service will be started even though the service isn't running; -and init system status commands may incorrectly claim that the service -was started. +like ``DISABLED=yes`` in the package's ``/etc/default`` file. [#]_ Note that if your package changes runlevels or priority, you may have to remove and recreate the links, since otherwise the old links may @@ -1034,6 +1025,17 @@ Debian, so this section has been removed. init scripts, may fail if ``set -e`` is in effect and echoing status messages to the console fails, for example. +.. [#] + The package's init script would not start the service until the + local system administrator changed this to ``DISABLED=no``, or + similar. The problem with this approach was that it hides from the + init system whether or not the daemon should actually be started, + which leads to inconsistent and confusing behavior: ``service +start`` may return success but not start the service; + services with a dependency on this service will be started even + though the service isn't running; and init system status commands + may incorrectly claim that the service was started. + .. [#] Creating, modifying or removing a file in ``/usr/lib/mime/packages/`` using maintainer scripts will not -- 2.23.0 >From 82db1fc4300e2b6563f2436fadf3f964d567c65b Mon Sep 17 00:00:00 2001 From: Ansgar Date: Thu, 26 Sep 2019 08:54:03 +0200 Subject: [PATCH 2/2] refer to external documentation for implementation details of /etc/rcn.d --- policy/ch-opersys.rst | 65 --- 1 file changed, 12 insertions(+), 53 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 1b63064..5a647fd 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -329,59 +329,18 @@ The ``/etc/init.d`` directory contains the scripts executed by ``init`` at boot time and when the init state (or "runlevel") is changed (see ``init(8)``). -There are at least two different, yet functionally equivalent, ways of -handling these scripts. For the sake of simplicity, this document -describes only the symbolic link method. However, it must not be assumed -by maintainer scripts that this method is being used, and any automated -manipulation of the various runlevel behaviors by maintainer scripts -must be performed using ``update-rc.d`` as described below and not by -manually installing or removing symlinks. For information on the -implementation details of the other method, implemented in the -``file-rc`` package, please refer to the documentation of that package. - -These scripts are referenced by symbolic links in the ``/etc/rcn.d`` -directories. When changing runlevels, ``init`` looks in the directory -``/etc/rcn.d`` for the scripts it should execute, where ``n`` is the -runlevel that is being changed to, or ``S`` for the boot-up scripts. - -The names of the links all have the form ``Smmscript`` or ``Kmmscript`` -where mm is a two-digit number and script is the name of the script -(this should be the same as the name of the actual script in -``/etc/init.d``). - -When ``init`` changes runlevel first the targets of the links whose -names start with a ``K`` are executed, each with the single argument -``stop``, followed by the scripts prefixed with an ``S``, each with the -single argument ``start``. (The links are those in the ``/etc/rcn.d`` -directory corresponding to the new runlevel.) The ``K`` links are
Bug#941194: initscripts: remove some implementation details
Package: bugs.debian.org Severity: normal Tags: patch The section on initscripts has too much implementation details about /etc/rcn.d; these are better explained by external documentation. Also the rationale for why `DISABLED=yes` (or similar) fits better into a footnote than the main text (IMHO). (Policy also should say something about LSB headers in "Writing the scripts", but that will be a different patch.) Ansgar >From 4bdc0bfa5a08ae0481a9820c1d4bfb8b933afcc4 Mon Sep 17 00:00:00 2001 From: Ansgar Date: Thu, 26 Sep 2019 08:49:28 +0200 Subject: [PATCH 1/2] move rationale to discourage old practice into footnote --- policy/ch-opersys.rst | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 6e0c020..1b63064 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -554,16 +554,7 @@ administrator can enable autostarting the daemon using the command ``update-rc.d package enable``. An older practice, which should not be used, was to include a line -like ``DISABLED=yes`` in the package's ``/etc/default`` file. The -package's init script would not start the service until the local -system administrator changed this to ``DISABLED=no``, or similar. The -problem with this approach was that it hides from the init system -whether or not the daemon should actually be started, which leads to -inconsistent and confusing behavior: ``service start`` may -return success but not start the service; services with a dependency -on this service will be started even though the service isn't running; -and init system status commands may incorrectly claim that the service -was started. +like ``DISABLED=yes`` in the package's ``/etc/default`` file. [#]_ Note that if your package changes runlevels or priority, you may have to remove and recreate the links, since otherwise the old links may @@ -1034,6 +1025,17 @@ Debian, so this section has been removed. init scripts, may fail if ``set -e`` is in effect and echoing status messages to the console fails, for example. +.. [#] + The package's init script would not start the service until the + local system administrator changed this to ``DISABLED=no``, or + similar. The problem with this approach was that it hides from the + init system whether or not the daemon should actually be started, + which leads to inconsistent and confusing behavior: ``service +start`` may return success but not start the service; + services with a dependency on this service will be started even + though the service isn't running; and init system status commands + may incorrectly claim that the service was started. + .. [#] Creating, modifying or removing a file in ``/usr/lib/mime/packages/`` using maintainer scripts will not -- 2.23.0 >From 82db1fc4300e2b6563f2436fadf3f964d567c65b Mon Sep 17 00:00:00 2001 From: Ansgar Date: Thu, 26 Sep 2019 08:54:03 +0200 Subject: [PATCH 2/2] refer to external documentation for implementation details of /etc/rcn.d --- policy/ch-opersys.rst | 65 --- 1 file changed, 12 insertions(+), 53 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 1b63064..5a647fd 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -329,59 +329,18 @@ The ``/etc/init.d`` directory contains the scripts executed by ``init`` at boot time and when the init state (or "runlevel") is changed (see ``init(8)``). -There are at least two different, yet functionally equivalent, ways of -handling these scripts. For the sake of simplicity, this document -describes only the symbolic link method. However, it must not be assumed -by maintainer scripts that this method is being used, and any automated -manipulation of the various runlevel behaviors by maintainer scripts -must be performed using ``update-rc.d`` as described below and not by -manually installing or removing symlinks. For information on the -implementation details of the other method, implemented in the -``file-rc`` package, please refer to the documentation of that package. - -These scripts are referenced by symbolic links in the ``/etc/rcn.d`` -directories. When changing runlevels, ``init`` looks in the directory -``/etc/rcn.d`` for the scripts it should execute, where ``n`` is the -runlevel that is being changed to, or ``S`` for the boot-up scripts. - -The names of the links all have the form ``Smmscript`` or ``Kmmscript`` -where mm is a two-digit number and script is the name of the script -(this should be the same as the name of the actual script in -``/etc/init.d``). - -When ``init`` changes runlevel first the targets of the links whose -names start with a ``K`` are executed, each with the single argument -``stop``, followed by the scripts prefixed with an ``S``, each with the -single argument ``start``. (The links are those in the ``/etc/rcn.d`` -directory corresponding to the new runlevel.) The
Bug#940572: gnome-terminal: changing font size on one tab has effect on other tabs
Package: gnome-terminal Version: 3.34.0-1 Severity: minor Tags: upstream Changing the font size in one tab has an effect of other tabs: when switching from tab A (with larger font size) to tab B (regular font size), I can see that tab B gets restored with the larger font size and is only then changed to the normal font size. This causes screen refreshes which is noticable when, for example, running irssi over a SSH connection in one of the tabs. It would be nice if gnome-terminal would switch font size at the same time as changing the terminal emulator's contents to avoid such artifacts. Ansgar -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (300, 'buildd-unstable'), (300, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii dconf-gsettings-backend [gsettings-backend] 0.34.0-1 ii gnome-terminal-data 3.34.0-1 ii gsettings-desktop-schemas 3.34.0-1 ii libatk1.0-0 2.34.0-1 ii libc6 2.29-1 ii libdconf1 0.34.0-1 ii libglib2.0-0 2.62.0-1 ii libgtk-3-03.24.11-1 ii libpango-1.0-01.42.4-7 ii libuuid1 2.34-0.1 ii libvte-2.91-0 0.58.0-1 ii libx11-6 2:1.6.7-1 Versions of packages gnome-terminal recommends: ii gvfs 1.38.1-5+b1 pn nautilus-extension-gnome-terminal ii yelp 3.34.0-1 gnome-terminal suggests no packages. -- no debconf information
Bug#940556: gnome-terminal: uses DPI from wrong screen resulting in hard to read font rendering
Package: gnome-terminal Version: 3.34.0-1 Severity: normal Tags: upstream I have a laptop with an external screen; internal and external screen have different resolutions and DPI. Since a recent update gnome-terminal and other GNOME applications use the DPI from the wrong screen when the window in located close to the screen boundary. (In particular it seems to be triggered by the shadow around the window reaching the other (left) screen.) This results in hard to read text. I've seen this happen with gnome-terminal and gnome-settings under a Wayland GNOME session; not with emacs or firefox (which still use X as far as I know). I've installed gnome-shell 3.34.0-1 and a few other packages from experimental to give them a try. Ansgar -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (300, 'buildd-unstable'), (300, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii dconf-gsettings-backend [gsettings-backend] 0.34.0-1 ii gnome-terminal-data 3.34.0-1 ii gsettings-desktop-schemas 3.34.0-1 ii libatk1.0-0 2.34.0-1 ii libc6 2.29-1 ii libdconf1 0.34.0-1 ii libglib2.0-0 2.62.0-1 ii libgtk-3-03.24.11-1 ii libpango-1.0-01.42.4-7 ii libuuid1 2.34-0.1 ii libvte-2.91-0 0.58.0-1 ii libx11-6 2:1.6.7-1 Versions of packages gnome-terminal recommends: ii gvfs 1.38.1-5+b1 pn nautilus-extension-gnome-terminal ii yelp 3.34.0-1 gnome-terminal suggests no packages. -- no debconf information
Re: [systemd-devel] host0 virtual link suddenly default down in systemd-nspawn container
Johannes Ernst writes: > I've been running the same systemd-nspawn container for some time, always > with the same options: > > systemd-nspawn -b -n -D dir -M name --bind /home -x > > It would always bring up the virtual ethernet link immediately during > boot of the container. But since a recent Arch (host) upgrade (I > think), the virtual ethernet link host0 now stays "down" during boot > of the container: Do you use systemd-networkd? I noticed that systemd-networks no longer starts in nspawn containers (the condition for CAP_NET_ADMIN failed), so nothing configured the network interface after upgrading to systemd 243 in Debian experimental. I haven't had time to investigate the problem further. Ansgar ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Bug#939469: dkimpy-milter: indicate when domain is in "testing mode" in Auth-Results
Package: dkimpy-milter Version: 1.0.1-1 Severity: wishlist Tags: upstream Hi, a recent mail to -devel@ resulted in the following header from dkimpy-milter: Authentication-Results: [...]; dkim=fail (Bad 1024 bit rsa-sha256 signature.) header.d=[...] header.a=rsa-sha256 However the domain (or key) is in testing mode (t=y): +--- | [...]._domainkey.[...] 1513 IN TXT "v=DKIM1; t=y; k=rsa; p=[...]" +---[ $ dig TXT a._domainkey.[...] ] It would be nice if dkimpy-milter would report when a domain is testing DKIM. Ansgar
Bug#932849: ftp.debian.org: NEW process looses .buildinfo files
Control: tag -1 moreinfo Control: retitle -1 ftp.debian.org: `dak process-policy new` loses .buildinfo files The title says "loses .buildinfo files", but the IRC log says: > tar tf /srv/ftp-master.debian.org/queue/done/2019/02.tar.xz | grep > liblogger-simple-perl > 02/04/liblogger-simple-perl_2.0-1_amd64.changes > 02/04/liblogger-simple-perl_2.0-1_amd64.buildinfo > they're still retrievable, just not as friendly So I'm not sure what the problem is? Ansgar
Re: git & Debian packaging sprint report
Russ Allbery writes: > Scott Kitterman writes: >> Except that we have different requirements than git. Git isn't looking >> for security properties from SHA-1, so it's highly likely it'll meet >> their accident avoidance requirements long after it's no longer >> appropriate for security related assertions. > >> I don't think adding more SHA-1 in a security sensitive context is a >> good plan. > > I talked this over briefly in the security pod at work with some other > security engineers who know more crypto than I do to sanity-check my > initial opinion. > > The consensus among all of us was that if you have an opportunity to pick > something other than SHA-1 when designing a new protocol, you should. We have that opportunity here, so I guess we should then? :-) There are also other useful properties the current implementation has: for example the archive contains the artifact that was signed. This can be checked at a later time unlike a Git tag on salsa.d.o that may or may not exist in the future. It is always possible to go back to the key that was used to introduce an artifact without having to trust any system. > But > if it's not simple to pick a different hash, SHA-1 preimage resistance is > reasonable and the other design properties of the system should dominate > any concern about SHA-1 preimage attacks. What about MD5's preimage resistance? We don't really care about collision attacks after all. We have most infrastructure already using SHA-2 and there are preparations to support newer hashes as well; it is a regression to introduce a new system bound to SHA1 for the foreseeable future (and given Git's use of SHA1 their need to require a strong hash is far less). Ansgar
Bug#932789: tor: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111
Package: tor Version: 0.3.5.8-1 Severity: normal Tags: upstream Hi, I found the following warning in my log files: +--- | Tor[2185]: Bug: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:. Stack trace: (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(log_backtrace_impl+0x46) [0x55d7f7455aa6] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(tor_bug_occurred_+0xc0) [0x55d7f74511c0] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(channel_tls_handle_cell+0x49a) [0x55d7f72db71a] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(+0x9a16a) [0x55d7f72ff16a] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(connection_handle_read+0x99d) [0x55d7f72c918d] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(+0x69ebe) [0x55d7f72ceebe] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7fe17bc599ba] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7fe17bc5a537] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(do_main_loop+0xb0) [0x55d7f72d0290] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(tor_run_main+0x10e5) [0x55d7f72be0d5] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(tor_main+0x3a) [0x55d7f72bb30a] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(main+0x19) [0x55d7f72baec9] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fe17b53b09b] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(_start+0x2a) [0x55d7f72baf1a] (on Tor 0.3.5.8 ) +--- (on a Debian buster system) I currently don't have time to investigate further; the system will also be decommissioned next month. Ansgar
Re: git & Debian packaging sprint report
On Tue, 2019-07-16 at 08:29 +0100, Sean Whitton wrote: > We also rely on git for security elsewhere. For example, dak is > deployed by ftpmasters pushing a signed git tag to salsa; a cronjob on > ftpmaster then deploys that code. That's relying on SHA-1 in pretty > much the same way as tag2upload does, AFAICT. That is true and I don't like it. I should probably add a sha2 hash somewhere. (Note that we *can* just change it...) > On Mon 15 Jul 2019 at 10:43PM +02, Ansgar Burchardt wrote: > > It also has one downside: `git tag` alone won't be enough to generate > > the required information, but then a special-purpose tool was proposed > > here already. > > > > The client tool could possibly also just create the .dsc and .changes, > > except for hashes of the compressed files, and the web service just > > recreate the tarball and compress them. That would require near zero > > trust in the web service, but still allow developers to no longer upload > > source packages which might be large. (A bit similar to not having to > > trust buildds by making packages reproducible.) > > This is certainly an interesting proposal and it would be better for > users than using dput, as you say. > > An important advantage of the tag2upload solution over such a thing, > aside from just the fact that it already exists today, is that it allows > us to move (slowly!) towards replacing source packages with git trees, > like the rest of the world has. > > git-debpush is such a simple wrapper around git-tag and git-push that > its users really are uploading only by pushing a signed tag. Your > proposal would bake source packages back into the upload process in a > way that will make it harder to ever get rid of them. No, my proposal allows to stop generating the "source package" as a set of real files at any given time. A "source package" generally consists of: - a set of upstream artifacts (currently one or more tarballs, signatures); can be the empty set for native packages - Debian-specific artifacts - the .dsc artifact (generated from the Debian part); consists of: - strong cryptographic hashes of all other artifacts (Checksum-*, Files, ...) - convenience information extracted from Debian-specific artifacts (Build-Depends, ...) Currently we represent all of these as real files that need to be provided by the uploader. If you no longer want "source packages" as we have currently, you just define another representation as the canonical one. So I would like to just change how developers can provide artifacts to the archive: upstream artifacts can be specified as either a set of URLs to retrieve them from or a Git tree; Debian-specific artifacts can be a Git tree or (for source format 1.0) a diff between two Git trees. All artifacts provided must be covered by a strong cryptographic hash which is signed by a developer. The hash must not only cover the Git tree object itself, but also all content covered by it. We currently have "tar" as the serialization format covered by the strong cryptographic hash and, as I value having a representation of upstream artifacts in the published archive, believe we should continue to provide the "tar" files. However this is not necessary; we could instead provide only the Git tree. Currently this proposal should also allow multi-package repositories, packaging-only repositories, packages using multiple upstream artifacts, and ensuring Debian uses the same artifact as upstream. It does not require any integrity from the VCS system. I think the .dsc artifact should eventually be split into the two parts: the list of artifacts (together with strong cryptographic hashes and where to locate them) signed by the uploader, and the convenience information extracted from these. The second part should be generated by the archive software. Ansgar
Re: git & Debian packaging sprint report
Russ Allbery writes: > Ansgar Burchardt writes: >> The client tool could possibly also just create the .dsc and .changes, >> except for hashes of the compressed files, and the web service just >> recreate the tarball and compress them. > > I think experience with pristine-tar indicates that recreating tarballs is > unfortunately not trivial. pristine-tar tries to recreate an arbitrary tarball that was created by a third-party; in this case both sides are controlled by the same party. Using the uncompressed tarballs also avoids possible problems from the compression algorithm. This is a simpler problem than what pristine-tar tries to solve. For upstream tarballs, one can fetch them from the upstream source if matching the upstream release is desired. Ansgar
Re: git & Debian packaging sprint report
Russ Allbery writes: > Ansgar Burchardt writes: >> Russ Allbery writes: >>> If so, I think that security model is roughly equivalent to the >>> automatic signing of binary packages by buildds, so probably doesn't >>> introduce a new vulnerability, > >> It doesn't rely on strong cryptographic hashes to guarantee integrity. >> To quote Wikipedia: > >> +--- >> | Revision control systems such as Git, Mercurial, and Monotone use >> | SHA-1 not for security but to identify revisions and to ensure that >> | the data has not changed due to accidental corruption. >> +---[ https://en.wikipedia.org/wiki/SHA-1#Data_integrity ] > >> But developers could instead just sign artifacts using a strong >> cryptographic hash that will be included in the source package; for >> example the .orig.tar and .debian.tar which can be made reproducible >> (git-archive is supposed to be reproducible; compression might not be so >> just sign the uncompressed version). > >> We shouldn't go back to trusting SHA-1. > > I'm dubious that we really care that much about a preimage attack on > SHA-1, but sure, if there's some easy way to use something different, that > would be more future-proof. SHA-1 isn't going to get stronger in the future. The TLS world has already moved on, OpenPGP is still in the slow process to move on, Release/Packages stopped using it[1], there is no reason to continue using it. There is another advantage to developers signing the artifacts: one would need much less trust in the service building the source files as it could only manipulate the .dsc, .changes and compression used. It also has one downside: `git tag` alone won't be enough to generate the required information, but then a special-purpose tool was proposed here already. The client tool could possibly also just create the .dsc and .changes, except for hashes of the compressed files, and the web service just recreate the tarball and compress them. That would require near zero trust in the web service, but still allow developers to no longer upload source packages which might be large. (A bit similar to not having to trust buildds by making packages reproducible.) Ansgar [1] Though we still have MD5sum for some suites for jigdo...
Re: git & Debian packaging sprint report
Russ Allbery writes: > If so, I think that security model is roughly equivalent to the automatic > signing of binary packages by buildds, so probably doesn't introduce a new > vulnerability, It doesn't rely on strong cryptographic hashes to guarantee integrity. To quote Wikipedia: +--- | Revision control systems such as Git, Mercurial, and Monotone use | SHA-1 not for security but to identify revisions and to ensure that | the data has not changed due to accidental corruption. +---[ https://en.wikipedia.org/wiki/SHA-1#Data_integrity ] But developers could instead just sign artifacts using a strong cryptographic hash that will be included in the source package; for example the .orig.tar and .debian.tar which can be made reproducible (git-archive is supposed to be reproducible; compression might not be so just sign the uncompressed version). We shouldn't go back to trusting SHA-1. > There are also some interesting nuances here around handling DM packages, > where not everyone with a key in the keyring can upload every package, > although the obvious way to address that is probably for this service to > do the same DM checks that ftpmaster would normally do. We have other permissions checks as well; they shouldn't be reimplemented in different places. Instead the archive (dak) should know who signed the package. Ansgar
Re: Is it the job of Lintian to push an agenda?
Russ Allbery writes: > Matthias Klumpp writes: >> With two Debian stable releases defaulting to systemd now, I think a >> solid case could be made to at least relax the "must" requirement to a >> "should" in policy (but that should better go to the respective bug >> report). > > The Policy process is not equipped to deal with this because that process > requires fairly consensus, and I don't believe that's possible to reach on > this topic. If we have no consensus that doing something is the right thing, then lintian should probably not start raising a warning about it and one should keep in mind that Policy might not reflect consensus when referring to it. Ansgar
Re: Buster install
Curt Howland writes: > I know some kinks will work out, but seriously, /sbin is not in root's > path by default? /sbin is in root's path by default. However Debian now uses a different implementation of `su` which no longer changes PATH by default: +--- | - new 'su' (with no args, i.e. when preserving the environment) also | preserves PATH and IFS, while old su would always reset PATH and IFS | even in 'preserve environment' mode. | [...] | The first difference is probably the most user visible one. Doing | plain 'su' is a really bad idea for many reasons, so using 'su -' is | strongly recommended to always get a newly set up environment similar | to a normal login. +---[ /usr/share/doc/util-linux/NEWS.Debian.gz ] Ansgar
Re: git & Debian packaging sprint report
On Thu, 2019-07-11 at 17:58 -0300, Antonio Terceiro wrote: > > We designed and implemented a system to make it possible for DDs to > > upload new versions of packages by simply pushing a specially > > formatted git tag to salsa. [...] > If the uploads will be done by a service, this means that all of them > will be signed by a single key and not by the DD key. Is ftp-master > ok with that? Depends on a lot of things. As far as I understand this work is in a very early stage and a first brainstorming session on what problem this is intended to solve, why one should consider doing it, and possible requirements is planned for DebConf[1]. Without having any of these, it is hard to comment on anything. Ansgar [1] https://debconf19.debconf.org/talks/68-one-git-to-package-them-all-and-on-the-salsa-find-them/
Bug#931923: gnupg: should support sha2 fingerprints
Package: gnupg Version: 2.2.12-1 Severity: normal Tags: upstream >From man:gpg(1): +--- | This format is deduced from the length of the string and its content | or the 0x prefix. Note, that only the 20 byte version fingerprint | is available with gpgsm (i.e. the SHA-1 hash of the certificate). +--- SHA-2 fingerprints should be supported for X.509 as well. Web browsers have shown those for quite a while now. The same is true for fingerprints of OpenPGP keys, but I'm not sure if there is any standard for those... Ansgar
Bug#931847: Boggus package-supports-alternative-init-but-no-init.d-script test?
On Thu, 11 Jul 2019 13:26:34 +0200 Laurent Bigonville wrote: > My understanding of the policy is that, if a package supports an > alternative init (other than systemd) it must also support sysvinit. > > Also note that if the check is actually correct, this will create false > positive for all the systemd .service files not started at boot > (scheduled jobs, dbus activated,...). The current policy requirement is that everything would need to provide a sysvinit script, see https://bugs.debian.org/911165 Sadly the process to change this is stuck. Ansgar
Bug#931847: Boggus package-supports-alternative-init-but-no-init.d-script test?
On Thu, 11 Jul 2019 13:26:34 +0200 Laurent Bigonville wrote: > My understanding of the policy is that, if a package supports an > alternative init (other than systemd) it must also support sysvinit. > > Also note that if the check is actually correct, this will create false > positive for all the systemd .service files not started at boot > (scheduled jobs, dbus activated,...). The current policy requirement is that everything would need to provide a sysvinit script, see https://bugs.debian.org/911165 Sadly the process to change this is stuck. Ansgar
Bug#931785: release-notes: bullseye: security suite renamed to bullseye-security (from buster/updates)
Package: release-notes Severity: normal For bullseye, the security suite is now named bullseye-security instead of buster/updates and users should adapt their sources.list accordingly when upgrading. People should probably use something like deb http://security.debian.org/debian-security bullseye-security main (adding /debian-security was proposed in [1]). See [2][3][4] for some more information. I should probably also sent a mail to d-d-a@ or so about this in the near future... Ansgar [1] https://lists.debian.org/debian-devel/2015/12/msg00333.html [2] https://bugs.debian.org/614204 [3] https://lists.debian.org/debian-devel/2015/12/msg00254.html [4] https://lists.debian.org/debian-security/2019/06/msg00015.html
Bug#931785: release-notes: bullseye: security suite renamed to bullseye-security (from buster/updates)
Package: release-notes Severity: normal For bullseye, the security suite is now named bullseye-security instead of buster/updates and users should adapt their sources.list accordingly when upgrading. People should probably use something like deb http://security.debian.org/debian-security bullseye-security main (adding /debian-security was proposed in [1]). See [2][3][4] for some more information. I should probably also sent a mail to d-d-a@ or so about this in the near future... Ansgar [1] https://lists.debian.org/debian-devel/2015/12/msg00333.html [2] https://bugs.debian.org/614204 [3] https://lists.debian.org/debian-devel/2015/12/msg00254.html [4] https://lists.debian.org/debian-security/2019/06/msg00015.html
Bug#931785: release-notes: bullseye: security suite renamed to bullseye-security (from buster/updates)
Package: release-notes Severity: normal For bullseye, the security suite is now named bullseye-security instead of buster/updates and users should adapt their sources.list accordingly when upgrading. People should probably use something like deb http://security.debian.org/debian-security bullseye-security main (adding /debian-security was proposed in [1]). See [2][3][4] for some more information. I should probably also sent a mail to d-d-a@ or so about this in the near future... Ansgar [1] https://lists.debian.org/debian-devel/2015/12/msg00333.html [2] https://bugs.debian.org/614204 [3] https://lists.debian.org/debian-devel/2015/12/msg00254.html [4] https://lists.debian.org/debian-security/2019/06/msg00015.html
Bug#931764: popularity-contest: please report foreign architectures
Package: popularity-contest Version: 1.67 Severity: wishlist Hi, it would be nice if popularity-contest would report which foreign architecture are enabled, i.e. the list `dpkg --print-foreign-architectures` should report. In particular I'm interested in seeing how many people have enabled i386 as a foreign architecture on amd64. I've seen that i386 installations have, as one would expect, decreased quite a lot (especially if one looks at architecture-over-popcon-version to see arch usage by release). But we have no data how many people are still using i386 software via multiarch. Ansgar
Bug#931525: dak: NVIU removal should only happen after some time
Package: ftp.debian.org Removing packages from experimental when a newer version is available in unstable should only happen after the package has been in unstable for a few days. This works around https://bugs.debian.org/865304 (too early removal of overrides). It also keep binaries available for users if builds take a while. Ansgar
Re: Unreliable systemd user service
Aidan Gauland writes: > I have a user service for running xautolock that does not start on login > reliably, and I have no idea why, because there is no error message, > just an exit code of 1. (Unit file and output of systemctl status > attached.) Any suggestions on what to do next to troubleshoot this? I would guess `xautolock` might be started before X is running/accessible by your user. Does the journal contain any useful log messages? Note that there is a race condition that some messages might not be logged as part of the user service[1], so you might have to check all log messages and cannot rely on journalctl's `--user-unit` option. Ansgar [1] https://github.com/systemd/systemd/issues/2913
Bug#930428: debootstrap should ensure matching _apt uid
Philipp Kern writes: > 20/06/2019 20:22, Ansgar Burchardt wrote: >> You look up which uid the _apt user inside the chroot has and use that. > > Yeah, but that scales poorly if you have a centralized firewall > policy. It means that you need to maintain dynamic rules. I know it's > possible and you can dedicate a chain to it. At the same time I think > this problem is actually common enough that it deserves a solution. If _apt deserves a special solution, I would suggest assigning the _apt user a static uid instead of patching debootstrap. Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
Philipp Kern writes: > 20/06/2019 20:22, Ansgar Burchardt wrote: >> You look up which uid the _apt user inside the chroot has and use that. > > Yeah, but that scales poorly if you have a centralized firewall > policy. It means that you need to maintain dynamic rules. I know it's > possible and you can dedicate a chain to it. At the same time I think > this problem is actually common enough that it deserves a solution. If _apt deserves a special solution, I would suggest assigning the _apt user a static uid instead of patching debootstrap. Ansgar
Re: libpam-ck-connector missing
Hans writes: > I am running denbian/testing and dicovered, that /var/log/auth.log is got > spammed with the message, that /lib/security/pam_ck_connector.so is missing. > > And yes, it is really missing. However, libpam-ck-connector can not be > installed (due to dependencies of systemd). pam_ck_connector belongs to consolekit which is no longer supported. Is libpam-ck-connector still partly installed? What does `dpkg -l libpam-ck-connector` say? Is pam_ck_connector still used anywhere in /etc/pam.d/*? Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
Trek writes: > Ansgar Burchardt wrote: >> For limiting network access, I would recommend instead using network >> namespaces (to only provide limited network access for all processes) >> and/or user namespaces (if filtering for single UIDs is really >> needed). These do not require any uids to match between in- and >> outside. > > filtering out the root user is a pretty common security practice and > setting an iptables rule on uids is simple for system administrators So you don't run sshd (requires root with network access)? That seems rather uncommon to me. > using namespaces, how can you block any user but not the _apt user if it > is not already created? You look up which uid the _apt user inside the chroot has and use that. > P.S.: the patch seems ok to me, I don't like hard-conding the _apt user > line in /etc/passwd, as apt postinst uses adduser, but it's not clear > to me when adduser is installed during debootstrap You cannot use `adduser` as debootstrap might install binaries you cannot execute (in the first stage). But the effects of the patch are different from calling adduser, for example the _apt user it creates has no entry in /etc/shadow. Such inconsistencies are not good. Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
Trek writes: > Ansgar Burchardt wrote: >> For limiting network access, I would recommend instead using network >> namespaces (to only provide limited network access for all processes) >> and/or user namespaces (if filtering for single UIDs is really >> needed). These do not require any uids to match between in- and >> outside. > > filtering out the root user is a pretty common security practice and > setting an iptables rule on uids is simple for system administrators So you don't run sshd (requires root with network access)? That seems rather uncommon to me. > using namespaces, how can you block any user but not the _apt user if it > is not already created? You look up which uid the _apt user inside the chroot has and use that. > P.S.: the patch seems ok to me, I don't like hard-conding the _apt user > line in /etc/passwd, as apt postinst uses adduser, but it's not clear > to me when adduser is installed during debootstrap You cannot use `adduser` as debootstrap might install binaries you cannot execute (in the first stage). But the effects of the patch are different from calling adduser, for example the _apt user it creates has no entry in /etc/shadow. Such inconsistencies are not good. Ansgar
Bug#930788: creating /var/lib/dpkg/cmethopt
Package: apt,dselect Severity: normal Hi, [ X-Debbugs-Cc'ed -boot@ for debootstrap ] today I learned that debootstrap as special code to create the file /var/lib/dpkg/cmethopt (contents: "apt apt"); this is the function setup_dselect_method in functions. It seems wrong that debootstrap has to know about such a particular detail. Alternatives to debootstrap might also not create the file at all. So I wonder if this could be created somewhere else. An APT developer said this is used by dselect and suggested to file a bug against apt,dselect; he also had the idea that the file might be created in dselect's postinst. Ansgar
Bug#930788: creating /var/lib/dpkg/cmethopt
Package: apt,dselect Severity: normal Hi, [ X-Debbugs-Cc'ed -boot@ for debootstrap ] today I learned that debootstrap as special code to create the file /var/lib/dpkg/cmethopt (contents: "apt apt"); this is the function setup_dselect_method in functions. It seems wrong that debootstrap has to know about such a particular detail. Alternatives to debootstrap might also not create the file at all. So I wonder if this could be created somewhere else. An APT developer said this is used by dselect and suggested to file a bug against apt,dselect; he also had the idea that the file might be created in dselect's postinst. Ansgar
Bug#930788: creating /var/lib/dpkg/cmethopt
Package: apt,dselect Severity: normal Hi, [ X-Debbugs-Cc'ed -boot@ for debootstrap ] today I learned that debootstrap as special code to create the file /var/lib/dpkg/cmethopt (contents: "apt apt"); this is the function setup_dselect_method in functions. It seems wrong that debootstrap has to know about such a particular detail. Alternatives to debootstrap might also not create the file at all. So I wonder if this could be created somewhere else. An APT developer said this is used by dselect and suggested to file a bug against apt,dselect; he also had the idea that the file might be created in dselect's postinst. Ansgar
Re: The Difference between debcheckout and dgit and what they try to accomplish
On Thu, 2019-06-20 at 10:52 +0200, Enrico Zini wrote: > This reminds me of something that popped up in a dinner discussion a few > days ago: mandate documenting workflow in debian/README.source no matter > what, and allow to symlink that file to a repository in > /usr/share/doc/somewhere/ as we do for common licenses. My workflow also includes getting changes merged upstream, so any such documentation would need to include the upstream workflow. Information how to contribute also includes code style (spaces vs tabs), naming conventions and so on. I'm not willing to write such things down for Debian for the rare case someone might read it; there are enough other things that need to be done. Ansgar
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Michael Biebl writes: > On Wed, 19 Jun 2019 22:16:58 +0200 Ansgar Burchardt wrote: >> I'm just a GNOME user, but from gdm3's changelog the default was >> switched to Wayland in July 2017 (or August 2017 for unstable). I >> myself only noticed the switch after reading it happened somewhere on >> the internet shortly after it happened. [...] > When you talk about "gdm3's default", what exactly do you mean: the > display technology gdm is using or the type of GNOME session that is > started as default? I meant the GNOME session; that is the only thing that changed in July/August 2017 as gdm itself used Wayland already before as far as I understand. For something that has been the default for almost two years to be switched back two weeks before the release there has to be some really huge issues for me. Any change will not see much testing given the time after all and risks new regressions. Ansgar
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Michael Biebl writes: > On Wed, 19 Jun 2019 22:16:58 +0200 Ansgar Burchardt wrote: >> I'm just a GNOME user, but from gdm3's changelog the default was >> switched to Wayland in July 2017 (or August 2017 for unstable). I >> myself only noticed the switch after reading it happened somewhere on >> the internet shortly after it happened. [...] > When you talk about "gdm3's default", what exactly do you mean: the > display technology gdm is using or the type of GNOME session that is > started as default? I meant the GNOME session; that is the only thing that changed in July/August 2017 as gdm itself used Wayland already before as far as I understand. For something that has been the default for almost two years to be switched back two weeks before the release there has to be some really huge issues for me. Any change will not see much testing given the time after all and risks new regressions. Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
Ansgar Burchardt writes: > (I don't maintain debootstrap.) > > I don't think it is a good idea to require debootstrap to know about > such details. > > For limiting network access, I would recommend instead using network > namespaces (to only provide limited network access for all processes) > and/or user namespaces (if filtering for single UIDs is really needed). > These do not require any uids to match between in- and outside. And sadly the submitter's address bounced my mail as the mail provider the submitter uses cannot parse RFC-5321 mail addresses correctly. Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
Ansgar Burchardt writes: > (I don't maintain debootstrap.) > > I don't think it is a good idea to require debootstrap to know about > such details. > > For limiting network access, I would recommend instead using network > namespaces (to only provide limited network access for all processes) > and/or user namespaces (if filtering for single UIDs is really needed). > These do not require any uids to match between in- and outside. And sadly the submitter's address bounced my mail as the mail provider the submitter uses cannot parse RFC-5321 mail addresses correctly. Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
Michael Schaller writes: > At the end of the 'apt' package installation the '_apt' user will be > created without specifying a fixed uid. This typically results in a > differing '_apt' uid between the host system and the bootstrapped > system. The differing '_apt' uid is problematic in case the host > system has firewall rules specific to the '_apt' user and that > typically leads to Apt downloads failing inside a chroot. > > For more details see: > * https://lists.debian.org/debian-devel/2019/04/msg00259.html > * https://robots.org.uk/PbuilderFirewallSetup > > Unfortunately this issue isn't easy to detect/troubleshoot, > particularly firewall rules on the '_apt' uid and that there is an uid > mismatch inside a chroot. This could be improved a lot if debootstrap > could avoid this issue if it would ensure that the '_apt' user in the > bootstrapped system has the same uid as on the host system. (I don't maintain debootstrap.) I don't think it is a good idea to require debootstrap to know about such details. For limiting network access, I would recommend instead using network namespaces (to only provide limited network access for all processes) and/or user namespaces (if filtering for single UIDs is really needed). These do not require any uids to match between in- and outside. Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
Michael Schaller writes: > At the end of the 'apt' package installation the '_apt' user will be > created without specifying a fixed uid. This typically results in a > differing '_apt' uid between the host system and the bootstrapped > system. The differing '_apt' uid is problematic in case the host > system has firewall rules specific to the '_apt' user and that > typically leads to Apt downloads failing inside a chroot. > > For more details see: > * https://lists.debian.org/debian-devel/2019/04/msg00259.html > * https://robots.org.uk/PbuilderFirewallSetup > > Unfortunately this issue isn't easy to detect/troubleshoot, > particularly firewall rules on the '_apt' uid and that there is an uid > mismatch inside a chroot. This could be improved a lot if debootstrap > could avoid this issue if it would ensure that the '_apt' user in the > bootstrapped system has the same uid as on the host system. (I don't maintain debootstrap.) I don't think it is a good idea to require debootstrap to know about such details. For limiting network access, I would recommend instead using network namespaces (to only provide limited network access for all processes) and/or user namespaces (if filtering for single UIDs is really needed). These do not require any uids to match between in- and outside. Ansgar
Re: The Difference between debcheckout and dgit and what they try to accomplish
Russ Allbery writes: > Colin Watson writes: >> Is it at all likely that the ftpmaster api service might migrate away >> from Let's Encrypt at this point? I would assume probably not. In that >> case, you could at least make the situation substantially better with no >> further DSA work required by pinning the appropriate LE root certificate >> in dgit. > > debian.org already publishes a CAA record, which conveys that information > (although has its own verification concerns, but I think debian.org is > using DNSSEC so you can verify the record that way). It says that all > debian.org hosts will only use certificates from either LE or Amazon: The CAA record does not indicate a future commitment and could change at any time. If you want to rely on debian.org to use some specific CAs, you would have to ask DSA. (Nor does the CAA record indicate that all currently valid certificates must come from the listed CAs; the CAA record could have been different when those were issued.) Ansgar
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Jonathan Dowland writes: > So far as I am aware there is still radio silence from active GNOME > packaging team members regarding this issue. No comment yet on the > patch I adapted, positive or negative; this bug (#927667) remains > at an RC severity. > > I've not yet read all the thread that Samuel linked to[1] but it looks > like it leans in favour of preserving the current default (xorg). > > I'm copying -release team to see if they have any (new) opinions on > the matter. Otherwise I guess it's up to someone to prepare an NMU > upload, which I will *try* to look at in the next few days, but can't > make any guarantees. I'm just a GNOME user, but from gdm3's changelog the default was switched to Wayland in July 2017 (or August 2017 for unstable). I myself only noticed the switch after reading it happened somewhere on the internet shortly after it happened. Switching the default back two weeks before the release seems too late for me. The largest issue seems to be accessibility, but as far as I understand we already recommend a different desktop environment for that. I don't think that warrants changes that would only see very little testing by now :-/ Ansgar
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Jonathan Dowland writes: > So far as I am aware there is still radio silence from active GNOME > packaging team members regarding this issue. No comment yet on the > patch I adapted, positive or negative; this bug (#927667) remains > at an RC severity. > > I've not yet read all the thread that Samuel linked to[1] but it looks > like it leans in favour of preserving the current default (xorg). > > I'm copying -release team to see if they have any (new) opinions on > the matter. Otherwise I guess it's up to someone to prepare an NMU > upload, which I will *try* to look at in the next few days, but can't > make any guarantees. I'm just a GNOME user, but from gdm3's changelog the default was switched to Wayland in July 2017 (or August 2017 for unstable). I myself only noticed the switch after reading it happened somewhere on the internet shortly after it happened. Switching the default back two weeks before the release seems too late for me. The largest issue seems to be accessibility, but as far as I understand we already recommend a different desktop environment for that. I don't think that warrants changes that would only see very little testing by now :-/ Ansgar
Re: Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Jonathan Dowland writes: > So far as I am aware there is still radio silence from active GNOME > packaging team members regarding this issue. No comment yet on the > patch I adapted, positive or negative; this bug (#927667) remains > at an RC severity. > > I've not yet read all the thread that Samuel linked to[1] but it looks > like it leans in favour of preserving the current default (xorg). > > I'm copying -release team to see if they have any (new) opinions on > the matter. Otherwise I guess it's up to someone to prepare an NMU > upload, which I will *try* to look at in the next few days, but can't > make any guarantees. I'm just a GNOME user, but from gdm3's changelog the default was switched to Wayland in July 2017 (or August 2017 for unstable). I myself only noticed the switch after reading it happened somewhere on the internet shortly after it happened. Switching the default back two weeks before the release seems too late for me. The largest issue seems to be accessibility, but as far as I understand we already recommend a different desktop environment for that. I don't think that warrants changes that would only see very little testing by now :-/ Ansgar
Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
Mattia Rizzolo writes: > On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote: >> The .buildinfo files are referred to in the .changes files; renaming >> them would require updating the .changes file. The .changes files are >> used to upload the security updates to ftp-master. > > With .changes being ephemeral, it feels to me that using them to cross > the archive is not really a good solution, and whatever is used to copy > packages from one archive to another (is it dak itself?) should instead > re-create the upload and re-sign it. Also because that way it would be > perfectly able to "upload" all of the sources+binaries from sec-master > to ftp-master in a single go, which can't be bad. We also currently require .dsc to be signed by the same key as the .changes; that wouldn't work either. There are some advantages to changing the way the sync works, but it's not a priority to look at. There are enough other things... >> ftp-master also has the same problem when uploads end up in policy >> queues (the renaming to .buildinfo.N is only done when dak is "done" >> with the file and will never touch it again). > > Also here, it feels to me that once something is accepted into a policy > queue, dak should already consider it something controlled by itself, > store checksums in the database and be done, not keep the .changes > around as a "source of truth" for additional processing, imho. Throwing away .changes doesn't help with .buildinfo name conflicts. > Sure, I understand that things works like that, I'm just showing a few > design points that could potentially be done differently. We could also just not accept .buildinfo uploads when they don't contain useful information about published binaries, that is for source-only uploads. Maybe I should reenable the check for this at least on security-master? It was rejecting uploads that are okay for unstable/experimental so I disabled it again the last time. Ansgar
Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
Mattia Rizzolo writes: > On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote: >> The .buildinfo files are referred to in the .changes files; renaming >> them would require updating the .changes file. The .changes files are >> used to upload the security updates to ftp-master. > > With .changes being ephemeral, it feels to me that using them to cross > the archive is not really a good solution, and whatever is used to copy > packages from one archive to another (is it dak itself?) should instead > re-create the upload and re-sign it. Also because that way it would be > perfectly able to "upload" all of the sources+binaries from sec-master > to ftp-master in a single go, which can't be bad. We also currently require .dsc to be signed by the same key as the .changes; that wouldn't work either. There are some advantages to changing the way the sync works, but it's not a priority to look at. There are enough other things... >> ftp-master also has the same problem when uploads end up in policy >> queues (the renaming to .buildinfo.N is only done when dak is "done" >> with the file and will never touch it again). > > Also here, it feels to me that once something is accepted into a policy > queue, dak should already consider it something controlled by itself, > store checksums in the database and be done, not keep the .changes > around as a "source of truth" for additional processing, imho. Throwing away .changes doesn't help with .buildinfo name conflicts. > Sure, I understand that things works like that, I'm just showing a few > design points that could potentially be done differently. We could also just not accept .buildinfo uploads when they don't contain useful information about published binaries, that is for source-only uploads. Maybe I should reenable the check for this at least on security-master? It was rejecting uploads that are okay for unstable/experimental so I disabled it again the last time. Ansgar
Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On Mon, 2019-06-17 at 13:12 -0700, Vagrant Cascadian wrote: > > This behaviour is really causing issues for the security-archive so in > > one way or the other there needs to be a solution. Regularly we need > > to fetch the buildd changes and build binary packages, resign them and > > reupload them due to this bug. > > What's unclear to me is why the workaround in DAK for the main archive, > which adds .buildinfo.N for duplicate .buildinfo filenames, can't be or > hasn't been applied for the security archive. Is there something > fundamentally different with the security archive? The .buildinfo files are referred to in the .changes files; renaming them would require updating the .changes file. The .changes files are used to upload the security updates to ftp-master. ftp-master also has the same problem when uploads end up in policy queues (the renaming to .buildinfo.N is only done when dak is "done" with the file and will never touch it again). As most uploads go to unstable and experimental, one mostly doesn't notice the issue. Ansgar
Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On Mon, 2019-06-17 at 13:12 -0700, Vagrant Cascadian wrote: > > This behaviour is really causing issues for the security-archive so in > > one way or the other there needs to be a solution. Regularly we need > > to fetch the buildd changes and build binary packages, resign them and > > reupload them due to this bug. > > What's unclear to me is why the workaround in DAK for the main archive, > which adds .buildinfo.N for duplicate .buildinfo filenames, can't be or > hasn't been applied for the security archive. Is there something > fundamentally different with the security archive? The .buildinfo files are referred to in the .changes files; renaming them would require updating the .changes file. The .changes files are used to upload the security updates to ftp-master. ftp-master also has the same problem when uploads end up in policy queues (the renaming to .buildinfo.N is only done when dak is "done" with the file and will never touch it again). As most uploads go to unstable and experimental, one mostly doesn't notice the issue. Ansgar
Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On Mon, 2019-06-17 at 13:12 -0700, Vagrant Cascadian wrote: > > This behaviour is really causing issues for the security-archive so in > > one way or the other there needs to be a solution. Regularly we need > > to fetch the buildd changes and build binary packages, resign them and > > reupload them due to this bug. > > What's unclear to me is why the workaround in DAK for the main archive, > which adds .buildinfo.N for duplicate .buildinfo filenames, can't be or > hasn't been applied for the security archive. Is there something > fundamentally different with the security archive? The .buildinfo files are referred to in the .changes files; renaming them would require updating the .changes file. The .changes files are used to upload the security updates to ftp-master. ftp-master also has the same problem when uploads end up in policy queues (the renaming to .buildinfo.N is only done when dak is "done" with the file and will never touch it again). As most uploads go to unstable and experimental, one mostly doesn't notice the issue. Ansgar ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#930482: openblas: uses AVX-512 even when AVX-512 is not available in a VM
Package: libopenblas-base Version: 0.3.5+ds-3 Severity: important File: /usr/lib/x86_64-linux-gnu/libopenblas.so.0 Tags: upstream OpenBLAS tries to use AVX-2 / AVX-512 even when it is not actually available, causing programs to crash with SIGILL: +--- | Thread 1 "cholmodtest" received signal SIGILL, Illegal instruction. | 0x7728fc18 in dgemv_n_SKYLAKEX () from /usr/lib/x86_64-linux-gnu/libopenblas.so.0 | (gdb) bt | #0 0x7728fc18 in dgemv_n_SKYLAKEX () from /usr/lib/x86_64-linux-gnu/libopenblas.so.0 | [...] | (gdb) disassemble 0x7728fc18,+8 | Dump of assembler code from 0x7728fc18 to 0x7728fc20: | => 0x7728fc18 : vmovsd (%rdx),%xmm18 |0x7728fc1e : inc%rax +--- As far as I found out, the %xmm18 register should only be available with AVX-512. The CPU model is capable of AVX-2 and AVX-512, however it is not made available in the VM I am using and therefore missing from the "Flags" below. +--- | Architecture:x86_64 | CPU op-mode(s): 32-bit, 64-bit | Byte Order: Little Endian | Address sizes: 40 bits physical, 48 bits virtual | CPU(s): 16 | On-line CPU(s) list: 0-15 | Thread(s) per core: 1 | Core(s) per socket: 1 | Socket(s): 16 | NUMA node(s):2 | Vendor ID: GenuineIntel | CPU family: 6 | Model: 85 | Model name: Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz | Stepping:4 | CPU MHz: 3000.000 | BogoMIPS:6000.00 | Hypervisor vendor: VMware | Virtualization type: full | L1d cache: 32K | L1i cache: 32K | L2 cache:1024K | L3 cache:25344K | NUMA node0 CPU(s): 0-7 | NUMA node1 CPU(s): 8-15 | Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm 3dnowprefetch cpuid_fault pti ssbd ibrs ibpb stibp fsgsbase smep arat md_clear flush_l1d arch_capabilities +---[ Output from `lscpu` ] Ansgar
Bug#930482: openblas: uses AVX-512 even when AVX-512 is not available in a VM
Package: libopenblas-base Version: 0.3.5+ds-3 Severity: important File: /usr/lib/x86_64-linux-gnu/libopenblas.so.0 Tags: upstream OpenBLAS tries to use AVX-2 / AVX-512 even when it is not actually available, causing programs to crash with SIGILL: +--- | Thread 1 "cholmodtest" received signal SIGILL, Illegal instruction. | 0x7728fc18 in dgemv_n_SKYLAKEX () from /usr/lib/x86_64-linux-gnu/libopenblas.so.0 | (gdb) bt | #0 0x7728fc18 in dgemv_n_SKYLAKEX () from /usr/lib/x86_64-linux-gnu/libopenblas.so.0 | [...] | (gdb) disassemble 0x7728fc18,+8 | Dump of assembler code from 0x7728fc18 to 0x7728fc20: | => 0x7728fc18 : vmovsd (%rdx),%xmm18 |0x7728fc1e : inc%rax +--- As far as I found out, the %xmm18 register should only be available with AVX-512. The CPU model is capable of AVX-2 and AVX-512, however it is not made available in the VM I am using and therefore missing from the "Flags" below. +--- | Architecture:x86_64 | CPU op-mode(s): 32-bit, 64-bit | Byte Order: Little Endian | Address sizes: 40 bits physical, 48 bits virtual | CPU(s): 16 | On-line CPU(s) list: 0-15 | Thread(s) per core: 1 | Core(s) per socket: 1 | Socket(s): 16 | NUMA node(s):2 | Vendor ID: GenuineIntel | CPU family: 6 | Model: 85 | Model name: Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz | Stepping:4 | CPU MHz: 3000.000 | BogoMIPS:6000.00 | Hypervisor vendor: VMware | Virtualization type: full | L1d cache: 32K | L1i cache: 32K | L2 cache:1024K | L3 cache:25344K | NUMA node0 CPU(s): 0-7 | NUMA node1 CPU(s): 8-15 | Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm 3dnowprefetch cpuid_fault pti ssbd ibrs ibpb stibp fsgsbase smep arat md_clear flush_l1d arch_capabilities +---[ Output from `lscpu` ] Ansgar -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#929265: coinor-ipopt: new upstream release available
Package: src:coinor-ipopt Version: 3.11.9-2.1 Severity: wishlist The Debian version of IPopt lags quite a bit behind upstream: Debian still ships 3.11.9 (released 2014-08-16); the current upstream release is 3.12.13 (released 2019-04-08), but there were several releases in between that were not includede in Debian. The `Homepage` field in Debian is also no longer current: the page now only says Ipopt has been moved to https://github.com/coin-or/Ipopt Ansgar
Bug#929122: coinor-ipopt: use parallel version of MUMPS (though only with one process)
Package: src:coinor-ipopt
Version: 3.11.9-2.1
Severity: normal
I had some problems with IPopt using the sequential version of MUMPS
recently: as MUMPS provides dummy `MPI_*` functions, my program ended
up using some of them or MUMPS used some of the real MPI functions.
As mentioned in IPopt's README this doesn't work well:
+---
| Note: MUMPS uses interally a fake implementation of MPI. If you are
| using Ipopt within an MPIprogram together with MUMPS, the code will not
| run. You will have to modify the MUMPS sources so that the MPI symbols
| inside the MUMPS code are renamed.
+---[
https://projects.coin-or.org/Ipopt/browser/stable/3.12/Ipopt/doc/documentation.pdf?format=raw
]
I guess I was a bit lucky that is didn't happen before.
The attached patch builds IPopt against the MPI-parallel version of
MUMPS, but uses only one process (MPI_COMM_SELF). That has worked
better for me without needing invasive changes to the MUMPS source
code.
Ansgar
diff -Nru coinor-ipopt-3.11.9/debian/control coinor-ipopt-3.11.9/debian/control
--- coinor-ipopt-3.11.9/debian/control 2015-08-30 14:44:13.0 +0200
+++ coinor-ipopt-3.11.9/debian/control 2019-03-15 14:01:05.0 +0100
@@ -3,8 +3,9 @@
Priority: extra
Maintainer: Greg Horn
Build-Depends: debhelper (>= 5), autotools-dev, gfortran, libblas-dev,
- libmumps-seq-dev (>= 4.9.2.dfsg-4),
- liblapack-dev, doxygen-latex, ghostscript, chrpath, cdbs
+ libmumps-dev (>= 4.9.2.dfsg-4),
+ liblapack-dev, doxygen-latex, ghostscript, chrpath, cdbs,
+ mpi-default-dev, mpi-default-bin
Build-Conflicts: pkg-config
Standards-Version: 3.9.5
Homepage: https://projects.coin-or.org/Ipopt
@@ -34,7 +35,7 @@
Package: coinor-libipopt-dev
Section: libdevel
Architecture: any
-Depends: coinor-libipopt1v5 (= ${binary:Version}), libmumps-seq-dev,
${shlibs:Depends}, ${misc:Depends}
+Depends: coinor-libipopt1v5 (= ${binary:Version}), libmumps-dev,
${shlibs:Depends}, ${misc:Depends}
Description: Interior-Point Optimizer - header files
Ipopt is an open-source solver for large-scale nonlinear continuous
optimization. It can be used from modeling environments, such as AMPL,
diff -Nru coinor-ipopt-3.11.9/debian/patches/parallel-mumps.patch
coinor-ipopt-3.11.9/debian/patches/parallel-mumps.patch
--- coinor-ipopt-3.11.9/debian/patches/parallel-mumps.patch 1970-01-01
01:00:00.0 +0100
+++ coinor-ipopt-3.11.9/debian/patches/parallel-mumps.patch 2019-03-15
14:01:05.0 +0100
@@ -0,0 +1,40 @@
+---
coinor-ipopt-3.11.9.orig/Ipopt/src/Algorithm/LinearSolvers/IpMumpsSolverInterface.cpp
coinor-ipopt-3.11.9/Ipopt/src/Algorithm/LinearSolvers/IpMumpsSolverInterface.cpp
+@@ -12,7 +12,7 @@
+
+ // The following line is a fix for otherwise twice-defined global variable
+ // (This would have to be taken out for a parallel MUMPS version!)
+-#define MPI_COMM_WORLD IPOPT_MPI_COMM_WORLD
++//#define MPI_COMM_WORLD IPOPT_MPI_COMM_WORLD
+ // The first header to include is the one for MPI.
+ #include "mpi.h"
+
+@@ -46,8 +46,6 @@ namespace Ipopt
+ static const Index dbg_verbosity = 0;
+ #endif
+
+-#define USE_COMM_WORLD -987654
+-
+ int MumpsSolverInterface::instancecount_mpi = 0;
+
+ MumpsSolverInterface::MumpsSolverInterface()
+@@ -71,8 +69,9 @@ namespace Ipopt
+ else if( instancecount_mpi > 0 )
+++instancecount_mpi;
+ #endif
++MPI_Comm comm = MPI_COMM_SELF;
+ int myid;
+-MPI_Comm_rank(MPI_COMM_WORLD, );
++MPI_Comm_rank(comm, );
+ #endif
+ mumps_->n = 0;
+ mumps_->nz = 0;
+@@ -82,7 +81,7 @@ namespace Ipopt
+ mumps_->job = -1;//initialize mumps
+ mumps_->par = 1;//working host for sequential version
+ mumps_->sym = 2;//general symetric matrix
+-mumps_->comm_fortran = USE_COMM_WORLD;
++mumps_->comm_fortran = MPI_Comm_c2f(comm);
+ dmumps_c(mumps_);
+ mumps_->icntl[1] = 0;
+ mumps_->icntl[2] = 0;//QUIETLY!
diff -Nru coinor-ipopt-3.11.9/debian/patches/series
coinor-ipopt-3.11.9/debian/patches/series
--- coinor-ipopt-3.11.9/debian/patches/series 2014-10-01 14:42:17.0
+0200
+++ coinor-ipopt-3.11.9/debian/patches/series 2019-03-15 14:01:05.0
+0100
@@ -2,3 +2,4 @@
add_missing_cstddef.patch
doxygen.patch
+parallel-mumps.patch
diff -Nru coinor-ipopt-3.11.9/debian/rules coinor-ipopt-3.11.9/debian/rules
--- coinor-ipopt-3.11.9/debian/rules2015-08-30 14:47:04.0 +0200
+++ coinor-ipopt-3.11.9/debian/rules2019-03-15 14:01:05.0 +0100
@@ -3,11 +3,15 @@
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk
-CPPFLAGS += -I/usr/include/mumps_seq -DHAVE_CSTDDEF
-LDFLAGS += -llapack -lblas -ldmumps_seq -ldl
+export OMPI_MCA_plm_rsh_agent=/bin/false
+export OMPI_MCA_rmaps_base_oversubscribe=1
+
+CPPFLAGS += -DHAVE_CSTDDEF
+LDFLAGS += -llapack -lblas -ldmumps -ldl
DEB_CONFIGURE_EXTRA_FLAGS += --enable-static \
--with-mumps-incdir=/usr/include \
-
Bug#929108: unblock / tpu approval: gmsh/4.1.3+ds1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
gmsh has an old path to OpenCASCADE include files (#927808); this is
easy to fix (see attached diff).
Rebuilding the package also changes a dependency on amd64 (libgmsh4.1
depends on `libhdf5-openmpi-103 (>= 1.8.13)` instead of `libhdf5-103`
after the rebuild); however this matches the dependency on i386.
However gmsh was updated to a new upstream release in unstable on
2019-03-02 with a small fix on 2019-03-04; this missed the freeze date
slightly.
Do you prefer an upload via t-p-u or should I prepare a gmsh
4.1.5+really4.1.3+ds1-1 upload for unstable?
Ansgar
diff -Nru gmsh-4.1.3+ds1/debian/changelog gmsh-4.1.3+ds1/debian/changelog
--- gmsh-4.1.3+ds1/debian/changelog 2019-01-27 12:22:01.0 +0100
+++ gmsh-4.1.3+ds1/debian/changelog 2019-05-17 10:41:56.0 +0200
@@ -1,3 +1,10 @@
+gmsh (4.1.3+ds1-2) buster; urgency=medium
+
+ * Team upload.
+ * debian/rules: Do not pass `-DOCC_INC=...` to cmake (Closes: #927808)
+
+ -- Ansgar Burchardt Fri, 17 May 2019 10:41:56 +0200
+
gmsh (4.1.3+ds1-1) unstable; urgency=medium
* [dbbbe82] New upstream version 4.1.3+ds1
diff -Nru gmsh-4.1.3+ds1/debian/rules gmsh-4.1.3+ds1/debian/rules
--- gmsh-4.1.3+ds1/debian/rules 2019-01-27 12:22:01.0 +0100
+++ gmsh-4.1.3+ds1/debian/rules 2019-05-17 10:39:57.0 +0200
@@ -32,7 +32,6 @@
-DENABLE_ONELAB:BOOL=ON \
-DCMAKE_SKIP_RPATH:BOOL=ON \
-DCMAKE_INCLUDE_PATH:STRING="/usr/include/mpi" \
--DOCC_INC:STRING="/usr/include/occt" \
-DOCC_LIB:STRING="/usr/lib/${DEB_HOST_MULTIARCH}"
│
Bug#929108: unblock / tpu approval: gmsh/4.1.3+ds1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
gmsh has an old path to OpenCASCADE include files (#927808); this is
easy to fix (see attached diff).
Rebuilding the package also changes a dependency on amd64 (libgmsh4.1
depends on `libhdf5-openmpi-103 (>= 1.8.13)` instead of `libhdf5-103`
after the rebuild); however this matches the dependency on i386.
However gmsh was updated to a new upstream release in unstable on
2019-03-02 with a small fix on 2019-03-04; this missed the freeze date
slightly.
Do you prefer an upload via t-p-u or should I prepare a gmsh
4.1.5+really4.1.3+ds1-1 upload for unstable?
Ansgar
diff -Nru gmsh-4.1.3+ds1/debian/changelog gmsh-4.1.3+ds1/debian/changelog
--- gmsh-4.1.3+ds1/debian/changelog 2019-01-27 12:22:01.0 +0100
+++ gmsh-4.1.3+ds1/debian/changelog 2019-05-17 10:41:56.0 +0200
@@ -1,3 +1,10 @@
+gmsh (4.1.3+ds1-2) buster; urgency=medium
+
+ * Team upload.
+ * debian/rules: Do not pass `-DOCC_INC=...` to cmake (Closes: #927808)
+
+ -- Ansgar Burchardt Fri, 17 May 2019 10:41:56 +0200
+
gmsh (4.1.3+ds1-1) unstable; urgency=medium
* [dbbbe82] New upstream version 4.1.3+ds1
diff -Nru gmsh-4.1.3+ds1/debian/rules gmsh-4.1.3+ds1/debian/rules
--- gmsh-4.1.3+ds1/debian/rules 2019-01-27 12:22:01.0 +0100
+++ gmsh-4.1.3+ds1/debian/rules 2019-05-17 10:39:57.0 +0200
@@ -32,7 +32,6 @@
-DENABLE_ONELAB:BOOL=ON \
-DCMAKE_SKIP_RPATH:BOOL=ON \
-DCMAKE_INCLUDE_PATH:STRING="/usr/include/mpi" \
--DOCC_INC:STRING="/usr/include/occt" \
-DOCC_LIB:STRING="/usr/lib/${DEB_HOST_MULTIARCH}"
│
Bug#910783: Remove doc-base recommendation
Paul Wise writes: > On Thu, 11 Oct 2018 17:32:52 -0700 Sean Whitton wrote: >> Instead, if there is indeed consensus, we should change it so that it >> no longer says that doc-base registration is recommended. > > We need a cross-distro cross-desktop standard for an index of > docs before we can move on from doc-base like we did with menu. I don't think so: we can just remove doc-base without providing a replacement at the same time too. Personally I don't know anyone using doc-base (probably most don't even know it exists). If doc-base has indeed no users (or very few users), it just creates work for maintainers for no real benefit. As [1] says, doc-base had 20+ years to get adopted. I think it is fair to say that it failed to do so. [1] https://bugs.debian.org/910783#13 Ansgar
Bug#910783: Remove doc-base recommendation
Paul Wise writes: > On Thu, 11 Oct 2018 17:32:52 -0700 Sean Whitton wrote: >> Instead, if there is indeed consensus, we should change it so that it >> no longer says that doc-base registration is recommended. > > We need a cross-distro cross-desktop standard for an index of > docs before we can move on from doc-base like we did with menu. I don't think so: we can just remove doc-base without providing a replacement at the same time too. Personally I don't know anyone using doc-base (probably most don't even know it exists). If doc-base has indeed no users (or very few users), it just creates work for maintainers for no real benefit. As [1] says, doc-base had 20+ years to get adopted. I think it is fair to say that it failed to do so. [1] https://bugs.debian.org/910783#13 Ansgar
Re: https://wiki.debian.org/Teams/pkg-systemd/Packaging
Hi, On Mon, 2019-05-13 at 12:38 +0200, Maximilian Batz wrote: > I believe to have found a typo in the following line: > > Users can also install a complete unit file > to /etc/systemd/system/foo.service. Systemd then uses it instead > of /lib/systemd/systemd/foo.service. > > I believe it should be systemd/system > > Users can also install a complete unit file > to /etc/systemd/system/foo.service. Systemd then uses it instead > of /lib/systemd/system/foo.service. Yes, that looks correct. I updated the Wiki page[1]. As it is a Wiki, feel free to just correct such mistakes yourself if you want (you just have to be logged in for the edit link to be there IIRC). Ansgar [1] https://wiki.debian.org/Teams/pkg-systemd/Packaging?action=diff=43=44 ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: .deb format: let's use 0.939, zstd, drop bzip2
Ian Jackson writes:
> Ansgar writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
>> `ar` needs to be replaced for the file size limitation mentioned in the
>> initial mail: ar represents file size as a 10 digit decimal number[1]
>> which limits the members (control.tar.*, data.tar.*) to ~10G.
> ...
>> Replacing `ar` is an incompatible format change. So if we already do
>> an incompatible change, it is an appropriate time to bundle any other
>> incompatible changes (if there are any). That is why I suggested that
>> it might be useful to also replace the `tar` archives with another
>> format.
>
> As has been pointed out, we have done many incompatible format
> changes. Every new compression algorithm is one. It isn't really a
> big problem, when managed properly.
>
> So I strongly disagree. The archive size limit is getting more and
> more annoying. We should not let fixing that be entangled with some
> random other nice-to-haves.
Changing container formats is a more invasive change than just
compression algorithms (of which there are already several anyway);
I believe it is a bad idea to create too many new formats that
would require long-term support in dpkg.
Ansgar
Re: Configure your PC to contribute to Debian community
Vipul writes: > I've been using Debian from couples of years but haven't contributed > yet back to community. I want to contribute to Debian by maintaining > packages and fixing bugs. Since I'm using Debian for work purpose also > so, I don't want to mess-up with my system by installing unstable > packages or libraries. Is there a way to get isolation for work & > contribution purpose to keep yourself organized > I can get isolation by using Docker image or install one more copy > of Debian in PC and switch between them but that would be painful. I > want to hear from contributors & maintainers Which method they are > using or prefer to get isolation? You can use pretty much anything you prefer; it also depends on what you are using it for: there is no single solution for all needs. If you are already familiar with Docker, using that as a container for development or for building packages is fine. There is also the "whalebuilder" program to build Debian packages using Docker; it should be comparable to pbuilder or sbuild (I haven't used whalebuilder myself though). Using schroot is also okay; though Docker provides more isolation and might be easier to use. I'm using systemd-nspawn for running full systems including multiple services (daemons); Docker or schroot usually only run one program in a container. There are also alternatives like lxc. Finally for most isolation there are virtual machines; they provide even more isolation, but are also more complicated to use (transferring files, changing resource allocations (disk size, RAM), initial setup). Though if you try potentially destructive things, doing so in a VM is probably much better than breaking your production system :-) Ansgar
Re: Preferred git branch structure when upstream moves from tarballs to git
Sam Hartman writes: >> "Ansgar" == Ansgar writes: > > Ansgar> Sam Hartman writes: > >> I'm having a bit of trouble here and am hoping you can help us > >> out. Ian asked what git workflow it is that you're talking about > >> where people can deal with commit push and pull and don't need to > >> know more. > >> > >> I didn't see a clear answer to that. Which debian packaging > >> workflow do you believe has that property? > > Ansgar> There is no need for a vendor branch if only the packaging > Ansgar> information is kept in the repository, i.e. only debian/. > Ansgar> In particular there is no need for branches or merges for > Ansgar> regular updates (i.e. not based on an older release). > > OK, I didn't hear that as an answer but think I'm coming to the same > conclusion that Ian did after reading your mail. > It sounds like you are talking about having the Debian packaging in a > separate repository from upstream. > Do I correctly understand the model you are talking about? Sure. I'll point to [1] for what complexity this avoids. Try explaining that to someone without advanced Git knowledge... [1] https://manpages.debian.org/unstable/git-debrebase/git-debrebase.5.en.html Note that CVS already had a mechanism for tracking upstream releases (vendor branches); I'm not sure how widely they were used, but as far as I understand they were usually seen as advanced use of CVS. Git makes maintaining such vendor branches easier (better merging), and some workflows for Debian packaging result in trivial merges, but it is very confusing when something unexpected happens. Ansgar
Bug#926215: dune-pdelab: FTBFS with gcc 8.3
On Sun, 2019-05-05 at 16:05 +0200, Santiago Vila wrote: > [ Ansgar: If you still can reproduce the assertion failure, please > file > a new bug. It's better not to mix different issues in the same report ]. The other assertion failure I had also disappeared this week. Not sure if there is a real bug, but I don't have time to look at this too much. Before it was reproducible, unless I rebuilt dune-grid which made the problem in dune-pdelab go away as well... Ansgar
Bug#926215: dune-pdelab: FTBFS with gcc 8.3
On Sun, 2019-05-05 at 16:05 +0200, Santiago Vila wrote: > [ Ansgar: If you still can reproduce the assertion failure, please > file > a new bug. It's better not to mix different issues in the same report ]. The other assertion failure I had also disappeared this week. Not sure if there is a real bug, but I don't have time to look at this too much. Before it was reproducible, unless I rebuilt dune-grid which made the problem in dune-pdelab go away as well... Ansgar
Bug#926215: dune-pdelab: FTBFS with gcc 8.3
On Sun, 2019-05-05 at 16:05 +0200, Santiago Vila wrote: > [ Ansgar: If you still can reproduce the assertion failure, please > file > a new bug. It's better not to mix different issues in the same report ]. The other assertion failure I had also disappeared this week. Not sure if there is a real bug, but I don't have time to look at this too much. Before it was reproducible, unless I rebuilt dune-grid which made the problem in dune-pdelab go away as well... Ansgar -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: "missing pubkey" for buster-security
Harald Dunkel writes: > I am running a local mirror of the security.debian.org > repository for in-house use. It seems to be available for > Buster as well, except that there is an error message > > ERROR: Condition '7638D0442B90D010' not fulfilled for > '/var/www/official/lists/buster-security_buster%2Fupdates_InRelease'. > Signatures in > '/var/www/official/lists/buster-security_buster%2Fupdates_InRelease': > '9D6D8F6BC857C906' (signed 2019-05-03): missing pubkey > 'AA8E81B4331F7F50' (signed 2019-05-03): missing pubkey > Error: Not enough signatures found for remote repository > buster-security (http://security.debian.org buster/updates)! > There have been errors! These keys are already in the debian-archive-keyring package (in testing/unstable): +--- | $ gpg --no-default-keyring --keyring /usr/share/keyrings/debian-archive-keyring.gpg --list-keys 7638D0442B90D010 9D6D8F6BC857C906 AA8E81B4331F7F50 | pub rsa4096 2014-11-21 [SC] [expires: 2022-11-19] | 126C0D24BD8A2942CC7DF8AC7638D0442B90D010 | uid [ full ] Debian Archive Automatic Signing Key (8/jessie) | | pub rsa4096 2014-11-21 [SC] [expires: 2022-11-19] | D21169141CECD440F2EB8DDA9D6D8F6BC857C906 | uid [ full ] Debian Security Archive Automatic Signing Key (8/jessie) | | pub rsa4096 2017-05-22 [SC] [expires: 2025-05-20] | 6ED6F5CB5FA6FB2F460AE88EEDA0D2388AE22BA9 | uid [ full ] Debian Security Archive Automatic Signing Key (9/stretch) | sub rsa4096 2017-05-22 [S] [expires: 2025-05-20] | 379483D8B60160B155B372DDAA8E81B4331F7F50 +--- Your condition requires the security archive to be signed with the main archive key; that is wrong. The 9/stretch keys are fairly new and were announced in [1]. [1] https://lists.debian.org/debian-devel-announce/2019/04/msg8.html > These keys are unknown on keyserver as well: > > # apt-key adv --keyserver keyring.debian.org --recv-keys 9D6D8F6BC857C906 keyring.d.o only has developer keys, not any of the other keys Debian might be using. I recommend getting them either from the debian-archive-keyring package or the locations referred to in the announcement; they should also be available on other keyservers. I would also recommend using the full fingerprint instead of shorter keyids. Ansgar
Re: Preferred git branch structure when upstream moves from tarballs to git
On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote: > > On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote: > > > As an example: to update to a new upstream release, I ideally just have > > to drop the new upstream tarball, update d/changelog and am done. > > Compare with [1] which is much more complicated, even ignoring the extra > > complexity using dgit adds compared to just using git. > > > > [1] > > https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html#NEW_UPSTREAM_RELEASES > > As a package maintainer, if you don't keep the whole source package in > git, you're giving up on a lot of the power of git. I think keeping entry barriers low is more important than being able to use all the power of Git. That's sadly one of the main problems with Dgit: it raises entry barriers by making packaging more complicated. Packaging shouldn't be complicated: it's just a build recipe plus some metadata. > The most > significant thing is that you cannot manipulate quilt patches as commits > on a branch. It is also much more involved to cherry pick commits from > upstream branches, and quickly obtain diffs between Debian's version of > the code and arbitrary other branches, to mention a few other things. Most packages don't need that either: for me most changes are either fairly static (no merge conflict) or are just backports of upstream commits (in which case they can just be removed when using a new upstream version). It does get easier when most fixes are applied upstream instead of staying only in Debian :-) > I also think that you're doing a disservice to downstream users. If > you're trying to fix a bug in the packaged version of some software on > your computer, you don't care about the distinction between Debian's > packaging scripts and the upstream code. Either the bug is in upstream code, then you just need the upstream source (and the patch should be pushed upstream anyway). Or it is in the (ideally smalll) Debian-specific parts which hopefully don't need a long history to understand. If you have large, invasive changes from upstream, you effectively fork the package. Maybe one should release it as a "fork" then so non- Debian distributions can benefit from the changes in the fork. That is arguable a disservice to users... Ansgar
Bug#926215: dune-pdelab: FTBFS with gcc 8.3
Control: reassign -1 src:dune-pdelab 2.6~20180302-1 Control: retitle -1 dune-pdelab: testpk fails with assertion failure On Mon, 2019-04-08 at 08:42 +0200, Ansgar Burchardt wrote: > This is a bug in dune-istl, though I'm not quite sure I understand > what > is exactly wrong. Renaming the template argument from `T` to `T1` in > the definition of `prolongateVector` makes the problem go away, but the > name of template arguments shouldn't really matter? > > There is also a template argument `T` in the generic version of the > `Transfer` class... Maybe that results in the confusion in some way? That problem went away with a GCC update, but there is still a problem with a test in dune-pdelab that now fails... Not sure yet if the problem is in dune-grid or dune-pdelab for that one, reassigning to dune-pdelab for now: +--- | check_mesh: checking mesh 'DUNE AlbertaGrid' | checking done; no error detected | AlbertaGrid< 2, 2 > created from macro grid file '/<>/dune/pdelab/test/grids/ldomain.al'. | GridParameterBlock: Parameter 'refinementedge' not specified, defaulting to 'ARBITRARY'. | testpk: /build/dune-grid-yp9bpw/dune-grid-2.6.0/dune/grid/albertagrid/elementinfo.hh:488: bool Dune::Alberta::ElementInfo::isLeaf() const [with int dim = 2]: Assertion `!(*this) == false' failed. +--- Ansgar
Bug#926215: dune-pdelab: FTBFS with gcc 8.3
Control: reassign -1 src:dune-pdelab 2.6~20180302-1 Control: retitle -1 dune-pdelab: testpk fails with assertion failure On Mon, 2019-04-08 at 08:42 +0200, Ansgar Burchardt wrote: > This is a bug in dune-istl, though I'm not quite sure I understand > what > is exactly wrong. Renaming the template argument from `T` to `T1` in > the definition of `prolongateVector` makes the problem go away, but the > name of template arguments shouldn't really matter? > > There is also a template argument `T` in the generic version of the > `Transfer` class... Maybe that results in the confusion in some way? That problem went away with a GCC update, but there is still a problem with a test in dune-pdelab that now fails... Not sure yet if the problem is in dune-grid or dune-pdelab for that one, reassigning to dune-pdelab for now: +--- | check_mesh: checking mesh 'DUNE AlbertaGrid' | checking done; no error detected | AlbertaGrid< 2, 2 > created from macro grid file '/<>/dune/pdelab/test/grids/ldomain.al'. | GridParameterBlock: Parameter 'refinementedge' not specified, defaulting to 'ARBITRARY'. | testpk: /build/dune-grid-yp9bpw/dune-grid-2.6.0/dune/grid/albertagrid/elementinfo.hh:488: bool Dune::Alberta::ElementInfo::isLeaf() const [with int dim = 2]: Assertion `!(*this) == false' failed. +--- Ansgar
Re: A call to drop gnome as the default desktop
Keith Bainbridge writes: > I see the point that people who like gnome should be allowed to use it > - > so withdraw the drop gnome from debian. I believe the change to the > subject line will keep the discussion together. I'll re-send if it > opens a new topic. Why should GNOME not stay the default desktop? Because it supports using either of Wayland or X11? To quote your original mail this was one of the two main reasons you proposed GNOME to be dropped after all (besides not being able to move some toolbar): | [...] gnome is insisting that we like a new video process, just | because the team have decided to like it lots. | | I say this is NOT freedom. How is supporting *only* X11 freedom, but supporting *both* Wayland and X11 NOT freedom? Wouldn't it be more logical to drop all desktop environments that support *only* X11 to give more freedom? Ansgar
Re: A call to drop gnome
Gene Heskett writes: > On Tuesday 16 April 2019 13:32:38 Ansgar Burchardt wrote: >> Gene Heskett writes: >> > Where the heck in its confusing menu's can I find a tab supporting >> > terminal so I can get something done? Go ahead, find it, my coffee >> > needs to cool anyway.. >> >> You press the magic Super key, then type "Terminal" on the keyboard >> (or at least the beginning), then press Enter. GNOME feels pretty >> much designed to not be used by a mouse alone ;-) > > And that magic Super key is? https://en.wikipedia.org/wiki/Super_key_(keyboard_button) On many keyboards it is also known as this: https://en.wikipedia.org/wiki/Windows_key In my opinion GNOME is not really usable without using that key, so that might partly explain you being uncomfortable with it. > And does it do tabs? https://en.wikipedia.org/wiki/GNOME_Terminal#Tabs Ansgar
Re: A call to drop gnome
Gene Heskett writes: > Where the heck in its confusing menu's can I find a tab supporting > terminal so I can get something done? Go ahead, find it, my coffee needs > to cool anyway.. You press the magic Super key, then type "Terminal" on the keyboard (or at least the beginning), then press Enter. GNOME feels pretty much designed to not be used by a mouse alone ;-) Ansgar
Bug#917535: debian-archive-keyring: ftp-master key for buster
Niels Thykier writes: > We need new archive signing keys for buster, so we can include them in > a debian-archive-keyring upload before the buster release. The two keys are prepared; I'm waiting for a few more signatures from other ftp masters. FWIW they will be: pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12] 5E61B217265DA9807A23C5FF4DFAB270CAA96DFA uid [ full ] Debian Security Archive Automatic Signing Key (10/buster) sub rsa4096 2019-04-14 [S] [expires: 2027-04-12] 5237CEEEF212F3D51C74ABE0112695A0E562B32A pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12] 80D15823B7FD1561F9F7BCDDDC30D7C23CBBABEE uid [ full ] Debian Archive Automatic Signing Key (10/buster) sub rsa4096 2019-04-14 [S] [expires: 2027-04-12] 0146DC6D4A0B2914BDED34DB648ACFD622F3D138 and are also signed by the old signing key. Ansgar signature.asc Description: PGP signature
Bug#917535: debian-archive-keyring: ftp-master key for buster
Niels Thykier writes: > We need new archive signing keys for buster, so we can include them in > a debian-archive-keyring upload before the buster release. The two keys are prepared; I'm waiting for a few more signatures from other ftp masters. FWIW they will be: pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12] 5E61B217265DA9807A23C5FF4DFAB270CAA96DFA uid [ full ] Debian Security Archive Automatic Signing Key (10/buster) sub rsa4096 2019-04-14 [S] [expires: 2027-04-12] 5237CEEEF212F3D51C74ABE0112695A0E562B32A pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12] 80D15823B7FD1561F9F7BCDDDC30D7C23CBBABEE uid [ full ] Debian Archive Automatic Signing Key (10/buster) sub rsa4096 2019-04-14 [S] [expires: 2027-04-12] 0146DC6D4A0B2914BDED34DB648ACFD622F3D138 and are also signed by the old signing key. Ansgar signature.asc Description: PGP signature
Bug#926849: Generate treeinfo files to ease automatic installations
On Thu, 2019-04-11 at 11:49 +0200, Guido Günther wrote:
> E.g. for amd64 and stretch we'd have a file
>
>http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/.treeinfo
>
> looking like
>
> [checksums]
> current/images/netboot/mini.iso = sha256:...
> current/images/netboot/debian-installer/amd64/initrd.gz =
> sha256:...
> current/images/netboot/debian-installer/amd64/linux = sha256: ...
>
> [general]
> arch = x86_64
> family = Debian
> name = Debian Stretch
> version = 9.8.0
> platforms = x86_64
>
> [images-x86_64]
> boot.iso = current/images/netboot/mini.iso
> initrd = current/images/netboot/debian-installer/amd64/initrd.gz
> kernel = current/images/netboot/debian-installer/amd64/linux
Given one can list multiple architectures at one place, shouldn't that
be
https://deb.debian.org/debian/dists/${release}/main/treeinfo
or
https://deb.debian.org/debian/dists/${release}/treeinfo
Users shouldn't have to deal with installer-amd64 or such.
"[general]" also seems deprecated (and limited to one arch).
Is there any reason why this should be a hidden file?
Shouldn't such a file be signed in some way? If for some reason you
only want to trust http(s), the canonical location should probably
*not* be the regular mirror network, but some different place (at which
point anyone could generate these files as well).
Ansgar
Bug#926215: dune-pdelab: FTBFS with gcc 8.3
Control: reassign -1 src:dune-istl 2.6.0-2 Control: affects -1 src:dune-pdelab Santiago Vila writes: > /usr/include/dune/istl/paamg/transfer.hh:97:5: error: no declaration matches > 'void Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T, const > Dune::Amg::SequentialInformation&, const Redist&)' > Transfer::prolongateVector(const > AggregatesMap& aggregates, > ^~~~ > /usr/include/dune/istl/paamg/transfer.hh:62:19: note: candidates are: > 'template template static void > Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T1, const > Dune::Amg::SequentialInformation&)' >static void prolongateVector(const AggregatesMap& aggregates, > Vector& coarse, Vector& fine, >^~~~ > /usr/include/dune/istl/paamg/transfer.hh:57:19: note: > 'template template static void > Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T1, const > Dune::Amg::SequentialInformation&, const Redist&)' >static void prolongateVector(const AggregatesMap& aggregates, > Vector& coarse, Vector& fine, >^~~~ > /usr/include/dune/istl/paamg/transfer.hh:50:11: note: 'class > Dune::Amg::Transfer' defined here > class Transfer >^ This is a bug in dune-istl, though I'm not quite sure I understand what is exactly wrong. Renaming the template argument from `T` to `T1` in the definition of `prolongateVector` makes the problem go away, but the name of template arguments shouldn't really matter? There is also a template argument `T` in the generic version of the `Transfer` class... Maybe that results in the confusion in some way? Ansgar
Bug#926215: dune-pdelab: FTBFS with gcc 8.3
Control: reassign -1 src:dune-istl 2.6.0-2 Control: affects -1 src:dune-pdelab Santiago Vila writes: > /usr/include/dune/istl/paamg/transfer.hh:97:5: error: no declaration matches > 'void Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T, const > Dune::Amg::SequentialInformation&, const Redist&)' > Transfer::prolongateVector(const > AggregatesMap& aggregates, > ^~~~ > /usr/include/dune/istl/paamg/transfer.hh:62:19: note: candidates are: > 'template template static void > Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T1, const > Dune::Amg::SequentialInformation&)' >static void prolongateVector(const AggregatesMap& aggregates, > Vector& coarse, Vector& fine, >^~~~ > /usr/include/dune/istl/paamg/transfer.hh:57:19: note: > 'template template static void > Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T1, const > Dune::Amg::SequentialInformation&, const Redist&)' >static void prolongateVector(const AggregatesMap& aggregates, > Vector& coarse, Vector& fine, >^~~~ > /usr/include/dune/istl/paamg/transfer.hh:50:11: note: 'class > Dune::Amg::Transfer' defined here > class Transfer >^ This is a bug in dune-istl, though I'm not quite sure I understand what is exactly wrong. Renaming the template argument from `T` to `T1` in the definition of `prolongateVector` makes the problem go away, but the name of template arguments shouldn't really matter? There is also a template argument `T` in the generic version of the `Transfer` class... Maybe that results in the confusion in some way? Ansgar
Bug#926215: dune-pdelab: FTBFS with gcc 8.3
Control: reassign -1 src:dune-istl 2.6.0-2 Control: affects -1 src:dune-pdelab Santiago Vila writes: > /usr/include/dune/istl/paamg/transfer.hh:97:5: error: no declaration matches > 'void Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T, const > Dune::Amg::SequentialInformation&, const Redist&)' > Transfer::prolongateVector(const > AggregatesMap& aggregates, > ^~~~ > /usr/include/dune/istl/paamg/transfer.hh:62:19: note: candidates are: > 'template template static void > Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T1, const > Dune::Amg::SequentialInformation&)' >static void prolongateVector(const AggregatesMap& aggregates, > Vector& coarse, Vector& fine, >^~~~ > /usr/include/dune/istl/paamg/transfer.hh:57:19: note: > 'template template static void > Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T1, const > Dune::Amg::SequentialInformation&, const Redist&)' >static void prolongateVector(const AggregatesMap& aggregates, > Vector& coarse, Vector& fine, >^~~~ > /usr/include/dune/istl/paamg/transfer.hh:50:11: note: 'class > Dune::Amg::Transfer' defined here > class Transfer >^ This is a bug in dune-istl, though I'm not quite sure I understand what is exactly wrong. Renaming the template argument from `T` to `T1` in the definition of `prolongateVector` makes the problem go away, but the name of template arguments shouldn't really matter? There is also a template argument `T` in the generic version of the `Transfer` class... Maybe that results in the confusion in some way? Ansgar -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
