Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Sat, 3 Aug 2024 at 12:39, Sebastian Ramacher  wrote:
>
> On 2024-08-03 12:20:09 +0200, Paul Gevers wrote:
> > Hi
> >
> > On 03-08-2024 11:58, Luca Boccassi wrote:
> > > > On the use of tpu:
> > > > Personally, until now I fail to see enough value of being able to
> > > > distinguish unstable and testing to give the package carrying
> > > > /etc/os-release a permanent exception via tpu.
> > >
> > > Thanks for chiming in - assuming for a moment that it is decided that
> > > the change will be implemented, do you see any technical obstacles in
> > > using t-p-u as proposed?
> >
> > The biggest reason I know against using tpu is that it currently isn't
> > receiving the same amount of testing (be it automatic (autopkgtest,
> > piuparts, in the future reproducibility) or human) as unstable-to-testing
> > migrations receive. For the automatic part, that's obviously a solvable
> > problem (and already on my todo list for YEARS), but currently not the case.
> > It also *always* requires human intervention by the Release Team. Another
> > issue issue with tpu is that binNMU'ing is more difficult (I assume that's
> > probably not very often relevant in the current case). I recall there are
> > more issues with tpu, but I have forgotten them. When I find them, I'll add
> > them.
>
> To add to that: tpu is used for exceptional cases only. Cases where we
> deem the result of the upload more important than the additional
> work required of a release team member. Cases where we deem RC bugs
> potentially introduced by missing QA for tpu uploads less severe than
> the issue we are trying to fix in testing. Essentially, if it is not a
> critical bug (think xz incident critical), going through tpu during non-freeze
> time never happens.
>
> For a package that is part of the essential set, having all the QA tools
> checking the consequences of the inclusion of this a package is really
> essential. Skipping out on QA checks for an essential packages that
> would normally run for typical unstable to testing migration puts even
> more pressure on the release team to make sure that accepting the
> package from tpu does not severly break testing.
>
> (As side note: in essentially all cases where I handled tpu uploads
> (that I remember) during non-freeze time, it was more effort to untangle
> unstable so I have asked maintainers explicitly to perform tpu uploads.)

In the generic case, sure, I see all of that making perfect sense.
This though is about one very specific and narrow case: an arch: all
package with a single, fixed and inert text file, that differs by one
line. No maintainer scripts that run on install/upgrades and could
fail, no programs that run on install, no dependencies that might not
be available or installable, one reverse dependency for one cycle to
ensure installation in existing images and then it will be removed.
And it's one upload at the beginning of a cycle, and then it stays
as-is for 2 years until the next, so there is no continued effort nor
need to watch it. At each cycle there is a lot of work to do to
prepare the next testing pocket I imagine - creating new aliases and
whatnot, so in the context of that and compared to the size of that
work, this appears to me as a minor addition, no? Which is not to say
it's nil or doesn't require any effort ofc. The QA effort I see is:
diffoscope old.deb new.deb and verify the difference is only in the
changelog entry and the VERSION_CODENAME= field. For this specific and
precise use case, do you see the requirement for any other QA effort
on top of this, and if so could you please clarify what it would
entail?

> Also, we have been pushing to keep testing and unstable as close as
> possible. Packages not migrating for some time are considered RC buggy
> to reduce the difference and where Paaul is thankfully filing the
> corresponding bugs. Going through tpu would essentially introduce a
> package that is auto-RC buggy in the essential set with consequences: it
> causes even more divergence for autopkgtests in testing (reference
> tests), in testing + pinned packages from unstable for migration checks
> and in unstable. That would cause potentially even more work (for the RT
> and maintainers) to figure out why some test is failing in one
> configuration and not the other.

I deal with fairly complex autopkgtest in debci all the time, for
systemd and related packages. The differences between testing and
unstable at any given time are so massive due to things like the
kernel having a fast development and upload cycle with lots of point
releases, a one line difference in one text file seems extremely minor
compared to the mountain of other things that are ongoing at any given
time. For example, right n

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Sat, 3 Aug 2024 at 11:20, Paul Gevers  wrote:
>
> Hi
>
> On 03-08-2024 11:58, Luca Boccassi wrote:
> >> On the use of tpu:
> >> Personally, until now I fail to see enough value of being able to
> >> distinguish unstable and testing to give the package carrying
> >> /etc/os-release a permanent exception via tpu.
> >
> > Thanks for chiming in - assuming for a moment that it is decided that
> > the change will be implemented, do you see any technical obstacles in
> > using t-p-u as proposed?
>
> The biggest reason I know against using tpu is that it currently isn't
> receiving the same amount of testing (be it automatic (autopkgtest,
> piuparts, in the future reproducibility) or human) as
> unstable-to-testing migrations receive. For the automatic part, that's
> obviously a solvable problem (and already on my todo list for YEARS),
> but currently not the case. It also *always* requires human intervention
> by the Release Team. Another issue issue with tpu is that binNMU'ing is
> more difficult (I assume that's probably not very often relevant in the
> current case). I recall there are more issues with tpu, but I have
> forgotten them. When I find them, I'll add them.

Thank you. For this particular case: there would be 2 uploads for
every cycle, one at the end to add version numbers (this already
happens, no?), one at the beginning to change the VERSION_CODENAME. I
think from the point of view of requiring manual labour it should be
pretty lightweight compared to the current workload of managing
stable-p-u, at 2 uploads to review once every ~2 years, right?

For the binNMU side, this would be an Architecture: all package, so it
doesn't apply I think, right? It wouldn't be subject to any binary
transition for library bumps or things like that. In the current
proposal I am putting forward it's a binary arch: all with a single
fixed arch-independent text file in /usr/lib/ and a single fixed
symlink in /etc/ to the file in /usr/lib, no maintainer scripts
whatsoever, no dependencies.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 21:06, Sam Hartman  wrote:
>
> >>>>> "Luca" == Luca Boccassi  writes:
>
> Luca> On Fri, 2 Aug 2024 at 13:00, Simon McVittie  wrote:
> >>
> >> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
> >> > To further clarify why the status quo with
> >> VERSION_CODENAME=trixie in > sid is really bad: it used to be
> >> that if you had "debian" mentioned in > os-release but no other
> >> version identifying fields, you knew you were > on testing OR
> >> unstable and you'd have to deploy horrendous hacks to > attempt
> >> and figure out which of the two it was really.
> >>
> >> OK, I think this is progress:
> >>
> >> What is the scenario / use-case in which it becomes necessary to
> >> distinguish between those two suites?
> >>
> >> To put that another way, what external piece of software needs to
> >> change its behaviour, dependent on whether you are running
> >> testing (of an unspecified datestamp) or unstable (of an
> >> unspecified datestamp)?
> >>
> >> Or perhaps you are thinking of a scenario in which a *person*
> >> needs to change their behaviour, dependent on whether they are
> >> running testing or unstable?
>
> Luca> Are the examples I provided at:
>
> Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43
> Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5
>
> Not to me.
> I read what I think is the examples you linked from both bug reports.
> I didn't dig too far into the github links you provided though.
> What I see from your mail is that people want to distinguish unstable
> from testing and have created various hacks to do so.
>
> What I do not see is a compelling explanation of why Debian as a project
> wants to encourage that distinction.
> I agree that people doing a thing is evidence that it has value to those
> people.
> But I do not think you provided an explanation of what that value is.
>
> If it were easy to distinguish testing from unstable, why would I want
> to do that?

I don't see any of this being about "encouraging", because, as
mentioned in a previous mail, this is already how things work, and it
doesn't need any encouraging. It's about simply recognizing that this
is how everything already works, and changing 5 characters in a text
file that will have no repercussion on how these are used. Because
once again, I can do:

debootstrap trixie foo
debootstrap sid bar

foo and bar are different images, with different policies and
different lifecycles.
foo is currently in development, will freeze and then become stable
and security supported, and then move to LTS, and then be EOL. It is a
development-to-stable-to-eol image.
bar will continue being a development image, will never freeze, will
never become security supported, will never become LTS, will never be
EOL. It is a rolling image.

These details are what os-release is about, if you read the spec,
there are tons of fields about lifecycle management of an image, with
support and so on.

I am not describing a proposal here, I am describing how things work
and have always worked.

If you are asking me _why_ other people use the above how they use
them, well, I don't know? Unfortunately I left my Cerebro helmet in my
other coat. What I can do is show that it happens, it's always
happened, and it will very likely continue to happen. And what I am
highlighting is that we are the only distro that makes it hard to do
it, and I am highlighting that a specification (that I am one of the
owners of) is implemented incorrectly since it says A is B. And I am
asking to fix it so that A says it's A instead, and B continues to say
it's B as it does today.

I can say why _I_ do it though: because I regularly build and manage
multiple images, and I can correctly identify all of them based on
standard distro-agnostic tooling, but not Debian unstable, which is
the _only_ exception that requires annoying kludges to be used.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Sat, 3 Aug 2024 at 10:51, Paul Gevers  wrote:
>
> Hi,
>
> [Release Team member hat on, but I only voice my opinion as a member].
>
> On the use of tpu:
> Personally, until now I fail to see enough value of being able to
> distinguish unstable and testing to give the package carrying
> /etc/os-release a permanent exception via tpu.

Thanks for chiming in - assuming for a moment that it is decided that
the change will be implemented, do you see any technical obstacles in
using t-p-u as proposed?

> On Debian version numbers:
> I my view we only assign version numbers the moment we release. You can
> see that reflected in the symlink layout of debian/dists and in the
> trixie/Release file.

Understood, thanks for providing that additional information - then as
mentioned in another reply, I am changing the request from what it was
originally stated in the initial email that opened the bug, and I do
not request that version numbers be added to testing. The
implementation I am then requesting to rule on is defined in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43 and, in
practice, results only in a change to unstable, testing's content will
remain as it currently is, with no change at all.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Sat, 3 Aug 2024 at 05:23, Sean Whitton  wrote:
>
> Hello,
>
> Luca is the upstream maintainer of the specification, but whether and
> how the specification as published applies to Debian is not simply up to
> his assertion.

To be really really precise, what I asserted is that the
implementation is currently buggy in unstable, which is technically
correct. I then _ask_ for a ruling to change the implementation. As
already mentioned many times in other mails, one is perfectly allowed
to say "this bug should not be fixed", "this bug's severity is nil",
but not to say "this bug does not exist". To repeat the same example,
if os-release was a program asserting on the state, it would run
correctly on testing, and it would crash when run in unstable. One can
say it's wrong that it crashes and one wants the state to remain
as-is, but one can't say it doesn't crash, because it is a fact that
it does, not an opinion. Both of these things can happen at the same
time and be both true: the TC rules that the os-release file in
unstable will remain as-is, and os-release implementation in Debian is
buggy. A bug report can be closed by an upload that changes something,
or by a close+wontfix.

> The TC is being asked to override how Santiago has determined the
> specification applies to Debian.
> The Release Team's opinion is as relevant as Santiago's, I think.

Everybody is welcomed to chime in at any time, and I have already said
so on RT's IRC channel the other day just after opening this bug.
On the matter of formal ownership however, I want to highlight that,
as you can see in various replies detailing the precise technical
solution that could possibly be implemented, there are _no changes to
testing_ being proposed here, in case what you are worried about here
is ownership of testing and changes to it. The only change would be in
unstable, and as far as I understand (I might be wrong, please correct
me) RT owns testing and [old]stable, not unstable. If you want to
ensure the owner of the relevant area is directly involved, then
perhaps it's the FTP team that should be, since as far as I understand
they are the owners of unstable (might be wrong here too)? Again,
everyone's welcome to chime in at any time, just trying to clarify
who's responsible for what here.

> Here is how it seems to me:
>
>   - the specification applies cleanly to our stable releases, and we
> want to support it, so we ship the appropriate metadata
>
>   - it applies to testing during the later stages of the freeze, and
> indeed we ship correct metadata at that time
>
>   - it does not apply to testing the rest of the time, and it never
> applies to unstable.  We ship metadata, but only as a side-effect of
> our process for preparing stable releases.
>
> If this is right, then the goal should not be to ship correct metadata
> in testing and unstable, because that's impossible.
> The goal should simply be to make whatever we ship in testing and
> unstable relatively unobtrusive to users.

If I understand correctly what you mean by "apply" here, and you mean
in terms of the specification and what it is meant for, then as one of
the owners of the spec I can say with certainty that the spec applies
to testing and unstable, at any time. There is nothing incompatible
with the way testing and unstable exist, are created, handled,
maintained, used or anything else, and they are nothing "special"
compared to other distributions, other than in the fact that the spec
is not implemented correctly in unstable. There should not be any
doubt on any of this, solely from the point of view of what the
specification is for and what its goals are. One can of course
disagree on whether it should be implemented as such and where, which
is what is happening right now.
If you mean it in terms of what is currently implemented in Debian,
then that's also inaccurate: the spec is currently correctly
implemented in testing, where it says VERSION_CODENAME=trixie at all
times. It is incorrectly implemented in unstable, since also there it
says VERSION_CODENAME=trixie, which makes it buggy, as sid is
obviously not trixie, and that's the main change I am asking to
implement. I'll note again that it is perfectly ok to omit VERSION_ID
until release time, and in one of the replies I am clarifying that, if
there are reasons to leave it out, it is ok to do so, and I am not
asking the CTTE to overrule that.

Also, speaking as someone who has worked on image building tools for
many years, the current state is extremely intrusive for users, and
that's why I am trying to fix it.

> Possibly it's less obtrusive to always ship "trixie" in both testing and
> unstable, rather than the special "trixie/sid" value.  Or maybe not.
> Santiago doesn't think so; it would be good to hear why, in this bug.
>
> I'd also like

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 18:01, Russ Allbery  wrote:
>
> Simon McVittie  writes:
> > On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
> >> Luca Boccassi  writes:
>
> >>> It is correct as-is. VERSION_ID is meant to identify a release, not
> >>> updates or point releases. A release as in, Debian Bookworm, or Fedora
> >>> 40, or Ubuntu Noble, and so on.
>
> >> Why would you not want to identify point releases?  This really
> >> surprises me.
>
> > I think the idea is that two releases have a different VERSION_ID if and
> > only if they can both be fully up to date, but still remain
> > different. If we make the analogy of git, VERSION_ID labels a branch,
> > not a tag.
>
> Oh, thank you, this was not at all obvious to me.  If this is indeed the
> case, that would be a useful clarification to add to the specification.
>
> This also explains the desire to identify testing as trixie, but not
> identify unstable as trixie.  If one configures a testing system to point
> to trixie, then fully updating it will move it into the stable release
> when the stable release comes out.  However, if one points a system at
> unstable, that system will never become a trixie system and will always
> continue to point to a different release.
>
> This is not an entirely clean analogy, since it's also possible to point a
> system at the testing suite directly, rather than using the code name, in
> which case that system will also never become trixie.  So in that sense
> testing is simultaneously both trixie and not trixie depending on exactly
> how you configure apt.
>
> This sort of ambiguity is, I think, part of why this proposal generates so
> much discussion.  Debian simply doesn't currently have clean semantics for
> testing.  It exists in a sort of quantum superposition where it is
> multiple things simultaneously for different people, and this proposal is
> trying to label it in a way that collapses that state to match the mental
> model of one group of people, invalidating the mental model of a different
> group of people.

If you instantiate it as 'testing', using that keyword through your
configuration, including apt, then it will be updated to the next
version when that is created in the archive. So it is still trixie
today, and tomorrow it will be forky, and everything, including the
os-release file, will be updated accordingly with my proposal.

>From the point of view of the os-release specification, this is
exactly the same as using 'stable' to build and manage an image. Today
that is bookworm, yesterday it was buster, tomorrow it will be trixie.
It is still correct that today os-release says it's bookworm. Once it
is upgraded, the os-release will be upgraded too and say 'trixie'
because that's released and that's what the 'stable' alias points to.
It's the same installation, and it gets upgraded to a new release -
that's entirely supported by the os-release spec. That's the same if
you are tracking 'testing'. And that is why in my very first mail at
the top of this bug, I said that testing is _not_ a rolling release,
because there's a -1 and a +1 and it has a limited lifespan. Support
status is different than stable, but there are other fields to
indicate that, and again it applies just as well to oldoldoldstable.

So again, while I see why there could be different points of views and
some confusion around what means what, my view is that this proposal
doesn't really introduce anything new, and doesn't change anything
that happens today in any fundamental way. As already mentioned, I do
not see anything fundamentally incompatible between the os-release
concept and the unstable or testing concepts as they are today,
whether they are considered with their codenames or the aliases.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 17:07, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > That's yet another Debian-specific workaround. The point of this is,
> > again, answering the question "what is this vendor tree" _without_
> > distro specific kludges. That's the entire reason for os-release to
> > exist. If the answer at any point is "check os-release AND THEN run this
> > distro specific set of scripts or binaries", then the answer is wrong,
> > and the implementation of the spec is buggy. Again, one might say "I am
> > ok with this being buggy because we gain X Y and Z in exchange", but
> > buggy it is and buggy it will remain.
>
> This talk about "buggy" and "workarounds" didn't help me understand what
> you meant, but I think what you're saying is that I'm right, you *do* only
> care about the apt configuration, BUT apt is Debian-specific and figuring
> out how it is configured is not something that can be done portably, so
> you do want to use os-release as a proxy for that information because it's
> a cross-distro tool.
>
> That makes sense to me.  It's a fallible proxy and it will get a bunch of
> edge cases wrong, but it's probably not possible to do better with an
> equivalently simple tool.

Right, but one important correction though - it's not _only_ apt, it's
_also_ apt. Apt is one of the common issues, yes, but it's not the
only one. It is entirely valid to create an OS vendor tree without apt
or its configuration, for a minimal read-only image deployment for a
VM or a container, that you update with an image-based tool with A/B
style partitioning, for example. How do you identify such a vendor
tree? There's no apt. The answer on every other distro is: read
usr/lib/os-release. In Debian it's: read os-release and pray the old
gods and the new that it returns something identifiable, and otherwise
just despair and take a wild guess.

> Fundamentally, you want to change Debian's policy about testing to
> complete the separation from unstable and treat it as a first-class
> release in its own right in our metadata.  Debian has historically not
> done this and generally discouraged people from doing this (this is *not*
> just Santiago's position; Santiago is correctly reflecting the previous
> consensus of the project), but there's always been a fair bit of
> controversy over that point, and I personally tend towards the side that
> thinks testing can be usefully treated as a rolling release with very
> substantial caveats and limitations.
>
> I do agree that it's often useful to be able to quickly determine if an
> image is pointing to testing or to unstable.

I see what you are saying, but I have to say that expressing it like
that makes it sound like I am asking to flip the thing on its head
completely, and do something new and unprecedented, but I'm really
not? I am asking to add one line to a text file. I'm not asking to
change a policy. Nothing else will change - all workflows, all usages,
all intentions, all procedures, all tools, everything will be exactly
the same before and after. Because you can already, today, build and
install a testing image, run it, update it, manage it, use it for
workloads, and never, ever get even a hint that something called
"unstable" even exists. We know this happens, and it always has
happened, and it will continue to happen. And the same is true for
unstable. They each have their own section of the archive, which are
independent from each other and fully complete on their own (as
opposed to other things already mentioned like ubuntu-proposed or
experimental or stable-proposed-updates). You can do 'debootstrap
unstable' build an image and run it, you can do 'debootstrap trixie'
build an image and run it, and you were always able to do so. So, I
don't know, it seems excessive and scary to say it's a change in
policy? No policy changes here, no?

> > On Fri, 2 Aug 2024 at 04:00, Russ Allbery  wrote:
>
> >> Well, it's related to your example of the zoom package basing decisions
> >> on the version number.  If they had done that based on a version number
> >> of testing, there's a fairly high chance that whatever decisions they
> >> made would be wrong by the time the stable release happens,
> >> particularly if they do that early in a release cycle.
>
> >> That said, I would expect most third-party non-free packages like that
> >> to not care at all about anything in Debian until it reached stable, so
> >> the chances of them doing that may be low.
>
> > Uh, I did not provide an example regarding zoom? Where's that from?
>
> Ugh, I'm sorry, I was reading a lot of bug history and completely
> misattributed that message (and, for that matter, when it was sent).  I
> 

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 08:22:55 +0200 Helmut Grohne 
wrote:
> Hi Russ,
> 
> Let me adress the essential/bootstrap aspects of this sub-discussion
> only.
> 
> On Thu, Aug 01, 2024 at 08:00:40PM -0700, Russ Allbery wrote:
> > Given that it's included in base-files now and base-files is
essential, I
> > believe it has to continue to be provided by an essential package,
unless
> > we want to try to do the work of figuring out if os-release can be
removed
> > from essential (and I would not be eager to do that).
> 
> I concur.
> 
> > Since it is part of the essential set, though, I'm not sure the
dependency
> > from base-files is actually needed (but also it may not really
matter).  I
> > think dependencies between essential packages are only really used
during
> > the bootstrapping phase, and presumably os-release is not needed by
> > bootstrapping.
> 
> It actually is the other way round. debootstrap-like tools will
> automatically pick up all packages marked with "Essential: yes".
> Bootstrapped systems will not magically install newly essential
packages
> though. So doing an upload of base-files that releases /etc/os-
release
> will not magically cause a newly essential os-release package to be
> installed and thus our essential promise of /etc/os-release may be
> temporarily broken. (There is no implication of how bad breaking this
> promise is.) So whenever we want to add a new package to the
essential
> set, we need some existing essential package to declare a dependency
on
> that new package for the duration of one release cycle (as we do not
> support skip upgrades).
> 
> The obvious candidate to express such a dependency would be base-
files
> here and that brings us back to the aspects you (Russ) mentioned
earlier
> regarding the fragility of the bootstrap order related to base-files.
> Admittedly, bootstrapping is more empirically solved in Debian than
> well-defined. As I attempted clarifying this in Debian policy
earlier,
> the outcome was to explicitly leave it undefined. If I remember
> correctly, randomly ordering the maintainer scripts executed during
> filesystem bootstrap makes things fail every now and then and the
order
> that most tools produce works well enough currently.  Any new
dependency
> inside the essential set poses a risk of perturbing this order that
> happens to work by chance. Hence my request to validate the proposed
> changes.  With luck, things just work, but we better figure out
before
> we upload to unstable.
> 
> This is not pretty, but it is what we have. And then I see this
mostly
> as a work item rather than a blocking issue once we agree on the
other
> matters.

