Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Lyndon Brown]

On Wed, 2024-05-29 at 18:58 +0200, Andreas Metzler wrote:
> Hello,
> 
> That is false dichotomy. data-loss will occur when people use /tmp or
> /var/tmp for persistent data-storage because "This has (for a couple
> of
> years) worked on Debian systems" not because "This has (for a couple
> of
> years) worked on *this* *specific* Debian system.".
> 
> cu Andreas

I think you might be missing the point that this is the *DEFAULT*
behaviour. You're free to override it. If you personally have no
precious data in tmp storage to worry about then after upgrade you can
simply tweak the config to enable the new behaviour, as I have done.

I'm using Sid and after doing a little reading up on the topic
yesterday after the upgrade I believe all that needed doing was to
delete the /etc/tmpfiles.d/tmp.conf file, which as I understand it
contains a simple override of the new behaviour defined in
/usr/lib/tmpfiles.d/tmp.conf.

FWIW I think Luca made a perfectly sensible choice here.

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Noah Meyerhans]

On Wed, May 29, 2024 at 06:58:32PM +0200, Andreas Metzler wrote:
> >> I think it is bad choice to deliberately have different behavior for
> >> freshly installed and upgraded systems. Offering upgrades has always
> >> been one of the major selling points of Debian, and imho this
> >> implicitely includes that you do not get a worse or second class Debian
> >> installation when you upgrade it than if you installed from scratch.
> 
> > I strongly disagree: it is a bad choice to change on upgrades a default 
> > which may cause data loss.
> 
> That is false dichotomy. data-loss will occur when people use /tmp or
> /var/tmp for persistent data-storage because "This has (for a couple of
> years) worked on Debian systems" not because "This has (for a couple of
> years) worked on *this* *specific* Debian system.".

Both perspectives are valid, and that is part of why this change is
concerning to me.  Transitioning the filesystem configuration of an
existing system is inherently dangerous and can lead to data loss, as
Marco points out.  But leaving a system to diverge from the default
Debian base configuration leads to configurtion drift that may trigger
obscure bugs, untested configuration, difficult upgrades, etc.  I'm not
convinced the change is worth the risk.

noah

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andreas Metzler]

On 2024-05-29 Marco d'Itri  wrote:
> On May 28, Andreas Metzler  wrote:

>> I think it is bad choice to deliberately have different behavior for
>> freshly installed and upgraded systems. Offering upgrades has always
>> been one of the major selling points of Debian, and imho this
>> implicitely includes that you do not get a worse or second class Debian
>> installation when you upgrade it than if you installed from scratch.

> I strongly disagree: it is a bad choice to change on upgrades a default 
> which may cause data loss.

Hello,

That is false dichotomy. data-loss will occur when people use /tmp or
/var/tmp for persistent data-storage because "This has (for a couple of
years) worked on Debian systems" not because "This has (for a couple of
years) worked on *this* *specific* Debian system.".

cu Andreas

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Marvin Renich]

* Hakan Bayındır  [240529 07:51]:
> On 28.05.2024 ÖS 8:16, Andreas Metzler wrote:
> > On 2024-05-28 Luca Boccassi  
> > wrote:
> > [...]
> > > - existing installations pre-trixie will get an orphaned tmpfiles.d in
> > > /etc/ that keeps the existing behaviour unchanged (no cleanup of
> > > /var/tmp)
> > [...]
> > 
> > Hello,
> > 
> > I think it is bad choice to deliberately have different behavior for
> > freshly installed and upgraded systems. Offering upgrades has always
> > been one of the major selling points of Debian, and imho this
> > implicitely includes that you do not get a worse or second class Debian
> > installation when you upgrade it than if you installed from scratch.
> > 
> > cu Andreas
> 
> I'll kindly disagree here.

While I agree with Andreas that having the same behavior for upgraded
systems and new installations is generally better, I agree with you that
in this specific case it is not the better choice.

> I'd rather not have to go back to every system
> and make sure that they all behave the way I want after doing a periodic,
  ^
> completely boring "apt-get upgrade".

You haven't specified what behavior you want.  Is it the existing
behavior or the new behavior?  This thread is exactly about choosing
between the two, and possibly between different behavior for new and
existing systems.

There are four combinations of old/new behavior and upgrading/new
installation.  Eliminating the obviously bad combination, we are left
with three:

A.  Keep old behavior for both upgrading and new installations.
B.  Keep old behavior for upgrading, use new behavior for new installations.
C.  Apply new behavior for both.

The new behavior is preferable for many use cases, but the old behavior
is not a "BUG" that must be fixed.  Debian has had the old behavior for
a very long time.

A number of people have spoken up on this list saying that they are
relying on the old behavior, and that changing to the new behavior could
potentially cause serious data loss.

Some people have stated an opinion that keeping upgraded systems in sync
with the behavior of new installations is desirable.

So to choose between A, B, and C, we must rank the following:

X.  desirability of new behavior
Y.  preventing data loss for an unspecified, but non-zero, number of
existing systems
Z.  desirability of having upgraded systems match new installations.

Both X and Z are primarily opinions with some (non-overwhelming)
technical merit to each.

Sufficient technical arguments have been provided on this meta-thread to
support that Y is highly important and also more important than both X
and Z.  This means that choice C fails.

If Z were more important than X, then the order of importance would
become Y, then Z, then X, which would make choice A the winner.

However, there have been no technical arguments whatsoever that Z is
more important than either of X or Y, only a few personal opinions.
And, from the discussion, the consensus appears to be that X is more
important than Z, so the order is Y, then X, then Z.

This gives us choice B as the winner.

It also looks like Luca Boccassi has already made the changes to effect
choice B.  Thank you, Luca!

,,,Marvin

Re: MBF: Building packages in the (not so distant) future

[Andrius Merkys]

Hello,

On 2024-05-26 20:35, Santiago Vila wrote:

After we make a stable release, there is usually a constant flow
of packages which start to FTBFS due to "time bombs", i.e. expired
SSL certificates used in tests and other similar reasons.


Just FYI, there is a suggestion to implement lintian hint for expired 
SSL certificates (#1036769) with an ongoing implementation [1]. Now the 
hint is raised for SSL certificates which are outdated at the moment of 
running lintian, but it could as well check for some time in future.


[1] 
https://salsa.debian.org/lintian/lintian/-/merge_requests/511#note_495288


Best,
Andrius

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Hakan Bayındır]

On 28.05.2024 ÖS 8:16, Andreas Metzler wrote:

On 2024-05-28 Luca Boccassi  
wrote:
[...]

- existing installations pre-trixie will get an orphaned tmpfiles.d in
/etc/ that keeps the existing behaviour unchanged (no cleanup of
/var/tmp)

[...]

Hello,

I think it is bad choice to deliberately have different behavior for
freshly installed and upgraded systems. Offering upgrades has always
been one of the major selling points of Debian, and imho this
implicitely includes that you do not get a worse or second class Debian
installation when you upgrade it than if you installed from scratch.

cu Andreas


I'll kindly disagree here. I'd rather not have to go back to every 
system and make sure that they all behave the way I want after doing a 
periodic, completely boring "apt-get upgrade".


Cheers,

H.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: MBF: drop dependencies on system-log-daemon

[Luca Boccassi]

On Wed, 29 May 2024 at 11:48, Lorenzo  wrote:
>
> Hi,
>
> socklog-run is a syslog daemon, it has no dependency on
> system-log-daemon

Yes the initial list had some false positives, it has been pruned when
filing and socklog-run is not part of it:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian.org;tag=system-log-daemon

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Luca Boccassi]

On Wed, 29 May 2024 at 08:18, Marc Haber  wrote:
>
> On Wed, 29 May 2024 00:44:29 +0200, Marco d'Itri  wrote:
> >On May 28, Andreas Metzler  wrote:
> >> I think it is bad choice to deliberately have different behavior for
> >> freshly installed and upgraded systems. Offering upgrades has always
> >> been one of the major selling points of Debian, and imho this
> >> implicitely includes that you do not get a worse or second class Debian
> >> installation when you upgrade it than if you installed from scratch.
> >I strongly disagree: it is a bad choice to change on upgrades a default
> >which may cause data loss.
>
> I also think that a change of this kind is release notes material. A
> system having been updated for two decades is bound to carry some
> cruft.


> - two paragraphs have been provided for the release notes ticket

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Marc Haber]

On Wed, 29 May 2024 00:44:29 +0200, Marco d'Itri  wrote:
>On May 28, Andreas Metzler  wrote:
>> I think it is bad choice to deliberately have different behavior for
>> freshly installed and upgraded systems. Offering upgrades has always
>> been one of the major selling points of Debian, and imho this
>> implicitely includes that you do not get a worse or second class Debian
>> installation when you upgrade it than if you installed from scratch.
>I strongly disagree: it is a bad choice to change on upgrades a default 
>which may cause data loss.

I also think that a change of this kind is release notes material. A
system having been updated for two decades is bound to carry some
cruft.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Marco d'Itri]

On May 28, Andreas Metzler  wrote:

> I think it is bad choice to deliberately have different behavior for
> freshly installed and upgraded systems. Offering upgrades has always
> been one of the major selling points of Debian, and imho this
> implicitely includes that you do not get a worse or second class Debian
> installation when you upgrade it than if you installed from scratch.
I strongly disagree: it is a bad choice to change on upgrades a default 
which may cause data loss.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andreas Metzler]

On 2024-05-28 Luca Boccassi  
wrote:
[...]
> - existing installations pre-trixie will get an orphaned tmpfiles.d in
> /etc/ that keeps the existing behaviour unchanged (no cleanup of
> /var/tmp)
[...]

Hello,

I think it is bad choice to deliberately have different behavior for
freshly installed and upgraded systems. Offering upgrades has always
been one of the major selling points of Debian, and imho this
implicitely includes that you do not get a worse or second class Debian
installation when you upgrade it than if you installed from scratch.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Russ Allbery]

Matthew Garrett  writes:
> On Mon, May 06, 2024 at 07:42:11AM -0700, Russ Allbery wrote:

>> Historically, deleting anything in /var/tmp that hadn't been accessed
>> in over seven days was a perfectly reasonable and typical
>> configuration.  These days, we have the complication that it's fairly
>> common to turn off atime updates for performance reasons, which makes
>> it a bit harder to implement that policy when /var/tmp isn't its own
>> partition and thus inherits that setting from the rest of the system.

> Apologies for being a bit late to this, but is this true? relatime-type 
> setups will still update atime if the time between the previous update 
> and the access is larger than some threshold, so you lose some degree of 
> granularity but the rough policy should still apply.

You are correct and I completely forgot about that.

-- 
Russ Allbery (r...@debian.org)  

Re: MBF: drop dependencies on system-log-daemon

[Luca Boccassi]

On Tue, 28 May 2024 at 08:43, Guillem Jover  wrote:
>
> Hi!
>
> On Tue, 2024-05-28 at 10:57:13 +0900, Simon Richter wrote:
> > On 5/27/24 22:18, Simon McVittie wrote:
> > > So I think your syslogd-is-journald could not be a Provides on the
> > > existing systemd-sysv package, and would have to be a separate package.
> > > I'm not sure that the benefit is worth it (and I see that Luca is sure
> > > that the benefit *isn't* worth it).
> >
> > I agree -- that's why I suggested changing the dependency to
> >
> > "systemd-sysv | system-log-daemon"
> >
> > This does not require an extra package, leaves out the system-log-daemon on
> > most systems, still leaves the option of co-installing a flat logging daemon
> > parallel to journald, and the packages work out-of-the-box on derived
> > non-systemd distributions, so we don't waste developer time on maintaining a
> > fork just for this issue.
>
> I also care about portability and non-default alternatives, so I
> assume for packages I maintain I'll be going instead with:
>
>   " | system-log-daemon | systemd-sysv"
>
> I don't think the original proposal is technically sound to represent
> what is really going on with logging, but given its tone and how it
> is being rushed (not even a day for discussion), it seems to me like
> spending time thinking or proposing alternatives would be a waste of
> time and energy.

That means such packages cannot be installed in minimal containers
without pulling in half the universe. And then people wonder why
Debian is slowly fading into irrelevance, and other distributions are
being built from scratch instead of using Debian for container guests.
Yes, let's ignore today's number one Linux use case by usage to avoid
ever so slightly inconveniencing an openly hostile downstream, that
sure sounds like a winning strategy if there ever was one.

Re: MBF: drop dependencies on system-log-daemon

[Luca Boccassi]

On Tue, 28 May 2024 at 02:57, Simon Richter  wrote:
>
> Hi,
>
> On 5/27/24 22:18, Simon McVittie wrote:
>
> > So I think your syslogd-is-journald could not be a Provides on the
> > existing systemd-sysv package, and would have to be a separate package.
> > I'm not sure that the benefit is worth it (and I see that Luca is sure
> > that the benefit *isn't* worth it).
>
> I agree -- that's why I suggested changing the dependency to
>
>  "systemd-sysv | system-log-daemon"
>
> This does not require an extra package, leaves out the system-log-daemon
> on most systems, still leaves the option of co-installing a flat logging
> daemon parallel to journald, and the packages work out-of-the-box on
> derived non-systemd distributions, so we don't waste developer time on
> maintaining a fork just for this issue.

