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
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
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: 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
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: 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
Re: usrmerge breaks POSIX
On Thu, Feb 15, 2024 at 10:08:11AM +0100, Vincent Lefevre wrote: > Not for mksh. so the subject should be "mksh is broken with usrmerge"? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ „Never argue with an idiot. They will drag you down to their level and beat you with experience.“ (Mark Twain) signature.asc Description: PGP signature
Re: Confusion over t64 migration
On Sat, Feb 10, 2024 at 12:16:48PM +, Holger Levsen wrote: > I'm also of the opinion that *someone* should do this for all these bugs > but I am too lazy to do it myself. sebas...@debian.org has thankfully done this, 15min before I wrote the above. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Der Mensch is' gut, aber die Leut' san a G'sindel! signature.asc Description: PGP signature
Re: Confusion over t64 migration
On Fri, Feb 09, 2024 at 10:01:06AM -0600, John Goerzen wrote: > So at the moment, I am unclear why there are bugs filed with severity > serious that apparently cannot be fixed. Shouldn't they be normal with > a tag wontfix until the relevant dpkg changes are in unstable? I've downgraded those in packages I care about to "important" once the autoremoval mail arrived. I'm also of the opinion that *someone* should do this for all these bugs but I am too lazy to do it myself. > To put it another way, I'm not seeing why we are reporting RC bugs > against a bunch of packages before it is possible to fix them. indeed. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The people who refer to the pandemic in the past tense and climate change in the future tense are the reason everything is going to shit. signature.asc Description: PGP signature
Re: Bits from the Release Team: Cambridge sprint update
On Sat, Dec 16, 2023 at 06:23:46PM +, Paul Gevers wrote: > During the wonderful mini-DebConf at Cambridge, the Release Team had a sprint > and other discussions. Some of the discussed topics are worth sharing, so here > we go. [...] > Reproducibility migration policy > > > The folks from the Reproducibility Project have come a long way since they > started working on it 10 years ago, and we believe it's time for the next step > in Debian. Several weeks ago, we enabled a migration policy in our migration > software that checks for regression in reproducibility. At this moment, that > is > presented as just for info, but we intend to change that to delays in the not > so distant future. We eventually want all packages to be reproducible. To > stimulate maintainers to make their packages reproducible now, we'll soon > start > to apply a bounty for reproducible builds, like we've done with passing > autopkgtests for years. We'll reduce the bounty for successful autopkgtests at > that moment in time. \o/ and hooray and yay and much looking forward to that! and thanks for acknowledging our work and many thanks to *everyone* contributing so that we've come this far by now! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "I like beautiful people. I don't care about their looks." signature.asc Description: PGP signature
Re: DEP17 - /usr-merge - what has happened - what will happen - what you can do to help
hi Helmut, On Thu, Nov 16, 2023 at 04:35:18PM +0100, Helmut Grohne wrote: > What I actually meant was the set of packages used by debootstrap, but I > wrote essential. ah! > In essence, this is "Priority: required". I'm not sure > about "Priority: important" yet. debootstrap seems to reliably configure > all required packages before unpacking important packages and that may > be sufficient to be safe. Rule of thumb: If your package is in the > "Priority: required" set and has an aliased file, do expect me to send a > patch. :) fwiw, required is also only 27 source packages. and important adds another 27 as well. btw, this made me aware that we (r-b.o) didn't track that, so thanks to this thread there's https://tests.reproducible-builds.org/debian/unstable/amd64/pkg_set_important.html now and in future! > > a mail or a bug? is there a user tag? > A d-devel thread Cced to all relevant maintainers. > https://lists.debian.org/20230912181509.ga2588...@subdivi.de thanks! > We're talking about: > * base-files > * bash > * coreutils maybe > * dash > * libc6 > * util-linux ok, those are kinda important. ;) > > many thanks for all your work on this! > You are welcome. & many thanks to everyone else involved too! -- 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#1054595: ITP: nom -- command line tool that helps you lose weight
Package: wnpp Severity: wishlist Owner: Holger Levsen X-Debbugs-Cc: debian-devel@lists.debian.org, m...@blinry.org * Package name: nom Version : 0.1.3 * URL : https://github.com/blinry/nom * License : GPL2+ Programming Lang: Ruby Description : command line tool that helps you lose weight nom is a command line tool that helps you lose weight by tracking your energy intake and creating a negative feedback loop. It's inspired by John Walker's The Hacker's Diet (https://www.fourmilab.ch/hackdiet/) and tries to automate things as much as possible. I'm using this myself and plan to maintain it in the debian group on salsa. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ In a world where you can be anything, be kind. signature.asc Description: PGP signature
+1 (Re: debian/copyright format and SPDX)
On Fri, Sep 22, 2023 at 08:43:25AM -, Sune Vuorela wrote: > I do think that this is another point of "we should kill our babies if > they don't take off". And preferably faster if/when "we lost" the race. > > We carried around the debian menu for a decade or so after we failed to > gain traction and people centered on desktop files. > > We failed to gain traction on the structure of the copyright file, and > spdx is the one who has won here. > > This is just going to be more useless work. Things can more or less the > same, so let's go with the one where we get the least work requirements > in the long run, and not put more resources into the current version. very much +1 on everything quoted. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ War is peace. Freedom is slavery. Covid is like the flu. signature.asc Description: PGP signature
Re: Bug#1052004: libcbor: requires source-only upload to transition
On Fri, Sep 15, 2023 at 11:29:27PM +0200, Vincent Bernat wrote: > What's the status of throwing away the binaries when doing a non-source-only > upload? it's an existing feature of dak waiting to be enabled by ftp-master. I'd guess that nowish would be a good time to enable it. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Do yo ever think about how capitalism is forcing us to work up until the eminent extinction of our species as the earth heats to an unlivable temperature? (@aishamadeit) signature.asc Description: PGP signature
Bug#1050815: snapshot.d.o has been in a bad state for several months
package: snapshot.debian.org severity: important x-debbugs-cc: debian-devel@lists.debian.org, reproducible-bui...@lists.alioth.debian.org Hi, filing this as a bug report, again, because the problem has become worse than when #1031628 was filed and since snapshot.d.o is part of the central services Debian provides and it should work better than it does right now. else, why do we operate it? ;) On Wed, Aug 02, 2023 at 01:33:11PM +0200, Johannes Schauer Marin Rodrigues wrote: > snapshot.debian.org is getting worse again. There is not a single snapshot for > August yet and the last days of July are spotty: > > http://snapshot.debian.org/archive/debian/?year=2023=7 > > None for the 29. and only a single timestamp for the 26., 27., 28. and 30. > There should be four per day. The situation is even worse for other archives. > For debian-ports, for the month of July, there are only 22 snapshots overall: > > http://snapshot.debian.org/archive/debian-ports/?year=2023=7 > > This problem has been known for half a year already: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031628 > > But that bug got closed in favor of #1029744 which was filed because > debian-ports had no snapshots at all for January and only three for February > this year but there is no reply to that bug. > > In #1031628 Julien said that there is "not much we can do about it at the > moment". > > What is the status of this problem? What is needed to fix it? Is this just a > problem of computational and/or storage resources which an be fixed by the > funds available to Debian? > > I'd argue that snapshot.d.o is part of the central services Debian provides > and > it should work better than it does right now. On https://snapshot.debian.org/archive/debian-ports/?year=2023=8 I count 31 snapshot for those 29 days of August so far, with no snapshots so far for 2023-08-01, 2023-08-08, 2023-08-17 and 2023-08-29. But it get's worse: On Wed, Aug 09, 2023 at 11:34:56AM -0400, Theodore Ts'o wrote: > BTW, it also looks like not only are some snapshots not being taken, > some of the snapshots are missing packages. For example: > >https://snapshot.debian.org/archive/debian/20230806T091912Z/ > > is missing the package libc-dev-bin, and: > >https://snapshot.debian.org/archive/debian/20230807T150823Z/ > > is missing the package dbus. Which is something that I'm finding when > I try building an kvm-xfstests VM using: > > https://github.com/tytso/xfstests-bld/blob/master/test-appliance/gen-image > > Ah, well, I guess I'll try the snapshot for 20230805T151946Z next Please don't just close this bug report as it was done with #1031628, it's useful to be able to track this, point out that this problem has been existed since some time and have a place to discussion workarounds. Also, how can one start helping with this issue (or others)? where does the snapshot team communicate? https://salsa.debian.org/snapshot-team/snapshot/-/commits/master has not seen any commit since 7 months. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Alles weird gut. signature.asc Description: PGP signature
POT creation date should match last modification of the source (Re: Potential MBF: packages failing to build twice in a row)
On Wed, Aug 16, 2023 at 11:42:32AM +0800, Paul Wise wrote: > On Tue, 2023-08-15 at 09:21 -0400, Boyuan Yang wrote: > > --- ibus-array-0.2.2.orig/po/zh_TW.po > > +++ ibus-array-0.2.2/po/zh_TW.po > > @@ -6,7 +6,7 @@ msgid "" > > msgstr "" > > "Project-Id-Version: ibus-array 0.2.2\n" > > "Report-Msgid-Bugs-To: https://github.com/lexical/ibus-array/issues\n; > > -"POT-Creation-Date: 2019-12-10 22:09+0800\n" > > +"POT-Creation-Date: 2023-08-15 09:07-0400\n" > > "PO-Revision-Date: 2019-12-10 22:12+0800\n" > > "Last-Translator: Anthony Fok \n" > > "Language-Team: Chinese (traditional)\n" > I've long been annoyed by this behaviour as an upstream developer on > gettext based projects. I think the most correct upstream solution to > this is that the gettext tools need to be made deterministic. Probably > the POT creation date field should be removed and replaced with the > date of the last source file modification? seems legit. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ “We are about to sacrifice our civilization for the opportunity of a very small number of people to continue to make enormous amounts of money. We are about to sacrifice the biosphere so that rich people in countries like mine can live in luxury. But it is the sufferings of the many which pay for the luxuries of the few.” ― Greta Thunberg signature.asc Description: PGP signature
Re: Questionable Package Present in Debian: fortune-mod
On Mon, Aug 21, 2023 at 06:06:34PM +0200, Wouter Verhelst wrote: > On Sat, Aug 19, 2023 at 02:28:22PM -0400, Roberto C. Sánchez wrote: > https://www.debian.org/code_of_conduct.en starts off with: > > "The Debian Project, the producers of the Debian system, have adopted a > code of conduct for participants to its mailinglists, IRC channels and > other modes of communication within the project." > > Packaged software is not a "mode of communication within the project". > The code of conduct, therefore, does not apply to it. if an image, a png or a jpeg, is considered "software" by us, I'd very well also argue that packaging software is communication to the inside and outside of our project. and if there is disagreement about this, we should extend the CoC. -- 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
Re: [RFC] Extending project standards to services linked through Vcs-*
hi Nik, On Mon, Aug 21, 2023 at 05:00:04PM +0200, Dominik George wrote: > Generally, not having a clear policy on that VCS package maintenance means > is, in my opinion, one of the major obstacles when trying to contribute > to Debian. [...] have you considered dgit? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The past is over. signature.asc Description: PGP signature
Re: Request for review of debootstrap change [was: Re: Second take at DEP17 - consensus call on /usr-merge matters]
On Fri, Aug 11, 2023 at 10:56:03PM +0200, Helmut Grohne wrote: > > what about cdebootstrap? > cdebootstrap (and mmdebstrap) never implemented a merging step[1] and to > this date rely on the usrmerge package doing it at postinst time. Once > base-files ships the aliasing symlinks, both will produce /usr-merged > trees without any modifications. The reason that we need a change to > debootstrap is that its current merging implementation breaks when > base-files ships aliasing symlinks. > > So the main reason for doing this change to debootstrap is that it > enables us to continue supporting cdebootstrap and mmdebstrap without > any changes there. ah, thank you! -- 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: Request for review of debootstrap change [was: Re: Second take at DEP17 - consensus call on /usr-merge matters]
On Fri, Aug 11, 2023 at 09:38:02AM +0100, Luca Boccassi wrote: > > This is implemented in > > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/96 what about cdebootstrap? -- 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
Re: pre-MBF: fail to build (repack) source
On Mon, Jul 17, 2023 at 11:10:52AM +0100, Simon McVittie wrote: > > I wonder what's the point of B-D-Arch And B-D-Indep then? > > The point is the same as it always was: primarily to exclude large > dependencies from a `dpkg-buildpackage -B` build chroot (like the official > buildd for each architecture) if they are only needed when building > Architecture: all packages such as documentation, and secondarily to > exclude large dependencies from a `dpkg-buildpackage -A` build chroot > (like the official "all" buildd) if they are only needed when building > Architecture: any packages. > > B-D-I are required/guaranteed to be installed for builds that will run > `debian/rules build-indep`, and B-D-A for builds that will run > `debian/rules build-arch`. What Adam has been exercising for this MBF > are builds that will do neither, but only build the source package > (`dpkg-buildpackage -S`). This is a somewhat common thing to want to do > if you do all your builds in a chroot, container, VM or remote machine: > you start from an unpacked source directory or git clone, and you want > to build binary packages "over there", which in many cases requires > giving sbuild etc. a .dsc to work with, but you do not necessarily have > all of the "heavier" dependencies on the local development system where > you will convert the source directory into a .dsc. > > You can move tools, libraries etc. from B-D to B-D-A or B-D-I as > appropriate, *if* they are not needed by `debian/rules clean`. In > practice this is usually the case for most "large" build-dependencies. ah, makes sense, thank you! > For instance, if you have documentation built with Doxygen, LaTeX > or other large frameworks, it's usually OK for those tools to be in > Build-Depends-Indep only; or if you have a GTK GUI and you've taken > steps to avoid building it in Architecture: all builds, it's probably > OK for GTK to be in Build-Depends-Arch only. *nods* > One common failure mode is that if your source package only builds > Architecture: all packages, it's tempting to move debhelper from > Build-Depends to Build-Depends-Indep, but that's incorrect for the > reasons that Adam raised here (because debhelper is needed during clean). for src:developers-reference, debhelper is the only package listed in B-D atm :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ First, they came for the transgender, and I spoke out immediatly even though I'm straight and cis because I've read the rest of the fucking poem. signature.asc Description: PGP signature
Re: pre-MBF: fail to build (repack) source
Hi Adam, On Sun, Jul 16, 2023 at 12:03:00AM +0200, Adam Borowski wrote: > Here's a raw list of packages that fail to build their source (ie, > "dpkg-buildpackage -S"). Usually, this is either due to Build-Depends > being inadequate (per the Policy, B-D-Indep are _not_ necessarily > installed), or due to failing the "clean" target from a clean tree. with what severity do you plan to file these bugs? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Every time you see the word "smart" used to describe a device, replace it with "surveillance." Surveillance watch. Surveillance streetlights. Surveillance oven. Surveillance toilet. Surveillance car. Surveillance city. (@mollyali) signature.asc Description: PGP signature
Re: pre-MBF: fail to build (repack) source
On Sun, Jul 16, 2023 at 11:41:36AM +0100, Simon McVittie wrote:
> On Sun, 16 Jul 2023 at 00:03:00 +0200, Adam Borowski wrote:
> > due to Build-Depends
> > being inadequate (per the Policy, B-D-Indep are _not_ necessarily
> > installed)
> For completeness, B-D-Arch are not guaranteed to be installed during
> clean either. Similarly, Build-Conflicts are guaranteed to be absent,
> but the rarely-used Build-Conflicts-{Arch,Indep} are allowed to be
> present during clean. Policy reference for this is §7.7:
> clean
> Only the Build-Depends and Build-Conflicts fields must be
> satisfied when this target is invoked.
I wonder what's the point of B-D-Arch And B-D-Indep then?
Speaking as one of the src:developers-reference maintainers here, which
is affected from the above. Also up to now I've only ever used
dpkg-checkbuilddeps without passing any options...
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Ich glaube die Letzte Generation ist die erste kriminelle Vereinigung in der
Geschichte, deren einziges Ziel es ist, dass sich die Regierung an die
Verfassung und ihre eigenen Gesetze hält. (@muellermusik)
signature.asc
Description: PGP signature
Re: /usr-merge: continuous archive analysis
Hi Helmut, thanks for your continuious work on this! On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > To make matters worse, an upload to bookworm-backports > is immediately available to users and there is no migration that some > check (such as dumat) could hook into. there is NEW processing however and every package going into bookworm-backports needs to go through it... and granted, once it's in there no more NEW processing (unless $conditions), so this not perfect but it's more than nothing. -- 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
Re: Second take at DEP17 - consensus call on /usr-merge matters
On Fri, Jul 07, 2023 at 09:55:05AM +0200, Helmut Grohne wrote: > Thus far, my impression was that temporarily (<1week, preferably <1day) > breaking the ability to debootstrap was an acceptable risk and is > something we experience every now and then anyway (with adduser most > recently). actually, python3-mininmal (#1040316) is the most recent case of debootstrap being broken, not adduser (#1039709). :) AFAIK. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If we'd ban all cars from cities tomorrow, next week we will wonder why we waited for so long. signature.asc Description: PGP signature
Re: amount of bootstrapping tools in Debian (Re: Second take at DEP17 - consensus call on /usr-merge matters)
On Wed, Jun 28, 2023 at 08:59:18PM +, Holger Levsen wrote: > however it's author also said on #-devel just now: [...] < josch> | h01ger: i'm not multistraps author though (josch AFAICS is the last maintainer of it, maintaining it from 2016 to 2018.) my point is: it's more than two tools and let's do this properly. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The system isn't broken. It was built this way. signature.asc Description: PGP signature
Re: amount of bootstrapping tools in Debian (Re: Second take at DEP17 - consensus call on /usr-merge matters)
On Wed, Jun 28, 2023 at 08:28:28PM +, Holger Levsen wrote: > On Wed, Jun 28, 2023 at 09:15:30PM +0100, Luca Boccassi wrote: > > > to how you see things moving forward? > > Changing the bootstrap tools seems much safer. It is just two tools, > three: debootstrap, mmdebstrap and cdebootstrap. four: https://tracker.debian.org/multistrap however it's author also said on #-devel just now: | h01ger: i tried to fix multistrap but failed https://gitlab.mister-muffin.de/josch/multistrap/commit/cd5dfbbbf2435bae8fc34ac32ee7d716c24bada8 < josch> i very much dislike removing stuff that still works -- if you feel differently, feel free to go ahead. i'll not stand in anybodies way :) (quoted here with permission.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Religion has been more harmful to humanity than cigarettes. signature.asc Description: PGP signature
amount of bootstrapping tools in Debian (Re: Second take at DEP17 - consensus call on /usr-merge matters)
On Wed, Jun 28, 2023 at 09:15:30PM +0100, Luca Boccassi wrote: > > to how you see things moving forward? > Changing the bootstrap tools seems much safer. It is just two tools, three: debootstrap, mmdebstrap and cdebootstrap. -- 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
Re: Policy consensus on transition when removing initscripts.
On Sun, Jun 25, 2023 at 03:15:24PM +0100, Mark Hindley wrote: > Debian Policy no longer requires that packages which provide a systemd > .service > file also provide an initscript. This permits maintainers who so wish to > remove > initscripts from their packages. However, initscripts remain used and > useful[1], > and uncoordinated removal can have significant effects on users' systems[2]. > > With the encouragement of the Technical Committee[3] and despite some > unavoidable deficiencies resulting consequent on keeping initscripts without > their intended package[4], orphan-sysvinit-scripts has collected and > maintained > some dropped initscripts. However, the process surrounding this has not been > defined in Policy. Indeed, #975075[5] contains a number of suggestions that > have > not yet been followed through. I'm not sure Debian Policy is the best place to document this, because Debian Policy documents what packages *must* comply with, while legacy initscripts are a thing of the past which still are permitted (and liked & prefered by some), so *maybe* src:dev-ref would be a better place for documenting those best practices? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Homelessness exists not because the housing systemn is not working, but because this is the way it works. - Peter Marcuse. signature.asc Description: PGP signature
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Fri, Jun 09, 2023 at 11:49:21AM +0800, Paul Wise wrote: > > You mean by somehow refreshing the signatures there? > Some ideas for that are here: > https://bugs.debian.org/763419 > https://bugs.debian.org/820423 interesting. thanks for those pointers! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ https://showyourstripes.info signature.asc Description: PGP signature
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Thu, Jun 08, 2023 at 07:14:17PM +0200, Helmut Grohne wrote: > I concur. Given Simon's analysis and the replies even when combined with > earlier messages, I now see significantly more voices for the opinion: > > i386 primarily exists for running legacy binaries and binary > compatibility with legacy executables is more important than correct > representation of time beyond 2038. I agree. (And personally I don't care about i386 at all. I'm happy if we support i386 usecases if this seems reasonable for all involved.) > I'm inclined to call this consensus now [...] I'm inclined to call this consensus of the few people who participated (activly or passivly) in this short & short-lived thread, but I'm not sure we can call this project wide consensus *yet*. RFC on d-d-a? That's at least less heavy than a GR and yet way more visible than just a thread on d-d. -- 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: 64-bit time_t transition for 32-bit archs: a proposal
On Thu, Jun 08, 2023 at 11:19:15AM +0800, Paul Wise wrote: > Would it be feasible to drop i386 but still support this use-case by > requiring folks to use historical releases on archive.debian.org? You mean by somehow refreshing the signatures there? Would IMO also be useful for other archs. :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "Climate change" is an euphenism. "Global warming" as well. signature.asc Description: PGP signature
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, May 12, 2023 at 03:29:29PM +0100, Steve McIntyre wrote: > >> >Oh holy fuck. > So why the hell do you want to break this in the first place? > You're wilfully missing the point, and you know it. > I have better things to do than argue about this. I refuse to engage > with this right now. You're talking about breaking things for *no* > discernible benefit that I've seen any discussion about. language please. and also assume good faith. thanks. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Das Leben ist schön. Von 'einfach' war nie die Rede. (@lernzyklus) signature.asc Description: PGP signature
Re: DEP 17: Improve support for directory aliasing in dpkg
On Thu, Apr 27, 2023 at 10:58:46AM +0200, Marc Haber wrote: > My gut feeling is that we are wasting prescious time of numerous > skilled Debian Developers to find ugly workarounds to something that > should be done in dpkg, but isnt being done because one dpkg > maintainer has decided to not go the way the project has decided to > go. fwiw, I largely agree with this. Constitution 2.1.1 is great, however we don't really have a mechanism how to deal with people flat out ignoring Constitution 6 aka the tech-ctte and doubting and activly working against it's decisions. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ It ain't no revolution, just because you can dance to it. signature.asc Description: PGP signature
Re: Starting the weekly live images for Bookworm building again
On Sun, Mar 19, 2023 at 03:13:47PM +, Steve McIntyre wrote: > So, after some delay from me and some further delays from various > Debian machines committing suicide [1], I've got bookworm live builds > running again. \o/ this is great news! thanks and kudos to everyone involved! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ 40% of homeless people in the United States have full-time jobs. signature.asc Description: PGP signature
Bug#1032440: www.d.o: please link to single html page version of developers-reference
package: www.debian.org severity: wishlist x-debbugs-cc: debian-devel@lists.debian.org hi, On Mon, Mar 06, 2023 at 07:46:43PM +, Holger Levsen wrote: > [...], there's a single page HTML version available again, eg on > https://www.debian.org/doc/manuals/developers-reference/developers-reference.html > which could be linked from https://www.debian.org/doc/devel-manuals#devref > again. & thank you for maintaining www.debian.org! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The past is over. signature.asc Description: PGP signature
src:developers-reference, call for patches, bug fixes & translations
hi, so I've uploaded src:developers-reference 12.17 today, marking the 17th upload during the bookworm release cycle - and I'm not done with src:developers-reference and bookworm yet, though further updates will only change the documentation itself and it's translations. During the bullseye development cycle there were 22 uploads, during the buster development cycle 7 uploads and for stretch there were 4. I'm not going back further, since I hope you'll get my point already: src:developers-reference is in active maintenance again! \o/ & many thanks to everyone who contributed to these uploads! Still, https://bugs.debian.org/src:developers-reference lists 40 open bugs, of which approximitly at least 23 just need 30-60min attention, probably less. So if you're bored during the freeze, please help a bit. ;) And please, feel free to either send a patch to any of these bugs, open a MR on salsa or just commit and push to salsa directly if you're confident the change is sensible. (The package is in the Debian group on salsa, and there's a slightly more verbose README.contributing.) And then, the five existing translations could use some updates: Stats for de: 1276 translated messages, 45 fuzzy translations, 53 untranslated messages. Stats for fr: 1286 translated messages, 39 fuzzy translations, 49 untranslated messages. Stats for it: 869 translated messages, 46 fuzzy translations, 459 untranslated messages. Stats for ja: 891 translated messages, 26 fuzzy translations, 457 untranslated messages. Stats for ru: 870 translated messages, 44 fuzzy translations, 460 untranslated messages. (I don't plan to add any new translations during bookworm development, except maybe if a complete new translation pops up.) I'd appreciate forwarding this mail to the appropriate translation mailing lists *and* cc:ing me on those mails, so in future I can notify them myself. Last and least, there's a single page HTML version available again, eg on https://www.debian.org/doc/manuals/developers-reference/developers-reference.html which could be linked from https://www.debian.org/doc/devel-manuals#devref again. (I'll reply to this mail turning this paragraph into a bug report against www.debian.org :) Feedback very much welcome. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Smart things make us dumb. signature.asc Description: PGP signature
Re: Reducing allowed Vcs for packaging?
On Sun, Feb 26, 2023 at 10:25:21AM -0700, Sean Whitton wrote: > Why don't we just fix all those packacges, instead of changing any > documents? Is there anyone who actually wants to introduce new packages > not using git? I'm not so sure. mostly agreed, i'm just sure there will be very few people who want that, though for the scope of developers-reference I think those should be ignored. that said, dev-ref currently only explicitly mentions vcs-git. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The mark of a civilized man is the ability to look at a column of numbers and weep. (Bertrand Russell) signature.asc Description: PGP signature
Re: Consensus on closing old bugs
On Sat, Feb 11, 2023 at 10:45:16PM +0200, Adrian Bunk wrote: > On Mon, Feb 06, 2023 at 10:07:59AM -0700, Sam Hartman wrote: > > Most of us do not prefer to close bugs simply because they are old. > It creates angry users and no real benefits. this is undoubtingly true for some bugs and users. for other bugs (and users) there will be no reply ever and unactionable bugs clutter the view and harm bug fixing. so I don't think there is a general rule and I also don't think asking "does this bug still apply?" is harmful, nor is closing very old bugs against ancient versions. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Every time you see the word "smart" used to describe a device, replace it with "surveillance." Surveillance watch. Surveillance streetlights. Surveillance oven. Surveillance toilet. Surveillance car. Surveillance city. (@mollyali) signature.asc Description: PGP signature
Re: Please, minimize your build chroots
On Sat, Jan 28, 2023 at 03:11:39PM +0100, Johannes Schauer Marin Rodrigues wrote: > And I asked in my mail to please "decouple the policy and bug severity > question > from the question of what a buildd chroot should contain" for a reason. yes, I know. my point was that too many people won't be able to do this (which this thread proves again.) > Discussing policy questions and bug severity distracts from the actual > question > that I find interesting. yes. (and as (too many) people are not able to do this my suggestion is to lower the severity of these bugs. not every policy violation is RC.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Some of my friends and I overcommit to things, so we made "Saying No to Things" punch cards. If you say no to 10 things, your friends have to buy you an ice cream. In a pilot study, we found participants both said no to more things and got more free ice cream. (@leah_pierson) signature.asc Description: PGP signature
Re: Please, minimize your build chroots
On Sat, Jan 28, 2023 at 02:28:30PM +0100, Johannes Schauer Marin Rodrigues wrote: > could we decouple the policy and bug severity question from the question of > what a buildd chroot should contain, please? [...] > Why do people call just accepting that Priority:required packages have to be > part of the buildd chroot the easier solution? [...] because people get upset if they receive bug reports with severity serious when they don't perceive these bugs as serious. happened more than 9000 times already. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ This too shall pass. signature.asc Description: PGP signature
+1 (Re: SONAME bumps (transitions) always via experimental)
On Thu, Jan 05, 2023 at 12:26:09PM +0100, Paul Gevers wrote in a mail with the subject "SONAME bumps (transitions) always via experimental)": > Are there objections against this workflow? (Or voices from people who like > this?) I like this. -- 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: Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions
On Fri, Dec 16, 2022 at 01:22:30AM +0100, Juri Grabowski wrote: > Quebes is not really RPM distribution as long I know. It is: Qubes' dom0 is based on Fedora. (and then you can install (almost) any other distro in domU, not just linux however, but also BSDs, Mirage, Windows or something else.) -- 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
Re: Enabling branch protection on amd64 and arm64
On Tue, Nov 01, 2022 at 01:09:39AM +0100, Sebastian Ramacher wrote: > > this change is only targeted at two archs, which I'd hope could cope with > > it. > If we ignore/break MA: same co-installability, sure. point taken, thanks! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Punk ist nicht tot. Punk trägt Maske, ist solidarisch und schützt sich und andere. (@Kreuzpirat) signature.asc Description: PGP signature
Re: Enabling branch protection on amd64 and arm64
On Thu, Oct 27, 2022 at 12:27:12AM +0200, Sebastian Ramacher wrote: > Some of the architectures already have a hard time keeping up with the > normal load. this change is only targeted at two archs, which I'd hope could cope with it. > Enabling these flags as soon as the trixie release cycle starts, sounds > like a better idea. Adoption of these flags will then naturally progress > and before the trixie release we can rebuild whatever remains. even^walso if this is done only for the trixie cycle I think it would be good to binNMU all affected packages, which I would guess to be around 25-33% of the archive. because else we cannot really say whether we have enabled this feature archive wide and whether it works/builds ;) summary: I think the next step should be calculating how many packages are affected. because the above 25-33% is my guestimate only. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ https://showyourstripes.info signature.asc Description: PGP signature
Re: Firmware GR result - what happens next?
On Fri, Oct 14, 2022 at 01:32:41PM +0800, Paul Wise wrote: > 4. Keep all non-free-firmware packages in non-free too. This would be > backwards compatible, but may expose bugs in dak, debian-cd, apt and > other tools, so IIRC this has been vetoed by the archive and CD teams. > This also wouldn't result in users without non-free getting any of the > non-free firmware, which maybe we want since it is the new default? > > Personally I would choose 4 first, I expect any potential issues could > be easily fixed before the freeze. but what would you then propose after the release, where we would have exactly the same situation as we would have now. carry this on forever? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ When this virus is over, I still want some of you all to stay away from me. signature.asc Description: PGP signature
Re: Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
Thanks Antoine and Dylan for those two mails today, now I have a much better understanding of the reasons for switching! -- 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: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Fri, Sep 09, 2022 at 09:38:39PM +0200, Michael Biebl wrote: > Should we repeat this mistake? Or put this differently: is there a pressing > need/compelling reason to switch to pipewire in bookworm? > I.e. what I miss from the proposal are the benefits of pipewire over > pulseaudio. > Can you elaborate why you'd want to make the switch in bookworm? yes, I'm missing answers to these questions too. > Personally, I'd rather see pipewire mature a little bit more before we make > the switch. same here. > This puts less pressure on you, as maintainer, and pipewire as upstream > project. yes. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Money is worth nothing on a dead planet. signature.asc Description: PGP signature
Re: Need a buildd build after trip through NEW -- best practice?
On Wed, Aug 24, 2022 at 10:06:55PM +0200, Paul Gevers wrote: > > The patch for dropping NEW binaries has been in dak for two years but > > its configuration options were never enabled by ftp-master so far. > > Dinstall::ThrowAwayNewBinarySuites > > Dinstall::ThrowAwayNewBinaryComponents > I would be a great fan of this happening. YES, please. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If you liked Corona, you will also enjoy the upcoming global climate disaster. signature.asc Description: PGP signature
Re: Need a buildd build after trip through NEW -- best practice?
On Thu, Aug 25, 2022 at 07:13:52PM +0800, Paul Wise wrote: > On Thu, 2022-08-25 at 11:04 +0200, Paul Gevers wrote: > > In testing and on release architectures, I'm only aware [1] of one that > > can't build arch:all+arch:any binaries on amd64 (cmucl), but even that > > one builds its arch:all binaries on amd64. I'm wondering if there are > > packages where this is a known issue (and with the missing header, is > > there a way the outside world can track this)? > I guess finding out the list of such packages would require someone to > do a rebuild run of the arch:all packages on arm64 or similar. https://tests.reproducible-builds.org/debian/ does rebuild of all source packages for arm64, armhf, i386 and amd64. https://tests.reproducible-builds.org/debian/unstable/arm64/index_blacklisted.html shows 3 packages we have blacklisted on unstable/arm64. https://tests.reproducible-builds.org/debian/bookworm/arm64/index_blacklisted.html shows 1 package blacklisted on bookworm/arm64. https://tests.reproducible-builds.org/debian/bookworm/arm64/index_FTBFS.html shows 1105 packages failing to build on bookworm/arm64, while only 829 packages fail to build on bookworm/amd64 as shown on https://tests.reproducible-builds.org/debian/bookworm/amd64/index_FTBFS.html This data is also available via json as described in https://jenkins.debian.net/userContent/about.html#_reproducible_builds_jobs There are two JSON files which can be downloaded from https://tests.reproducible-builds.org/reproducible.json and https://tests.reproducible-builds.org/reproducible-tracker.json The 1st one has all the data (except history) and the 2nd has all the data we consider relevant to bother maintainers with, that is, some ftbfs isses are excluded. -- 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: Need a buildd build after trip through NEW -- best practice?
On Tue, Aug 23, 2022 at 04:59:10PM -0500, Steven Robbins wrote: > Commonly, I update a package that provides a shared library. Due to the > package naming convention, a new SOVERSION necessitates a trip through NEW, > which in turn means a binary upload. > > The binary upload cannot transition to testing -- a buildd binary build is > required. So far as I know -- assuming [1] is still up-to-date, this means a > nuisance upload just bumping the debian revision from -1 to -2. Is this > still > the recommended practice? yes. it's rather easy to do too, though maybe there should be something in src:devscripts implementing something along these lines: dch -i -m "Source only upload for testing migration." dch -r debuild -S cd .. ; dput $changes_file # git commit & git tag 4 out of these 5 steps I've automated for myself with small scripts written catering how "my" packages are maintained (which is the part where putting this in src:devscripts is not that easy...). "debuild -S" I do manually, because sometimes that's all I do and sometimes I feed the resulting source package into yet another small script called 'spb', because it's running _s_udo _p_builder _b_uilt on the latest source package in $PWD. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ When this virus is over, I still want some of you all to stay away from me. signature.asc Description: PGP signature
Re: Epoch for node-markdown-it
On Sat, Aug 20, 2022 at 03:29:59PM +, Stefano Rivera wrote: > > > Epochs cause problems, [...] > > which are? (I agree they are ugly and should often be avoided, but I don't > > see any unsolved problems with them, which is why I'm asking.) > The standard one is that people use them to revert an upload. ok, I agree that's bad. (but not the case here.) > But, epochs aren't used in the upstream tarball filename, so you then > easily get a conflict between the old and the new one. I'd replace 'easily' with 'theoretically in rare cases' but I can see how this is a valid point, sometimes. Thanks for the feedback. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ A single bitcoin transaction alone consumes 621 KWh, or half a million times more energy consumption than a credit card payment. The bitcoin network annually wastes 78 TWh (terrawatt hours) annually or the energy consumption of several *million* US households. https://twitter.com/smdiehl/status/1350869944888664064 signature.asc Description: PGP signature
Re: Epoch for node-markdown-it
On Fri, Aug 19, 2022 at 06:00:44PM +0100, Simon McVittie wrote: > Epochs cause problems, [...] which are? (I agree they are ugly and should often be avoided, but I don't see any unsolved problems with them, which is why I'm asking.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ It's not climate change nor climate crisis, it's climate disaster. signature.asc Description: PGP signature
Re: Epoch for node-markdown-it
On Fri, Aug 19, 2022 at 05:50:46PM +0200, Andrej Shadura wrote: > As Jonas said, an epoch cannot be undone, +really can, regardless when this > is going to happen. Both are ugly solutions, but an epoch is also evil, > unlike +really it's still only version number cosmetics, or nit-picking or maybe even just xkcd/386 :) as a user, I definitly don't care. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Religion has been more harmful to humanity than cigarettes. signature.asc Description: PGP signature
Re: Coq packages in Debian : difficult transitions
On Sun, Jul 31, 2022 at 01:00:03PM +0200, julien.pu...@gmail.com wrote: > > Please file a transition bug. The mailing list has a high volume and > > non-bug mails may be overlooked. > Well, I would file a bug for a specific transition, but first I would > like to discuss how to handle transitions for Coq-related packages in > general. file a general bug against release.debian.org then. The mailing list has a high volume and non-bug mails may be overlooked. ;) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If you upload your address book to "the cloud", I don't want to be in it. signature.asc Description: PGP signature
+1 (Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name)
On Wed, Jul 20, 2022 at 10:16:19AM -0600, Sam Hartman wrote: > Yes, it's one of the ways people learn about software that is being > packaged and they might like to become involved in. > I find reading ITPs > > 1) increases my interest in Debian because I see cool stuff people are > doing > > 2) Is one of the ways I learn about software I might find useful > > 3) Potentially could point me in the direction of software to contribute > to. > > All those are valuable to me even when an ITP is filed immediately > before uploading. > > I agree that we could find other ways of getting that information to > people who are interested. > But today, in my work flow, ITPs are useful to me as an ITP consumer > even if immediately before upload. +1 to evertyhing quoted. Thanks, Sam! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "A developed country is not a place where the poor have cars. It's where the rich use public transportation." (quote attributed to several people) signature.asc Description: PGP signature
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Sat, Jul 16, 2022 at 10:05:59AM +, Stefano Rivera wrote: > I think it's our business, as a community, and as conference organisers, > to try to increase the diversity at our events. To me, that means > increasing speaker diversity, primarily. Attendee diversity won't change > unless the speaker diversity changes. I agree, I just don't see how collecting statistics can be useful here. OTOH I know about several cases where harmless and unneeded data collection has become harmful later. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Imagine god created trillions of galaxies but freaks out because some dude kisses another. signature.asc Description: PGP signature
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Sat, Jul 16, 2022 at 09:12:16AM +, Stefano Rivera wrote: > If you're asking about DebConf 22, we have that information: [...] > I guess we should expose this in our conference statistics. We care > about it. but why? how is gender relevant for participating in DebConf as a whole? (i can see how it could be relevant for some events, but not for the whole conference.) society should be *less* about gender, sex, race, etc, not more. that's at least for me the reason why I usually select "decline to state". my gender is none of your business for running DebConf. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ There are no jobs on a dead planet. (Also many other things but people mostly seem to care about jobs.) signature.asc Description: PGP signature
Re: how to convey package porting details?
On Mon, Jun 06, 2022 at 10:47:38AM +0200, Marco d'Itri wrote: > Is this really worth the effort, considering that probably RISC-V is > going to be our last port for a very long time? you mean like 640kb should be enough for everyone? :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Words may inspire but only action creates change. signature.asc Description: PGP signature
Re: Firmware: Scope of non-free-firmware
On Wed, May 11, 2022 at 12:04:15AM +0200, Vincent Bernat wrote: > ❦ 10 May 2022 14:30 -06, Sam Hartman: > > 2) We value being able to build from source when we can. We value > > being able to have reproducible builds when we can. We don't want to > > take steps backward in those areas in order to get hardware working > > better. > Is there any firmware that would match this? yes, eg coreboot for some devices. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ A single bitcoin transaction alone consumes 621 KWh, or half a million times more energy consumption than a credit card payment. The bitcoin network annually wastes 78 TWh (terrawatt hours) annually or the energy consumption of several *million* US households. https://twitter.com/smdiehl/status/1350869944888664064 signature.asc Description: PGP signature
Re: Reminder to participate in the Debian Developer's Survey
On Wed, May 04, 2022 at 07:19:34AM -0300, David Bremner wrote: > For the record, I gave up on the survey about half way through because > it refused to let me advance without giving an answer to one of the > questions. Consider this feedback on the survey design. for the record, I gave up on the survey halfway through because I felt the questions were too intimidating/private given that I could only participate unanonymously. I also then made sure that my answers given were deleted from the db. I liked the idea of such a survey, incl. the limitation to Debian members, but once I realized what data is collected and without anonymisation, I didn't want to participate anymore. I'd be happy to participate once this has been approved. (And I don't need perfect anonymity here, I do trust the folks running the survey.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ June 2021 was the hottest on record for the Northern Hemisphere. In fact, 2019, 2020 and 2021 are the three hottest Junes on record for the Northern Hemisphere. (@ScottDuncanWX) signature.asc Description: PGP signature
writing good GR ballots (Re: Firmware - what are we going to do about it?)
On Wed, Apr 20, 2022 at 10:52:04AM -0700, Russ Allbery wrote: > I agree with this option split, but that reminds me of a different > procedural note. > > While I recognize and respect the desire to create a comprehensive ballot, > I'm still going to advocate for proposing a GR only with the options that > the person proposing the GR would vote above NOTA, and possibly only your > preferred options. > > There are a couple of reasons for this. One is that the people who prefer > your disfavored options may have their own way of wording them that's > slightly different than what you might believe they would want to say, and > it's awkward to update other people's ballot options. The other, somewhat > more technical reason is that I expect this GR to require a 3:1 majority > for some options, and mixing 3:1 and 1:1 majority options on the same GR > can be rather confusing. We may end up needing to do that anyway for this > vote, but I think it would be a good idea to avoid creating the problem > unless someone steps forward and proposes a 1:1 option that they really > want to win. > > (That said, I think there's a big exception, which is that if you've > canvassed a bunch of people who may not want to try to craft their own > ballot options, and developed options to reflect their views, I think > that's a fine approach and a good reason to propose options that aren't > your personal preference.) > > As a side note, I don't remember exactly how this worked before, but under > the current constitutional rules the original GR proposer doesn't have a > special ability to put a bunch of options on the original ballot. You > start with one option, and then you can add more options but they all need > to be sponsored independently. So that also pushes in this direction of > ballot construction. would it make sense to document this (and more) somewhere as 'guidelines for writting good GR ballots' or some such? I'd guess the wiki would be a good starting point or maybe somewhere else? does this exist already -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The entire society has no clue what the word freedom means in the context of relating to the world around them. It has degenerated into "my ego first". It is why the entire planet is dying right now. signature.asc Description: PGP signature
Re: Firmware - what are we going to do about it?
hi Steve, On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre wrote: > TL;DR: firmware support in Debian sucks, and we need to change this. See the > "My preference, and rationale" Section below. [...] and anyone involved, especillay including those not listed here: > Thanks to people who reviewed earlier versions of this document and/or made > suggestions for improvement, in particular: > > • Cyril Brulebois > • Matthew Garrett > • David Leggett > • Martin Michlmayr > • Andy Simpkins > • Neil Williams I just wanna say THANK YOU VERY MUCH for this thread and everything good which will undoubtfully arise from it. You rock. And for those unware I would just like to point out https://en.wikipedia.org/wiki/Intel_ME#Hardware which explains that on modern Intel CPUs, there's another 386 CPU inside the CPU, running Minix, so that "The ME has its own MAC and IP address for the out-of-band interface, with direct access to the Ethernet controller; one portion of the Ethernet traffic is diverted to the ME even before reaching the host's operating system". My point is not, that other CPUs don't have this problem, but rather that there's a lot of 'invisible' firmware on any modern computer, starting with the CPU but going down all the way to the battery, screen, mouse and keyboard. So this thread is (roughly guesstimated) only about 10-23% of the firmware running on your computer, while today (as opposed to 1993) most of this firmware *can* be updated. IMO firmware is (sadly or not) somewhat out of scope for Debian. Even though, or maybe precisely because hardware *is* software nowadays. So, I'll say it again: many thanks to everyone involved in improving running Debian on modern computers. And huge thanks to those working on free and open hardware too. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ War is peace. Freedom is slavery. Covid is like the flu. signature.asc Description: PGP signature
Re: proposed MBF: packages still using source format 1.0
On Mon, Mar 14, 2022 at 01:10:19PM +, Wookey wrote: > > You're trying to produce packages from CI builds or other automation > > where you sometimes have native Debian revisions. > > > > * you are producing a package where you have distinct upstream and > > debian branches, and you cannot control the upstream version number. > > Doesn't this make it 'not a native debian package'? yes, exactly, that's the problem. > I thought the whole point of debian native packages was that there was > no 'upstream' and it was only for debian so you _are_ in control of > the source, the versioning and the releases? yes, that was the idea when native packages were introduced over 20 ago, when there were hardly any Debian forks, and certainly no CI systems and other automated systems which 'constantly fork'. > As soon as that stops > being true then should one not shift to making it a standard > 'upstream+debian revision' non-native package? yes, we should convert all native packages in our archive, the idea of a native package has been obsoleted for long. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Humans despise their genitals so much they often use them as metaphors for humans they dislike. signature.asc Description: PGP signature
Re: proposed MBF: packages still using source format 1.0
Hi Lucas, On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote: > There are 629 packages in bookworm that use source format 1.0. That's 1.9% of > bookworm packages. many thanks for filing these bugs and even more thanks for filing them with severity wishlist! I've just read one bug report of these, on a package I'm vaguely interested, and it felt really good to receive it: knowing/learning there are 1.9% of these packages and being prodded with wishlist, felt very reasonable, a suggestion given with pat(c)hes to learn and grow, yay. Thanks, again. :) ! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Only change is constant. signature.asc Description: PGP signature
Debian Reunion Hamburg 2022 from May 23 to 30
hi, as last year there will be a Debian Reunion Hamburg 2022 event taking place at the same location as previous years, from May 23rd until the 30th. See https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg for much more information! This is just a preliminary announcement to get the word out, that this event will happen, so you can ponder attending. Some fine folks have even already registered! A few things still need to be sorted out, eg a call for papers and a call for sponsors. If you want to help with that or have questions about the event, please reach out via #debconf-hamburg on irc.oftc.net or via the debconf-hamburg mailinglist, see https://lists.debian.org/debconf-mini-hamburg/ I'm very much looking forward to meet some of you again soon and getting to know some others for the first time! Yay. It's been a long time... -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "All opinions are not equal. Some are a great deal more robust, sophicated and logical than others." - DouglasAdams signature.asc Description: PGP signature
Re: proposed MBF: packages still using source format 1.0
Hi Lucas, thanks for doing this MBF! I agree with the other two replies and have another thing to add: On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote: > I propose to file bugs using the following template, and make them Severity: > serious after a month (minimum). > > -->8 > Subject: upgrade to 3.0 source format > Severity: important I think those severities are too high and that they will cause unneeded friction and frustration, also because (I think) they are not meeting the BTS criteria: serious: is a severe violation of Debian policy (roughly, it violates a "must" or "required" directive), or, in the package maintainer's or release manager's opinion, makes the package unsuitable for release. important: a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. So I'd rather propose to file these bugs with severity 'normal' and then wait and then get policy updated, and then raise the severity further. To be frank: right now (or in a month) I'd just shake my head at severity 'serious', downgrade the bug and do something else. I totally agree it's a smell (for some packages, see other replies) but IMO definitly not seriously smelly :) IOW: It doesn't stink, it's just a tiny bit awkward and less than ideal. And that's neither important nor serious. Finally and again: thank you for doing this work! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "Climate change" is an euphenism. "Global warming" as well. signature.asc Description: PGP signature
Re: MBF: valgrind-if-available
On Sun, Feb 27, 2022 at 03:40:09AM +0100, Adam Borowski wrote: > No, and the recent debacle revealed enough reasons that I'm pondering a MBF > to change that _back_ in packages which followed the bad advice. do you have a # as a starter? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Alles weird gut. signature.asc Description: PGP signature
Re: Including build metadata in packages
On Sun, Feb 13, 2022 at 02:13:10PM -0800, Vagrant Cascadian wrote: > Curious to hear your thoughts! I'd just like to comment with three rather general comments: a.) thanks for bringing this up here, Vagrant. b.) solving this seems to be a requirement for getting the build-essential package set reproducible in Debian.(!) c.) solving this could include solving the distributing Debian .buildinfo files problem(s) - some of which are collected here: https://wiki.debian.org/ReproducibleBuilds#Big_outstanding_issues IOW, this could become a *major* step towards reproducible Debian! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The devel is in the details. signature.asc Description: PGP signature
Re: developers-reference "vs" wiki.debian.org/DebianMaintainer
On Fri, Feb 11, 2022 at 12:25:36AM -0600, Gunnar Wolf wrote: > I agree with Stephan's and Sam's reasoning, I think the detailed > information should be in the devref. > > A wiki is by definition open to edition by any (authorized?) user; the > devref has named editors (as you are very well aware ;-) ) and can be > seen as verified and curated information. I think the information > should be concisely explained in the devref, leaving the Wiki for more > full/detailed information on specific points, examples, or documenting > changes as they are discussed or implemented, Ok, thanks for your feedback, Gunnar, Sam, Stephan & Jochen! I'll take this route soon. > while waiting for them > to arrive to the devref's next edition. fwiw, I've switched the release modell of src:developers-reference to 'release early, release often', which means I basically aim to release directly after each substancial change. By looking at the version number in bullseye, which is 11.0.21, you can easily see this ment I did 21 uploads in the two years of developing bullseye. (This poses challenges to translations to say the least, which I plan to address eventually.) More help (best in form of patches or commits) absolutly very welcome! Any member of the Debian group on salsa can and should commit freely & with responsibility :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ People call vaccine mandates "Orwellian" even though Orwell died at 46 of tuberculosis, which is now preventable with a vaccine. signature.asc Description: PGP signature
developers-reference "vs" wiki.debian.org/DebianMaintainer
hi, so Stephan Lachnit submitted an MR for developers-reference on Monday to document how to grant DM upload permissions, which I gladly merged, even though I was aware of "#653399: developers-reference: Please include a paragraph about Debian Maintainers (DM)" still being unresolved. Which lead me to (quoting from #-devel that day) < h01ger> stephanlachnit: now i'm wondering how much of https://wiki.debian.org/DebianMaintainer i should copy into developers-reference... i've seen you also documented the dcut commands there, which makes sense as it is now, though i'm not convinced it's good to have all the docs in two places < h01ger> so i'm also pondering about mostly adding a pointer to that wiki page to devref < h01ger> (the wiki and devref are both GPL2 licenced, so that part is easy :) < h01ger> feedback from anyone is welcome of course, not just stephan :) So what do you all think? I'm leaning towards explaining the basics in devref (mostly by copying bits from the wiki page) and adding a pointer to the wiki page, but if there's consensus that the wiki page is supposed to be made obsolete by *moving* the contents to src:devref and leaving a pointer on the wiki page, I could also do that. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The vision of self driving cars is nothing compared to the vision of no cars at all. signature.asc Description: PGP signature
Re: NEW processing friction
On Mon, Feb 07, 2022 at 09:28:16PM -0500, Theodore Ts'o wrote: > The argument why a package which has an upstream-induced shared > library version bump, has to go through the entire NEW gauntlet [...] I hear your frustration but don't you think that language like "gauntlet" makes it, uhm, very hard for the "gauntlet team" to reply, and even more importantly, reason with you? IOW: how can we get to 'no NEW (or a much lighter one) for new binary packages' or how can we communicate this if we already have this, maybe also? 'cause I think the latter could very well also be true, or very close to it. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Never waste a crisis. signature.asc Description: PGP signature
yet another thread about NEW
On Wed, Jan 26, 2022 at 11:43:36AM +0100, Adam Borowski wrote: > Without the NEW queue, there would be no point at which packaging receives > any sort of review. I'd prefer Debian to deliver at least some level of > quality. +1 -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Privacy is a Human Right. (Universal Declaration of Human Rights, article 12.) signature.asc Description: PGP signature
Re: What are the most important projects that Debian ought to work on?
On Mon, Jan 24, 2022 at 12:19:25PM +0100, Sébastien Delafond wrote: > We were thinking of sending the survey itself in about 2 weeks, so > that'd be the timeline for your ideas to appear in there. ah, cool, thanks. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If nothing saves us from death, may love at least save us from life. signature.asc Description: PGP signature
Re: What are the most important projects that Debian ought to work on?
Hi Séb, On Mon, Jan 24, 2022 at 10:31:01AM +0100, Sébastien Delafond wrote: > As part of an upcoming survey that we are preparing, we plan to ask > Debian developers to rank, by order of importance, the most popular > ideas of improvements for Debian. thanks for doing this! I'm curious for the results... > That's where you come into play: it would be nice if you could share > what are — according to you — the most important projects/improvements > that Debian ought to make. You can share your ideas here by replying to > this email, but it would be interesting to file them as new issues in > the "grow-your-ideas" project and then reply here pointing to your new > issue: > https://salsa.debian.org/debian/grow-your-ideas/-/issues what timeline do you have in mind for this, as in, until when should these ideas be filed? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The vision of self driving cars is nothing compared to the vision of no cars at all. signature.asc Description: PGP signature
Re: Dropping dpatch for bookworm
hi Moritz, On Fri, Jan 07, 2022 at 12:35:12AM +0100, Moritz Mühlenhoff wrote: > There are only 24 packages left using dpatch and the vast majority of > remaining > uses are packages which haven't seen a maintainer upload for a decade or > longer. [...] > So unless there's objections, I'd bump existing bugs to RC and file bugs where > they don't exist. And anything that doesn't get fixed/NMUd/removed can then > be removed along with dpatch before the bookworm freeze. yay, thanks for this cleanup work! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ https://showyourstripes.info signature.asc Description: PGP signature
Re: MBF: please drop transitional dummy package foo (if they were part of two releases or more)
hi, On Sun, Aug 22, 2021 at 08:47:06PM +0200, Moritz Mühlenhoff wrote: > Holger Levsen wrote: > > again, I'm planning an small mass bug filing against obsolete transitional > > packages, which are at least marked "dummy transitional" since the buster > > release, > > Thanks for taking care of this! > > But I'm wondering if this wouldn't be a perfect task for a Debian Janitor > fixer > script, have you considered filing a task for this? After all those > transitional > deps are reliably detectable and fixable. actually there's already a bug, #982655 (cc:ed), titled "scrub-obsolete: replace dependencies on transitional or removed packages" which I believed could be extended to also cover removing transitional packages which have been present for more than 2 releases. Jelmer, do you agree or do you want another bug for this feature request? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If we'd ban all cars from cities tomorrow, next week we will wonder why we waited for so long. signature.asc Description: PGP signature
Re: DD(s) to help DM land some long-overdue package updates?
On Sat, Jan 01, 2022 at 02:48:49PM -0500, Boyuan Yang wrote: > should be the correct choice. For a specific example, I just spotted > https://bugs.debian.org/961136 the second time (last time back in May 2020); yet the bug was never pinged after it was filed. and so as many bugs it "got lost", despite being there. I wouldn't blame a busy maintainer for that. I'd rather blame myself for not pinging the bug in >18 month despite caring. it's ok to ping bugs without an answer (after a sensible amount of time), and it's ok to ping again and again (again, after sensible time). -- 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
Re: [RFC] changes to rsyslog
On Wed, Nov 17, 2021 at 10:57:11AM +0800, Paul Wise wrote: > > Do you know of a tool that does what logcheck does, but operating > > directly on the journal? Logcheck is the only reason I still have > > rsyslog installed on the servers I maintain. same here, I use (and tune) logcheck on all systems I maintain and absolutly don't wanna miss what I regulary learn from it. > There are some similar things: [...] none of them seem to be availble in Debian and/or on par of what logcheck does. Happy to be proven wrong or outdated! :) -- 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
Re: Bug#1000000: fixed in phast 1.6+dfsg-2
congrats to the Debian Med team for filing #100 *and* fixing it so quickly! well done & well deserved to hit this "special bug" :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Words may inspire but only action creates change. signature.asc Description: PGP signature
Re: Proposed mass bug filing: packages without support for build-arch and build-indep
On Sat, Nov 06, 2021 at 11:31:25AM +0100, Emilio Pozuelo Monfort wrote: > I think severity serious is fine if you use an appropriate Version so that > this won't block testing migration. I would still prefer if this was filed > at important severity, and raised to serious after a month or so. given (too) many maintainers (sometimes) react very emotionally to serious bugs filed against "their" packages and given we're early in the release cycle and given this effects some hundred packages I think it would be better to file these bugs with severity "important" and then raise the severity a month later (and announce this in each filed bug from the start.) This will achieve the same effect from an archive perspective and is hardly any different (after 8 years in policy) nor any more work. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The apocalypse is here now, it’s just not equally distributed. signature.asc Description: PGP signature
Re: deb822 sources by default for bookworm
On Wed, Nov 03, 2021 at 05:32:53PM +0100, Julian Andres Klode wrote: > I don't know, to be honest, have not thought about it yet. many thanks for your verbose reply! /me likes this timeline. > I think an automatic migration might be to painful what with all the > juju and ansible and saltstack (I feel like it'd be nice to have > those tools migrate config to new formats). I guess it would be nice if those tools (and users not using those tools) could run one standard tool doing the job :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ This too shall pass. signature.asc Description: PGP signature
Re: deb822 sources by default for bookworm
Hi Julian, this sounds like a nice and useful plan and feature(s), thank you! just one question: On Wed, Nov 03, 2021 at 04:45:15PM +0100, Julian Andres Klode wrote: > I'd like us to move from > /etc/apt/sources.list > to > /etc/apt/sources.list.d/debian.sources [...] > #timeline You didn't say so explicitly, but do you plan to support old style /etc/apt/sources.list until forever? ;) Or do you envision automatic migration of that file? Or? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Only change is constant. signature.asc Description: PGP signature
thank *you*, team@security.d.o! (was Re: [SECURITY] [DSA 5000-1] openjdk-11 security update)
hey hey, hear hear! On Mon, Nov 01, 2021 at 07:44:34PM +, Moritz Muehlenhoff wrote: > - > Debian Security Advisory DSA-5000-1 secur...@debian.org WHHO! that's *something* to *celebrate*!!1 Very many thanks to the whole Debian security team, past and present, and to everyone contributing! You rock! A lot! 5 whooping thousand (counted) times so far! Thank you very much once more, and not enough, not even close. ! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ It's climate crime, not climate change. signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
On Sat, Sep 25, 2021 at 06:49:53PM -0400, Nick Black wrote: > So the only ones covered by partman and not covered by growlight would be: > amiga, atari, sun, > and mac (if mac is not the same as APM). I don't see any difficulty in > adding these four, so long > as there's someone with an Amiga or ATARI who'd be willing to test them > out. If there are no such > people, is it that important? those ancient hardwares are not important to Debian, we have ceased to support them years ago. some people OTOH support them on Debian Ports and some of these people are very vocal about the need of supporting architectures there. In my opinion they should only be heard if they also offer to do the work needed to keep those ancient architectures alive. (and so far I've not even read an offer to help *testing* such code there and also no offer to help developing such code...) blocking progress on main Debian architectures because of some unsupported ancient hardwares seems more problematic to me than not supporting those ancient plattform. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ It's not about saving the climate or the planet, it's about saving us, the children and grandchildren. The planet will survive anyway. signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Sun, Sep 12, 2021 at 03:10:27AM +, Paul Wise wrote: > ISTR the future of creating new Debian installations is to move from > debootstrap to dpkg/apt. As an interim step, debootstrap could [...] I've switched all my occurances of using debootstrap to mmdebstrap and am a very happy user of it. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ signature.asc Description: PGP signature
Re: Debian Reunion Hamburg 2021
hi, On Wed, Sep 01, 2021 at 03:18:21PM +, Holger Levsen wrote: > I'm glad to finally be able to send out this invitation for the "Debian > Reunion > Hamburg 2021" taking place at the venue of the 2018 & 2019 MiniDebConfs! > > The event will run from Monday, Sep 27 2021 until Friday Oct 1 2021, with > Sunday, Sep 26 2021 as arrival day. IOW, Debian people meet again in Hamburg. > The exact format is less defined and structured than previous years, probably > we will just be hacking from Monday to Wednesday, have talks on Thursday and > a nice day trip on Friday. > > Please read https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg > if you intend to attend, especially > https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg#Dates_and_format_of_the_event > https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg#Covid_things > https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg#Call_for_papers > https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg#Registration > (registration is mandatory for this event!) > > Probably having some video coverage would be very nice to have, though due to > this very late announcement I'm not sure we'll really have talks and the need > for video. The event is in 3.5 weeks and will take place, either as a very > small hack meeting, or somewhat bigger. We certainly want videoing if we have > talks - and if you could help with this that would be very great! > > Last and definitly not least, financial sponsors for the event would be great. > If you can support the "Debian Reunion Hamburg 2021", please contact me > directly! > > > Now, late, after weeks of wondering if and how to do this event, I'm finally > and very much looking forward to it, to meet some Debian folks at least & for > some shared Debian hacking. Definitly not the 2021 event I had in mind after > the 2019 one, but something I feel I can responsibly do & enjoy. > > So, hoping to see some of you soon & most of you later! ;-) Sad but true, and > at least something for some people. We should all do more *local* events. And > more *online* events too, eg I think this is a great idea too: > https://wiki.debian.org/DebianEvents/internet/2021/MiniDebConfOnlineBookworm > > See you! there have been very few registrations so far, so I'm in contact with the venue discussing what to do. If you are still pondering whether to come or not, please register yourself, now!, even as 'maybe attending' so that we can better evaluate the situation. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The corona crisis is peanuts compared to the global climate disaster. signature.asc Description: PGP signature
Re: Debian Reunion Hamburg 2021
On Wed, Sep 01, 2021 at 01:56:08PM +0200, Dominik George wrote: > Great to hear that someone will take place in Hamburg again! :) > One question, is the collision with MiniDebCamp Regensburg > intended/accidental/duly noted, iirc both dates were choosen independently and based on venue availability. definitly not intended. > and will there be any exchange? I dont understand the question, can you explain? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The entire society has no clue what the word freedom means in the context of relating to the world around them. It has degenerated into "my ego first". It is why the entire planet is dying right now. signature.asc Description: PGP signature
Re: Automated backports based on Janitor work?
On Fri, Aug 27, 2021 at 03:04:34PM +0200, Lucas Nussbaum wrote:
> > uploading to -backports also implies the promise to keep maintaining that
> > backport until the next release is out... I'm not sure that part of the
> > upload should be automated nor forgotten ;)
> Oh I wasn't thinking about uploading to the official backports suite.
> In the same spirit as the fresh-{releases,snapshots} suites provided by
> janitor, I was thinking about an automatically-generated backports
> suite.
oh, ic, this makes sense to me too, thanks for clarifying!
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Change is coming whether you like it or not.
signature.asc
Description: PGP signature
Re: Automated backports based on Janitor work?
On Thu, Aug 26, 2021 at 11:39:06AM +0200, Lucas Nussbaum wrote: > There's probably a large number of packages that just require a > rebuild (+ test with autopkgtest) to be backported. uploading to -backports also implies the promise to keep maintaining that backport until the next release is out... I'm not sure that part of the upload should be automated nor forgotten ;) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make racists afraid again. signature.asc Description: PGP signature
Re: merged /usr
On Tue, Aug 17, 2021 at 05:56:15PM +0100, Simon McVittie wrote: > tl;dr: I would prefer it if the usrmerge variation continues to be > exercised for the testing suite for the foreseeable future. ack, thanks (for the long version especially :) & agreed. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Just 100 companies are responsible for 71% of global emissions. 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
MBF: please drop transitional dummy package foo (if they were part of two releases or more)
Hi, again, I'm planning an small mass bug filing against obsolete transitional packages which are at least marked "dummy transitional" since the buster release, IOW, they have been transitional for both the buster and bullseye release and thus can definitly go now. There are just 137 bugs to be filed. ;) I have done this for the previous two releases as well, from which there are still 277 open bugs as of now. This is an example bug: (so it's a bit dated and that package was even part of three releases, though it's gone now...) On Sat, Oct 14, 2017 at 02:31:45PM +0200, Holger Levsen wrote: > Package: ttf-liberation > Version: 1.07.4-1 > Severity: normal > user: qa.debian@packages.debian.org > usertags: transitional > tags: pending > > Please drop transitional package ttf-liberation for Buster, > as it has been released with wheezy, jessie and stretch already. (This is #878536.) Attached is a list of affected maintainers, the full job output including the binary packages names is at https://jenkins.debian.net/job/obsolete-transitional/1393/console I'll start filing those bugs after DebConf21 and I'd be very happy if you'd fix your package until then! :) -- cheers, Holger Aaron M. Ucko dictionary-el Adrien Grellier calligra (U) Agustin Martin Domingo hunspell-lv (U) myspell-lv (U) myspell-pt-br myspell.pt rus-ispell (U) Aigars Mahinovs hunspell-lv myspell-lv Alberto Garcia webkit2gtk (U) Andreas Boll mesa (U) Andreas Cord-Landwehr kdevelop (U) Andreas Tille acedb (U) debian-science (U) Andrej Shadura intellij-annotations (U) Android Tools Maintainers android-platform-system-core Anthony Fok etcd (U) golang-github-coreos-semver (U) Anton Gladky openshot-qt (U) APT Development Team apt Ari Pollak docker (U) Arno Töll apache2 (U) Aurélien COUDERC kolourpaint (U) Barak A. Pearlmutter haskell-mode (U) Bastian Germann gambas3 (U) Chirayu Desai android-platform-system-core (U) Chris Halls libreoffice-dictionaries (U) Christoph Berg pgqd (U) Christoph Biedl gnupg2 (U) Craig Small ncurses Damien Raude-Morvan plexus-classworlds (U) plexus-containers (U) Damyan Ivanov bgoffice debianbuttons (U) Daniel Baumann open-infrastructure-service-tools open-infrastructure-storage-tools Daniel Kahn Gillmor gnupg2 (U) dann frazier edk2 (U) David Kalnischkies apt (U) Debian Accessibility Team orca Debian Apache Maintainers apache2 Debian Common Lisp Team ffcall Debian Emacsen team dash-el go-mode.el s-el Debian Emacsen Team haskell-mode Debian Fonts Task Force fonts-hack fonts-roboto Debian Gambas Team gambas3 Debian GNOME Maintainers gnome-themes-extra gnome-tweaks gnome-user-docs orca (U) Debian GnuPG Maintainers gnupg2 Debian Go Packaging Team golang-github-coreos-semver golang-github-xi2-xz Debian Go Packaging Team etcd golang-github-gorilla-rpc Debian Java Maintainers exec-maven-plugin intellij-annotations plexus-classworlds plexus-containers servlet-api wagon Debian LibreOffice Maintainers libreoffice-dictionaries Debian Med Packaging Team acedb pydicom Debian Mozilla Extension Maintainers tree-style-tab Debian Mozilla Extension Maintainers ublock-origin Debian Multimedia Maintainers openshot-qt Debian OpenLDAP Maintainers openldap Debian PostgreSQL Maintainers pgqd Debian Privacy Tools Maintainers mat2 Debian Python Team buildbot pyotherside Debian QEMU Team edk2 Debian Qt Extras Team gcompris-qt Debian Qt/KDE Maintainers breeze-gtk calligra kdevelop Debian Science Team apertium-spa-cat Debian Science Team apertium-spa-ita debian-science Debian WebKit Maintainers webkit2gtk Debian Window Maker Team fookb Debian X Strike Force mesa xorgproto Debian Xfce Maintainers garcon Debian+Ubuntu MATE Packaging Team atril caja eom libmatekbd mate-desktop mate-menus mate-panel Debian/Kubuntu Qt/KDE Maintainers kmail kolourpaint Dmitry Shachnev gnome-themes-extra (U) Dmitry Smirnov golang-github-xi2-xz (U) Doug Torrance fookb (U) Dr. Tobias Quathamer openshot-qt (U) Eduard Bloch icewm Emilio Pozuelo Monfort webkit2gtk (U) Emmanuel Bourg servlet-api (U) wagon (U) Eric Dorland gnupg2 (U) Eshat Cakar kmail (U) Fabian Greffrath fonts-hack (U) Felix Zielcke pyotherside (U) Georg Faerber mat2 (U) George Kiagiadakis kdevelop (U) kmail (U) Gustavo Noronha Silva webkit2gtk (U) Hajime Mizuno dash-el (U) s-el (U) silversearcher-ag-el Henti Smith golang-github-gorilla-rpc (U) HIGUCHI Daisuke (VDR dai) uim Hilko Bengen go-mode.el (U) Hypra Team compiz Ian Haywood gam
Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")
On Mon, Aug 16, 2021 at 07:18:03PM +0200, Wouter Verhelst wrote: > Well, then we disagree (and that's fine). Personally, I'd rather have my > CI system try to find as many problems as possible, so I can fix them > *before* I upload, rather than after. I didn't try to build a CI system here, but rather a publishing system, which only publishes reproducible releases. For development, a CI system which finds problems, is nice. But I also want a system which can do releases and which only does them when they are reproducible. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ It's climate crime, not climate change. signature.asc Description: PGP signature
Re: merged /usr
On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote: > The failure mode we have sometimes seen is packages that were built in > a merged-/usr chroot not working on a non-merged-/usr system, although > that's detected by the reproducible-builds infrastructure and is already > considered to be a bug since buster (AIUI it's considered a non-RC bug > in buster and bullseye, as a result of things like #914897 mitigating it). FWIW i'm preparing a commit right now which will change the reproducible-builds infrastructure in so far as: - bullseye will not be tested anymore for differences of building with or without the usrmerge package installed (just like stretch and buster were and are not). - bookworn and unstable will be tested for differences of building with or without the usrmerge package installed. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ :wq signature.asc Description: PGP signature
Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")
On Mon, Aug 16, 2021 at 03:59:50PM +0200, Wouter Verhelst wrote: > > because here, our focus would be to publish things :) > Sure. But also to find problems early rather than late, no? no. -- 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: Debian package manager privilege escalation attack
On Thu, Aug 12, 2021 at 01:19:23PM +, Holger Levsen wrote: > if those users are not trustworthy than the bug is giving them sudo, > nothing else. (Debian does not give sudo to users by default. The default > is to set a root password.) > > if you give someone a gun for hunting (animals) and that person uses > the gun for hunting people, the problem is not in the configuration of > that gun, but that someone. after some thinking I'd like to s#hunting (animals)#self defense#. signature.asc Description: PGP signature
Re: Debian package manager privilege escalation attack
On Thu, Aug 12, 2021 at 01:12:37AM -0500, Brian Thompson wrote: > Would you agree that there is an issue with sudo access that is enabled > by default on most Debian and Debian-based distributions? The bug may > not be in apt, but it definitely lives somewhere. if those users are not trustworthy than the bug is giving them sudo, nothing else. (Debian does not give sudo to users by default. The default is to set a root password.) if you give someone a gun for hunting (animals) and that person uses the gun for hunting people, the problem is not in the configuration of that gun, but that someone. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Change is coming whether you like it or not. signature.asc Description: PGP signature
Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")
Hi Wouter, sorry for the late reply but I think it's still relevant... (just thus rather leaving almost full quote as context.) On Thu, Jul 08, 2021 at 11:25:26AM +0200, Wouter Verhelst wrote: > On Mon, Jul 05, 2021 at 12:31:10PM +0000, Holger Levsen wrote: > > On Mon, Jul 05, 2021 at 02:09:36PM +0200, Mathieu Parent (Debian) wrote: > > > > Do you have plans to support publishing builds only if they've produced > > > > bit by bit identical results on several builders? IOW, do you plan to > > > > support reproducible builds? :) > > > There is no specific support for reproducible builds. Currently, [...] > > > But reproducibility can be tested in GItlab jobs, before the upload. > > that's nice, but rather theoretic (however common it is today) in practice > > :) > > It would be really interesting / a game changer, to have a publishing option > > which would only allow publishing of builds proven in practice to be > > identical. > It's actually fairly easy to do that: > > - Create two runners, with different tags (e.g., one tagged "build1", > and one tagged "build2"). One can be a docker runner, the other a > shell runner, just to keep things interesting. > - Create two jobs that build the same source in ways that might trigger > reproducability issues (I'm sure you're better at this than me). Make > sure that they don't store their artifacts in the same location (e.g., > one job runs "dcmd mv ../*.changes products/build1/", and the other > one does "dcmd mv ../*.changes products/build2/"). > - Have a third job that depends on both the above two jobs, and that > runs diffoscope over the artifacts of both jobs. If and only if the > diffoscope doesn't reveal any issues, run dput to upload the packages. > > I think the salsa-CI team can easily add support for this to their > generic pipeline... that would be really nice, thank you for explaining this idea so well! just one thing: here we do *not* want to trigger reproducibility issues, rather the opposite: if we manage to do two builds resulting in exactlty the same .deb(s), we are happy. because here, our focus would be to publish things :) elsewhere we do have a well known setup to find problems... (=tests.r-b.o/debian) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ When this virus is over, I still want some of y'all to stay away from me. signature.asc Description: PGP signature
Re: missing unblock requests (was Re: bullseye release planned on 2021-08-14 and the last weeks up to the release)
On Sat, Jul 24, 2021 at 09:36:15PM +0200, Ole Streicher wrote: > I already had the situation that I accidently uploaded to sid instead of > experimental, and I then created an RC bug to block migration. Frequent > reminders about the non-migration wouldn't have helped me to solve the > problem. you mean like this: 1 s Jul 23 Paul Gevers (3.3K) bullseye release planned on 2021-08-14 and the last weeks up to the release 2 s Jul 17 Paul Gevers (1.4K) Debian bullseye fully frozen 7 S Jun 14 Cyril Brulebois (4.7K) Debian Installer Bullseye RC 2 release 8 s Jun 13 Paul Gevers (1.3K) Full Freeze starts on 2021-07-17 12 s May 02 Paul Gevers (4.4K) bits from the Release Team: bullseye status update 13 S Apr 23 Cyril Brulebois (6.3K) Debian Installer Bullseye RC 1 release 26 s Mar 20 Paul Gevers (2.2K) Bits from the Release Team: frozen hard to get hot ? you might want to subscribe to https://lists.debian.org/debian-devel-announce/ and read those mails... and if in doubt, just go to https://release.debian.org/ - this page is really nicely structured and updated frequently, and has information directly from the source! :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ We live in a world where teenagers get more and more desperate trying to convince adults to behave like grown ups. signature.asc Description: PGP signature