Validating is of course necessary. If the worry is around changing the
dependencies of base-files, I would be happy to carry the dependency on
a new os-release binary package in init-system-helpers, which is
already Essential: yes. I already did something similar in Bookworm to
force all installations to become usrmerged, and I do not recall issues
with the bootstrapping order. This would be even easier in practice as
the new package would have a single file, no maintainer scripts, no
dependencies and no build dependencies. Would that solve your concerns?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#833256: util-linux: Please use login/passwd implementations provided by util-linux

[Luca Boccassi]

On Fri, 2 Aug 2024 at 14:51, Chris Hofstaedtler  wrote:
>
> Control: block -1 by 1074394
>
> Hi Luca,
>
> * Luca Boccassi  [240802 15:09]:
> > What's the state on this?
>
> Package: login currently provides these separate interfaces:
>
> * /usr/bin/login
> * /usr/bin/newgrp
> * /usr/bin/sg
> * /usr/sbin/nologin
>
> For these 4, I need to reread this bug and see if util-linux has
> direct replacements.
>
> * /etc/login.defs
>
> Getting this out of Package: login is #1074394, added a block.
>
> > Any chance we can get util-linux's login in
> > for trixie?
>
> Unsure. Lets see if time permits it.
>
> > Some folks have done a _ton_ of work to make util-linux's
> > login work nicely with autologin for containers and VMs with zero guest
> > configuration, using systemd credentials over smbios and such things.
> > It would be great if we could reap the benefits of this in trixie.
>
> Is this all already part of Debian's util-linux or will it become
> part of a newer release or sth else?

It's all part of the latest releases of util-linux and systemd

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 13:00, Simon McVittie  wrote:
>
> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
> > To further clarify why the status quo with VERSION_CODENAME=trixie in
> > sid is really bad: it used to be that if you had "debian" mentioned in
> > os-release but no other version identifying fields, you knew you were
> > on testing OR unstable and you'd have to deploy horrendous hacks to
> > attempt and figure out which of the two it was really.
>
> OK, I think this is progress:
>
> What is the scenario / use-case in which it becomes necessary to
> distinguish between those two suites?
>
> To put that another way, what external piece of software needs to
> change its behaviour, dependent on whether you are running testing
> (of an unspecified datestamp) or unstable (of an unspecified datestamp)?
>
> Or perhaps you are thinking of a scenario in which a *person* needs to
> change their behaviour, dependent on whether they are running testing
> or unstable?

Are the examples I provided at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5

enough to answer this question? (I'm trying to avoid copy/pasting the
same stuff multiple times in an already long and
probably-going-to-be-even-longer thread)

> > Sorry, but there's no other way to define this than a bug.
>
> I would personally characterize it as a potential root cause for bugs,
> more than as a bug itself. To me, an example of one of those bugs might
> look more like "I run ansible/Puppet/etc. against my test VM, and I
> expect it to do a useful thing, but actually it..." (with the buggy result
> perhaps being to crash, or to install the wrong package, or something).

It's not running code, but we consider mistakes in documentation bugs
too, and treat them as such in our tools and processes. A wrong
implementation of a specification, that results in wrong text being
published, should still qualify as a bug given precedents, even if
it's not in itself running code. It might or might not cause other
bugs/bad behaviour, but that should be orthogonal.

Bug#833256: util-linux: Please use login/passwd implementations provided by util-linux

[Luca Boccassi]

On Sun, 3 May 2020 21:19:41 +0200 Chris Hofstaedtler 
wrote:
> Hi Bálint,
> 
> * Bálint Réczey  [200503 19:18]:
> > I'm now a bit less convinced that the switch its worth the pain of
> > getting through the transition, but I'm still not strongly against
it.
> > 
> > To move forward I have created a branch where MRs are welcome:
> >
https://salsa.debian.org/debian/shadow/commits/move-login-to-util-linux
.
> 
> Thanks for working on this. I'll try to see what we need to do on
> the util-linux side soon.
> 
> > I' have also converted the shadow the package to dh and cleaned up
it
> > a bit. /etc/securetty is dropped, so we don't have to drop it if
the
> > move to util-linux finally happens.
> 
> Awesome.

Hi Chris,

What's the state on this? Any chance we can get util-linux's login in
for trixie? Some folks have done a _ton_ of work to make util-linux's
login work nicely with autologin for containers and VMs with zero guest
configuration, using systemd credentials over smbios and such things.
It would be great if we could reap the benefits of this in trixie.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 12:48, Simon McVittie  wrote:
>
> On Fri, 02 Aug 2024 at 11:35:54 +0100, Luca Boccassi wrote:
> > VERSION_CODENAME=trixie was added, and the problem as explained is
> > that it's present in sid too. So the only identifier we have in sid,
> > identifies it as trixie, which is categorically and unequivocally
> > wrong.
>
> When involved in a disagreement, please could you try to make an effort
> to understand the point of view of the other side, rather than declaring
> them to be categorically and unequivocally wrong? I think that would
> lead to fewer people feeling that they're being shouted at and refusing
> to engage with you, which is likely to result in more of the changes
> you want to see actually being adopted.

Some things are viewpoints, and then there are such things as facts.
As mentioned in another mail, one is of course allowed to say "it is
fine if the os-release implementation in debian is buggy". One can say
"the severity of this bug is nil". One can say "it is better if the
bug is not solved". One doesn't even have to state a reason for such a
belief, and it's perfectly valid nonetheless. That's a viewpoint.
It is not a "viewpoint" to say "the os-release implementation in
debian is not buggy", because it's not a competing opinion or design
choice, it's denying a fact that exists independently of opinions, for
reasons already explained at length, that I am not going to repeat yet
again. One can disagree on the severity of the bug and think it is
nil, one can disagree on whether it should be fixed or how. It is
still a bug. Why is it a problem to define it as such? Why is saying
"the spec says A, this does B, therefore it's a bug" equivalent to
"shouting" or "insulting"? If this was a running program and it
checked the state according to the spec and assert on it, it would
crash. Whether one holds the view that it would be right or wrong to
crash, it would still crash, and there's no point in denying it would,
and I don't see how it helps with resolving anything or making any
progress.

> In this case, I think the two design principles might be:
>
> - you think of sid as an independent rolling-release distribution in
>   its own right, an alternative to e.g. Arch Linux, and so you want to
>   label sid images/containers/chroots/etc. in a way that is consistent
>   with that point of view;

I don't think that's accurate. It's not an opinion that one can run
"debootstrap sid", install it, run it, and never ever reach any point
in time where that is a stable, security supported os vendor tree that
will go EOL and have a version+1. This is a fact. We know for a fact
that this happens, today, yesterday and tomorrow, in the real world.
It is also a fact that due to this, the os-release specification
mandates certain things to be defined in its metadata, that are
currently not done today, and that some that are done, shouldn't.

It is an opinion that I think this should be fixed, and it is also an
opinion that fixing it is more important than other competing
concerns. It is an opinion to say that it is better to leave it as-is.

> - Santiago thinks of sid as a tool to be used as part of the process of
>   making our next stable release, an alternative to e.g. Fedora Rawhide,
>   and wants to label sid images/etc. in a way that is consistent with
>   *that* point of view

That's not an opinion either. It is a fact that sid is a tool used to
develop the next stable release. I recognize that fact, and I do not
want to change it.

My understanding is that Santiago's opinion is that fact is a reason
enough to avoid fixing the above issue, because labeling is
incompatible with , and because sid and trixie must remain
undistinguishable because they are the same thing. It is my opinion
that labeling does not impede on the goal of sid being a tool to
develop the next stable release, and it is a fact that the os-release
specification is not incompatible with this situation, and it is my
opinion that we should change this implementation, and it is my
opinion that it would not negatively affect sid's purpose and role in
our development model, and it is my opinion that trixie and sid should
be distinguishable, and it is a fact that trixie and sid being
distinguishable would fix a bug in the os-release implementation.

> I think that, as a project, we need a lot more willingness to frame
> disagreements in terms of "I see your point, but I think my point is
> more important", and a lot less "you're just wrong". All of us are
> doing our best to make Debian the best possible Free operating system,
> even if we don't always agree on precisely what that means.

I don't see saying "this is a bug" as "I don't see your point" or "you
are just wrong". I see i

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 11:35, Luca Boccassi  wrote:
>
> On Fri, 2 Aug 2024 at 10:15, Simon McVittie  wrote:
> > So I think Luca really has two distinct change requests here, not just one:
> >
> > 1. Label testing as Debian 13 starting from the beginning of the trixie
> >cycle, and the equivalent for each future cycle
> > 2. Label unstable as something that differs from testing
> >
> > and it would be technically possible to have both, or neither, or accept
> > (1.) but reject (2.).
> >
> > I personally have a lot of sympathy for wanting (1.) - as I said, when
> > I'm communicating with developers outside the Debian bubble who don't
> > know our processes, I tend to refer to both testing and unstable as some
> > sort of prerelease, alpha or preview of Debian 13, because that's close
> > enough to true. I am much more hesitant about (2.), because testing and
> > unstable are more similar than they are different, and more similar to
> > each other than they are to their state 6 months ago.
>
> 1 is already the case, and actually I am asking to revert that.
> VERSION_CODENAME=trixie was added, and the problem as explained is
> that it's present in sid too. So the only identifier we have in sid,
> identifies it as trixie, which is categorically and unequivocally
> wrong.

To further clarify why the status quo with VERSION_CODENAME=trixie in
sid is really bad: it used to be that if you had "debian" mentioned in
os-release but no other version identifying fields, you knew you were
on testing OR unstable and you'd have to deploy horrendous hacks to
attempt and figure out which of the two it was really. But if you had
VERSION_CODENAME, you could just use that, full stop, and everything
was sane.

Now all these hacks have to be further hacked, and you have to check
if you are on Debian, and if you have VERSION_CODENAME, and if you do
_not_ have VERSION_ID _then_ you have to discard VERSION_CODENAME,
completely ignore it, and then run the previous hacks.

Sorry, but there's no other way to define this than a bug. Well, there
are many more I could mention, but then Russ would whip out the cane
;-)

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 11:39, Matthew Vernon  wrote:
>
> Hi,
>
> With my jaunty TC member hat on, I would prefer if issue came to us with
> a description of both sides' perspective on the discussion that they
> would view as fair. In any case, I hope that Santiago will feel able to
> chime in with their perspective.

In case that doesn't happen, for reference, his position is
articulated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021663#55
and the other linked bugs.

> My initial thought is that this is really about whether the base-files
> maintainer is correct to have decided that os-release for testing and
> unstable should not provide VERSION nor VERSION_ID; that seems to me the
> technical policy question, and whether os-release moves into a new
> package or not is an implementation detail that flows from that decision?

Almost, but not quite - as mentioned in other emails it's actually
fine to omit VERSION/VERSION_ID until release time. The main vector to
do this distinction is VERSION_CODENAME which is currently set to
'trixie' in both trixie and sid. I am asking the CTTE to rule that
testing and unstable must have different VERSION_CODENAME fields in
their respective os-release files, that is to say "trixie" and "sid"
respectively.

It is correct to say that "sid does not have a version", just like
Arch or Tumbleweed, so that is not a contentious point. It is
acceptable to me to say "trixie does not have a version until release
day", although I would prefer it did, because it is sufficient to have
VERSION_CODENAME being different for the purpose of this ticket.

Please note that older bugs against base-files mention version numbers
because VERSION_CODENAME is a later addition to the spec, it appeared
in 2016, so VERSION_ID used to be the only way to tell the difference
between releases programmatically, so naturally users reporting bugs
about being impossible to distinguish testing vs unstable asked for
that to be added. It's no longer the case today, so this request is
_not_ about overriding the decision to omit VERSION_ID until release
date.

> I think the submitter's contention against that is that in fact people
> do want to be able to differentiate between testing and unstable. I
> think they would go further and say that people want to be able to do
> this without doing anything more involved than inspecting
> /etc/os-release and that Debian should support them in so doing.

Yes, this is correct, minus the part about the specific field numeric
versions, which is more of a "nice to have" but can still be omitted
if, e.g., RT prefers doing so.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 10:15, Simon McVittie  wrote:
> The closest equivalent of what Fedora and Ubuntu do would be to label
> both testing and unstable as though they were some sort of Debian 13
> prerelease, but not distinguish between the two. But Luca is asking for
> unstable images/chroots/installations to be machine-readably different,
> even if they happen to contain all of the same packages at the same
> versions (other than base-files), and I think that's because unstable
> has more users than Ubuntu proposed, and is typically further away from
> testing than the gap between Ubuntu proposed and devel.

As far as I understand Ubuntu proposed is a partial pocket, like
stable-proposed-updates. It doesn't have full content at all times.
You cannot debootstrap and install oracular-proposed, you _have_ to
include oracular. So it's correctly not identified separately and
independently in its os-release, as it doesn't make sense to do so,
from the point of view of the os-release specification and its purpose
and intent. oracular-proposed will always be oracular, if you clone it
now and update it a year on it will still fetch oracular 24.10
content, not 25.04 . Debian sid will remain
debian sid forever, if you clone sid today and update it in 2 years
time you will not get trixie 13.x. If you clone testing today and
update it in 2 years time, you will get trixie 13.x. If you enable
bookworm-proposed-updates on bookworm, it's still bookworm. If you
enable experimental on sid, it's still sid.

Testing and unstable have completely separate and independent
archives, you can point an image builder to one OR the other, in
isolation, and it will produce a fully complete and runnable and
bootable OS tree. The fact that they might have some or even all
content in common at particular points in time is orthogonal and
unrelated to what the purpose of os-release is.

> So I think Luca really has two distinct change requests here, not just one:
>
> 1. Label testing as Debian 13 starting from the beginning of the trixie
>cycle, and the equivalent for each future cycle
> 2. Label unstable as something that differs from testing
>
> and it would be technically possible to have both, or neither, or accept
> (1.) but reject (2.).
>
> I personally have a lot of sympathy for wanting (1.) - as I said, when
> I'm communicating with developers outside the Debian bubble who don't
> know our processes, I tend to refer to both testing and unstable as some
> sort of prerelease, alpha or preview of Debian 13, because that's close
> enough to true. I am much more hesitant about (2.), because testing and
> unstable are more similar than they are different, and more similar to
> each other than they are to their state 6 months ago.

1 is already the case, and actually I am asking to revert that.
VERSION_CODENAME=trixie was added, and the problem as explained is
that it's present in sid too. So the only identifier we have in sid,
identifies it as trixie, which is categorically and unequivocally
wrong.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 10:09, Simon McVittie  wrote:
>
> On Thu, 01 Aug 2024 at 16:54:20 +0100, Luca Boccassi wrote:
> > The second [objection from the base-files maintainer] is pushing forward a
> > philosophical explanation according to which testing and unstable are
> > not actually different images, but they are one and the same (two sides
> > of the same coin is the expression used). While that might be true in a
> > philosophical sense, this is a practical matter, and it concerns only
> > the os-release specification and its implementation. In such context,
> > testing and unstable are different and independent images, built from
> > different and independent archives of packages. For example, at any
> > point in time you can do:
> >
> > deboostrap testing /tmp/a
> > deboostrap unstable /tmp/b
> >
> > and if your shell history is lost, you have no reliable, stable,
> > distro-agnostic way to identify what exactly /tmp/a and /tmp/b are.
>
> But, let's continue your example: suppose you ran those commands back in
> January. Now, 6 months later, run similar commands again:
>
> debootstrap testing /tmp/c
> debootstrap unstable /tmp/d
>
> With your proposed labelling of testing and unstable as being fundamentally
> different, you would have:
>
> /tmp/a: testing from January, labelled as testing (or trixie or Debian 13)
> /tmp/b: unstable from January, labelled as unstable
> /tmp/c: testing from July, labelled as testing (or trixie or Debian 13)
> /tmp/d: unstable from July, labelled as unstable
>
> But, contrary to that, the differences between a and b will be relatively
> small, and so will the differences between c and d; whereas the differences
> between a and c will be large (even though they're both labelled as
> testing) and so will the differences between b and d.
>
> For example, a and b will have glibc 2.37, but c and d will have 2.39,
> with whatever behaviour changes have happened in the last 6 months.
> Similarly, neither a nor b has been through the t64 transition, but
> both c and d have.
>
> I think the most important fact about all of these chroots is
> "it's strictly newer than Debian 12, so expect some behaviour
> changes". Precisely how much newer, and precisely which behaviour changes,
> is not such a simple question to answer: it depends which package's
> behaviour you're interested in, and if you want to answer that question,
> the only way is to look at individual packages, so that you can tell
> whether they were last updated in January or whether they have been
> updated to July's version.

If you chroot into /tmp/b after you create /tmp/d, and you update it,
you will get content that matches /tmp/d, not /tmp/c (yes yes if you
touched /tmp/b in some ways there will be subtle differences, and
weird breakages might happen from time to time, but you know what I
mean). sid remains sid, it will never be trixie, it will never become
released with security support, then move to ELTS, and then go EOL. A
particular instance might have some out of date content, but that's
true of every OS tree in the universe, but it fundamentally doesn't
change its identification from the point of view of os-release. The
fact that some content might match the content of other releases
doesn't change anything in the specific context of os-release - again
it's fine to have a philosophical discussion on what actually
constitutes a pipe, but this is not the purpose of this ticket - in
fact, we have many many packages that never get rebuilt, and that are
bit-by-bit identical from oldoldstable to oldstable to stable to
testing to unstable. Does it mean that os-release in bullseye is wrong
to identify it as bullseye and should say 'sid' instead, because some
packages are identical and indistinguishable between the two?

This is trying to ascribe a meaning to os-release that it really
doesn't have, and nobody I know of uses it for. Because it doesn't
tell you "yes this is exactly up to date at the time you are reading
it". It tells you, "this is what this vendor tree was, at the time it
was last updated or created", and yes, this is useful and needed
information to convey. If you create an Archlinux or a SUSE Tumbleweed
vendor tree now, and another one next year, they will be massively
different. os-release will still, correctly, say the same thing.
Because it is not a statement about updated-ness, it's a statement
that captures the identity of a vendor tree at the point in time it
was touched. As mentioned already in a separate mail, we actually have
optional fields like BUILD_ID where timestamps can be added, if that
needs to be tracked. A VERSION_CODENAME doesn't mean content will
always be the same - it's not a reflection on every single bit of its
content. It's the identity of the 

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 04:00, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > It could be a dependency of something else, or it could be marked as
> > essential itself, given the content is a 5 lines text file and a symlink
> > it shouldn't be too hard to figure out an acceptable way to ensure it
> > ships everywhere. It doesn't have to be related to base-files at all, it
> > was just the first thing that came to mind.
>
> Given that it's included in base-files now and base-files is essential, I
> believe it has to continue to be provided by an essential package, unless
> we want to try to do the work of figuring out if os-release can be removed
> from essential (and I would not be eager to do that).
>
> Since it is part of the essential set, though, I'm not sure the dependency
> from base-files is actually needed (but also it may not really matter).  I
> think dependencies between essential packages are only really used during
> the bootstrapping phase, and presumably os-release is not needed by
> bootstrapping.
>
> Anyway, I haven't done any work in this area of Debian so I'll leave this
> for other people with more relevant expertise to comment on.

Yeah it really has to be part of the essential set, it's just expected
to be there in the minimalest of barest vendor trees. Priority:
essential is probably the easiest.

> [version numbers]
> > The really important part is adding different and separate codenames, so
> > that a testing image can be reliably and univocally distinguished from a
> > sid image, and VERSION_CODENAME is enough for that, the version number
> > is cherry on top.
>
> Like Santiago, I admit to not finding this use case compelling.  Most of
> the reasons why I might imagine someone would want to do this sound like
> misunderstandings of how Debian works, given that in many cases, excluding
> the apt configuration, today's unstable image is next week's testing image
> without changing a single byte on disk.  In other words, in the cases
> where this does make sense, I feel like this desire is usually a proxy for
> "what package pool will *new* packages for this image be drawn from," and
> using os-release to guess at that information seems at least a bit
> questionable.  If what someone cares about is apt configuration, it seems
> better to get that information from apt directly, not via a fallible proxy
> (and maybe we need a better way to do that).