That would mean tons of extra stuff gets pulled in single-process
containers using said package and similar setups, for exactly zero
advantages.

Re: t64 suffix

[Mathieu Malaterre]

On Mon, May 27, 2024 at 10:26 PM Steve Langasek  wrote:
>
> On Thu, May 23, 2024 at 08:14:20PM +0200, Mathieu Malaterre wrote:
> > Dear all,
>
> > I am trying to find the status of t64 suffix, but I cannot find it
> > neither in my mailbox nor on the page:
>
> > https://wiki.debian.org/ReleaseGoals/64bit-time#Transition_in_place
>
> > What is expected from Debian packager now ?
>
> > 1. Remove the t64 suffix upon next version upload ?
>
> Does the new version have a new soname? if not it would be incorrect to undo
> this transition.

Ack. Now that makes sense.

> > 2. Keep the package-name-doesnt-match-sonames lintian warning (for now) ?
>
> What package are you seeing such a warning on?  The mass-NMUs included a
> lintian override to suppress this warning.

I think I am missing something big here...anyway here it goes:

* https://udd.debian.org/lintian/?packages=highway

(I'll fix the symbols-file-contains-current-version-with-debian-revision asap).

Thanks all for your kind help
-M

Re: MBF: drop dependencies on system-log-daemon

[Guillem Jover]

Hi!

On Tue, 2024-05-28 at 10:57:13 +0900, Simon Richter wrote:
> On 5/27/24 22:18, Simon McVittie wrote:
> > So I think your syslogd-is-journald could not be a Provides on the
> > existing systemd-sysv package, and would have to be a separate package.
> > I'm not sure that the benefit is worth it (and I see that Luca is sure
> > that the benefit *isn't* worth it).
> 
> I agree -- that's why I suggested changing the dependency to
> 
> "systemd-sysv | system-log-daemon"
> 
> This does not require an extra package, leaves out the system-log-daemon on
> most systems, still leaves the option of co-installing a flat logging daemon
> parallel to journald, and the packages work out-of-the-box on derived
> non-systemd distributions, so we don't waste developer time on maintaining a
> fork just for this issue.

I also care about portability and non-default alternatives, so I
assume for packages I maintain I'll be going instead with:

  " | system-log-daemon | systemd-sysv"

I don't think the original proposal is technically sound to represent
what is really going on with logging, but given its tone and how it
is being rushed (not even a day for discussion), it seems to me like
spending time thinking or proposing alternatives would be a waste of
time and energy.

Regards,
Guillem

Re: MBF: drop dependencies on system-log-daemon

[Marc Haber]

On Mon, 27 May 2024 15:08:38 +0100, Simon McVittie 
wrote:
>I know fail2ban and logcheck do read plain-text logs (although as
>mentioned, fail2ban already has native Journal-reading support too), and I
>would guess that fwlogwatch, snort and xwatch probably also read the logs.

Those files could use alternatively journal-brief, which also nicely
handles the issue of having a "cursor". With journal-brief a package
could explicitly ask for all log entries since the last run without
having to implement their own method.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Matthew Garrett]

On Mon, May 06, 2024 at 07:42:11AM -0700, Russ Allbery wrote:
> Historically, deleting anything in /var/tmp that hadn't been accessed in
> over seven days was a perfectly reasonable and typical configuration.
> These days, we have the complication that it's fairly common to turn off
> atime updates for performance reasons, which makes it a bit harder to
> implement that policy when /var/tmp isn't its own partition and thus
> inherits that setting from the rest of the system.

Apologies for being a bit late to this, but is this true? relatime-type 
setups will still update atime if the time between the previous update 
and the access is larger than some threshold, so you lose some degree of 
granularity but the rough policy should still apply.

Re: MBF: drop dependencies on system-log-daemon

[Simon Richter]

Hi,

On 5/27/24 22:18, Simon McVittie wrote:


So I think your syslogd-is-journald could not be a Provides on the
existing systemd-sysv package, and would have to be a separate package.
I'm not sure that the benefit is worth it (and I see that Luca is sure
that the benefit *isn't* worth it).


I agree -- that's why I suggested changing the dependency to

"systemd-sysv | system-log-daemon"

This does not require an extra package, leaves out the system-log-daemon 
on most systems, still leaves the option of co-installing a flat logging 
daemon parallel to journald, and the packages work out-of-the-box on 
derived non-systemd distributions, so we don't waste developer time on 
maintaining a fork just for this issue.



Along similar lines, I have wondered about
dbus-{system,session}-bus-is-external packages as non-default providers
of dbus-{system,session}-bus, for use in containers that arrange for a
suitable socket to be bind-mounted in from outside, but I'm unsure how
much appetite there is for a proliferation of packages whose metadata
is larger than their content for purposes like these - especially if
they could accidentally get installed (possibly on real systems rather
than in containers) by users who have not actually made the documented
arrangements, resulting in spurious bug reports and extra support burden.


Indeed, but we only have the two options "make it declarative in the 
package namespace" and "make it an essential service that packages may 
rely on without making a declaration."


The latter would imply that we'd need to officially state that using 
Debian packages for Docker containers or inside CI runners is 
unsupported, because these don't fulfill the requirements for essential 
services.


   Simon

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Luca Boccassi]

On Sun, 5 May 2024 at 21:04, Luca Boccassi  wrote:
>
> On Tue, 5 Jul 2022 19:42:37 +0200 Michael Biebl 
> wrote:
> >
> > Hi Eric
> >
> > On Fri, 31 Jul 2020 15:12:48 + Eric Desrochers
> >  wrote:
> > > Package: systemd
> > > Version: 245.7-1
> > > Severity: normal
> > >
> > > Dear Maintainer,
> > >
> > > Debian systemd implementation does not clean
> > > /var/tmp by default.
> > >
> > > * quilt patch:
> > > d/p/debian/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-
> defaul.patch
> > >
> > > * systemd-245.7/tmpfiles.d/tmp.conf:
> > > #q /var/tmp 1777 root root 30d
> > >
> > > The patch exist in Debian since 2012.
> > >
> > > The topic has been discussed and a few suggestion has been put on
> the
> > > table in the following Ubuntu bug:
> https://launchpad.net/bugs/1870585
> > >
> > > I fill this bug today to start a conversation.
> >
> > I haven't received any further input from your side.
> > Are you still interested in this issue or not?
> > I wonder where to go from here and what to do about this bug report.
>
> I think it's been long enough, and for Trixie we should bring the
> defaults in line with upstream and other distributions, which means:
>
> - /tmp/ is a tmpfs
> - /var/tmp/ is cleaned up on a timer
>
> Hence, I intend to apply these changes in the next src:systemd upload
> to unstable, probably next week.
>
> This will be mentioned in NEWS (and I guess in the release notes when
> the time comes), together with the instructions to override for anybody
> wanting to keep the old behaviour, which is as trivial as:
>
> systemctl mask tmp.mount (or touch /etc/systemd/system/tmp.mount)
> touch /etc/tmpfiles.d/tmp.conf
>
> for the former and the latter respectively.
>
> In case anybody is aware of packages/programs needing an update to cope
> with these changes, or any other issue, please let me know and I will
> file bugs.

Thanks for the useful input, the following has been done:

