Re: finally end single-person maintainership

[Wouter Verhelst]

On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote:
> Hi Wouter,
> 
> Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
> > [Feel free to quote any part of this email which I wrote outside of this
> > mailinglist]
> 
> OK, moving the discussion to debian-devel where it should belong.
> 
> > Debian packages need to be well maintained. In some cases, having
> > multiple maintainers on a package improves the resulting quality of
> > packages. But in some other cases, it does not; one example for this
> > second case is my package "logtool", which I'm going to upload to fix
> > #1066251 soon and for which by the simple act of doing that I will
> > double the amount of uploads it's seen in the past five years (and the
> > number of uploads in the past 10 can still be counted on the fingers of
> > a single hand).
> > 
> > This is not because it's not well maintained; it's because the package
> > just *does not require* a lot of work to be kept up to date: upstream
> > has not been active for over 20 years, but it still performs the job it
> > was designed to do, as it was designed to, and I see no need to have it
> > removed from the archive.
> 
> What is your opinion about pushing logtool to Salsa?

I did that as part of my latest upload :)

https://salsa.debian.org/wouter/logtool

(I realize now that I forgot to add VCS headers... ah well, next time
I'm sure)

[...]
> > If there are stupid barriers to helping people out by doing NMUs or
> > taking over packages, then by all means let's break down those barriers.
> 
> I was sometimes confronted with those barriers.

And that's not good, and we should work on those.

I just don't think that mandating team maintenance drops those barriers.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: /usr-move: Do we support upgrades without apt?

[Wouter Verhelst]

On Wed, Jan 03, 2024 at 04:43:45PM +0100, Helmut Grohne wrote:
> On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote:
> > We can restore lost files in a postinst. For this to work, we must
> > duplicate (e.g. hard link) affected files in the data.tar.
> > Example: #1057220 (systemd-sysv upgrade file loss)
> > Note that this approach is not policy compliant for essential packages
> > as they must work when unpacked and this is relevant for gzip being
> > diverted by zutils for instance.
> 
> We'll be doing this anyway. It is implemented in systemd-sysv.postinst
> and proposed in the gzip patch above. Yes, we are technically violating
> policy for gzip then, but I don't really see a technical way not to
> violate policy. I expect that we do not consider fixing this (unfixable)
> policy violation release-critical.

I agree that this is the best way forward.

Presumably the reason for this requirement in policy is that without it,
debootstrap cannot function. That is, debootstrap first unpacks all
Essential packages, without running any preinst or postinst scripts, and
*then* runs all the maintainer scripts. If an Essential package would
not function without its maintainer scripts being run, then debootstrap
could fail halfway through.

Running debootstrap cannot trigger the issue, because it does not
involve upgrades; and I do not believe that apt will special-case
Essential packages other than that it refuses to remove them unless
the user enters The Phrase[1], so we can consider that if it's something
that would work for a regular package, it will work for an Essential
one, too.

Perhaps if the above assumptions are correct, policy should be updated
such that the requirement is relaxed to only apply for initial
installation?

[1] At least, I think it logically *should* not do so, but then I'm not
an apt developer and thus I may not know all the corner cases.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Questionable Package Present in Debian: fortune-mod

[Wouter Verhelst]

On Mon, Aug 21, 2023 at 06:55:03PM +, Andrew M.A. Cater wrote:
[...]
> More cogently: where are we going to get our fortunes from - where's the 
> canonical source now that FreeBSD has gone?
> 
> Who is going to take responsibility for checking quotes and translations
> in all languages and dealing with requests for additions and deletions?

I think this is for the maintainer to decide, not the project. We don't
require any particular type of authorship for any other package, and
there have been multiple instances of packages where the Debian
maintainer has taken over upstream maintenance (including, occasionally,
the NBD software, where the "Debian maintainer" turned out to be me). I
don't see why the contents of the fortunes package should be any
different?

> [Each language should have the full quota of quotes where feasible - compare
> the Debian installer or the wiki - no language should be inferior as far
> as this is possible]
> 
> If it is the package maintainer, is this an appropriate burden for a package
> on which others may judge the project as a whole, rightly or wrongly?

As long as the maintainer replies to reasonable bug reports, and as long
as packages that contain things which "might offend" (etc) are clearly
marked as such? Yes, I think so.

[...]
> if you really want the Project to continue with this package / these 
> packages, may I suggest a straightforward series of small changes?
> 
> * Make the fortunes package a reader for fortune-format files.
> * Add a doc package detailing how to create the valid format of files that
> fortune as a program will read. How to form a fortune from arbitrary text.
> * Debian as a whole stops shipping fortune formatted files and lets users
> compose or download/translate their own fortune databases.
> 
> There's no censorship of files/thought/speech

I don't think this is a good way forward.

As someone who used to run fortune in his shell initialiation files for
a very long time, the value of having fortune installed is to learn new
things, or gain new insights, based on the quotes of famous people. You
lose that advantage if you have to maintain your own fortune database.

If we stop shipping fortune files, we might as well stop shipping
the fortune program altogether.

(as an aside, the file format is ridiculously easy -- create a plain
text file with quotes separated by percent ("%") characters on a single
line. You're done)

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Questionable Package Present in Debian: fortune-mod

[Wouter Verhelst]

On Mon, Aug 21, 2023 at 07:09:00PM +, Holger Levsen wrote:
> 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.

While I don't think this is entirely an unreasonable interpretation of
the facts and of our history, I also don't know that it is generally
accepted, and so I don't think this position is generally agreed upon
within the project.

> and if there is disagreement about this, we should extend the CoC.

That, for sure, is a good idea -- at the very least, we should take it
to a vote.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Questionable Package Present in Debian: fortune-mod

[Wouter Verhelst]

On Sat, Aug 19, 2023 at 02:28:22PM -0400, Roberto C. Sánchez wrote:
> On Sat, Aug 19, 2023 at 07:11:11PM +0200, Dominik George wrote:
> > >The mission you have chosen for yourself, then, is to identify all those
> > >things in the Debian distribution that are not constitutive of an
> > >operating system.
> > 
> > That is a major part of the work of a Debian Developer, and the ftp-master 
> > team.
> > 
> But we have established criteria,

We have not.

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.

We may decide that certain language is inappropriate in our packages,
and if so, you can start censoring packages in the archive under the
code of conduct. I make no statement as to whether I believe that is the
right course of action at this point; bring it to a GR and you will see.

Absent that action, however, the code of conduct does not apply to
relevant content of packages in the archive.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: MBF: packages shipping init scripts without corresponding systemd units

[Wouter Verhelst]

On Sun, Jun 25, 2023 at 10:31:35PM +0100, Luca Boccassi wrote:
> On Sun, 25 Jun 2023 at 22:29, Luca Boccassi  wrote:
> >
> > Hi,
> >
> > According to Lintian there are 314 packages shipping init scripts
> > without a corresponding systemd unit:
> >
> > https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script
> >
> > They currently work because there is still a transitional unit
> > generator that creates a unit on-the-fly on boot. This was always
> > intended as a temporary stop-gap, and is technically vastly inferior to
> > a native unit, as for example it cannot tell the difference between a
> > one-shot and a long-running service, and cannot enable any hardening or
> > sandboxing options.
> >
> > Now the generator is also on the way to be deprecated and removed. It's
> > been there for a decade, which is enough time to complete the
> > transition, and will likely be removed before Trixie ships.
> >
> > Therefore I filed a bug against all affected packages, provided a patch
> > for policy:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039102
> >
> > and a patch for Lintian to bump the severity from warning to error:
> >
> > https://salsa.debian.org/lintian/lintian/-/merge_requests/407
> >
> > It's possible that there will be a good chunk of false positives, as
> > often new units added don't have a name that matches exactly the old
> > init script name, in which case it's fine to add an override and close
> > the bug.
> 
> It would probably make things easier if I typed the destination
> address correctly.

It's generally expected that you discuss MBFs on this list *before*
actually performing the MBF, so that other options can be discussed, but
meh, whatever.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Wouter Verhelst]

On Wed, May 31, 2023 at 11:24:15PM +0200, Diederik de Haas wrote:
> On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote:
[...]
> > 20+ year old machines are typically more power hungry, more expensive,
> > less performant, and less reliable than an up-to-date raspberry pi. If
> > you want to support people who can't afford shiny new hardware, I think
> > pointing them to raspberry pi-class hardware is a better idea than
[...]
> In the responses here, I've mostly seen the *assumption* that those old
> devices must be power hungry. While I'm quite sure modern hardware is
> more power *efficient*, that doesn't mean old hardware is thus power
> hungry. 
> But most of all, I'm flabbergasted/annoyed that someone who made explicit and 
> clear what they need, namely keeping support for i386, a bunch of people feel 
> the need to respond like "Well, actually, you need this (other thing)".
> I find that extremely condescending.

That's actually a bit of a misrepresentation of what I said.

I do believe there are still people using i386 hardware. I know for a
fact that there are still people using m68k hardware, too.

My argument is that "it is still used" is an argument that, due to the
very fact that retrocomputing exists, will never be a wrong statement.
To name an extreme example, there exist a handful of apple I devices
that are in working order today, but nobody would reasonably suggest
that it is a platform that still matters today.

Since it is always possible to come up with an example of someone still
using some old piece of hardware, I therefore think that it is not a
very compelling argument, in and of itself.

I also specifically said that older systems *typically* require more
power for less performance (etc). Of course there are exceptions, but
those are much more rare than the more common case of 20 year old
desktop-class hardware.

As an ex contributor to the m68k port who was active on the port when
our buildd hosts were still running on actual m68k hardware, I can tell
you that 20 year old hardware is not reliable *at all*. I have forgotten
how many times we've had to scrounge for older hard drives to replace
ones that died, wiggle RAM modules around, or do various types of
insane hardware maintenance that on modern hardware just isn't
necessary (I .. remember the one time where the one host
had to be moved because it was in a hot attic and the cooling system
had Opinions on having been run 24/7 for over a decade). As such, if
your choice is between a 20 year old piece of hardware or a brand new
one that has similar performance, your better choice is almost always
going to be the latter.

Note again how I said "almost always" here. Exceptions exist.

In my opinion, the question we should be asking ourselves is therefore
not "can we still find valid use cases for the port", because the answer
to that is always "yes" and therefore not interesting, but rather, "how
much effort will it cost us to keep the old port running".

Note that the answer to that very valid question will be influenced by
"who is interested in keeping the port available". If there is a strong
feeling that the i386 port needs to go, and there is a bunch of people
with the skills required and the interest in changing that, then there
is a fairly straightforward thing they can do to avoid the port being
binned. It requires you do lot of work, but "complain on -devel" is not
part of the job.

I was part of the team that kept doing the necessary work for years, and
we saved the port from being removed from Debian several times. If you
want to do the same for i386, the path is clear...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Wouter Verhelst]

On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> While it may be a no-brainer for a person with a $/€ 1000 a month residual 
> income to just buy new hardware whenever they feel like it, that is not the 
> case for everyone.
[...]
> It's absolutely true that modern machines are more energy efficient. What is 
> also true is that the production of new devices has a big environmental 
> impact. 

20+ year old machines are typically more power hungry, more expensive,
less performant, and less reliable than an up-to-date raspberry pi. If
you want to support people who can't afford shiny new hardware, I think
pointing them to raspberry pi-class hardware is a better idea than
trying to recycle old hardware. As such, I don't think "but old hardware
is still used" is a very good argument for keeping i386 around.

If they can afford 10 year old hardware, the situation is different; but
no 10 year old hardware that is worth recycling does not support x86-64.

I'm not saying we shouldn't support old hardware at all -- I fought for
a long time to keep m68k hardware a supported architecture in Debian --
but this is not the best argument for it, IMO.

Thanks,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Yearless copyrights: what do people think?

[Wouter Verhelst]

On Wed, Feb 22, 2023 at 08:20:27AM -0800, Russ Allbery wrote:
> Daniel Baumann  writes:
> > On 2/22/23 14:26, Peter Pentchev wrote:
> 
> >> Wait, I may have been unclear. I did not mean that I want to omit the
> >> upstream copyright years *when they are there*.
> 
> > I know you didn't mean that, nevertheless, it's imho good idea.
> 
> Unfortunately, it's often against the upstream license.
> 
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
> 1. Redistributions of source code must retain the above copyright
>notice, this list of conditions and the following disclaimer.
> 
> and:
> 
> The above copyright notice and this permission notice shall be
> included in all copies or substantial portions of the Software.

It says you need to do that, yes. It does not say *where* that copyrigh
statement must be.

debian/copyright is wholly a Debian-specific invention. We can often do
whatever we want there and still comply with the copyright license.

It's useful for our users that debian/copyright contains an accurate
copy of the license statement, but I don't see how it would be relevant
for an upstream license.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Please, minimize your build chroots

[Wouter Verhelst]

On Sat, Jan 28, 2023 at 01:30:42PM +0100, Timo Röhling wrote:
> Hi Andreas,
> 
> * Andreas Henriksson  [2023-01-28 12:50]:
> > Policy is not a religion. Policy has many bugs. Policy is very outdated.
> > [...]
> > Here's an example you could follow:
> > https://lists.debian.org/debian-policy/2022/12/msg00023.html
> Your argument cuts both ways. Right now, Policy says that
> the bugs are RC, and if you believe that should be different, why
> don't you propose such a change and seek consensus yourself?

What is "RC" is defined by the release team, not by policy.

The release team has clarified that these bugs are not RC.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Multi-host networking software, autopkgtests

[Wouter Verhelst]

Hi Ian,

On Fri, Jan 06, 2023 at 04:59:58PM +, Ian Jackson wrote:
> Paul Gevers writes ("Re: Multi-host networking software, autopkgtests"):
> > I guess this is best discussed in https://bugs.debian.org/908274 (added 
> > in the To)? Maybe with Wouter and other interested parties?
> 
> Hmmm.  Well, a way of doing this "officially" in autopkgtest would be
> nice.  But:
> 
> Think such an "official" thing ought to allow the specification of
> different dependencies for the different hosts in the test.  And I
> don't much like the mini-DSL suggestion.  Maybe it would be better to
> offer the test script an adt virt server interface to control the
> "other" hosts.
> 
> This all seems very complex.  I definitely want to have something
> working before something like that could exist.  Also, I think it
> would be a good idea to do something ad-hoc, ideally in a number of
> packages, to gain experience so we know what shape the "official"
> thing ought to be.
> 
> I think therefore that I need to pursue some kind of within-testbed
> nesting, as an interim approach at the very least.  I was hoping that
> someone else had solved (part of) this problem already...

Unfortunately not.

We also had a discussion during the "autopkgtest office hours" session
during debconf21[1], where an alternate method (that would be slightly
easier to implement) was proposed: to have an autopkgtest helper command
that allows you to easily create and run a Debian VM for the host
architecture, and run stuff on it. This might be a bit easier to
implement than the dsl in the proposal.

[1] 
https://debconf-video-team.pages.debian.net/videoplayer/#/event/2021/debconf21?video=debconf21-82-autopkgtest-office-hours.webm=2028

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[Wouter Verhelst]

Hi Ian,

On Thu, Dec 15, 2022 at 10:41:13AM +, Ian Jackson wrote:
> I would like to add the following entry to the table of build
> profiles in BuildProfileSpec:
> 
>  Profile anme: `cargo-upstream`
>  Can cause changes to built binaries, including functional chnges. (Y)
>  Should not cause changes to set of build debs. (N)
>  Description:
>Obtain Rust dependencies from crates.io, not from Debian; use a
>`Cargo.lock` from the source package if there is one.  Will usually
>cause cargo to make network accesses.  Ideally, behaviour of the
>resulting programs will be the same, but this is not guaranteed.
[...]

I have just one question: why make this rust-specific? I think a similar
thing might be useful for golang packages (who also don't support shared
libraries), or, heck, even Perl (if I'm willing to test that the package
works while I have the not-yet-packaged dependencies in my ~/perl5/lib)

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Firmware GR result - what happens next?

[Wouter Verhelst]

On Thu, Oct 13, 2022 at 04:13:57PM +0100, Steve McIntyre wrote:
> On Thu, Oct 13, 2022 at 05:08:57PM +0200, Julien Cristau wrote:
> >On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
> >> Maybe and idea would to do something like isa-support does for e.g 
> >> sseX-support
> >> on CPUs that does not have that feature: It fails on installation with an 
> >> debconf message, IIRC.
> >> So that would allow something like "new package" | 
> >> "you-need-to-enable-nonfree-firmware-reminder-package"
> >> 
> >Failing on installation is a terrible user experience, let's not, pretty
> >please.
> 
> It's not great, no. Do you have a better suggestion for making sure
> people update sources.list?

We can display a debconf error (which debconf tries really really hard
to show to the user) and then succeed?

Alternatively, the package could install an apt hook that nags the user
every time they run "apt update" or equivalent, and that turns silent if
the updated firmware packages are installed (because of the difference
between "purge" and "remove").

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Wouter Verhelst]

Hi Dylan,

Something in pipewire caused my laptop to lose all audio. Since I work
remotely and need to attend meetings over various video conferencing
tools, that was not an option for me, so I reverted back to pulseaudio
by removing everything from src:pipewire from my laptop and rebooting,
which seems to have "fixed" the issue.

Obviously however, this can't be the right long-term solution, but I
don't know exactly what went wrong.

When I opened an ALSA mixer tool, the mixer was set to 0, and moving it
up would work but then restarting the mixer tool would show it was at 0
again.

Opening pavucontrol would show a single device, called "dummy audio
device" (paraphrasing), with no way to select another device.

I'm not familiar enough yet with pipewire to know which tools to use to
debug what went wrong. Can you point me to the relevant docs? Once I
have a better idea of what went wrong, expect a bug report coming your
way ;-)

Thanks,

On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Aïssi wrote:
> Hi,
> 
> I have been asked several times regarding when Debian will switch its default
> sound server from PulseAudio to PipeWire without having an official answer.
> Thus, I suppose it's the right time to start a discussion about that.
> 
> As you know, PipeWire is already installed by default with Bullseye (at least
> with Wayland environments) for screen-sharing. PipeWire was not mature enough
> to use it as default sound server for Bullseye, but since it gained in
> stability, features and popularity. Several other major distributions
> (Fedora, Ubuntu is doing the switch with 22.10) have switched to PipeWire
> for audio [1-3].
> 
> We cannot talk about PipeWire without mentioning its session manager.
> Thus, this change should go along the switch of the default session manager,
> i.e. from the deprecated pipewire-media-session to WirePlumber.
> We still use pipewire-media-session as default session manager because it
> enables PipeWire *only* for screen-sharing and not for managing audio.
> Whereas WirePlumber always configures PipeWire for audio excepted by modifying
> conf files in a non-compatible packaging way. This issues was also hit on
> the Arch Linux side [4]. This WirePlumber behavior may be solved in the next
> major release 0.5 planned later this year.
> 
> BTW, I just uploaded latest PipeWire and WirePlumber in bullseyes-backports
> (still in the NEW queue) to allow more users to test them.
> 
> Best,
> Dylan
> 
> [1] https://fedoraproject.org/wiki/Changes/DefaultPipeWire
> [2] https://fedoraproject.org/wiki/Changes/WirePlumber
> [3] https://wiki.ubuntu.com/ImpishIndri/ReleaseNotes
> [4] 
> https://archlinux.org/news/undone-replacement-of-pipewire-media-session-with-wireplumber/
> 
> 

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Wouter Verhelst]

