Content and translation status for the debian-edu-bookworm manual
The (translated) debian-edu-bookworm manual in PDF, ePUB or HTML formats are available at https://jenkins.debian.net/userContent/debian-edu-doc// To understand this mail better, please read /usr/share/doc/debian-edu-doc/README. This mail is automatically send by a cronjob run by Holger Levsen every two weeks. Please send feedback, suggestions, flames and cookies via this list. debian-edu-bookworm-manual.da.po: 618 translated messages, 255 fuzzy translations, 165 untranslated messages. debian-edu-bookworm-manual.de.po: 996 translated messages, 30 fuzzy translations, 12 untranslated messages. debian-edu-bookworm-manual.es.po: 1038 translated messages. debian-edu-bookworm-manual.fr.po: 1038 translated messages. debian-edu-bookworm-manual.id.po: 211 translated messages, 827 untranslated messages. debian-edu-bookworm-manual.it.po: 1031 translated messages, 7 fuzzy translations. debian-edu-bookworm-manual.ja.po: 739 translated messages, 198 fuzzy translations, 101 untranslated messages. debian-edu-bookworm-manual.nb-no.po: 599 translated messages, 304 fuzzy translations, 135 untranslated messages. debian-edu-bookworm-manual.nl.po: 1038 translated messages. debian-edu-bookworm-manual.pl.po: 307 translated messages, 128 fuzzy translations, 603 untranslated messages. debian-edu-bookworm-manual.pt-br.po: 1038 translated messages. debian-edu-bookworm-manual.pt-pt.po: 1038 translated messages. debian-edu-bookworm-manual.pt.po: 1038 translated messages. debian-edu-bookworm-manual.ro.po: 1038 translated messages. debian-edu-bookworm-manual.sv.po: 756 translated messages, 44 fuzzy translations, 238 untranslated messages. debian-edu-bookworm-manual.uk.po: 1038 translated messages. debian-edu-bookworm-manual.zh-cn.po: 806 translated messages, 149 fuzzy translations, 83 untranslated messages. FIXME: The HowTos from https://wiki.debian.org/DebianEdu/HowTo/"/> are either user- or developer-specific. Let's move the user-specific HowTos over here (and delete them over there)! (But first ask the authors (see the history of those pages to find them) if they are fine with moving the howto and putting it under the GPL.) 1 FIXMEs left to fix
Bug#1069934: 4.9.2. The dak ls utility should mention rmadison
control: severity -1 wishlist thanks Hi Bill, On Sat, Apr 27, 2024 at 12:11:21PM +0200, Bill Allombert wrote: > 4.9.2. The dak ls utility > could mention rmadison from devscripts > that does not require to log to ftp-master.debian.org. yes. patches, commits & pushes welcome. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ 20230709: Today was the warmest day on earth in 125,000 years. Today was also the day with the most planes in the air at one time ever in history. By the time you read this both of these records have probably been broken. signature.asc Description: PGP signature
Bug#1069934: 4.9.2. The dak ls utility should mention rmadison
control: severity -1 wishlist thanks Hi Bill, On Sat, Apr 27, 2024 at 12:11:21PM +0200, Bill Allombert wrote: > 4.9.2. The dak ls utility > could mention rmadison from devscripts > that does not require to log to ftp-master.debian.org. yes. patches, commits & pushes welcome. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ 20230709: Today was the warmest day on earth in 125,000 years. Today was also the day with the most planes in the air at one time ever in history. By the time you read this both of these records have probably been broken. signature.asc Description: PGP signature
Re: Making trixie debootstrap-able again?
hi kibi, fwiw, bootstraping trixie still works using mmdebstrap, while it fails with debootstrap and cdebootstrap. I've notified #-release about the debootstrap breakage on the 24th and added that mmdebstrap was still working on the 25th... https://jenkins.debian.net/job/reproducible_mmdebstrap_trixie/ etc show this nicely. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If it feels like we’re breaking climate records every year, it’s because we are. signature.asc Description: PGP signature
Re: Making trixie debootstrap-able again?
hi kibi, fwiw, bootstraping trixie still works using mmdebstrap, while it fails with debootstrap and cdebootstrap. I've notified #-release about the debootstrap breakage on the 24th and added that mmdebstrap was still working on the 25th... https://jenkins.debian.net/job/reproducible_mmdebstrap_trixie/ etc show this nicely. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If it feels like we’re breaking climate records every year, it’s because we are. signature.asc Description: PGP signature
Bug#1069853: pbuilder: add support for '--debootstrap mmdebstrap'
Package: pbuilder Version: 0.231 Severity: wishlist Dear Maintainer, please add support for '--debootstrap mmdebstrap'. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ figures don't lie, but liars figure. signature.asc Description: PGP signature
Bug#1069727: libsequoia-octopus-librnp: Thunderbird integration autopkgtests
On Tue, Apr 23, 2024 at 10:02:13AM -0400, Daniel Kahn Gillmor wrote: > It would be great to have an autopkgtest that confirms that it actually > interoperates with Thunderbird as expected. [...] > Perhaps upstream could help us assemble a comparable test that would run > reliably in ci.debian.org. upstream pointed me to https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/pipelines/1258177075 and said "note jobs in the tb_test column", which at least is something in that direction, though I think eg https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/jobs/6656045653 (1st link from that 1st url in that column mentioned above) is not really easily comprehensible and I would also love to see something with screenshots (and a video) where one can see thunderbird started, email being written, pgp icon clicked, etc, as I've seen being done eg with openqa. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The past is over. signature.asc Description: PGP signature
Bug#1069242: official bookworm-backports of rust packages unlikely
control: tags -1 + wontfix hi Jérôme, backports of rust packages at least currently are very unlikely, because one cannot simply backport one package plus one or two libraries maybe, or 5 libraries, but instead one would need to backport src:rust-sequoia-octopus-librnp which would need around 10 other src:rust-sequoia* packages, which then need a 100 (or 200?) or so other src:rust* packages backported and then these backports (besides being a huge effort already) need to be maintained until after one year of the release of trixie, which translates to more backports of these hundreds of packages plus any new dependencies... So right now I don't see *this* happen, sorry. OTOH, if the unstable libsequoia-octopus-librnp binary package works for you on bookworm, it's trivial to put it in a local apt repo and be done. :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Stop saying that we are all in the same boat. We’re all in the same storm. But we’re not all in the same boat. signature.asc Description: PGP signature
Bug#1069686: libsequoia-octopus-librnp: postinst script Syntax error: "fi" unexpected
On Mon, Apr 22, 2024 at 02:41:44PM -0400, Daniel Kahn Gillmor wrote: > /var/lib/dpkg/tmp.ci/preinst: 12: Syntax error: "fi" unexpected (expecting > "then") > dpkg: error processing archive > /tmp/apt-dpkg-install-aFNmwO/1-libsequoia-octopus-librnp_1.8.1-3_amd64.deb > (--unpack): > new libsequoia-octopus-librnp package pre-installation script subprocess > returned error exit status 2 fixed in git. > Please try at least installing and uninstalling the package before > pushing it into unstable! the change seems innocent enough... (I just wasnt expected the different formatting styles...) > This also makes me wonder whether we should be doing anything in an > autopkgtest kind of way for this package. It'd be great to get some > more automated confirmation that the things are working as expected > before we inflict them on the rest of the debian ecosystem :P the irony is: the autopkg tests for the package had failed which I blamed on unstables unstableness these days, so I reviewed the diff once more, (again) didnt notice the introduced bug and did a source only upload, because the change were tiny... :/ to me this is more an argument for unstable-untested, or testing maybe. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ 20230709: Today was the warmest day on earth in 125,000 years. Today was also the day with the most planes in the air at one time ever in history. By the time you read this both of these records have probably been broken. signature.asc Description: PGP signature
Bug#1069686: libsequoia-octopus-librnp: postinst script Syntax error: "fi" unexpected
On Mon, Apr 22, 2024 at 02:41:44PM -0400, Daniel Kahn Gillmor wrote: > /var/lib/dpkg/tmp.ci/preinst: 12: Syntax error: "fi" unexpected (expecting > "then") > dpkg: error processing archive > /tmp/apt-dpkg-install-aFNmwO/1-libsequoia-octopus-librnp_1.8.1-3_amd64.deb > (--unpack): > new libsequoia-octopus-librnp package pre-installation script subprocess > returned error exit status 2 fixed in git. > Please try at least installing and uninstalling the package before > pushing it into unstable! the change seems innocent enough... (I just wasnt expected the different formatting styles...) > This also makes me wonder whether we should be doing anything in an > autopkgtest kind of way for this package. It'd be great to get some > more automated confirmation that the things are working as expected > before we inflict them on the rest of the debian ecosystem :P the irony is: the autopkg tests for the package had failed which I blamed on unstables unstableness these days, so I reviewed the diff once more, (again) didnt notice the introduced bug and did a source only upload, because the change were tiny... :/ to me this is more an argument for unstable-untested, or testing maybe. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ 20230709: Today was the warmest day on earth in 125,000 years. Today was also the day with the most planes in the air at one time ever in history. By the time you read this both of these records have probably been broken. signature.asc Description: PGP signature
Bug#1069593: libsequoia-octopus-librnp: dpkg-divert in preinst doesn't happen on upgrade
hi dkg, thanks for these bugreports! I've commited fixes and am doing test builds now and will upload shortly. On Sun, Apr 21, 2024 at 04:29:10AM -0400, Daniel Kahn Gillmor wrote: > Why does the package exclude the diversion when preinst runs on upgrade? I guess because I used a bad example... > i see the same issue in the use of dpkg-divert in gpg-from-sq and > gpgv-from-sq also, btw. Compare that to the use of dpkg-divert in > /var/lib/dpkg/info/perl-doc.preinst, for example, which triggers on both > "install" and on "upgrade". thanks. will upload a new version of chameleon once we confirmed with this package that the fix works. > I worked around this on my system by removing libsequoia-octopus-librnp, > upgrading thunderbird, and then reinstalling libsequoia-octopus-librnp, > but it seems like the goal should be to not have to make the user do > that. yes, absolutly. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "I became an antifascist out of a sense of common decency.” – Marlene Dietrich signature.asc Description: PGP signature
Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"
On Sat, Apr 20, 2024 at 08:30:52PM +0200, Guillem Jover wrote: > While I fully support properly marking obsolete packages by putting > them in the (unfortunately misnamed :) oldlibs section (well excluding > library-like depended on packages that get dropped as a mater of course). > I wanted to note that I've received some pushback from the archive > maintainers about this being considered unnecessary churn (paraphrasing > from what ISTR). So it would be nice to clarify this with them before > creating and proposing a procedure that might end up generating social > friction. I tend to agree. Already now maintainers forget to drop transitional packages after having them been part of *two* releases (I have filed >400 bugs requesting removal of such old transitional packages in the last 10y, so roughly 80 per release), so I don't think requiring them to do *more* will work out nicely. (also this adds workload to ftpmasters too.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "In just 6 decades, roughly the life span of a blue whale, humans took blue whale population down from 360,000 to just 1,000. In one century, whalers killed two million baleen whales, which together weighed twice as much as all wild mammals on Earth today." https://www.theatlantic.com/science/archive/2021/11/whaling-whales-food-krill-iron/620604/ signature.asc Description: PGP signature
Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"
On Sat, Apr 20, 2024 at 08:30:52PM +0200, Guillem Jover wrote: > While I fully support properly marking obsolete packages by putting > them in the (unfortunately misnamed :) oldlibs section (well excluding > library-like depended on packages that get dropped as a mater of course). > I wanted to note that I've received some pushback from the archive > maintainers about this being considered unnecessary churn (paraphrasing > from what ISTR). So it would be nice to clarify this with them before > creating and proposing a procedure that might end up generating social > friction. I tend to agree. Already now maintainers forget to drop transitional packages after having them been part of *two* releases (I have filed >400 bugs requesting removal of such old transitional packages in the last 10y, so roughly 80 per release), so I don't think requiring them to do *more* will work out nicely. (also this adds workload to ftpmasters too.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "In just 6 decades, roughly the life span of a blue whale, humans took blue whale population down from 360,000 to just 1,000. In one century, whalers killed two million baleen whales, which together weighed twice as much as all wild mammals on Earth today." https://www.theatlantic.com/science/archive/2021/11/whaling-whales-food-krill-iron/620604/ signature.asc Description: PGP signature
Bug#1069322: diffoscope crashes when trying to compare unreproducible src:dasel build artifacts
Package: diffoscope Version: 264 Severity: normal X-Debbugs-Cc: team+pkg...@tracker.debian.org Dear Maintainer, diffoscope crashes when comparing the build results of src:dasel. To make it more fun, src:dasel is only unreproducible on i386 (out of our four tested archs, amd64/i386/arm64/armhf) and only *sometimes*. vagrant added the following note to reproducible-notes.git, visible at https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/dasel.html ---begin-note--- timezone-dependent date in manpages triggered when building with reprotest but not reproducible builds test infrastructure. dasel itself is used to generate the manpage. https://sources.debian.org/src/dasel/2.7.0-1/internal/command/man.go/ . Something non-deterministic, possibly GO BUILDID only on i386. ---end-note--- several build artifacts at available at https://tests.reproducible-builds.org/debian/artifacts/r00t-me/ and only the i386 ones are sometimes unreproducible and then crashing diffoscope. (Please download them for investigations, they will vanish after 48h but I can easily and quickly recreate them anytime.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ I used to be scared for our grandchildren's future. Such optimism! signature.asc Description: PGP signature
Bug#1069322: diffoscope crashes when trying to compare unreproducible src:dasel build artifacts
Package: diffoscope Version: 264 Severity: normal X-Debbugs-Cc: team+pkg...@tracker.debian.org Dear Maintainer, diffoscope crashes when comparing the build results of src:dasel. To make it more fun, src:dasel is only unreproducible on i386 (out of our four tested archs, amd64/i386/arm64/armhf) and only *sometimes*. vagrant added the following note to reproducible-notes.git, visible at https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/dasel.html ---begin-note--- timezone-dependent date in manpages triggered when building with reprotest but not reproducible builds test infrastructure. dasel itself is used to generate the manpage. https://sources.debian.org/src/dasel/2.7.0-1/internal/command/man.go/ . Something non-deterministic, possibly GO BUILDID only on i386. ---end-note--- several build artifacts at available at https://tests.reproducible-builds.org/debian/artifacts/r00t-me/ and only the i386 ones are sometimes unreproducible and then crashing diffoscope. (Please download them for investigations, they will vanish after 48h but I can easily and quickly recreate them anytime.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ I used to be scared for our grandchildren's future. Such optimism! signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"
Hi Vincent, On Wed, Apr 17, 2024 at 04:24:16AM +0200, Vincent Lefevre wrote: > Now that the deborphan package has been removed from unstable, > the section "Make transition packages deborphan compliant" in > "Best Packaging Practices" is out of date and should be updated. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065312 > where "apt-mark auto ..." (for autoremove) is suggested as a > replacement. But with it, putting transition packages to oldlibs > is even more necessary. thanks for filing this bug report. Patches are very welcome, it's all mark down now. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ So what CAN we actually do? Well, individual decisions (eating less meat, taking public transport, buying less fast fashion) are all important, but we also need to change the system. As you may know, just 100 companies are responsible for 71% of global emissions. (@JessicaTheLaw) https://www.theguardian.com/sustainable-business/2017/jul/10/100-fossil-fuel-companies-investors-responsible-71-global-emissions-cdp-study-climate-change signature.asc Description: PGP signature
Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"
Hi Vincent, On Wed, Apr 17, 2024 at 04:24:16AM +0200, Vincent Lefevre wrote: > Now that the deborphan package has been removed from unstable, > the section "Make transition packages deborphan compliant" in > "Best Packaging Practices" is out of date and should be updated. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065312 > where "apt-mark auto ..." (for autoremove) is suggested as a > replacement. But with it, putting transition packages to oldlibs > is even more necessary. thanks for filing this bug report. Patches are very welcome, it's all mark down now. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ So what CAN we actually do? Well, individual decisions (eating less meat, taking public transport, buying less fast fashion) are all important, but we also need to change the system. As you may know, just 100 companies are responsible for 71% of global emissions. (@JessicaTheLaw) https://www.theguardian.com/sustainable-business/2017/jul/10/100-fossil-fuel-companies-investors-responsible-71-global-emissions-cdp-study-climate-change signature.asc Description: PGP signature
Bug#1068890: diffoscope: --hard-timeout option
On Tue, Apr 16, 2024 at 04:51:09PM +0100, Chris Lamb wrote: > Just to say that I am totally on board with the idea of ensuring we > get _something_ out of diffoscope on tests.reproducible-builds.org. :) great! > Way better than 250 timeouts. https://tests.reproducible-builds.org/debian/stats_breakages.png showed that in the last 3-4 years there was constant progress on that! \o/ > However, I think this first iteration of --hard-timeout time has a few > things that would need ironing out first, and potentially make it not > worth implementing: > > (1) You suggest it should start again with "--max-container-depth 3", > but it would surely need some syntax (or another option?) to control > that "3" (but for the second time only). another option, --second-pass-max-container-depth or some such > (2) In fact, its easy to imagine that one would want to restart with > other restrictions as well: not just --max-container-depth. For > instance, excluding external commands like readelf and objdump that > you know to be slow. yes, that's a good idea and IMO should be automatically implied for the 2nd pass or round or try. > (3) The output might need some comment saying "this was re-run with > restrictions as we hit a timeout". absolutly. > (4) My gut feel that it would not be all that great to rely on CPython > to really properly clear up child processes after a certain amount of > time. Although I believe the most reliable top-level description to do > this kind of thing inside CPython is to start a watchdog thread that > sleeps until the timeout and then tries to kill everything, but my > experience of doing anything like this within Python itself is not > great, and essentially always needed something at the process level > outside of it for it to be reliable. A container would be even more > effective, I'm sure. hmmm. > In other words, I think the best way of achieving the result we want > is, alas, by doing it outside of diffoscope at the level of the > Jenkins. As in, exactly what you describe here: > > > Else we could also extend the current code for tests.r-b.o/debian, > > which currently > > just kills diffoscope after 2h, to then run diffoscope > > --max-container-depth 3 :) > > Is that a massive faff? :/ not really, I guess it would be rather simple even, I just thought (or think?) that it would be a nice feature for diffoscope proper. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The purpose of propaganda isn't to make you believe something. It's to make you believe nothing. So that you do nothing. (@DarthPutinKGB) signature.asc Description: PGP signature
Bug#1068890: diffoscope: --hard-timeout option
On Tue, Apr 16, 2024 at 04:51:09PM +0100, Chris Lamb wrote: > Just to say that I am totally on board with the idea of ensuring we > get _something_ out of diffoscope on tests.reproducible-builds.org. :) great! > Way better than 250 timeouts. https://tests.reproducible-builds.org/debian/stats_breakages.png showed that in the last 3-4 years there was constant progress on that! \o/ > However, I think this first iteration of --hard-timeout time has a few > things that would need ironing out first, and potentially make it not > worth implementing: > > (1) You suggest it should start again with "--max-container-depth 3", > but it would surely need some syntax (or another option?) to control > that "3" (but for the second time only). another option, --second-pass-max-container-depth or some such > (2) In fact, its easy to imagine that one would want to restart with > other restrictions as well: not just --max-container-depth. For > instance, excluding external commands like readelf and objdump that > you know to be slow. yes, that's a good idea and IMO should be automatically implied for the 2nd pass or round or try. > (3) The output might need some comment saying "this was re-run with > restrictions as we hit a timeout". absolutly. > (4) My gut feel that it would not be all that great to rely on CPython > to really properly clear up child processes after a certain amount of > time. Although I believe the most reliable top-level description to do > this kind of thing inside CPython is to start a watchdog thread that > sleeps until the timeout and then tries to kill everything, but my > experience of doing anything like this within Python itself is not > great, and essentially always needed something at the process level > outside of it for it to be reliable. A container would be even more > effective, I'm sure. hmmm. > In other words, I think the best way of achieving the result we want > is, alas, by doing it outside of diffoscope at the level of the > Jenkins. As in, exactly what you describe here: > > > Else we could also extend the current code for tests.r-b.o/debian, > > which currently > > just kills diffoscope after 2h, to then run diffoscope > > --max-container-depth 3 :) > > Is that a massive faff? :/ not really, I guess it would be rather simple even, I just thought (or think?) that it would be a nice feature for diffoscope proper. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The purpose of propaganda isn't to make you believe something. It's to make you believe nothing. So that you do nothing. (@DarthPutinKGB) signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: debian-backports missing packages
hi, I was told by formorer that there will be announcement about this change later today, as well as an update to the documentation. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Kinda weird that we’re all gonna experience climate change as a series of short, apocalyptic videos until eventually it’s your phone that’s recording. (@shocks) signature.asc Description: PGP signature
Re: debian-backports missing packages
hi, I was told by formorer that there will be announcement about this change later today, as well as an update to the documentation. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Kinda weird that we’re all gonna experience climate change as a series of short, apocalyptic videos until eventually it’s your phone that’s recording. (@shocks) signature.asc Description: PGP signature
Bug#1069100: libscout.jar has duplicate ZIP entries in the central directory
Package: libscout Version: 2.3.2-3 Severity: normal X-Debbugs-Cc: reproducible-bui...@alioth-lists.debian.net, Fay Stegerman Dear Maintainer, a few days ago I filed "#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye" which then led Fay Stegerman to discover than src:libscout builds a libscout.jar that has duplicate ZIP entries in the central directory, pointing to the same actual entry in the ZIP. Please don't do this. #1068705 has been fixed in the meantime and diffoscope 264 can now correctly display the differences, as can be seen in https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/libscout.html this is still an incorrect and broken zip file. Thanks for maintaining libscout! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ I miss the old days were billionaires’ vanity projects were to build 1000 public libraries or giant music venues. signature.asc Description: PGP signature
Bug#1069100: libscout.jar has duplicate ZIP entries in the central directory
Package: libscout Version: 2.3.2-3 Severity: normal X-Debbugs-Cc: reproducible-builds@alioth-lists.debian.net, Fay Stegerman Dear Maintainer, a few days ago I filed "#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye" which then led Fay Stegerman to discover than src:libscout builds a libscout.jar that has duplicate ZIP entries in the central directory, pointing to the same actual entry in the ZIP. Please don't do this. #1068705 has been fixed in the meantime and diffoscope 264 can now correctly display the differences, as can be seen in https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/libscout.html this is still an incorrect and broken zip file. Thanks for maintaining libscout! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ I miss the old days were billionaires’ vanity projects were to build 1000 public libraries or giant music venues. signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
On Mon, Apr 15, 2024 at 03:00:42PM +0200, Fay Stegerman wrote: > > (thanks again!), am I correct to assume that thus there's no need > > to file a seperate bug against libscout? > It's generating a broken ZIP file with duplicate entries. It really shouldn't > be doing that, regardless of whether we can extract the files nonetheless. > That's still a bug that should be reported and fixed. ok, will do, mostly using this bug as reference, thanks! > > (which is nice, though maybe could only been shown once?) > Ah. It correctly shows that twice as there could be differences between the > two > files being compared wrt whether they have duplicate entries (and if so how > many). > > And if you run 'diffoscope foo.zip bar.zip' it'll show those two different > file > names. But in this case we have nested archives and the path (and in this > case > also the number of duplicate entries) is identical for both, so maybe we can > tweak the output to show which top-level file it belongs to? yes. :) > > though this later is done using diffoscope from unstable while the > > rest of the userland is bullseye, so this might be expected as well? > Ah. Looks like zipdetails(1) on bullseye doesn't support the --redact, > --scan, > and --utc options yet. right, thanks for confirming in detail! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
On Mon, Apr 15, 2024 at 03:00:42PM +0200, Fay Stegerman wrote: > > (thanks again!), am I correct to assume that thus there's no need > > to file a seperate bug against libscout? > It's generating a broken ZIP file with duplicate entries. It really shouldn't > be doing that, regardless of whether we can extract the files nonetheless. > That's still a bug that should be reported and fixed. ok, will do, mostly using this bug as reference, thanks! > > (which is nice, though maybe could only been shown once?) > Ah. It correctly shows that twice as there could be differences between the > two > files being compared wrt whether they have duplicate entries (and if so how > many). > > And if you run 'diffoscope foo.zip bar.zip' it'll show those two different > file > names. But in this case we have nested archives and the path (and in this > case > also the number of duplicate entries) is identical for both, so maybe we can > tweak the output to show which top-level file it belongs to? yes. :) > > though this later is done using diffoscope from unstable while the > > rest of the userland is bullseye, so this might be expected as well? > Ah. Looks like zipdetails(1) on bullseye doesn't support the --redact, > --scan, > and --utc options yet. right, thanks for confirming in detail! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: debina-backports missing packages
On Tue, Apr 16, 2024 at 02:09:21AM -0400, Boyuan Yang wrote: > [...] Can I expect > the homepage and the Packages page to be updated soon? sooner if you provide patches. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Try to imagine a future where paying for your morning coffee involved smashing an iPhone and burning enough fossil fuels to run your entire household for 60 days. That's the environmental cost of the "revolutionary" technology behind Bitcoin in a nutshell. https://twitter.com/smdiehl/status/1350869944888664064 signature.asc Description: PGP signature
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
Hi again,
I've got two remaining questions about libscout (and diffoscope)
On Thu, Apr 11, 2024 at 01:48:18AM +0200, Fay Stegerman wrote:
> unzip does seem to extract all the files, though it errors out. Not sure what
> diffoscope should do here. This is definitely a broken ZIP file. That bug
> should probably be reported against libscout or whatever tooling it used to
> create that JAR.
you filed https://github.com/python/cpython/issues/117779
(thanks again!), am I correct to assume that thus there's no need
to file a seperate bug against libscout?
and 2nd,
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/libscout.html
now as expected displays:
'./usr/share/java/libscout.jar' has 35 duplicate entries
'./usr/share/java/libscout.jar' has 35 duplicate entries
(which is nice, though maybe could only been shown once?)
but
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/arm64/diffoscope-results/libscout.html
shows this:
Command `'zipdetails --redact --scan --utc {}'` failed with exit code 255.
Standard output:
zipdetails [OPTIONS] file
Display details about the internal structure of a Zip file.
This is zipdetails version 1.11
OPTIONS
-h display help
-v Verbose - output more stuff
[...]
Archive contents identical but files differ, possibly due to different
compression levels. Falling back to binary comparison.
'./usr/share/java/libscout.jar' has 35 duplicate entries
'./usr/share/java/libscout.jar' has 35 duplicate entries
though this later is done using diffoscope from unstable while the
rest of the userland is bullseye, so this might be expected as well?
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
:wq
signature.asc
Description: PGP signature
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
Hi again,
I've got two remaining questions about libscout (and diffoscope)
On Thu, Apr 11, 2024 at 01:48:18AM +0200, Fay Stegerman wrote:
> unzip does seem to extract all the files, though it errors out. Not sure what
> diffoscope should do here. This is definitely a broken ZIP file. That bug
> should probably be reported against libscout or whatever tooling it used to
> create that JAR.
you filed https://github.com/python/cpython/issues/117779
(thanks again!), am I correct to assume that thus there's no need
to file a seperate bug against libscout?
and 2nd,
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/libscout.html
now as expected displays:
'./usr/share/java/libscout.jar' has 35 duplicate entries
'./usr/share/java/libscout.jar' has 35 duplicate entries
(which is nice, though maybe could only been shown once?)
but
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/arm64/diffoscope-results/libscout.html
shows this:
Command `'zipdetails --redact --scan --utc {}'` failed with exit code 255.
Standard output:
zipdetails [OPTIONS] file
Display details about the internal structure of a Zip file.
This is zipdetails version 1.11
OPTIONS
-h display help
-v Verbose - output more stuff
[...]
Archive contents identical but files differ, possibly due to different
compression levels. Falling back to binary comparison.
'./usr/share/java/libscout.jar' has 35 duplicate entries
'./usr/share/java/libscout.jar' has 35 duplicate entries
though this later is done using diffoscope from unstable while the
rest of the userland is bullseye, so this might be expected as well?
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
:wq
signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#877337: single-page html of debian-policy to be revived?
On Sun, Apr 14, 2024 at 08:43:51PM +0800, Sean Whitton wrote: > ... but if dev-ref is already shipping both, maybe singlepage is indeed > usable these days ... I think it is. > > Could the Policy Editors team check, if everything is fine now, and if > > this should be published again? > > At least there is still an issue with the footnotes, there are 16 > > occurrences > > of #id1 for example... (search for "[1]" in policy-1.html). > Hrm. That seems like a pretty serious problem :\ I wouldnt call it serious. annoying yes, maybe. > Holger L., did you know about this issue? > Did you decide it was worth publishing anyway? yes. https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages or (single page) https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages both show four footnotes, right where they belong, it's just that each foot note is numbered and that [1] or [2] or whatever is a link, pointing to a wrong place. I agree it's a bug, but I do think it's a pretty harmless one. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "Any fool can know. The point is to understand." - A. Einstein signature.asc Description: PGP signature
Bug#877337: single-page html of debian-policy to be revived?
On Sun, Apr 14, 2024 at 08:43:51PM +0800, Sean Whitton wrote: > ... but if dev-ref is already shipping both, maybe singlepage is indeed > usable these days ... I think it is. > > Could the Policy Editors team check, if everything is fine now, and if > > this should be published again? > > At least there is still an issue with the footnotes, there are 16 > > occurrences > > of #id1 for example... (search for "[1]" in policy-1.html). > Hrm. That seems like a pretty serious problem :\ I wouldnt call it serious. annoying yes, maybe. > Holger L., did you know about this issue? > Did you decide it was worth publishing anyway? yes. https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages or (single page) https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages both show four footnotes, right where they belong, it's just that each foot note is numbered and that [1] or [2] or whatever is a link, pointing to a wrong place. I agree it's a bug, but I do think it's a pretty harmless one. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "Any fool can know. The point is to understand." - A. Einstein signature.asc Description: PGP signature
Re: single-page html of debian-policy to be revived?
On Sun, Apr 14, 2024 at 08:43:51PM +0800, Sean Whitton wrote: > ... but if dev-ref is already shipping both, maybe singlepage is indeed > usable these days ... I think it is. > > Could the Policy Editors team check, if everything is fine now, and if > > this should be published again? > > At least there is still an issue with the footnotes, there are 16 > > occurrences > > of #id1 for example... (search for "[1]" in policy-1.html). > Hrm. That seems like a pretty serious problem :\ I wouldnt call it serious. annoying yes, maybe. > Holger L., did you know about this issue? > Did you decide it was worth publishing anyway? yes. https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages or (single page) https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages both show four footnotes, right where they belong, it's just that each foot note is numbered and that [1] or [2] or whatever is a link, pointing to a wrong place. I agree it's a bug, but I do think it's a pretty harmless one. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "Any fool can know. The point is to understand." - A. Einstein signature.asc Description: PGP signature
Bug#1068890: diffoscope: --hard-timeout option
Package: diffoscope Version: 264 Severity: wishlist Dear Maintainer, currenlty diffoscope has a --timeout option --timeout SECONDS Best-effort attempt at a global timeout in seconds. If enabled, diffoscope will not recurse into any further sub-archives after X seconds of total execution time. (default: no timeout) [experimental] however this doesnt give any guarantees how long diffoscope will be running, so so far we haven't used it for the RB CI tests, mostly because I'm not sure what would be a good inner timeout (=for diffoscope) and what would be a good good outer timeout (=for killing diffoscope from the outside no matter what). Currently we use 2h as outer timeout, but have no inner timeout. Maybe we should use --timeout 1h? Anyhow, about my --hard-timeout option idea: my idea of "--hard-timeout $time" is that diffoscope terminates itself after $time, no matter what *and* then re-starts itself with "--max-container-depth 3" (or whatever is useful to get a glimpse on what files in a Debian package are different) (probably also with another hard timeout set...) as to guarantee to always produce meaningful output (especially html output if specified with --html). What do you think? Else we could also extend the current code for tests.r-b.o/debian, which currently just kills diffoscope after 2h, to then run diffoscope --max-container-depth 3 :) https://tests.reproducible-builds.org/debian/index_breakages.html lists 251 pkg/suite/arch combinations where diffoscope runs into a timeout... & many thanks for rocking diffoscope airlines..! \o/ -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Bottled water companies don't produce water, they produce plastic bottles. signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068890: diffoscope: --hard-timeout option
Package: diffoscope Version: 264 Severity: wishlist Dear Maintainer, currenlty diffoscope has a --timeout option --timeout SECONDS Best-effort attempt at a global timeout in seconds. If enabled, diffoscope will not recurse into any further sub-archives after X seconds of total execution time. (default: no timeout) [experimental] however this doesnt give any guarantees how long diffoscope will be running, so so far we haven't used it for the RB CI tests, mostly because I'm not sure what would be a good inner timeout (=for diffoscope) and what would be a good good outer timeout (=for killing diffoscope from the outside no matter what). Currently we use 2h as outer timeout, but have no inner timeout. Maybe we should use --timeout 1h? Anyhow, about my --hard-timeout option idea: my idea of "--hard-timeout $time" is that diffoscope terminates itself after $time, no matter what *and* then re-starts itself with "--max-container-depth 3" (or whatever is useful to get a glimpse on what files in a Debian package are different) (probably also with another hard timeout set...) as to guarantee to always produce meaningful output (especially html output if specified with --html). What do you think? Else we could also extend the current code for tests.r-b.o/debian, which currently just kills diffoscope after 2h, to then run diffoscope --max-container-depth 3 :) https://tests.reproducible-builds.org/debian/index_breakages.html lists 251 pkg/suite/arch combinations where diffoscope runs into a timeout... & many thanks for rocking diffoscope airlines..! \o/ -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Bottled water companies don't produce water, they produce plastic bottles. signature.asc Description: PGP signature
Bug#1068853: reprotest: SyntaxWarning: invalid escape sequence '\;'
On Fri, Apr 12, 2024 at 10:29:07AM -0700, Vagrant Cascadian wrote:
> How exactly did you get this error?
upgrading my sid schroot. just confirmed the bug by removing it there
and installing it again. then I mounted /proc but the bug is still
there. /dev is also populated, though /usr/bin/mount fails with
"mount: failed to read mtab: No such file or directory".
> I installed locally, but did not encounter any such issues on package
> installation just now, and also nothing when manually running a simple
> test:
>
> reprotest 'date > date' date
that also fails verbosely here:
$ schroot -- reprotest 'date > date' date
WARNING:reprotest:The control build runs on 1 CPU by default, give --min-cpus
to increase this.
WARNING:reprotest.build:IGNORING user_group variation; supply more usergroups
with --variations=user_group.available+=USER1:GROUP1;USER2:GROUP2 or
alternatively, suppress this warning with --variations=-user_group
WARNING:reprotest.build:Not using sudo for domain_host; your build may fail.
See man page for other options.
WARNING:reprotest.build:Be sure to `echo 1 >
/proc/sys/kernel/unprivileged_userns_clone` if on a Debian system.
fusermount: failed to open /etc/mtab: No such file or directory
fusermount: mount failed: Operation not permitted
fusermount: failed to unmount /tmp/reprotest.AQkTKX/build-experiment-1:
Operation not permitted
cleanup failed with exit code 1
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 862, in run
return 0 if check_func(*check_args) else 1
^^^
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 379, in
check
local_dists += [proc.send(nv) for nv in zip(bnames[1:],
build_variations[1:])]
^^^
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 379, in
local_dists += [proc.send(nv) for nv in zip(bnames[1:],
build_variations[1:])]
^
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 339, in
corun_builds
bctx.run_build(testbed, build, os.environ, artifact_pattern,
testbed_build_pre, no_clean_on_error)
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 218, in
run_build
testbed.check_exec2(build_argv,
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 63, in
check_exec2
self.bomb('"%s" failed with status %i' % (' '.join(argv), code),
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 70, in bomb
raise _type(m)
reprotest.lib.adtlog.AutopkgtestError: "sh -ec run_build() {
mkdir -p /tmp/reprotest.AQkTKX/build-experiment-1-aux && \
SETARCH_ARCH=$(for a in $(setarch --list); do setarch $a true && echo $a ||
true; done) && \
DROP_ARCH="-v -e ^$(uname -m)\$" && \
WORDSIZE=64 && \
if [ $WORDSIZE -eq 64 ]; then for _ARCH_TO_DROP in armh armv7b armv7l
armv8b armv8l arm athlon i386 i486 i586 i686 linux32 mips32 mips
parisc32 parisc ppc32le ppc32 ppcle ppc s390 sparc32bash
sparc32 sparc; do DROP_ARCH="$DROP_ARCH -e ^$_ARCH_TO_DROP\$";
done; fi && \
SETARCH_ARCH=$(echo "$SETARCH_ARCH" | grep $DROP_ARCH | shuf -n1) && \
KERNEL_VERSION=$(uname -r) && \
if [ ${KERNEL_VERSION#2.6} = $KERNEL_VERSION ]; then
SETARCH_OPTS=--uname-2.6; fi && \
CPU_MAX=$(nproc) && \
CPU_MIN=$({ echo $CPU_MAX; echo 1; } | sort -n | head -n1) && \
CPU_NUM=$(if [ $CPU_MIN = $CPU_MAX ]; then echo $CPU_MIN; echo
>&2 "only 1 CPU is available; num_cpus is ineffective"; else shuf
-i$((CPU_MIN + 1))-$CPU_MAX -n1; fi) && \
export CPU_LIST="$(echo $(shuf -i0-$((CPU_MAX - 1)) -n$CPU_NUM) | tr ' '
,)" && \
mv /tmp/reprotest.AQkTKX/build-experiment-1/
/tmp/reprotest.AQkTKX/build-experiment-1-before-disorderfs/ && \
mkdir -p /tmp/reprotest.AQkTKX/build-experiment-1/ && \
disorderfs -q --shuffle-dirents=yes
/tmp/reprotest.AQkTKX/build-experiment-1-before-disorderfs/
/tmp/reprotest.AQkTKX/build-experiment-1/ && \
umask 0002 && \
export REPROTEST_BUILD_PATH=/tmp/reprotest.AQkTKX/build-experiment-1/ && \
export REPROTEST_UMASK=$(umask) && \
unshare -r --uts sh -ec '
hostname reprotest-capture-hostname
domainname "reprotest-capture-domainname"
"$@"' - \
faketime +398days+2hours+27minutes \
taskset -a -c $CPU_LIST \
setarch $SETARCH_ARCH $SETARCH_OPTS \
sh -ec 'cd "$REPROTEST_BUILD_PATH"; unset REPROTEST_BUILD_PATH; umask
"$REPROTEST_UMASK"; unset REPROTEST_UMASK; date > date'
}
cleanup() {
__c=0; \
export PATH="/tmp/reprotest.AQkTKX/bin:$PATH" || __c=$?; \
fusermount -u /tmp/reprotest.AQkTKX/build-experiment-1/ || __c=$?; \
rmdir /tmp/reprotest.AQkTKX/build-experiment-1/ || __c=$?; \
mv /tmp/reprotest.AQkTKX/build-experiment-1-before-disorderfs/
Bug#1068853: reprotest: SyntaxWarning: invalid escape sequence '\;'
On Fri, Apr 12, 2024 at 10:29:07AM -0700, Vagrant Cascadian wrote:
> How exactly did you get this error?
upgrading my sid schroot. just confirmed the bug by removing it there
and installing it again. then I mounted /proc but the bug is still
there. /dev is also populated, though /usr/bin/mount fails with
"mount: failed to read mtab: No such file or directory".
> I installed locally, but did not encounter any such issues on package
> installation just now, and also nothing when manually running a simple
> test:
>
> reprotest 'date > date' date
that also fails verbosely here:
$ schroot -- reprotest 'date > date' date
WARNING:reprotest:The control build runs on 1 CPU by default, give --min-cpus
to increase this.
WARNING:reprotest.build:IGNORING user_group variation; supply more usergroups
with --variations=user_group.available+=USER1:GROUP1;USER2:GROUP2 or
alternatively, suppress this warning with --variations=-user_group
WARNING:reprotest.build:Not using sudo for domain_host; your build may fail.
See man page for other options.
WARNING:reprotest.build:Be sure to `echo 1 >
/proc/sys/kernel/unprivileged_userns_clone` if on a Debian system.
fusermount: failed to open /etc/mtab: No such file or directory
fusermount: mount failed: Operation not permitted
fusermount: failed to unmount /tmp/reprotest.AQkTKX/build-experiment-1:
Operation not permitted
cleanup failed with exit code 1
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 862, in run
return 0 if check_func(*check_args) else 1
^^^
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 379, in
check
local_dists += [proc.send(nv) for nv in zip(bnames[1:],
build_variations[1:])]
^^^
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 379, in
local_dists += [proc.send(nv) for nv in zip(bnames[1:],
build_variations[1:])]
^
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 339, in
corun_builds
bctx.run_build(testbed, build, os.environ, artifact_pattern,
testbed_build_pre, no_clean_on_error)
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 218, in
run_build
testbed.check_exec2(build_argv,
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 63, in
check_exec2
self.bomb('"%s" failed with status %i' % (' '.join(argv), code),
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 70, in bomb
raise _type(m)
reprotest.lib.adtlog.AutopkgtestError: "sh -ec run_build() {
mkdir -p /tmp/reprotest.AQkTKX/build-experiment-1-aux && \
SETARCH_ARCH=$(for a in $(setarch --list); do setarch $a true && echo $a ||
true; done) && \
DROP_ARCH="-v -e ^$(uname -m)\$" && \
WORDSIZE=64 && \
if [ $WORDSIZE -eq 64 ]; then for _ARCH_TO_DROP in armh armv7b armv7l
armv8b armv8l arm athlon i386 i486 i586 i686 linux32 mips32 mips
parisc32 parisc ppc32le ppc32 ppcle ppc s390 sparc32bash
sparc32 sparc; do DROP_ARCH="$DROP_ARCH -e ^$_ARCH_TO_DROP\$";
done; fi && \
SETARCH_ARCH=$(echo "$SETARCH_ARCH" | grep $DROP_ARCH | shuf -n1) && \
KERNEL_VERSION=$(uname -r) && \
if [ ${KERNEL_VERSION#2.6} = $KERNEL_VERSION ]; then
SETARCH_OPTS=--uname-2.6; fi && \
CPU_MAX=$(nproc) && \
CPU_MIN=$({ echo $CPU_MAX; echo 1; } | sort -n | head -n1) && \
CPU_NUM=$(if [ $CPU_MIN = $CPU_MAX ]; then echo $CPU_MIN; echo
>&2 "only 1 CPU is available; num_cpus is ineffective"; else shuf
-i$((CPU_MIN + 1))-$CPU_MAX -n1; fi) && \
export CPU_LIST="$(echo $(shuf -i0-$((CPU_MAX - 1)) -n$CPU_NUM) | tr ' '
,)" && \
mv /tmp/reprotest.AQkTKX/build-experiment-1/
/tmp/reprotest.AQkTKX/build-experiment-1-before-disorderfs/ && \
mkdir -p /tmp/reprotest.AQkTKX/build-experiment-1/ && \
disorderfs -q --shuffle-dirents=yes
/tmp/reprotest.AQkTKX/build-experiment-1-before-disorderfs/
/tmp/reprotest.AQkTKX/build-experiment-1/ && \
umask 0002 && \
export REPROTEST_BUILD_PATH=/tmp/reprotest.AQkTKX/build-experiment-1/ && \
export REPROTEST_UMASK=$(umask) && \
unshare -r --uts sh -ec '
hostname reprotest-capture-hostname
domainname "reprotest-capture-domainname"
"$@"' - \
faketime +398days+2hours+27minutes \
taskset -a -c $CPU_LIST \
setarch $SETARCH_ARCH $SETARCH_OPTS \
sh -ec 'cd "$REPROTEST_BUILD_PATH"; unset REPROTEST_BUILD_PATH; umask
"$REPROTEST_UMASK"; unset REPROTEST_UMASK; date > date'
}
cleanup() {
__c=0; \
export PATH="/tmp/reprotest.AQkTKX/bin:$PATH" || __c=$?; \
fusermount -u /tmp/reprotest.AQkTKX/build-experiment-1/ || __c=$?; \
rmdir /tmp/reprotest.AQkTKX/build-experiment-1/ || __c=$?; \
mv /tmp/reprotest.AQkTKX/build-experiment-1-before-disorderfs/
Re: finally end single-person maintainership
On Fri, Apr 12, 2024 at 09:53:29AM +0100, Jonathan Dowland wrote: > On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote: [...] > I agree with everything you say here! :) > Wrt git-buildpackage, I'd like to add that personally, I respect the gbp > authors and maintainers and it's a very useful tool to bring together > some complex workflows and in particular successfully move a lot of > people over from svn-buildpackage. absolutly. > I do however agree that there's too much magic. Some of that is > inherited from the Debian-specific tooling it sits on top of: I also > think there's too much magic and/or complexity in debuild and > dpkg-buildpackage. absolutly. Thanks for these additions! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ “I'll tell you what freedom is to me No fear.” (Nina Simone) signature.asc Description: PGP signature
Bug#1068853: reprotest: SyntaxWarning: invalid escape sequence '\;'
Package: reprotest
Version: 0.7.27
Severity: important
Dear Maintainer,
when installing reprotest 0.7.27:
SyntaxWarning: invalid escape sequence '\;'
Setting up reprotest (0.7.27) ...
/usr/lib/python3/dist-packages/reprotest/__init__.py:360: SyntaxWarning:
invalid escape sequence '\;'
run_or_tee(['sh', '-ec', 'find %s -type f -exec sha256sum "{}" \;' %
self.artifact_pattern],
/usr/lib/python3/dist-packages/reprotest/build.py:315: SyntaxWarning: invalid
escape sequence '\$'
_ = _.append_setup_exec_raw('DROP_ARCH="-v -e ^$(uname -m)\$"')
/usr/lib/python3/dist-packages/reprotest/build.py:317: SyntaxWarning: invalid
escape sequence '\$'
_ = _.append_setup_exec_raw('if [ $WORDSIZE -eq 64 ]; then \
/usr/lib/python3/dist-packages/reprotest/environ.py:10: SyntaxWarning: invalid
escape sequence '\w'
"path": "(/\w{1,12}){1,4}",
/usr/lib/python3/dist-packages/reprotest/environ.py:11: SyntaxWarning: invalid
escape sequence '\d'
"port": "([1-9]\d{0,3}|[1-5]\d{4})",
/usr/lib/python3/dist-packages/reprotest/environ.py:12: SyntaxWarning: invalid
escape sequence '\w'
"domain": "\w{1,10}(\.\w{1,10}){0,3}",
/usr/lib/python3/dist-packages/reprotest/environ.py:13: SyntaxWarning: invalid
escape sequence '\w'
"password": "\w{1,40}",
/usr/lib/python3/dist-packages/reprotest/environ.py:14: SyntaxWarning: invalid
escape sequence '\w'
"username": "\w{2,20}",
/usr/lib/python3/dist-packages/reprotest/environ.py:113: SyntaxWarning: invalid
escape sequence '\w'
"REPROTEST_CAPTURE_ENVIRONMENT_UNKNOWN_\w+"]
/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:305: SyntaxWarning:
invalid escape sequence '\['
script = '''sed -rn 's/^(deb|deb-src) +(\[.*\] *)?([^
]*(ubuntu.com|debian.org|ftpmaster|file:\/\/\/tmp\/testarchive)[^ ]*) +([^ -]+)
+(.*)$/\\1 \\2\\3 \\5-%s \\6/p' /etc/apt/sources.list `ls
/etc/apt/sources.list.d/*.list 2>/dev/null|| true` >
/etc/apt/sources.list.d/%s.list; for retry in 1 2 3; do apt-get
--no-list-cleanup -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/%s.list -o
Dir::Etc::sourceparts=/dev/null update 2>&1 && break || sleep 15; done''' %
(pocket, pocket, pocket)
/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:320: SyntaxWarning:
invalid escape sequence '\/'
'for d in %s; do [ ! -d $d ] || touch -r $d %s/${d//\//_}.stamp; done' % (
/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:342: SyntaxWarning:
invalid escape sequence '\/'
'for d in %s; do s=%s/${d//\//_}.stamp;'
/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:724: SyntaxWarning:
invalid escape sequence '\('
script = '''d=%(t)s/deps
/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:1211:
SyntaxWarning: invalid escape sequence '\/'
script += '''REL=$(sed -rn '/^(deb|deb-src)
.*(ubuntu.com|debian.org|ftpmaster|file:\/\/\/tmp\/testarchive)/ { s/^[^ ]+
+(\[.*\] *)?[^ ]* +([^ -]+) +.*$/\\2/p}' $SRCS | head -n1); '''
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
The devel is in the details.
signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068853: reprotest: SyntaxWarning: invalid escape sequence '\;'
Package: reprotest
Version: 0.7.27
Severity: important
Dear Maintainer,
when installing reprotest 0.7.27:
SyntaxWarning: invalid escape sequence '\;'
Setting up reprotest (0.7.27) ...
/usr/lib/python3/dist-packages/reprotest/__init__.py:360: SyntaxWarning:
invalid escape sequence '\;'
run_or_tee(['sh', '-ec', 'find %s -type f -exec sha256sum "{}" \;' %
self.artifact_pattern],
/usr/lib/python3/dist-packages/reprotest/build.py:315: SyntaxWarning: invalid
escape sequence '\$'
_ = _.append_setup_exec_raw('DROP_ARCH="-v -e ^$(uname -m)\$"')
/usr/lib/python3/dist-packages/reprotest/build.py:317: SyntaxWarning: invalid
escape sequence '\$'
_ = _.append_setup_exec_raw('if [ $WORDSIZE -eq 64 ]; then \
/usr/lib/python3/dist-packages/reprotest/environ.py:10: SyntaxWarning: invalid
escape sequence '\w'
"path": "(/\w{1,12}){1,4}",
/usr/lib/python3/dist-packages/reprotest/environ.py:11: SyntaxWarning: invalid
escape sequence '\d'
"port": "([1-9]\d{0,3}|[1-5]\d{4})",
/usr/lib/python3/dist-packages/reprotest/environ.py:12: SyntaxWarning: invalid
escape sequence '\w'
"domain": "\w{1,10}(\.\w{1,10}){0,3}",
/usr/lib/python3/dist-packages/reprotest/environ.py:13: SyntaxWarning: invalid
escape sequence '\w'
"password": "\w{1,40}",
/usr/lib/python3/dist-packages/reprotest/environ.py:14: SyntaxWarning: invalid
escape sequence '\w'
"username": "\w{2,20}",
/usr/lib/python3/dist-packages/reprotest/environ.py:113: SyntaxWarning: invalid
escape sequence '\w'
"REPROTEST_CAPTURE_ENVIRONMENT_UNKNOWN_\w+"]
/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:305: SyntaxWarning:
invalid escape sequence '\['
script = '''sed -rn 's/^(deb|deb-src) +(\[.*\] *)?([^
]*(ubuntu.com|debian.org|ftpmaster|file:\/\/\/tmp\/testarchive)[^ ]*) +([^ -]+)
+(.*)$/\\1 \\2\\3 \\5-%s \\6/p' /etc/apt/sources.list `ls
/etc/apt/sources.list.d/*.list 2>/dev/null|| true` >
/etc/apt/sources.list.d/%s.list; for retry in 1 2 3; do apt-get
--no-list-cleanup -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/%s.list -o
Dir::Etc::sourceparts=/dev/null update 2>&1 && break || sleep 15; done''' %
(pocket, pocket, pocket)
/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:320: SyntaxWarning:
invalid escape sequence '\/'
'for d in %s; do [ ! -d $d ] || touch -r $d %s/${d//\//_}.stamp; done' % (
/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:342: SyntaxWarning:
invalid escape sequence '\/'
'for d in %s; do s=%s/${d//\//_}.stamp;'
/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:724: SyntaxWarning:
invalid escape sequence '\('
script = '''d=%(t)s/deps
/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:1211:
SyntaxWarning: invalid escape sequence '\/'
script += '''REL=$(sed -rn '/^(deb|deb-src)
.*(ubuntu.com|debian.org|ftpmaster|file:\/\/\/tmp\/testarchive)/ { s/^[^ ]+
+(\[.*\] *)?[^ ]* +([^ -]+) +.*$/\\2/p}' $SRCS | head -n1); '''
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
The devel is in the details.
signature.asc
Description: PGP signature
Re: Please review the draft for March's report
Dear Chris et al, On Thu, Apr 11, 2024 at 07:52:39PM +0100, Chris Lamb wrote: > > Please review the draft for March's Reproducible Builds report: > This has now been published — thanks to all who contributed. great, thank you and everyone involved indeed! I also like the final order of the entries, though when I skimmed through https://reproducible-builds.org/reports/2024-03/ I wondered whether we should add a table of contents to the top of each post? What do y'all think? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Manchmal kommt der Wind von Lee. (Konny) signature.asc Description: PGP signature
Bug#1066340: marked as done (t4kcommon: FTBFS: linebreak.c:163:19: error: implicit declaration of function ‘u8_mbtouc_unsafe’ [-Werror=implicit-function-declaration])
Dear Chris, On Thu, Apr 11, 2024 at 05:51:05PM +, Debian Bug Tracking System wrote: > Date: Thu, 11 Apr 2024 17:50:02 + > From: Debian FTP Masters > To: 1066340-cl...@bugs.debian.org > Subject: Bug#1066340: fixed in t4kcommon 0.1.1-11.2 > Reply-To: Chris Hofstaedtler thanks for that NMU, much appreciated! <3 -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Because things are the way they are, things will not stay the way they are. (Bertolt Brecht) signature.asc Description: PGP signature
Bug#1066340: marked as done (t4kcommon: FTBFS: linebreak.c:163:19: error: implicit declaration of function ‘u8_mbtouc_unsafe’ [-Werror=implicit-function-declaration])
Dear Chris, On Thu, Apr 11, 2024 at 05:51:05PM +, Debian Bug Tracking System wrote: > Date: Thu, 11 Apr 2024 17:50:02 + > From: Debian FTP Masters > To: 1066340-cl...@bugs.debian.org > Subject: Bug#1066340: fixed in t4kcommon 0.1.1-11.2 > Reply-To: Chris Hofstaedtler thanks for that NMU, much appreciated! <3 -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Because things are the way they are, things will not stay the way they are. (Bertolt Brecht) signature.asc Description: PGP signature
Bug#1002458: "version in VCS newer than in repository" might be a bit overzealous
On Thu, Apr 11, 2024 at 03:02:05PM +0200, Christoph Berg wrote: > > additionally you could also only classify d/changelog changing commits > > with "Gbp-Dch: ignore" in them as such, but I'd guess Marc's suggestion > > really is good enough. > I don't understand, if debian/changelog-only commits are already > ignored, what should vcswatch do additionally? nothing. I ment it the other way around: if you were *not* willling to ignore debian/changelog-only commits maybe you'd be willing to ignore debian/changelog-only commits which also have "Gbp-Dch: ignore"/ but it seems you'd be fine to just ignore debian/changelog-only commits, so this is mood. > > Please reconsider, IOW, Myon: my I reassign this back to qa.debian.org > > for vcswatch? > Done. thank you! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If secure encryption is outlawed, only criminals will have it. signature.asc Description: PGP signature
Bug#1002458: "version in VCS newer than in repository" might be a bit overzealous
On Thu, Apr 11, 2024 at 03:02:05PM +0200, Christoph Berg wrote: > > additionally you could also only classify d/changelog changing commits > > with "Gbp-Dch: ignore" in them as such, but I'd guess Marc's suggestion > > really is good enough. > I don't understand, if debian/changelog-only commits are already > ignored, what should vcswatch do additionally? nothing. I ment it the other way around: if you were *not* willling to ignore debian/changelog-only commits maybe you'd be willing to ignore debian/changelog-only commits which also have "Gbp-Dch: ignore"/ but it seems you'd be fine to just ignore debian/changelog-only commits, so this is mood. > > Please reconsider, IOW, Myon: my I reassign this back to qa.debian.org > > for vcswatch? > Done. thank you! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If secure encryption is outlawed, only criminals will have it. signature.asc Description: PGP signature
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
On Thu, Apr 11, 2024 at 11:28:19AM +0100, Chris Lamb wrote: [...] > Applied in Git with attribution taken from your email. [...] > Fixed as well. And it adds a nice comment displaying the issue. awesome, thank you both! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make facts great again. signature.asc Description: PGP signature
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
On Thu, Apr 11, 2024 at 11:28:19AM +0100, Chris Lamb wrote: [...] > Applied in Git with attribution taken from your email. [...] > Fixed as well. And it adds a nice comment displaying the issue. awesome, thank you both! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make facts great again. signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors
On Thu, Apr 11, 2024 at 09:18:06AM +0200, Thomas Lange wrote: > A single page html may be an additional option but there's already the > single page txt version and the PDF. That's sufficient and I see no > need in providing more formats of this manual. > > Therefore we can close this and I will close 877337. fwiw, I disagree with this conclusion. single page txt and pdf versions are no replacements for single page html. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Another end of the world is possible. signature.asc Description: PGP signature
Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors
On Thu, Apr 11, 2024 at 09:18:06AM +0200, Thomas Lange wrote: > A single page html may be an additional option but there's already the > single page txt version and the PDF. That's sufficient and I see no > need in providing more formats of this manual. > > Therefore we can close this and I will close 877337. fwiw, I disagree with this conclusion. single page txt and pdf versions are no replacements for single page html. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Another end of the world is possible. signature.asc Description: PGP signature
Re: Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors
On Thu, Apr 11, 2024 at 09:18:06AM +0200, Thomas Lange wrote: > A single page html may be an additional option but there's already the > single page txt version and the PDF. That's sufficient and I see no > need in providing more formats of this manual. > > Therefore we can close this and I will close 877337. fwiw, I disagree with this conclusion. single page txt and pdf versions are no replacements for single page html. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Another end of the world is possible. signature.asc Description: PGP signature
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
On Thu, Apr 11, 2024 at 01:48:18AM +0200, Fay Stegerman wrote: > Salsa is probably better for figuring out what to do next, but I get these > mails > too :) :) > The libscout.jar has duplicate ZIP entries in the central directory, pointing > to > the same actual entry in the ZIP. So the "overlapped entries" error is > entirely > correct, even if it's not a zip bomb. ah! > unzip does seem to extract all the files, though it errors out. Not sure what > diffoscope should do here. This is definitely a broken ZIP file. That bug > should probably be reported against libscout or whatever tooling it used to > create that JAR. I agree it's more complicated, but fundamentally, diffoscope should *not* crash here! (but rather report the broken zip file.) thanks! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ I’ve said it once, and I’ll say it a thousand times: If the penalty for breaking a law is a fine, then that law only exists for the poor. signature.asc Description: PGP signature
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
On Thu, Apr 11, 2024 at 01:48:18AM +0200, Fay Stegerman wrote: > Salsa is probably better for figuring out what to do next, but I get these > mails > too :) :) > The libscout.jar has duplicate ZIP entries in the central directory, pointing > to > the same actual entry in the ZIP. So the "overlapped entries" error is > entirely > correct, even if it's not a zip bomb. ah! > unzip does seem to extract all the files, though it errors out. Not sure what > diffoscope should do here. This is definitely a broken ZIP file. That bug > should probably be reported against libscout or whatever tooling it used to > create that JAR. I agree it's more complicated, but fundamentally, diffoscope should *not* crash here! (but rather report the broken zip file.) thanks! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ I’ve said it once, and I’ll say it a thousand times: If the penalty for breaking a law is a fine, then that law only exists for the poor. signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1002458: "version in VCS newer than in repository" might be a bit overzealous
On Fri, Dec 24, 2021 at 01:36:35PM +0100, Marc Haber wrote: > On Fri, Dec 24, 2021 at 01:15:08PM +0100, Christoph Berg wrote: > > Re: Marc Haber > > > To fill my idea, vcswatch would need to classify commits into "real" > > > commits and "housekeeping" commits, so that the tracker can handle them > > > differently. > > The idea makes sense, but I doubt that is possible without entering a > > very deep rathole :( > For starters, an early release could classify changelog-only commits as > "housekeeping". *that*! additionally you could also only classify d/changelog changing commits with "Gbp-Dch: ignore" in them as such, but I'd guess Marc's suggestion really is good enough. Please reconsider, IOW, Myon: my I reassign this back to qa.debian.org for vcswatch? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Only change is constant. signature.asc Description: PGP signature
Bug#1002458: "version in VCS newer than in repository" might be a bit overzealous
On Fri, Dec 24, 2021 at 01:36:35PM +0100, Marc Haber wrote: > On Fri, Dec 24, 2021 at 01:15:08PM +0100, Christoph Berg wrote: > > Re: Marc Haber > > > To fill my idea, vcswatch would need to classify commits into "real" > > > commits and "housekeeping" commits, so that the tracker can handle them > > > differently. > > The idea makes sense, but I doubt that is possible without entering a > > very deep rathole :( > For starters, an early release could classify changelog-only commits as > "housekeeping". *that*! additionally you could also only classify d/changelog changing commits with "Gbp-Dch: ignore" in them as such, but I'd guess Marc's suggestion really is good enough. Please reconsider, IOW, Myon: my I reassign this back to qa.debian.org for vcswatch? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Only change is constant. signature.asc Description: PGP signature
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
On Wed, Apr 10, 2024 at 06:12:21PM +0100, Chris Lamb wrote: > Holger Levsen wrote: > > > when building libscout 2.3.2-3 on current unstable, the result is also > > unreproducible, but diffoscope crashes when analysing the diff. > I think this is somewhat related to: > https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/362 > … which was said to be fixed by Fay in > cc3b077f6ef97b4e20036e9823926fe633c7d4d0 > that released as diffoscope version 263 on 2024-04-05. > However, I can see that the current output of libscout/amd64 on > tests.reproducible-builds.org is failing with this very version: yes, indeed. also, this happened before too, I'm sure about at least with diffoscope 260 already. > Will loop Fay in via Salsa presently. thank you! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Fischers Fritz fischt Plastik. signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
On Wed, Apr 10, 2024 at 06:12:21PM +0100, Chris Lamb wrote: > Holger Levsen wrote: > > > when building libscout 2.3.2-3 on current unstable, the result is also > > unreproducible, but diffoscope crashes when analysing the diff. > I think this is somewhat related to: > https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/362 > … which was said to be fixed by Fay in > cc3b077f6ef97b4e20036e9823926fe633c7d4d0 > that released as diffoscope version 263 on 2024-04-05. > However, I can see that the current output of libscout/amd64 on > tests.reproducible-builds.org is failing with this very version: yes, indeed. also, this happened before too, I'm sure about at least with diffoscope 260 already. > Will loop Fay in via Salsa presently. thank you! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Fischers Fritz fischt Plastik. signature.asc Description: PGP signature
Re: Please review the draft for March's report
On Wed, Apr 10, 2024 at 10:02:56AM -0400, David A. Wheeler via rb-general wrote: > I agree, this one is HUGE news. There's been a lot of awesome work related to > reproducible builds, but "minimal container userland is a 100% reproducible > build in a real-world widely-used distro" is a big step forward and should be > widely announced. agreed. I also think the news about Vagrant helping Debian to confirm the xz related builds have been fine, deserves a bigger headline. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ You cannot ban abortion. You can only ban safe abortions. signature.asc Description: PGP signature
Bug#1068761: packaging-tutorial: mention hello and hello-traditional examples
Package: packaging-tutorial Version: 0.30 Severity: normal Dear Lucas, it would be great if the hello pkg would be mentioned, because its a clean example and because there's hello-traditional too. hello is a good example for using dh in d/rules: #!/usr/bin/make -f %: dh $@ override_dh_auto_clean: [ ! -f Makefile ] || $(MAKE) distclean override_dh_installdocs: dh_installdocs NEWS Many thanks for packaging-tutorial! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ “I'll tell you what freedom is to me No fear.” (Nina Simone) signature.asc Description: PGP signature
Bug#1068760: packaging-tutorial: discourage cdbs and even pure debhelper more
Package: packaging-tutorial Version: 0.30 Severity: normal Dear Lucas, packaging-tutorial is great, but please discourage the use of cdbs and even pure debhelper more and emphasize to use dh which is great and simple. & many thanks for packaging-tutorial! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Facts do not cease to exist because they are ignored. (Aldous Huxley) signature.asc Description: PGP signature
Re: finally end single-person maintainership
hi, just adding some random data points to this thread: - I love git. - I very much dislike git-buildpackage, too much magic. I try to avoid it where I can. - I like salsa. (though I think for many new contributors this is rather a barrier "why not use github" directly. Also salsa is Debian only, which also is a barrier for some.) - I love autopkgtests. - I hardly every look at the autopkgs logs on salsaci, cause I find them incomprehensible and the javascript "UX" makes me wanna chop wood. - I also think disallowing single-person maintainership would be very unwise, though I agree team maintenance in general is probably better than single-person maintainership. Still disallowing single-person maintainership doesnt make a team and motivation lost is often motivation lost forever. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The era of global warming has ended, the era of global boiling has arrived. The heat is unbearable, and the level of fossil fuel profits & climate inaction is unacceptable. Humanity has unleashed destruction. This must not inspire despair, but action." — UNSG @AntonioGuterres signature.asc Description: PGP signature
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
package: diffoscope version: 263 hi, diffoscope 263 crashes on libscout 2.3.2-3 build on unstable but not bullseye: libscout 2.3.2-3 is part of bullseye (but neither bookworm nor trixie) and builds unreproducible there and diffoscope is able to show a diff. when building libscout 2.3.2-3 on current unstable, the result is also unreproducible, but diffoscope crashes when analysing the diff. this happens on all 4 tested archs. I've copied the packages in question to https://tests.reproducible-builds.org/debian/diffoscope-libscout/artifacts/r00t-me/ for further investigation. (because one .deb is 20mb and there's 16 of them.) (someone please remind me to delete them there once this bug has been closed.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The hardest part about defending against social engineering is that it doesn't attack attack the weakness of a community. It attacks its *strengths*: trust, collaboration, and mutual assistance. (Russ Allbery) signature.asc Description: PGP signature
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
package: diffoscope version: 263 hi, diffoscope 263 crashes on libscout 2.3.2-3 build on unstable but not bullseye: libscout 2.3.2-3 is part of bullseye (but neither bookworm nor trixie) and builds unreproducible there and diffoscope is able to show a diff. when building libscout 2.3.2-3 on current unstable, the result is also unreproducible, but diffoscope crashes when analysing the diff. this happens on all 4 tested archs. I've copied the packages in question to https://tests.reproducible-builds.org/debian/diffoscope-libscout/artifacts/r00t-me/ for further investigation. (because one .deb is 20mb and there's 16 of them.) (someone please remind me to delete them there once this bug has been closed.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The hardest part about defending against social engineering is that it doesn't attack attack the weakness of a community. It attacks its *strengths*: trust, collaboration, and mutual assistance. (Russ Allbery) signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Two questions about build-path reproducibility in Debian
On Tue, Mar 12, 2024 at 08:45:03AM -0700, Vagrant Cascadian wrote: > >> Note: I confused myself when writing this; in fact Salsa-CI reprotest > >> _does_ > >> continue to test build-path variance, at least until we decide otherwise. > > this is in fact a bug and should be fixed with the next reprotest release. > That is not a reprotest bug, but an infrastructure issue for the > debian-specific salsa-ci configuration. Reprotest is not a > debian-specific tool. agreed. > Reprotest should continue to vary build paths by default; reprotest > historically and currently defaults to enabling all variations and > making an exception does not seem worth the opinionated change of > behavior. By design, reprotest is easy to configure which variations to > enable and disable as needed. agreed for the upstream release. for reprotest in Debian I'm still not so sure. (and for reprotest running as part of salsaci I do think the default should be not to vary path.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "The two hardest problems in computer science are: (i) people, (ii), convincing computer scientists that the hardest problem in computer science is people, and, (iii) off by one errors." - Jeffrey P. Bigham signature.asc Description: PGP signature
Content and translation status for the debian-edu-bookworm manual
The (translated) debian-edu-bookworm manual in PDF, ePUB or HTML formats are available at https://jenkins.debian.net/userContent/debian-edu-doc// To understand this mail better, please read /usr/share/doc/debian-edu-doc/README. This mail is automatically send by a cronjob run by Holger Levsen every two weeks. Please send feedback, suggestions, flames and cookies via this list. debian-edu-bookworm-manual.da.po: 618 translated messages, 255 fuzzy translations, 165 untranslated messages. debian-edu-bookworm-manual.de.po: 996 translated messages, 30 fuzzy translations, 12 untranslated messages. debian-edu-bookworm-manual.es.po: 1038 translated messages. debian-edu-bookworm-manual.fr.po: 1038 translated messages. debian-edu-bookworm-manual.id.po: 211 translated messages, 827 untranslated messages. debian-edu-bookworm-manual.it.po: 1031 translated messages, 7 fuzzy translations. debian-edu-bookworm-manual.ja.po: 739 translated messages, 198 fuzzy translations, 101 untranslated messages. debian-edu-bookworm-manual.nb-no.po: 599 translated messages, 304 fuzzy translations, 135 untranslated messages. debian-edu-bookworm-manual.nl.po: 1038 translated messages. debian-edu-bookworm-manual.pl.po: 307 translated messages, 128 fuzzy translations, 603 untranslated messages. debian-edu-bookworm-manual.pt-br.po: 1038 translated messages. debian-edu-bookworm-manual.pt-pt.po: 1038 translated messages. debian-edu-bookworm-manual.pt.po: 1038 translated messages. debian-edu-bookworm-manual.ro.po: 1038 translated messages. debian-edu-bookworm-manual.sv.po: 756 translated messages, 44 fuzzy translations, 238 untranslated messages. debian-edu-bookworm-manual.uk.po: 1038 translated messages. debian-edu-bookworm-manual.zh-cn.po: 806 translated messages, 149 fuzzy translations, 83 untranslated messages. FIXME: The HowTos from https://wiki.debian.org/DebianEdu/HowTo/"/> are either user- or developer-specific. Let's move the user-specific HowTos over here (and delete them over there)! (But first ask the authors (see the history of those pages to find them) if they are fine with moving the howto and putting it under the GPL.) 1 FIXMEs left to fix
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
On Fri, Apr 05, 2024 at 09:49:58PM +0200, Aurelien Jarno wrote: > If we go that route, here is a proposed alternative patch: > > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -338,7 +338,8 @@ > For example, the build target should pass ``--disable-silent-rules`` > to any configure scripts. See also :ref:`s-binaries`. > > -For packages in the main archive, required targets must not attempt > +Except for packages in the non-free archive with the ``Autobuild`` > +control field unset or set to ``no``, required targets must not attempt > network access, except, via the loopback interface, to services on the > build host that have been started by the build. seconded as well. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ There never has been more knowledge in the world with less conclusions. (Die Goldenen Zitronen, 1996 or so) signature.asc Description: PGP signature
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
On Fri, Apr 05, 2024 at 09:49:58PM +0200, Aurelien Jarno wrote: > If we go that route, here is a proposed alternative patch: > > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -338,7 +338,8 @@ > For example, the build target should pass ``--disable-silent-rules`` > to any configure scripts. See also :ref:`s-binaries`. > > -For packages in the main archive, required targets must not attempt > +Except for packages in the non-free archive with the ``Autobuild`` > +control field unset or set to ``no``, required targets must not attempt > network access, except, via the loopback interface, to services on the > build host that have been started by the build. seconded as well. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ There never has been more knowledge in the world with less conclusions. (Die Goldenen Zitronen, 1996 or so) signature.asc Description: PGP signature
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote: > Thanks Philipp. Following that result, please find a patch proposal: > > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -338,9 +338,9 @@ > For example, the build target should pass ``--disable-silent-rules`` > to any configure scripts. See also :ref:`s-binaries`. > > -For packages in the main archive, required targets must not attempt > -network access, except, via the loopback interface, to services on the > -build host that have been started by the build. > +Required targets must not attempt network access, except, via the > +loopback interface, to services on the build host that have been started > +by the build. > > Required targets must not attempt to write outside of the unpacked > source package tree. There are two exceptions. Firstly, the binary thanks, this looks good to me as well. seconded. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Bananas are berries. signature.asc Description: PGP signature
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote: > Thanks Philipp. Following that result, please find a patch proposal: > > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -338,9 +338,9 @@ > For example, the build target should pass ``--disable-silent-rules`` > to any configure scripts. See also :ref:`s-binaries`. > > -For packages in the main archive, required targets must not attempt > -network access, except, via the loopback interface, to services on the > -build host that have been started by the build. > +Required targets must not attempt network access, except, via the > +loopback interface, to services on the build host that have been started > +by the build. > > Required targets must not attempt to write outside of the unpacked > source package tree. There are two exceptions. Firstly, the binary thanks, this looks good to me as well. seconded. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Bananas are berries. signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Fri, Apr 05, 2024 at 12:26:03PM +0200, Andreas Tille wrote: > > also: (NMU-)uploads to DELAYED/15 are great. > Sorry, I do not feel my time well spent on just curing a symptom > (unfixed RC bug) via NMU instead of addressing the underlying cause > that the package is maintained by a single person. so you value your values and needs higher than our shared and agreed values. noted. (also, pressuring people to accept more co-maintainers can have serious side effects as became very visible last weekend with xz upstream...) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make facts great again. signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Thu, Apr 04, 2024 at 02:32:45PM +0200, Andreas Tille wrote: > [...] I could follow the normal NMU procedure but I do not consider > this a sustainable solution. [...] > I did not uploaded my work but I would like to know what action is > considered acceptable by the voters. I repeat that the package is no > key package for which I would not consider what I did above. Please > simply fill in the form: > >[ ] Its not acceptable, don't do that >[ ] We should discuss this on debian-devel, possibly do some GR >before things like this are permitted >[ ] Wait one week before uploading >[ ] Wait one day before uploading >[ ] Just upload provided you care for any break your action might >have caused. >[ ] ??? > > What do you think? rereading this, I must say I think "wtf". please *do* follow the NMU procedures or salvage the package. (or leave it alone.) also: (NMU-)uploads to DELAYED/15 are great. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Everyone is entitled to their own opinion, but not their own facts. signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Thu, Apr 04, 2024 at 02:59:34PM +0200, Andreas Tille wrote: > I would like to learn what options I have to realise paragraph >Packaging standards > of my platform. I also think this feels a bit like abusing the election audience for a topic which should be discussed on -devel outside campaigning. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The greatest danger in times of turbulence is not the turbulence; it is to act with yesterdays logic. (Peter Drucker) signature.asc Description: PGP signature
ufw (was Re: Debian openssh option review: considering splitting out GSS-API key exchange)
On Thu, Apr 04, 2024 at 01:32:11PM +0200, Marc Haber wrote: > So you have dedicated packet filters on every machine you run, even if > sshd is the only network-facing service? on most machines and it was as simple as doing: apt install ufw ufw allow ssh ufw enable voila, done. rules configured like above end up in /etc/ufw/user.rules and user6.rules. quite simple, quite nice. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Kinda weird that we’re all gonna experience climate change as a series of short, apocalyptic videos until eventually it’s your phone that’s recording. (@shocks) signature.asc Description: PGP signature
Re: review of src:sequoia-chameleon-gnupg package descriptions
Dear Justin, On Sun, Mar 24, 2024 at 05:10:02PM +, Justin B Rye wrote: > Okay! Suggested version attached. <3 thank you very much for that lovely & caring review! I love all your changes and will upload shortly! 珞 > > Description: Sequoia's reimplementation of the GnuPG cli tools (metapackage) > An initialism, so definitely capitalised. > > It's a bit long; maybe the "reimplementation" part can wait for the > long description: > Description: Sequoia's GnuPG CLI tools (metapackage) agreed. > Fair enough, this all looks intelligible. I'll deal with the quoted > descriptions below, but notice that one of them is a "what it is" noun > phrase while the other is a "what it's for" verb phrase - the list > would read a bit more smoothly if they were syntactically parallel. I knew you would find these inconsistancies.. thank you. [...] > But this is essentially repeating the previous paragraph, while > slightly contradicting it. Couldn't we merge the two paragraphs as > something like > > gpg-sq is Sequoia's alternative implementation of a tool following > the GnuPG command line interface. It provides a drop-in but not > feature-complete.replacement for the GnuPG project's gpg. YES. [...] > The previous two descriptions both talked about themselves as packages > when it would make things simpler to keep the focus on the utilities > they contained; this one does some administrative hocus-pocus, so if > anything it would make *more* sense for it to start with "this > package" (and an active verb). :)) thank you, again. I knew it needed someone to look from the distance to have this perspective and be able to express it / point out whats wrong with the previous version. > (g10code? Oh, okay, "ɡ10ᶜᵒᵈᵉ GMBH".) well spotted! :) *thank you*, ***again!*** -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make racists afraid again. signature.asc Description: PGP signature
review of src:sequoia-chameleon-gnupg package descriptions
hi,
I would kindly ask you for a review of these src:sequoia-chameleon-gnupg package
descriptions. I'm intentionaly not giving more context as I think the package
descriptions should speak for themselves. I'm looking forward to your comments
and other feedback! (And please cc: my on replies I'm not subscribed to this
list.)
Source: rust-sequoia-chameleon-gnupg
Maintainer: Debian Rust Maintainers
Uploaders:
Alexander Kjäll ,
Holger Levsen
Vcs-Git: https://salsa.debian.org/rust-team/debcargo-conf.git
[src/sequoia-chameleon-gnupg]
Vcs-Browser:
https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/sequoia-chameleon-gnupg
Homepage: https://sequoia-pgp.org/
Package: sequoia-chameleon-gnupg
Architecture: all
Depends:
gpg-sq,
gpgv-sq
Description: Sequoia's reimplementation of the GnuPG cli tools (metapackage)
This metapackage depends on the following binaries packages:
- gpg-sq: OpenPGP toolkit offering an interface aligned with gpg
- gpgv-sq: Validate OpenPGP signatures as gpgv does
Both are drop-in replacements using the Sequoia OpenPGP implementation
provided in the Rust crate sequoia-chameleon-gnupg.
Package: gpg-sq
Architecture: any
Description: OpenPGP toolkit offering a command line interface aligned with gpg
This package provides the GnuPG interface while useing Sequoia's state.
It follows the same interface offered by the GnuPG project's gpg, and can
be used wherever gpg is used.
.
gpg-sq is drop-in replacement of gpg that is not feature-complete.
.
It currently implements a commonly used subset of the signature
creation and verification commands, the encryption and decryption
commands, the key listing commands, and some miscellaneous commands.
.
Support for trust models is limited. Currently, the Web-of-Trust
('pgp') and always trust ('always') are implemented.
.
This tool is provided by the Sequoia project via the sequoia-chameleon-gnupg
crate.
Package: gpgv-sq
Architecture: any
Description: validate OpenPGP signatures as gpgv does
This package provides a verification-only command line interface for OpenPGP
signatures. It follows the same interface offered by the GnuPG project's gpgv,
and can be used wherever gpgv is used.
.
gpgv-sq is a feature-complete drop-in replacement of gpgv.
.
This tool is provided by the Sequoia project via the sequoia-chameleon-gnupg
crate.
Package: gpg-from-sq
Architecture: all
Depends:
gpg-sq
Description: use gpg-sq for /usr/bin/gpg
The GnuPG implementation of gpg, if installed, is diverted to gpg-g10code,
while /usr/bin/gpg is provided by the Rust crate sequoia-chameleon-gnupg.
Package: gpgv-from-sq
Architecture: all
Depends:
gpgv-sq
Description: use gpgv-sq for /usr/bin/gpgv
The GnuPG implementation of gpgv, if installed, is diverted to gpgv-g10code,
while /usr/bin/gpgv is provided by the Rust crate sequoia-chameleon-gnupg.
Thank you!
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Never waste a crisis.
signature.asc
Description: PGP signature
Bug#1041832: #1041832: libsequoia-octopus-librnp: undeclared file conflict with thunderbird
hi, < h01ger> helmut: re: #1041832: i just could not reproduce this bug, see https://paste.debian.net/1311659/ - though we "didnt change anything" in sequoia-octopus, so what am i missing? :) that paste had basically this content: ± dpkg -L libsequoia-octopus-librnp |grep librnp.so /usr/lib/sequoia/libsequoia_octopus_librnp.so /usr/lib/thunderbird/librnp.so ± dpkg -L thunderbird|grep librnp.so 1 ± < jochensp> | h01ger: https://packages.debian.org/search?searchon=contents=librnp.so=path=unstable=any says on ppc64 < jochensp> | h01ger: also https://packages.debian.org/search?suite=bookworm=any=path=contents=librnp.so < h01ger> jochensp: what? (re: ppc64 only) < jochensp> | h01ger: also thunderbird (1:115.0.1-1) has: [f78b777] d/mozconfig.default: Use internal shipped librnp version and 1:115.1.1-1 reverts that < jochensp> (and ppc64 is out of date in unstable) < h01ger> jochensp: ah! [f78b777] - thank you! < h01ger> jochensp: can i quote you in that bug? < jochensp> | h01ger: sure < h01ger> :) thanks! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Just because other people are also responsible, does not mean you are not responsible. signature.asc Description: PGP signature
Bug#1041832: #1041832: libsequoia-octopus-librnp: undeclared file conflict with thunderbird
hi, < h01ger> helmut: re: #1041832: i just could not reproduce this bug, see https://paste.debian.net/1311659/ - though we "didnt change anything" in sequoia-octopus, so what am i missing? :) that paste had basically this content: ± dpkg -L libsequoia-octopus-librnp |grep librnp.so /usr/lib/sequoia/libsequoia_octopus_librnp.so /usr/lib/thunderbird/librnp.so ± dpkg -L thunderbird|grep librnp.so 1 ± < jochensp> | h01ger: https://packages.debian.org/search?searchon=contents=librnp.so=path=unstable=any says on ppc64 < jochensp> | h01ger: also https://packages.debian.org/search?suite=bookworm=any=path=contents=librnp.so < h01ger> jochensp: what? (re: ppc64 only) < jochensp> | h01ger: also thunderbird (1:115.0.1-1) has: [f78b777] d/mozconfig.default: Use internal shipped librnp version and 1:115.1.1-1 reverts that < jochensp> (and ppc64 is out of date in unstable) < h01ger> jochensp: ah! [f78b777] - thank you! < h01ger> jochensp: can i quote you in that bug? < jochensp> | h01ger: sure < h01ger> :) thanks! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Just because other people are also responsible, does not mean you are not responsible. signature.asc Description: PGP signature
Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
On Thu, Mar 21, 2024 at 10:47:21AM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug?
> [and 1 more messages]"):
> > Steve, could you please do this for *all* the time_t transition RC
> > bugs?
> IMO things are currently ON FIRE.
I'd rather call it a very large smoldering fire, so far. ;)
> If no-one else has put this fire out by 24h from now, I will attempt
> to find which are the relevant bugs and downgrade them all.
I've sent a few contentless pings today to some of those bugs today,
which will keep the smoldering fire smoldering (=delay autoremovals
further). I agree that is far from ideal, but as I understand things,
it's better than possibly letting such buggy packages migrate *to* testing.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
I don't want to see your smile.
I want to see your intelligence, compassion, integrity, and consideration.
(@1goodtern)
signature.asc
Description: PGP signature
Bug#1062904: ping to prevent autoremoval
pong
Bug#1062904: ping to prevent autoremoval
pong
Bug#1067232: limit diffoscope recursions on packages where diffoscope runs into a timeout
On Wed, Mar 20, 2024 at 04:31:22PM +, James Addison wrote: > > or maybe even simpler: first run diffoscope normally, then if that runs > > into a timeout, > > run with --max-container-depth=3 (or 5). It also occured to me that we then could diffoscope with a (way) lower timeout, eg 60min instead of 155min, because hardly never diffoscope runs longer than 30min, and if it does, it usually runs 155min until it gets killed. I'm not sure we're collecting data on this, so far this is just an educated guess. :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Stop saying that we are all in the same boat. We’re all in the same storm. But we’re not all in the same boat. signature.asc Description: PGP signature
Bug#1067232: limit diffoscope recursions on packages where diffoscope runs into a timeout
On Wed, Mar 20, 2024 at 04:31:22PM +, James Addison wrote: > Package: jenkins.debian.org > X-Debbugs-Cc: hol...@layer-acht.org no need for that cc:, i'm subscribed to the package. > That seems like a straightforward way to get started, and without adding much > complexity. indeed. > In reproducible_build.sh it looks like there are some IRC notifications: it > could make sense to suppress the retried-diffoscope-results, or emit a > noticably different message for those to distinguish them from the initial > attempt? yes. (and I apologize to your eyes for having seen that IRC notification "logic"... I've looked at it yesterday for too long and only came up with a small improvement while that whole thing could use an overhaul.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ All data, over time, approaches deleted, or public. (@quinnnorton) signature.asc Description: PGP signature
Bug#1067232: limit diffoscope recursions on packages where diffoscope runs into a timeout
package: jenkins.debian.org severity: wishlist hi, in https://salsa.debian.org/qa/jenkins.debian.net/-/merge_requests/163 James Addison suggested to use --max-container-depth=3 (or 5) for when diffscope runs into a timeout on a package. (or rather not then, but always, which why this MR wasnt accepted.) However this lead to the following discussion on irc: jayaddison: thanks for closing MR163! no probs! thought it might confuse/distract someone later otherwise :) jayaddison: thinking about it, we could probably run diffoscope with the reduced depth option on those packages we know diffoscope timeouts, eg all packages listed more than 4 times on https://tests.reproducible-builds.org/debian/index_breakages.html the breakage job could generated that list, and then reproducible_build.sh could consume it and act accordingly interesting idea. that was going to be my next question (how to maintain the list of relevant packages) I'm slightly averse to adaptive testing because it becomes a maintenance/debug challenge over time, but am thinking about it what's the effect of a diffoscope timeout at the moment? no output at all? < h01ger> thinking about it, this could cause an interesting jojo effect: git-annex is tested, diffoscope runs into a timeout. this happens more than 4 times -> git-annex is put on the list of packages which diffoscope is run on with reduced depth. thus, (hopefullly! now) diffoscope doesnt run into a timeout anymore. this happens so often that git-annex appears less than 4 times on the breakages page -> git-annex is tested without a timeout again, rinse repeat, until diffoscope or git-annex is improved yes, its basically empty, see eg https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/git-annex.html basically true for any link on https://tests.reproducible-builds.org/debian/index_breakages.html ok. I guess 'in theory' it'd be nice for diffoscope to diff to depth 1, then write output, then proceed to depth 2, rewrite output, etc. nah, depth 3/4/5 should be fine, i hope first few levels are generally .deb, data/xz or something, and... I forget. but fast/inexpensive compute-wise yeah if we could write output after each layer, there should always be 'something' to show on the results page even if it later fails at depth 8 or whatever s/fails/times-out i'd just go with layer X for a start, i doubt its useful to make this more sophisticated, esp from the start. also its sophisticated enough to only invoke this for a few timeouting packages or maybe even simpler: first run diffoscope normally, then if that runs into a timeout, run with --max-container-depth=3 (or 5). I think this would be acceptable with only 286 suite/arch/package combinations currently which run into a timeout. I'd still like to store/record somewhere (for later reading, eg to then semiautomatically add this information to notes.git) that diffoscope ran into a timeout on this package, but for the moment I don't have a plan how to that exactly. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Deutschland ist so rechts, es wird sogar diskutiert ob die Nazis links waren. (@elhotzo, 20220206) signature.asc Description: PGP signature
Alexander Kjäll: Advocate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 For nm.debian.org, at 2024-03-20: I support Alexander Kjäll 's request to become a Debian Developer, uploading. I have worked with Alexander Kjäll on rust packaging and specifically on sequoia packaging for the last 5 months and I consider them as having sufficient technical competence. I've met Alexander for the first time at foss-north.se in April 2023 where he was giving a talk about packages Rust crates for Debian, https://foss-north.se/2023/speakers-and-talks.html#akjall and I learned a lot in that talk and enjoyed talking to him afterwards. Then it happened that I became involved in sequoia packaging at the end of 2023 and since them I've been sponsoring exactly 100 rust sources from him into unstable. Out of these 75 needed NEW processing and out of these 75 *one* got a reject from ftpmasters for missing one file in d/copyright. - From what I've seen when interacting with him online as well as at two other events recently I can say that I wholehearty recommend and support him becoming a Debian Developer, uploading. I previously wrote that that I thought I cannot advocate him to be able *to upload any package right now*, because I've only interacted with him on rust packages, but similar situations were true for all of us, eg noone could know how I would handle rust packages when I became a DD. :) And I very much do trust him to know what he's doing, so I also trust him to become a DD and act responsible. So long story short: I fully support Alexander Kjäll's NM application and hope he'll be a DD soon! Thanks for all your great work, Alexander! I have personally worked with Alexander Kjäll (key 7E068070D5EF794B00C8A9D91D108E6C07CBC406) for 5 months, and I know Alexander Kjäll can be trusted to be a full member of Debian, and have unsupervised, unrestricted upload rights, right now. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmX6smAACgkQCRq4Vgaa qhwdnQ//R5J7LEJ1JKJLZwb881Rn6X9KBfwtEDl/a7IBdTls7e9ldrcwv6mnz8a9 oW0LonGxB7XyZusg9ie1mYUFqEPggy1D2i2Ket3bl4n/Y/ckv6NHZCqd8Ss9M9pq UbP+RBUaAXlgoWr0LoAVPmOPDmoFmhOuheYAqZymU6xlqNRbeaJFJIyxT2E4u0xX 5L4ZikHzAo+1HaYrRa94wsNFPDcNTu/qJS8b0wXOavmiQ0KBJtAN72F8V+j1wtlL cti+Kjk5BHgOanAMasvj89Ivpp2aqMBIYxdTDCYGyskRrBriaT6avvPJsRsM3qw2 3oPvYQCdKQ0SdQc3dsPt99HGsY7v+wKfNBBbtfPOteThzDkrEEJkyc/XQd/M9w/8 SXHirLC1Ux129gPguLocTvDo+PJ5JBQ/wCKCTwSGlgF3wjbupQrq4ozi4KgAINDj sZBCDWExZT+H1+wOOkGqPTdCPjRSvkCCe45UWXr4Yz0XFYR6bHC5TAAEmx4hu0xx gEBfQPiQwB2ciX7jw+I4TxhpNksxOyL8cGI3Q15kodxg3XIzifq6tDSbSp/2zc49 GDEsrUmvUuCFW/7V3jwbk+4oV/eUW6k9ti3jR5O328E87TcOirGNyFv1GU16YtzQ WT4tzQk052n3dd3UTovSfUU1nJfWPFjT9QgUstPAvmCepNfv7qQ= =TwUX -END PGP SIGNATURE- Holger Levsen (via nm.debian.org) For details and to comment, visit https://nm.debian.org/process/1257/ -- https://nm.debian.org/process/1257/
Bug#1066991: easy way to crash diffoscope
package: diffoscope version: 240 hi, crashing diffoscope in under 2min (the package build takes 42sec here). $ apt source golang-github-stvp-tempredis $ sudo pbuilder build golang-github-stvp-tempredis_0.0~git20231107.8a695b6-1.dsc $ mkdir p1 ; mv /var/cache/pbuilder/unstable/result/* p1/ $ sudo pbuilder build golang-github-stvp-tempredis_0.0~git20231107.8a695b6-1.dsc $ mkdir p2 ; mv /var/cache/pbuilder/unstable/result/* p2/ $ diffoscope p1/golang-github-stvp-tempredis_0.0~git20231107.8a695b6-1_amd64.changes p2/golang-github-stvp-tempredis_0.0~git20231107.8a695b6-1_amd64.changes Traceback (most recent call last): File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 767, in main sys.exit(run_diffoscope(parsed_args)) ^^^ File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 718, in run_diffoscope difference = compare_root_paths(path1, path2) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 69, in compare_root_paths difference = compare_files(file1, file2) ^^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 149, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/debian.py", line 275, in compare differences = super().compare(other, *args, **kwargs) ^^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 532, in compare difference = self._compare_using_details(other, source) ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 467, in _compare_using_details details.extend( File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", line 197, in compare_pair difference = compare_files( ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 149, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 532, in compare difference = self._compare_using_details(other, source) ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 467, in _compare_using_details details.extend( File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", line 197, in compare_pair difference = compare_files( ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 149, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 532, in compare difference = self._compare_using_details(other, source) ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 467, in _compare_using_details details.extend( File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", line 197, in compare_pair difference = compare_files( ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 149, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 532, in compare difference = self._compare_using_details(other, source) ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 467, in _compare_using_details details.extend( File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", line 197, in compare_pair difference = compare_files( ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 149, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 532, in compare difference = self._compare_using_details(other, source) ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 433, in _compare_using_details details.extend(self.compare_details(other, source)) ^^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/rdata.py", line 166, in
Bug#1066991: easy way to crash diffoscope
package: diffoscope version: 240 hi, crashing diffoscope in under 2min (the package build takes 42sec here). $ apt source golang-github-stvp-tempredis $ sudo pbuilder build golang-github-stvp-tempredis_0.0~git20231107.8a695b6-1.dsc $ mkdir p1 ; mv /var/cache/pbuilder/unstable/result/* p1/ $ sudo pbuilder build golang-github-stvp-tempredis_0.0~git20231107.8a695b6-1.dsc $ mkdir p2 ; mv /var/cache/pbuilder/unstable/result/* p2/ $ diffoscope p1/golang-github-stvp-tempredis_0.0~git20231107.8a695b6-1_amd64.changes p2/golang-github-stvp-tempredis_0.0~git20231107.8a695b6-1_amd64.changes Traceback (most recent call last): File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 767, in main sys.exit(run_diffoscope(parsed_args)) ^^^ File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 718, in run_diffoscope difference = compare_root_paths(path1, path2) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 69, in compare_root_paths difference = compare_files(file1, file2) ^^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 149, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/debian.py", line 275, in compare differences = super().compare(other, *args, **kwargs) ^^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 532, in compare difference = self._compare_using_details(other, source) ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 467, in _compare_using_details details.extend( File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", line 197, in compare_pair difference = compare_files( ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 149, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 532, in compare difference = self._compare_using_details(other, source) ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 467, in _compare_using_details details.extend( File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", line 197, in compare_pair difference = compare_files( ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 149, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 532, in compare difference = self._compare_using_details(other, source) ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 467, in _compare_using_details details.extend( File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", line 197, in compare_pair difference = compare_files( ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 149, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 532, in compare difference = self._compare_using_details(other, source) ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 467, in _compare_using_details details.extend( File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", line 197, in compare_pair difference = compare_files( ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 149, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 532, in compare difference = self._compare_using_details(other, source) ^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 433, in _compare_using_details details.extend(self.compare_details(other, source)) ^^^ File "/usr/lib/python3/dist-packages/diffoscope/comparators/rdata.py", line 166, in
Re: Reproducible Arch Linux in 2024/Q1 (irregular status update)
hi, from irc: kpcyrd: may i quote on rb-general what you wrote here? [11:56] < h01ger> kpcyrd: many thanks for your arch linux status update! i just wonder: does archlinux re-build in the same path as the original build or not? :) [11:59] < kpcyrd> | h01ger: yes, the build path always starts with /build/ plus what's configured in the build instructions, e.g. /build/libfoo-1.2.3/ [12:00] < kpcyrd> with libfoo-1.2.3 usually coming from the source code .tar.gz h01ger: yes thanks -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make earth cool again. signature.asc Description: PGP signature
Bug#1066121: ionos 5/6/15/16 loosing network
[22:39] * | h01ger filed a bug about 5/6/15/16 loosing network now [22:40] * | mapreri ponders the accuracy: the link was still up, so perhaps it only lost the IP somehow? [22:40] next time I will look up the dhcp lease if there is anything odd [22:40] mapreri: that pondering could be the right direction.. [11:03] mapreri: and ionos5+15 are gone again.. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "Any fool can know. The point is to understand." - A. Einstein signature.asc Description: PGP signature
Bug#1066186: setup mastadon2irc bot
package: jenkins.debian.org not strictly a jenkins.d.o topic, but it would be nice to have mastadon mentions on #reproducible-builds again in that channel. https://github.com/hackspace-marburg/troet is a Mastodon plugin for Sopel IRC bots, sopel is available in Debian. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If it feels like we’re breaking climate records every year, it’s because we are. signature.asc Description: PGP signature
Bug#1066122: ionos3 configured twice
package: jenkins.debian.org some cleanup needs to be done here, we dont need two hosts. also twitter is dead, so maybe not even one. though maybe we wanted a mastadon bot? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ I miss the old days were billionaires’ vanity projects were to build 1000 public libraries or giant music venues. signature.asc Description: PGP signature
Bug#1066121: ionos 5/6/15/16 loosing network
package: jenkins.debian.org (this has been ongoing for month already) < h01ger> mapreri: i think we need to put restarting network into some sort of 'cronjob' (probably only if network is down), ionos5 is been gone since several hours and thus half the amd64 builders are down now < h01ger> not sure how to test if network is up, ping -c 1 8.8.8.8 ? < mapreri> fwiw, testing the network is actually this very easy: < mapreri> mattia@ionos5-amd64 ~ % ip -br a < mapreri> lo UNKNOWN127.0.0.1/8 ::1/128 < mapreri> eth0 UP fe80::1:5dff:fedf:3b89/64 < mapreri> mattia@ionos5-amd64 ~ % sudo service networking restart < mapreri> mattia@ionos5-amd64 ~ % ip -br a < mapreri> lo UNKNOWN127.0.0.1/8 ::1/128 < mapreri> eth0 UP 85.184.249.130/32 fe80::1:5dff:fedf:3b89/64 < mapreri> mattia@ionos5-amd64 ~ % < mapreri> < mapreri> but still, I'd really really prefer to figure out what's happening inside those 4 affected hosts :( < h01ger> what are the 4 nodes? < h01ger> all ionos/ffm datacenter? < h01ger> (ffm=frankfurt/main) < mapreri> yes < mapreri> 5 6 15 16 * | h01ger will file a bug using this irc log < mapreri> today it seems to be only 5, for whatever reason. < h01ger> i think i might have seen 2+12 loosing network too, but that might have been other i386 related failures. i dont think i've seen this with 1+11 < mapreri> (fwiw, `ip -br -4 a show dev eth0` is currently the shortest command I use to get a parsable ip4 address) < h01ger> s#i dont think i've seen this with 1+11#i haven't seen this with 1+11# < h01ger> those addresses are assigned by dhcp, arent they? < mapreri> they are < h01ger> hmm < mapreri> but it doesn't happen with 3 7 10 that are also there < mapreri> so I don't think we can blame ionos < h01ger> in ffm you mean < mapreri> yep < h01ger> nods -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Manchmal kommt der Wind von Lee. (Konny) signature.asc Description: PGP signature
Bug#1059479: r-b CI tests very slow
On Tue, Dec 26, 2023 at 05:50:47PM +, Holger Levsen wrote: > packages tested on average per day in the last week 596 3484482 > 348 > packages tested on average per day in the last 4 weeks774 4351 > 546 339 > packages tested on average per day in the last 3 months 1018 2987916 > 359 > packages tested on average per day in the last year 144618621331 > 658 update from today, 12:04 UTC packages tested yesterday (2024-03-11) 687 960 226 321 packages tested today (2024-03-12) 263 1524181 196 packages tested in the last 24h 633 1909339 451 packages tested on average per day in the last week 607 105274 95 packages tested on average per day in the last 4 weeks 181 174888 67 packages tested on average per day in the last 3 months 379 2282 296 217 packages tested on average per day in the last year 104918401036 523 update from today, 16:04 UTC packages tested yesterday (2024-03-11) 689 961 226 321 packages tested today (2024-03-12) 368 2419299 248 packages tested in the last 24h 601 2721449 425 packages tested on average per day in the last week 625 120394 103 packages tested on average per day in the last 4 weeks 183 176192 68 packages tested on average per day in the last 3 months 380 2283 297 217 packages tested on average per day in the last year 104818421035 522 since Saturday we, mostly Mattia, made some relevant changes how we run our build service (basically now >100 slices, compared to 1 before), so now oomd is killing the build service and thus all builds several times a day. since 2h all workers are enabled again, before we were running with less. so let's revisit this in a week and in 4 weeks. :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ wirklicher reichtum ist nicht privatjet fliegen, sondern sich vor dem schützen können, was privatjet fliegen auslöst." <3 böhmermann am 3.2.23 signature.asc Description: PGP signature
Re: Two questions about build-path reproducibility in Debian
On Mon, Mar 11, 2024 at 06:24:22PM +, James Addison via rb-general wrote: > Please find below a draft of the message I'll send to each affected bugreport. looks good to me, thank you for doing this! > Note: I confused myself when writing this; in fact Salsa-CI reprotest _does_ > continue to test build-path variance, at least until we decide otherwise. this is in fact a bug and should be fixed with the next reprotest release. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Historians have a word for Germans who joined the Nazi party, not because they hated Jews, but out of hope for restored patriotism, or a sense of economic anxiety, or a hope to preserve their religious values, or dislike of their opponents, or raw political opportunism, or convenience, or ignorance, or greed. That word is "Nazi". Nobody cares about their motives anymore. signature.asc Description: PGP signature
Bug#1063376: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)
On Mon, Mar 11, 2024 at 08:26:40PM +, Holger Levsen wrote: > do mutt -s "RM: remove $package" -i tmpfile $package the 2nd $package in that line must be sub...@bugs.debian.org -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ “We live in capitalism. Its power seems inescapable. So did the divine right of kings. Any human power can be resisted and changed by human beings. Resistance and change often begin in art, and very often in our art, the art of words.” ― Ursula K. Le Guin signature.asc Description: PGP signature
Bug#1063376: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)
On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote: > I hope there is some better solution than sending single bug reports > for those packages. If ftpmaster tooling really needs single bug > reports I wonder how I can automatically create such bug reports with > always the same text, just targeting at different binary packages. > > This also should include some means to work around the less than 5 > bug reports per hour SPAM protection means of BTS. foo="bin1 bin2 bin3" $file=/some/path/to/bugreport_without_package_line.txt tmpfile=$(mktemp) for package in $foo ; do ( echo "package: $package" ; cat $file ) > $tmpfile do mutt -s "RM: remove $package" -i tmpfile $package sleep 15m done rm $tmpfile with 40 packages this is just a 10h running script ;) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If you’re going through hell, keep going! signature.asc Description: PGP signature
Re: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)
On Mon, Mar 11, 2024 at 08:26:40PM +, Holger Levsen wrote: > do mutt -s "RM: remove $package" -i tmpfile $package the 2nd $package in that line must be sub...@bugs.debian.org -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ “We live in capitalism. Its power seems inescapable. So did the divine right of kings. Any human power can be resisted and changed by human beings. Resistance and change often begin in art, and very often in our art, the art of words.” ― Ursula K. Le Guin signature.asc Description: PGP signature
Re: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)
On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote: > I hope there is some better solution than sending single bug reports > for those packages. If ftpmaster tooling really needs single bug > reports I wonder how I can automatically create such bug reports with > always the same text, just targeting at different binary packages. > > This also should include some means to work around the less than 5 > bug reports per hour SPAM protection means of BTS. foo="bin1 bin2 bin3" $file=/some/path/to/bugreport_without_package_line.txt tmpfile=$(mktemp) for package in $foo ; do ( echo "package: $package" ; cat $file ) > $tmpfile do mutt -s "RM: remove $package" -i tmpfile $package sleep 15m done rm $tmpfile with 40 packages this is just a 10h running script ;) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If you’re going through hell, keep going! signature.asc Description: PGP signature
Re: Two questions about build-path reproducibility in Debian
On Tue, Mar 05, 2024 at 11:51:16PM +, Richard Purdie wrote: > FWIW Yocto Project is a strong believer in build reproducibiity > independent of build path and we've been quietly chipping away at those > issues. [...] > OpenEmbedded-Core (around 1000 pieces of software) is 100% reproducible > and we have the tests to prove it running daily, building in different > build paths and comparing the output. that's awesome! btw, https://www.yoctoproject.org/reproducible-build-results/ (linked from https://reproducible-builds.org/who/projects/#Yocto%20Project) doesn't show any results? > We're working on our wider layers too, e.g. meta-openembedded has > another 2000+ pieces of software and less than 100 are not > reproducible. nice. we had 35000 pieces of software in Debian of which ~2000 were not reproducible with undeterministic build pathes. Now with build pathes as part of the build environment it's less than half. > So even if debian doesn't do this, there is interest elsewhere and I > believe good progress is being made. nice! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Lebend in einer privilegierten Region und als Angehöriger einer Generation, der es wahrscheinlich so gut geht wie keiner zuvor und danach, die in nicht dagewesenem Maße die Ressourcen unserer Erde geplündert hat. signature.asc Description: PGP signature
Bug#1065463: debootstrap can deal with native dpkg file replacement feature
On Tue, Mar 05, 2024 at 08:36:59AM +0800, Steven Shiau wrote: > debootstrap should be able to solve the libuuid1t64 dependency by installing > libuuid1 only. just in case you are not aware, bootstrapping using either mmdebstrap or cdebootstrap works atm. mmdebstrap is faster and mostly a drop-in replacement. (same applies to cdebootstrap but its less faster :) daily tests are available at: https://jenkins.debian.net/job/reproducible_debootstrap_unstable/ https://jenkins.debian.net/job/reproducible_cdebootstrap_unstable/ https://jenkins.debian.net/job/reproducible_mmdebstrap_unstable/ -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Where will you go when you become a climate refugee? signature.asc Description: PGP signature
Bug#1065463: debootstrap can deal with native dpkg file replacement feature
On Tue, Mar 05, 2024 at 08:36:59AM +0800, Steven Shiau wrote: > debootstrap should be able to solve the libuuid1t64 dependency by installing > libuuid1 only. just in case you are not aware, bootstrapping using either mmdebstrap or cdebootstrap works atm. mmdebstrap is faster and mostly a drop-in replacement. (same applies to cdebootstrap but its less faster :) daily tests are available at: https://jenkins.debian.net/job/reproducible_debootstrap_unstable/ https://jenkins.debian.net/job/reproducible_cdebootstrap_unstable/ https://jenkins.debian.net/job/reproducible_mmdebstrap_unstable/ -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Where will you go when you become a climate refugee? signature.asc Description: PGP signature
Re: Two questions about build-path reproducibility in Debian
On Mon, Mar 04, 2024 at 11:52:07AM -0800, John Gilmore wrote: > Why would these become "wishlist" bugs as opposed to actual reproducibility > bugs > that deserve fixing, just because one server at Debian no longer invokes this > bug because it always uses the same build directory? because it's "not one server at Debian" but what many ecosystems do: build in an deterministic path (eg /$pkg/$version or whatever) or record the path as part of the build environment, to have it deterministic as well. in the distant past, before namespacing become popular, using a random path was a solution to allow parallel builds of the same software & version. and yes, this is a shortcut and a tradeoff, similar to demanding to build in a certain locale. also it makes reproducibilty from around 80-85% of all packages to >95%, IOW with this shortcut we can have meaningful reproducibility *many years* sooner, than without. and I'd really rather like to see Debian 100% reproducible in 2030, than in 2038. and some subsets today, or much sooner. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Homophobia is a sin against god. signature.asc Description: PGP signature
Re: New requirements for APT repository signing
On Mon, Mar 04, 2024 at 07:47:08AM -, Sune Vuorela wrote: > In theory. I don't know if there are any statistics on 'popular' > 3rdparty repositories and their keys. I suspect src:extrepo-data is a good starting point for anyone interested in generating such statistics... -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The moon landing 50 years ago was paid by taxes, while Bezos space trip was paid by not paying taxes. signature.asc Description: PGP signature
Content and translation status for the debian-edu-bookworm manual
The (translated) debian-edu-bookworm manual in PDF, ePUB or HTML formats are available at https://jenkins.debian.net/userContent/debian-edu-doc// To understand this mail better, please read /usr/share/doc/debian-edu-doc/README. This mail is automatically send by a cronjob run by Holger Levsen every two weeks. Please send feedback, suggestions, flames and cookies via this list. debian-edu-bookworm-manual.da.po: 618 translated messages, 255 fuzzy translations, 165 untranslated messages. debian-edu-bookworm-manual.de.po: 996 translated messages, 30 fuzzy translations, 12 untranslated messages. debian-edu-bookworm-manual.es.po: 1033 translated messages, 5 fuzzy translations. debian-edu-bookworm-manual.fr.po: 792 translated messages, 181 fuzzy translations, 65 untranslated messages. debian-edu-bookworm-manual.id.po: 211 translated messages, 827 untranslated messages. debian-edu-bookworm-manual.it.po: 1031 translated messages, 7 fuzzy translations. debian-edu-bookworm-manual.ja.po: 739 translated messages, 198 fuzzy translations, 101 untranslated messages. debian-edu-bookworm-manual.nb-no.po: 599 translated messages, 304 fuzzy translations, 135 untranslated messages. debian-edu-bookworm-manual.nl.po: 1038 translated messages. debian-edu-bookworm-manual.pl.po: 307 translated messages, 128 fuzzy translations, 603 untranslated messages. debian-edu-bookworm-manual.pt-br.po: 1033 translated messages, 5 fuzzy translations. debian-edu-bookworm-manual.pt-pt.po: 995 translated messages, 43 fuzzy translations. debian-edu-bookworm-manual.pt.po: 1033 translated messages, 5 fuzzy translations. debian-edu-bookworm-manual.ro.po: 1033 translated messages, 5 fuzzy translations. debian-edu-bookworm-manual.sv.po: 756 translated messages, 44 fuzzy translations, 238 untranslated messages. debian-edu-bookworm-manual.uk.po: 1033 translated messages, 5 fuzzy translations. debian-edu-bookworm-manual.zh-cn.po: 805 translated messages, 132 fuzzy translations, 101 untranslated messages. FIXME: The HowTos from https://wiki.debian.org/DebianEdu/HowTo/"/> are either user- or developer-specific. Let's move the user-specific HowTos over here (and delete them over there)! (But first ask the authors (see the history of those pages to find them) if they are fine with moving the howto and putting it under the GPL.) 1 FIXMEs left to fix