- existing installations pre-trixie will get an orphaned tmpfiles.d in
/etc/ that keeps the existing behaviour unchanged (no cleanup of
/var/tmp)
- openssh and tmux have been fixed to provide a tmpfiles.d exception
to retain their respective files
- the /tmp/ description in debian-installer has been updated to note
it is a tmpfs by default (via a commit in partman-basicfilesystems,
will upload if nobody gets around to it before Trixie's freeze)
- two paragraphs have been provided for the release notes ticket
- the changes are also noted in NEWS, with instructions on how to
override locally
- as mentioned, the latest upload to unstable makes /tmp/ a tmpfs by
default and for new installations 10+ days old files in /tmp/ and 30+
days old files in /var/tmp/ are cleaned up daily

If anybody wants to spend time to provide a MR to query in
debian-installer whether to optionally customize these changes locally
on installation, I will happily review and merge it.

Re: Debian 10 "buster" moved to archive.debian.org

[Leandro Cunha]

Hi,

On Fri, May 24, 2024 at 10:28 PM Otto Kekäläinen  wrote:
>
> Hi!
>
> So just to clarify, are you saying that a copy of
> https://security.debian.org/debian-security/dists/buster/ will never
> be archived at https://archive.debian.org/debian-security/dists/ like
> previous releases have been so far?
>
> This is not about getting *new security updates*, but purely a
> question of how moving Buster to archival works and how e.g. CI
> systems that test upgrades from Buster should work.
>
> I see that e.g.
> https://deb.debian.org/debian/dists/buster/main/binary-armel and
> https://deb.debian.org/debian/dists/buster-updates/main/binary-armel
> no longer exists, but have been archived at
> https://archive.debian.org/debian/dists/buster/main/binary-armel/ and
> https://archive.debian.org/debian/dists/buster-updates/main/binary-armel/.
>
> The 
> https://security.debian.org/debian-security/dists/buster/updates/main/binary-armel
> is now gone, is the intent for it to show up on archive.debian.org in
> some form?

True, you're right, the buster is missing from
https://archive.debian.org/debian-security/dists/ and I'm waiting for
a response from the people who take care of this repository about
this. I think they forgot to migrate.

-- 
Cheers,
Leandro Cunha

Re: t64 suffix

[Steve Langasek]

On Thu, May 23, 2024 at 08:14:20PM +0200, Mathieu Malaterre wrote:
> Dear all,

> I am trying to find the status of t64 suffix, but I cannot find it
> neither in my mailbox nor on the page:

> https://wiki.debian.org/ReleaseGoals/64bit-time#Transition_in_place

> What is expected from Debian packager now ?

> 1. Remove the t64 suffix upon next version upload ?

Does the new version have a new soname? if not it would be incorrect to undo
this transition.

> 2. Keep the package-name-doesnt-match-sonames lintian warning (for now) ?

What package are you seeing such a warning on?  The mass-NMUs included a
lintian override to suppress this warning.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: MBF: drop dependencies on system-log-daemon

[Richard Lewis]

Russ Allbery  writes:

> Simon McVittie  writes:
>
>> I know fail2ban and logcheck do read plain-text logs (although as
>> mentioned, fail2ban already has native Journal-reading support too), and
>> I would guess that fwlogwatch, snort and xwatch probably also read the
>> logs.
>
> logcheck also has native journal-reading support.
>
> Note that its dependency is only Suggests.  I have not checked if that's
> there for some other reason.

(oops, I thought i'd read to the end of the thread!)

The suggests is only retained for non-systemd users, since without some
logging thing, logcheck isnt going to do much out of the box.

It would ideally recommend:
- journal| rsyslog| system-log-daemon (if under systemd)
- rsyslog | rystem-log-daemon (if not)

but that seemed too hard withough potentialy installing systemd or
rsyslog on systems that dont want them.

Re: MBF: drop dependencies on system-log-daemon

[Richard Lewis]

Simon McVittie  writes:

> On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
>> The list of affected packages according to apt-cache showpkg is not
>> that long either:
>> 

>>   logcheck


> However, for packages that want to read a traditional /var/log/syslog
> or similar, notably logcheck,

No, logcheck checks the systemd journal by default since bookworm. it
works with any combination of systemd, syslog (or other log files if you
configure it)

logcheck in stable has 'Suggests: rsyslog | system-log-daemon' -- not
sure how that could be any weaker so i suspect a false positive here?

Re: MBF: drop dependencies on system-log-daemon

[Luca Boccassi]

On Mon, 27 May 2024 at 17:04, Russ Allbery  wrote:
>
> Simon McVittie  writes:
>
> > I know fail2ban and logcheck do read plain-text logs (although as
> > mentioned, fail2ban already has native Journal-reading support too), and
> > I would guess that fwlogwatch, snort and xwatch probably also read the
> > logs.
>
> logcheck also has native journal-reading support.
>
> Note that its dependency is only Suggests.  I have not checked if that's
> there for some other reason.

Yeah apt-cache listed Suggests too in a single lump, but I've already
skipped them when filing since that's fine to have.

Re: MBF: drop dependencies on system-log-daemon

[Russ Allbery]

Simon McVittie  writes:

> I know fail2ban and logcheck do read plain-text logs (although as
> mentioned, fail2ban already has native Journal-reading support too), and
> I would guess that fwlogwatch, snort and xwatch probably also read the
> logs.

logcheck also has native journal-reading support.

Note that its dependency is only Suggests.  I have not checked if that's
there for some other reason.

-- 
Russ Allbery (r...@debian.org)  

Re: MBF: drop dependencies on system-log-daemon

[Luca Boccassi]

On Mon, 27 May 2024 at 15:09, Simon McVittie  wrote:
>
> On Mon, 27 May 2024 at 14:38:44 +0100, Luca Boccassi wrote:
> > Yes this sounds reasonable - do you already have an idea about which
> > is which, from the list above?
>
> Nothing reliable, so please check before opening bugs.
>
> I know fail2ban and logcheck do read plain-text logs (although as
> mentioned, fail2ban already has native Journal-reading support too), and I
> would guess that fwlogwatch, snort and xwatch probably also read the logs.
>
> >From my limited knowledge of what they do, I would guess that approx,
> hippotat, inetutils-*d, request-tracker*, *inetd and spamd are just log
> sources that need a syslog-compatible logging sink, for which either
> journald or a traditional syslogd should be equally valid.
>
> The others, no idea.

Filed bugs, it's just 16 after a cursory look to exclude a few. I've
included a note saying explicitly it's fine to keep a dependency for
the case you pointed out, that should be enough.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian.org;tag=system-log-daemon

Re: MBF: drop dependencies on system-log-daemon

[Simon McVittie]

On Mon, 27 May 2024 at 14:38:44 +0100, Luca Boccassi wrote:
> Yes this sounds reasonable - do you already have an idea about which
> is which, from the list above?

Nothing reliable, so please check before opening bugs.

I know fail2ban and logcheck do read plain-text logs (although as
mentioned, fail2ban already has native Journal-reading support too), and I
would guess that fwlogwatch, snort and xwatch probably also read the logs.

>From my limited knowledge of what they do, I would guess that approx,
hippotat, inetutils-*d, request-tracker*, *inetd and spamd are just log
sources that need a syslog-compatible logging sink, for which either
journald or a traditional syslogd should be equally valid.

The others, no idea.

smcv

Re: MBF: drop dependencies on system-log-daemon

[Luca Boccassi]

On Mon, 27 May 2024 at 13:59, Simon McVittie  wrote:
>
> On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
> > The list of affected packages according to apt-cache showpkg is not
> > that long either:
> >
> >   anacron
> >   approx
> >   fail2ban
> >   fwlogwatch
> >   heartbeat
> >   hippotat-server
> >   inetutils-ftpd
> >   inetutils-inetd
> >   inetutils-talkd
> >   inetutils-telnetd
> >   ldirectord
> >   logcheck
> >   lyskom-server
> >   prelude-lml
> >   psad
> >   request-tracker4
> >   request-tracker5
> >   rlinetd
> >   snort
> >   socklog-run
> >   socklog-run:i386
> >   spamd
> >   sympa
> >   xinetd
> >   xwatch
> >   zoneminder
>
> I think we can divide these into: packages that want to write to a logging
> service via the syslog protocol, and packages that want to read a
> traditional plain-text syslog file.
>
> For packages that want to write out messages via syslog(3) or equivalent
> and have them get written out somewhere that the sysadmin can see them,
> I agree that the systemd Journal (whether persistent or volatile) is
> sufficient to provide a suitable log sink. Obviously many sysadmins will
> want these messages to persist across a reboot, but that's a configuration
> choice, for which I think defaulting to persistent but allowing volatile
> at the sysadmin's own risk is a good arrangement.
>
> However, for packages that want to read a traditional /var/log/syslog
> or similar, notably logcheck, I think it might still make sense to declare
> a dependency on system-log-daemon - this is not functionality that the
> systemd Journal provides. Obviously the same information exists and can
> be retrieved by journalctl(1) or via libsystemd, or received and written
> out to the traditional flat file over time by rsyslog or equivalent,
> but it's no longer provided as a flat file on disk by default.

Yes this sounds reasonable - do you already have an idea about which
is which, from the list above? And it's fine if the answer is no, I
can look it up myself, just in case you already know about some of
those.

Re: MBF: drop dependencies on system-log-daemon

[Simon McVittie]

On Mon, 27 May 2024 at 21:38:07 +0900, Simon Richter wrote:
> My train of thought here is that there should be a "syslogd-is-journald"
> package that Provides/Conflicts system-log-daemon
...
> hence the idea to use systemd-sysv instead of a new empty
> package as the alternative

I wonderered about this too.

There is an issue with this which is unique to the journald/syslog
case. We actively don't want systemd-sysv to have Provides/Conflicts on
system-log-daemon, because as I've tried to clarify elsewhere in this
thread, there are use-cases where people will want to co-install systemd
and a traditional flat-file syslog implementation, in order to have the
logging pipeline that was the default in Debian 11:

service --> syslog(3) --> journald --> rsyslogd --> flat text files
|
\--> binary storage
 (on tmpfs or disk, your choice)

because some of their tools or workflows rely on having a flat text
file, or because they value the redundancy and lack-of-structure of a
flat text file for better ability to recover partial information from
a corrupted log.

So I think your syslogd-is-journald could not be a Provides on the
existing systemd-sysv package, and would have to be a separate package.
I'm not sure that the benefit is worth it (and I see that Luca is sure
that the benefit *isn't* worth it).

Along similar lines, I have wondered about
dbus-{system,session}-bus-is-external packages as non-default providers
of dbus-{system,session}-bus, for use in containers that arrange for a
suitable socket to be bind-mounted in from outside, but I'm unsure how
much appetite there is for a proliferation of packages whose metadata
is larger than their content for purposes like these - especially if
they could accidentally get installed (possibly on real systems rather
than in containers) by users who have not actually made the documented
arrangements, resulting in spurious bug reports and extra support burden.

smcv

Re: MBF: drop dependencies on system-log-daemon

[Luca Boccassi]

On Mon, 27 May 2024 at 13:41, Simon McVittie  wrote:
>
> On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
> > In Bookworm we enabled persistent journald by default, which was the
> > right choice. The problem is that some packages declare a dependency on
> > the virtual package system-log-daemon, which we cannot add on systemd
> > given it would make rsyslog and other packages that also declare it
> > uninstallable, which is not nice.
>
> Expanding on that a little, because it isn't 100% obvious:
>
> rsyslog and other system-log-daemon implementations have
> Provides/Conflicts system-log-daemon. I believe the idea is that this
> is required in order to avoid having more than one system-log-daemon
> implementation try to listen on the same AF_UNIX socket (/dev/log)
> on non-systemd systems, which would not work.
>
> On systemd systems, if I understand correctly it's always the Journal
> that listens on that socket, and the system-log-daemon is responsible
> for switching into a mode where it receives messages from the Journal -
> is that correct? (But this probably still only works for a single
> system-log-daemon at a time, and having more than one wouldn't make sense
> even if it does work, because they'd fight over filenames like
> /var/log/syslog.)
>
> systemd(-sysv) could add Provides: system-log-daemon and it would satisfy
> the Depends by the packages mentioned in this MBF, but that would still
> make rsyslog uninstallable, because the Conflicts is still effective
> even if only one side of the conflict declares it.
>
> We presumably want rsyslog etc. to remain installable on systemd systems,
> because some sysadmins don't want to rely on the persistent Journal as
> their only log destination, and would prefer to have a text version that
> can remain somewhat readable even in the presence of file corruption, or
> would prefer to have a text version because their other tools consume it.
>
> So the only remaining choice is the status quo: systemd(-sysv) *do not*
> have a Provides: system-log-daemon. But then most of the dependent
> packages need to change, if we want the persistent Journal to be enough
> to satisfy their dependencies (which makes sense).
>
> Is that all correct?

Yep, that's the gist of it

Re: MBF: drop dependencies on system-log-daemon

[Simon McVittie]

On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
> The list of affected packages according to apt-cache showpkg is not
> that long either:
> 
>   anacron
>   approx
>   fail2ban
>   fwlogwatch
>   heartbeat
>   hippotat-server
>   inetutils-ftpd
>   inetutils-inetd
>   inetutils-talkd
>   inetutils-telnetd
>   ldirectord
>   logcheck
>   lyskom-server
>   prelude-lml
>   psad
>   request-tracker4
>   request-tracker5
>   rlinetd
>   snort
>   socklog-run
>   socklog-run:i386
>   spamd
>   sympa
>   xinetd
>   xwatch
>   zoneminder

I think we can divide these into: packages that want to write to a logging
service via the syslog protocol, and packages that want to read a
traditional plain-text syslog file.

For packages that want to write out messages via syslog(3) or equivalent
and have them get written out somewhere that the sysadmin can see them,
I agree that the systemd Journal (whether persistent or volatile) is
sufficient to provide a suitable log sink. Obviously many sysadmins will
want these messages to persist across a reboot, but that's a configuration
choice, for which I think defaulting to persistent but allowing volatile
at the sysadmin's own risk is a good arrangement.

However, for packages that want to read a traditional /var/log/syslog
or similar, notably logcheck, I think it might still make sense to declare
a dependency on system-log-daemon - this is not functionality that the
systemd Journal provides. Obviously the same information exists and can
be retrieved by journalctl(1) or via libsystemd, or received and written
out to the traditional flat file over time by rsyslog or equivalent,
but it's no longer provided as a flat file on disk by default.

If these log consumers have not been updated to be able to read messages
out via journald's C API (or the journalctl CLI if they must), then they
do still have a functional dependency on rsyslog or one of its competitors,
so I think they do still genuinly need a dependency.
It would make sense to file a wishlist bug asking for them to be taught
to bypass the flat file and read directly from the Journal, but I don't
think that's really quite the same category of bug report as something
like approx or spamd that just wants a working logging destination, and
until that feature has been written, they genuinely do need a traditional
syslog implementation.

See also recent bug traffic in src:fail2ban about teaching fail2ban
to read from the systemd Journal, instead of relying on having the
traditional syslog flat-files from which it can read log records for
failed sshd logins. (The required configuration change seems to have
been to change `backend = auto` to `backend = systemd` by default,
and bump up the Recommends on python3-systemd to a Depends.)

smcv

Re: MBF: drop dependencies on system-log-daemon

[Luca Boccassi]

On Mon, 27 May 2024 at 13:38, Simon Richter  wrote:
>
> Hi,
>
> On 5/27/24 19:59, Luca Boccassi wrote:
>
> > This MBF is
> > not about removing the virtual provides where they are defined, they
> > can stay as-is, but downgrading/removing the hard dependencies so that
> > we can make Debian minimal images.
>
> So the policy becomes "a logging service is present even if not
> explicitly declared." -- that sounds kind of like an Essential package,
> except that the interface is injected externally, and not visible in the
> package namespace.

This is already the case, and that's a good thing - a running host
without a logging system is just nonsensical in this day and age.

> My train of thought here is that there should be a "syslogd-is-journald"
> package that Provides/Conflicts system-log-daemon, so I can explicitly
> select this during container image creation with the existing package
> selection mechanism -- basically if I build a container image with
> syslogd-is-journald, then it becomes my responsibility to fulfill that
> promise, just as it is my responsibility to start rsyslog from my
> entrypoint when I build with rsyslog.
>
> We cannot really avoid a regression for container builders here: the
> implicit dependency on (effectively) rsyslog will go away, and if their
> entrypoint starts it explicitly (because no one uses sysvinit in a
> container) without having it listed in the package list, that is broken
> anyway.
>
>  From systemd's immutable system images point of view, I think at least
> systemd must be installed into the immutable image anyway (for the
> default units in /usr/lib to be defined), and systemd-sysv on top of
> that doesn't use much space -- hence the idea to use systemd-sysv
> instead of a new empty package as the alternative.

Nope, not going to add weird empty packages just for the hypothetical
benefits of downstreams, sorry - said downstreams can do the work
themselves if they want to. People want to install rsyslog for things
like network export protocols, and should still be allowed to do that
without impediment.

Re: MBF: drop dependencies on system-log-daemon

[Simon McVittie]

On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
> In Bookworm we enabled persistent journald by default, which was the
> right choice. The problem is that some packages declare a dependency on
> the virtual package system-log-daemon, which we cannot add on systemd
> given it would make rsyslog and other packages that also declare it
> uninstallable, which is not nice.

Expanding on that a little, because it isn't 100% obvious:

rsyslog and other system-log-daemon implementations have
Provides/Conflicts system-log-daemon. I believe the idea is that this
is required in order to avoid having more than one system-log-daemon
implementation try to listen on the same AF_UNIX socket (/dev/log)
on non-systemd systems, which would not work.

On systemd systems, if I understand correctly it's always the Journal
that listens on that socket, and the system-log-daemon is responsible
for switching into a mode where it receives messages from the Journal -
is that correct? (But this probably still only works for a single
system-log-daemon at a time, and having more than one wouldn't make sense
even if it does work, because they'd fight over filenames like
/var/log/syslog.)

systemd(-sysv) could add Provides: system-log-daemon and it would satisfy
the Depends by the packages mentioned in this MBF, but that would still
make rsyslog uninstallable, because the Conflicts is still effective
even if only one side of the conflict declares it.

We presumably want rsyslog etc. to remain installable on systemd systems,
because some sysadmins don't want to rely on the persistent Journal as
their only log destination, and would prefer to have a text version that
can remain somewhat readable even in the presence of file corruption, or
would prefer to have a text version because their other tools consume it.

So the only remaining choice is the status quo: systemd(-sysv) *do not*
have a Provides: system-log-daemon. But then most of the dependent
packages need to change, if we want the persistent Journal to be enough
to satisfy their dependencies (which makes sense).

Is that all correct?

smcv

Re: MBF: drop dependencies on system-log-daemon

[Simon Richter]

Hi,

On 5/27/24 19:59, Luca Boccassi wrote:


This MBF is
not about removing the virtual provides where they are defined, they
can stay as-is, but downgrading/removing the hard dependencies so that
we can make Debian minimal images.


So the policy becomes "a logging service is present even if not 
explicitly declared." -- that sounds kind of like an Essential package, 
except that the interface is injected externally, and not visible in the 
package namespace.


My train of thought here is that there should be a "syslogd-is-journald" 
package that Provides/Conflicts system-log-daemon, so I can explicitly 
select this during container image creation with the existing package 
selection mechanism -- basically if I build a container image with 
syslogd-is-journald, then it becomes my responsibility to fulfill that 
promise, just as it is my responsibility to start rsyslog from my 
entrypoint when I build with rsyslog.


We cannot really avoid a regression for container builders here: the 
implicit dependency on (effectively) rsyslog will go away, and if their 
entrypoint starts it explicitly (because no one uses sysvinit in a 
container) without having it listed in the package list, that is broken 
anyway.


From systemd's immutable system images point of view, I think at least 
systemd must be installed into the immutable image anyway (for the 
default units in /usr/lib to be defined), and systemd-sysv on top of 
that doesn't use much space -- hence the idea to use systemd-sysv 
instead of a new empty package as the alternative.


   Simon

Re: MBF: drop dependencies on system-log-daemon

[Luca Boccassi]

On Mon, 27 May 2024 at 12:53, Ansgar   wrote:
>
> Hi,
>
> On Mon, 2024-05-27 at 03:29 +0100, Luca Boccassi wrote:
> > TL;DR: drop or downgrade dependency on system-log-daemon from any
> > package that declares it
>
> +1. Log service freedom is important. Packages should in general not
> pull in a log service as a dependency.
>
> > The list of affected packages according to apt-cache showpkg is not
> > that long either:
> >
> >   anacron
> >   approx
> >   fail2ban
> >   fwlogwatch
> >   heartbeat
> >   hippotat-server
> >   inetutils-ftpd
> >   inetutils-inetd
> >   inetutils-talkd
> >   inetutils-telnetd
> >   ldirectord
> >   logcheck
> >   lyskom-server
> >   prelude-lml
> >   psad
> >   request-tracker4
> >   request-tracker5
> >   rlinetd
> >   snort
> >   socklog-run
> >   socklog-run:i386
> >   spamd
> >   sympa
> >   xinetd
> >   xwatch
> >   zoneminder
>
> At first glance these all look like packages that should leave the
> decision whether/how to log to the admin.
>
> However there are false positives: for example xinetd already dropped
> the recommendation some time ago (Oct 2023)[1].  Maybe you used
> information from stable to generate the list?

Yeah I did - it's few packages enough that I was just going to double
check before actually filing the bugs

Re: MBF: drop dependencies on system-log-daemon

[Luca Boccassi]

On Mon, 27 May 2024 at 06:00, Simon Richter  wrote:
>
> Hi,
>
> On 5/27/24 11:29, Luca Boccassi wrote:
>
> > With the default system installation including persistent journald by
> > default, it doesn't seem useful anymore to have such dependencies. They
> > are leftovers from an era where not having a system logging setup that
> > just worked by default was a thing, and fortunately we are long past
> > that today.
>
> There is no need to advertise for the default setting. :)
>
> For the benefit of Devuan, we could change this to "systemd-sysv |
> system-log-daemon".
>
> The only breakage resulting from this change would be Debian based
> container images that pull in a (nonfunctional, because not entrypoint)
> systemd instead of the logging daemon they expect, but that also breaks
> when we demote the dependency, so that's not worse.
>
> And anyone using a different entrypoint is unsupported by Debian anyway.

I don't think we should actively make Debian worse in order to maybe
save some minor work for downstreams (being a downstream means at the
very least reconfiguring what your upstream does, if it's a 1:1 copy
then it doesn't make sense to exist in the first place). This MBF is
not about removing the virtual provides where they are defined, they
can stay as-is, but downgrading/removing the hard dependencies so that
we can make Debian minimal images. These dependencies can be trivially
added back by downstreams, if they are needed where they are, or in
different packages.

Re: MBF: drop dependencies on system-log-daemon

[Ansgar ]

Hi,

On Mon, 2024-05-27 at 03:29 +0100, Luca Boccassi wrote:
> TL;DR: drop or downgrade dependency on system-log-daemon from any
> package that declares it

+1. Log service freedom is important. Packages should in general not
pull in a log service as a dependency.

> The list of affected packages according to apt-cache showpkg is not
> that long either:
> 
>   anacron
>   approx
>   fail2ban
>   fwlogwatch
>   heartbeat
>   hippotat-server
>   inetutils-ftpd
>   inetutils-inetd
>   inetutils-talkd
>   inetutils-telnetd
>   ldirectord
>   logcheck
>   lyskom-server
>   prelude-lml
>   psad
>   request-tracker4
>   request-tracker5
>   rlinetd
>   snort
>   socklog-run
>   socklog-run:i386
>   spamd
>   sympa
>   xinetd
>   xwatch
>   zoneminder

At first glance these all look like packages that should leave the
decision whether/how to log to the admin.

However there are false positives: for example xinetd already dropped
the recommendation some time ago (Oct 2023)[1].  Maybe you used
information from stable to generate the list?

Ansgar

  [1]: 
https://tracker.debian.org/news/1474312/accepted-xinetd-123154-1-source-into-unstable/

Re: Bug#1071991: ITP: fastobj -- Simple single-header library OBJ loader

[Simon Richter]

Hi,

On 5/27/24 17:08, Federico Ceratto wrote:


   Description : Simple OBJ loader


Can this somehow include the word "Wavefront", or a hint that this is 
about 3D models? OBJ is also used to refer to relocatable object files 
on MS-DOS.


   Simon

Re: MBF: drop dependencies on system-log-daemon

[Simon Richter]

Hi,

On 5/27/24 11:29, Luca Boccassi wrote:


With the default system installation including persistent journald by
default, it doesn't seem useful anymore to have such dependencies. They
are leftovers from an era where not having a system logging setup that
just worked by default was a thing, and fortunately we are long past
that today.


There is no need to advertise for the default setting. :)

For the benefit of Devuan, we could change this to "systemd-sysv | 
system-log-daemon".


The only breakage resulting from this change would be Debian based 
container images that pull in a (nonfunctional, because not entrypoint) 
systemd instead of the logging daemon they expect, but that also breaks 
when we demote the dependency, so that's not worse.


And anyone using a different entrypoint is unsupported by Debian anyway.

   Simon

Re: MBF: Building packages in the (not so distant) future

[Scott Kitterman]

On May 26, 2024 6:14:40 PM UTC, Bastian Blank  wrote:
>On Sun, May 26, 2024 at 05:43:54PM +, Scott Kitterman wrote:
>> On May 26, 2024 5:35:27 PM UTC, Santiago Vila  wrote:
>> >https://people.debian.org/~sanvila/build-logs/trixie-time-bomb/
>> The clamav issue looks like a false positive.  The distro-info data will get 
>> updated between now and then.
>
>I see this failure:
>
>| Test that clam can trust an EXE based on an authenticode certificate check.
>
>This clearly sounds like an expiration date somewhere, esp as this looks
>like a shipped binary.
>
>So, you where talking about developers-reference.  However I don't see
>how a probable update of distro-info would make this a false positive.
>In fact, it is an explicit time bomb.

I don't think that's wrong, but I think it's a distro-info bug if it's out of 
date.  I don't think that a package is inherently buggy for relying on it.  I 
don't think distro-info is currently buggy either.  It will require a future 
update, but that's not a current bug.

Scott K

Re: About i386 support

[Steve Langasek]

On Sat, May 18, 2024 at 10:28:21AM +, Andrew M.A. Cater wrote:
> Pretty much every major Linux distribution is dropping _any_ 32 bit: Debian
> is trying to support 32 bit on armhf, for example, which is more than
> Ubuntu and Fedora.

I don't know what you're basing it on, but it's simply not true.  We've just
released Ubuntu 24.04 LTS with full support for (2038-proof) armhf
userspace.

We don't have any armhf images released with 24.04 LTS because we've dropped
32-bit support for *Raspberry Pi*, but that's a separate matter.  We expect
support for other armhf devices for both Ubuntu and Ubuntu Core to come soon
in 24.04.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: MBF: Building packages in the (not so distant) future

[Otto Kekäläinen]

Plus one to this initiative!

I also wanted to share the tip to use libfaketime as the easiest way
to test if a build or test suite works on an arbitrary future date. I
am currently testing that the MariaDB upstream test suite passes in
2037 and 2028 using libfaketime like this:
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/74/diffs#diff-content-b1dbf22e88351ec0d5d1d1a7f53295504b480e61

Syntax: faketime  
Example: faketime "2038-03-03" mariadb-test-run

Re: MBF: Building packages in the (not so distant) future

[Bastian Blank]

On Sun, May 26, 2024 at 05:43:54PM +, Scott Kitterman wrote:
> On May 26, 2024 5:35:27 PM UTC, Santiago Vila  wrote:
> >https://people.debian.org/~sanvila/build-logs/trixie-time-bomb/
> The clamav issue looks like a false positive.  The distro-info data will get 
> updated between now and then.

I see this failure:

| Test that clam can trust an EXE based on an authenticode certificate check.

This clearly sounds like an expiration date somewhere, esp as this looks
like a shipped binary.

So, you where talking about developers-reference.  However I don't see
how a probable update of distro-info would make this a false positive.
In fact, it is an explicit time bomb.

Bastian

-- 
No one wants war.
-- Kirk, "Errand of Mercy", stardate 3201.7

Re: MBF: Building packages in the (not so distant) future

[Stefano Rivera]

Hi Scott (2024.05.26_17:43:54_+)
> The clamav issue looks like a false positive.  The distro-info data
> will get updated between now and then.

Same goes for distro-info, itself.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: MBF: Building packages in the (not so distant) future

[Alexandre Detiste]

Le dim. 26 mai 2024 à 19:35, Santiago Vila  a écrit :
> * It would be wonderful if reproducible-builds people could set the
> time-to-build-in-future for trixie and sid to three years after the
> estimated release date of trixie (I believe they use six months ahead
> of time, which imo it's not enough).

And/or anything with not the same "leapness" as current year.

https://gitlab.com/doctormo/python-crontab/-/issues/109

Re: MBF: Building packages in the (not so distant) future

[Philipp Kern]

On 26.05.24 19:35, Santiago Vila wrote:

My plan is to file bug reports for the causing packages, initially
as severity:important bugs as a "grace period". (Paul asked me not to
report this as RC yet, because the t64 transition has not finished yet.
On the other hand, he also pointed out that now is the appropriate
time to report those bugs).


I fixed libinfinity upstream - but would still need to make an upload. 
It's quite ironic, given that all certs but one had an expiry around the 
year 3000.


Kind regards
Philipp Kern

Re: MBF: Building packages in the (not so distant) future

[Scott Kitterman]

On May 26, 2024 5:35:27 PM UTC, Santiago Vila  wrote:
>Greetings.
>
>After we make a stable release, there is usually a constant flow
>of packages which start to FTBFS due to "time bombs", i.e. expired
>SSL certificates used in tests and other similar reasons.
>
>This is not fun for anybody trying to keep stable free of FTBFS bugs,
>but fortunately we can do better than that.
>
>According to Paul Gevers, who allowed me to quote him on this, if we
>know for sure that a package will FTBFS during the support time of
>the release, then it's RC.
>
>So, if we aim at releasing stable every two years, and we released bookworm
>at 2023-06-10, then the estimated support timeframe for trixie will be
>approximately from 2025-06-10 to 2028-06-10 (two years as stable plus one
>year as oldstable).
>
>Therefore, I set my clock at 2028-06-10 and built trixie/sid on such date,
>and found around 50 packages with time bomb issues of all kinds. A preliminary
>list of build logs is available here:
>
>https://people.debian.org/~sanvila/build-logs/trixie-time-bomb/

The clamav issue looks like a false positive.  The distro-info data will get 
updated between now and then.

Scott K

Re: Debian 10 "buster" moved to archive.debian.org

[Otto Kekäläinen]

Hi!

So just to clarify, are you saying that a copy of
https://security.debian.org/debian-security/dists/buster/ will never
be archived at https://archive.debian.org/debian-security/dists/ like
previous releases have been so far?

This is not about getting *new security updates*, but purely a
question of how moving Buster to archival works and how e.g. CI
systems that test upgrades from Buster should work.

I see that e.g.
https://deb.debian.org/debian/dists/buster/main/binary-armel and
https://deb.debian.org/debian/dists/buster-updates/main/binary-armel
no longer exists, but have been archived at
https://archive.debian.org/debian/dists/buster/main/binary-armel/ and
https://archive.debian.org/debian/dists/buster-updates/main/binary-armel/.

The 
https://security.debian.org/debian-security/dists/buster/updates/main/binary-armel
is now gone, is the intent for it to show up on archive.debian.org in
some form?

Re: salsa web server broken?

[Vincent Lefevre]

On 2024-05-24 11:51:15 +0200, Alexander Wirt wrote:
> Am Fri, May 24, 2024 at 11:23:44AM +0200 schrieb Vincent Lefevre:
> > Is the salsa web server broken?
> > 
> > The display of https://salsa.debian.org/python-team/packages/fail2ban
> > is completely wrong, and https://salsa.debian.org/ gives an
> >
> We are in maintenance. 

OK. A mail is usually sent to debian-infrastructure-announce, but
this time, there was no such mail.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: salsa web server broken?

[Alexander Wirt]

Am Fri, May 24, 2024 at 11:23:44AM +0200 schrieb Vincent Lefevre:
> Is the salsa web server broken?
> 
> The display of https://salsa.debian.org/python-team/packages/fail2ban
> is completely wrong, and https://salsa.debian.org/ gives an
>
We are in maintenance. 

Alex
 

Re: changing existing entries in debian/changelog

[Johannes Schauer Marin Rodrigues]

Quoting Bill Allombert (2024-05-24 10:54:32)
> Le Fri, May 24, 2024 at 09:30:44AM +0200, Bastian Venthur a écrit :
> > Hi,
> > 
> > I'm having troubles finding the relevant parts in the developers reference.
> > I've uploaded a version to experimental and later found out that this
> > version fixes several bugs.
> > 
> > Can I rewrite existing changelog entries for already uploaded versions with
> > the next upload, i.e. by adding the relevant "closes" line to the previsions
> > version?
> 
> You need to use the option -v of dpkg-genchanges so that the relevant
> bugs are listed in the .changes file, so that they get automatically closed.

But then they get closed by the wrong version, no? Dev-ref says:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-bugs-are-closed-by-new-uploads

> To close any remaining bugs that were fixed by your upload, email the
> .changes file to xxx-d...@bugs.debian.org, where XXX is the bug number, and
> put Version: YYY and an empty line as the first two lines of the body of the
> email, where YYY is the first version where the bug has been fixed.

When I don't have the .changes file anymore, I just mail
xxx-d...@bugs.debian.org with a mail that has the "Version: YYY" line at the
top and then in the body explains that I'm manually closing it because I made a
mistake.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: changing existing entries in debian/changelog

[Bill Allombert]

Le Fri, May 24, 2024 at 09:30:44AM +0200, Bastian Venthur a écrit :
> Hi,
> 
> I'm having troubles finding the relevant parts in the developers reference.
> I've uploaded a version to experimental and later found out that this
> version fixes several bugs.
> 
> Can I rewrite existing changelog entries for already uploaded versions with
> the next upload, i.e. by adding the relevant "closes" line to the previsions
> version?

You need to use the option -v of dpkg-genchanges so that the relevant
bugs are listed in the .changes file, so that they get automatically
closed.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: changing existing entries in debian/changelog

[Johannes Schauer Marin Rodrigues]

Quoting Andrey Rakhmatullin (2024-05-24 09:37:45)
> On Fri, May 24, 2024 at 09:30:44AM +0200, Bastian Venthur wrote:
> > I'm having troubles finding the relevant parts in the developers reference.
> > I've uploaded a version to experimental and later found out that this
> > version fixes several bugs.
> > 
> > Can I rewrite existing changelog entries for already uploaded versions with
> > the next upload, i.e. by adding the relevant "closes" line to the previsions
> > version?
> You can if you want but it won't close the bugs, you'll still need to
> close them properly with manual action. SO it may be easier to just not edit
> them.

When I forget to add the "closes:" line to d/changelog, I will add it
retroactively (after having closed the bugs with the correct version manually)
because it allows others as well as future-me to look up in d/changelog to
which changes correspond to which bugs and bugs will have much more context for
a problem than a line in d/changelog.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: changing existing entries in debian/changelog

[Andrey Rakhmatullin]

On Fri, May 24, 2024 at 09:30:44AM +0200, Bastian Venthur wrote:
> I'm having troubles finding the relevant parts in the developers reference.
> I've uploaded a version to experimental and later found out that this
> version fixes several bugs.
> 
> Can I rewrite existing changelog entries for already uploaded versions with
> the next upload, i.e. by adding the relevant "closes" line to the previsions
> version?
You can if you want but it won't close the bugs, you'll still need to
close them properly with manual action. SO it may be easier to just not
edit them.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: t64 suffix

[Sven Joachim]

On 2024-05-23 18:22 +, Stefano Rivera wrote:

> Hi Mathieu (2024.05.23_18:14:20_+)
>> What is expected from Debian packager now ?
>>
>> 1. Remove the t64 suffix upon next version upload ?
>
> You can remove it at the next SONAME transition (ABI bump)
>
>> 2. Keep the package-name-doesnt-match-sonames lintian warning (for now) ?
>
> That should only occur on architectures that weren't impacted by the t64
> migration.

No, it occurs on all architectures because we changed the package names
but not the sonames.

> I imagine t64 could be explicitly ignored in lintian (and
> someone has probably filed a bug about that).

Yes, #1067040[1].  IIUC, the issue should be fixed in lintian git
already[2].

Cheers,
   Sven


1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067040
2. 
https://salsa.debian.org/lintian/lintian/-/commit/07167eebb697d74d84627b275d8aeff4ebf32f7e

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Thu, 2024-05-23 at 22:00 +0200, Sven Mueller wrote:
> 
> 
> Am 23.05.2024 20:16 schrieb Bernd Zeimetz :
> > On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote:
> > > Yes, but unironically: experimental is a side branch, unstable is
> > a
> > > MR, 
> > > and testing is the main branch.
> > > 
> > > It is entirely valid to be dissatisfied with the turnaround time
> > of
> > > the 
> > > existing CI, but what we're seeing here is the creation of a
> > parallel
> > > structure with as-of-yet unclear scope.
> > 
> > You are wasting a lot of hardware resources we don't have by
> > abusing
> > experimental as a CI. Don't do that.
> 
> I have a string feeling that it is easier for Debian to set up more
> hardware (I'm thinking of the "how should we spend the money we have"
> mails) than it is to find more maintainers.

Yes, but I think its a very valid request not to waste buildd time for
CIing your packages.
And maintaining hardware also needs human resources, its not just done
by buying new hardware.


-- 
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Sven Mueller]

Am 23.05.2024 20:16 schrieb Bernd Zeimetz :On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote:
> Yes, but unironically: experimental is a side branch, unstable is a

> MR, 

> and testing is the main branch.

> 

> It is entirely valid to be dissatisfied with the turnaround time of

> the 

> existing CI, but what we're seeing here is the creation of a parallel

> structure with as-of-yet unclear scope.



You are wasting a lot of hardware resources we don't have by abusing

experimental as a CI. Don't do that.I have a string feeling that it is easier for Debian to set up more hardware (I'm thinking of the "how should we spend the money we have" mails) than it is to find more maintainers. Using the resources we have if that saves time on the developer side seems reasonable to me. But IMHO, it would be better to use Salsa CI für that, not experimental.