On Thu, Sep 29, 2022 at 02:26:03PM +0200, Emanuele Rocca wrote:
> [1] I already have alsa, jack, pulseaudio, pipewire packages
> installed... At least no oss anymore! :)

Since OSS is completely in-kernel, you actually do :-)

(and yes, it still works. I own some ancient non-free games, they only
support OSS for audio, and are statically linked so the aoss stuff
doesn't work...)

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Automatic trimming of changelogs in binary packages

[Wouter Verhelst]

On Wed, Sep 14, 2022 at 10:40:28AM +0300, Hakan Bayındır wrote:
> 
> 
> > On 14 Sep 2022, at 10:37, Wouter Verhelst  wrote:
> > 
> > On Sun, Sep 11, 2022 at 03:09:07PM +0300, Hakan Bayındır wrote:
> >> Yes, you’re right. However, my reservation is whether dpkg is more prone to
> >> breaking in disaster recovery scenarios. Reading a gzipped file is always
> >> simpler than querying a DB via more abstraction.
> > 
> > Honestly though, the way to track down a regression is to read
> > /var/log/dpkg.log, not changelogs.
> 
> Does /var/log/dpkg.log contain why my VPNs suddenly don’t connect or my
> daemon behaves differently after the last update? I thought they’re delivered
> through news and changelogs.

They are. And once you know which package is likely to be the culprit,
you can look at changelogs.

But in order to do that, you would have to look at which packages were
upgraded first. That's what dpkg.log helps you with.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Automatic trimming of changelogs in binary packages

[Wouter Verhelst]

On Sun, Sep 11, 2022 at 03:09:07PM +0300, Hakan Bayındır wrote:
> Yes, you’re right. However, my reservation is whether dpkg is more prone to
> breaking in disaster recovery scenarios. Reading a gzipped file is always
> simpler than querying a DB via more abstraction.

Honestly though, the way to track down a regression is to read
/var/log/dpkg.log, not changelogs.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Epoch for node-markdown-it

[Wouter Verhelst]

On Fri, Aug 19, 2022 at 04:37:46PM +0200, Jonas Smedegaard wrote:
> Quoting Yadd (2022-08-19 10:21:17)
> > some months ago, a bad upstream tag changed node-markdown-it version to 
> > 22.2.3 instead of 10.0.0. So I'd like to change node-markdown-it version 
> > into 1:13.0.1
> 
> Since upstream is already at 10, is it unlikely that they will reach 22
> in the foreseeable future?
> 
> What I am getting at is that introducing an epoch is a pain *forever*
> (all dependent packages must then *forever* remember to add "1:" prefix)
> wheread converting the accidental too-high major version into
> pseudo-epoch "22.really." will last only until upstream catches up.

"only"

Policy 5.6.12.1 states:

> Note that the purpose of epochs is to cope with situations where the
> upstream version numbering scheme changes and to allow us to leave
> behind serious mistakes.

Someone using 22.something rather than 12.something in a version number,
to me, sounds like someone making a "serious mistake".

So this is *exactly* what epochs are meant for!

The something+reallysomethingelse convention is evil and should never
have been invented in the first place. It's extremely confusing to
users, and an epoch is *hidden* from them.

If someone forgets an epoch in a package dependency, we have this
wonderful invention called "the Debian Bug Tracking System" that's
designed to deal with that, or someone can create a lintian test that
complains loudly if you create a dependency for a package version that
has not existed since oldstable.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: adduser default for sgid home directories

[Wouter Verhelst]

On Mon, Jul 25, 2022 at 07:06:59PM +0200, Marc Haber wrote:
> I don't like the idea of messing with old NEWS entries at all.

I'm trying to understand why you feel this way.

A NEWS.Debian entry is not aimed towards developers; it is meant as
documentation shown to the user when upgrading. Having apt-listchanges
tell you "We changed X to Y" immediately followed by "Oh actually, we
changed Y to Z" (or "Y back to X", as the case may be) is quite
confusing in that context, and could therefore be counterproductive.

I feel that NEWS.Debian should always be edited in such a way that
expected upgrade paths show our users the information they would need to
keep things running, and not (much) more than that. This means that if
the information in a NEWS.Debian file has become outdated, it should be
updated so that users upgrading from the package version they are
running get the most relevant information for their situation.

If people need to investigate how a package changed over time, then
there are other tools (debian/changelog, snapshot.debian.org, and a git
log if one is available) to achieve this. I don't think NEWS.Debian is
the right place to keep that type of information.

Am I missing something?

> In this case, an exception might be warranted, but we need to have the
> long explanation somewhere in the package for the next round of this
> issue that is expected in the 2030ies.

It absolutely makes sense to document decisions for future people
looking at the problem, but I'm not convinced that a long explanation
for historic decisions belongs in the NEWS.Debian file. The changelog
would seem to be a more appropriate location, or perhaps a
debian/README.why-we-do-things-this-way file could be created. Of
course, a NEWS.Debian entry should still contain the bits of information
that are relevant for the user who's upgrading the package, possibly
duplicating information if necessary.

Thanks,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: adduser: disabling passwords, disabling logins

[Wouter Verhelst]

On Wed, Mar 09, 2022 at 09:00:22PM +0100, Marc Haber wrote:
> On Tue, 8 Mar 2022 18:40:11 +, Simon McVittie 
> >--disabled-login: the new account has an empty password but is "locked";
> >so password authentication will fail, but "unlocking" the account will
> >result in login being accepted with a blank password (subject to other
> >policies like ssh PermitEmptyPasswords and PAM nullok)
> 
> that way, --disabled-login doesnt sound desireable at all, it would
> violate the principle of least surprise at least for me. I'd have
> expected (and always believed) that a password of ! will also prevent
> ssh-key logins from happening.

I don't see how that follows from Simon's statement? AIUI, he's saying
that that is true *until" you unlock the account (which essentially
means dropping the "!" from the passwd file).

Am I misreading something here?

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: proposed MBF: packages still using source format 1.0

[Wouter Verhelst]

On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote:
> Wouter Verhelst 
>aspic
>logtool

Yeah, no. These will be reduced to "wishlist" and probably tagged
"wontfix".

The packages work just fine, the source format is still supported, I
have better things to do with my time?

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Next attempt to add Blends to Debian installer

[Wouter Verhelst]

On Tue, Jan 18, 2022 at 09:52:42AM +0100, Philip Hands wrote:
> I don't have anything like a design for how that should look in my head
> though -- I guess interested parties should get together and come up
> with a design _before_ we start trying to implement it :-)

This sounds like you need someone with UX design experience to look at
this first, before you can actually implement things properly.