That's yet another Debian-specific workaround. The point of this is,
again, answering the question "what is this vendor tree" _without_
distro specific kludges. That's the entire reason for os-release to
exist. If the answer at any point is "check os-release AND THEN run
this distro specific set of scripts or binaries", then the answer is
wrong, and the implementation of the spec is buggy. Again, one might
say "I am ok with this being buggy because we gain X Y and Z in
exchange", but buggy it is and buggy it will remain.
apt might not even be installed or configured in an otherwise correct
and minimal read-only OS tree. It's not just about your laptop or your
server, it's about building, running, stacking and identifying many
types of images - bare metal, virtual, container, chroot, you name it.
Please see examples in my other email to Helmut.

> However, it doesn't seem obviously *bad* to do this either, and I trust
> that you have reasons why you think this is important.
>
> > But this example seems a bit too tortured to me.
>
> Well, it's related to your example of the zoom package basing decisions on
> the version number.  If they had done that based on a version number of
> testing, there's a fairly high chance that whatever decisions they made
> would be wrong by the time the stable release happens, particularly if
> they do that early in a release cycle.
>
> That said, I would expect most third-party non-free packages like that to
> not care at all about anything in Debian until it reached stable, so the
> chances of them doing that may be low.

Uh, I did not provide an example regarding zoom? Where's that from?

> > And secondly, that same strawman
>
> straw man (noun)
>
> 1: a weak or imaginary opposition (such as an argument or adversary)
>set up only to be easily confuted
>
> This is the sort of thing I was talking about when I said insults.  I'm
> not sure if you're using this term with some non-standard definition
> (believable, since I was using this argument in the opposite way from how
> one would use a straw man), but the normal implication of calling my
> argument a straw man is that I was arguing in bad faith.  This comes
> across as weirdly aggressive and makes these discussions unnecessarily
> annoying.

I admit I don't real

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Thu, 1 Aug 2024 at 22:52, Helmut Grohne  wrote:
>
> Hi Luca,
>
> On Thu, Aug 01, 2024 at 04:54:20PM +0100, Luca Boccassi wrote:
> > This is an escalation requesting a ruling on the matter of several
> > base-files bugs around its buggy implementation of the os-release
> > specification, the most recent example being #1021663 and other
> > instances that I could find with a cursory look being #1008735 and
> > #675731.
>
> I observe that Santiago has replied to each of them with patience and
> that he has presented relatable reasons for his choices.
>
> As you detail later, it seems that the corner stone of your complaint is
> that an unstable installation should have VERSION_CODENAME=sid rather
> than VERSION_CODENAME=trixie. Do you agree with this characterization?

Yes, _and_ testing should have VERSION_CODENAME=trixie at the same
time, to be precise. I.e., the very core of the conflict is about
whether being able to tell the difference between testing and unstable
should be possible following the distro-agnostic os-release
specification.

> > The TL;DR is a request to override the base-files maintainer, and
> > enable moving os-release into a new, independent and separate source
> > package, so that these bugs may finally be fixed, and Debian's os-
> > release may finally be made compliant with the specification.
>
> On a process level, the CTTE can only decide among available options. In
> this context available roughly equates the existence of a patch (or
> source package). Reading multiple bugs, I found disagreement on this
> approach, but no code that could be characterized as a reviewable
> solution.

Well you know this better than me of course, but isn't this also
something you can do? Decide between:

1) The os-release specification must be adhered to, and it must be
possible to tell the difference between testing vs unstable, and each
must be correctly identified by the respective metadata

or

2) Testing and unstable can continue to remain indistinguishable, and
both be erroneously identified as trixie

Again you'll know better than me, but it seems to me rulings were made
in the past that were along similar lines (eg: usrmerge) - there
wasn't reviewable code there, no?

> Another plausible way to interpret your mail is that you really ask the
> CTTE to override the base-files maintainer in claiming ownership of
> /etc/os-release in the base-files package request releasing the file to
> another package. Given that said file has become part of the essential
> interface, releasing it is subtle and warrants a more detailed look at
> how the take-over is supposed to happen. To me that process is too
> sketchy to consider at this time.
>
> > Numerous attempts were independently made by many different people to
> > try and convince the base-files maintainer to fix this issue, the
> > oldest one linked above being 12 years ago, and they have all been
> > rejected, as recently as today. The only course of action left is
> > therefore asking for a CTTE intervention in the matter, as all attempts
> > at mediation and negotiation over the years have failed.
>
> Evidently, there are multiple conflicting requirements that various
> parties would like to see implemented. The base-files maintainer has
> made a compromise and argued in favour of his position. Said compromise
> encompasses an interpretation of the os-release specification that does
> not follow it to the letter.

Sorry but I do not think that is an accurate representation. First of
all, the implementation of the spec is bugged, period - it's not about
being pedantic about it, it's about being completely incompatible: sid
is identified as trixie, and that is just plain wrong, and there's no
room for interpretation, no matter how one might try to bend it. You
might say that you don't _care_ that the implementation is buggy, you
might even say that it is worth, nay _good_ it to leave it buggy - but
buggy it is, if I create a sid image, it will never in a million years
be trixie, and yet it says it's trixie.

Secondly, I am not even sure what these conflicting requirements
actually are? Could you please spell them out? If trixie was
identified as trixie, and sid was identified as unstable, what
compromise would be, er, compromised, precisely? Because the only
practical objections I could find were based on the idea that
implementations would be ugly or hard to maintain or so - as already
mentioned, I am happy to relieve anybody else and take that hard and
ugly maintenance burden for myself. What other actual problem would
suddenly appear? What feature or advantage do we leave behind? How are
things made worse for our users?

> > The os-release specification, of which I am an upstream author and
> > maintainer, defines a distro-agnostic text-based metada

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Thu, 1 Aug 2024 at 20:06, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > I was about to say that the proposal is in the linked bug, but it has
> > disappeared - it could be due to the bugs getting unlinked. Anyway, my
> > variant is here:
>
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675731#54
>
> Ah, thank you.  I think that answers my questions.
>
> To summarize briefly to ensure that I understand, your proposal is to
> separate only this content into a second package, make base-files depend
> on it, and then maintain different versions of that package in unstable
> and testing.
>
> There are two technical aspects of this proposal that worry me.
>
> The first is adding a dependency to base-files.  I know people have put a
> whole lot of work into pure dependency-based bootstrapping for Debian, but
> historically base-files has been very special and posed lots of
> interesting complications that are separately handled in lots of different
> tools.

It could be a dependency of something else, or it could be marked as
essential itself, given the content is a 5 lines text file and a
symlink it shouldn't be too hard to figure out an acceptable way to
ensure it ships everywhere. It doesn't have to be related to
base-files at all, it was just the first thing that came to mind.

> I do agree with Santiago's desire to maintain base-files as a "normal"
> Debian package that gets tested in unstable and propagates to testing, so
> if we go down this route, splitting out this data does seem better to me
> than maintaining multiple lines of development for base-files itself.
>
> The second thing that I'm not fond of is giving testing the version number
> 13 when we plan on using 13 as the version number for the trixie release.
> I fear that if we do that, someone (probably a third-party package
> provider) will add some workaround or behavior change for a package based
> on that version number for a problem that only ever existed in testing and
> that was not in the actual 13 release.  I would instead expect testing to
> use some version number that is between stable and the version number that
> will be assigned to the next release, to reflect that it is likely to
> change substantially before Debian makes an actual release 13.

The version number is the least important part of the changes - so for
example, it could still be omitted until the actual release like it is
now. The really important part is adding different and separate
codenames, so that a testing image can be reliably and univocally
distinguished from a sid image, and VERSION_CODENAME is enough for
that, the version number is cherry on top. I still think that trixie
is 13 and 13 is trixie, so there's no point in delaying, as that piece
of metadata is not going to change, and I think it would be better if
"debootstrap trixie" always gave the same identification metadata
(barring the release type as per below perhaps) but it's not a crucial
matter and it's fine either way, in the end.
But this example seems a bit too tortured to me. First, if you add a
workaround like that, you would normally do it based on the package
version you are working around, or at least that's how I usually do it
and see it done. And secondly, that same strawman can be applied to
stable, as we do point releases and security uploads. One could see a
bug in bookworm and decide to check for VERSION_ID=12 to work around
it, even if that bug is later solved in a point release or security
update. It is still correct to mark stable as VERSION=12 (without the
point release).