Re: t64 suffix

[Stefano Rivera]

Hi Mathieu (2024.05.23_18:14:20_+)
> What is expected from Debian packager now ?
> 
> 1. Remove the t64 suffix upon next version upload ?

You can remove it at the next SONAME transition (ABI bump)

> 2. Keep the package-name-doesnt-match-sonames lintian warning (for now) ?

That should only occur on architectures that weren't impacted by the t64
migration. I imagine t64 could be explicitly ignored in lintian (and
someone has probably filed a bug about that).

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote:
> Hi,
> 
> On 5/23/24 04:32, Andrey Rakhmatullin wrote:
> 
> > > > It could be argued that testing migration is a CI process. >>
> > > > Its a CI process at a way too late stage.
> > > Also, uploading to test a merge request is not the right thing to
> > > do.
> 
> > If the archive is a VCS then uploading an untested package to
> > experimental
> > to run tools is pushing a commit to run CI.
> > *shrug*
> 
> Yes, but unironically: experimental is a side branch, unstable is a
> MR, 
> and testing is the main branch.
> 
> It is entirely valid to be dissatisfied with the turnaround time of
> the 
> existing CI, but what we're seeing here is the creation of a parallel
> structure with as-of-yet unclear scope.

You are wasting a lot of hardware resources we don't have by abusing
experimental as a CI. Don't do that.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Luca Boccassi]