Perhaps this is something that could be posted as a "job" on the open
source design website? I've used them in the past to great effect for
the review interface of SReview, my video review system (we did a talk
about that process at FOSDEM 2019; you can see the video at
https://archive.fosdem.org/2019/schedule/event/open_source_design_in_trenches/)

You'd need someone who's willing and able to implement the required
changes to give feedback to the designer, and you'd need to commit to a
bit of time in order to do this properly (in my experience there were a
few iterations of back-and-forth improvements that did take some time to
get fleshed out), but I think the end result is worth it...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Next attempt to add Blends to Debian installer

[Wouter Verhelst]

On Tue, Jan 11, 2022 at 12:51:45AM +, Seth Arnold wrote:
> On Mon, Jan 10, 2022 at 08:02:50PM +0100, Philip Hands wrote:
> > The only missing bit AFAIK is getting the step where tasksel gets
> > installed into the target system, and then run, to be able to grab the
> > version of tasksel to use from an alternative apt repository (which is
> > already being created as part of the salsa-CI pipeline I've got setup),
> 
> Is installing tasksel actually necessary? apt understands tasks, eg:
> apt install lamp-server^
> 
> https://shantanugoel.com/2010/10/23/apt-get-caret/
> https://askubuntu.com/questions/211912/
> 
> I believe this works even if tasksel isn't installed on the target system.

Yes, but that doesn't give a user a friendly way to select a task.

If you know the task then yes, that's plenty, but there's more at play here.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Adding new language/locale to system via a graphical interface

[Wouter Verhelst]

Hi,

On Mon, Jan 03, 2022 at 03:29:06PM +0530, Pirate Praveen wrote:
> 
> 
> On തി, ജനു 3 2022 at 12:09:10 രാവിലെ +0200 +0200, Peter Pentchev
>  wrote:
> > On Mon, Jan 03, 2022 at 02:59:26AM +0530, Pirate Praveen wrote:
> > >  Hi,
> > > 
> > >  I'm looking for a way to add a new locale/language to system from
> > > gnome
> > >  (think about gnome on mobile like Purism Librem 5 or Pine Phone). I
> > > can do
> > >  that from a terminal by running dpkg-reconfigure locales but want
> > > to provide
> > >  an easier option to users. Is there a way to force gtk interface of
> > > debconf
> > >  and launch it from graphical interface? In Ubuntu, there is
> > > separate add
> > >  language tool which can add new languages.
> > 
> > The debconf(7) manual page suggests that setting DEBIAN_FRONTEND=gnome
> > after installing the libgtk3-perl package ought to work, and it seems to
> > work for me:
> > 
> >   sudo env DEBIAN_FRONTEND=gnome dpkg-reconfigure locales
> > 
> > ...brings up a GTK+ interface.
> > 
> 
> Thanks! I need to run xhost + to be able to launch this. Is there another
> way to lauch this graphically without having to run xhost +. May be
> something using policykit?

If you drop the "env" in that command, then the XAUTHORITY environment
variable will be retained and you shouldn't need to muck about with X
authorization.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: How to contribute ?

[Wouter Verhelst]

Hi Maxime,

On Tue, Dec 21, 2021 at 07:47:47PM +0100, Maxime Lombard wrote:
>Hello,
> 
>I'm an user of Debian since 10 years ago and it's only now that i decide
>to help to packaging.
>I send this email about wine and wine-development package which are not
>updated since a very long time.
>The last wine stable version on Sid is the 5.0 and development version is
>6.0+repack. Currently, the wine source code is frozen and the new stable
>version 7.0 will release next month.
>--> I sent email to Michael Gilbert (without answer from him) and open a
>bug report recently to update package.
>Same thing with vkd3d package 1.2 which is still in "experimental" since a
>long time too.
>I think it's not in Unstable because the test fail with mesa-vulkan-driver
>>= 21 (see changelog)
>--> I open a bug report upstream about this failure (see
>https://bugs.winehq.org/show_bug.cgi?id=52248). Is it possible to build
>the package without to do test (set --disable-tests to configure) ?
>Nowadays, the last package of wine-development was uploaded ~6 months ago.
>More bugs report opened the last months have no answer from Maintainer
>(999753, 995580), same thing with vkd3d bug (994186, 993570)
>I packaged myself vkd3d 1.2-7  and wine-development 7.0~rc2 and all works
>correctly.
>I updated debian folder for wine to prepare the next Stable version.
>My question is, how to contribute and hope to have updated version of this
>package in Debian since I am a novice ?

https://www.debian.org/devel/join/ should help as a general introduction
on how to contribute.

Assuming you built your updated wine package by getting the existing
wine packages and updating them for the new upstream version (your mail
suggests that, but I'm not sure), you have a few options.

First, you can send a patch to the Debian BTS. The easiest way to
accomplish this is by way of the "debdiff" program in the "devscripts"
package; see its man page for details. Alternatively, you can publish
your build directory in a git repository somewhere, possibly on
salsa.debian.org, and let the wine developers (who gather on the
debian-w...@lists.debian.org mailinglist) know.

If you don't get any feedback from the wine maintainers, you should
probably contact the debian mentors mailinglist (link on the join page
above) to request more help.

Hope this helps,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Using release-monitoring.org [was: uscan roadmap]

[Wouter Verhelst]

On Sat, Dec 04, 2021 at 02:43:56AM +, Scott Kitterman wrote:
> I think that there's a security consideration associated with all these
> proposals for externalizing finding upstream updates.  Currently watch files
> and at least the redirectors I know of all run on Debian infrastructure or on
> the systems of the Debian person doing the update.

I don't see how? At least repology just tells you "there is a new
upstream release", it doesn't tell you where to get it. It's up to the
maintainer to know where to download a new release.

Obviously if upstream is compromised and a new "release" is produced
that contains malicious code then there is a problem, but that is a
problem that is neither exacerbated nor mitigated by using repology.

> If one of these services were ever compromised it would provide a
> vector for offering substitute upstream code (at least for the cases
> where upstream releases aren't both signed by upstream and verified in
> Debian).  I find that prospect concerning.

Validating that upstream releases are valid is part of the job of being
a maintainer in Debian. Having some helper service that tells you there
is a new release doesn't change that.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: partman, growlight, discoverable partitions, and fun

[Wouter Verhelst]

On Tue, Sep 28, 2021 at 12:22:18PM +0200, John Paul Adrian Glaubitz wrote:
> On 9/28/21 12:13, Wouter Verhelst wrote:
> > IOW, chill out, nobody's going to kill off partman unless there's
> > something that's *actually* better than partman.
> 
> Just some comments after reading after this [1] because I honestly find it
> unfair the way I am being cornered here.

Yes, and what I'm saying is, I don't think anyone is trying to corner
you here, Nick are just saying "hey here's some cool new tech, what do
people think". The consensus in my reading is that people like it enough
that we might want to see some proof of concept, and then, assuming it
doesn't lack functionality that we don't want to lose and gives us
something new that we do like (e.g., better usability, more features,
etc etc) then we can perhaps replace partman one or more releases down
the line as the default partitioner.

You have some very good arguments against growlight in its *current*
state. That's fine. Just stay on top of things, and perhaps help Nick
out with testing a few of the more exotic features that partman
currently supports? Either through emulators or by giving him access to
real hardware if you can provide it (and given your collection, I
suspect you can ;-) ).

partman is currently being maintained by the d-i team very much in a
drive-by patches manner, but it's not actually seeing development of new
features. If Nick is offering to take over that work by replacing the
parted bits in d-i by his pet project, *and* he's offering to make sure
that we don't lose functionality we actually care about, then I think
that's a good thing? It's just a matter of making sure Nick *knows*
about the important bits, and that they get implemented in whatever we
end up replacing partman with before we actually do so...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: partman, growlight, discoverable partitions, and fun

[Wouter Verhelst]

On Tue, Sep 28, 2021 at 06:19:28AM -0400, nick black wrote:
> Wouter Verhelst left as an exercise for the reader:
> > One thing that partman does is "support plug-ins", to allow for
> > configuring block devices before being able to partition them, where
> > needed. This can be useful for iSCSI, multipath, or (the one I care most
> > about) NBD. I wrote a "partman-nbd" a few years back to do just that:
> > https://salsa.debian.org/installer-team/partman-nbd
> 
> Thanks a lot for pointing this out, Wouter -- this is *exactly*
> the kind of feedback I was hoping for! I allow loopback devices
> to be set up, but not in any reboot-crossing manner, and I have
> no NBD nor iSCSI functionality.
> 
>  https://github.com/dankamongmen/growlight/issues/150

NBD is fairly easy to set up (well, it is for me, but then I'm biased).
For the server side, you install nbd-server, you create a (probably
sparse) large file somewhere, and then edit /etc/nbd-server/config to
point to that. For the client side, you install nbd-client and read "man
5 nbdtab" if you want to persist things, or you read "man 8 nbd-client"
if you just want to connect now and not care about reboot.

iSCSI works very differently and is way more complex, but I remember
from when I last played with it (which is a while ago, so the details
are hazy) that it's not possible to set up in a non-persistent manner
(i.e., all iSCSI connections survive reboot unless explicitly deleted,
although obviously partman-iscsi has to do some dark magic to ensure the
configuration is migrated from the d-i environment to the live system).

There's also ATA-over-Ethernet, Fibrechannel-over-ethernet, multipath,
and a whole slew of other things, if you want to configure this from
growlight.

That said though, I would personally recommend against doing that. From
where I'm standing, it seems to be out of scope for growlight? If you're
replacing partman in d-i, you'd still need to add *some* d-i
integration, and I'd imagine that integration is where this type of
device configuration would go. As far as running growlight outside of
d-i goes, there I'd think you'd just tell the user to configure the
device before starting growlight (or you'd give them the ability to
re-scan for new devices after they'd set up the device in a (different)
terminal), and then that'll be all? Otherwise you'll end up with a
neverending story of "oh here's another type of device that needs to be
added", and I don't think that's a great rabbit hole to go down.

I could be wrong though, haven't looked at growlight in much detail, and
in the end it's your call, not mine :-D

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: partman, growlight, discoverable partitions, and fun

[Wouter Verhelst]

On Mon, Sep 27, 2021 at 03:18:48PM +0200, John Paul Adrian Glaubitz wrote:
> 
> 
> > On Sep 27, 2021, at 2:25 PM, Luca Boccassi  wrote:
> > 
> > Even if that interpretation would work as an excuse to never do
> > anything, and I'm not really sure it does, this specification has been
> > published in 2014 [0] so even by Debian standard it's old stuff.
> 
> That’s not what I said so. You’re trying to dismiss my opinion as completely 
> invalid now by trying to frame it such that I am against progress. I am not.
> 
> > It's
> > older than Debian Jessie, which was EOL'd last year. If libparted can't
> > keep up with 7 years old stuff that in the meantime was implemented in
> > util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
> > and so on, then to me it sounds like a tool in maintenance mode:
> > perfectly fine and adequate for existing tools and programs, but not
> > quite the best choice for new tools developed from scratch.
> 
> Whether a tool that was developed new from scratch is automatically better is
> not a given. The burden of proof is on the person trying to introduce the new
> software, not on the people maintaining the current set of software.

I think you're reading too much into the question here. The whole
*point* of Nick asking whether people would be opposed to that is
precisely *because* he wants to provide proof that his solution is
better than parted.

You've shown some things that are missing, and his immediate answer is
"ah, right, I'll need to add that then, but would need some assistance
to test that properly".

What's the problem with that?

Nobody is proposing to replace partman tomorrow.

Nobody is proposing to replace partman without testing the replacement.

It's also perfectly possible to imagine a transition period where both
partitioners are supported. That's the whole point of making d-i
modular: you can replace one component with another, and it adds new
features that support more use cases without killing off the older ones
because you can always ask for the other module. In fact, if memory
serves well, partman is the *second* partitioner that was written for
d-i, the first one having been replaced after just such a transition.

IOW, chill out, nobody's going to kill off partman unless there's
something that's *actually* better than partman.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: partman, growlight, discoverable partitions, and fun

[Wouter Verhelst]

Hi Nick,

On Mon, Sep 27, 2021 at 06:25:03PM -0400, nick black wrote:
> Marc Haber left as an exercise for the reader:
> > But maybe an alternative? I find the partitioning step one of the most
> > error-prone and hard-to-use parts of non-trivial Debian installations.
> 
> so overall, i've got to say the feedback i heard here was a lot
> more positive than i was expecting, though there was a bit less
> than i had hoped for. but perhaps something that can be touched
> would see more interest?
> 
> given that no one seemed to reject the idea out of hand, i'm
> going to go ahead and rebase my work from 2012 (or more likely
> look at it once and redo it) in a Salsa fork of d-i, and make
> some installation media available. forgive me for likely only
> having x86 available at first. i'll try to have this done within
> a week or so, and put it up on my server. people can then give
> it a whirl.

I hadn't replied to it *yet*, but had fully intended to do so (just
didn't get around to that yet).

One thing that partman does is "support plug-ins", to allow for
configuring block devices before being able to partition them, where
needed. This can be useful for iSCSI, multipath, or (the one I care most
about) NBD. I wrote a "partman-nbd" a few years back to do just that:

https://salsa.debian.org/installer-team/partman-nbd

This adds a few options to the partitioner menu to allow you to
add or remove an NBD device, and then if used makes sure the resulting
system is configured properly so that the NBD device(s) configured in
the installer will work after the system has been booted.

It would be nice if whatever component you write to replace partman has
support for things along these lines too. I don't mind having to rewrite
partman-nbd if that ends up being necessary (it's trivial enough), but
others might have different ideas about, say, partman-iscsi (just using
that as an example though, no idea about the details there).

Thanks,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Errors from TCP connections (was: How to build circular dependant packages in debian)

[Wouter Verhelst]

On Mon, Sep 20, 2021 at 11:45:06AM +0200, Bastian Blank wrote:
> On Mon, Sep 20, 2021 at 02:11:06AM +, Paul Wise wrote:
> > Normally one would get "Connection refused" when connecting to a port
> > that isn't open,
> 
> "Connection refused" is generated by TCP reset packets.

That, or ICMP type 1 code 3 packets ("destination port unreachable). See
below.

> >  but at this site one gets "No route to host", as if
> > there is no network path to reach the host,
> 
> "No route to host" is generated by an ICMP error.

Specifically, by ICMP type 1 code 1 ("destination host unreachable"). It
has become fashionable to use that code to reject connection attempts,
but personally I find that to be very confusing if it's used for a
single port rather than a whole host or network.

It's possible to use the correct ICMP code in firewalls, and then
connection error messages become far less confusing:

root@pc181009:~# telnet -4 localhost 3000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
root@pc181009:~# iptables -A INPUT -p tcp --dport 3000 -j REJECT --reject-with 
icmp-port-unreachable
root@pc181009:~# telnet -4 localhost 3000
Trying 127.0.0.1...
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
root@pc181009:~# iptables -D INPUT -p tcp --dport 3000 -j REJECT --reject-with 
icmp-port-unreachable
root@pc181009:~# iptables -A INPUT -p tcp --dport 3000 -j REJECT --reject-with 
icmp-host-unreachable
root@pc181009:~# telnet -4 localhost 3000
Trying 127.0.0.1...
Trying 127.0.0.1...
telnet: Unable to connect to remote host: No route to host

but you do you of course ;-)

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr vs. symlink farms

[Wouter Verhelst]

On Wed, Aug 25, 2021 at 09:57:09AM -0700, Russ Allbery wrote:
> Wouter Verhelst  writes:
> > On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote:
> 
> >> If we tried to document every random bit of buggy packaging behavior
> >> anyone thought of in Policy, Policy would become unwieldy, so I want to
> >> verify here that someone really thought having one package containing a
> >> file in /bin and another package containing the same file in /usr/bin
> >> was was a reasonable thing to do (as opposed to accidental).  Are there
> >> packages in the archive like this?  Or could you point me at the
> >> message in the thread that said this was non-buggy?  I think I missed
> >> it.
> 
> > The problem here is also that if there are two packages like that, on an
> > usrmerge system, we would not know this is happening.
> 
> I agree, of course, but I don't see a way in which Policy can help with
> that problem unless this packaging decision was intentional and the person
> who made that decision would have chosen otherwise if Policy had said to
> not do it.
>
> This seems more like an appropriate check for an archive-wide QA tool
> looking for cross-package problems.

Indeed, and that was the point I was trying to make: it's not something
Policy can help with, unless it is intentional (and it is my belief that
this is not likely to be the case).

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr vs. symlink farms

[Wouter Verhelst]

On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote:
> Luca Boccassi  writes:
> 
> > Thank you - it has been brought up in this thread as an example of a
> > valid setup, so if it is not, I think it could be good to be extra clear
> > in the policy? How about the following:
> 
> If we tried to document every random bit of buggy packaging behavior
> anyone thought of in Policy, Policy would become unwieldy, so I want to
> verify here that someone really thought having one package containing a
> file in /bin and another package containing the same file in /usr/bin was
> was a reasonable thing to do (as opposed to accidental).  Are there
> packages in the archive like this?  Or could you point me at the message
> in the thread that said this was non-buggy?  I think I missed it.

The problem here is also that if there are two packages like that, on an
usrmerge system, we would not know this is happening.

Let's say there's a package "foo" which installs /usr/bin/foo, and an
package "binfoo" which installs "/bin/foo". In the current situation,
dpkg would not know that the two files are equivalent, and would happily
overwrite /usr/bin/foo with /bin/foo if "binfoo" was installed after
"foo".

Then when the user notices the "foo" program is not doing what they
believe it should be doing and runs "reportbug /usr/bin/foo", reportbug
will file the bug against the package "foo" rather than the package
"binfoo" which is the actual package whose binary they are trying to
use.

In contrast, if foo and binfoo both install "/bin/foo" (or both install
"/usr/bin/foo", either way works), then dpkg will complain at
installation time that one of the two packages tries to overwrite a file
from the other and refuse to continue.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Looking for Estonian DD-s

[Wouter Verhelst]

On Mon, Aug 23, 2021 at 04:12:43AM +, Paul Wise wrote:
> On Sun, Aug 22, 2021 at 2:31 PM Aivar Annamaa wrote:
> 
> > Is here someone, who can meet me in Tartu, Estonia or is willing to
> > arrange this over the internet? Perhaps I could sign a statement about
> > my identity with Estonian ID card?
> 
> I checked the list of lists of Debian locations and there are no
> Debian members that list their location as Estonia. It generally isn't
> accepted to sign keys over the internet or other electronic means.

Disagree. Why would that be the case?

By signing an OpenPGP key you certify that you are sufficiently
convinced that the key's holder is who they say they are, and that they
control their key. The easiest way to do that is to meet someone in
person, but that doesn't mean it's the *only* possible way.

Am I missing something?

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr vs. symlink farms

[Wouter Verhelst]

On Sat, Aug 21, 2021 at 02:40:02PM +0100, Luca Boccassi wrote:
> On Sat, 2021-08-21 at 10:26 +0200, Wouter Verhelst wrote:
> > It bothers me that you believe "we've been doing this for a while
> > and it didn't cause any problems, so let's just continue doing
> > things that way even if the people who actually wrote the damn code
> > say that path is littered with minefields and they're scared of what
> > could happen when we finish the tranition this way" is a valid
> > strategy. It goes against everything I was taught to do to write
> > reliable software.
> 
> Many people are bothered by many things - such is life. For example, I
> am very bothered that it appears impossible to do any kind of project-
> wide innovation in Debian,

  "I don't deny the benefits.  I do think that in the current
  implementation, the drawbacks outweigh those benefits.  That's not to
  say it couldn't be done.  But if it is done, we should do it *right*.
  We're Debian.  That's what we do."

  -- Colin Walters, https://lists.debian.org/debian-devel/2003/06/msg00475.html

It's true that there are other distributions out there who go for the
quick-and-dirty solution, who want the feature before the benefits,
downsides, and risks have all been fleshed out. There's a reason why I'm
not contributing to those distributions; there's a reason why I don't
use those distributions.

"Doing it right", even if that takes time, has proven benefits.

When the RPM world implemented "multiarch", they only supported
installing 32-bit binaries on 64-bit versions of the same architecture.
They did have that feature implemented and functioning in a few months
or so, but the functionality of it was very limited -- and even today it
has problems, in that the way in which RPM checks that packages are
correct has some inherent heuristics that can make mistakes. Yes, I've
encountered those in practice on CentOS systems that my customers at the
time really really wanted to get up and running again pretty quickly.

When Debian and Ubuntu implemented multiarch (look ma, no quotes), the
time from concept to tests to implementation to public availability was
*much* longer than it was in the RPM world; and while this work was
unfinished, there was a lot of angry nagging about the lack of this
feature and why can they do it in the RPM world you guys are idiots, but
eventually it was implemented; and I think you'll agree that the dpkg
implementation of multiarch is far superior to the RPM one: it's
possible to use multiarch not just for compatibility with 32-bit
versions of your 64-bit platform, as in the RPM world, but *also* for
running arm binaries on x86 with qemu user emulation, or for
cross-compiling, or for various other features that the RPM world can
only dream of.

To get back to the point: I'm not saying we shouldn't merge /usr. We
should; the benefits of a properly merged /usr far outweigh any
disadvantages it may bring.  However, having an inconsistent dpkg
database is far more serious than just "oh dpkg -S won't work as
expected". It means dpkg isn't properly keeping track of which files
belong to which package anymore, which means you will have issues with a
package that Replaces: another, or with removing packages (especially
with security-conscious binaries), or with diversions, or with
alternatives, or with file conflicts, or with basically anything that
asks dpkg about locations of files; and just dismissing it with a
handwavy "ah well just run dpkg -S again" is so far removed from reality
that it's not even funny. I think the dpkg maintainers are 100% correct
to point out that that *is* a problem for which currently no viable
solution seems to exist, and that any way forward *must* include a
solution to that problem.

I'm not saying the solution which the dpkg maintainers are proposing is
the only valid solution, but if you go and tell them "ah the real
problems you point out are irrelevant" then You! Are! Doing! It! Wrong!

[...]
> The main point is that of course the insights of experts are extremely
> important, incredibly valuable and worth careful consideration,
> especially when making decisions about an unknown future and events yet
> to unfold. But in this case these are predictions about the past, a
> past that already exists and is lived experience for many users here,
> and for all users in Ubuntu.

What that is, is anecdotal evidence. "We've been doing X for a while and
it seems to not kill everything". Cool, great, awesome data points, but
not likely to convince me that there won't ever be any problems. You
can't prove the absense of bugs by anecdotal evidence; you can only
prove the existence of them that way.

What the dpkg maintainers are providing is analytical evidence. "There's
some corner cases here which need to be catered to". You just can't sa

Re: Q: Use https for {deb,security}.debian.org by default

[Wouter Verhelst]

On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote:
> Yes transparent proxies or overridden DNS lookups could be used to
> direct deb.debian.org and security.debian.org to your alternative
> location,

I've been thinking for a while that we should bake a feature in apt
whereby a network administrator can indicate somehow that there is a
local apt mirror and that apt should use that one in preference to
deb.debian.org.

This could be useful for both the "I've got a slow uplink and would like
it to not be overwhelmed at the BSP I'm hosting for my Debian friends"
type as well as the "I'm an ISP and I want to provide a mirror to Debian
users so we can reduce our uplink connection a bit" type of situations.

However, I've not been able to come up with a scheme which is simple
enough to be doable on a LAN while at the same time be usable by larger
network providers, *and* which can't also be abused by MitM attackers.

Perhaps it's just not something we would be able to do?

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Q: Use https for {deb,security}.debian.org by default

[Wouter Verhelst]

On Thu, Aug 19, 2021 at 10:11:33PM +, Jeremy Stanley wrote:
> On 2021-08-19 16:37:13 -0400 (-0400), Kyle Edwards wrote:
> > On 8/19/21 3:46 PM, Simon Richter wrote:
> > > For the most part, users would configure https if they are behind a
> > > corporate firewall that disallows http, or modifies data in-flight so
> > > signature verification fails, everyone else is better off using plain
> > > http.
> > 
> > Or they might configure https on the sheer principle of not wanting to have
> > their traffic hoovered up by their ISP or anyone else who might be
> > listening.
> 
> While this does complicate it, a snooping party can still know the
> site they're connecting to via SNI happening unencrypted,

SNI is not unencrypted if you do TLS1.3...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr vs. symlink farms

[Wouter Verhelst]

On Fri, Aug 20, 2021 at 11:21:55AM +0100, Luca Boccassi wrote:
> On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote:
> > On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote:
> > > 
> > > I think no one likes that idea, but it's the only solution that doesn't
> > > immediately fail because it requires a dpkg update that hasn't shipped 
> > > with
> > > the current stable release, breaks local packages (kernel modules, 
> > > firmware,
> > > site-wide systemd configuration), or both.
> > 
> > This could be solved if we could somehow require dpkg to be updated
> > before any other packages during the the next update, no?
> > 
> > Breaking this constraint means that we can't make "apt-get
> > dist-update" work seemlessly --- but what if we were to change the
> > documented procedure for doing a major update?
> > 
> > That's not ideal, granted, but how does that compare against the other
> > alternatives?
> > 
> > - Ted
> > 
> > P.S.  I had a vague memory that there was some update in the long
> > distant past where we did require a manual upgrade of dpkg first.  Or
> > is my memory playing tricks on me?  I do know that a manual update of
> > dpkg is the first step in a crossgrade
> 
> An update to dpkg is not _required_. It might be very strongly
> _desired_ which is a perfectly legitimate stance to take, but it is not
> technically required, otherwise we couldn't have been shipping with
> merged-usr as default in new installations of Buster and Bullseye for
> 2+ years, we could not have been installing usrmerge in older
> installations for 2+ years, and Ubuntu would not exist anymore since
> legacy split-usr is discontinued and even older installations are being
> forcibly converted. So continuing to live with this minor ~20 years old
> dpkg bug as we've been doing for years is a valid option - one that
> some might very, very strongly dislike and argue against which is again
> perfectly legitimate, but it is de-facto an option nonetheless, because
> it's the actual status quo for 2+ years.

It bothers me that you believe "we've been doing this for a while and it
didn't cause any problems, so let's just continue doing things that way
even if the people who actually wrote the damn code say that path is
littered with minefields and they're scared of what could happen when we
finish the tranition this way" is a valid strategy. It goes against
everything I was taught to do to write reliable software.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Wouter Verhelst]

On Mon, Aug 16, 2021 at 04:47:32PM +, Holger Levsen wrote:
> 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.

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.

YMMV, of course.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr

[Wouter Verhelst]

On Mon, Aug 16, 2021 at 04:17:01PM +0200, Marco d'Itri wrote:
> On Aug 16, Wouter Verhelst  wrote:
> > On Fri, Aug 13, 2021 at 07:53:20AM +0200, Marco d'Itri wrote:
> > > Implementations with real /bin /sbin /lib* directories and symlink farms
> > > are not useful because they would negate the major benefits of 
> > > merged-/usr, i.e. the ability of sharing and independently updating 
> > > /usr.
> > In those cases, you would never run dpkg inside the system with the
> > "shared" /usr directory, so for those cases having /bin /sbin /lib* be
> > symlinks or real directories is irrelevant.
> It is not irrelevant because then you would need to update /bin /sbin 
> /lib* on the root file system when a new binary is added to the /usr 
> file system (e.g. in an updated OS image).
> So I do not think that you understand well this use case.

My point is:

There is pushback against having usrmerge as the "default" thing,
because it confuses dpkg. Therefore some people would prefer a solution
that does not require all systems to have /bin etc be symlinks unless
and until the transition is complete.

This pushback however is only relevant for systems where dpkg will run.
If dpkg will not run, then dpkg cannot get confused, and so you *can*
have /bin etc be symlinks and it won't cause problems.

So "this is problematic for a case where dpkg will not run" is
irrelevant, as there you can do what you want and dpkg won't get
confused at all.

> > The point of having /bin etc not be a symlink is *to stop confusing
> > dpkg*.
> This is a legitimate but very minor goal which could also be achieved 
> by changing dpkg.

Yes; but according to the dpkg maintainer, "changing dpkg" will take
much effort that may cause corner case bugs (including files
disappearing), and it would be easier (as in, faster and less likely to
cause problems) to try to do this in some other way. Perhaps he's wrong
at this (I don't know), but I haven't seen anyone take his concerns
seriously, and/or even try to come up with solutions to the concerns
that are raised.

Putting your hands in your ears and saying lalala it's not true is not
helping anyone.

(of course it might be that you have tried to do this and I've just
missed it, in which case just point me to the relevant bug)

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Debian package manager privilege escalation attack

[Wouter Verhelst]

On Thu, Aug 12, 2021 at 01:19:23PM +, Holger Levsen wrote:
> 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.)

Well, if you choose not to enter a root password, then the installed
system will have sudo with a "the user created at install time can run
everything as root through sudo" configuration, which essentially is the
same thing.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

[Wouter Verhelst]

On Sat, Aug 14, 2021 at 07:48:06AM +0100, Jonathan Dowland wrote:
> Backports is not analogous to the concepts Timothy was presenting. It's
> *one* repository, not a system where people (not just Debian maintainers)
> can create repos.

extrepo tries to help there, and now that bullseye is released, should
be more usable for everyone.

Unfortunately it requires you to do all the handywork in order to have
an actual, signed, repository, but reprepro is easy enough to use and
works well enough for most use cases; it's something that we could
document somewhere and then point people to it.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr

[Wouter Verhelst]

On Fri, Aug 13, 2021 at 10:16:57AM +0100, Luca Boccassi wrote:
> On Fri, 2021-08-13 at 07:53 +0200, Marco d'Itri wrote:
> > Implementations with real /bin /sbin /lib* directories and symlink farms
> > are not useful because they would negate the major benefits of 
> > merged-/usr, i.e. the ability of sharing and independently updating 
> > /usr.
> > 
> 
> Indeed, it would be a completely pointless exercise. There's no benefit until
> you can safely ignore the split-usr legacy directories, which with this
> alternative scheme would never happen, and that's the whole point. As SUSE
> found out after wasting 10 years trying to implement this failed strategy,
> despite having tools and a build system that are light years ahead of what
> Debian has (and a stronger top-down governance model too, which doesn't leave
> much room for dissent), such package-by-package transition will never finish.

We finished the /usr/doc transition in *exactly* this way. Yes it took
us longer, but we have better tools now.

So I call BS on "it will never finish".

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr

[Wouter Verhelst]

On Fri, Aug 13, 2021 at 07:53:20AM +0200, Marco d'Itri wrote:
> Implementations with real /bin /sbin /lib* directories and symlink farms
> are not useful because they would negate the major benefits of 
> merged-/usr, i.e. the ability of sharing and independently updating 
> /usr.

In those cases, you would never run dpkg inside the system with the
"shared" /usr directory, so for those cases having /bin /sbin /lib* be
symlinks or real directories is irrelevant.

The point of having /bin etc not be a symlink is *to stop confusing
dpkg*. If you're talking about a system where dpkg will never run, then
that's irrelevant and you can just do whatever you want.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Wouter Verhelst]

Hi Holger,

On Wed, Aug 11, 2021 at 05:12:54PM +, Holger Levsen wrote:
> 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 +, 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.

Yes, of course -- I didn't mean to say "you should make it fail", but
rather "I'm sure you know of ways in which it commonly fails that we
want to protect against".

> because here, our focus would be to publish things :)

Sure. But also to find problems early rather than late, no?

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr

[Wouter Verhelst]

On Tue, Jul 27, 2021 at 04:26:34PM +0200, Simon Richter wrote:
> Also, take care when moving shell commands from a shell script: the bash
> shell at least keeps a cache of commands to paths so it doesn't have to do a
> full path search every time. A shell script that calls
> 
> mv /bin/cp /usr/bin/cp
> ln -s ../usr/bin/cp bin/cp
> mv /bin/ln /usr/bin/ln
> ln -s ../usr/bin/ln bin/ln
> 
> could fall over because it cached the location of "ln" as /bin/ln in the
> beginning, then after the move cannot find it anymore. That needs at least a
> "hash -d ln".

This is why I said to use cp, not mv, when moving the file...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr

[Wouter Verhelst]

On Tue, Jul 27, 2021 at 06:53:01PM +0500, Andrey Rahmatullin wrote:
> On Tue, Jul 27, 2021 at 03:25:48PM +0200, Wouter Verhelst wrote:
> > I'm worried about systems being written to completely bypass the dpkg
> > database. 
> Like alternatives and things that create files in postinst?

The alternatives system doesn't bypass the dpkg database. It creates
extra symlinks on the system that do not exist in the dpkg database.

Creating files in postinst doesn't bypass the dpkg database. It creates
extra files on the system that do not exist in the dpkg database.

Creating a system that tells dpkg that files exist in one place but
where in reality they're in a different place does bypass the dpkg
database.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr

[Wouter Verhelst]

On Tue, Jul 27, 2021 at 02:13:33PM +0200, Andreas Metzler wrote:
> On 2021-07-27 Wouter Verhelst  wrote:
> > On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
> >> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> >>> I've suggested previously that we can easily make it RC for bookworm to
> >>> have a file outside a limited set of directories (/etc and /usr would be
> >>> OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
> >>> This is easy to detect with a lintian check and reasonably easy to
> >>> implement
> 
> >> I don't think that works in general without breaking some of Debian's
> >> axioms around Essential packages, as previously described here:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118
> 
> > Yes. Those arguments didn't convince me then, and they don't convince me
> > now.
> 
> > A package in the essential set could work around the issue by moving a
> > file around and creating a necessary symlink in preinst rather than
> > shipping things. The set of Essential packages is small however, and
> > most packages can ship a compat symlink.
> 
> > I didn't say we *should* ship compat symlinks; I said we should make
> > antyhing that is *not* a compat symlink in a particular set of
> > directories be RC.
> [...]
> 
> Hello Wouter,
> 
> I will bite.

Cool.

> just for context: Simon said in #978636 that e.g. coreutils
> a) cannot ship both /usr/bin/mv and /bin/mv (the latter a symlink) in
> the tarfile since /bin _might_ be a symlink to /usr/bin but 
> b) it needs to provide /bin/mv in unpacked, unconfigured state.
> 
> Simon then said we needed a flag day where the aliasing-symlinks /bin -->
> /usr/bin are either guaranteed to exist or forbidden. Once that is know
> essential packages either ship both /usr/bin/mv and /bin/mv (the latter
> a symlink) or only ship /usr/bin/mv (with no symlink required.)
> 
> Afaiu you are suggesting to do somethink like this instead and
> immediately post bulleye release.
> 
> preinst upgrade|install
> if aliasing-symlinks /bin --> /usr/bin
># do nothing
> else
>mv /bin/mv /usr/bin/mv

That should be a copy (mv is too dangerous)

>ln -s /usr/bin/mv /bin/mv

This can be "ln -sf" to make it atomic.

> fi
> Plus corresponding error handling code in postrm abort install.
> 

Yes, but for packages in the Essential set only. For other packages, we
can make it much simpler.

> I just do not get the benefit. It seems rather complicated with
> potential for breakage in corner cases and unnecessary since we (CTTE)
> have essentially decided that there is going to be a cutoff date
> pre-bookworm-release whereupon package maintainers can rely on the
> existence of aliasing-symlinks and can simply move the file without any
> maintainerscripts. It seems to be a waste of work to write
> complicated maintainerscripts that are only needed as long as we need to
> handle both usrmerge-d and non-usrmerge-d systems.

I'm not worried about the support for both usrmerge'd and not usrmerge'd
systems.

I'm worried about systems being written to completely bypass the dpkg
database. It's being pushed forward "because we broke things in the past
and now the only way to fix it is to break even more things". That's BS.

I'm convinced there is a way that we can move forward which does *not*
require bypassing the dpkg database. I think that such a way *should* be
preferential, and the complete lack of even a desire to discuss things
with the dpkg maintainer in ways that the dpkg maintainer thinks is a
reasonable way forward is distressing for me.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr

[Wouter Verhelst]

On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> > I've suggested previously that we can easily make it RC for bookworm to
> > have a file outside a limited set of directories (/etc and /usr would be
> > OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
> > This is easy to detect with a lintian check and reasonably easy to
> > implement
> 
> I don't think that works in general without breaking some of Debian's
> axioms around Essential packages, as previously described here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118

Yes. Those arguments didn't convince me then, and they don't convince me
now.

A package in the essential set could work around the issue by moving a
file around and creating a necessary symlink in preinst rather than
shipping things. The set of Essential packages is small however, and
most packages can ship a compat symlink.

I didn't say we *should* ship compat symlinks; I said we should make
antyhing that is *not* a compat symlink in a particular set of
directories be RC.

> I have a longer mail written with possible ways forward, which I'm
> deliberately not sending right now, because the first step in all of these
> plans is "release Debian 11" and I don't want to distract the people who
> are making that happen (any more than has already happened).

This is so exhausting.

Yes, I know the release is close, and yes, I know that some people are
immensely busy working on that. I want to help them do so in any way I
can, but they're not *required* to read -devel, and "they might read
this and get distracted" seems like a pretty poor argument.

I'm not busy with the release. Are you? If not, you *can* actually come
up with an argument right now, and I promise not to insist on any
decision being made until the release happens, so that those
hypothetical people who *are* busy with the release can still chip in
later if they choose to do so.

Meanwhile, we can still discuss this.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Wouter Verhelst]

On Mon, Jul 19, 2021 at 03:10:42PM +0200, Michael Biebl wrote:
> Hi Guillem
> 
> Am 19.07.21 um 03:36 schrieb Guillem Jover:
> > What I've also said multiple times, is that
> > merged-usr-via-moves-and-symlink-farms could have been implemented in
> > a fully automated way, by debhelper, w/o requiring any maintainer scripts,
> > all with full cooperation and managed by dpkg, with .debs shipping
> > actual tracked pathnames
> I'm convinced this view is way too naive and not implementable in practice
> (and yes, openSUSE is a data point that confirms that)
> 
> What you propose is, that each and every package does its /usr-merge
> transition on its own. This only works, if packages are independent (enough)
> so this actually works.
> Unfortunately this is not the case. Take PAM for example. You can't just
> recompile src:pam and have debhelper automatically move all files to /usr.
> This would break all packages that install a PAM plugin. You have a
> transition here, involving many packages.

Why?

Nobody is saying the old path should cease to function. The whole point
of a symlink farm is that *YOU ADD A SYMLINK* to replace the old path.

So then you have /lib/*/security/pam_foo.so ->
/usr/lib/*/security/pam_foo.so and your old-pam plugin will still work
with new-pam (and vice versa) and there is no need for a transition.

I've suggested previously that we can easily make it RC for bookworm to
have a file outside a limited set of directories (/etc and /usr would be
OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
This is easy to detect with a lintian check and reasonably easy to
implement, and would not confuse dpkg *at all*.

But whenever I bring this up, I hear people say "oh but suse tried it
and failed" (well suse aren't using dpkg and there's no reason to assume
we'll have the same problem, why don't we try?) or "oh but the /usr/doc
transition that worked that way 20 years ago took forever" (that was 20
years ago, our tooling is way more advanced these days) or "oh but that
will break bash and you can't upgrade safely without bash" (true, but
bash is just the one package and we already have /bin/sh be a symlink
and that never made upgrades fail permanently so I don't see how
usrmerge is somehow special).