> (If I were designing this from scratch, I'd give serious thought to using
> even version numbers for releases and odd version numbers for testing,
> similar to how Perl releases are versioned for very similar reasons.  But
> that's probably too big of a change for the level of benefit.)
>
> Presumably the RELEASE_TYPE setting of pre-release is supposed to help
> with that, but (a) that variable doesn't seem to be documented in
> os-release(5);

What do you mean?!! It's right there!
https://www.freedesktop.org/software/systemd/man/devel/os-release.html#RELEASE_TYPE=

...ok, ok, it's there now because I just merged it and regenerated the docs :-P

> (b) the sorts of packagers that I'm worried about are quite
> likely to not make subtle distinctions like that, so the version is still
> there as a potential foot-gun for people who aren't paying close
> attention; and (c) I would argue that calling testing a "pre-release" is
> not very accurate, since that applies that the contents are very similar
> to the eventual release and are in a relatively late stage of testing.

As above, if someone wants to abuse the version to pin things, it can
already happen in all stable point releases too. In fact with ker

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Thu, 1 Aug 2024 at 18:33, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > There are several different ways of having different content in sid vs
> > testing, and some have been proposed in the latest bug linked above, I
> > would be happy to discuss those details too if required.
>
> Generally the technical committee works best if it can consider a concrete
> technical proposal for a fix alongside the problem statement.  I'm not a
> member, but as an interested bystander, I would like to see the details of
> precisely how you would implement your desired functionality.  That could
> be several options if you'd like the committee to choose between them.

I was about to say that the proposal is in the linked bug, but it has
disappeared - it could be due to the bugs getting unlinked. Anyway, my
variant is here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675731#54

There was also a slight variant by Gioele, that again I fail to find
now and it might be because of the bugs being rearranged, where
testing-proposed-updates is used to upload testing-specific content.

The TL;DR: ensure that the version of the 'os-release' package with
the content for unstable stays in unstable and never migrates, and the
version of the 'os-release' package with the content for testing goes
to testing either via a quick migration or via
testing-proposed-updates.

And the exact details on _how_ to manage it are all up for discussion
of course, if there are better ideas I'm happy to implement them. The
reason for escalating to the CTTE is not the implementation details
however, it's a core conflict about the basic concept of os-release
itself.

> I'd also like to see an elaboration of how you propose to distinguish sid
> from testing.  This would be an ill-defined concept on the systems that I
> personally install testing packages on, and the specific criteria that you
> would use is not obvious to me from the bug discussion.

If you 'debootstrap unstable /tmp/a' and then 'cat
/tmp/a/usr/lib/os-release' you will see:

PRETTY_NAME="Debian GNU/Linux sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=sid
ID=debian

If you instead 'debootstrap testing /tmp/b' and then 'cat
/tmt/b/lusr/lib/os-release' you will see:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
RELEASE_TYPE=pre-release
ID=debian

That's it. Of course if what you are saying is that you mix and match
a selection of packages from testing and unstable, well that's a
frankendebian - you can do that on any release (I have some testing
packages pulled in my debian stable laptop right now). So the
identification will be as it is right now, it will depend on the
version of the package providing the os-release file, which like any
other package can be manually overridden, upgraded, downgraded if one
really wishes to do so. I could echo "ID=windows 3.1" into my local
/etc/os-release and nothing would stop me or fix it until the next
stable release. But this doesn't really change the purpose or meaning
of the os-release specification and its implementation and purpose.

> I did review the discussion #1021663 in the hope that I would find a
> detailed technical proposal there, but your messages to that bug seemed to
> focus on criticisms of the current behavior mixed with insults.  I wasn't
> able to find a proposal, but it's entirely possible I missed it.

There are for sure a lot of criticisms of the bugs in base-files, but
there are no insults.

Bug#1008735: base-files: os-release and debian_version make testing and unstable indistinguishable

[Luca Boccassi]

These bugs have now been escalated to the CTTE:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Thu, 1 Aug 2024 at 17:32, Christoph Berg  wrote:
>
> Re: Luca Boccassi
> > The TL;DR is a request to override the base-files maintainer, and
> > enable moving os-release into a new, independent and separate source
> > package, so that these bugs may finally be fixed, and Debian's os-
> > release may finally be made compliant with the specification.
>
> If we are fixing that, we should also fix /etc/debian_version in the
> same way. I've always been wondering why we don't put better content
> into these files.
>
> (Though I'm not sure the ruling should include the "move to new source
> package" part. It could also be fixed inside base-files.)

I left that out intentionally, as that is by definition a
Debian-specific file and the main goal here is fixing the
distro-agnostic metadata issues, and also changing that might affect
backward compatibility of existing consumers (not an issue in
os-release, as the relevant metadata is either absent or the wrong one
is very new). However, I personally do not have a strong opinion one
way or the other, and I am happy to do extra work if required.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

e a trixie+1
(forky). The fact that trixie gets a lot of changes in this 2 years
development period is orthogonal and independent, and does not qualify
it as a rolling distribution, in the context of the os-release
specification. In fact, there is a proposal to add an independent os-
release field that qualifies a version as "stable", "lts" or in
"development", that would be suited to mark testing as such. So it
would be entirely appropriate to set VERSION_ID=13 in trixie's os-
release right now. It is not appropriate to set VERSION_ID=13 in sid's
os-release, now or ever.

These issues are not just theoretical, and do not concern mere personal
preferences or cleanliness or code quality or ugliness. They cause very
real, very actual and very painful grief for Debian users, as evidenced
by the multiple independent bugs with multiple independent reporters
chiming in, and the multiple ugly hacks that have to be implemented as
Debian-specific workarounds (the latest instance of which can be found
at https://sources.debian.org/src/systemd/256.4-2/debian/tests/upstream/#L15
).

The base-files maintainer repeatedly, over numerous years, refused to
fix these incompatibilities with the specification, citing personal
preferences and interpretations, and the latest suggestion as per
#1021663 is to override the lsb_releae maintainer and ship again buggy
and deprecated lsb_release python scripts to try again to solve the
problem in a Debian-specific way, parsing apt's sources.list. The point
of a cross-distro specification is to perform its function reliably so
that users do not have to employ distro-specific workarounds, so we are
currently doing our users a disservice by shipping a buggy
implementation, and require them to use deprecated and buggy scripts as
workarounds. It would in fact be much better to simply not ship an
implementation of os-release at all, rather than implement it wrongly
based on reinterpretations.

A concrete proposal that I can put forward is to move os-release away
from base-files, into a new source+binary package, that can be managed
independently, and can be updated to respect the specification it is
supposed to follow. base-files ships code in maintainer scripts so
requires changes and updates, and using a separate package allows to do
only one upload per cycle to set the new metadata. base-files can then
depend on this new binary package, which will ship only /usr/lib/os-
release, its /etc/os-release symlink and no maintainer script. This
package should be team-maintained on Salsa (as opposed as base-files
that is individually maintained with no VCS).

The os-release installed in sid's images would then be something along
those lines:

PRETTY_NAME="Debian GNU/Linux sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=sid
ID=debian

And trixie's would be something along those lines:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
RELEASE_TYPE=pre-release
ID=debian

With RELEASE_TYPE= changing to 'lts' immediately before release day.
There are several different ways of having different content in sid vs
testing, and some have been proposed in the latest bug linked above, I
would be happy to discuss those details too if required.

I volunteer to do the work to create and team-maintain the new package,
and provide a patch to do the move from base-files. If requested, I am
happy to do such work in advance so that you can judge based on
something concrete.

Thank you for your consideration.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1008735: base-files: os-release and debian_version make testing and unstable indistinguishable

[Luca Boccassi]

On Thu, 1 Aug 2024 at 14:29, Santiago Vila  wrote:
> El 21/7/24 a las 11:36, Luca Boccassi escribió:
> > There have been many bugs over the years,
>
> Well, my feeling is quite the opposite: I think there really
> have not been so many bugs over the years.

The 3 CC'ed ones are the first ones I could find with a cursory look.
The sheer amount of Debian-specific ugly hacks that are around because
of this bug in base-files speaks volumes.

> There is a paragraph in /usr/share/doc/base-files/FAQ saying
> testing and unstable are sides of the same coin. Most people
> read it and realize that differentiating between testing
> and unstable is not such an important issue. In some cases
> (read below) it may be even counter-productive and harmful.

That FAQ is wrong, at the very least from the point of view of the
os-release specification. Once again, you can do:

debootstrap unstable a/
debootstrap testing b/

and then you have two different and independent images, running two
different and independent sets of packages, from two different and
independent archives, and no sensible way to distinguish them.

It doesn't matter what you write down in your own FAQ, the
specification is what matters. If you want to write a competing
specification, with different semantics and contents, and convince
other distros to adopt it instead of os-release, feel free to do so.
But what base-files ships is not a spec-compliant os-release metadata
file, and that's a bug in base-files.

> Moreover, for some time, we had a smart "lsb_release" command
> which actually looked at the sources.list file (the recommended
> approach).

That is not the recommended approach, that's a Debian-specific
horrendous and fragile hack (hint: you can have _both_ unstable and
testing lines in sources.list, with unstable apt-pinned at 1 or so,
and then your recommendation falls apart). LSB is dead, and good
riddance. We want to reduce these pointless and painful debianism, not
make them proliferate. We should promote Debian based on what it's
good at, not based on how much of a pain it is to use.

> > and this issue keep biting.
> > Just fell into it yet again.
>
> Well, that's vague and imprecise. When reporting bugs, one usually
> tells what one did, what one expected, and what one got.
>
> I guess you simply expected VERSION_CODENAME to be "sid" on a system
> running sid, but there are reasons why that's not reasonable or useful
> and the FAQ attempts at explaining that.

No, I expected to be able to tell if an image I am managing is trixie
or sid, and it is impossible to do so reliably. It is a problem that
exists only in Debian.

> > os-release is the Linux
> > standard for identifying images, and we need to make it useful for our
> > users for testing and unstable too, not just for stable.
>
> This is unaccurate in several ways. You say that it's not useful for
> testing, but that's not true. Also, you say that we need to make it useful
> for unstable. Well, unstable is not a supported distribution, so that
> would be at least subject to debate.

As an upstream author and maintainer of the os-release specification,
I can tell you with absolute certainty that it is in fact accurate.
The way base-files generates os-release currently in Debian is bugged,
and as per multiple bug reports has always been bugged. The wrong
metadata is conveyed to users. This is not a matter of opinions, the
spec is very clear.

> > Currently in unstable/testing os-release contains:
> >
> > PRETTY_NAME="Debian GNU/Linux trixie/sid"
> > VERSION_CODENAME=trixie
> >
> > And debian_version contains:
> >
> > trixie/sid
> >
> > This is confusing and breaks all the software out there that needs to
> > distinguish between releases.
>
> Well, one might wonder what kind of software needs to differentiate
> between testing and unstable. It may be the case that such software
> is already broken to begin with.

Any software that deals with images, root directories, and whatnot.
And the only broken software here is base-files.

> If you find the above confusing, there is a very simple explanation:
> some fields are to be read by humans, and others are to be read by scripts
> and the like. The file debian_version historically reads as trixie/sid
> because its contents end up being shown to the end user on login screens,
> while the more recent VERSION_CODENAME has the value "trixie", as it's
> to be read by scripts which are meant to work in a system running trixie.

And it's broken: an unstable image will be identified as "trixie",
which is not unstable, it's something different.

> [ At this point, I'll omit your split-os-release proposal from this quote,
> it was already proposed by Gioele Barabucci and it was already rejec

Bug#1008735: Bug#675731: base-files: Please add VERSION entry to /etc/os-release for unstable/testing too

[Luca Boccassi]

On Thu, 1 Aug 2024 at 13:15, Santiago Vila  wrote:
>
> Hello Luca.
>
> I'm not happy at all that you decided to reopen three different bugs for this,
> including this one which was 12 years old (!).
>
> Sure, the three bugs are "related" but only to a certain point, as they ask
> for different things, and I consider them to be different bugs, so please 
> respect that.
>
> Bug #1021663, based on its original subject, is the one that best matches
> the things you mention now, so that will be where I will address your 
> concerns.

They *ask* for different things, as in, different solutions are
brainstormed and proposed. But the underlying problem is the same
across all those (and more, actually), which is the title I picked: it
is not possible to distinguish a testing image from an unstable image.
That's the reason I merged and retitled - while submitters often
propose solutions, the thing that matters most is the problem being
addressed, and in my view it doesn't make sense to consider the same
problem multiple times independently and in isolation. Of course you
are entitled to rearrange bugs for your packages as you see fit, so I
will not change them any further.

> (Please do *not* post the same message again in the other bug,
> I will quote if/as needed).

Just as you are entitled to rearrange bugs of your packages as you see
fit, I am entitled to reply where and how I see fit. If I think some
information is worth being associated with multiple issues, I will CC
multiple issues. You are free to drop any CC from your own mails of
course.

> Follows an explanation for bugs #675731 and #1008735.
>
> This report (#675731) is a request for VERSION and VERSION_ID to be added
> for testing and unstable. This is a wontfix because testing and unstable
> do not have a version at all, they only have codenames. That has been the
> case for at least 25 years, and the Release Managers have always supported
> that view. This bug was closed for a good reason. Please do not reopen it 
> again.

And once again, the root cause is not being able to distinguish
between the two. The particular fields are one specific suggestion on
how to potentially fix that issue, and one that is not correct as you
already noted. The underlying problem is still the same though.

> Bug #1008735 asks for VERSION, VERSION_ID and VERSION_CODENAME to be added.
> Only VERSION_CODENAME may be added from those (see above to see why) and it
> was done in version 12.3, so the bug was closed for a good reason. As noted
> before, differentiating stable from testing/unstable is a thing and
> differentiating testing from unstable is another different thing. Please
> do not reopen this bug again.

Same as above. Adding VERSION_CODENAME did not solve that problem at
all, as it is present in unstable too - in fact, by adding
VERSION_CODENAME=trixie to unstable, it made things _worse_, not
_better_, as now there is yet another piece of wrong metadata being
associated with sid images, that users have to know about and work
around manually.

Bug#1076432: systemd: [networkd] incorrect IPv6 address generation

[Luca Boccassi]

Control: retitle -1 networkd: no option to use lower 64 bits of IPv6-LL address 
for global addr
Control: tags -1 -moreinfo
Control: notfound -1 systemd/252.26-1~deb12u2
Control: severity -1 wishlist
Control: close -1

As per the upstream ticket, there is nothing incorrect about address
generation, simply different expectations. The ticket has been
converted in an RFE to implement the missing mode, so closing here as
new features are tracked upstream only.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1076432: systemd: [networkd] incorrect IPv6 address generation

[Luca Boccassi]

On Mon, 29 Jul 2024 at 19:02, Martin-Éric Racine
 wrote:
>
> On Tue, 23 Jul 2024 18:15:48 +0100 Luca Boccassi  wrote:
> > Control: tags -1 upstream
> >
> > On Tue, 23 Jul 2024 19:45:33 +0300 =?UTF-
> > 8?Q?Martin=2D=C3=89ric_Racine?=  wrote:
> > > Please note that if you only reply to the bug itself, the reporter
> > > will never know that you requested more information.
> > >
> > > On Tue, 16 Jul 2024 11:37:43 +0100 Luca Boccassi 
> > wrote:
> > > > Control: tags -1 moreinfo
> > > >
> > > > On Tue, 16 Jul 2024 13:29:36 +0300 =?utf-8?q?Martin-
> > =C3=89ric_Racine?=
> > > >  wrote:
> > > > > Package: systemd
> > > > > Version: 252.26-1~deb12u2
> > > > > Severity: important
> > > > > Tags: ipv6
> > > > >
> > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > > Hash: SHA256
> > > > >
> > > > > I have enabled networkd and created the following
> > > > /etc/systemd/network/dhcp.network:
> > > > >
> > > > > [Match]
> > > > > Name=en* wl*
> > > > >
> > > > > [Network]
> > > > > DHCP=yes
> > > > > IPv6PrivacyExtensions=yes
> > > > > IPv6LinkLocalAddressGenerationMode=stable-privacy
> > > > >
> > > > > Two issues:
> > > > >
> > > > > 1) networkd creates a new link address with the stable-privacy
> > flag,
> > > > in addition to the existing one created by the kernel on bootup.
> > > > > 2) Regardless, the stable-privacy flag is not inherited by the
> > > > mngtmpaddr address. It steadfastly uses an EUI64 address.
> > > >
> > > > Can you reproduce in testing/unstable?
> > >
> > > Yes. It still ignores the fe80 created by the kernel at boottime with
> > > the stable-privacy flag, it still creates an additional one, and it
> > > still creates a public address with EUI64 instead of stable-privacy.
> >
> > Ok, then please open an issue upstream, after gathering debug level
> > logs (SYSTEMD_LOG_LEVEL=debug env var in networkd) and attach them too,
> > and also attach the "ip addr" output
>
> I have no idea of where to enable debug only for networkd.

First result on Google for "how to enable debug logs in systemd-networkd":

https://superuser.com/questions/1187633/how-to-debug-systemd-networkd

Both methods listed there are correct

Bug#1077204: systemd fails to boot on a 5.4 kernel

[Luca Boccassi]

On Sun, 28 Jul 2024 at 12:04, Kornilios Kourtis  wrote:
>
> On Sun, Jul 28, 2024 at 11:16:33AM +0100, Luca Boccassi wrote:
> > > Booting the kernel.
> > > [0.00] Linux version 5.4.280 (root@buildkitsandbox) (gcc
> > version 13.2.0 (Ubuntu 13.2.0-23ubuntu4)) #1 SMP Fri Jul 26 13:40:53
> > UTC 2024
> >
> > You are running an Ubuntu kernel on Debian? That doesn't make sense and
> > it's not supported. You are probably hitting some apparmor denials that
> > are blocking some setup step from working:
> >
> > dev-hugepages.mount: Failed to spawn executor: Argument list too long
> >
> > Use the Debian kernel from the Debian version you are running, or if
> > you want to use an Ubuntu kernel, install Ubuntu instead.
>
> This is not an ubuntu kernel. It is a custom kernel that we build on our
> own (we just happen to build the kernels in ubuntu) and we use them in
> our testing pipeline with a debian rootfs. FWIW, 5.4 kernels booted fine
> with previous versions of systemd.
>
> My expectation would be that debian's systemd would be able to boot the
> machine even with a custom kernel.

Please do not open bugs for issues happening on custom kernels. Only
Debian kernels are supported, for anything else you'll have to either
figure it out yourself, or pay a contractor to do so.

Bug#1077204: systemd fails to boot on a 5.4 kernel

[Luca Boccassi]

Control: tags -1 -moreinfo
Control: tags -1 wontfix
Control: close -1

On Sun, 28 Jul 2024 09:11:34 +0200 Kornilios Kourtis 
wrote:
> On Sat, Jul 27, 2024 at 11:06:08AM +0100, Luca Boccassi wrote:
> > On Fri, 26 Jul 2024 22:39:15 +0200 Kornilios Kourtis

> > wrote:
> > > On Fri, Jul 26, 2024 at 07:09:03PM +0100, Luca Boccassi wrote:
> > > > Please set systemd.log_level=debug on the kernel command line
and
> > > > attach the full debug log output
> > >
> > > Decompressing Linux... Parsing ELF... Performing relocations...
done.
> > > Booting the kernel.
> >
> > You did not enable debug level output
> 
> I've set  "debug systemd.log_level=debug systemd.log_target=console"
in
> the kernel command line, and now I'm seeing more messages.  Adding
output
> below. Please let me know if there is  more information I can
provide.
> 
> Booting the kernel.
> [    0.00] Linux version 5.4.280 (root@buildkitsandbox) (gcc
version 13.2.0 (Ubuntu 13.2.0-23ubuntu4)) #1 SMP Fri Jul 26 13:40:53
UTC 2024

You are running an Ubuntu kernel on Debian? That doesn't make sense and
it's not supported. You are probably hitting some apparmor denials that
are blocking some setup step from working:

dev-hugepages.mount: Failed to spawn executor: Argument list too long

Use the Debian kernel from the Debian version you are running, or if
you want to use an Ubuntu kernel, install Ubuntu instead.

-- 
Kind regards,
Luca Boccassi

Bug#1077271: systemd broken after 256.4-2 upgrade

[Luca Boccassi]

Control: severity -1 minor
Control: tags -1 unreproducible moreinfo

On Sat, 27 Jul 2024 18:16:36 + Richard B  wrote:
> Jul 27 11:41:44 fw13 systemd[1]: Failed to fork off sandboxing environment 
> for executing generators: Protocol error
> Jul 27 11:41:45 fw13 systemd[1]: Freezing execution.

Something on your system is blocking namespaces, you will need to
figure out what it is and why

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1051785: workaround

[Luca Boccassi]

On Fri, 21 Jun 2024 14:55:13 +0100 Simon McVittie 
wrote:
> The intended way to change the settings of the Debian-gdm user is to
edit
> /etc/gdm3/greeter.dconf-defaults. In this case I think the equivalent
would
> be to locate the line "[org/gnome/login-screen]" and fill in
> "enable-smartcard-authentication=false" below it, so it looks
> something like this:
> 
> ...
> [org/gnome/login-screen]
> enable-smartcard-authentication=false
> logo='/usr/share/images/vendor-logos/logo-text-version-64.png'
> ...
> 
> And then restart gdm (the easiest/most reliable way is to reboot).

I can confirm this works (I too have a yubikey with a cert for
unrelated purposes).

Previously this was a mere annoyance as it just meant having to type
the username manually, which is no big deal. However, since gnome 46
migrated to testing, this actually breaks login completely - after
typing the password, the greeter is just stuck there.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072930: libpam-wtmpdb: sessions not closed after systemd-run --user --machine …@.host

[Luca Boccassi]

On Sat, 27 Jul 2024 16:50:55 +0200 Chris Hofstaedtler 
wrote:
> Control: reassign -1 src:systemd
> Control: affects -1 libpam-wtmpdb
> 
> Luca,
> 
> On Mon, Jun 10, 2024 at 03:26:24PM +0100, Tomas Janousek wrote:
> > If I do the following:
> > 
> > $ sudo systemd-run --user -M "$USER"@.host --quiet --wait --
collect --pipe echo foo
> > 
> > then I get an error in the journal:
> > 
> > Jun 10 14:15:08 deb1-wtmpdb systemd[657]: Started run-
u7.service - echo foo.
> > Jun 10 14:15:08 deb1-wtmpdb (sd-pam)[1297]:
pam_unix(login:session): session closed for user debian
> > Jun 10 14:15:08 deb1-wtmpdb (sd-pam)[1297]:
pam_wtmpdb(login:session): update_logout: Updating logout time did not
return SQLITE_DONE: 8
> > 
> > and the session stays open:
> > 
> > $ last
> > debian Mon Jun 10 14:15 - still
logged in
> 
> 
> I'll need your help/insight here. ISTM systemd is restricting what
> PAM is allowed to do, but the libpam-wtmpdb cannot really function
> without writing to its file.
> 
> How is this supposed to work?
> Was there a discussion with wtmpdb upstream?

Sorry I am completely clueless about pam, please ask upstream on the
mailing list or on a ticket

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1077204: systemd fails to boot on a 5.4 kernel

[Luca Boccassi]

On Fri, 26 Jul 2024 22:39:15 +0200 Kornilios Kourtis 
wrote:
> On Fri, Jul 26, 2024 at 07:09:03PM +0100, Luca Boccassi wrote:
> > Please set systemd.log_level=debug on the kernel command line and
> > attach the full debug log output
> 
> Decompressing Linux... Parsing ELF... Performing relocations... done.
> Booting the kernel.

You did not enable debug level output

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1077204: systemd fails to boot on a 5.4 kernel

[Luca Boccassi]

Control: tags -1 moreinfo

On Fri, 26 Jul 2024 19:59:35 +0200 Kornilios Kourtis 
wrote:
> Package: systemd
> Version: 256.4-2
> 
> Hi,
> 
> systemd fails to boot on 5.4 kernels (other kernels seem to work).
The
> logs below are from 5.4.280, but trying with older kernels has the
same
> effect.
> 
> SELinux:  Could not open policy file <=
/etc/selinux/targeted/policy/policy.33:  No such file or directory
> [    1.136915] systemd[1]: systemd 256.4-2 running in system mode
(+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS
+OPENSSL +ACL +BLKID +CU
> RL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP
+LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE
+TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZST
> D +BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE)
> [    1.139048] systemd[1]: Detected virtualization kvm.
> [    1.139402] systemd[1]: Detected architecture x86-64.
> 
> Welcome to Debian GNU/Linux trixie/sid!
> 
> [    1.140500] systemd[1]: Hostname set to .
> [    1.160170] systemd[1]: bpf-restrict-fs: BPF LSM hook not enabled
in the kernel, BPF LSM not supported.
> [    1.169448] systemd-tpm2-ge (89) used greatest stack depth: 14272
bytes left
> [    1.171050] systemd-debug-g (79) used greatest stack depth: 13576
bytes left
> [  OK  ] Created slice system-getty.slice - Slice /system/getty.
> [  OK  ] Created slice system-modprobe.slice - Slice
/system/modprobe.
> [  OK  ] Created slice system-serial\x2dget…slice - Slice
/system/serial-getty.
> [  OK  ] Created slice user.slice - User and Session Slice.
> [  OK  ] Started systemd-ask-password-conso…equests to Console
Directory Watch.
> [  OK  ] Started systemd-ask-password-wall.…d Requests to Wall
Directory Watch.
> [  OK  ] Set up automount proc-sys-fs-binfm…ormats File System
Automount Point.
>  Expecting device dev-ttyS0.device - /dev/ttyS0...
> [  OK  ] Reached target paths.target - Path Units.
> [  OK  ] Reached target remote-fs.target - Remote File Systems.
> [  OK  ] Reached target slices.target - Slice Units.
> [  OK  ] Reached target swap.target - Swaps.
> [  OK  ] Reached target timers.target - Timer Units.
> [  OK  ] Listening on systemd-creds.socket - Credential
Encryption/Decryption.
> [  OK  ] Listening on systemd-initctl.socke…- initctl Compatibility
Named Pipe.
> [  OK  ] Listening on systemd-journald-dev-…socket - Journal Socket
(/dev/log).
> [  OK  ] Listening on systemd-journald.socket - Journal Sockets.
> [  OK  ] Listening on systemd-networkd.socket - Network Service
Netlink Socket.
> [  OK  ] Listening on systemd-udevd-control.socket - udev Control
Socket.
> [  OK  ] Listening on systemd-udevd-kernel.socket - udev Kernel
Socket.
> [FAILED] Failed to mount dev-hugepages.mount - Huge Pages File
System.
> See 'systemctl status dev-hugepages.mount' for details.
> [FAILED] Failed to mount dev-mqueue.mount - POSIX Message Queue File
System.
> See 'systemctl status dev-mqueue.mount' for details.
> [FAILED] Failed to mount run-lock.mount - Legacy Locks Directory
/run/lock.
> See 'systemctl status run-lock.mount' for details.
> [FAILED] Failed to mount sys-kernel-debug.mount - Kernel Debug File
System.
> See 'systemctl status sys-kernel-debug.mount' for details.
> [FAILED] Failed to mount sys-kernel-tracing.mount - Kernel Trace File
System.
> See 'systemctl status sys-kernel-tracing.mount' for details.
> [FAILED] Failed to mount tmp.mount - Temporary Directory /tmp.
> See 'systemctl status tmp.mount' for details.
> [FAILED] Failed to start modprobe@configfs.…vice - Load Kernel Module
configfs.
> See 'systemctl status modprobe@configfs.service' for details.
> ...

Please set systemd.log_level=debug on the kernel command line and
attach the full debug log output

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1077184: systemd: /etc/sysctl.conf is no longer read

[Luca Boccassi]

Control: severity -1 wishlist
Control: tags -1 wontfix
Control: close -1

On Fri, 26 Jul 2024 15:00:17 +0200 Vincent Lefevre 
wrote:
> Package: systemd
> Version: 256.4-2
> Severity: grave
> Tags: security
> Justification: user security hole
> X-Debbugs-Cc: Debian Security Team 
> 
> The /etc/sysctl.conf file is no longer read, while I have security
> settings there.
> 
> I suspect that the cause is
> 
>   * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
> /etc/sysctl.conf (Closes: #1076190)
> 
> which is wrong!

It is not, create the symlink yourself if you still need it, the procps
package dropped it so this package dropped it as well

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1077045: bookworm-pu: package systemd/252.29-1~deb12u1

[Luca Boccassi]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

Dear Release Team,

We would like to upload the latest stable point release of systemd 252
to bookworm-p-u. Stable release branches are maintained upstream with
the intention of providing bug fixes only and no compatibility
breakages, and with automated non-trivial CI jobs that also cover
Debian and Ubuntu. I have already uploaded to p-u.

There are no packaging changes. Debdiff attached. The debdiff excludes
hwdb generated IDs.
The list of commits included can be seen at:

https://github.com/systemd/systemd-stable/compare/v252.28...v252.29

-- 
Kind regards,
Luca Boccassi
diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.28/debian/changelog systemd-252.29/debian/changelog
--- systemd-252.28/debian/changelog	2024-07-07 11:56:20.0 +0100
+++ systemd-252.29/debian/changelog	2024-07-25 13:49:17.0 +0100
@@ -1,3 +1,9 @@
+systemd (252.29-1~deb12u1) bookworm; urgency=medium
+
+  * New upstream version 252.29 (Closes: #1074789)
+
+ -- Luca Boccassi   Thu, 25 Jul 2024 13:49:17 +0100
+
 systemd (252.28-1~deb12u1) bookworm; urgency=medium
 
   * New upstream version 252.28 (Closes: #1074789)
diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.28/hwdb.d/meson.build systemd-252.29/hwdb.d/meson.build
--- systemd-252.28/hwdb.d/meson.build	2024-07-07 11:52:10.0 +0100
+++ systemd-252.29/hwdb.d/meson.build	2024-07-25 13:45:32.0 +0100
@@ -29,6 +29,7 @@
 '70-analyzers.hwdb',
 '70-av-production.hwdb',
 '70-cameras.hwdb',
+'70-hardware-wallets.hwdb',
 '70-joystick.hwdb',
 '70-mouse.hwdb',
 '70-pda.hwdb',
diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.28/man/systemd.service.xml systemd-252.29/man/systemd.service.xml
--- systemd-252.28/man/systemd.service.xml	2024-07-07 11:52:10.0 +0100
+++ systemd-252.29/man/systemd.service.xml	2024-07-25 13:45:32.0 +0100
@@ -707,8 +707,8 @@
 Configures a maximum time for the service to run. If this is used and the service has been
 active for longer than the specified time it is terminated and put into a failure state. Note that this setting
 does not have any effect on Type=oneshot services, as they terminate immediately after
-activation completed. Pass infinity (the default) to configure no runtime
-limit.
+activation completed (use TimeoutStartSec= to limit their activation).
+Pass infinity (the default) to configure no runtime limit.
 
 If a service of Type=notify sends EXTEND_TIMEOUT_USEC=…, this may cause
 the runtime to be extended beyond RuntimeMaxSec=. The first receipt of this message
diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.28/man/systemd.unit.xml systemd-252.29/man/systemd.unit.xml
--- systemd-252.28/man/systemd.unit.xml	2024-07-07 11:52:10.0 +0100
+++ systemd-252.29/man/systemd.unit.xml	2024-07-25 13:45:32.0 +0100
@@ -165,13 +165,13 @@
 section. When the unit is enabled, symlinks will be created for those names, and removed when the unit is
 disabled. For example, reboot.target specifies
 Alias=ctrl-alt-del.target, so when enabled, the symlink
-/etc/systemd/system/ctrl-alt-del.service pointing to the
+/etc/systemd/system/ctrl-alt-del.target pointing to the
 reboot.target file will be created, and when
 CtrlAltDel is invoked,
-systemd will look for the ctrl-alt-del.service and execute
-reboot.service. systemd does not look at the [Install] section at
-all during normal operation, so any directives in that section only have an effect through the symlinks
-created during enablement.
+systemd will look for ctrl-alt-del.target, follow the symlink to
+reboot.target, and execute reboot.service as part

Bug#1076432: systemd: [networkd] incorrect IPv6 address generation

[Luca Boccassi]

Control: tags -1 upstream

On Tue, 23 Jul 2024 19:45:33 +0300 =?UTF-
8?Q?Martin=2D=C3=89ric_Racine?=  wrote:
> Please note that if you only reply to the bug itself, the reporter
> will never know that you requested more information.
> 
> On Tue, 16 Jul 2024 11:37:43 +0100 Luca Boccassi 
wrote:
> > Control: tags -1 moreinfo
> >
> > On Tue, 16 Jul 2024 13:29:36 +0300 =?utf-8?q?Martin-
=C3=89ric_Racine?=
> >  wrote:
> > > Package: systemd
> > > Version: 252.26-1~deb12u2
> > > Severity: important
> > > Tags: ipv6
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > I have enabled networkd and created the following
> > /etc/systemd/network/dhcp.network:
> > >
> > > [Match]
> > > Name=en* wl*
> > >
> > > [Network]
> > > DHCP=yes
> > > IPv6PrivacyExtensions=yes
> > > IPv6LinkLocalAddressGenerationMode=stable-privacy
> > >
> > > Two issues:
> > >
> > > 1) networkd creates a new link address with the stable-privacy
flag,
> > in addition to the existing one created by the kernel on bootup.
> > > 2) Regardless, the stable-privacy flag is not inherited by the
> > mngtmpaddr address. It steadfastly uses an EUI64 address.
> >
> > Can you reproduce in testing/unstable?
> 
> Yes. It still ignores the fe80 created by the kernel at boottime with
> the stable-privacy flag, it still creates an additional one, and it
> still creates a public address with EUI64 instead of stable-privacy.

Ok, then please open an issue upstream, after gathering debug level
logs (SYSTEMD_LOG_LEVEL=debug env var in networkd) and attach them too,
and also attach the "ip addr" output

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1076616: systemd-container: Bind mounts not working

[Luca Boccassi]

Control: tags -1 -moreinfo
Control: close -1

The logs are showing what the issues are:

/var/lib/machines/debian-sid.nspawn:4: Unknown key 'PrivateUsersChown' in 
section [Exec], ignoring.
Ignoring TemporaryFileSystem=, Bind= and BindReadOnly= settings, file 
/var/lib/machines/debian-sid.nspawn is not trusted.
Ignoring network settings, file /var/lib/machines/debian-sid.nspawn is not 
trusted.
Ignoring PrivateUsers= and PrivateUsersChown= settings, file 
/var/lib/machines/debian-sid.nspawn is not trusted.

One setting is in the wrong section, and others are ignored because of
the cmdline used. Please fix the settings and the cmdline and then
update the wiki page accordingly.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#675731: base-files: os-release and debian_version make testing and unstable indistinguishable

[Luca Boccassi]

Hi Santiago,

There have been many bugs over the years, and this issue keep biting.
Jut fell into it yet again.
Please, let's fix this, once and for all. os-release is the Linux
standard for identifying images, and we need to make it useful for our
users for testing and unstable too, not just for stable.

Currently in unstable/testing os-release contains:

PRETTY_NAME="Debian GNU/Linux trixie/sid"
VERSION_CODENAME=trixie

And debian_version contains:

trixie/sid

This is confusing and breaks all the software out there that needs to
distinguish between releases. And yes, they are different releases, as
the archives are different and separate. And when we create an unstable
or testing image, we choose one OR the other, not both, not either.

debootstrap unstable

or

debootstrap testing

Then after creating the image, we lose the ability to figure out which
is which, and have to resort to ugly hacks like grepping in
/etc/apt/sources.list, praying that it doesn't contain both
repositories.

This needs to be fixed. Here is a concrete proposal:

Move os-release and debian_version to a separate source package, in a
separate binary package, that base-files will depend on.
At the beginning of a cycle, upload os-release containing, for example:

VERSION_CODENAME=trixie
PRETTY_NAME="Debian GNU/Linux trixie"

and debian_version:

trixie

Give it urgency=high and let it migrate quickly. Then, upload again
immediately, with:

VERSION_CODENAME=sid
PRETTY_NAME="Debian GNU/Linux sid"

and debian_version:

sid

and file an RC bug on it to stop it from migrating.

At the end of the cycle, repeat and add the VERSION_ID and other fields
if you want to only add them on release day.

With 2 uploads every ~2 years, the problem is solved, unstable can be
identified as unstable, and testing can be identified as testing. For
~4 days in a 2 years period, unstable will have a wrong identifier.
Compared to the current situation when it is always wrong, we can live
with it I am sure. It can be reduced to 2 days and 1 upload if we
immediately add the full next-release os-release content at the
beginning of the cycle.

If you do not have the time to work on the new package, as the upstream
maintainer of the os-release spec, I volunteer to take care of it, if
you wish it.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#931197: base-files: Include minor version in /etc/os-release

[Luca Boccassi]

On Mon, 15 Apr 2024 13:19:00 +0200 Santiago Vila 
wrote:
> severity 931197 normal
> thanks
> 
> I consider this to be a normal bug, and will try to discuss with
Release Managers
> to see if we can change it for trixie.

As the maintainer of the os-release spec: Ansgar is right, the current
setup is correct. Please do not add minor versions or patch versions to
VERSION_ID. That field is supposed to identify whether you are on
Bookworm or Bullseye or Trixie, not the minor patch levels in between.
It would be a bug to change this, and it would break A LOT of parsers
that expect just the Debian version.

What you can do, is add another field. The spec is intentionally
extensible and downstream can add any fields they like, just add a new
one prefixed with DEBIAN_ to namespace it, and then you can add
whatever you want in it. It could be DEBIAN_VERSION_FULL_ID=12.1 or
DEBIAN_VERSION_MINOR_ID=1 or any other combination.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1076616: systemd-container: Bind mounts not working

[Luca Boccassi]

Control: tags -1 unreproducible moreinfo

On Sat, 20 Jul 2024 01:21:45 +0700 Josh Santos 
wrote:
> Package: systemd-container
> Version: 252.26-1~deb12u2
> Severity: normal
> X-Debbugs-Cc: j...@omnidapps.com
> 
> Dear Maintainer,
>    * What led up to the situation?
>    Running a container using nspawn with a bind mount such as is
described here: https://wiki.debian.org/Packaging/Pre-Requisites/nspawn
> 
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>    systemctl start systemd-nspawn@debian-sid
> 
>    * What was the outcome of this action?
>    Launches fine, but bind mount is non-existent.
> 
>    * What outcome did you expect instead?
>    Expected the bind mount to be present
> 
>    * Additional context: pirate_praveen on DebConf IRC confirms this
happens on their system which is running Debian Sid.

This is working just fine here on stable:

$ mkdir -p /tmp/foo/bar
$ sudo systemd-nspawn --quiet --bind /tmp/foo --directory ~/images/noble/ ls -l 
/tmp/foo
total 0
drwxr-xr-x 2 1000 1000 40 Jul 19 23:09 bar

so you need to attach the exact command you are using, run it with
SYSTEMD_LOG_LEVEL=debug and also attach the logs

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1076610: shorewall: hardcoded iproute2 binary path

[Luca Boccassi]

Source: shorewall
Severity: important

With the latest iproute2 upload the legacy /sbin/ip symlink is gone.
/bin/ip has been available since Buster, so please use that or better
rely on $PATH.

https://codesearch.debian.net/search?q=%2Fsbin%2Fip%5CW+package%3Ashorewall=0

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#981799: Bug#981937: dh-sysuser: Reduce negative impact and assess overall utility

[Luca Boccassi]

Control: tags 981799 -moreinfo
Control: tags 981799 patch
Control: severity 981799 serious
Control: severity 981937 serious

On Fri, 28 Jun 2024 00:44:01 +0200 lorenzo 
wrote:
> > That cycle has happened. How about removing it now?
> I'm open to consider further changes but the removal request
> is a wontfix.
> 
> Lorenzo

We have now finished painstakingly removing dh-sysuser usage from all
packages in the archive, bar runit which is maintaned by the dh-sysuer
maintainer, for which a patch has been available in #981799 for 3 years
now.

With Trixie's cycle coming to an end soon-ish, it is now time to either
apply the provided runit patch, or alternatively merge whatever remains
of dh-sysuser inside runit so that it can continue to use it
individually, without it being available for other packages in the
archive and being mistakenly picked up again.

Having competing packaging APIs is confusing and detrimental to the
project. The standard interface the project has adopted for declarative
user/group creation is dh_installsysusers provided by debhelper. Having
a similarly named API, that is incompatible, does not actually use the
sysuser.d interface despite being named after it, and does not provide
the same advantages, is confusing for developers who might pick it by
mistake, and leads to needless divergence and bugs.

Hence I am bumping the severity of both bugs to serious, so that this
does not ship in Trixie. Please apply the suggested change, or an
equivalent one, in runit, and then please file an RM bug for dh-
sysuser. Thank you.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1076455: ITP: partman-dps -- apply Discoverable Partitions Specification labels to GPT disks during installation

[Luca Boccassi]

Package: wnpp
Severity: wishlist
Owner: Luca Boccassi 

* Package name: partman-dps
  Version : 0.1
  Upstream Author : Luca Boccassi 
* URL : https://salsa.debian.org/installer-team/partman-dps
* License : GPL-2.0-or-later
  Programming Lang: shell
  Description : debian-installer component to apply GPT labels following

https://uapi-group.org/specifications/specs/discoverable_partitions_specification/

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1076432: systemd: [networkd] incorrect IPv6 address generation

[Luca Boccassi]

Control: tags -1 moreinfo

On Tue, 16 Jul 2024 13:29:36 +0300 =?utf-8?q?Martin-=C3=89ric_Racine?=
 wrote:
> Package: systemd
> Version: 252.26-1~deb12u2
> Severity: important
> Tags: ipv6
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I have enabled networkd and created the following
/etc/systemd/network/dhcp.network:
> 
> [Match]
> Name=en* wl*
> 
> [Network]
> DHCP=yes
> IPv6PrivacyExtensions=yes
> IPv6LinkLocalAddressGenerationMode=stable-privacy
> 
> Two issues:
> 
> 1) networkd creates a new link address with the stable-privacy flag,
in addition to the existing one created by the kernel on bootup.
> 2) Regardless, the stable-privacy flag is not inherited by the
mngtmpaddr address. It steadfastly uses an EUI64 address.

Can you reproduce in testing/unstable?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1069425: socket_wrapper and the time_t 64-bit is hard

[Luca Boccassi]

On Mon, 29 Apr 2024 13:03:22 +1200 Andrew Bartlett 
wrote:
> Just a warning that trying to brute force a fix for this is likely to
> end badly.  A lot of developer time was spent to get to this current
> delicate situation, which relied on the narrow behaviour that is now
> eliminated by the Debian time_t 64 transition rules. 
> 
> Socket-wrapper starts with:
> 
> /*
>  * Make sure we do not redirect (f)open(at)() or fcntl() to their
64bit
>  * variants
>  */
> #undef _FILE_OFFSET_BITS
> 
> This was added in 
>
https://gitlab.com/cwrap/socket_wrapper/-/commit/bbe14cc3200ca553b13ed49357e2e88ba487eeaa
> 
> Setting  -D_FILE_OFFSET_BITS=64 will break the fcntl64 wrapper and so
> break Samba's tests. 
> 
> I don't know if there is a good fix for this actually.  
> 
> Andrew Bartlett

How about simply dropping armv7 support from socket-wrapper and uid-
wrapper? Having architectures that are actually used being blocked by
these issues is suboptimal at best

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1076230: clapper: after upgrading to 0.6.1, binary and .desktop file can no longer be found

[Luca Trevisani]

Package: clapper
Version: 0.6.1-1
Severity: important
X-Debbugs-Cc: luc4trevis...@libero.it

Dear Maintainer,
after upgrading to 0.6.1, binary and .desktop file can no longer be found, 
neither clapper deb package filelist shows them 
http://packages.debian.org/sid/amd64/clapper/filelist

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.9.8-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages clapper depends on:
ii  gir1.2-adw-11.5.2-1
ii  gir1.2-gst-plugins-base-1.0 1.24.5-1
ii  gir1.2-gstreamer-1.01.24.5-1
ii  gir1.2-gtk-4.0  4.12.5+ds-6+b1
ii  gir1.2-soup-3.0 3.4.4-5+b1
ii  gstreamer1.0-plugins-good   1.24.5-1
ii  libc6   2.38-14
ii  libglib2.0-0t64 2.80.4-1
ii  libgraphene-1.0-0   1.10.8-3+b1
ii  libgstreamer-gl1.0-01.24.5-1
ii  libgstreamer-plugins-base1.0-0  1.24.5-1
ii  libgstreamer1.0-0   1.24.5-1
ii  libgtk-4-1  4.12.5+ds-6+b1

Versions of packages clapper recommends:
ii  gstreamer1.0-libav1.24.5-1
ii  gstreamer1.0-plugins-bad  1.24.5-1+b1

clapper suggests no packages.

-- no debconf information

Bug#1076127: (build-)dependency on removed python3-distutils

[Luca Boccassi]

Control: tags -1 moreinfo upstream
Control: severity -1 wishlist

On Thu, 11 Jul 2024 08:08:05 +0200 Matthias Klose 
wrote:
> Source: azure-cli
> Version: 2.62.0-1
> Severity: serious
> Tags: sid trixie
> User: debian-pyt...@lists.debian.org
> Usertags: python3.12
> 
> there are (build-)dependency on the now removed python3-distutils.
> please remove them

It's a runtime dependency, and it is still used, so it cannot just be
removed. Have you file an upstream issue, or better yet, sent a PR
upstream to provide an alternative?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1075818: ubuntu-keyring: upload to bookworm-backports

[Luca Boccassi]

Control: tags -1 pending

n Fri, 05 Jul 2024 19:45:20 +0100 Luca Boccassi 
wrote:
> Source: ubuntu-keyring
> Severity: wishlist
> X-Debbugs-Cc: x...@debian.org
> 
> Hello,
> 
> ubuntu-keyring missed the bookworm train due to some RC bugs. Now
that
> it is bug in testing, I'd like to have it in backports. Would you be
ok
> with it?
> 
> I am happy to NMU it myself if you are busy.
> 
> Thanks!

Hi,

I have NMU'ed to DELAYED/7 for bookworm-backports, debdiff is just the
changelog entry. Let me know if you prefer me to cancel this.


--- ubuntu-keyring-2023.11.28.1/debian/changelog2023-11-28 
15:02:25.0 +
+++ ubuntu-keyring-2023.11.28.1/debian/changelog2024-07-10 
12:09:34.0 +0100
@@ -1,3 +1,10 @@
+ubuntu-keyring (2023.11.28.1-0.2~bpo12+1) bookworm-backports; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bookworm-backports.
+
+ -- Luca Boccassi   Wed, 10 Jul 2024 12:09:34 +0100
+
 ubuntu-keyring (2023.11.28.1-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1076059: RM: azure-cosmos-python -- ROM; deprecated and replaced by python-azure

[Luca Boccassi]

Package: ftp.debian.org
Severity: normal

Hi,

azure-cosmos-python has long been deprecated, as it is replaced
by a module from src:python-azure.

It will be removed from testing via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052507 and the last
reverse dependency, azure-cli, will drop it with version 2.62.0-1

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1075898: bookworm-pu: package systemd/252.28-1~deb12u1

[Luca Boccassi]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

Dear Release Team,

We would like to upload the latest stable point release of systemd 252
to bookworm-p-u. Stable release branches are maintained upstream with
the intention of providing bug fixes only and no compatibility
breakages, and with automated non-trivial CI jobs that also cover
Debian and Ubuntu. I have already uploaded to p-u.

There are no packaging changes. Debdiff attached.
The list of commits included can be seen at:

https://github.com/systemd/systemd-stable/compare/v252.27...v252.28

-- 
Kind regards,
Luca Boccassi
diff -Nru systemd-252.27/debian/changelog systemd-252.28/debian/changelog
--- systemd-252.27/debian/changelog	2024-06-25 21:25:25.0 +0100
+++ systemd-252.28/debian/changelog	2024-07-07 11:56:20.0 +0100
@@ -1,3 +1,9 @@
+systemd (252.28-1~deb12u1) bookworm; urgency=medium
+
+  * New upstream version 252.28 (Closes: #1074789)
+
+ -- Luca Boccassi   Sun, 07 Jul 2024 11:56:20 +0100
+
 systemd (252.27-1~deb12u1) bookworm; urgency=medium
 
   * New upstream version 252.27
diff -Nru systemd-252.27/docs/CODING_STYLE.md systemd-252.28/docs/CODING_STYLE.md
--- systemd-252.27/docs/CODING_STYLE.md	2024-06-25 21:13:13.0 +0100
+++ systemd-252.28/docs/CODING_STYLE.md	2024-07-07 11:52:10.0 +0100
@@ -54,6 +54,18 @@
   }
   ```
 
+- Function return types should be seen/written as whole, i.e. write this:
+
+  ```c
+  const char* foo(const char *input);
+  ```
+
+  instead of this:
+
+  ```c
+  const char *foo(const char *input);
+  ```
+
 - Single-line `if` blocks should not be enclosed in `{}`. Write this:
 
   ```c
@@ -163,7 +175,7 @@
 
   ```c
   static int foobar_frobnicate(
-  Foobar* object,/* the associated mutable object */
+  Foobar *object,/* the associated mutable object */
   const char *input, /* immutable input parameter */
   char **ret_frobnicated) {  /* return parameter */
   …
diff -Nru systemd-252.27/.github/workflows/mkosi.yml systemd-252.28/.github/workflows/mkosi.yml
--- systemd-252.27/.github/workflows/mkosi.yml	2024-06-25 21:13:13.0 +0100
+++ systemd-252.28/.github/workflows/mkosi.yml	2024-07-07 11:52:10.0 +0100
@@ -55,6 +55,11 @@
   if: ${{ matrix.release == '9-stream' }}
   run: sudo sed -i '/add_packages/s/systemd-boot/systemd/g' /usr/local/lib/python3.10/dist-packages/mkosi/__init__.py
 
+# FIXME: temporary workaround for debootstrap issue of Debian testing/sid on Jammy
+- name: Fix Debian testing/sid
+  if: ${{ matrix.distro == 'debian' && matrix.release == 'testing' }}
+  run: sudo sed -i 's/merged-usr/no-merged-usr/g' /usr/local/lib/python3.10/dist-packages/mkosi/__init__.py
+
 - name: Install
   run: sudo apt-get update && sudo apt-get install --no-install-recommends python3-pexpect python3-jinja2
 
diff -Nru systemd-252.27/LICENSES/README.md systemd-252.28/LICENSES/README.md
--- systemd-252.27/LICENSES/README.md	2024-06-25 21:13:13.0 +0100
+++ systemd-252.28/LICENSES/README.md	2024-07-07 11:52:10.0 +0100
@@ -13,7 +13,14 @@
 the systemd project source tree.
 
 Unless otherwise noted, the systemd project sources are licensed under the terms
-and conditions of the **GNU Lesser General Public License v2.1 or later**.
+and conditions of
+**LGPL-2.1-or-later** (**GNU Lesser General Public License v2.1 or later**).
+
+Unless otherwise noted, compiled programs and all shared or static libraries
+include sources under **LGPL-2.1-or-later** along with more permissive
+licenses, and are effectively licensed **LGPL-2.1-or-later**.
+systemd-udevd and other udev helper programs also include sources under
+**GPL-2.0-or-later**, and are effectively licensed **GPL-2.0-or-later**.
 
 New sources that cannot be distributed under LGPL-2.1-or-later will no longer
 be accepted for inclusion in the systemd project to maintain license uniformity.
@@ -22,8 +29,9 @@
 
 The following exceptions apply:
 
- * some udev sources under src/udev/ are licensed under **GPL-2.0-or-later**, so the
-   udev binaries as a whole are also distributed under **GPL-2.0-or-later**.
+ * some sources under src/udev/ are licensed under **GPL-2.0-or-later**,
+   so all udev programs (`systemd-udevd`, `udevadm`, and the udev builtins
+   and test programs) are also distributed under **GPL-2.0-or-later**.
  * the header files contained in src/basic/linux/ and src/shared/linux/ are copied
verbatim from the Linux kernel source tree and are licensed under **GPL-2.0 WITH
Linux-syscall-note** and are used within the scope of the Linux-syscall-note
diff -Nru systemd-252.27/man/file-hierarchy.xml systemd-252.28/man/file-hierarchy.xml
--- systemd-252.27/man/file-hierarchy.xml	2024-06-25 21:13:13.0 +0100
+++ systemd

Bug#1042969: vsftpd: Deletes the ftp user on remove, breaking other packages

[Luca Boccassi]

Control: tags -1 pending

On Thu, 03 Aug 2023 08:54:40 -0500 John Goerzen 
wrote:
> Package: vsftpd
> Version: 3.0.3-13+b2
> Severity: critical
> Justification: breaks unrelated software
> 
> On removing this package, it indiscriminately removes the ftp user.
> Unfortunately, that user was required for iksd in package ckermit to
work, so
> this broke the unrelated ckermit package.
> 
> It is likely that there are other packages and users that would also
> use the ftp user.  It should not be removed on package removal.

Given this will cause the autoremoval of several of my packages, I've
NMU'ed to DELAYED/7 with a fix to stop removing the ftp user/group in
the postinst. debdiff attached.

-- 
Kind regards,
Luca Boccassi
diff -Nru vsftpd-3.0.3/debian/changelog vsftpd-3.0.3/debian/changelog
--- vsftpd-3.0.3/debian/changelog	2021-03-03 21:05:45.0 +
+++ vsftpd-3.0.3/debian/changelog	2024-07-07 13:39:11.0 +0100
@@ -1,3 +1,10 @@
+vsftpd (3.0.3-13.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Stop removing ftp user/group on removal (Closes: #1042969)
+
+ -- Luca Boccassi   Sun, 07 Jul 2024 13:39:11 +0100
+
 vsftpd (3.0.3-13) unstable; urgency=medium
 
   [Frey Daniel]
diff -Nru vsftpd-3.0.3/debian/vsftpd.postrm vsftpd-3.0.3/debian/vsftpd.postrm
--- vsftpd-3.0.3/debian/vsftpd.postrm	2015-03-03 17:40:36.0 +
+++ vsftpd-3.0.3/debian/vsftpd.postrm	2024-07-07 13:39:07.0 +0100
@@ -23,22 +23,8 @@
 
 case "${1}" in
 	remove)
-		_USERNAME="ftp"
-		_GROUPNAME="${_USERNAME}"
 		_DIRECTORY="/srv/ftp"
 
-		pathfind deluser
-		if [ $? = 0 ] ;
-		then
-			deluser --quiet --system ${_USERNAME}
-		fi
-
-		pathfind delgroup
-		if [ $? = 0 ] ;
-		then
-			delgroup --quiet --system --only-if-empty ${_GROUPNAME} || true
-		fi
-
 		if [ -d "${_DIRECTORY}" ]
 		then
 			rmdir --ignore-fail-on-non-empty "${_DIRECTORY}" || true


signature.asc
Description: This is a digitally signed message part

Bug#1075882: systemd + crypttab not working after 256-2

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Sat, 06 Jul 2024 17:58:17 -0400 Wesley Schwengle
 wrote:
> Package: systemd
> Version: 256.2-1
> Severity: important
> X-Debbugs-Cc: wes...@schwengle.net
> 
> Dear Maintainer,
> 
> Today after an upgrade of systemd my machine was unable to reboot
because it
> failed to read /etc/crypttab.
> 
> In /etc/crypttab I have a second disk which is encrypted (which is my
/home).
> My fstab entry for /home could not be mounted, resulting in a
timeout.
> 
> I did see a recommendation for a package that wasn't going to be
installed:
> systemd-cryptsetup.

Recommends are installed by default intentionally, if you choose to
turn that default off, you need to make sure you install every you need
for optional features manually, there's just no way around it.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1074014: encode mandatory merged-/usr into policy

[Luca Boccassi]

On Fri, 21 Jun 2024 20:27:56 +0200 Helmut Grohne 
wrote:
> Package: debian-policy
> Version: 4.7.0.0
> X-Debbugs-Cc:
bl...@debian.org,m...@debian.org,mbi...@debian.org,z...@debian.org
> 
> Hi,
> 
> given the progress we have made with /usr-move and DEP17, I think it
is
> time to consider encoding the changes into policy. As of this
writing,
> there are 216 source packages in unstable that still install into
> aliased locations and their number has been dropping since a while.
All
> but very few packages have bug reports of important severity and will
> have their severity upgraded to serious on August 6th.
> 
> Generally speaking DEP17 says that no package should install any
files
> below /bin/, /lib*/ and /sbin/. Doing so would amount to a symlink vs
> directory conflict between base-files which now installs symlinks at
the
> relevant locations. What happens with these locations depends on the
> order of unpacks. In many cases, this is not a problem, because
> base-files is essential and thus unpacked early. Other than that,
> running dpkg-deb -x foo.deb / causes these symlinks to be overwritten
> with actual directories possibly breaking the installation. We
currently
> have mitigations for these problems in place and plan to drop them
after
> trixie.
> 
> For these reasons, I propose changing section 10.1 and encoding the
> avoidance of symlink vs directory conflicts into policy. To get a
> discussion going, I suggest the following update.
> 
> - To support merged-/usr systems, packages must not install files in
both
> - /path and /usr/path. For example, a package must not install both
> - /bin/example and /usr/bin/example.
> + Since base-files implements mandatory merged-/usr by installing the
> + aliasing symbolic links, other packages must not install files into
> + aliased paths such as /bin, /lib, /lib* or /sbin. The package
manager is
> + not prepared to deal with such aliasing and in prohibiting the
> + installation into aliased locations, we avoid triggering undefined
> + behaviour. Conversely, packages may assume that /bin, /lib and
/sbin are
> + symlinks at all times and that their files below /usr/bin, /usr/lib
and
> + /usr/sbin are also accessible via their aliased locations.

Seconded

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions

[Luca Boccassi]

On Wed, 14 Dec 2022 15:27:18 +0100 Juri Grabowski 
wrote:
> Package: wnpp
> Version: 1.79
> Severity: wishlist
> Owner: Juri Grabowski 
> X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@jugra.de
> 
> * Package name    : distribution-gpg-keys
>   Version : 1.7.9
>   Upstream Author : Miroslav Suchý 
> * URL : https://github.com/xsuchy/distribution-gpg-keys/
> * License : CC0-1.0
>   Programming Lang: data
>   Description : GPG keys by various Linux distributions
> 
> used by various Linux distributions to sign packages.
> 
> needed by mock/3.5 and I need a sponsor for this package. See current
packaging in
> https://salsa.debian.org/pkg-rpm-team/distribution-gpg-keys
> After I know ITP bug number I upload this source package to
> https://mentors.debian.net/package/distribution-gpg-keys/

This has stalled for too long, I'll update the package as it is on
Salsa and upload it shortly. I'll set it to be team maintained in pkg-
rpm-team and keep you as an uploader, given it's already stored there
on Salsa, seems like a good fit.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1075818: ubuntu-keyring: upload to bookworm-backports

[Luca Boccassi]

Source: ubuntu-keyring
Severity: wishlist
X-Debbugs-Cc: x...@debian.org

Hello,

ubuntu-keyring missed the bookworm train due to some RC bugs. Now that
it is bug in testing, I'd like to have it in backports. Would you be ok
with it?

I am happy to NMU it myself if you are busy.

Thanks!

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1075759: isa-support: please add armv8 + crc support package

[Luca Boccassi]

On Fri, 5 Jul 2024 at 18:06, Bastien Roucariès  wrote:
>
> Le jeudi 4 juillet 2024, 12:51:01 UTC Luca Boccassi a écrit :
> Hi,
>
> > Source: isa-support
> > Severity: wishlist
> > X-Debbugs-Cc: pkg-dpdk-de...@lists.alioth.debian.org
> >
> > Dear Maintainer(s),
> >
> > For src:dpdk we would like to depend on a higher arm64 baseline, which
> > includes the crc extension. Would it be possible to add a new package
> > that matches it?
> >
> > For reference, we compile with: -march=armv8-a+crc
>
> I will really prefer to add an arch level like armv8.1-a if possible.
>
> Does it exist some processor with crc without ‘+lse’, ‘+rdma’ ?

Sorry, I am not an expert, I do not know. I am fine with a "wider"
flag if it includes crc, that would work just fine.

> Next question how can I detect it ?

Sorry, I am really not sure, I just know the requirement from the build flags.

Bug#1075759: isa-support: please add armv8 + crc support package

[Luca Boccassi]

Source: isa-support
Severity: wishlist
X-Debbugs-Cc: pkg-dpdk-de...@lists.alioth.debian.org

Dear Maintainer(s),

For src:dpdk we would like to depend on a higher arm64 baseline, which
includes the crc extension. Would it be possible to add a new package
that matches it?

For reference, we compile with: -march=armv8-a+crc

https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html

Thank you!

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1074789: [Pkg-utopia-maintainers] Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists

[Luca Boccassi]

On Wed, 03 Jul 2024 23:10:30 +0100 Luca Boccassi 
wrote:
> On Wed, 03 Jul 2024 22:58:33 +0100 Luca Boccassi 
> wrote:
> > On Wed, 3 Jul 2024 21:26:36 +0200 Michael Biebl 
> > wrote:
> > > Am 03.07.24 um 21:00 schrieb Lionel Élie Mamane:
> > > > On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:
> > > > 
> > > >>>>> connect(5, {sa_family=AF_UNIX,
> > sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1
> > ECONNREFUSED (Connection refused)
> > > > 
> > > >> systemd should be listening on this socket
> > > > 
> > > > Well, on no less than four different Debian machines, it does
> not.
> > > > 
> > > >> $ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
> > > >> COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE
> NAME
> > > >> systemd   1 root   28u  unix 0x73ac41e2  0t0 8696
> > > >> /run/systemd/userdb/io.systemd.DynamicUser type=STREAM
(LISTEN)
> > > > 
> > > > Isn't that on a machine where systemd-userdb is installed
maybe?
> > The
> > > > installation of that package triggers the systemd binary to
> listen?
> > > 
> > > No, systemd-userdb is not installed and as you can see from the
> above
> > > output it's actually systemd which listens on that socket.
> > 
> > I can reproduce it by mounting a tmpfs on /run/systemd/userdb/
_and_
> > creating an empty io.systemd.DynamicUser file on it. Maybe it
should
> > not abort like that, however, if you have the directory in /run/
> _and_
> > the socket file exists _but_ nothing is listening on it, then your
> > machine is broken in some way. If the directory/socket are missing
> they
> > are just skipped gracefully.
> 
> I'm not sure what's the alternative here - if consulting NSS fails
for
> some local reasons because the machine is broken/misconfigured, I am
> not sure if it should just ignore it and continue it. If NSS is
> configured and is supposed to work, but doesn't for some
> temporary/local reason, you might end up creating a duplicated
> user/group, and I am not really sure that's better than bailing out
> without touching anything.

Consensus seems to be that in this bad situation it's slightly better
to complain loudly and continue, so the next point release will contain
a fix to this effect. You should still figure out how you ended up with
a dead af_unix socket in the first place, as that's a sign of something
seriously wrong on that machine.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1075733: login: broadcasted wall message no longer shown

[Luca Boccassi]

Package: login
Version: 1:4.15.2-3

Dear Maintainer(s),

since the new login version 1:4.15.2-3 has migrated to testing, an
upstream systemd test has started failing.
The issue is that the "broadcast" wall message on shutdown is no longer
detected by the test script running pexpect, a reboot is scheduled, and
the test sees "Reboot scheduled for Wed 2024-07-03 11:14:42 UTC, ..."
coming through. Before the change, it also could see "Broadcast message
from ..." but now it doesn't. Downgrading login to the previous version
fixes the issue.

This is the test case:
https://github.com/systemd/systemd/blob/main/test/units/TEST-69-SHUTDOWN.py

It opens a new tty with "login -f root" and then issues "shutdown -r"
on it. The same thing can be verified manually.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1074789: [Pkg-utopia-maintainers] Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists

[Luca Boccassi]

On Wed, 03 Jul 2024 22:58:33 +0100 Luca Boccassi 
wrote:
> On Wed, 3 Jul 2024 21:26:36 +0200 Michael Biebl 
> wrote:
> > Am 03.07.24 um 21:00 schrieb Lionel Élie Mamane:
> > > On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:
> > > 
> > >>>>> connect(5, {sa_family=AF_UNIX,
> sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1
> ECONNREFUSED (Connection refused)
> > > 
> > >> systemd should be listening on this socket
> > > 
> > > Well, on no less than four different Debian machines, it does
not.
> > > 
> > >> $ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
> > >> COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE
NAME
> > >> systemd   1 root   28u  unix 0x73ac41e2  0t0 8696
> > >> /run/systemd/userdb/io.systemd.DynamicUser type=STREAM (LISTEN)
> > > 
> > > Isn't that on a machine where systemd-userdb is installed maybe?
> The
> > > installation of that package triggers the systemd binary to
listen?
> > 
> > No, systemd-userdb is not installed and as you can see from the
above
> > output it's actually systemd which listens on that socket.
> 
> I can reproduce it by mounting a tmpfs on /run/systemd/userdb/ _and_
> creating an empty io.systemd.DynamicUser file on it. Maybe it should
> not abort like that, however, if you have the directory in /run/
_and_
> the socket file exists _but_ nothing is listening on it, then your
> machine is broken in some way. If the directory/socket are missing
they
> are just skipped gracefully.

I'm not sure what's the alternative here - if consulting NSS fails for
some local reasons because the machine is broken/misconfigured, I am
not sure if it should just ignore it and continue it. If NSS is
configured and is supposed to work, but doesn't for some
temporary/local reason, you might end up creating a duplicated
user/group, and I am not really sure that's better than bailing out
without touching anything.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1074789: [Pkg-utopia-maintainers] Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists

[Luca Boccassi]

On Wed, 3 Jul 2024 21:26:36 +0200 Michael Biebl 
wrote:
> Am 03.07.24 um 21:00 schrieb Lionel Élie Mamane:
> > On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:
> > 
> >>>>> connect(5, {sa_family=AF_UNIX,
sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1
ECONNREFUSED (Connection refused)
> > 
> >> systemd should be listening on this socket
> > 
> > Well, on no less than four different Debian machines, it does not.
> > 
> >> $ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
> >> COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> >> systemd   1 root   28u  unix 0x73ac41e2  0t0 8696
> >> /run/systemd/userdb/io.systemd.DynamicUser type=STREAM (LISTEN)
> > 
> > Isn't that on a machine where systemd-userdb is installed maybe?
The
> > installation of that package triggers the systemd binary to listen?
> 
> No, systemd-userdb is not installed and as you can see from the above
> output it's actually systemd which listens on that socket.

I can reproduce it by mounting a tmpfs on /run/systemd/userdb/ _and_
creating an empty io.systemd.DynamicUser file on it. Maybe it should
not abort like that, however, if you have the directory in /run/ _and_
the socket file exists _but_ nothing is listening on it, then your
machine is broken in some way. If the directory/socket are missing they
are just skipped gracefully.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1074478: bookworm-pu: package systemd/252.27-1~deb12u1

[Luca Boccassi]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

Dear Release Team,

We would like to upload the latest stable point release of systemd 252
to bookworm-p-u. Stable release branches are maintained upstream with
the intention of providing bug fixes only and no compatibility
breakages, and with automated non-trivial CI jobs that also cover
Debian and Ubuntu. I have already uploaded to p-u.

There are no packaging changes. Debdiff attached.
The list of commits included can be seen at:

https://github.com/systemd/systemd-stable/compare/v252.26...v252.27

-- 
Kind regards,
Luca Boccassi
diff -Nru systemd-252.26/debian/changelog systemd-252.27/debian/changelog
--- systemd-252.26/debian/changelog	2024-06-16 10:44:31.0 +0100
+++ systemd-252.27/debian/changelog	2024-06-25 21:25:25.0 +0100
@@ -1,3 +1,9 @@
+systemd (252.27-1~deb12u1) bookworm; urgency=medium
+
+  * New upstream version 252.27
+
+ -- Luca Boccassi   Tue, 25 Jun 2024 21:25:25 +0100
+
 systemd (252.26-1~deb12u2) bookworm; urgency=medium
 
   [ Gioele Barabucci ]
diff -Nru systemd-252.26/man/systemd-tmpfiles.xml systemd-252.27/man/systemd-tmpfiles.xml
--- systemd-252.26/man/systemd-tmpfiles.xml	2024-05-28 11:31:24.0 +0100
+++ systemd-252.27/man/systemd-tmpfiles.xml	2024-06-25 21:13:13.0 +0100
@@ -48,8 +48,8 @@
   
 Description
 
-systemd-tmpfiles creates, deletes, and cleans up volatile and temporary files
-and directories, using the configuration file format and location specified in
+systemd-tmpfiles creates, deletes, and cleans up files and directories, using
+the configuration file format and location specified in
 tmpfiles.d5. It must
 be invoked with one or more options --create, --remove, and
 --clean, to select the respective subset of operations.
diff -Nru systemd-252.26/rules.d/99-systemd.rules.in systemd-252.27/rules.d/99-systemd.rules.in
--- systemd-252.26/rules.d/99-systemd.rules.in	2024-05-28 11:31:24.0 +0100
+++ systemd-252.27/rules.d/99-systemd.rules.in	2024-06-25 21:13:13.0 +0100
@@ -10,6 +10,8 @@
 ACTION=="remove", GOTO="systemd_end"
 
 SUBSYSTEM=="tty", KERNEL=="tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*", TAG+="systemd"
+# Exclude 8250 serial ports with a zero IO port, as they are not usable until "setserial /dev/ttySxxx port …" is invoked.
+SUBSYSTEM=="tty", KERNEL=="ttyS*", DRIVERS=="serial8250", ATTR{port}=="0x0", ENV{SYSTEMD_READY}="0"
 KERNEL=="vport*", TAG+="systemd"
 
 SUBSYSTEM=="ptp", TAG+="systemd"
diff -Nru systemd-252.26/src/basic/missing_loop.h systemd-252.27/src/basic/missing_loop.h
--- systemd-252.26/src/basic/missing_loop.h	2024-05-28 11:31:24.0 +0100
+++ systemd-252.27/src/basic/missing_loop.h	2024-06-25 21:13:13.0 +0100
@@ -20,5 +20,5 @@
 #endif
 
 #ifndef LOOP_SET_STATUS_SETTABLE_FLAGS
-#define LOOP_SET_STATUS_SETTABLE_FLAGS (LO_FLAGS_AUTOCLEAR | LO_FLAGS_PARTSCAN | LO_FLAGS_DIRECT_IO)
+#define LOOP_SET_STATUS_SETTABLE_FLAGS (LO_FLAGS_AUTOCLEAR | LO_FLAGS_PARTSCAN)
 #endif
diff -Nru systemd-252.26/src/basic/strbuf.c systemd-252.27/src/basic/strbuf.c
--- systemd-252.26/src/basic/strbuf.c	2024-05-28 11:31:24.0 +0100
+++ systemd-252.27/src/basic/strbuf.c	2024-06-25 21:13:13.0 +0100
@@ -107,7 +107,6 @@
 /* add string, return the index/offset into the buffer */
 ssize_t strbuf_add_string(struct strbuf *str, const char *s, size_t len) {
 uint8_t c;
-char *buf_new;
 struct strbuf_child_entry *child;
 struct strbuf_node *node;
 ssize_t off;
@@ -147,10 +146,8 @@
 }
 
 /* add new string */
-buf_new = realloc(str->buf, str->len + len+1);
-if (!buf_new)
+if (!GREEDY_REALLOC(str->buf, str->len + len + 1))
 return -ENOMEM;
-str->buf = buf_new;
 off = str->len;
 memcpy(str->buf + off, s, len);
 str->len += len;
diff -Nru systemd-252.26/src/core/service.c systemd-252.27/src/core/service.c
--- systemd-252.26/src/core/service.c	2024-05-28 11:31:24.0 +0100
+++ systemd-252.27/src/core/service.c	2024-06-25 21:13:13.0 +0100
@@ -1233,7 +1233,7 @@
 service_start_watchdog(s);
 
 if (UNIT_ISSET(s->accept_socket)) {
-Socket* socket = SOCKET(UNIT_DEREF(s->accept_socket));
+Socket *socket = SOCKET(UNIT_DEREF(s->accept_socket));
 
 if (socket->max_connections_per_source > 0) {
 SocketPeer *peer;
@@ -3011,8 +3011,8 @@
 } else if (streq(key, "accept-socket")) {
 Unit *socket;
 
-if (u->type != UNIT_SOCKET) {
- 

Bug#1074443: Unable to boot due to missing package from the split

[Luca Boccassi]

On Fri, 28 Jun 2024 22:22:46 +0300 hammered hammered
 wrote:
> You should show a minimum effort to not break stuff even in
> unstable/testing.

You have intentionally disabled 'recommends', which are enabled by
default, and which normally results in sd-cryptsetup being installed.
That was your decision, so stop wasting time and blaming others for
your choices.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1074433: systemd: please package systemd-vmspawn

[Luca Boccassi]

On Fri, 28 Jun 2024 15:15:42 +0200 Andrea Pappacoda
 wrote:
> Source: systemd
> Version: 256.1-2
> Severity: wishlist
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi all!
> 
> Could you please consider packaging systemd-vmspawn? I know it's very
new, but
> I'd like to start experimenting with it.
> 
> Thanks :)

It's still considered experimental, and enabled only in dev mode. The
interface will likely change. Will need at least one more release to
stabilize. Should be done in time for Trixie.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1074443: Unable to boot due to missing package from the split

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Fri, 28 Jun 2024 20:27:55 +0300 hammered hammered
 wrote:
> It is totally unacceptable to break a working systems like that.

You are running "unstable" or "testing", not "stable", there's a reason
they are called as such. Incompatible changes in unstable/testing are
normal and expected, if you don't want to deal with them, just run
stable.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#864341: systemd-sysctl: failed to apply sysctl config at bootup

[Luca Boccassi]

Control: close -1

On Fri, 7 Sep 2018 02:15:47 +0200 Michael Biebl 
wrote:
> On Wed, 30 Aug 2017 08:30:55 +0200 Arturo Borrero Gonzalez
>  wrote:
> > Hi,
> > 
> > any news? We are being hit by this bug, which is a bit annoying.
> > Are upstream systemd developers aware of this issue?
> > 
> 
> I don't see a systemd bug here, tbh. So I didn't raise this upstream.
> 
> I might be completely wrong on this one though, so feel free to raise
> this upstream yourself.

This doesn't seem to be a systemd issue and there were no updates in 6
years, closing as not actionable.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1070474: time sync overflows on ARCH armhf(Debian 12, bookworm) with systemd-timesyncd.service

[Luca Boccassi]

Control: tags -1 -moreinfo
Control: close -1

On Mon, 27 May 2024 09:04:00 +0800 Perr Zhang 
wrote:
> I has tested for about one week, and hasn't catched the process's
coredump yet

No update in a month, assuming it was a local issue with the setup and
it was worked around/solved.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1074014: encode mandatory merged-/usr into policy

[Luca Boccassi]

On Sat, 22 Jun 2024 13:34:23 +0200 Chris Hofstaedtler 
wrote:
> On Sat, Jun 22, 2024 at 09:42:27AM +0200, Helmut Grohne wrote:
> > [..] he came up with a crazy solution where mksh's data.tar
contains
> > ./bin/mksh but not ./bin on the grounds that ./bin is provided by
an
> > essential package in all Debian releases.
> 
> > I think this approach practically solves a significant chunk of the
> > problems listed by DEP17, but it still confuses QA tools and e.g.
> > dpkg -S (maybe more). [..]
> 
> A fully working, unconfused, dpkg is part of what we want. In my
> understanding, we are trying to ship a distribution, IOW a set of
> packages that work *together*.
> 
> If a confused dpkg was okay, then a lot of the work could have been
> skipped.

+1

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1073922: systemd-{container,cryptsetup,repart}: ineffective Replaces due to /usr-move (DEP17)

[Luca Boccassi]

Control: tags -1 -patch
Control: tags -1 pending

On Fri, 21 Jun 2024 12:30:25 +0200 Helmut Grohne 
wrote:
> Control: reassign -1 systemd-container,systemd-cryptsetup,systemd-
repart
> Control: found -1 systemd/256.1-1
> Control: tags -1 + patch
> 
> On Thu, Jun 20, 2024 at 10:58:23AM +0200, Helmut Grohne wrote:
> > Package: systemd-container,systemd-cryptsetup,cryptsetup-repart
> 
> Fixed bad package cryptsetup-repart.
> 
> > Let me not go into details of this problem just yet and just
install
> > this bug as a temporary migration blocker. I shall have an update
within
> > three working days, ideally with a patch. Thanks for your patience.
> 
> The recurring theme is that systemd moved all of its files from / to
> /usr (expected via DEP17) and now moves components from the main
systemd
> package into systemd-container, systemd-cryptsetup and systemd-
repart.
> In all of these cases, affected files may be lost in upgrades from
> either bookworm or bookworm-backports to unstable and eventually
trixie.
> Users upgrading from trixie to sid, will likely not experience loss
> unless they skip systemd versions.
> 
> There are multiple mitigation techniques available. Upgrading
> Breaks+Replaces to Conflicts provides a relatively strong protection
as
> long as one uses an apt-based package management tool. However, the
CTTE
> advised that packages relevant to booting a system should also be
safe
> when installing packages directly with dpkg and in that scenario,
> Conflicts are insufficient, because dpkg allows a conflicting package
to
> be unpacked before the conflicted package is removed to facilitate a
> smooth handover. This is only exercised by apt when the relevant
> packages employ a mutual conflict, which is not the case here. As
such,
> I also add temporary diversions that exist from preinst to postinst
to
> protect the relevant files from loss.

Thank you for the bug report, analysis and patch.

Of the three affected packages, -cryptsetup and -repart are brand new,
were never and will never be in bookworm, not even in backports, so
they are actually unaffected by the potential issue that affects the
Conflicts workaround.
-container does ship in bookworm, but the affected files, the sd-
sysupdate units, did not exist at all in bookworm, as the sub-feature
was only enabled later, and they only shipped in backports, not in
bookworm proper. Moreover, the feature itself is experimental, wasn't
really in a good shape in the backports version, and even in the newer
it cannot actually be used with any Debian infrastructure: we just do
not build and publish any of the image formats it supports. The only
reason it was enabled, was to allow local experiments. It is most
definitely not "boot critical" in any sense of the term. Finally, if it
_is_ actually used, then it would be in an image-based system, that by
definition does not perform package upgrades at all, but exclusively
installs read-only images using A/B schemes or similar, so any system
actually making use of these units would not be affected by such
upgrade issues in the first place, as it would be read-only. Any system
affected by this hypothetical cycle-induce file loss would experience
no issue, as the units would not be in use, by definition, and would
just come back at the next point release update.

Given the likelihood of any impact is minimal, and the magnitude of any
impact is nil, and given that the fix requires a large and expensive to
maintain patch, my conclusion is that the costs are not worth the
benefits, and I am ok with the minimal and localized risk that comes
with just relying on the much simpler Conflicts-based solution, and
will hence opt to use that instead.

Thanks again for the input and the discussion.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1073835: systemd: new run0 utility fails due to missing dependency

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Wed, 19 Jun 2024 16:41:44 +0200 John Shaft 
wrote:
> Package: systemd
> Version: 256-1
> Severity: normal
> 
> Dear Maintainer,
> 
> systemd 256 introduced a 'run0' utility intended to serve a similar
purpose as sudo(8)
> 
> run0(1) manpage states:
> 
> 'Authentication takes place via polkit[1], thus isolating the
authentication prompt from the terminal (if possible).'
> 
> As of now, polkitd is only a suggestion and not yet a dependency for
systemd so chances are it is not installed. Trying to use run0 thus
fails, eg:

Yes this is expected and intended, as we want to prioritize allowing to
build minimal images, so a lot of "extra" functionality is enabled but
won't work until recommends and suggests are installed. If you want to
make sure all features are usable, you can use apt install --install-
suggests and that will bring in everything.

> $ run0 ls /tmp
> Failed to start transient service unit: Access denied
> 
> (note that run0 error message could be improved, but it is an
upstream issue)

Please file an issue upstream, or better yet, a PR.

-- 
Kind regards,
Luca Boccassi

Bug#1074073: systemctl: some lines flash for no apparent reason

[Luca Boccassi]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/systemd/systemd/issues/33449
Control: close -1

On Sat, 22 Jun 2024 21:45:33 + Michael Gold 
wrote:
> Package: systemd
> Version: 256.1-1
> Severity: minor
> 
> Dear Maintainer,
> 
> When I run systemctl, some lines are under-lined; and since some time
> within the last year, these have flashed at about 1 Hz.  It's
annoying
> and makes them difficult to read.
> 
> For example, these lines are affected:
>   proc-sys-fs-binfmt_misc.automount
>   user.slice
> 
> I'm using urxvt, but xterm and mlterm behave the same way.
> 
> The under-lining seems non-sensical, although the manual explains it:
>   The header and the last unit of a given type are underlined
> 
> I find no mention of what the flashing is meant to indicate.  If it's
> intentional, it should be explained and there should be some way way
to
> disable it.

There are no patches affecting this downstream. Issues unrelated to
configuration/packages/patches need to be reported upstream. There's
already a github issue about this.

-- 
Kind regards,
Luca Boccassi

Bug#1073539: libnss-myhostname: incorrect documentation leading to breakage

[Luca Boccassi]

Control: tags -1 upstream
Control: close -1

On Mon, 17 Jun 2024 06:48:39 + ca...@allfreemail.net wrote:
> Package: libnss-myhostname
> Severity: important
> 
> Dear Maintainer,
> 
> the manpage for libnss-myhostname contains this line:
> 
> ```
> It is recommended to place "myhostname" after "file" and before
"dns".
> ```
> 
> However the correct name is not "file" but "files", so the line
should
> be:
> 
> ```
> It is recommended to place "myhostname" after "files" and before
"dns".
> ```
> 
> Using "file" instead of "files" leads to /etc/hosts not being used
and
> thus causing hostname resolution failures for hostnames defined in
that
> file.
> 
> The documentation should therefore be fixed. It applies to both sid
and
> bookworm.

There are no patches for manpages, please report this directly upstream
or better yet, send a PR: https://github.com/systemd/systemd

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072004: Possible fix for 9p change breaking autopkgtest-build-qemu

[Luca Boccassi]

On Sun, 16 Jun 2024 17:24:15 +0200 Christian Kastner 
wrote:
> FYI, a contributor has submitted a patch to the kernel Bugzilla [1]
and
> it indeed fixed the issue for the packages where I was seeing this.
> 
> Let's hope it gets recognized and accepted soon.
> 
> Best,
> Christian
> 
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218916

By and large, kernel developers and maintainers just ignore
bugzilla.kernel.org, so if you have a fix, it would be better to just
send it to the appropriate mailing list, cc'ing the maintainer.
Otherwise it's unlikely anything will happen.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072716: bookworm-pu: package systemd/252.26-1~deb12u2

[Luca Boccassi]

On Sun, 16 Jun 2024 00:23:32 +0100 Jonathan Wiltshire 
wrote:
> On Thu, Jun 06, 2024 at 03:34:33PM -0700, Noah Meyerhans wrote:
> > I'd like to get the release team's approval for a proposed change
to
> > bookworm's libnss-myhostname and libnss-mymachines packages, which
are both
> > generated from src:systemd.
> 
> I would have no objection to this, assuming the package maintainers
agree
> with it.

Thanks, uploaded.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1073260: systemd-tmpfiles can nuke /home and /srv

[Luca Boccassi]

Control: severity -1 wishlist
Control: tags -1 wontfix
Control: close -1

On Sat, 15 Jun 2024 12:58:28 +0200 Antoine Le Gonidec
 wrote:
> Package: systemd
> Version: 256-1
> Severity: critical
> Justification: causes serious data loss
> 
> The current build of systemd in Debian Sid ships the following file:
> /usr/lib/tmpfiles.d/home.conf

This is not social media, so if this is an attempt at trolling, it's
not even funny. This functionality is for services and packaging
scripts, not for manual invocation, there is nowhere that even hints to
do that. Don't run things that you don't know what to do, without
reading its documentation.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1073210: systemd-boot-efi: loader.conf default entry incompatibility

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Fri, 14 Jun 2024 17:51:07 +0200 (CEST) Christoph Ziebuhr
 wrote:
> Package: systemd-boot-efi
> X-Debbugs-Cc: ch...@codefrickler.de
> Version: 252.22-1~deb12u1
> Severity: normal
> Tags: upstream
> 
> We are managing IoT devices as a product, which consists of two root
partitions with corresponding
> loader/entries/*.conf file on the EFI partition. On each update, a
whole image gets written to the currently unused partition
> and the default entry in loader/loader.conf gets updated to point to
the new loader/entries/*.conf file.
> 
> After upgrading our image from debian buster to bookworm, the system
booted into the wrong partition.

Buster didn't even ship systemd-boot, we started shipping it from
bookworm, so there is certainly no incompatible change in Debian. Just
update your loader.conf.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1073169: debootstrap: support working on a nodev filesystem (e.g. /tmp)

[Luca Boccassi]

On Thu, 13 Jun 2024 22:47:48 +0200 Helmut Grohne 
wrote:
> Package: debootstrap
> Version: 1.0.134
> Tags: patch
> X-Debbugs-Cc: jo...@debian.org
> Control: affects -1 + src:genext2fs
> 
> Hi,
> 
> I tried running the genext2fs autopkgtest for the /usr-move bootstrap
> upload and it failed rather early here while running debootstrap:
> 
> Cannot install into target '/tmp/...' mounted with noexec or
nodev
> 
> I thought Johannes fixed debootstrap to work without mknod via
>
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/109
,
> so why would it fail on nodev?
> 
> When you're root and on a nodev filesystem, mknod still works. What
does
> not work is writing to that device. Hence, the bind mounting code
does
> not come into effect here. That also leads us to a relatively obvious
> solution: We can simply try writing to the created devices and
perform
> the bind mount dance if it does not.
> 
> I've prepared a patch for this.
> 
> Helmut

Could you please send a MR on Salsa? Thanks

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1073112: daemontools: autopkgtest daemontools-run-systemd is flaky

[Luca Boccassi]

Source: daemontools
Severity: serious
Justification: flaky debci is RC as per RT
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

The daemontools-run-systemdautopkgtest is flaky, and often requires a
retry to pass, with no other changes. As per RT, this is RC. Example:

https://ci.debian.net/packages/d/daemontools/testing/riscv64/47570489/
https://ci.debian.net/packages/d/daemontools/testing/riscv64/47570489/
https://ci.debian.net/packages/d/daemontools/testing/riscv64/47664507/

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1073079: RM: cpufrequtils -- RoQA; obsolete and replaced

[Luca Boccassi]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: kkama...@gmail.com, z...@debian.org

As per #877016, cpufrequtils is obsolete, unmaintained and has been
replaced by cpupowerutils, which is part of the upstream kernel sources
and is maintained. It was last uploaded 4 years ago, and has been out
of testing with this RC bug since 2023-10-28.

I think it is now time to remove it from unstable too. Thanks.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1073052: cryptsetup: autopkgtest cryptroot-lvm is flaky

[Luca Boccassi]

Source: cryptsetup
Severity: serious
Justification: flaky debci is RC as per RT
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

The cryptroot-lvm autopkgtest is flaky, and often fails and
then passes upon reruns, independently of the reason why it was
triggered. As per RT, this is an RC issue.

Example:

134s 
/tmp/autopkgtest-lxc.snppntav/downtmp/build.WFv/src/debian/tests/cryptroot-lvm: 
line 514:  7255 Segmentation fault  ${QEMU_TIMEOUT:+timeout 3600s} 
"$QEMU_SYSTEM_CMD" "${QEMU_COMMON_ARGS[@]}" "${QEMU_STDIO_ARGS[@]}" -drive 
"$QEMU_DEBIANIMG_DRIVE" -kernel "$TEMPDIR/vmlinuz-$KERNEL_VERSION" -append 
"console=$CONSOLE,115200n8" -initrd "$TEMPDIR/initrd.img-$KERNEL_VERSION"
134s + exit 139
134s + teardown
134s + local rv=139 ts
134s + '[' -n '' ']'
134s + rm -rf -- 
/tmp/autopkgtest-lxc.snppntav/downtmp/autopkgtest_tmp/cryptroot-lvm.fuN4MJ9S9Q
135s + trap - EXIT
135s + '[' '!' -t 1 ']'
135s ++ printf '%(%s)T'
135s + ts=1718183644
135s + rv=139
135s + printf 'Result for test '\''%s'\'': exit status %s, runtime %d 
seconds\n' cryptroot-lvm 139 56
135s + exit 139
135s Result for test 'cryptroot-lvm': exit status 139, runtime 56 seconds

https://ci.debian.net/packages/c/cryptsetup/testing/amd64/47561302/

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072917: Cannot generate a certificate request for a RSA-PSS key

[Luca Boccassi]

Control: tags -1 upstream
Control: close -1

On Mon, 10 Jun 2024 11:04:50 +0100 Anton Ivanov
 wrote:
> Package: tpm2-openssl
> Version: 1.1.1-1
> Severity: important
> 
> In order to use tpm to store TLS keys, the key type must be usable
for TLS. If,
> the ecc algo family cannot be used, this has to be RSA-PSS. RSA-PSS
keys can be
> created with tpm2-tools and appear to function correctly outside
openssl. Trying
> to generate an openssl cert request with invalid padding.
> 
> How to reproduce:
> 
> tpm2_createek -G rsa -c ek_pss.ctx
> tpm2_createak -C ek_pss.ctx -G rsa -g sha256 -s pss -c ak_ecc.ctx
> tpm2_evictcontrol -c ak_ecc.ctx 0x8101
> OPENSSL_CONF=./openssl.cnf openssl req -provider tpm2 -provider
default \
> -propquery '?provider=tpm2' -key handle:0x8101 -out
testcsr.pem -new
> 
> The resulting csr has invalid padding (200+ bytes instead of 32) and
is rejected
> if passed to a CA

There are no patches in Debian, please test this again in
unstable/testing, and if it is still a problem report this upstream:

https://github.com/tpm2-software/tpm2-openssl/issues

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072947: dropbear: autopkgtest remote-unlocking is flaky

[Luca Boccassi]

Source: dropbear 2024.85-2
Severity: serious
Justification: flaky debci is RC as per RT
User: debian...@lists.debian.org
Usertags: flaky

Dear Maintainer(s),

The remote-unlocking autopkgtest is flaky, and often requires a retry
to pass, with no other changes. As per RT, this is RC. Example:

https://ci.debian.net/packages/d/dropbear/testing/amd64/47506735/
https://ci.debian.net/packages/d/dropbear/testing/amd64/47426591/
https://ci.debian.net/packages/d/dropbear/testing/amd64/47261698/
https://ci.debian.net/packages/d/dropbear/testing/amd64/47105607/

887s Connection timed out during banner exchange
887s Connection to 127.0.0.1 port 10022 timed out
887s + rv=255
887s + [ 255 -ne 255 ]
887s + [ 1 -le 1 ]
887s + echo ERROR: Couldn't SSH into QEMU: maximum number of tries exceeded
887s ERROR: Couldn't SSH into QEMU: maximum number of tries exceeded
887s + exit 1
887s + kill 29110

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false

[Luca Boccassi]

On Sun, 9 Jun 2024 at 21:07, Andreas Beckmann  wrote:
>
> Hi Peter,
>
> thanks for testing that.
>
> On 08/06/2024 16.42, Peter De Wachter wrote:
> > Those locations work. But the correct environment variable turns out to be
> > SYSTEMD_SLEEP_FREEZE_USER_SESSIONS (plural), the NEWS file has it wrong.
>
> Hi Luca,
>
> do you need a cloned bug against systemd for the variable mismatch?

Thanks but no need, it's just the changelog, already fixed it.

> > (I've no idea why suspend seemed to work for me yesterday with the wrong
> > variable. Today it definitely didn't.) The overrides probably also need to
> > be installed for the other service files that run systemd-sleep:
> > systemd-hybrid-sleep.service, systemd-hibernate.service and
> > systemd-suspend-then-hibernate.service.
>
> Can you give some hints here?
>
> And if it is the case that we need these override variables in many
> places, isn't there an easier way to "configure systemd-sleep behavior"
> regardless of the way it is being called?

This is a workaround, so the drop-in is the only way. The correct fix
is for the functionality to stop relying on the user session being
runnable to come out of suspension, as that's the real problem. I
realize you can't fix this, but at least it should be reported
upstream, asking them to fix it (they probably won't, I know)

Bug#1072105: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.

[Luca Boccassi]

On Sun, 9 Jun 2024 06:58:24 +0200 Andreas Metzler 
wrote:
> On 2024-05-29 Luca Boccassi  wrote:
> > On Wed, 29 May 2024 20:15:36 +0200 Michael Biebl  > wrote:
> >> On Tue, 28 May 2024 17:15:02 +0100 Luca Boccassi  > wrote:
> >>> On Tue, 28 May 2024 17:44:54 +0200 Michael Biebl
 >>> wrote:
> [...]
> 
> >>>> Please do not not ship conflicting configuration for /run/lock
> 
> >>>> /usr/lib/tmpfiles.d/debian.conf:d /run/lock    1777 root root -
  
> > -
> >>>> /usr/lib/tmpfiles.d/legacy.conf:d /run/lock 0755 root root -
> 
> >>>> triggering unnecessary warnings.
> 
> >>> This is needed to apply debian-specific changes, just ignore it,
> >>> it's
> >>> harmless
> [...]
> > No. The current approach is just fine. If you don't like seeing the
> > harmless notice-level log, just add a local override in /etc/.
> 
> >> Btw, please don't close bug reports without CCing the bug
submitter. 
> >> That's rude.
> 
> > Please stop playing ping pong with the BTS, this is staying as it
is.
> 
> Hello,
> 
> Let me upvote this bug-report. I have unnecessarly spent time
> investigating the issue, checking whether this is a known bug. Having
> read through the bug I still have not read an explanation why the
> current state "is just fine". If it really was systemd would not
throw
> a warning. What is the huge benefit of shipping conflicting
configurations
> instead of shipping one that is correct for Debian that justifies
> wasting our contributors' time?

It exists due to a silly legacy debianism - namely /run/lock being
world writable instead of having sensible permissions. If you don't
like the warning, please spend time to move the project away from this
ancient and obsolete debianism, and then the override will be dropped.
Until then, it will stay exactly as it is. Complaining on this or
similar bug reports is not going to achieve anything.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false

[Luca Boccassi]

On Fri, 7 Jun 2024 at 21:03, Andreas Beckmann  wrote:
>
> On 07/06/2024 08.17, Peter De Wachter wrote:
> > systemd 256-rc3 was recently uploaded to Debian. Its NEWS file mentions:
> >
> >  * The behavior of systemd-sleep and systemd-homed has been updated 
> > to
> >freeze user sessions when entering the various sleep modes or 
> > when
> >locking a homed-managed home area. This is known to cause issues 
> > with
> >the proprietary NVIDIA drivers. Packagers of the NVIDIA 
> > proprietary
> >drivers may want to add drop-in configuration files that set
> >SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for 
> > systemd-suspend.service
> >and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false 
> > for
> >systemd-homed.service.
>
> Thanks for catching that. I'll try to include a fix with the upcoming
> uploads of the recent CVE series.
>
> As I'm not that familiar with configuring systemd bits, do you know what
> would be the correct locations and contents to ship the fix?
>
> If I read the documentation correctly, that should be
>
> /usr/lib/systemd/system/systemd-suspend.service.d/nvidia.conf
> = 8< =
> [Service]
> Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSION=false"
> = >8 =
>
> and
>
> /usr/lib/systemd/system/systemd-homed.service.d/nvidia.conf
> = 8< =
> [Service]
> Environment="SYSTEMD_HOME_LOCK_FREEZE_SESSION=false"
> = >8 =
>
> Could you verify that this works (after unapplying your temporary solution)?

Hi Andreas, I can confirm those are the correct locations. You can
also omit the quotes.

Bug#1072748: upower: autopkgtest installed-tests is flaky

[Luca Boccassi]

Source: upower 1.90.3-1
Severity: serious
Justification: flaky debci is RC as per RT
User: debian...@lists.debian.org
Usertags: flaky

Dear Maintainer(s),

This autopkgtest is flaky, and often requires a couple of retries to
pass. As per RT, this is RC. Example:

236s FAIL: test_sibling_priority_no_overwrite 
(__main__.Tests.test_sibling_priority_no_overwrite)
236s Test siblings using the fallback device do not overwrite previous guesses
236s --
236s Traceback (most recent call last):
236s   File "/usr/libexec/upower/integration-test.py", line 2635, in 
test_sibling_priority_no_overwrite
236s self.assertDevs({
236s   File "/usr/libexec/upower/integration-test.py", line 294, in assertDevs
236s self.assertEqual(names, sorted(expected.keys()))
236s AssertionError: Lists differ: [] != ['battery_wacom_battery_0']
236s 
236s Second list contains 1 additional elements.
236s First extra element 0:
236s 'battery_wacom_battery_0'
236s 
236s - []
236s + ['battery_wacom_battery_0']
236s 
236s --
236s Ran 67 tests in 177.484s
236s 
236s FAILED (failures=1)
236s FAIL: upower/upower-integration.test (Child process exited with code 1)

https://ci.debian.net/packages/u/upower/testing/s390x/47448061/

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1069871: netplan.io: flaky autopkgtest on s390x: eth42 interface already exists

[Luca Boccassi]

mic noprefixroute 
359svalid_lft 86395sec preferred_lft 86395sec
359s inet6 fe80::e867:94ff:fe09:4831/64 scope link proto kernel_ll 
359svalid_lft forever preferred_lft forever

https://ci.debian.net/packages/n/netplan.io/testing/amd64/47450641/#S10

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072734: prometheus-squid-exporter: autopkgtest dh-golang-autopkgtest is flaky

[Luca Boccassi]

Source: prometheus-squid-exporter
Severity: serious
Justification: flaky debci is RC as per RT
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

The dh-golang-autopkgtest autopkgtest is flaky, and often fails and
then passes upon reruns, independently of the reason why it was
triggered. As per RT, this is an RC issue.

Example:

 98s === RUN   TestReadFromSquid
 98s panic: runtime error: invalid memory address or nil pointer dereference
 98s [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x653bf4]
 98s 
 98s goroutine 7 [running]:
 98s github.com/boynux/squid-exporter/collector.TestReadFromSquid.func1()
 98s
/tmp/autopkgtest-lxc.tnsof3vy/downtmp/autopkgtest_tmp/build/src/github.com/boynux/squid-exporter/collector/client_test.go:39
 +0x44
 98s created by github.com/boynux/squid-exporter/collector.TestReadFromSquid in 
goroutine 6
 98s
/tmp/autopkgtest-lxc.tnsof3vy/downtmp/autopkgtest_tmp/build/src/github.com/boynux/squid-exporter/collector/client_test.go:37
 +0x70
 98s FAIL   github.com/boynux/squid-exporter/collector  0.010s

https://ci.debian.net/packages/p/prometheus-squid-exporter/testing/arm64/47447211/

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072380: cloud.debian.org: Azure deployment misconfigures /etc/hosts resulting in slow sudo

[Luca Boccassi]

On Thu, 6 Jun 2024 at 22:30, Noah Meyerhans  wrote:
>
> On Wed, Jun 05, 2024 at 10:09:25PM +0100, Luca Boccassi wrote:
> > > Is there any specific additional testing that the systemd maintainers
> > > would like to see?
> > >
> > > noah
> >
> > The checks themselves look good to me, but would be good doing the
> > same validation on a real machine running stable, not just a VM. Bonus
> > points for a container too - running a full image like nspawn or lxc.
>
> Updated testing checklist:
>
> [*] Fresh install of libnss-myhostname (nsswitch.conf lists the modules
> in the expected order)
> [*] Upgrade of libnss-myhostname (this does not attempt to rewrite
> nsswitch.conf, which is the same as upgrading to the fixed version
> in trixie)
> [*] Validate that the name resolution behavior is correct with the new
> nss module ordering; that is attempts to resolve the local hostname,
> localhost.localdomain, _gateway, and _outbound are handled by
> nss-myhostname and don't result in a DNS lookup
> [*] Validate that libnss-mymachines resolves local container names
> without a DNS query
> [*] Validate that resolution of external names is unimpacted
> [ ] validate that a cloud image build based on the updated packages
> lists the nss modules in the desired order, with myhostname ahead
> of dns
>
> To improve readability, I've documented the actual test results in HTML
> at https://people.debian.org/~noahm/bug-1072380-testing.html  It
> includes tests on bare-metal bookworm hosts as well as systemd-nspawn
> bookworm containers.
>
> I haven't yet started validated that the right thing happens when
> building a VM image from scratch, which is necessary to confirm the fix
> in the environment where the issue was reported, but I think it's
> reasonable to initiate the conversation with the SRMs with that test
> still pending.
>
> Agree?

Yes that looks all good to me, thanks

Bug#1072683: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian

[Luca Boccassi]

Control: close -1

On Thu, 6 Jun 2024 15:42:28 +0200 (CEST) "pham...@bluewin.ch"
 wrote:
> Package:  systemd
> 
> Version: 252.22-1~deb12u1
> 
> Severity: important
> 
> Bug Description: 
> 
> RJ-45 wired network does not start when booting Debian.
> The problem occurs once for about ten successful starts, about once a
week for me.
> Attached is a screenshot of my workstation booting with the problem
described.

This has nothing to do with systemd, file a bug against your network
management software of choice, which for a desktop is probably network-
manager.

> I have to admit that I don't like systemd.

Nobody cares, you can keep these sort of comments for yourself.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072669: systemd: after upgrades systemd to 256~rc3-7 /proc/sys/fs/nr_open becomes 1073741816

[Luca Boccassi]

Control: reassign -1 torbrowser-launcher
Control: retitle -1 tor browser iterates manually over FD hard limit instead of 
using close_range()

On Thu, 6 Jun 2024 14:09:12 +0800 Wregyek  wrote:
> Package: systemd
> Version: 256~rc3-7
> Severity: normal
> 
> Dear Maintainer,
> 
> After systemd upgraded from 256~rc3-2 to 256~rc3-7,
/proc/sys/fs/nr_open
> changes from 1048576 (0x10) to 1073741816 (0x3ff8), causing
some
> applications (e.g. Tor Browser) to spend a lot of time to iterate
through the
> max filedescriptors and close() them before exec(), like
>
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013821.html

Yes, that was intentional as per changelog. Iterating over the hard
limit is a bug and needs to be fixed in the program doing it, which can
be done by simply using close_range():

https://man7.org/linux/man-pages/man2/close_range.2.html

This syscall has been available since Linux 5.9 (bullseye/oldstable).

Reassigning this to torbrowser-launcher.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072380: cloud.debian.org: Azure deployment misconfigures /etc/hosts resulting in slow sudo

[Luca Boccassi]

On Wed, 5 Jun 2024 at 21:47, Noah Meyerhans  wrote:
>
> On Tue, Jun 04, 2024 at 11:53:17PM +0100, Luca Boccassi wrote:
> > > This has recently been fixed in the systemd packages for sid/trixie.
> > [4]
> > > I'm going to reassign this to the systemd maintainers for now to see
> > if
> > > they're willing to backport (or accept a merge request to backport)
> > this
> > > fix to bookworm for an upcoming point release.  If they aren't
> > willing
> > > to do that (the blast radius for such a change is wide and they may
> > not
> > > be comfortable introducing it in a stable release), then we can
> > consider
> > > making the change in the cloud images.  That's less desirable because
> > it
> > > introduces a change to a conffile, which will introduce issues on
> > > upgrades, but we will see.
> >
> > Such a change in a stable release would be very risky, and at the very
> > least it would need to get buy-in from the release team in advance. If
> > you want to ask RT if they are ok with it, and then thoroughly test it
> > and provide a MR, with RT's blessings, then I will merge it and include
> > it in the next point release.
>
> The commits in
> https://salsa.debian.org/systemd-team/systemd/-/merge_requests/162
> cherry pick cleanly to the debian/bookworm branch and have the expected
> effect when libnss-myhostname is freshly installed.
>
> Test scenarios:
>
> [*] Fresh install of libnss-myhostname (nsswitch.conf lists the modules
> in the expected order)
> [*] Upgrade of libnss-myhostname (this does not attempt to rewrite
> nsswitch.conf, which is the same as upgrading to the fixed version
> in trixie)
> [ ] Validate that the name resolution behavior is correct with the new
> nss module ordering; that is attempts to resolve the local hostname,
> localhost.localdomain, _gateway, and _outbound are handled by
> nss-myhostname and don't result in a DNS lookup
> [ ] Validate that resolution of external names is unimpacted
> [ ] validate that a cloud image build based on the updated packages
> lists the nss modules in the desired order, with myhostname ahead
> of dns
>
> Is there any specific additional testing that the systemd maintainers
> would like to see?
>
> noah

The checks themselves look good to me, but would be good doing the
same validation on a real machine running stable, not just a VM. Bonus
points for a container too - running a full image like nspawn or lxc.

Bug#1072521: fakeroot hangs on some commands with faked-sysv using 100% CPU

[Luca Boccassi]

On Wed, 5 Jun 2024 13:57:38 +0200 Helmut Grohne 
wrote:
> From what I can tell, fakeroot would be better served with using
> close_range(2). That would lower the CPU consumption with a higher
> resource limit and make the real problem more apparent or disappear.

FYI the FD hard limit has been bumped in systemd 256~rc3-3, to the max
that the kernel allows. The soft limit is still 1024.
A tight loop around any hard limit is really a bug, and using
close_range is indeed the right solution here.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072380: cloud.debian.org: Azure deployment misconfigures /etc/hosts resulting in slow sudo

[Luca Boccassi]

Control: fixed -1 256~rc3-3

On Tue, 4 Jun 2024 15:24:19 -0700 Noah Meyerhans 
wrote:
> Control: reassign -1 libnss-myhostname
> Control: affects -1 cloud.debian.org
> Control: retitle -1 incorrect nsswitch.conf entry for nss-myhostname
> 
> On Sat, Jun 01, 2024 at 11:13:32PM +, Michael Salivar wrote:
> >    * What led up to the situation?
> > 
> > This was not previously an issue some months back as I deployed
previous labs with the same scripts, but affected Bookworm deployments
on 2024-06-01 in Azure.
> > 
> > I found that /etc/hosts IPv4 loopback not configured with real
hostname.  This results in sudo taking approximately 20 seconds to
prompt for password, or run command in the case of passwordless.
> > 
> >    * What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> > I changed the IPv4 loopback in /etc/hosts to include the real
hostname like so:
> > 
> > 127.0.0.1 localhost realhostname
> > 
> > Sudo now works as expected
> 
> It's not /etc/hosts, and in fact we haven't changed the content of
> /etc/hosts in the cloud images.  However, we did switch from
installing
> nss-resolve to nss-hostname ([1], [2]), which has uncovered a bug in
the
> systemd packaging.
> 
> The hosts entry in /etc/nsswitch.conf in current cloud images looks
> like:
> hosts:  files dns myhostname
> 
> What this means is that, when trying to map between hostnames and
> addresses, glibc will first consult /etc/hosts (which is why your
change
> to /etc/hosts seems to resolve the problem), then DNS, and then
> nss-myhostname, which synthesizes responses for certain queries.
> 
> The problem is that DNS is being consulted unnecessarily, and if DNS
> resolution is slow or unresponsive for any reason, that will be
> reflected in the response.
> 
> Per the nss-myhostname(8) documentation [3], "It is recommended to
place
> "myhostname" after "file" and before "dns". This resolves well-known
> hostnames like "localhost" and the machine hostnames locally." 
However,
> the nss-myhostname package in bookworm does not adhere to this
> recommendation, instead adding the myhostname entry to the *end* of
the
> module list.
> 
> This has recently been fixed in the systemd packages for sid/trixie.
[4]
> I'm going to reassign this to the systemd maintainers for now to see
if
> they're willing to backport (or accept a merge request to backport)
this
> fix to bookworm for an upcoming point release.  If they aren't
willing
> to do that (the blast radius for such a change is wide and they may
not
> be comfortable introducing it in a stable release), then we can
consider
> making the change in the cloud images.  That's less desirable because
it
> introduces a change to a conffile, which will introduce issues on
> upgrades, but we will see.

Such a change in a stable release would be very risky, and at the very
least it would need to get buy-in from the release team in advance. If
you want to ask RT if they are ok with it, and then thoroughly test it
and provide a MR, with RT's blessings, then I will merge it and include
it in the next point release.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1069613: systemd: Startup fails after apt full-upgrade

[Luca Boccassi]

Control: close -1

On Sun, 21 Apr 2024 09:52:55 -0400 Bud Heal 
wrote:
> Package: systemd
> Version: 252.22-1~deb12u1
> Severity: critical
> Justification: breaks the whole system
> X-Debbugs-Cc: budheal...@gmail.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
appropriate ***
> 
>    * What led up to the situation?
> A couple of non-Debian packages needed libc > 2.31, so I upgraded
this
> laptop.
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> I changed sources.list to point to bullseye, apt-get update, apt-get
> upgrade --without-new-pkgs, apt-get full-update. Reboot at each
upgrade.
> I changed sources.list to point to bookworm, including non-free and
> non-free-firmware, apt-get update, apt-get upgrade --without-new-
pkgs,
> reboot, noted that GLIB (libc) had budged to 2.36 and debian_version
was
> 12.5, so time for apt-get full-upgrade. Things were still working
fine, 
> but not after another reboot.
>    * What was the outcome of this action?
> Now startup does not complete to login. After I enter the disk
password,
> a long list of messages come up as usual and the first error was that
> apache could not be started. Later boots add a line, Error ucsi_acpi
> USBC000:00 PPM init failed (-110)
> I used a Bookworm RC3 disk (DLBD) for triage, and tail var/log/syslog
> informs that gnome crashed.

GNOME crashing is not a systemd issue, closing. If you have issues with
GNOME please open a bug against the relevant package, attaching
relevant information.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072524: systemd: On a debian trixie, after upgrading systemd to latest version the system fails to reboot.

[Luca Boccassi]

Control: close -1

On Tue, 4 Jun 2024 at 08:09, Christophe Trophime
 wrote:
>
> Indeed, it seems that I have tweeked my debian box for nvidia-docker at the 
> time.
> In /etc/default/grub:
>
> # Add this line for nvidia-docker
> GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"

You need to remove that, and then it will work. Closing.

> - Original Message -
> > From: "Luca Boccassi" 
> > To: "Christophe Trophime" 
> > Cc: 1072...@bugs.debian.org
> > Sent: Monday, June 3, 2024 7:33:45 PM
> > Subject: Re: systemd: On a debian trixie, after upgrading systemd to latest 
> > version the system fails to reboot.
>
> > On Mon, 3 Jun 2024 at 18:29, Christophe Trophime
> >  wrote:
> >>
> >> Hi,
> >> could you please just tell what info do you need?
> >
> > As already mentioned: did you customize the kernel command line?
> > Cgroupsv2 has been the default for years
> >
> >> - Original Message -
> >> > From: "Luca Boccassi" 
> >> > To: 1072...@bugs.debian.org
> >> > Cc: "Christophe Trophime" 
> >> > Sent: Monday, June 3, 2024 6:53:19 PM
> >> > Subject: Re: systemd: On a debian trixie, after upgrading systemd to 
> >> > latest
> >> > version the system fails to reboot.
> >>
> >> > Control: tags -1 moreinfo
> >> >
> >> > On Mon, 03 Jun 2024 18:41:12 +0200 Christophe Trophime
> >> >  wrote:
> >> >> Package: systemd
> >> >> Version: 256~rc3
> >> >> Severity: important
> >> >> X-Debbugs-Cc: christophe.troph...@lncmi.cnrs.fr
> >> >>
> >> >> Dear Maintainer,
> >> >>
> >> >> After upgrading systemd the machine does not reboot.
> >> >> The error message says:
> >> >>
> >> >> systemd freezing execution
> >> >> refusing to run under cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1
> >> >> shall be passed to kernel command line
> >> >>
> >> >>
> >> >> As far as I have understood cgroup v1 is no longer supported.
> >> >> So I think I have 2 choices:
> >> >> * add the variable to the kernel starting command line,
> >> >> * disable cgroup v1
> >> >>
> >> >> The point is that I cannot figure out how to do?
> >> >> Cannot find how to set the variable, nor how to eventually disable
> >> >> cgroup v1?
> >> >>
> >> >> Which packages may use the cgroup v1 features?
> >> >> I'm using container tools like docker (nvidia-container), singularity
> >> > and charliecloud
> >> >>
> >> >> Thanks for your help
> >> >> Best
> >> >> C
> >> >>
> >> >> PS: cannot provide any additional info about my debian trixie host.
> >> >
> >> > cgroupsv2 is the default and has been since Bookworm, did you apply
> >> > some custom kernel command line that disables it?
> >> >
> >> > --
> >> > Kind regards,
> > > > Luca Boccassi

Bug#1072524: systemd: On a debian trixie, after upgrading systemd to latest version the system fails to reboot.

[Luca Boccassi]

On Mon, 3 Jun 2024 at 18:29, Christophe Trophime
 wrote:
>
> Hi,
> could you please just tell what info do you need?

As already mentioned: did you customize the kernel command line?
Cgroupsv2 has been the default for years

> - Original Message -
> > From: "Luca Boccassi" 
> > To: 1072...@bugs.debian.org
> > Cc: "Christophe Trophime" 
> > Sent: Monday, June 3, 2024 6:53:19 PM
> > Subject: Re: systemd: On a debian trixie, after upgrading systemd to latest 
> > version the system fails to reboot.
>
> > Control: tags -1 moreinfo
> >
> > On Mon, 03 Jun 2024 18:41:12 +0200 Christophe Trophime
> >  wrote:
> >> Package: systemd
> >> Version: 256~rc3
> >> Severity: important
> >> X-Debbugs-Cc: christophe.troph...@lncmi.cnrs.fr
> >>
> >> Dear Maintainer,
> >>
> >> After upgrading systemd the machine does not reboot.
> >> The error message says:
> >>
> >> systemd freezing execution
> >> refusing to run under cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1
> >> shall be passed to kernel command line
> >>
> >>
> >> As far as I have understood cgroup v1 is no longer supported.
> >> So I think I have 2 choices:
> >> * add the variable to the kernel starting command line,
> >> * disable cgroup v1
> >>
> >> The point is that I cannot figure out how to do?
> >> Cannot find how to set the variable, nor how to eventually disable
> >> cgroup v1?
> >>
> >> Which packages may use the cgroup v1 features?
> >> I'm using container tools like docker (nvidia-container), singularity
> > and charliecloud
> >>
> >> Thanks for your help
> >> Best
> >> C
> >>
> >> PS: cannot provide any additional info about my debian trixie host.
> >
> > cgroupsv2 is the default and has been since Bookworm, did you apply
> > some custom kernel command line that disables it?
> >
> > --
> > Kind regards,
> > Luca Boccassi

Bug#1072524: systemd: On a debian trixie, after upgrading systemd to latest version the system fails to reboot.

[Luca Boccassi]

Control: tags -1 moreinfo

On Mon, 03 Jun 2024 18:41:12 +0200 Christophe Trophime
 wrote:
> Package: systemd
> Version: 256~rc3
> Severity: important
> X-Debbugs-Cc: christophe.troph...@lncmi.cnrs.fr
> 
> Dear Maintainer,
> 
> After upgrading systemd the machine does not reboot.
> The error message says:
> 
> systemd freezing execution
> refusing to run under cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1
> shall be passed to kernel command line
> 
> 
> As far as I have understood cgroup v1 is no longer supported.
> So I think I have 2 choices:
> * add the variable to the kernel starting command line,
> * disable cgroup v1
> 
> The point is that I cannot figure out how to do?
> Cannot find how to set the variable, nor how to eventually disable
> cgroup v1?
> 
> Which packages may use the cgroup v1 features?
> I'm using container tools like docker (nvidia-container), singularity
and charliecloud
> 
> Thanks for your help
> Best
> C
> 
> PS: cannot provide any additional info about my debian trixie host.

cgroupsv2 is the default and has been since Bookworm, did you apply
some custom kernel command line that disables it?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1009122: systemd-quotacheck : does not work on root file system

[Luca Boccassi]

Control: tags -1 -upstream
Control: close -1

On Tue, 5 Jul 2022 00:28:21 +0200 Michael Biebl 
wrote:
> Control: tags -1 + upstream
> On Fri, 8 Apr 2022 10:32:05 +0200 Laurent Bonnaud 
>  wrote:
> > On 4/7/22 18:41, Laurent Bonnaud wrote:
> > 
> > > However I got it to work nevertheless by adding the "ro" mount
option
> > > in /etc/fstab for the root file system
> > 
> > This "solves" the quotacheck problem, but unfortunately it has many
other negative consequences, such as:
> > 
> > Apr 08 05:01:29 hostname systemd[1]: swapfile.swap: Swap process
exited, code=exited, status=255/EXCEPTION
> > Apr 08 05:01:29 hostname systemd[1]: swapfile.swap: Failed with
result 'exit-code'.
> > Apr 08 05:01:29 hostname systemd[1]: Failed to activate swap
/swapfile.
> > 
> > Apr 08 05:01:30 hostname systemd-tmpfiles[522]: rm_rf(/tmp): Read-
only file system
> > 
> > Apr 08 05:01:30 hostname systemd[539]: systemd-timesyncd.service:
Failed to set up mount namespacing: /run/systemd/unit-root/dev: Read-
only file system
> > Apr 08 05:01:30 hostname systemd[539]: systemd-timesyncd.service:
Failed at step NAMESPACE spawning /lib/systemd/systemd-timesyncd: Read-
only file system
> > 
> > Such this "solution" can only be used as a "one shot" trick
followed by a proper reboot with a rw file system.
> 
> 
> I assume you are using stable.
> Can you please test, if you can still reproduce this with v250 from 
> bullseye-backports and if so, report this upstream at
> https://github.com/systemd/systemd/issues

No answer nor upstream report in 2 years, closing.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part