On Thu, 23 May 2024 at 03:01, Simon Richter  wrote:
>
> Hi,
>
> On 5/23/24 04:32, Andrey Rakhmatullin wrote:
>
> >>> It could be argued that testing migration is a CI process. >> Its a CI 
> >>> process at a way too late stage.
> >> Also, uploading to test a merge request is not the right thing to do.
>
> > If the archive is a VCS then uploading an untested package to experimental
> > to run tools is pushing a commit to run CI.
> > *shrug*
>
> Yes, but unironically: experimental is a side branch, unstable is a MR,
> and testing is the main branch.
>
> It is entirely valid to be dissatisfied with the turnaround time of the
> existing CI, but what we're seeing here is the creation of a parallel
> structure with as-of-yet unclear scope.
>
> Can we define the scope as "quick-turnaround unofficial validation",
> because that's the niche that is currently underserved?

The main problem is not turnaround (it's terrible ofc), it's that a
broken upload to unstable affects _everybody_, while a CI run on Salsa
is private and doesn't get in the way of other developers.

Re: dgit view of packages' history

[Simon McVittie]

On Wed, 22 May 2024 at 21:55:15 +0200, Paul Gevers wrote:
> On 21-05-2024 1:08 p.m., Sean Whitton wrote:
> > > PS: I've always wondered if the dgit server shouldn't track history, even 
> > > if
> > > uploads don't happen via it. A dgit clone could (should?) already provide
> > > available history, even if no upload happened via it yet.
> > 
> > Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's
> > history.  So it sort of does this.  We could make it do more.
> 
> Huh. Than my workflow hides this. All I'm often seeing is just the tar
> content represented in a commit, the latest Debian packing in another and
> the merge of these two (if I recall and describe what I recall correctly). I
> always thought that dgit clone generated that on my computer if there was no
> git content on the dgit server. I'll try to remember this next time I run my
> no-changes-source-only upload script.

I believe the 3-commit orig + packaging + merge (vaguely similar to what
you would get from `gbp import-dsc` into an empty repository) is what you
get if the most recent upload was not made with dgit, and therefore does
not have the Dgit field in its `apt-cache showsrc` record.

This means that dgit might know what repository the maintainer uses to
store their idea of the packaging (it can get this from Vcs-Git), but it
does not know which specific commit in that repository is the equivalent
of what's in the archive, or which of the various possible workflows
the maintainer uses to get from that commit to an uploadable .dsc - and
therefore it doesn't have a particularly good way to glue the maintainer's
git history into the ancestry of the commit that it generates.

If you look at GNOME team packages, packages that were most recently
uploaded by me generally do have a Dgit field[1], and packages that were
most recently uploaded by another team member often do not. At the time
of writing, gtk4/unstable was uploaded with dgit, but gtk4/experimental
was not - that might make a useful comparison?

I use the dgit-maint-gbp workflow myself, so the dgit history contains a
transformation from the format used in our team VCS, which dgit calls the
"maintainer view" (in the GNOME team this is gbp-style patches-unapplied)
to dgit's canonicalized view (which is patches-applied, because that's
what the designers of dgit have chosen to canonicalize into).

A nice thing about dgit-maint-gbp is that my co-maintainers don't need
to agree with me, and can continue to use gbp + debsign + dput, or
quilt + debsign + dput, or construct patches in any other compatible way:
as long as we agree on the desired source tree, we can interoperate.

smcv

[1] except for -security uploads

Re: finally end single-person maintainership

[Simon Richter]

Hi,

On 5/23/24 04:32, Andrey Rakhmatullin wrote:


It could be argued that testing migration is a CI process. >> Its a CI process 
at a way too late stage.

Also, uploading to test a merge request is not the right thing to do.



If the archive is a VCS then uploading an untested package to experimental
to run tools is pushing a commit to run CI.
*shrug*


Yes, but unironically: experimental is a side branch, unstable is a MR, 
and testing is the main branch.


It is entirely valid to be dissatisfied with the turnaround time of the 
existing CI, but what we're seeing here is the creation of a parallel 
structure with as-of-yet unclear scope.


Can we define the scope as "quick-turnaround unofficial validation", 
because that's the niche that is currently underserved?


   Simon

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Paul Gevers]

Hi

On 21-05-2024 1:08 p.m., Sean Whitton wrote:

PS: I've always wondered if the dgit server shouldn't track history, even if
uploads don't happen via it. A dgit clone could (should?) already provide
available history, even if no upload happened via it yet.


Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's
history.  So it sort of does this.  We could make it do more.


Huh. Than my workflow hides this. All I'm often seeing is just the tar 
content represented in a commit, the latest Debian packing in another 
and the merge of these two (if I recall and describe what I recall 
correctly). I always thought that dgit clone generated that on my 
computer if there was no git content on the dgit server. I'll try to 
remember this next time I run my no-changes-source-only upload script.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Wed, May 22, 2024 at 09:11:16PM +0200, Bernd Zeimetz wrote:
> > > You can run autopkgtests locally, you do not need Salsa for that.
> > 
> > Also, Debian runs autopkgtests on all packages that provide them, and
> > makes passing them on all supported architectures a requirement for 
> > testing migration.
> 
> Uploading to check autopkgtests is an absolute waste of ressources. I
> really hope nobody uploads a package without running the tests
> somewhere else.
> 
> > 
> > It could be argued that testing migration is a CI process.
> > 
> 
> Its a CI process at a way too late stage.
> Also, uploading to test a merge request is not the right thing to do.
If the archive is a VCS then uploading an untested package to experimental
to run tools is pushing a commit to run CI.
*shrug*

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Wed, 2024-05-22 at 21:26 +0900, Simon Richter wrote:
> Hi,
> 
> On 5/22/24 20:34, Bill Allombert wrote:
> 
> > You can run autopkgtests locally, you do not need Salsa for that.
> 
> Also, Debian runs autopkgtests on all packages that provide them, and
> makes passing them on all supported architectures a requirement for 
> testing migration.