I've grown tired of the whole discussion, and the "we must go forward
and only our way will work and your ideas are stupid just shut up
already" mentality the proponents of usrmerge seem to have.

I can understand the use case for usrmerge, and I won't cry over my
/bin/sh being essentially the same file as /usr/bin/sh -- but I long for
the good old days of Debian where we did things the right way, not
whichever is the fastest, because that way, things would *work* in *all*
cases, not just the cases that the proponents of some new feature care
about.

It took us forever to implement the /usr/doc transition, but it was
finished and nobody's machine broke.

It took us a fairly large time to implement multiarch, but we did it and
it works *way* better than in the RPM world.

I fail to see why usrmerge is so special that it can't wait until we do
things the right way.

Sure, there are technical issues with doing things the right way, and we
should deal with them. But just throwing them under the carpet and
deciding they're only a problem for other people isn't going to help
anyone.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}


signature.asc
Description: PGP signature

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Wouter Verhelst]

On Mon, Jul 05, 2021 at 12:31:10PM +, 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,
> > buildinfo files can be uploaded and are kept, with the metadata stored
> > in the DB. but nothing is done yet with those.
> 
> yeah :/
> 
> > 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...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Wouter Verhelst]

On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote:
> Jonathan Carter  writes:
> 
> > I think that framing the problems and noting them while the last GR is
> > still fresh in our collective memories will be really useful. I don't
> > think anyone should feel too much pressure right now to come up with
> > solutions, and I'd urge any group of people who are brainstorming on
> > this whether on a public channel or among some Debian friends to not yet
> > propose any kind of GR or anything major like that just yet.
> 
> I'm certainly not in any hurry to do anything like that.  :)  And I also
> expected everyone to not want to get into it in detail until after the
> release is out.
> 
> For the record, because some folks in this discussion have been worried
> that this is about one specific vote or another, here's a (nonexhaustive)
> list of concerns that I have that I think we should fix.  This isn't
> really intended to open a discussion or get into solutions and I probably
> therefore won't respond to more discussion of that right now (I promise, I
> will later and won't propose any surprise GRs).  This is just to give
> people a feel of what some of us mean when we talk about procedural flaws:
> 
> * The length of the discussion period is ill-defined in multiple ways,
>   which has repeatedly caused conflicts.  It only resets on accepted
>   amendments but not new ballot options, which makes little logical sense
>   and constantly confuses people.

I agree; I believe it should be the opposite (i.e., it should reset on
new ballot options but not on modifying already accepted options)

[...]
> * A formal amendment has to be sponsored like a new GR before it can be
>   accepted, but the original proposer of a GR can make their own amendment
>   without having it be sponsored.  These two rules make no sense in
>   combination (which is probably why the first rule is rarely, perhaps
>   never, enforced).

I'm not entirely sure what you mean by that. Can you clarify?

[...]
> * There's a reasonable argument that using a default option of "none of
>   the above" would be clearer to people who have not participated in a lot
>   of Debian votes but who have experience with other voting systems where
>   that's a more typical default option.

I can understand the issue with FD, but I don't think NOTA is a good
alternative. I think any other language should be explicit about what
the result will be, and what it will *not* be. NOTA does do that, IMO;
it does not clarify that the discussion may restart, and that a new vote
may appear; it just states that none of the presented options are
appropriate.

The default option means "we don't have a valid option on the ballot, we
would therefore like to cancel the vote and possibly do it over"; I
would therefore prefer the default option to state something like
"cancel the vote, possibly restart it" or some such.

>   Also, some folks (not including
>   me, but I do understand) have been unhappy with the plain English
>   implications of "further discussion" for some time and often feel
>   obliged to propose a ballot option that's functionally equivalent but
>   isn't seen as calling for more discussion.

Not sure whether you consider this an issue, but I don't see that as a
problem. There is a difference between "we can't reach an agreement and
therefore decide on a no-outcome vote" (which the default option is),
and "we have considered all the options and decide that a no-outcome
vote is the best result" (which an explicit no-outcome ballot option
represents).

To put it otherwise, due to the nature of the default option, an
explicit no-outcome ballot option is *not* functionally equivalent to
the default option, in my opinion, since the default option means "this
doesn't work, let's not do this and maybe try again", and an explicit
no-outcome ballot option explicitly means "this doesn't work, let's not
do that again".

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Wouter Verhelst]

Hi Sam,

On Mon, Apr 19, 2021 at 10:58:51AM -0600, Sam Hartman wrote:
> Certainly in the systemd process there were a number of short comings
> that came to light that are worth improving:
> 
> 1) The person who introduces a GR is treated differently than anyone who
> introduces an amendment in ways that are odd, and are subject to
> strategic abuse.
> 
> 2) The fact that a single person ends up calling for a vote has become
> problematic in three important Debian elections now--one on the TC and
> and two GRs.

I don't think this is necessarily a problem, provided that the rules for
calling for vote vis-a-vis discussion time are reasonable.

(I don't think they are, currently)

> 3) It seems like we could do better surrounding discussion time
> management.
> 
> 4) It seems like there is an emerging consensus that we want either all
> votes secret or to be able to have secret non-DPL votes.
> 
> None of these would have made the decision different, but I think they
> would together have improved the process.
> 
> However, I don't think any of the above needs a working group.

I agree with this. In my opinion, all historic attempts to create a
ballot through a working group or something similar have failed
miserably.

Our current processes work best, I believe, if proposals are written in
the open, so that if people disagree with the proposed texts, they can
start working on their amendment right away, which is much more
difficult to do under the time pressure of a GR procedure.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Fixed release dates are hurting quality

[Wouter Verhelst]

So.

On Sun, Feb 07, 2021 at 01:40:39PM +0100, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> I just noticed how maintainers are NMU'ing packages in large quantities to
> get them somehow in a usable state for the release. The packages get small
> patches so that they are more or less working and can get into testing,
> despite the packages being untouched for a long time in some cases meaning
> there is no guarantee for quality.

I was one of these maintainers.

gridengine has been in Debian since 2008, and the version in Buster
works well. I don't have time to maintain it, but I do use it often, and
some of the work I do for the debconf and FOSDEM video teams relies on
it being available.

It was pointed out to me shortly before the freeze that it was not in
bullseye because of a "FTBFS with gcc-10" bug for which a (rather
trivial) patch was already available. Unfortunately it turned out that
that patch wasn't sufficient, so I had to repeat the pattern one more
time to make it work. The patch is *still* very trivial though.

There is now a gridengine package in Bullseye again, and it works as
well as it did in Buster.

I don't agree with the statement that doing things like this is a bad
idea. Sometimes doing the minimal necessary to make a package work again
so that our future needs will still be served by it is a good idea. I
think that this is one of those times, and I guess that it's the same
for most of the packages uploaded like that.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Library won't link

[Wouter Verhelst]

Hi Sven,

On Sun, Nov 22, 2020 at 11:44:42AM +0100, Sven Joachim wrote:
> On 2020-11-22 11:29 +0200, Wouter Verhelst wrote:
> > What am I missing?
> 
> I think this happens because g++ passes --as-needed to the linker in
> unstable, but not in stable.  Your test program is compiled with
> 
> g++ -o linktest $(pkg-config --cflags --libs libola) debian/tests/hw.cc
> 
> and that adds -lola at the wrong place in the commandline.  According to
> the binutils documentation, --as-needed has this effect:
> 
> ,
> | Object files or libraries appearing on the command line _after_ the
> | library in question do not affect whether the library is seen as needed.
> | This is similar to the rules for extraction of object files from
> | archives.  '--no-as-needed' restores the default behaviour.
> `
> 
> So,
> 
> g++ -o linktest debian/tests/hw.cc $(pkg-config --cflags --libs libola)
> 
> is probably you want instead.

I was going to say "but 913704", but somehow I lost that change... D'oh.
That would explain it, obviously.

Thanks!

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Library won't link

[Wouter Verhelst]

Hi,

For the past year, I've been (on and off) working with ola upstream on
getting new-gcc (first 9, then 10) and python3 issues resolved, so that
I would be able to get it into bullseye again. We're almost there,
except for one thing that mystifies me.

As part of the autopkgtest, I build a small program that initializes
libola to make sure that a basic initialization works. This worked
previously, but now fails with:

autopkgtest [15:27:45]: test command6:  - - - - - - - - - - stderr - - - - - - 
- - - -
/usr/bin/ld: /tmp/cczs0VkU.o: warning: relocation against 
`_ZTVN3ola2io18LoopbackDescriptorE' in read-only section 
`.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]'
/usr/bin/ld: /tmp/cczs0VkU.o: in function `main':
hw.cc:(.text+0x11): undefined reference to 
`ola::io::LoopbackDescriptor::LoopbackDescriptor()'
/usr/bin/ld: hw.cc:(.text+0x24): undefined reference to 
`ola::client::OlaClient::OlaClient(ola::io::ConnectedDescriptor*)'
/usr/bin/ld: hw.cc:(.text+0x30): undefined reference to 
`ola::client::OlaClient::Setup()'
/usr/bin/ld: hw.cc:(.text+0xc1): undefined reference to 
`ola::client::OlaClient::~OlaClient()'
/usr/bin/ld: hw.cc:(.text+0xe0): undefined reference to 
`ola::client::OlaClient::~OlaClient()'
/usr/bin/ld: /tmp/cczs0VkU.o: in function 
`ola::io::BidirectionalFileDescriptor::~BidirectionalFileDescriptor()':
hw.cc:(.text._ZN3ola2io27BidirectionalFileDescriptorD2Ev[_ZN3ola2io27BidirectionalFileDescriptorD5Ev]+0xf):
 undefined reference to `vtable for ola::io::BidirectionalFileDescriptor'
/usr/bin/ld: 
hw.cc:(.text._ZN3ola2io27BidirectionalFileDescriptorD2Ev[_ZN3ola2io27BidirectionalFileDescriptorD5Ev]+0x1d):
 undefined reference to `vtable for ola::io::BidirectionalFileDescriptor'
/usr/bin/ld: /tmp/cczs0VkU.o: in function 
`ola::io::ConnectedDescriptor::~ConnectedDescriptor()':
hw.cc:(.text._ZN3ola2io19ConnectedDescriptorD2Ev[_ZN3ola2io19ConnectedDescriptorD5Ev]+0xf):
 undefined reference to `vtable for ola::io::ConnectedDescriptor'
/usr/bin/ld: 
hw.cc:(.text._ZN3ola2io19ConnectedDescriptorD2Ev[_ZN3ola2io19ConnectedDescriptorD5Ev]+0x1d):
 undefined reference to `vtable for ola::io::ConnectedDescriptor'
/usr/bin/ld: /tmp/cczs0VkU.o: in function 
`ola::io::LoopbackDescriptor::~LoopbackDescriptor()':
hw.cc:(.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]+0xf):
 undefined reference to `vtable for ola::io::LoopbackDescriptor'
/usr/bin/ld: 
hw.cc:(.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]+0x1d):
 undefined reference to `vtable for ola::io::LoopbackDescriptor'