Uploading to check autopkgtests is an absolute waste of ressources. I
really hope nobody uploads a package without running the tests
somewhere else.

> 
> It could be argued that testing migration is a CI process.
> 

Its a CI process at a way too late stage.
Also, uploading to test a merge request is not the right thing to do.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Documenting packaging workflows (was: finally end single-person maintainership)

[Philip Hands]

Salvo Tomaselli  writes:

> I'm also annoyed at the default ci configuration for salsa, because importing 
> a 
> project makes a CI start to run, then fail. Then I have to one by one point 
> the CI file to something else, but the project will forever be "CI failing" 
> and 
> will be reported forever as such in my status page.

If you go to the individual pipeline that you never wanted to run (e.g.
click on the red 'X' in the overview, or the pipelines view), then
you'll see a 'Delete' button in the top-right corner.

If you delete all the pipelines in a repo, it reverts to thinking CI is
not setup, and you'll no longer be told that the repo is 'CI failing'.

BTW I just confirmed that by setting up a new repo for the purpose, and
was surprised to find that I also needed to configure CI in order to get
it to fail, so I think you may be right that it was once doing the
annoying thing you describe, but it didn't do it to me just now.

HTH

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Simon Richter]

Hi,

On 5/22/24 20:34, Bill Allombert wrote:


You can run autopkgtests locally, you do not need Salsa for that.


Also, Debian runs autopkgtests on all packages that provide them, and 
makes passing them on all supported architectures a requirement for 
testing migration.


It could be argued that testing migration is a CI process.

   Simon

Re: finally end single-person maintainership

[Luca Boccassi]

On Wed, 22 May 2024 at 12:35, Bill Allombert  wrote:
>
> On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote:
> > On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote:
> > >
> > > When a change leads to a RC bug a month or three after having be
> > > part of a package, fixing the problem falls on the maintainer and not
> > > on the change author. Even correct changes can trigger latent bugs
> > > in software.
> >
> > Yet another reason why using Salsa and its CI *and having autopkg-
> > tests* is so important - contributors can test their changes before
> > even asking to merge them.
>
> You can run autopkgtests locally, you do not need Salsa for that.

It can, but it's really a massive pain. git push and go make a cup of
tea is so much nicer.
Nowadays I run locally only when debugging complex issues, otherwise
it's all delegated to Salsa.

> > And yes, its up to the 'expert' maintainer
> > of the package to ensure there are proper tests in place. Because even
> > that expert is a human only and we all make mistakes.
>
> Indiscriminate use of Salsa CI is not free, there is a cost in hardware, in 
> electricity
> and in carbon emission, that we cannot completely ignore.
>
> In any case, it is not realistic to expect tests to detect all kind of bugs, 
> alas.

The cost of running those same builds and tests locally is pushed onto
the developer though, and their electricity bill. By using Salsa, the
cost is pushed to the project and our sponsors - which seems the right
thing to me.

Re: Bug#1071236: general: keyboard, mouse, and trackpad behave inconsistently; seemingly phantom input device events occur unpredictably

[Ben Hutchings]

On Wed, 2024-05-22 at 00:41 +0200, Salvo Tomaselli wrote:
> Hello,
> 
> you can run "reportbug packagename" to report against a specific package.
> 
> You can find out how your kernel package is called with 
> 
> dpkg -l "linux-image-*"

That step isn't necessary because "reportbug kernel" automagically does
the right thing.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes
instead of old ones.



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

Re: finally end single-person maintainership

[Bill Allombert]

On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote:
> On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote:
> > 
> > When a change leads to a RC bug a month or three after having be
> > part of a package, fixing the problem falls on the maintainer and not
> > on the change author. Even correct changes can trigger latent bugs
> > in software.
> 
> Yet another reason why using Salsa and its CI *and having autopkg-
> tests* is so important - contributors can test their changes before
> even asking to merge them. 

You can run autopkgtests locally, you do not need Salsa for that.

> And yes, its up to the 'expert' maintainer
> of the package to ensure there are proper tests in place. Because even
> that expert is a human only and we all make mistakes.

Indiscriminate use of Salsa CI is not free, there is a cost in hardware, in 
electricity
and in carbon emission, that we cannot completely ignore.

In any case, it is not realistic to expect tests to detect all kind of bugs, 
alas.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

broad goals (Re: finally end single-person maintainership)

[Holger Levsen]

On Wed, May 22, 2024 at 12:25:49AM +0200, Salvo Tomaselli wrote:
> > I would rather see a small but very stable base distribution, with the
> > option to add features on top.
> Doesn't this conflict with debian being universal?
 
for some it surely does, while for others it's needed to make Debian the
universal OS.

fun! ;)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Only change is constant.


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Holger Levsen]

On Wed, May 22, 2024 at 07:18:04AM +0200, Andreas Tille wrote:
> IMHO this is a hen-egg-problem: If NMUer could expect packages beeing on
> Salsa we could require the NMUer to add at least a MR.  

those are two things:

- mandating salsa (for git)
- mandating to have MRs enabled on salsa for that project.
 

-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Very hard to relate to those who think the first three years of the pandemic
were bad because they couldn’t go to bars for a while, as opposed to because
25 million people died, 400 million were disabled, and many more continue to
be unable to access public space.


signature.asc
Description: PGP signature

Re: Documenting packaging workflows

[Russ Allbery]

Johannes Schauer Marin Rodrigues  writes:

> I would be *very* interested in more in-depth write-ups of the workflows
> other DDs prefer to use, how they use them and what they think makes
> them better than the alternatives.

> Personally, I start packaging something without git, once I'm satisfied
> I use "gbp import-dsc" to create a packaging git with pristine-tar (and
> that will *not* have DEP14 branches and it will use "master" instead of
> "main") and then I push that to salsa and do more fixes until the
> pipeline succeeds and lintian is happy. My patches are managed using
> quilt in d/patches and upstream git is not part of my packaging git. I
> upload using "dgit --quilt=gbp push-source".

> Would another workflow make me more happy? Probably! But how would I get
> to know them or get convinced that they are better? Maybe I'm missing
> out on existing write-ups or video recordings which explain how others
> do their packaging and why it is superior?

One of the lesser-known things found in the dgit package is a set of man
pages describing several packaging workflows.  These certainly aren't
exhaustive of the packaging workflows that people use (for one thing, they
are designed to explain how to use dgit in each workflow, and thus of
course assume that you want to do that), but they're both succinct and
fairly thorough and I found reading them very helpful.  dgit(1) has a list
at the start.

dgit-maint-debrebase(7) is the workflow that I now use, pretty much
exactly as described.  The primary thing that I like about it is that I
never have to deal with the externalized patches or with quilt (I used
quilt for years, and I have developed a real dislike for it and its odd
quirks -- I would rather only deal with Git's odd quirks), and I can use a
git-rebase-like command in much the same way that I use it routinely for
feature branches when doing upstream development.  Then some Git magic
happens behind the scenes to make this safe, and while I don't understand
the details, it has always worked fine, so I don't really care how it
works.  :)

I like having a Git history from as early in the process as possible and I
want the upstream Git history to refer to while I work on packaging (and
want to be able to cherry-pick upstream commits), so I generally start
with a tagged release from the upstream Git repository, create a branch
based on it, and start writing and committing debian/* files.

-- 
Russ Allbery (r...@debian.org)  

Re: Documenting packaging workflows (was: finally end single-person maintainership)

[PICCA Frederic-Emmanuel]

My standard workflow

I use gbp and dgit

gbp import-orig --pristine-tar --uscan
gbp dch
lintian-brush
dgit --gbp sbuild  (build and autopkgtest)
...work until it is ok on my computer
gbp dch
... hand edit the changelog
gbp push
git push (to push the UNRELEASE master branch)
... wait for salsa result if everythings is ok
... if not work and push commits to salsa
... then relase with
dch -r
dgit --gbp build-source
dgit --gbp push-source
gbp push


I like the way dgit help for the upload.

Cheers

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Wed, May 22, 2024 at 12:32:32AM +0200, Salvo Tomaselli wrote:
> And what's the advantage? When an nmu happens the person doing it normally 
> doesn't bother to push to salsa anyway. 
Yes, because it's unfortunately too expensive to:
- make sure the repo exists and is uptodate
- somehow find out what workflow does the repo imply
- if it's an unfamiliar one then somehow learn it
- check if there are no commits on top of the previous upload and if there
  are any then how to merge them with the NMU changes
- check that your commit builds correctly
at least when doing more than one NMU per week or whatever.
The nmudiff(1) interface is standardized, one command does everything, you
are still required to use it, and you need to remember that MRs don't give
notifications so you have an additional reason to use it, and importing a
nmudiff should be easy for the maintainer.

> At most I get a patch in the 
> bugreport, or I have to diff the packages and import the diff.
Sending the nmudiff to the bugreport is mandatory per the devref NMU
procedure (though of course that procedure itself is not a policy and not
everyone follows it).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andreas Tille]

Hi Stefano,

Am Tue, May 21, 2024 at 02:36:47PM + schrieb Stefano Rivera:
> Hi Philip (2024.05.21_10:05:59_+)
> > Attempts at top-down imposition of new methods on Debian strike me as
> > being unlikely to induce joy in anyone involved.
> 
> Yeah, that doesn't fly in community projects like Debian at all.

ACK.
 
> However, there is a gap between getting a DEP approved and getting the
> rest of the project to fully embrace it. That's something that takes
> some leadership in the project. DPLs are in a great position to help
> drive these changes forward.

I confirm I see myself in the "help to get something happening"
position.  I'm fully aware that we can't push anything top-down.  I see
a big step forward in permitting some progress in the first place since
I assume we have quite some volunteers who would implement this progress
which is just not permitted by some rules we have.
 
(My current challenge is to even find out what is broken first as
I'm currently learning in the lintian case.)

Kind regards
   Andreas. 

-- 
https://fam-tille.de

Re: finally end single-person maintainership

[Andreas Tille]

Am Wed, May 22, 2024 at 12:32:32AM +0200 schrieb Salvo Tomaselli:
> 
> And what's the advantage? When an nmu happens the person doing it normally 
> doesn't bother to push to salsa anyway. At most I get a patch in the 
> bugreport, or I have to diff the packages and import the diff.

IMHO this is a hen-egg-problem: If NMUer could expect packages beeing on
Salsa we could require the NMUer to add at least a MR.  I personally
would prefer permissions to push even to the default branch and tag
accordingly.  The current situation of not having some default VCS at
some default place makes injecting NMUs into the VCS impossible and it
does not help to blame NMUers about this.

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: finally end single-person maintainership

[Johannes Schauer Marin Rodrigues]

Quoting Bernd Zeimetz (2024-05-21 00:54:07)
> On Wed, 2024-04-10 at 23:16 +0200, Johannes Schauer Marin Rodrigues
> wrote:
> > Quoting Andreas Tille (2024-04-10 22:44:25)
> > > > I do understand the argument that lots of different workflows
> > > > adds
> > > > friction. But I'm just still using what used to be _the_ standard
> > > > one
> > > > (insofar as we ever had such a thing). Putting everything in
> > > > salsa/git
> > > > doesn't standardise workflows in itself. I think Ian/Sean
> > > > identified 12
> > > > different git-based methods in their dgit review.
> > > 
> > > I agree that different workflows are not helpful.  We have DEP14[1]
> > > ... but we have no efficient processes to
> > >   a) accept DEPs
> > >   b) dedicate to accepted DEPs
> > 
> > or teach gbp about DEP14. See this git-buildpackage bug from *six*
> > years ago:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444
> 
> DEP14 is a candidate, I can't see that there was any consensus to accept it.
> Just because there is a DEP there is no need to implement it without having
> any consensus on it.

the current gbp defaults were also implemented without any consensus on them,
so in that regard, embracing DEP14 would not make the situation worse.

What is improved by DEP14 is that in contrast to the current gbp defaults, it
is backed up by a write-up of advice, best-practices and recommendations. We
should have more of these write-ups for the things we do. This would also make
it easier for new contributors to get into Debian.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: finally end single-person maintainership

[Luca Boccassi]

On Wed, 22 May 2024 at 00:40, Russ Allbery  wrote:
>
> Salvo Tomaselli  writes:
>
> > If the debian/ directory is on salsa, but the rest of the project is
> > somewhere else, then this no longer works, I have to tag in 2 different
> > places, I have 2 different repositories to push to and so on.
>
> For what it's worth, what I do for the packages for which I'm also
> upstream is that I just add Salsa as another remote and, after I upload
> a new version of the Debian package, I push to Salsa as well (yes,
> including all the upstream branches; why not, the Debian branches are
> based on that anyway, so it's not much more space).  One of these days
> I'll get CI set up properly, and then it will be worthwhile to push to
> Salsa *before* I upload the package and let it do some additional
> checking.
>
> It's still an additional step, and I still sometimes forget to do it, but
> after some one-time setup, it's a fairly trivial amount of work.
>
> It's more work to accept a merge request on Salsa and update the
> repositories appropriately, since there are two repositories in play, but
> in that case I'm getting a contribution out of it that I might not have
> gotten otherwise, so to me that seems worth it.
>
> I used to try to keep the debian directory in a separate repository or try
> to keep the Debian Git branches in a separate repository, and all of that
> was just annoying and tedious and didn't feel like it accomplished much.
> Just pushing the same branches everywhere is easy and seems to accomplish
> the same thing.

Yeah I am doing the same, and gradually switching all my packages that
used to have a separate upstream/downstream history to a single merged
tree. This can be done post-facto with some one-time git rocket
surgery, doesn't have to be the case from day one. It's a huge
improvement, and with gpp patch-queue I can just cherry-pick upstream
commits directly, with no hassle whatsoever. It works really nicely,
and gbp supports it just fine as a workflow, even while still checking
in upstream release tarballs in pristine-tar.

Re: finally end single-person maintainership

[Russ Allbery]

Salvo Tomaselli  writes:

> If the debian/ directory is on salsa, but the rest of the project is
> somewhere else, then this no longer works, I have to tag in 2 different
> places, I have 2 different repositories to push to and so on.

For what it's worth, what I do for the packages for which I'm also
upstream is that I just add Salsa as another remote and, after I upload
a new version of the Debian package, I push to Salsa as well (yes,
including all the upstream branches; why not, the Debian branches are
based on that anyway, so it's not much more space).  One of these days
I'll get CI set up properly, and then it will be worthwhile to push to
Salsa *before* I upload the package and let it do some additional
checking.

It's still an additional step, and I still sometimes forget to do it, but
after some one-time setup, it's a fairly trivial amount of work.

It's more work to accept a merge request on Salsa and update the
repositories appropriately, since there are two repositories in play, but
in that case I'm getting a contribution out of it that I might not have
gotten otherwise, so to me that seems worth it.

I used to try to keep the debian directory in a separate repository or try
to keep the Debian Git branches in a separate repository, and all of that
was just annoying and tedious and didn't feel like it accomplished much.
Just pushing the same branches everywhere is easy and seems to accomplish
the same thing.

-- 
Russ Allbery (r...@debian.org)  

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Bernd Zeimetz]

On Tue, 2024-05-21 at 09:11 -0600, Sam Hartman wrote:
> > > > > > "Otto" == Otto Kekäläinen  writes:
>     Otto> Would you be kind and try to understand the opposing
> viewpoint
>     Otto> by trying it for one day?
> 
>     Otto> You could go to
>     Otto>
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
>     Otto> and conduct a code review?
> 
> I have not done a code review  of that particular patch on salsa.
> I have done code reviews on salsa, many other gitlabs, and github.
> I find doing a code review in a web page far more frustrating than in
> email.

There are external paid integrations for gitlab which provide the
feature to send emails with full diffs for projects, so there should be
a way to add this feature to the Debian gitlab. I would guess by using
the API.
You can comment on merge requests by email already and you should even
be able to create a new one by mail (that feature exists in gitlab, no
idea if its enabled on salsa and I've never tried it anywhere else).

So I think if this is a feature more people are missing, find them and
spend some time together on creating an external service for salsa that
provides it would be well spent time.



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Tue, 2024-05-21 at 12:05 +0200, Philip Hands wrote:
> 
> For anyone with an opinion, I'd suggest that you should try to make
> sure
> that DEP-14 reflects your opinion, and then work on getting people to
> adopt the use of DEP-14 and/or get DEP-14 accepted.
> 

To be honest: in my opinion the whole DEP process is flawed. I doubt
that even the first DEP that created DEPs was had enough consent to be
accepted in general. It did just not bother enough people to be against
it and it made some others happy, so it was accepted to exist.



With the future more and more being container and cloud driven, I would
indeed rather see a Debian that is completely maintained in one
location, with as much CI and testing as possible. Keeping everything
reproducible and maybe - in the future - having a rolling release,
which requires these things.
Even if that means that we loose packages and developers. Which would
be sad, but I think healthy for a long term future of Debian.

I would rather see a small but very stable base distribution, with the
option to add features on top. Which do not necessarily need to be
maintained at the same place as Debian, but could use Debian's
infrastructure as its done now. Each "feature" could have its own
release cycle as it fits. Sury's PHP packaging would be a prime example
for that. We run thousands of PHP driven websites and rarely anyone
wants to use what Debian ships as stable (or even from a still
supported oldstable).


The radical way would be to GR this into place with a *long* grace
period. Risky, but better than having a big slow distribution nobody
needs anymore at some point.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Tue, 2024-05-21 at 15:50 +0200, Salvo Tomaselli wrote:
> > Do you think that mandating Salsa is a sensible step in this
> > direction?
> 
> No. It would increase my workload for all the stuff where I am also
> upstream.

Could you explain that? I do similar things (just that not everything
of it is published for $reasons), and I can't see how its increasing my
workload as git and CIs are doing these things for me.

So I'm always curious on why workloads increase just by maintining a
package on salsa.


Thanks,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Otto Kekäläinen]

Hi!

On Sun, 19 May 2024 at 20:48, Don Armstrong  wrote:
>
> On Sun, 19 May 2024, Bill Allombert wrote:
> > Also debbugs is a special case:
> > The debbugs Debian package (as opposed to the debbugs software) have never 
> > been
> > really maintained. I am actually one of the very few users of this package
> > and I tried several times to get the maintainers to do a new upload but they
> > were clearly not interested.
>
> It's more that I'm prioritizing spending my (very) limited Debian time
> on keeping bugs.debian.org and debbugs itself working (and [very slowly]
> developing a new version of Debbugs with a more modern design in the
> hopes that others will contribute.)

Everyone else has very limited time to contribute to Debian as well.
Therefore we all need to think about what is the most efficient
workflow.

Perhaps you could consider how you can be a force multiplier and scale
your work? You could for example add some of the recent contributors as
developers or maintainers at
https://salsa.debian.org/groups/debbugs-team/-/group_members so they
can review/merge/push code, and you could review all submissions at
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests and
grow those contributors into co-maintainers instead of just ignoring
them?

Perhaps you can also consider optimizing your git workflows? For
example in the case of
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 you
could have simply pressed "Merge" and everything would be good. Now
you decided to not use any of the support Salsa/Salsa-CI provides, you
did extra work to cherry-pick some commits (but not all), added your
extra commit to break the build and now there is new follow-up work to
be done for lapses that could have been easily avoided if Salsa-CI was
enabled.. (I did submit MR!20 though, you can just merge it)

I started this thread "Salsa - best thing in Debian in recent years?"
by asking people who resist Salsa to at least try using it for a while
before criticizing it so much.

What happened in this episode is a case in point. You sit in a "local
optima" of your current workflow and are not willing to invest a bit
extra effort to get to a place where Salsa+Salsa-CI can benefit and
decrease your extra work burden. Now both you and me ended up having
to do extra work that could easily have been avoided..

Personally I like Salsa a lot, and collaboration with maintainers who
embrace Salsa is a breeze, and I feel that my limited Debian time is
relatively productive. That is all thanks to Salsa. I wish those who
are not yet using it would give it a sincere try.

Re: Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Guilherme Puida Moreira]

On Tue, May 21, 2024 at 06:13:21PM +0200, Andrej Shadura wrote:
> In fact, having checked the source code, it’s one way only, and after
> all it’s also someone else’s quick hack. Maybe someone should write
> a robust tool to support all formats and directions and package *that*
> for Debian? :)

I think dasel might be what you want :^)

Select, put and delete data from JSON, TOML, YAML, XML and CSV files
with a single tool. Supports conversion between formats and can be used
as a Go package.

https://github.com/tomwright/dasel
https://tracker.debian.org/pkg/dasel

--puida

Re: finally end single-person maintainership

[Russ Allbery]

Stefano Rivera  writes:

> On the other hand, dgit is only useful if you have a certain view of the
> world, that hasn't aligned with how I've done Debian packaging. I mean,
> an entirely git-centric view where you let go of trying to maintain your
> patch stack.

dgit has no problems with you maintaining your patch stack, at least as I
understand that statement.  I personally use the dgit-maint-debrebase(7)
workflow, which is a fancy way of maintaining your patch stack using an
equivalent of git rebase, since I love git rebase and use it all the time.
But I used the dgit-maint-gbp(7) workflow, which is basically just the
normal git-buildpackage workflow, for years and still use it for some of
my packages and it works fine.

Maybe you mean something different by this than I think you meant.

-- 
Russ Allbery (r...@debian.org)  

Re: Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Andrej Shadura]

Hi again,

On Tue, 21 May 2024, at 17:59, Andrej Shadura wrote:
> On Tue, 21 May 2024, at 17:17, Facundo Gaich wrote:
>> Well I ended packaging this, it's waiting in debcargo-conf at
>> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653
> 
> If the Rust impl of toml2json works better than one written in Python 
> (reserialize), I’m more than happy that you take over the binary package. I’m 
> almost certain it does, given that the Python package is basically someone’s 
> script I packaged and patched over and over again.

In fact, having checked the source code, it’s one way only, and after all it’s 
also someone else’s quick hack. Maybe someone should write a robust tool to 
support all formats and directions and package *that* for Debian? :)

-- 
Cheers,
  Andrej

Re: About i386 support

[Samuel Thibault]

Hello,

Tomas Pospisek, le mar. 21 mai 2024 17:22:47 +0200, a ecrit:
> > > Quoting Victor Gamper (2024-05-17 21:58:58)
> > > For i386 there is a severe lack of person-power. Do you want to start
> > > contributing your free-time for several years to come to d-i and
> > > other areas
> > > which are needed to keep i386 more alive for longer?
> 
> > On 18.05.24 03:15, r...@neoquasar.org wrote:
> >> That depends. What would be required of such a person? I also have
> >> several i386-class machines that run Debian (though only one that can
> >> run Debian 12).
> 
> On 18.05.24 15:16, Maite Gamper wrote:
> 
> > Whilst I can't for sure say how much free time I'll have, I'd like
> > to try and contribute. How would you get started with that?
> 
> There's somewhere a page that is showing how much of the archive is built by
> architecture. A search engine should help you finding that page. Pick the
> package that is furthest down the stack of package dependencies that is not
> building on i386.

It's probably not that easy to find.

The page I know about that would suit best would be the Build-Attempted
and Failed sections of:

https://buildd.debian.org/status/architecture.php?a=i386=sid

> Find out why. Fix the bug. Check if there's a bug report
> about the problem. Send a patch. If the maintainer doesn't have time then
> become a Debian Maintainer [or] Developer yourself, consult with the
> package's maintainers and upload fixed packages.

Yup

Samuel

Re: Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Andrej Shadura]

Hi,

On Tue, 21 May 2024, at 17:17, Facundo Gaich wrote:
> On Thu, Feb 22, 2024 at 1:39 PM Jonas Smedegaard  wrote:
>> Quoting Facundo Gaich (2024-02-22 17:12:22)
>> > I can work on packaging this if you're still interested, I'd need a 
>> > sponsor.
>> > 
>> > I've already done some preliminary work on this, in particular I renamed
>> > the bin to "rust-toml2json" but maybe you've got a better idea?
>> 
>> If the command-line tool does somewhat the same as the existing one, I
>> suggest to rename it with the deviating part as the end instead, so that
>> users TAB-completing would easier notice the alternative:
>> toml2json-rust. 
> 
> Well I ended packaging this, it's waiting in debcargo-conf at
> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653

If the Rust impl of toml2json works better than one written in Python 
(reserialize), I’m more than happy that you take over the binary package. I’m 
almost certain it does, given that the Python package is basically someone’s 
script I packaged and patched over and over again.

-- 
Cheers,
  Andrej

Re: About i386 support

[Tomas Pospisek]

Hi Maite, hi Rhys,


don't top-post. That breaks the flow of the arguments being argued about.


*From:* Johannes Schauer Marin Rodrigues 
*Sent:* Friday, May 17, 2024 15:48
*To:* Victor Gamper; debian-devel@lists.debian.org
*Subject:* Re: About i386 support

Quoting Victor Gamper (2024-05-17 21:58:58)
> Is there a reason to do this? If so, what would be required to keep 
the i386

> version, seeing as it still is important and used?

anything can be done if there are enough contributors who care.

For i386 there is a severe lack of person-power. Do you want to start
contributing your free-time for several years to come to d-i and other 
areas

which are needed to keep i386 more alive for longer?


> On 18.05.24 03:15, r...@neoquasar.org wrote:
>> That depends. What would be required of such a person? I also have
>> several i386-class machines that run Debian (though only one that can
>> run Debian 12).

On 18.05.24 15:16, Maite Gamper wrote:

> Whilst I can't for sure say how much free time I'll have, I'd like
> to try and contribute. How would you get started with that?

There's somewhere a page that is showing how much of the archive is 
built by architecture. A search engine should help you finding that 
page. Pick the package that is furthest down the stack of package 
dependencies that is not building on i386. Find out why. Fix the bug. 
Check if there's a bug report about the problem. Send a patch. If the 
maintainer doesn't have time then become a Debian Maintainer oder 
Developer yourself consult with the package's maintainers and upload 
fixed packages.

*t

Re: Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Facundo Gaich]

Control: retitle -1 ITP: rust-toml2json -- A very small CLI for converting
TOML to JSON
Control: owner -1 !

Well I ended packaging this, it's waiting in debcargo-conf at
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653

Best,
Facundo

On Thu, Feb 22, 2024 at 1:39 PM Jonas Smedegaard  wrote:

> Quoting Facundo Gaich (2024-02-22 17:12:22)
> > I can work on packaging this if you're still interested, I'd need a
> sponsor.
> >
> > I've already done some preliminary work on this, in particular I renamed
> > the bin to "rust-toml2json" but maybe you've got a better idea?
>
> If the command-line tool does somewhat the same as the existing one, I
> suggest to rename it with the deviating part as the end instead, so that
> users TAB-completing would easier notice the alternative:
> toml2json-rust.
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>  * Sponsorship: https://ko-fi.com/drjones
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Sam Hartman]

> "Otto" == Otto Kekäläinen  writes:
Otto> Would you be kind and try to understand the opposing viewpoint
Otto> by trying it for one day?

Otto> You could go to
Otto> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
Otto> and conduct a code review?

I have not done a code review  of that particular patch on salsa.
I have done code reviews on salsa, many other gitlabs, and github.
I find doing a code review in a web page far more frustrating than in
email.
I appreciate other people have different experience.
Some of my experience but not all is  accessibility related.

I do find that   trying to put everyone into one user interface--whether
it is github or gitlab or whatever--means some people are going to be
left out.
Interfaces like email mean that people can develop their own tooling.
And for those who do and find tooling they really like that's superior
to a common UI like gitlab for *those people*.
But it's going to be inferior for people who do not spend significant
time on tooling; for those people a common web ui is going to be
superior.

And you can say that I can use my own tooling with gitlab.
That's sort of true.  But then you or people like you will get
frustrated  that I don't interact with your per-commit-line comments
entered in the website, or go to the website to resolve comments or
whatever.
And you'll say that if I just tried the website I'd like it.
And that won't be true, because I have, I do use it in my day job, and I
don't really like it that much.

Even so, I think it is enough better that Debian should move in that
direction.

But Otto, I would encourage you to have more compassion for people who
work with the world differently than you.
In this thread, and in the krb5 merge request we are discussing, you
really do seem to be jumping to an assumption that everyone approaches
code the same way.
And you don't appear to be taking the time to understand or value how
the people you are interacting with may deal with the world differently.

Rather than simply asking people  to try out your way, I'd encourage you
to ask me and others how they deal with code and what they like about
their work flow.
I'm not going to ask you to try it out, because it probably won't work
for you.
You've found something you  think is great.
But I am going to ask you to ask and listen.

I do think we should fall in on the salsa way.  I think it will
generally be better overall.
I do think some of us will suffer as a result.

But there appears to be an assumption here that if we just all tried
this new thing it would be great.
I would appreciate compassion for our differences and for how that's
just not true.
There will be trade offs.

--Sam

Re: finally end single-person maintainership

[Stefano Rivera]

Hi Philip (2024.05.21_10:05:59_+)
> Attempts at top-down imposition of new methods on Debian strike me as
> being unlikely to induce joy in anyone involved.

Yeah, that doesn't fly in community projects like Debian at all.

However, there is a gap between getting a DEP approved and getting the
rest of the project to fully embrace it. That's something that takes
some leadership in the project. DPLs are in a great position to help
drive these changes forward.

> I suspect that there's a decent chunk of developers who generally just
> follow the status quo of every package they work on, without fuss.

Yeah, probably most.

> I rather like dgit for reducing the extent I have to think about this
> sort of thing, but I note that at least one person in this thread seems
> vexed by it, so we cannot even agree on the merits of that, apparently.

On the other hand, dgit is only useful if you have a certain view of the
world, that hasn't aligned with how I've done Debian packaging. I mean,
an entirely git-centric view where you let go of trying to maintain your
patch stack. So, I've only very briefly played with it. I imagine many
in the project have similarly little experience using it.

The tricky thing with tools like this is that you need to invest a lot
of time using the tool to really get a feel for what it's good / bad at.
You probably need to use it to maintain a complex package, for a while.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Any volunteers for lintian co-maintenance?

[Niels Thykier]

PICCA Frederic-Emmanuel:

I tried it on one of my package silx

warning: File: ./debian/tests/control:22:14:22:19: It is possible that the value is a 
typo of "i386". [Correctable via --auto-fix]
 22: Architecture: !i386

It seems wrong to me, the test control file allow !i386

Cheers

Frederic



Thanks for reporting this issue.

I have pushed a fixed for this to main.

I hope you will report any other issues you might discover. Though 
please consider using the BTS or salsa for future findings. :)


Best regards,
Niels

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Luca Boccassi]

On Tue, 21 May 2024 at 14:13, Andrey Rakhmatullin  wrote:
>
> On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> > Hi,
> >
> > On 5/21/24 15:54, Andrey Rakhmatullin wrote:
> >
> > > > The Debian archive itself is a VCS, so git-maintained packaging is also 
> > > > a
> > > > duplication, and keeping the official VCS and git synchronized is 
> > > > causing
> > > > additional work for developers, which is why people are opposed to 
> > > > having it
> > > > mandated.
> >
> > > The Debian archive itself is a *bad* and *poor* VCS. It should be obvious
> > > in which areas it's poor, and it's bad e.g. because force pushes are
> > > enabled, the history is periodically truncated (though there is no easy
> > > way to get it anyway) etc.
> >
> > All of these things are *also* explicit features. We need a way to unpublish
> > things, and mirrors only want to keep a shallow subset.
> We don't have a way to unpublish things, and force pushes I meant are
> uploading things without including all previous changes, like all those
> NMUs silently not included in the next maintainer uploads.
> But, sure, some of the problems we have are explicitly features.
>
> > Representing the Debian archive in git would probably look like a massive
> > amount of submodules, because that's the only way to represent state across
> > multiple projects without extending it
> Sorry? I don't understand what you would use submodules for. Unless you
> meant literally mapping archive-as-VCS to a single literal VCS repo?

Yeah, I don't understand that either. It seems there is some
misunderstanding, the suggestion to use Salsa doesn't mean that the
current ftp servers are retired. It just means that Salsa is used for
sources, like it is already used in ~90% of the packages today as per
trends.debian.net. Now, whether someone wants to make tarballs and ftp
uploads happen transparently behind the curtain in a salsa-ci job or
something like that is really orthogonal to the idea that sources need
to be stored in git.

Re: Any volunteers for lintian co-maintenance?

[Niels Thykier]

Andreas Tille:

Hi Niels,

at first sorry for my late answer.

At Thu, May 09, 2024 Niels Thykier wrote:
[...]  >> For me, lintian fails in all roles it has. It is not a good tool for 

newbies

to get help, since it can only test build artifacts. As an example, your
feedback look is a full package build followed by unpacking the package just
so lintian can tell you have a typo on line 4. That is a massive waste of
resources - notably developer time and mental bandwidth.


I understand your point about having a tool that checks the debian/ dir for
issues like spelling errors, binary files in the upstream source, and other
concerns right within the packaging tree before the build starts. However, I
don't understand why you mention newbies in this context.



My core argument is the feedback cycle is excruciatingly complicated and 
slow compared to what it needs to be for validation of "debian/*" files. 
In my view, the problem is amplified for newcomers in multiple areas.



[...]
As a consequence,
people now get auto-rejects when uploading because lintian on the FTP master
server does not produce the same output as current lintian in stable or
newer.


I think its a bit unfair to blame lintian about the fact that its old
versions do not do a proper job when it comes to checking newer packages.



Is it now? When I maintained lintian, I was of the understanding that 
the dak usage was an explicit use-case we, as lintian maintainers, were 
expected to support. In my time, I would have considered this situation 
as an RC bug against lintian if I had this change and the FTP masters 
were unable or unwilling to install the -backports version of lintian.


On the other side of the "unfairness" coin, I feel it is unfair to have 
people spend volunteer time being stuck in a painful cycle of "It works 
on my machine, but dak rejects it because lintian is not updated on the 
FTP masters machine" for which they are expected to ignore lintian 
warnings locally to get out of (you need overrides in the old format, 
which the new lintian then complains about - damned if you, damned if 
you don't). Those are volunteers that wasted their Debian time being 
cauhgt between lintian and dak and, in my book, that was much more 
unfair than having lintian (or dak) and its maintainers own up to it.


I feel we, as a distribution, should ensure such problems do not happen. 
As stated, in my time as a lintian maintainer, I felt the responsibility 
was with lintian and that is why I blame lintian.


Maybe times have changed here and we, as a distribution, no longer hold 
lintian accountable here. Not sure who is then, but maybe that is part 
of why this problem has existed for so long.


(For the record, I think the ship sailed on this one. I am not expecting 
Alex to go retroactively fix this problem on the lintian side. I expect 
us not to repeat this mistake again)



[...]
Especially for the editor support
related parts, where people get instant feedback both on issues and the fix,
automatic reformatting on save and completion suggestions. None of which
lintian or wrap-and-sort are capable of.


If you ask me personally I'm absolutely happy about a policy checker that
simply reports issues.  I'm fine with firing up an editor in some other
terminal and be done.  Maybe I'm missing your point but for me that's a
non-issue.  Or is your comparison with wrap-and-sort rather targeting at
some tool that automatically fixes the issues it has found and I can check
the changes afterwards with `git diff`?  Or something like the janitor tools
that even commit changes?
  


I feel my point is not coming across at all and that is frustrating me a 
bit.


Imagine you need to change `debian/control` for some reason regardless 
of the situation that triggered this. You open up your editor and do the 
change. In the process, you make a mistake.


The current workflow is:

 1) Edit file (introducing mistake)
 2) No feedback in the editor, so:
a) You save the file
b) Build an artifact that lintian can check
c) Run lintian to get the feedback
 3) You correct the mistake.
 4) Rinse and repeat all the sub-steps of 2) to validate there are no
mistakes.

This is the workflow you have today with lintian. And it applies equally 
to all kinds of mistakes from policy violations, to textual or semantic 
typos.


Now, I would like you to step away from the status quo. What this 
workflow *should* have been in my view is:


 1) Edit file (introducing mistake)
 2) Editor shows a "Here is a mistake"-marker.
 3) You correct the mistake (either manually or via a quick fix)
 4) Editor removes a "Here is a mistake"-marker.
 5) Save the file

Notice here that I do not need to leave my editor to get feedback. I get 
it automatically, so I cannot forget it nor am I inclined to skip the 
check in a hurry. This is the crux of my problem with status-quo 
feedback loop. I have *actively* ask for feedback. I have to wait for it 
too which becomes paper cut.

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Holger Levsen]

On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> The Debian archive itself is a VCS, so git-maintained packaging is also a
> duplication, and keeping the official VCS and git synchronized is causing
> additional work for developers, which is why people are opposed to having it
> mandated.

I don't follow this conclusion because the premise "the Debian archive itself is
a VCS" is as right or wrong as the statements "earth is clock" or an "ocean is a
washing machine".

Or, to put it differently, "vi $file ; cp $file $file.bak ; vi $file" is also 
a VCS, but an even poorer one than the Debian archive.

Just because something has some VCS like properties it doesn't make it a VCS
as in the sense as people understand it in 2024.

IMO (very few) people object using a(n official) VCS is because it would change
their workflows and/or because they believe their needs are more important than
our needs. And saying "the Debian archive is a VCS and that causes conflicts
with another VCS" is a red herring at best, because as dak+git or dak+vim+copy
shows (or gosh, using different git repos) that using several VCS is possible 
and
done by millions daily.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It's not climate change nor climate crisis, it's climate disaster.


signature.asc
Description: PGP signature

Re: Any volunteers for lintian co-maintenance?

[PICCA Frederic-Emmanuel]

I tried it on one of my package silx

warning: File: ./debian/tests/control:22:14:22:19: It is possible that the 
value is a typo of "i386". [Correctable via --auto-fix]
22: Architecture: !i386

It seems wrong to me, the test control file allow !i386

Cheers

Frederic

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Andrey Rakhmatullin]

On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> Hi,
> 
> On 5/21/24 15:54, Andrey Rakhmatullin wrote:
> 
> > > The Debian archive itself is a VCS, so git-maintained packaging is also a
> > > duplication, and keeping the official VCS and git synchronized is causing
> > > additional work for developers, which is why people are opposed to having 
> > > it
> > > mandated.
> 
> > The Debian archive itself is a *bad* and *poor* VCS. It should be obvious
> > in which areas it's poor, and it's bad e.g. because force pushes are
> > enabled, the history is periodically truncated (though there is no easy
> > way to get it anyway) etc.
> 
> All of these things are *also* explicit features. We need a way to unpublish
> things, and mirrors only want to keep a shallow subset.
We don't have a way to unpublish things, and force pushes I meant are
uploading things without including all previous changes, like all those
NMUs silently not included in the next maintainer uploads.
But, sure, some of the problems we have are explicitly features.

> Representing the Debian archive in git would probably look like a massive
> amount of submodules, because that's the only way to represent state across
> multiple projects without extending it 
Sorry? I don't understand what you would use submodules for. Unless you
meant literally mapping archive-as-VCS to a single literal VCS repo?


-- 
WBR, wRAR


signature.asc
Description: PGP signature