/usr/bin/ld: 
hw.cc:(.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]+0x31):
 undefined reference to `ola::io::LoopbackDescriptor::Close()'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
autopkgtest [15:27:45]:  summary

(as observed on
https://salsa.debian.org/wouter/ola/-/jobs/1173462#L1297)

>From what I can make out, the first message happens when a file is
compiled without -fPIC and then linked into a shared library. This would
be surprising if that is the reason, for libola is built using libtool
throughout, and trying the build on stable works with no problem
whatsoever.

What am I missing?

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Making Linux distro with Debian

[Wouter Verhelst]

On Sat, Nov 21, 2020 at 01:39:10AM +0300, ajsjajis eihwjshs wrote:
>Its legal to making Linux distro and sharing with changing Debian logos
>codes etc. 

Yes, it is legal, absolutely.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Hosting the original youtube-dl sources on salsa?

[Wouter Verhelst]

On Fri, Oct 30, 2020 at 09:16:21AM +0100, Philip Hands wrote:
> Rogério Brito  writes:
> 
> > Dear people,
> >
> > As many of you may know, the RIAA issued a resquest for GitHub to take down
> > the youtube-dl repository.
> 
> IANAL so I may be confused, but AIUI that takedown is based on the
> notion that there is no legitimate use for youtube-dl, which is
> nonsense, as this comment clealy demonstrates:

Actually not, it is based on the DMCA (which requires takedowns upon
being given notice), and on the fact that youtube-dl includes some
crypto bypassing code.

[...]
>   b) if the RIAA feels the need to repeat their claims, that we should
>  then insist that they persuade a judge that their case has some
>  merit before doing anything about it.

If salsa is hosted at a location that is under the jurisdiction of the
DMCA, then we would *have* to do anything about it before going to a
judge. That's how that (crappy) law works.

I'd rather we wait until the youtube-dl developers resolve the
situation, as it seems they are likely to do. The "nice" thing about
youtube in this context is that it treats content differently based on
the licenses that applies to the content; if youtube-dl is only able to
download videos whose licenses explicitly allows downloading (and it is
possible to do this), then youtube-dl can be reinstated with no issues.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Build-Depends-If-Available

[Wouter Verhelst]

Package: debian-policy

On Sun, Aug 09, 2020 at 06:28:50PM +0100, Barak A. Pearlmutter wrote:
> I understand what you're saying, and indeed trying to encode
> "Build-Depends-If-Available: foo" as "Build-Depends: foo | something"
> is a bad idea from the get-go. After all, foo can have three states on
> an architecture: installable, unavailable, or
> available-but-uninstallable-for-some-reason. And we want different
> behaviour in the three cases: build with it, build without it, or
> delay-building-until-installable. And we can't shoehorn those three
> things into the binary logic of "foo | something".

Exactly, and therein lies the problem.

Buildd used to consider alternative build-dependencies, and it caused a
never-ending stream of package transition entanglements, because the
delay-building-until-installable thing never happened, which meant that
every rebuild of something to solve a problem would have to either be
timed very well, or would be likely to be playing a roulette game of
"will the rebuild solve all problems or create yet even more".

-policy: this is a question that has come up before
(https://lists.debian.org/debian-devel/2016/12/msg00470.html is another
example that springs to mind, but I'm pretty sure there are more), so I
think we should document in Policy that a) buildd only looks at the
first dependency in alternative build-dependencies, and b) why this is
the case.

Suggestion:

---8<---
Note that sbuild, the program which builds packages on each of Debian's
architectures, only considers the first alternative for any declared
element in the Build-Depends: header, after removing alternatives with
architecture restrictions that don't apply to the architecture on which
the package is building. All other alternatives are ignored by sbuild.

This is done so that package dependencies are predictable; previously,
sbuild would consider alternative dependencies, but it made binary
package dependencies change based on whether a particular package
happened to be installable on unstable at the time of a package rebuild.
These changes were unpredictable, and made handling transitions harder
than they needed to be.
--->8---

Not sure in which section to place this though. Thoughts?

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Source only upload

[Wouter Verhelst]

On Tue, Jul 21, 2020 at 11:11:13AM +0200, Wouter Verhelst wrote:
> On Tue, Jul 14, 2020 at 02:21:30PM +, Paul Wise wrote:
> > Personally, I think we should discard binaries from all sourceful
> > uploads and only accept binaries from binary-only uploads such as the
> > uploads done by the buildds.
> 
> The reason we don't do this is because of bootstrapping: some tools
> require themselves to build, so you need to cross-build them on a
> different architecture, upload the cross-built binary, get an exception
> for that upload, and then re-upload the same version so it gets built on

Actually, you don't need an exception for that upload, but it needs to
go to unstable (and not testing).

Sorry for the confusion, my brain was a bit foggy apparently ;-)

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Source only upload

[Wouter Verhelst]

On Tue, Jul 14, 2020 at 02:21:30PM +, Paul Wise wrote:
> Personally, I think we should discard binaries from all sourceful
> uploads and only accept binaries from binary-only uploads such as the
> uploads done by the buildds.

The reason we don't do this is because of bootstrapping: some tools
require themselves to build, so you need to cross-build them on a
different architecture, upload the cross-built binary, get an exception
for that upload, and then re-upload the same version so it gets built on
the buildds. If you have a solution for that issue that allows not
accepting bootstrapped binaries in unstable, then by all means suggest
it. Otherwise I think the current situation is the best possible
solution given the requirements that exist.

Having said that, a warning by dupload or dak that you're uploading
binaries to unstable and is this really what you want would definitely
seem appropriate.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Recommendations around Git Packaging in Debian

[Wouter Verhelst]

Hi Sam,

Thanks for following up on this.

On Sat, Apr 18, 2020 at 02:38:04PM -0400, Sam Hartman wrote:
> *   We had a discussion of using native packages [2].

I wanted to read up on this a bit more, but your footnote is missing.
What was that meant to point to?

Thanks,

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: trends.debian.net updated

[Wouter Verhelst]

On Sun, Apr 12, 2020 at 09:11:57PM +0200, Ole Streicher wrote:
> Wouter Verhelst  writes:
> > On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote:
> >> Adam Borowski  writes:
> >> > Idea: perhaps we could make no unrestricted (maintainer, team, or QA) 
> >> > upload
> >> > for 10 years a RC bug on its own?  That threshold could then be gradually
> >> > reduced to eg. 5 years, as worst offenders get fixed.
> >> 
> >> One could deprecate old Standards-Version and require a version not that
> >> was not superceded for more than five years.
> >
> > That's not what Standards-Version means.
> >
> > You don't get to say "I know my package does not comply with current
> > Policy, but the Standards-Version claims an old version of Policy so
> > that's fine". You must always be compliant with current policy (in
> > unstable), and if policy changes in ways that apply to your package, you
> > need to update it.
> >
> > One of my packages, logtool, hasn't seen an upstream change since the
> > early naughties, and as a result there are 7 years between logtool
> > 1.2.8-8 and logtool 1.2.8-9.
> >
> > That however didn't mean it wasn't maintained, just that it didn't need
> > any update in 7 years.
> >
> > The only reason for Standards-Version to exist is so that when you or
> > whoever comes after you look at things a few days/weeks/months/years
> > down the line, you know what has changed in Policy since it was last
> > touched and can use upgrading-checklist.txt
> 
> In my understanding the Standards-Version documents up to which policy
> version a package was checked for compliance.

Yes.

> One could expect from maintainers that they check their packages for
> compliance regularly and that they document that.

Perhaps, but it is *also* documented that an upload just to bump the
Standards-Version is severely frowned upon. If there is no other reason
to upload in 7 years, then the Standards-Version will not be updated,
and that is perfectly fine.

> For a package that had no documented check for seven years it is OK to
> file an RC bug in order to clarify the compliance.

Hell no.

If you find that the 7-year-old package does not comply with policy in
some way because it is outdated (or for whatever other reason), then
sure, by all means file a bug at correct severity (RC if it is that).
But "this package is feature-complete and hasn't required an update in
seven years" is a feature, not a bug.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: length of Debian copyright files

[Wouter Verhelst]

On Sat, Apr 11, 2020 at 11:29:22AM +0200, Jonas Smedegaard wrote:
> Quoting Wouter Verhelst (2020-04-11 10:36:44)
> > On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote:
> > > Debian:
> > > https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1
> > > plus we ship the LGPL in base-files' common-licenses.
> > 
> > This kind of insanity is actually why I refuse to use the
> > machine-parseable copyright format.
> > 
> > Nobody cares that some file somewhere deep down in the source tree is
> > perhams maybe somewhat more permissive than the license on the whole. If
> > the license on the whole is a copyleft license, then that file somewhere
> > deep down is made available to you as that copyleft license, due to
> > "copyleft".
> > 
> > Anything else is insanity, and I refuse to waste my time on it.
> 
> You seem to conflate two issues:
> 
>  a) writing debian/copyright in a machine-parsable format
>  b) writing debian/copyright with too much detail included
> 
> Please use the machine-readable format because then machines can help 
> us. If you find it insane how detailed machine-readable format _can_ be, 
> then please use the format _without_ the insanity.

My point is that the machine-readable format is being "abused" to
deep-check the copyright status of all the files, and to reject
stuff/file bugs/... based on that.

Yes, a machine-readable copyright format is useful for our users. It
is, however, not useful if it is being used to inspect packages and kick
maintainers for not doing useless busywork. It is my belief that this is
actually happening, and therefore I don't want to do the
machine-readable copyright format.

People who care enough about the license of a piece of software that
they *do* need to know *all* these details can do the damn busywork
themselves; I will not.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: trends.debian.net updated

[Wouter Verhelst]

On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote:
> Hi,
> 
> https://trends.debian.net/ was just updated (with data until April 1st).

There is a significant bump in the number of co-maintained packages
during the buster release cycle. It is not at all clear to me what
happened there.

Do you have any idea?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: trends.debian.net updated

[Wouter Verhelst]

On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote:
> Adam Borowski  writes:
> > Idea: perhaps we could make no unrestricted (maintainer, team, or QA) upload
> > for 10 years a RC bug on its own?  That threshold could then be gradually
> > reduced to eg. 5 years, as worst offenders get fixed.
> 
> One could deprecate old Standards-Version and require a version not that
> was not superceded for more than five years.

That's not what Standards-Version means.

You don't get to say "I know my package does not comply with current
Policy, but the Standards-Version claims an old version of Policy so
that's fine". You must always be compliant with current policy (in
unstable), and if policy changes in ways that apply to your package, you
need to update it.

One of my packages, logtool, hasn't seen an upstream change since the
early naughties, and as a result there are 7 years between logtool
1.2.8-8 and logtool 1.2.8-9.

That however didn't mean it wasn't maintained, just that it didn't need
any update in 7 years.

The only reason for Standards-Version to exist is so that when you or
whoever comes after you look at things a few days/weeks/months/years
down the line, you know what has changed in Policy since it was last
touched and can use upgrading-checklist.txt

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: length of Debian copyright files

[Wouter Verhelst]

On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote:
> Debian:
> https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1
> plus we ship the LGPL in base-files' common-licenses.

This kind of insanity is actually why I refuse to use the
machine-parseable copyright format.

Nobody cares that some file somewhere deep down in the source tree is
perhams maybe somewhat more permissive than the license on the whole. If
the license on the whole is a copyleft license, then that file somewhere
deep down is made available to you as that copyleft license, due to
"copyleft".

Anything else is insanity, and I refuse to waste my time on it.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib

[Wouter Verhelst]

[sorry for the late reply; catching up on email]

On Fri, Feb 21, 2020 at 04:23:15PM -0500, Anthony DeRobertis wrote:
> On 2/21/20 2:00 AM, Wouter Verhelst wrote:
> > Even so, if we want to do so, this can be done correctly by a preinst
> > script in new libc, by way of a script that does the following:
> > 
> > cp -a /lib/ /usr/lib/
> > ln -sf /lib/ /usr/lib/
> > 
> > The first of the above two creates the new file; the second replaces the
> > old file, atomically, by a symlink.
> 
> Errr, pretty sure you meant to have the ln arguments in the opposite order.
> The link name is the second argument to ln.

Yes. I keep messing that up in production (ln is one of those commands
that I continually need to read the man page of)

> Besides that, you need a sync after the cp. Otherwise (in the event of an
> ill-timed crash) the data may not be written out, and you might wind up with
> /usr/lib/ being, e.g., a zero-byte file (with
> /lib/ a symlink to it). Possibly you even end up with
> /usr/lib/ missing, and /lib/ a
> dangling link.

Good point, yes.

My point was mostly though that it's possible to implement this
atomically, not to write a bug free script ;-)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib

[Wouter Verhelst]

On Wed, Feb 19, 2020 at 06:26:32AM +0100, Marco d'Itri wrote:
> On Feb 19, Guillem Jover  wrote:
> 
> > For any pathname that has been hardcoded a symlink can be used for
> > backwards compat, nothing unlike /bin or /sbin here. This looks just
> > like a normal bug from a botched transition, nothing special.
> Creating symlinks in /bin and /sbin DOES NOT result in a merged-/usr 
> system, because the content of /usr would not be decoupled anymore from 
> the content of /.

No, but it allows us to *transition* from the current situation to a
merged-/usr situation, *without* breaking the package manager's
expectations.

> A merged-/usr system must have /bin /sbin /lib* symlinks to /usr.

We can have a policy that by release X, any package installing anything
in /bin /sbin or /lib that is not a compat symlink is RC buggy.

Once we've reached that point, we can drop the directories and convert
them to symlinks. At that point, dpkg can also ignore any request to
create the compat symlinks, and later on we can make it an RC bug to
create compat symlinks if we wish to no longer support non-merged-/usr.

Yes, this approach takes more time, but it is an equally valid way to
move from unmerged /usr to merged-/usr, and is the approach that people
are advocating.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib

[Wouter Verhelst]

On Wed, Feb 19, 2020 at 10:19:35AM +, Simon McVittie wrote:
> On Tue, 18 Feb 2020 at 23:20:11 +0100, Andreas Henriksson wrote:
> >a debhelper addon which runs after
> >dh_install, detects files in /lib, /bin and /sbin, moves them
> >into /usr and generates the needed postinst code doing the compat
> >symlinks for non-merged systems.
> 
> This could work for non-Essential packages, or for Essential packages
> whose paths are not, in practice, hard-coded.
> 
> However, for Essential packages, I don't think this would be implementable
> in postinst, except by having the postinst be a statically-linked binary
> with no dependencies, or a busybox-static sh script. Otherwise we get
> this situation:
> 
> - starting point: /lib64/ld-linux-x86-64.so.2 exists,
>   /usr/lib64/ld-linux-x86-64.so.2 does not
> - (preinst runs, if any)
> - new libc6 is unpacked: now /usr/lib64/ld-linux-x86-64.so.2 exists,
>   and /lib64/ld-linux-x86-64.so.2 does not
> - postinst runs
> - if it's dynamically linked: /lib64/ld-linux-x86-64.so.2
>   doesn't exist so it fails to start
> - if it's a script with a dynamically-linked interpreter: ditto
> - if it runs dynamically-linked executables: ditto

It's insane to suggest that "merged /usr" *needs* to include the dynamic
linker. It's part of the ABI, so we can be perfectly fine by not moving
it around at all.

Even so, if we want to do so, this can be done correctly by a preinst
script in new libc, by way of a script that does the following:

cp -a /lib/ /usr/lib/
ln -sf /lib/ /usr/lib/

The first of the above two creates the new file; the second replaces the
old file, atomically, by a symlink.

The unpacking of new libc will then overwrite /usr/lib/,
and all is well.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: Can Debian packaging changes require a CLA?

[Wouter Verhelst]

On Mon, Feb 17, 2020 at 09:45:32AM +0100, Florian Weimer wrote:
> * Wouter Verhelst:
> 
> > On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote:
> >> It would also make the package unmaintainable if the original packer
> >> loses interest, so the package would not be suitable for inclusion in
> >> a stable release.
> >
> > Eh, it doesn't?
> >
> > A CLA is "you're allowed to change this, but if you want us to accept it
> > then you have to give us these rights, otherwise we'll reject your
> > contribution".
> 
> Ordinarily, yes.
> 
> But I think here the request was that Debian would only make changes
> (“packaging changes”) if they were made by someone who has been
> subjected to a CLA.

I didn't interpret it this way. And even if that is what the question
was, I don't think it's a valid question in Debian's context :-)

There is no ownership of a package in Debian other than "X is currently
the maintainer, and we don't usually take packages away without cause".
But if "X" doesn't actually continue maintaining a package properly,
then NMUs (in most cases) and/or package hijacks (in more extreme
circumstances) are part of our procedures and "not maintaining" would be
plenty of cause for such an action.

The package as part of Debian will remain, and can be modified by anyone
in Debian, as per the license applied to it if it is in main. Without a
signed CLA, such changes just won't be applied to the *current*
maintainer's git repository, but that doesn't matter as far as Debian is
concerned; if the original maintainer loses interest, then the
CLA-requiring git repository becomes utterly irrelevant to Debian.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: Can Debian packaging changes require a CLA?

[Wouter Verhelst]

On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote:
> It would also make the package unmaintainable if the original packer
> loses interest, so the package would not be suitable for inclusion in
> a stable release.

Eh, it doesn't?

A CLA is "you're allowed to change this, but if you want us to accept it
then you have to give us these rights, otherwise we'll reject your
contribution".

If the original packager loses interest, that becomes moot, because he's
not going to accept *any* patches anymore, anyway. You can fork, and you
can do whatever you want from then on.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: Y2038 - best way forward in Debian?

[Wouter Verhelst]

On Sat, Feb 15, 2020 at 11:41:32PM +, Steve McIntyre wrote:
> Hey John,
> 
> John Goarzen wrote:
> >On Tue, Feb 04 2020, Steve McIntyre wrote:
> >
> >The thing that we have to remember is that an operating system is a
> >platform for running software.  This problem is rather thorny, because:
> >
> >1) Some software is provided in only binary form and cannot be
> >recompiled
> 
> Oh, absolutely. In that situation there's not a lot we can sensibly
> do, modulo telling people to run such things in a time-shifted VM. I'm
> more worried about making *our* software work in the future.

This feels like a waste of effort, then. The only reason why people want
to run i386 is "multiarch, because I have this old binary that won't go
away". For all other stuff, there's amd64. Especially since RHEL doesn't
even do i386 anymore these days, so ISVs will have to compile for amd64
if they want it to work on whatever their customers run.

In my opinion, there are really only two viable options:

- Throw away the i386 port, and tell people that we no longer support
  it;
- Figure out a way for 32-bit binary-only programs to keep working when
  they touch a time_t beyond 2038.

Everything else feels like a waste of effort.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: Best practices for Debian developers who are also upstreams?

[Wouter Verhelst]

On Sat, Feb 08, 2020 at 10:07:48PM +0200, Otto Kekäläinen wrote:
> Hello!
> 
> I've ended up in being both the maintainer in Debian and an upstream
> developer for a couple of packages and I have been fantasizing about
> how to optimize my workflow so that I primarily fix all bugs and do QA
> directly on the upstream development version (=upstream git master)
> and then have only a very small overhead work then importing and
> uploading new upstream releases in Debian.

So, I have four packages that are in various ways similar to this:

- nbd, which I started maintaining in Debian before becoming upstream
  for it;
- SReview, which I started maintaining upstream before uploading it to
  Debian;
- fdpowermon, which I released first by uploading it to Debian;
- ola, which I maintain for Debian and do not really maintain upstream,
  but which upstream did give me commit rights to their repository for.

I have separate upstream and debian branches for nbd; however, if
someone reports a bug, I will fix it upstream first, and then (possibly,
if applicable and it's too soon to release an upstream version)
cherry-pick the patch to the debian branch. There is no debian/
directory in the upstream branch. Updating to a new upstream release for
Debian involves a simple "git merge" of the upstream branch, which will
always work if I never violated that policy. Needless to say, nbd is not
a native package.

I do not maintain separate branches for SReview or fdpowermon. The
difference between the two, however, is that SReview is uploaded to CPAN
as well as Debian. The CPAN upload does not contain the debian/
directory, and I do use the tarball of the CPAN upload as the
orig.tar.gz for the Debian upload. However, they're both built from the
same git checkout. Fdpowermon, on the other hand, I do not upload it to
CPAN (it's too simple for that), and is instead uploaded as a native
package to Debian.

For ola, upstream at one point committed a squash commit of all the
Debian patches I had committed to my debian branch at that point in
time. The next time I tried to merge their newest release by way of the
git tag, things went a bit haywire. I do not recommend this approach.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Y2038 - best way forward in Debian?

[Wouter Verhelst]

On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
> On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
> > Why not? This seems like the type of problem that SONAMEs are made for.
> > What am I missing?
> 
> SONAMEs are set by the upstream developer in their build system

Yes, I am aware of that, thank you. I meant to say that this feels like
something upstream could do a SONAME bump for.

I'm wondering why they chose not to.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Heads up: persistent journal has been enabled in systemd

[Wouter Verhelst]

On Thu, Feb 06, 2020 at 10:45:05AM +0100, Svante Signell wrote:
> On Thu, 2020-02-06 at 07:58 +0100, Vincent Bernat wrote:
> >  ❦  6 février 2020 09:50 +11, Dmitry Smirnov :
> > 
> > > > and 2) continuing to use rsyslog isn't an option if the default changes.
> > > 
> > > No. I just don't want default to change. IMHO rationale for this is weak
> > > but everybody keeps arguing that it would not be a big deal. In time we 
> > > will
> > > see how that goes (what could possibly go wrong?) but why do the change in
> > > first place?
> > 
> > To not have logs duplicated in two places.
> 
> If this is your motivation for the change it is a _very_ weak one, right? Disk
> space is not a crucial problem anymore.

I have been using computers for three decades now. All that time, people
have been saying "disk space is cheap nowadays". Yet all that same time,
my disks have been hovering around ~95% full.

Disk space is, and will always remain, a "crucial problem". If we have
more disk space, that just means people will find novel ways of filling
it up to the brink.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Y2038 - best way forward in Debian?

[Wouter Verhelst]

On Tue, Feb 04, 2020 at 01:14:10PM +, Steve McIntyre wrote:
> So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> need to basically rebuild the world to be 2038-safe. When we had to do
> something like this in the past, to deal with the libc5->libc6
> transition, we had an SONAME change in libc to work with. We decided
> to append the "g" tag to the names of our library binary packages to
> signal that a library was built against libc6. We can still see some
> of the effects of this in the archive, many years later
> (e.g. zlib1g). The problem now is that we will *not* have an soname
> change here to help identify code compatibility on the 32-bit front.

Why not? This seems like the type of problem that SONAMEs are made for.
What am I missing?

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Accepted sreview 0.5.0-1 (source) into unstable

[Wouter Verhelst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 25 Jan 2020 23:21:50 +0200
Source: sreview
Architecture: source
Version: 0.5.0-1
Distribution: unstable
Urgency: medium
Maintainer: Wouter Verhelst 
Changed-By: Wouter Verhelst 
Changes:
 sreview (0.5.0-1) unstable; urgency=medium
 .
   * New upstream release (too many changes to enumerate).
Checksums-Sha1:
 dc806abfedcc15abd4dc027204cd1769e9ac0264 2093 sreview_0.5.0-1.dsc
 e796d5ce363ccb281fad8291072e1dba6415a712 3204614 sreview_0.5.0.orig.tar.gz
 b6b1b5f8034bb2f6a37d950b59998269cdeb529e 61073 sreview_0.5.0-1.diff.gz
 9aadee43f3f446303e3783bfa66488d0b40c2f3c 14524 sreview_0.5.0-1_source.buildinfo
Checksums-Sha256:
 4071076032c6416fdbf9e575d0456d05f0d1785ddbff076cb876b64647df36cc 2093 
sreview_0.5.0-1.dsc
 0679fb579cc67b9f163d109f0a6fbd2736163ce86b7eedc00327bb7c1af404c2 3204614 
sreview_0.5.0.orig.tar.gz
 69469454daac308736869fc114ce1333b0cd3c3245588ca855d15b754eb6144c 61073 
sreview_0.5.0-1.diff.gz
 574fa51ca7cd67e6df4b0a09645b1112a5b411215d9c1843366e92a20f575af9 14524 
sreview_0.5.0-1_source.buildinfo
Files:
 a51df3e6ef4d2583964f9483cd5c02fb 2093 video optional sreview_0.5.0-1.dsc
 b0a7a80971c02333dee99cbe1dd53d45 3204614 video optional 
sreview_0.5.0.orig.tar.gz
 656d1ddf53b5562655268c30f45accaf 61073 video optional sreview_0.5.0-1.diff.gz
 ee55dc5a6e9c07bd565e31ce5cb3781b 14524 video optional 
sreview_0.5.0-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAl4ssgcACgkQLfxRmVQY
EpYNrQ//ayCZKbCOYmty+4iTpwWMqjGCN9jpFdyciljTXn5qiQHsntxf2XhIdfTM
qzGUuUOkHDqmbgwF7d7RQz4OZbKKKVg/HoAHPHdR0Z58JjSrnAlewQjlaSm1x759
OWprKW6zQixxcoeiXrjrfe/PKYb7rRNdrkrp8nkGUdhcfm8byiaDXwB3yZIIxS23
oJv9IPezPPfznhXm4cRVd9Xc3E0zrSKxZCQev2cxyEJXXaSj2ezBAEA1EJaptnrT
JZu3pWj9Kt4yRvBRuyMovwJTu3+wEGUgPO1qPa6KGtya8d7NJXvePC00mkXaZV8b
QJe1rKlRC8JE7XN51tVbzurNrPRr7fv1fuWnjCN3PdJq4wg9QPPMBebAIYguvvFw
kf/9DmrIM1xczpmKLamISNvlY7l2mRdCbd9bj3UsoVM1rpYs9LfLtcj4ovs6fiPO
Atb2aYXJmYLu4CfjOnrsF4MwMqT+BEwKRZutFaERk+VqlvNwIvaDoNXHr3272Zek
2zZ5pcnz7o+kn4+o+kbdF3NcWfwUYZM7cmy4ro0aTkSXfMZ7Dae7zDzKbbC9wYBv
ATCAS9qk2OsA63ETJIF9hOH4h0dMPg8L02eBvbyJda8Z3DKBCGsqh5OkatTew9DY
/VraY8DRvsc8NKQ6Ou0GICjz+AB10DROaZvT9rvV0C6zz3sinJQ=
=op9Q
-END PGP SIGNATURE-

Re: https://tracker.debian.org/pkg/dballe

[Wouter Verhelst]

On Mon, Dec 30, 2019 at 02:47:45AM +, Paul Wise wrote:
> On Sun, Dec 29, 2019 at 11:32 AM Paul Gevers wrote:
> 
> > [1] Source packages that build binaries unknown to the archive currently
> > need these binaries to be uploaded by the maintainers for reviewing by
> > ftp-master in NEW. IIRC there have been multiple proposals to avoid
> > these binaries from either being needed or being uploaded to the Debian
> > archive, but so far the current tooling requires this.
> 
> There has been some recent work on this part of the problem, I
> focussed on throwing away binaries for all sourceful uploads and ivodd
> focussed on doing that for NEW uploads only. Since ivodd's patch is
> further along than mine, I hope he will extend it to all sourceful
> uploads.

You'll make it unnecessarily harder to bootstrap environments that need
themselves to build if you do that.

Throwing it away for NEW makes sense, but not for regular uploads, IMO.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Accepted fdpowermon 1.19 (source) into unstable

[Wouter Verhelst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 11 Dec 2019 09:00:46 +0200
Source: fdpowermon
Architecture: source
Version: 1.19
Distribution: unstable
Urgency: medium
Maintainer: Wouter Verhelst 
Changed-By: Wouter Verhelst 
Changes:
 fdpowermon (1.19) unstable; urgency=medium
 .
   [ Wouter Verhelst ]
   * debian/control: update git URL to point to salsa, not alioth.
 .
   [ Debian Janitor ]
   * Bump debhelper from deprecated 7 to 12.
   * Change priority extra to priority optional.
Checksums-Sha1:
 fff86bdca69f890834d9d424a6b4040c05106c25 1582 fdpowermon_1.19.dsc
 6ff01d3e3ba6c6339c2111e751c833859b550778 23252 fdpowermon_1.19.tar.xz
 6d76b0393b57fc3e19655d7af7f980545ada8102 6535 fdpowermon_1.19_source.buildinfo
Checksums-Sha256:
 b77084e4edc8ab1e8e8636d2777409f96c50e037ccbc4759f9a0cc87d31301fd 1582 
fdpowermon_1.19.dsc
 682f8b2429f330f3740c816b032475ffca0f50fc1b360f5ca214cdcb4bda9b21 23252 
fdpowermon_1.19.tar.xz
 bcc74a675d725ff8b70e52d30ef14eca5a63829f4a37a6f06300f0d9e7709b87 6535 
fdpowermon_1.19_source.buildinfo
Files:
 cb279787ed932ab3899548a898e59a36 1582 x11 optional fdpowermon_1.19.dsc
 5f28b7795e0cafecab3280c5ab554cf1 23252 x11 optional fdpowermon_1.19.tar.xz
 fedc665db77b28bae8a4acda83ff5835 6535 x11 optional 
fdpowermon_1.19_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAl3wlEUACgkQLfxRmVQY
Epb5lw/+MksGeCgx3CwivC1a30OqY8fecoL6T5XYkvoP08q3jPk6P4JQEQapJsl0
PIy2b1xyxVX+tOfOT9fvEfO70jKaq2bHXyoDfqiSAuFy+OOGpYbM5bzViHy+kp4F
pn9rcU/hBCwiOc1gkYqGX+OvBrVfF7YWi0O6AAzLtqAioNVr1KW36m1jlZjwCvNM
c7Hk+cbiiGaTba27WsNp8UwEj3WSNFlLFaOgZVmXDd8BnV2VWKVQvPyWgQ939pl9
qYVnpQjagGmzHPLZU5SECXW2RaaRLyb6gb4C6+qyaFpequCpzZW647v9Ou6ajJCK
9dN6D1SczSjP6+FoDo97CGNdun92A4p4REBjov8iQFHdl5kqsreeEthJ3wYG7ebG
C/ltstmUBoTZIz5qU3ADubjCZvq9i6bMsojshhJ7LsvBXchL7z27os1BuGwqIKnQ
h3frE7c0LiaRA9A1fVV3gC5corxnVIJyZFLvtQbKgw6XjpupnmsyNpxwAQ82RlYe
+NPxVVd2pym6jfSYAYGdu43Z3Itg5lrIL+n6+MJeU80ppMSdXxM9PTBeXWy+q9d6
BV43bgml7McG02+BX4PPZYNGC/E9DuXDxh4cswH89m4o4bndHyLkGUAvCZUuCTgW
OqRuSq1cHnjjwKM+5Jpj9UVCbNt3SJENYIlo4wVfOh+T3gvemyA=
=WdbT
-END PGP SIGNATURE-

Accepted extrepo 0.5 (source) into unstable

[Wouter Verhelst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 04 Dec 2019 11:34:32 +0200
Source: extrepo
Architecture: source
Version: 0.5
Distribution: unstable
Urgency: medium
Maintainer: Wouter Verhelst 
Changed-By: Wouter Verhelst 
Changes:
 extrepo (0.5) unstable; urgency=medium
 .
   * debian/tests/notfound: add
   * ExtRepo::Data: use the LoadFoile method from YAML::XS, rather than
 Load, as the latter seems to sometimes be problematic (and we need
 to dump YAML data to file for gpg validation anyway)
   * ExtRepo::Data: parse gpgv's --status-fd output rather than relying
 on exit state, which is not reliable.
   * extrepo: add "use utf8" to be somewhat more unicode-clean
   * ExtRepo::Commands::Enable: Fix parsing of enabled policies. While at
 it, replace map by a for loop, which seems easier to understand.
Checksums-Sha1:
 48640f1b35521cd3febf3d85b1c631b563ddd022 1536 extrepo_0.5.dsc
 305f9fadee72e61e4af5b104c0fe4c86593c99c2 20156 extrepo_0.5.tar.xz
 f8c86fc974aebc25a9816bab5aeb3c2bbf27cc02 10389 extrepo_0.5_source.buildinfo
Checksums-Sha256:
 2de6be58e9752ee7d9d7b83d35893f120d2bfef79e185616cd35d0eb47b89d1d 1536 
extrepo_0.5.dsc
 068ec2a3b10010c619ce66cfe7771a18de1a96f0b2c8ccbee2881a9a1b1c109e 20156 
extrepo_0.5.tar.xz
 ef5665b975b5c5ccf75d5ce77d327ecdd333578c94cb3f5430094ffa347cede0 10389 
extrepo_0.5_source.buildinfo
Files:
 b5a6233824576edc98fc5addb7cb59fe 1536 admin optional extrepo_0.5.dsc
 b785b5b649db9ae843de6e42ba7dffa6 20156 admin optional extrepo_0.5.tar.xz
 867aef86891928e9b8a9aca1fea2bca2 10389 admin optional 
extrepo_0.5_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAl3nfh0ACgkQLfxRmVQY
EpZ8Lg//bkGmvM2av4vnx1mWsYKflfKml8jjftDkqXobcLU09n0SwGbQ+O7IVj43
pRsBmL0RVXmPRw67pvQ/C94Z9G3pBpul2zW1yFuFY6jLsl5BMSrEUz9DCIf+GKjM
EEYknGlT7pctFjO7HEONk7ASzDeUCrXTzEjM2GKEfzPBwnBkud1PA6L3uuz86bmZ
6gczviQEkZI8leJq/zZqMNhRe1aRQ/pPlL/xTqdqnj2u0Ys076mGhh2jT7RVO4MF
9xBblYyHsIv0zF5c5o/C2x6A2pzQDggxG5HLMxhkfUktxEWhDbmspyX9OUL9IEpd
inhL4U8RwWA99HXq7Jw6OU1KBBXiAly0YE6uMXJa5DbF6wOCJTMM95gEfs72PIQH
7BVGd8vzoDeBzxLydqgKknh6r7rcqLNVJXLFLOZJBT7/OgKflfNY/wEb6fTLzg8b
BqhykPFDCkpq8ya8EsWlC3f7n/Wy3cBSr21o8xKs90leDmaDHFLIef6jCF5Iwboz
/E5A0KewlMTldy7SBdFyEagQCdiXvsfPQAfy4o2iS/G7E7QDzmpDw+G7WRaBsFld
wWoY1q1phFFRM+T0KexBMCJ1zO7J9uvGaTid0cgipZGmKVTCEQxXcXrrHSoc/gN0
8Vmboz8xQlDBxgFHaOlXO6cxwwWymHnwlgq8xphE3UujLfiPh00=
=xMl5
-END PGP SIGNATURE-

Accepted extrepo 0.6 (source) into unstable

[Wouter Verhelst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 04 Dec 2019 11:39:46 +0200
Source: extrepo
Architecture: source
Version: 0.6
Distribution: unstable
Urgency: medium
Maintainer: Wouter Verhelst 
Changed-By: Wouter Verhelst 
Changes:
 extrepo (0.6) unstable; urgency=medium
 .
   * Rebuild with changes listed in previous upload actually working. When you
 build & test on two machines, it's important to keep your git checkouts in
 sync...
Checksums-Sha1:
 c7eaac42f176a95ed2f5650cea2d7d2119a3e550 1536 extrepo_0.6.dsc
 5fea29974cebac713f278dc9c22c6fa9e55ba80f 20264 extrepo_0.6.tar.xz
 e19678dc40e5acec5612089c27f79705c768eb9d 10389 extrepo_0.6_source.buildinfo
Checksums-Sha256:
 c5820fb7b75d961a29598d35e5e99869196b8eefbffe9010bc55ca77184fa1b6 1536 
extrepo_0.6.dsc
 2f00d3fd014412ab008b584f9816c0097998a064953fbd2a03ee1f64fec43459 20264 
extrepo_0.6.tar.xz
 ef0cd41e637858c5e7c03326738f1be750689f7d3ab94b255593347e13f8d151 10389 
extrepo_0.6_source.buildinfo
Files:
 cff4e6514debd096941ffdf60d0cf20d 1536 admin optional extrepo_0.6.dsc
 c7518ebf7ce1c2375801978e6649e70f 20264 admin optional extrepo_0.6.tar.xz
 62b1d4b8854c52883773e84629300d84 10389 admin optional 
extrepo_0.6_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAl3nfzkACgkQLfxRmVQY
EpYZqQ//WrwZuta/kl7W75q0x9xB41LJVunrIGfxsmCuNdeicAIE/R53A9Bcu7zl
Mxu86WMklJCvi7UUZsHtpGPPdS3Kh9/TbHGy0WBACIXMEltbtnWLvFO2d4FKXcja
o/mKWhdAoaYkET1LEjWYPNHALvXBnMpRZfL/90eCJQozgCLJ6HmhsFJMMt9S90Mf
u7o4loq5rBXfqwZz+qUTnPJFV51H5biOHf7Pqu8QrBv9g4Y451CzJgS4PWzfkPAp
cShcTt7cQ6p5jp3NGSkMWtAVCh3TmJctTm8w66N/l10skHDu84rdnsp+1Xkp8s/l
r6zNlcysckngXRwvFYtXXp4m9pxgzDhanAuqCnTaHm19cYpay15OWsI/CQaA3oBj
uVGEW9rEM+GwdVgSymDFalMqhrhJ+koSzBXg8LiZSx4DDI+Zm41TgjHiggSYkmTC
NfSZICdzFsX8soO9CqL61J75i6O9uu0qeeiaX6AkBysE4McWoJIGU5fdZO1FUJYo
o1J1yhWyuAvkYuaySC2qm3SGmMgcIZTQjq1qIWR2lA3ZOfMIIUGBM8GgCq9M7who
I728TAGJlW5L6u8RrqZKi6s7vO/K1RtBn67HY9ltq3DGmGJtDDfWz2eydG2Dyrvj
lR0OzhuTp5ZSAQ9jmYR8IuGdaiPlZYPAjpXb6O6wcpU2b9X+KUc=
=2eMc
-END PGP SIGNATURE-

Re: Namespaces for Lintian Tags

[Wouter Verhelst]

On Wed, Nov 20, 2019 at 09:55:04AM -0800, Felix Lechner wrote:
[...]
> For example, the tag
> 'debian-copyright-file-uses-obsolete-national-encoding' might become
> 'national-encoding@debian/copyright'.
> 
> There are many motivations:
> 
> 1. Shortens tag names.

I do not see how that is a good thing.

"debian-copyright-file-uses-obsolete-national-encoding" is a sentence, which
inherently makes it extremely human-readable. For a tool that is
primarily meant to validate the output of a human, this is an immensely
useful feature.

"national-encoding@debian/copyright" is not very useful in that respect, and is
a huge step backwards IMO.

> 2. Points to the code that issued the tag.

While I can see how that might be useful from a lintian maintainer's
point of view, this is not really of benefit to the majority of users of
lintian.

> 3. Frees up name space (good tags are rare).

This of course *does* make sense.

> 4. Multiple checks can use the same tag in different contexts (i.e.
> 'spelling').

Don't see that as a benefit, tbh.

> 5. Preempts name conflicts in case some check-writing is delegated to
> expert teams.
> 6. Quicker to split large checks when components reuse tag names.
> 7. Brings consistency between Lintian and custom profile users, such
> pkg-perl-tools and pkg-js-tools, who already have private namespaces.

These make sense, I guess.

I guess namespacing things might have some limited benefit, I suppose.
But I like that a plain "lintian" run provides enough context for most
people to understand what's going on, without having to use
lintian-info. Same for lintian overrides.

Please don't break that.

HTH,

[...]

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Accepted extrepo 0.4 (source) into unstable

[Wouter Verhelst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 20 Nov 2019 14:56:28 +0200
Source: extrepo
Architecture: source
Version: 0.4
Distribution: unstable
Urgency: medium
Maintainer: Wouter Verhelst 
Changed-By: Wouter Verhelst 
Changes:
 extrepo (0.4) unstable; urgency=medium
 .
   * debian/control: depend on libdpkg-perl, too
   * debian/control, lib/Debian/ExtRepo/Data.pm,
 lib/Debian/ExtRepo/Commands/Search.pm: change from YAML to
 YAML::XS. The latter is more complete, and is used by the process
 scripts, too; the YAML module can't grok all of the output of the
 YAML::XS module, apparently.
   * debian/tests/*: add test suite
Checksums-Sha1:
 3c81eddbe5f01e943997427060a6b60c0e117dd7 1536 extrepo_0.4.dsc
 2ef545a1f203896b7516668c5ffc5be448440404 19772 extrepo_0.4.tar.xz
 60bf5c39d2a17477ba868e35c0808e7d1fff0bbf 10783 extrepo_0.4_source.buildinfo
Checksums-Sha256:
 17513d6fc3e95f2a7f57e0ab717048e8f2bab4258c397f0698418349eb87b730 1536 
extrepo_0.4.dsc
 0ab2b9a82b3a5b00df623e09055d964605e9dacfd9230ba9cfe11d33de71f33c 19772 
extrepo_0.4.tar.xz
 204449b2639e6572cc99dc17063a35079980edc55ae371853f4a1658a609c871 10783 
extrepo_0.4_source.buildinfo
Files:
 9b179c42150c24df53c9fcf58e3ea774 1536 admin optional extrepo_0.4.dsc
 9b9c37068082ccbe4ab9925f56edf20d 19772 admin optional extrepo_0.4.tar.xz
 9145508779656579147bfb888c06d212 10783 admin optional 
extrepo_0.4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAl3VOFQACgkQLfxRmVQY
EpYHFw//ZI2ApMnCmQfAXblMNzi9wEQBNInQOqnVO7R3VUfX5nZdUH6K7bkoPJuN
PtDFCOAajAKB3MGdu0D3H0vdt/ycW6oCSjr5Z1LysUqHYs8nUdiDmQcHDxDeVk1z
7uZRSbJ1Z9WjF+ulRdYrqH3qfM2jCHOjpbUFQE6HGdjilQczsbmYj6AjV8t3DLl5
yVKH+amy219HinqctecN0WFiqh+BS1DbHj4L7d8fXpkIsUQGf+0R9v8kIAW+C+HZ
JXlxNVlfMsL7RbRxJKzSOEorV/hH/8yJDM1IeptvnQHRP1jQ1jHSkh9WFcWctA44
IA+Wu7Lp4n/tPRD7HWTUgr+JubgrSXBUm/b0y4JwAT9XhJN/TS8Hgw3kd27dWozH
k8DkeRaQOZUursIrcMg1Ca/JsWuBZMbpQ+y1/dLu5ylUVGiW1FKEKHHaX0uGoO6r
6acU6slfvUIAX1vRk2VJDbZGthiY2erSf+feOtCsFEw/FZ+wgYByL/v1qBbgBlGr
CdRj2ynI3yji/Ko++FwvEML2nQ5lcKswMk2z/WxtmR2o7EHp+EDEHYcxMmS7cX7e
EHYPQEjWUMpnYtVlRYeEt6fgmvn0Ljje4smbdjDeDd92scjfs06aPqMLvQi+Cti0
DI3IVuOtQsI8hJuzOpyCMaCgCrqlI3gnvEdvl/b16CqEuC0YQjE=
=R9ZB
-END PGP SIGNATURE-

Accepted extrepo 0.3 (source) into unstable

[Wouter Verhelst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 19 Nov 2019 09:31:46 +0200
Source: extrepo
Architecture: source
Version: 0.3
Distribution: unstable
Urgency: medium
Maintainer: Wouter Verhelst 
Changed-By: Wouter Verhelst 
Closes: 945047 945053 945054
Changes:
 extrepo (0.3) unstable; urgency=medium
 .
   * Add man page for extrepo
   * Fix bug in extrepo search introduced after change of metadata format.
   * Lintian fixes to package description and debian/copyright
   * debian/source/format: Mark as 3.0 (native) package
   * debian/control: add dependency on libcryptx-perl. Closes: #945047.
   * Sync config directory in binary with installed directory from packaging.
 Closes: #945053.
   * Rework comments in config.yaml slightly. Closes: #945054
   * Ship config for bullseye, not buster.
Checksums-Sha1:
 751506680b4092010e0ed5ab7a0a0e11e1a8c2b6 1513 extrepo_0.3.dsc
 26c5b053b6772c5e82d190e0bcf25648545cc9ef 19436 extrepo_0.3.tar.xz
 7fc2f3a9595d3c7f9c166429e1ef511475f9842d 10783 extrepo_0.3_source.buildinfo
Checksums-Sha256:
 6b2a42c361bf3ccfdc3d7ec9a3c0a2beba9be7521bead0a2b508b1d149001f27 1513 
extrepo_0.3.dsc
 a0b3e4adeff1f1072179a45229cd4eb2b4fe12ab24f56e1d488a468ea123c04d 19436 
extrepo_0.3.tar.xz
 d5eb96a30295b5852ce8773c5a6682335586f492afbbec565c86d0accbc989bf 10783 
extrepo_0.3_source.buildinfo
Files:
 63b4314a5e4cc4fbc3271e7b0d59a88b 1513 admin optional extrepo_0.3.dsc
 addfe2703ec4bf488b79b8ab58163bd1 19436 admin optional extrepo_0.3.tar.xz
 ecc7723a638d807451afd5a8e0bab47e 10783 admin optional 
extrepo_0.3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAl3TmvIACgkQLfxRmVQY
Epbb2Q//YbZtorkpW6uMWOFMx6QN+Gz55+g7hDVm7kOVm+1lDuqrwHs9crOr/DFf
BzJxmTanhwNxWY2EQeVGJa1JVs3io2aw1lG4UG5k1WoVucosCK0h35oXtSccCAZf
qYPCEY7YLYpsMSBeO40NXlfh6SNmpiOVcM7cH/wASdnr4yot1paVJyzwBGc8FbGO
Z9iU8PuuMoutt1oTthlh+As9W5LjZtfnbkjB63VO8PixixPxOpMVZDGK7WVl2jFf
SVeaQe6Z/bmScg2qBJehCDwlS9QRbFemxPq7W3aWe+ElzsWppcUek3sbui5xEGHR
vw7o9ZGCMiqQCDO4QnjAFGQ8Dvy7pVcbiaw8ACRub/UlNDLIPPg+GqhpgqJwWCBh
iMMQP4sDldsBlF+I3gNQHfvNsV44gAWQPqLLecPTSv0Nl0slToDLrMT7UvSeUlXp
yoxT9Zqr6hPuFhzp/14WQGeUaodiCxeEnYATrZmlRsObrIfbVvqS+lw76GSHgcAE
Fm5iJlspGhrb3JjbgwgnHGY/TCjJ7tgH52xHrVtkr5bRZG5miu9xuXk5Y7lKvNQ+
iwSQ3PyCnxuUizSzd6swhUbQOoA9VOuJeyg2sKUjs1vITJm9m3P7sp63e2xFHT1H
O8C/uZ5SRPF0bArcr8jlgVmnfvkWG0wpRMmmldxZzE8ClDNgm3s=
=Hk+m
-END PGP SIGNATURE-

Accepted extrepo 0.2 (source all) into unstable, unstable

[Wouter Verhelst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 10 Nov 2019 12:50:00 +0200
Source: extrepo
Binary: extrepo
Architecture: source all
Version: 0.2
Distribution: unstable
Urgency: medium
Maintainer: Wouter Verhelst 
Changed-By: Wouter Verhelst 
Description:
 extrepo- External repository manager
Changes:
 extrepo (0.2) unstable; urgency=medium
 .
   * Bump Standards-Level and Debhelper Compat level.
   * Rebuild with binary. Apparently uploads to NEW require them...
Checksums-Sha1:
 92e451c61f6a387b290a8610a52ac4b76a58f0bf 1504 extrepo_0.2.dsc
 b6a1a23605c9ddffb7111c540bcc2925f0844341 12725 extrepo_0.2.tar.gz
 3425969e6ddf5c7fab870afcc85245098d138982 5864 extrepo_0.2_all.deb
 c0bfb32e7da11e10f33024d0cdbcf7737dedf38b 11004 extrepo_0.2_amd64.buildinfo
Checksums-Sha256:
 65c92c8dc198fddb5e647bb821ac8170e77382f45a731d0262c824a99ebb8b2b 1504 
extrepo_0.2.dsc
 20fc92109b77f87b2075b240a6827ae244e3e41c674f3b869c0d8c43490cf9d5 12725 
extrepo_0.2.tar.gz
 7c7acc7e36d866227a65c5361efd8428aaa1ec8d6248ad3ac3bf5e3e897e9acb 5864 
extrepo_0.2_all.deb
 e23d52da43182e93f68e664926aa6ef89e9383936163ca19a43ecf1a5c66b5e0 11004 
extrepo_0.2_amd64.buildinfo
Files:
 e6dccec95898277962e14950f26d7ee6 1504 admin optional extrepo_0.2.dsc
 07fb36da7434450f0a6883df9d9a5abd 12725 admin optional extrepo_0.2.tar.gz
 50b33b84f7c302f880705e69b614b960 5864 admin optional extrepo_0.2_all.deb
 39cfc57f16910d219f3ecb689dd9fa8a 11004 admin optional 
extrepo_0.2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAl3H7GsACgkQLfxRmVQY
EpZyhA/9F9cPM9/BuJh+a3fZT76tnjF/kdnSIdX6OIK5FGsxDX4UpNnxn+PsAoWH
7rLjVju3l3GwfQbXPYkD0I2FYNxBTgeAoHHNP1+gRIK2I3c5xWG7pcuqnCGLFdKA
3ghAXT7NNTwsXZBXb6A/7KKVVYXtW+a9KI8J3WCulIeSq/zstWQf+3ehUSjF+PFY
99tAL+GLoBSyMNg5DN1X9srT+OviZmW67IL2dC7cunOwXvQzLn2uwvAVPaXMr2TD
EORmdfe7Bj/VtQa+r+iWMO5rHzR4etVAwq8/O6tEmo7kJhM8vIZhx8wOqY+1QDVW
i2J1gwIXapwfFyztz4ZDVSfo2FN5lqCRrwS3G0UsOTnGX4rptiwfSjmjLDAUM5By
nNrHJlUW38MBeaFDOEXdAO4jhDdBvZeR5o3Z8+zEhGmsQb3GPvTzLmcMOQIf/KfT
KCVM3x/GY8vggzdoPRqW7JL4egEAva8DcDSQ/uJPa9E/s8m5gvWsRuLV0yrLbuip
KfRUg07iSqU04ajJOxxwuJpZXM6NxhI77GCs5Z3y74GYZFLOJ/Di+hejF7Sqivvq
m6vMJSxtK/ccAOb9ypnFkeq22SE1wShfjhloPess+NOaI1VR8IfM34lRwhvcQt0M
wt+KPgyMLg7VYf9Yar68Oui6Vg+3fdYYDrT8Duc3wKjPYEoRHvQ=
=hQe2
-END PGP SIGNATURE-

Re: Facilitating external repositories

[Wouter Verhelst]

Hi,

On Sat, Nov 09, 2019 at 07:20:44PM +0200, Wouter Verhelst wrote:
> Hi Timo,
> 
> On Sun, Nov 03, 2019 at 07:33:10PM +0100, Timo Weingärtner wrote:
> > Hallo Wouter Verhelst,
> > 
> > 03.11.19 18:35 Wouter Verhelst:
> > > The software from the package downloads the metadata index and validates
> > > the GPG signature; and if everything checks out, adds configuration to
> > > /etc/apt/sources.list.d and /etc/apt/trusted.gpg.d to enable the
> > > repository.
> > 
> > Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key is 
> > in 
> > there its owner can impersonate the official debian repos for default 
> > setups.¹ 
> > Please use some other path (such as /var/lib/extrepo/keyrings/) for the 
> > keyrings and connect it with "Signed-By:" [1].
> > 
> > I just changed my /etc/apt/sources.list.d/debian.sources to have:
> > Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
> 
> Thanks. I agree that makes sense; I've updated the code as such.

So, that has happened, and I have now also uploaded extrepo[1].

In order for this to acually be useful, I would need a bunch of
repositories to be available through the "extrepo" command.

In order for that to happen, I think the best thing to do (eventually)
would be to have the maintainers of said external repositories to
request for them to be added[2]. We'd then need a vetting procedure and a
set of rules for things to be accepted.

I've created a start for that at
<https://salsa.debian.org/extrepo-team/extrepo-data>. Any comments?

(as a side note, that repository also contains the metadata of the
repositories which extrepo knows...)

Thanks,

[1] https://ftp-master.debian.org/new/extrepo_0.2.html
[2] For the time being though, I've started creating a set of
repositories. I'll probably add more in the next few days or weeks,
as I encounter repositories that might be interesting to add.
Long-term that is probably not the best idea, but short-term I want
to have some critical mass of packages first...

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Facilitating external repositories

[Wouter Verhelst]

Hi Timo,

On Sun, Nov 03, 2019 at 07:33:10PM +0100, Timo Weingärtner wrote:
> Hallo Wouter Verhelst,
> 
> 03.11.19 18:35 Wouter Verhelst:
> > The software from the package downloads the metadata index and validates
> > the GPG signature; and if everything checks out, adds configuration to
> > /etc/apt/sources.list.d and /etc/apt/trusted.gpg.d to enable the
> > repository.
> 
> Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key is in 
> there its owner can impersonate the official debian repos for default 
> setups.¹ 
> Please use some other path (such as /var/lib/extrepo/keyrings/) for the 
> keyrings and connect it with "Signed-By:" [1].
> 
> I just changed my /etc/apt/sources.list.d/debian.sources to have:
> Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Thanks. I agree that makes sense; I've updated the code as such.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Perhaps we're rehashed enough of the systemd discussions?

[Wouter Verhelst]

On Sun, Nov 03, 2019 at 03:26:40PM -0500, Sam Hartman wrote:
> >>>>> "Wouter" == Wouter Verhelst  writes:
> 
> Wouter> On Thu, Oct 31, 2019 at 03:45:47PM +0100, Marco d'Itri wrote:
> >> http://www.islinuxaboutchoice.com/
> 
> Wouter> 
> https://grep.be/blog/en/computer/cluebat/Systemd__Devuan__and_Debian/
> 
> Wouter> -- To the thief who stole my anti-depressants: I hope you're
> Wouter> happy
> 
> Hi.  We've received a lot of feedback about the negative costs of long
> threads here.

Yes.

[...]
> But as someone charged with helping try to facilitate discussions within
> the project, I think this particular set of related threads have reached
> the point of diminishing returns on debian-devel for now.
> If there's some last message you absolutely have to send, get that *one
> last message* out of your system.
> But let's be almost done, out of respect for everyone who has had this
> discussion before and out of the many people who have talked about the
> costs of relatively long threads like this.

I wasn't going to reply to this at first, but...

I'm not sure if you replying to my particular email has any
significance. But if it does, I think that's pretty terribly bad of you.

I replied exactly twice to this whole thread: once to ask you to *not*
prepare a GR proposal in private, *precicely because* announcing you're
going to propose a GR but not actually (yet) doing so has in the past
led to long and very much not productive threads about the general
subject the almost-proposed GR is about. You declined, for reasons that
I didn't agree with (but didn't feel strongly enough about to argue to
death). A second reply was the above one, to point out a particularly
bad style of "argument", of pointing to a URL that kindof okayishly
defends the way one of our competing distributions works, but doesn't
(at least in my opinion) match up with Debian's traditions very well. I
happen to believe that using a bad style of argument in an already-long
thread is not very productive, and I wanted to point that out in a short
and simple way.

So now that you've seen that your actions have caused a huge and
inproductive thread, rather than owning up to that and just doing the
right thing, you're pointing fingers and telling *me* that I'm making a
bad situation worse?

Srsly. Yes, the DPL is supposed to "lead discussion", but no, you do
*not* do that by telling people to shut up when they're just reacting to
*your* mistakes.

Thanks for considering.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Integration with systemd

[Wouter Verhelst]

On Thu, Oct 31, 2019 at 03:45:47PM +0100, Marco d'Itri wrote:
> http://www.islinuxaboutchoice.com/

https://grep.be/blog/en/computer/cluebat/Systemd__Devuan__and_Debian/

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Facilitating external repositories

[Wouter Verhelst]

So, in 2015 I wrote:

> Hi,
> 
> At $DAYJOB, I'm maintaining a few repositories with ready-to-install
> packages for a number of distributions[1]
> 
> Currently, the instructions[2] say to do the following:
> - Download and install an "eid-archive" package, which contains the GPG
>   keys and generates a sources.list.d file for the repository;
> - Run "apt-get update";
> - Install the "eid-mw" and/or "eid-viewer" packages.
> 
> This works, but it has a number of downsides:
> - The second step, "run apt-get update", is often overlooked; this seems
>   to be the case especially for users of Ubuntu, where the default
>   handler for installing packages is the "Software Center", a GUI
>   software management tool that doesn't have any UI element for doing
>   (the equivalent of) apt-get update
> - There is no trust path from your already-installed distribution to the
>   "archive" package (yes, I did sign the gpg keys; no, I don't consider
>   that enough).
> - It still requires users to manually install packages.
> 
> I note that other third-party developers often provide a single debian
> package that can be installed, where the binary package itself already
> contains repository configuration that gets installed. This method
> works for application software, but (as in my case) if the intent is to
> provide a library that wants to support multiarch, this approach doesn't
> work.
> 
> There is add-apt-repository, which presumably works, but:
> - It doesn't solve the "trust path" issue for third-party repositories,
>   (except, *maybe*, for PPA's, but that's Ubuntu, not Debian, so doesn't
>   solve my problem)
> - It doesn't remove the "manually install" requirement
> - I don't believe it solves the "user didn't do the apt-get update"
>   step, although I haven't checked in detail.
> 
> Do we have anything better, or should I try to come up with something
> myself?
> 
> [1] specifically, https://files.eid.belgum.be/
> [2] http://eid.belgium.be/en/using_your_eid/installing_the_eid_software/linux/

This caused a bit of discussion at the time, but no real implementation. Until
now.

I spent some time earlier this week to write, as a proof-of-concept,
, which contains two repositories:

- The first contains an "extrepo" package, that hasn't been uploaded yet
  (and will probably need some more work before that can happen)
- The "extrepo-data" repository contains some YAML files that can be
  consumed by the first package.

The idea would be that maintainers of third-party repositories (or other
interested parties) can file a merge request to add metadata for their
repository to the index file. When, after proper vetting of the
repository in question, the MR is accepted, that metadata then gets
slightly mangled and signed with a GPG key, then published on
pages.debian.net (or somewhere else, if necessary).

The software from the package downloads the metadata index and validates
the GPG signature; and if everything checks out, adds configuration to
/etc/apt/sources.list.d and /etc/apt/trusted.gpg.d to enable the
repository.

(I could also update the "add-apt-repository" program from the
software-properties-common package, and I might do so if this turns out
to be a success; but for a proof-of-concept that seems premature).

Does this seem like a particularly bad idea to anyone?

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: BITS from the DPL For September/October 2019

[Wouter Verhelst]

On Tue, Oct 29, 2019 at 03:19:03PM -0700, Russ Allbery wrote:
> We've now had several years of essentially declining to make a decision
> and trying to see if the project can muddle through, and while I feel
> somewhat vindicated by the fact that this didn't immediately fall apart
> and has sort of worked, I think it's becoming increasingly untenable.  We
> now have contributors who are far-removed from the original debate and who
> may have only used a systemd-based Debian system and we do not have clear
> project consensus that sysvinit support is mandatory in new packages, so
> the support is starting to bitrot, and given the lack of clear project
> guidance, no one is clearly empowered to prevent it from bitrotting.

Hear hear.

While I was reading Sam's message, I was a bit apprehensive about having
a vote about this; but his arguments, and yours, make sense in that it
is a good idea to either tell people we're no longer interested in
multiple init systems as a project, or to empower those who want to work
on it that we, as a project, think it is a sensible idea to do so and
that not supporting alternative init systems should be considered an RC
bug.

(FWIW, even though one of my packages doesn't currently have an init
script where it should, I happen to think the latter is true; but it has
become very clear to me over the past few years that this opinion is far
from common in the project, and that is precisely the reason why this
vote would be a good idea).

Having said that,

Sam: I notice that you've not sent a draft of your GR proposal to the
-vote mailing list yet. It has been my experience over the years that
that is not generally a good idea. The DPL does have the power to bypass
much of the GR procedure, and in urgent situations this is probably a
good thing; but I believe that the drafting of GR ballots in the open on
a public mailinglist is actually an essential part of the whole GR
procedure, which allows people to form an opinion together, resulting in
fewer (but better) options on the ballot.

It is times when we are divided, such as in the case of GR 2004_004,
that this process breaks down and the number of options on the ballot
skyrockets. This is also the reason, I think, why ballots that are
drafted in secret almost always immediately receive amendments as soon
as they are proposed, thereby negating any perceived benefit that they
might have provided.

For that reason, I would like to urge you to draft the ballot in the
open, unless you think there is little time for this and you need to
have something to move forward urgently -- which would be something I
would disagree with.

Thanks,

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Accepted policy-rcd-declarative 0.3 (source) into unstable

[Wouter Verhelst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 29 Oct 2019 18:49:29 +0200
Source: policy-rcd-declarative
Architecture: source
Version: 0.3
Distribution: unstable
Urgency: medium
Maintainer: Wouter Verhelst 
Changed-By: Wouter Verhelst 
Changes:
 policy-rcd-declarative (0.3) unstable; urgency=medium
 .
   * Add "clean" override, so that we don't ship pre-built files
   * Avoid hardcoding Perl RE syntax, and use re::engine::RE2 as regex
 engine, so that we can switch to another language easily in the
 future should we want to.
   * Upload to unstable
Checksums-Sha1:
 10c718761cba1f44bc26c212eb519a8189d7b9c2 1589 policy-rcd-declarative_0.3.dsc
 714e9b35e3527158c946f236c0aa384f9af1ab65 5096 policy-rcd-declarative_0.3.tar.xz
 3ebb1d3127d41a1728d05ea89cc71d8f432b7156 6668 
policy-rcd-declarative_0.3_source.buildinfo
Checksums-Sha256:
 d934ebe36b83c522d7cae5661b442339c1af2a37025a1d1ea1321a3c2a04e94f 1589 
policy-rcd-declarative_0.3.dsc
 ada37373be5ee0b1493f21bc34c290e159289bf8c8c15d643f6e562614dca2b0 5096 
policy-rcd-declarative_0.3.tar.xz
 94b736f5acac02354af1b24f650c0fe013b201a43415697bd608650c4d8be5fe 6668 
policy-rcd-declarative_0.3_source.buildinfo
Files:
 b234d20385d3f8fa51c39fc83ed5a627 1589 admin optional 
policy-rcd-declarative_0.3.dsc
 5ae51e137da11132a12fb17bfaf77936 5096 admin optional 
policy-rcd-declarative_0.3.tar.xz
 35dcf8399909b408f238408976226a52 6668 admin optional 
policy-rcd-declarative_0.3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAl24dbUACgkQLfxRmVQY
EpZLAw//ZsYboNlQJb4vb/ixWBGZqXVkgSd6vXJ/MtK+6UHwpK+22VSrvx/QVx63
jZW4d2V4SY4Jip1AafFiAR25FhcI/CS/jigVNc1IJxnDRVbvfgmmXtXPyyrXopP4
QVFXI3WqTgf7Tfq0CFqc3A0Umu+KPTVDRF2cB0IUT4O3oZtUk3Q/gPJNfsZwKRjc
apa5IWVBaM42RkOX+7uLFwzLEPG9SULHA6JKbhHdx2Jgcu/sYaNWAbG/D0LH3XQ4
mRZyO+t7QFoxIOQbdfA4ts7yVsy1HoO68+XIIk3scDHqpPPGtiCPUv/bXGTF74Ak
rv3+BhJV4bCZDnzOt77SWnuuiawSpGsKgt50OdY5yDIdZoiXgtxy7DY7IQLHqHfk
DocdPgahLg/HIYrUPqjSpWVbJZQ1nR34mCg8cTJU9QS+CQWxCU2KiSkQ7e7/Lr6W
zFkvBDWJ/ssuaz1Vk3YXWTXUVsXCNk3EYtAPdNnM0/A+twzkdRy/MKuX1wg+Rq5M
jgo8D5I3msKIM3LK7ruMeUBRtkIx60l2p0EEbUN7W6/s/XSN7pPR5kTNKzDl45Vo
1x79x+lZGpwi70wPr2pod5ylDNZtIef0nVb7l74wPSRKffvHNAhgi/F4+E1LuHE+
ACxo/i+bu+hzLOQf6TT5bbW/qf+cO7/eVTYmhLl7rq4XvD0nosc=
=uQZB
-END PGP SIGNATURE-

Re: Bits from the DPL (August 2019)

[Wouter Verhelst]

Sorry about the lateness here, been busy...

On Tue, Oct 01, 2019 at 12:22:34PM -0400, Sam Hartman wrote:
> > "Sean" == Sean Whitton  writes:
> 
> Sean> You might separate your detailed, narrative descriptions of
> Sean> how discussions went from what you took away from the
> Sean> discussions.  You could either drop the former, or put it in a
> Sean> "read this if you want more details" section.
> 
> I've found that if you do that, people get surprised and upset when it
> is not obvious how you got to a decision.  Basically I've found that
> enough people are upset without a narrative that you get much more
> overall mail and less confidence in the process without.
> 
> I do organize my mail so people can skip sections, and I do try to
> consistently put the conclusions after the narrative.

That's great. It does help to be explicit about it then:

"if you're short on time and/or not interested in the details, please
skip ahead to the conclusion in section XYZ".

I did miss that in your most recent "Bits" email, and I do think it
could be useful for those of us who are short on time.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Accepted nbd 1:3.20-1 (source) into unstable

[Wouter Verhelst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 16 Sep 2019 09:05:42 +0200
Source: nbd
Architecture: source
Version: 1:3.20-1
Distribution: unstable
Urgency: medium
Maintainer: Wouter Verhelst 
Changed-By: Wouter Verhelst 
Changes:
 nbd (1:3.20-1) unstable; urgency=medium
 .
   * New upstream release
Checksums-Sha1:
 82e2740e511d6e835cb0e563ddc7a974bcf24659 1972 nbd_3.20-1.dsc
 54545f59d8bc938103e680601b5d56ffdf18f3b2 1058878 nbd_3.20.orig.tar.gz
 1ce6e24cb0c82219c7490f8060cfd631da243940 89905 nbd_3.20-1.diff.gz
 21c7e1c9ce8d6a106039010a731abca12da0459c 11710 nbd_3.20-1_source.buildinfo
Checksums-Sha256:
 86ffbfc61bda49e1a486436df262879bdf09e4de52e5009a31ac55bf9d2d8b7c 1972 
nbd_3.20-1.dsc
 b6a82acbc9b1085534820dbc0d23ddbc39b7970e587e6930aec97e262feb222b 1058878 
nbd_3.20.orig.tar.gz
 39cc47b0e6c70190e3b6a302bfb48b5b779178376e2ea573afb0316cdf94adc8 89905 
nbd_3.20-1.diff.gz
 34bcb2bbd2d36c47a98285ffbca8ec09745595a0bab2976aeadc215fcdea62bb 11710 
nbd_3.20-1_source.buildinfo
Files:
 953e6df8ac6ca7c9c163c917d134893d 1972 admin optional nbd_3.20-1.dsc
 9139b0224da18d99b83a7af01deb8f70 1058878 admin optional nbd_3.20.orig.tar.gz
 a8c65c9e2fea764f521e39914f0c6580 89905 admin optional nbd_3.20-1.diff.gz
 084c76a3fa65ec792f535ba8196c4b75 11710 admin optional 
nbd_3.20-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAl1/N5QACgkQLfxRmVQY
EpZ9NQ/8CU7dLTm9dBAs9AVYCNS+aAfR/uewHFfi47A7GbN3cVIzxWfecRgXlLkb
2gD067Vcp+DT/sJZ0Sk8yO8VoNO6SThdzZcl3okBtJMITpveUt7xNjGqKwTAr36P
fEUzYdkCrbEP7swjl+4zb9PxCz8IGNoaMk1r+wlXPxpy2gms1U2oS9D9cmPSGRBL
HAfzGcwtCxCGaWQJz+eHCLLsP94w7inwUcvibWYkMJqinVJCwDE6iD2a3XscS2ZK
7HTMrVyO0YrC6ids/pmBpkpkt3S/bZ6djLCSgFujyBmrdU1kIYAY0Jz9WtLFhnm4
nSqXjP9TcBnYZ7XEvWWVQyfckF7Ze9VKTmsWzk3jmQNg5m0rqsBSR3YEb1WzfQzl
3I+TceWHXSJ/U36j+o6JyOOptjKhlvuEc5baXCkQcvY2HGG4kAfRrfPYcVU7DkSI
VnxI73GYIzo/0pEGCLU/66b9f/cdLHQva+D+BsGGkCVVO7of3P7G20Ii2wkwwYxM
Buo94bboT/G0aYZ7E4ESZ1N6cLfglf2tJt8ZvHDkRbXB61yr62vZJHvJZjAVeCaI
el/FR0QK1EiQpsnk0lmmT5wQ26Z3Bqf0CCaq5xWqAJNUQ5UCQNB0NzOk0pmLEzee
xPsz/t+zYXmCcn477cl1pglmqMXAJmjwjQNYxug2AlvWPmBbc8w=
=Yi84
-END PGP SIGNATURE-

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Wouter Verhelst]

On Sun, Sep 15, 2019 at 01:16:26AM +0200, Thomas Goirand wrote:
> On 9/15/19 12:06 AM, Scott Kitterman wrote:
> > There's nothing that requires you to interact with a VCS repository that 
> > you 
> > don't care to.
> 
> But I do care about using Git, and interacting with other DDs using it.

Cool.

> However, basically, what you're saying is that, for those who care about
> not using non-free platforms, we should just not do that anymore, as
> it's not required anyway.

No.

If this were about a non-free Subversion hosting service, then yes, I'd
agree. But we're talking about git here, which is a distributed VCS
service.

If you don't want to deal with a non-free hosting service, you can:

- Clone the git repository.
- Push it to the free git hosting service of your choice.
- Push a branch to that git hosting service with the changes you wish to
  make.
- Use git request-pull to send a pull request to the maintainer.

(Alternatively, if using salsa, for the first two steps you can use the
"mirror repository" feature of GitLab)

> That's simply not fair: I care more about software freedom, and
> therefore, I'd be left aside, not being able to use Git when
> interacting with others.

Except you're not.

The above will require that the maintainer on the non-free hosting
service do some more work, yes; that's correct. However, "git
request-pull" will explain to that maintainer how to do that work, and
it's their own fault for using a non-free service to begin with.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Wouter Verhelst]

On Sun, Sep 15, 2019 at 12:01:24AM +0200, Thomas Goirand wrote:
> It is a real life experience that I had to touch horribly maintained
> packages by unknown contributors, with Vcs-Git:
> https://github.com//, missing commits not matching the
> archive, and no response from the maintainer to the BTS (even for RC
> bugs). The last occurrence of this was pyroute2, which I pushed into the
> DPMT (and still no reply from that past maintainer). I hate seeing this,
> and don't want this anymore, though it happens again, and again, and
> again. So, the only way to get out of this is enforcement, like it or not..

I resent the implication that Vcs-Git: pointing to github.com implies
badly maintained packages.

Badly maintained packages can also have a Vcs-Git: pointing to
gitlab.com or salsa.d.o. Same for ignored bugs in the BTS, unresponsive
maintainers, or incomplete git repositories. None of this has anything
to do with the git hosting service in use.

Enforcing things can help in avoiding those issues, but then make sure
you enforce the correct thing. "Stuff must not point to github.com" is
not that.

Instead, we could make it policy that:
- incomplete git repositories should be considered an RC bug
- RC bugs in the BTS will get your package removed from Debian
- Badly maintained packages will result in RC bugs
- unresponsive packagers will get their packages removed from them.

Luckily we already do most of those.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Wouter Verhelst]

On Thu, Sep 12, 2019 at 11:43:33PM +0200, Marco d'Itri wrote:
> On Sep 12, Wouter Verhelst  wrote:
> 
> > Except all they need to do is return NXDOMAIN on the
> > "use-application-dns.net" domain, and Presto! they can spy on their
> > users again.
> They need to have a government to compel then to do it, which is not 
> obvious.

That's not in the announcement. In fact, it also allows for "opt-in
parental controls", which has nothing to do with governments.

> And then Mozilla will disable that (you can read this clearly 
> in their announcement) and figure out a different strategy.

The announcement does indeed mention that, yes. I sincerely doubt
they'll actually do that, though, unless more than, say, 50% of the
networks they measure end up disabling things.

Of course that's just a matter of personal opinion.

> > Meanwhile, Firefox' default sends everything to the other side of the
> > Internet without the user's consent. How does that improve privacy?
> Not really "to the other side": Cloudflare's resolvers are highly 
> anycasted.

I admit to using some hyperbole here, but the point was that your data
is being sent to a partner of the software you happen to be using,
without you having a contractual relationship with them.

If your bank did that, you'd yell that it's improper. So why is a
browser allowed to do so?

Don't get me wrong; I applaud Mozilla for trying to make encrypted DNS
the default. I just don't think they're going about it the right way.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: How to give back a build

[Wouter Verhelst]

On Thu, Sep 12, 2019 at 07:02:15PM +0200, Jeff wrote:
> The package I uploaded yesterday failed to build[1]. In the buildd, 2 of
> 1000+ tests failed. Of course, I built in a clean sbuild for sid before
> I uploaded it, and the same package built fine on the newer Ubuntu
> distros on launchpad. So I'm hoping it was just a glitch, and I'd like
> to retry the build, but my search engine foo is failing me.
> 
> How can I give back the build?
> 
> Or will it retry automatically?

You ask the wanna-build maintainers, or the build maintainers of the
architecture in question.

There's the debian-wb-team mailinglist where such requests can be sent.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Wouter Verhelst]

On Tue, Sep 10, 2019 at 07:56:48PM +0200, Julien Cristau wrote:
> On Tue, Sep 10, 2019 at 08:24:03 +0200, Ondřej Surý wrote:
> 
> > > On 9 Sep 2019, at 15:31, Bjørn Mork  wrote:
> > > 
> > > I for one, do trust my ISPs a lot more than I trust Cloudflare or
> > > Google, simply based on the jurisdiction.
> > 
> > While I still strongly agree with you on this one (even though I think all
> > major ISPs here are scumbags, especially the incumbent), I still strongly
> > think we should not have this debate here, and we should turn this around
> > the usual Debian policy - to not send data to 3rd party without explicit 
> > user
> > content and defaulting to not doing so.
> > 
> How is this worse than what we're already doing by default, namely
> sending the same data to whoever happens to be on the network, in
> addition to whoever happened to be listed in an unauthenticated dhcp
> response?  (Which, if you're lucky, is your ISP, aka a 3rd party.)

The major difference is that third party is someone you've got a
contractual relation with.

If you're talking to CloudFlare, you don't. Good luck calling CloudFlare
support when something goes wrong.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard