Hi!

On Fri, 2024-02-23 at 17:59:14 -0800, Steve Langasek wrote:

One generic case that this doesn't handle is Essential: yes packages. For many of these, the ${shlibs:Depends} gets promoted in debian/control to Pre-Depends, not to Depends.

Ah! Good point.

I think the particular case of the Essential: yes and Pre-Depends
should really be handled by dpkg-shlibdeps. So I've now implemented a
new --package option for it, that will grab the package information
from debian/control, and if it is «Essential: yes» it will change the
default from Depends to Pre-Depends (in addition to also setting the
default Package-Type, so no need for explicit -t anymore), and the
package name will be added to -x. If -p is not passed, then it will
behave as now.

This, combined with the upcoming implicit substvar support should then
by default give the expected behavior (which can always be overridden).

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

--P4uNKJ2NDgyFvJ+d
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Latest update:

We are still waiting for gcc to be ready for upload to unstable.

In the meantime, we've done some further due diligence to sanity check that
the packages uploaded to experimental are correct. This addresses the
problem Bill Allombert had raised of some packages building but being
missing their libraries.

After completing this review and fixing up the experimental NMUs as
necessary, we are left with a list of 170 packages that we supposed should
go through an ABI transition, but do not have correct builds in
experimental. This includes a few package builds still in-progress, but
most of the packages fall into one of three categories:

- there is already an incompatible maintainer upload in experimental (52)
- there is a pre-existing FTBFS in unstable documented in the BTS (37)
- the package contains a shared library but doesn't follow the usual
convention of naming the package after the soname; and has no
reverse-dependencies in the archive (20)
- it has been determined the package doesn't actually need a transition and
the bug has been closed (4)

Packages in the first category will be included in the mass NMU to unstable once the toolchain is unblocked, although they could not be uploaded to experimental and therefore do not have coverage from dumat to check for usrmerge issues.

Packages in the other three categories will not be included in the mass NMU; where appropriate, bugs have been opened on the packages with patches, but these will be for the maintainer to deal with.

I have attached the full list of current packages missing correct builds in experimental here for review. I am also attaching dd-list output for the
same. Please check whether you have packages on this list that need
attention.

I will be incorporating the contents of this list back into our scripting,
so we can make sure we get a correct list of reverse-dependencies for binNMUing.


On Fri, Feb 23, 2024 at 03:23:18PM -0800, Steve Langasek wrote:

On Fri, Feb 23, 2024 at 04:36:43PM +0100, Guillem Jover wrote:

Hi!

On Mon, 2024-02-19 at 19:48:38 -0800, Steve Langasek wrote:

I have coordinated with the gcc maintainer so that we can have the default
flags in gcc-13 changed this week.

We are therefore targeting Friday for the mass NMUs to unstable though there
is a possibility this won't start until as late as Monday depending on capacity.

Yesterday while trying to get a time for today's upload, I discussed
with Matthias, and it looks like today is not great for timing. There
are some things that might need to be hammered out in gcc, and Matthias
was not going to be available today until next week or so. I also just realized the transition exceptions coverage does not match between
what some porters expect (f.ex. hurd-i386 which I'll discuss with them later today), what dpkg and debhelper have implemented and what gcc
does, I'll discuss the latter with Matthias separately.

So as mentioned by Steve, this might need to be postponed a tiny bit
more.

Yes, it looks like we're not quite ready to go. There are also some bad
NMUs in experimental that need to be cleaned up, and also a few extra annotations we're going to have to add to some packages after belatedly realizing that debhelper magic isn't already DTRT as far as Provides: for
all packages. So we'll use the time well until gcc is ready to go.

In the meantime, another happy update on the statistics, showing that we've whittled away a few more libraries:

- 1093+50=1143 source packages to be transitioned
- 5261+180=5441 packages to be binNMUed

Thanks,
--
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/ slangasek@ubuntu.com vorlon@debian.org

--P4uNKJ2NDgyFvJ+d
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename="experimental-consistency-checks.txt"

abseil # already in experimental
ace # already in experimental
actor-framework # already in experimental
alsa-oss # closed invalid
anfo # known ftbfs
arrayfire # known ftbfs
bctoolbox # already in experimental
belle-sip # already in experimental
binutils # can't rename binutils; punted
broker # known ftbfs
ceph # already in experimental
clamav # already in experimental
consolekit2 # known ftbfs
cyclonedds # blocked on ftp override map refresh
daq # already in experimental
dcmtk # already in experimental
dune-grid # no

On Sun, 25 Feb 2024 at 23:56:58 -0800, Steve Langasek wrote:

I have attached the full list of current packages missing correct builds in experimental here for review. I am also attaching dd-list output for the same. Please check whether you have packages on this list that need attention.

glib2.0 # already in experimental

The upstream version in experimental is unsuitable for unstable, but it's
"the same shape" as the version in unstable in all the places that matter,
and we ack'd the earlier NMU to experimental already, so I'm confident
that similar changes will apply cleanly to the version in unstable. The
GNOME team can probably handle this one when the time comes, if that
would help (I know your Canonical colleague Jeremy B�cha was asking to
let the GNOME team do coordinated team-uploads rather than NMUs, I'm not
sure what the resolution of that was).

Also, if it's valid to apply this reasoning:

- libhigh0 depends on liblow0
- liblow0 will transition to liblow0t64
- libhigh0 does not really need to change its name because we know that the
version built against liblow0 is the old ABI, the version built against
liblow0t64 is the new ABI, and they cannot be co-installable

then we can cross all of the GLib-based packages off the list
immediately, and handle them by transitioning glib2.0 from libglib2.0-0
to libglib2.0-0t64. That covers at least these:

evolution # no sane ABI info, but maintainer handling via e-d-s gimp # already in experimental
gtk+2.0 # false positive
gtk+3.0 # false positive
libvirt-glib # ftbfs
mutter # already in experimental
telepathy-farstream # known ftbfs

... and similar logic could be applied to in the Qt ecosystem, with Qt
as the low-level package. Does that help to reduce the numbers?

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

None of this is relevant to the substvars discussion, but the collectd
side is worth looking at on its own.

On Sat, Feb 24, 2024 at 01:36:33PM +0100, Gioele Barabucci wrote:

On 24/02/24 11:26, Bernd Zeimetz wrote:

Absolutely. collectd for example - otherwise you would install *all*
plugin dependencies with collectd, which would be a big waste of space.

The other option would be to make one packe per plugin as redhat does,
but do we really want 20 packages with a single file?

Yes, please. So that installing package collectd-foo ensures that all the required dependencies are installed, instead of having to hunt them down (a task better left to the package maintainers rather than the end users).

There is a balance to be struck here. Adding one package per plugin is a
lot of plugins and you often install multiple plugins together. It is
not obvious that the benefit of splitting is worth the associated cost.

I think there is a middle ground here. Having one package per plugin
definitely does have advantage. However, consider the option of turning
those packages virtual. So you'd have tons of collect-plugin-foo
packages provided from collectd initially. Then, multiple plugins tend
to use the same dependencies and some plugins tend to use no additional dependencies. The latter can just be left in the main package together
with their provides. The former can be grouped together to say collectd-plugins-hardware or something that you wouldn't want on a
virtual machine. Together with the plugins, you'd also move the provides
and recommends (maybe upgraded to depends then). In particular, you can
later restructure the plugins provided that downstreams only depend on
your virtual collect-plugin-* packages rather than the underlying
physical packages.

An example where this has successfully been implemented with Depends and
a small installation footprint is lighttpd.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Simon,

On Mon, Feb 26, 2024 at 11:40:56AM +0000, Simon McVittie wrote:

glib2.0 # already in experimental

The upstream version in experimental is unsuitable for unstable, but it's "the same shape" as the version in unstable in all the places that matter, and we ack'd the earlier NMU to experimental already, so I'm confident
that similar changes will apply cleanly to the version in unstable. The
GNOME team can probably handle this one when the time comes, if that
would help (I know your Canonical colleague Jeremy B�cha was asking to
let the GNOME team do coordinated team-uploads rather than NMUs, I'm not
sure what the resolution of that was).

Yes, this is on the list to flag that it is a package for which we do not
have a guarantee of dumat coverage in experimental prior to uploading to unstable, and thus we might hit usrmerge problems for the first time in unstable.

In this particular case the t64 NMU sat in experimental for 2 weeks (31Jan-13Feb) before being replaced by a maintainer upload. So I trust that Helmut would have screamed at me if glib2.0 had gone pear-shaped.

But that is a finer level of investigation than we have the capacity for at this stage for each of these 50+ packages.

Also, if it's valid to apply this reasoning:

- libhigh0 depends on liblow0
- liblow0 will transition to liblow0t64
- libhigh0 does not really need to change its name because we know that the
version built against liblow0 is the old ABI, the version built against
liblow0t64 is the new ABI, and they cannot be co-installable

then we can cross all of the GLib-based packages off the list
immediately, and handle them by transitioning glib2.0 from libglib2.0-0
to libglib2.0-0t64. That covers at least these:

evolution # no sane ABI info, but maintainer handling via e-d-s gimp # already in experimental
gtk+2.0 # false positive
gtk+3.0 # false positive
libvirt-glib # ftbfs
mutter # already in experimental
telepathy-farstream # known ftbfs

... and similar logic could be applied to in the Qt ecosystem, with Qt
as the low-level package. Does that help to reduce the numbers?

Special-casing these stacks because they don't "need" to be renamed is, on
our side, more work and more prone to mistakes than if we just include them
in the mass NMU. *Not* renaming is not meaningfully better as a user experience than renaming, so I don't think it's valuable from the
perspective of the overall transition to carve out these exceptions.

If maintainers are confident that the renames are unnecessary and want to remove the 'pending' tag from the bug reports to exclude them, or want to revert the renames after upload, that's their choice.

The only caveat I would raise is that on the Ubuntu side, we're working to a very tight deadline now: Feature Freeze for Ubuntu 24.04 LTS is this
Thursday, and while I think we're going to vary our Debian Import Freeze in order to get the time_t transition through, we aren't going to vary it by
much. So maintainer name reverts in unstable that happen after this are not guaranteed to be picked up, and whatever package names we have on the Ubuntu side are going to be locked in for a 10-year LTS cycle. So I think any maintainer who's concerned about dependency compatibility with third-party
debs should bear this in mind.

--
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/ slangasek@ubuntu.com vorlon@debian.org

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmXdjPMACgkQVo0w8yGy Ez3ZZBAAoGZ2K2JhbW4iBbXYA/bb13z8XD8HAmQ9lT4RtQv375hyz74kGNNmpa28 lKtW/zwjckXbNzmygSHj8RnnKNV2ue6kJnjZcxZNSk4ENzer5wbVjuWmYXX22PiR yfGgu/6Fqnj0BrEgQZ3xxNlY4O5HBOWoizEqgcTKqVWN209noLeNFhaRH6Dexilu M1HuadZTmpMM34sQN1OpSHNxaAeuUu35AgRoU2Bv3uw4M+XqSGPi3AyTfNgYxaDU iP/O6qZMA1YnF3YOheEL8HaTjZ/Qhb2p0w5AEgfxn2P81a2Drce5rPGz5gaYbCpm HGjDJewcfLcdJZAle9fnPkknrrKxhQv2h7ttwW3R4hh/Dr3WUosk8yevV0Eu4XM5 vFeL7yj3sCa4CPwi+uM7R1kJycoXKt7sLc8DZsljMvNOgqPDgqrckEOPhHxPC1Cl zHgCtTBjYNMCtwAXdVgJxBXVhzjUdS6nAVtmWsKmRQmHDZXMpAzTOMCkLaHNs8vb 713ueIZppcwCllUTRgs3LYqPRqlVZ90G8G1vj1AxW8NIZmy1hffmHCoAO8AC4/Q+ W9LFvaYA3wqg+wRIz1KX

Hi David,

sorry for the late reply, and many thanks for you detailed answer.

What I mean with "falls back" is that APT downloads a package linked in
the arch-specific index, if present, and the on from "all" index only if
the package is not listed in the arch-specific one (or if there is no arch-specific one).

So you configured apt on the user systems to support riscv64,
but didn't change anything in the repository?

Not sure what you mean with "configured apt on the user systems to
support riscv64"? I added the key and repo via sources.list.d to a
riscv64 system, as that is all what it needs? Probably you mean /var/lib/dpkg/arch, which contains riscv64 OOTB, as this system was
generated via debootstrap to generate a base Debian with this
architecture explicitly.

On the repository, binary-all/Packages was added to enable riscv64
system support, and since all Webmin packages declare themselves
(correctly) as "Architecture: all", we though that it would be actually
cleaner and correct to provide an "all" index only, and remove all arch-specific indexes from the repo. But then we faced this warning,
which is the reason for the confusion, about how it is intended to be done.

Of course we can add binary-riscv64/Packages and the same for all other
new architectures added to Debian in the future, to mute the warning.
But having a large number of duplicate indexes which all contain/link
the the very same "Architecture: all" packages seems somehow
unnecessarily complicated, and even wrong for explicitly arch-agnostic packages.

Yes, i.e. no and yes there is. The previously mentioned wiki says this
about the Architectures field: "The field identifies which architectures
are supported by this repository." So your repository doesn't support
this architecture and doesn't even ship the data, the user has configured apt to get. Something is fishy, better warn about it.

I see. We were assuming that "all" implies that a repo supports all architectures, in case at least for the subset of packages listed in the
"all" index. The wiki however does not say anything explicitly about
that, but only that the "all" index is an indicator that "Architecture:
all" packages are not listed in the arch-specific indexes.

I understood now that APT repos are intended to explicitly define every architecture they support, regardless whether they provide
"Architecture: all" packages only or others as well. I tend to agree
that being explicit is usually better, and in this case means that
someone usually tested the package(s) on the particular architecture
before the repo maintainer does the effort to add it to the repo explicitly.

Thanks for taking your time, so we know now that the intended way is to
add binary-riscv64/Packages to declare riscv64 support explicitly.

Best regards,

Micha

Am 03.12.2023 um 15:27 schrieb David Kalnischkies:

Hi,

(I think this isn't a good mailing list for apt vs. third-party repo
config… users@ probably could have answered that already, deity@ if
you wanted full APT background which I will provide here now…
reordered quotes slightly to tell a better story)

On Sat, Dec 02, 2023 at 06:40:33PM +0100, MichaIng wrote:

we recognised that APT falls back to/uses "binary-all/Packages"

APT doesn't fall back to it, its default behaviour to use them if
available and supported (← that word becomes important later on).

Debian repos actually opt out of it for Packages files: https://wiki.debian.org/DebianRepository/Format#No-Support-for-Architecture-all

while checking how to best enable riscv64 support for Webmin's own APT
repository

And what did you do to the repository to enable riscv64 support?

but still complains with a warning if no "binary-riscv64/Packages"
is present and declared in the Release file of the APT repository:
-------
W: Skipping acquire of configured file 'contrib/binary-riscv64/Packages' as >> repository 'https://download.webmin.com/download/repository sarge InRelease' >> does not seem to provide it (sources.list entry misspelt?)
-------

So you configured apt on the user systems to support riscv64,
but didn't change anything in the repository?

Is this expected behaviour, i.e. is every repository expected to provide
dedicated package lists for every architecture, or is there a way to provide >> an "all" architectures list only, without causing clients to throw warnings?

Yes, i.e. no and yes there is. The previously mentioned wiki says this
about the Architectures field: "The field identifies which architectures
are supported by this repository." So your repository doesn't support
this architecture and doesn't even ship the data, the user has configured
apt to get. Something is fishy, better warn about it.

So, add riscv64 to Architecture in Release and be done, except that
you should read the entire stanza as it will explain how a client will
behave with that information. It also explains the specialness of 'all'. https://wiki.debian.org/DebianRepository/Format#Architectures

Why? So glad you asked! Nobody tested the repository with this arch.
If you e.g. have a Multi-Arch system bad things can happen if a library package is not available for all configured architectures in the same version. Or that arch:all package ships little-endian data, but your
system is big-endian (or vice versa), or its actually using linux-only binaries in maintainer scripts, but you are running hurd-i386 …

In case of Webmin, all packages are perl scripts, have "Architecture: all" >> declared and naturally support all architectures. So it seems unnecessary to

Well, arch:all packages do not "naturally" support all architectures
in edge cases and we love edge cases. It is also why an arch:all package
is not "naturally" also "Multi-Arch: foreign".

provide clones of a single package list for every architecture explicitly, >> and having to do so whenever a new one appears.

So yeah, if you want you can ship only an -all/Packages file and add the others if you ever ship some as long as you tell apt (and your users)
that you support an Architecture, they will manage.

Best regards

David Kalnischkies, who happens to have implemented most of this

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi

It seems the discussion on this topic has settled, so I am now doing a
summary of the discussion as I understand it.

* Generally, the original proposal seems to have been received
favorably at a conceptual level.

* Several people requested the scope to be expanded to extra fields.
So far, no one seems to have questioned any of the extra fields
proposed. Accordingly, I will expand the scope to all mentioned
extra fields (such as Built-Using/Static-Built-Using and negative
relationship).

* My alternative proposal of making relational substvars mandatory
did not have anyone supporting. Additionally, Simon McVittie provided
a strong argument for why the alternative would scale poorly. Given
the argument from Simon and no one openly supporting that proposal,
I am considering it a dead-end with no support.

* All the concerns raised related to promotion and demotion of
substvars were related to the shlib subvars (such as
${shlib:Depends} vs Pre-Depends/Recommends). I have yet to see anyone
concerned about a non-shlib related variable, which is great since
dpkg-shlibdeps as the only substvars provider has infrastructure for
promotion/demotion. No case presented seems to have been problematic
nor controversial. I have included an extended section below on this
topic for the details, should you be interested in those.

* Guillem proposed some concrete ideas for moving parts of the
implementation into the dpkg layer, which seems fine with me.
I consider these implementation detail and will handle that
bilaterally with Guillem.

In other words, it seems like there is consensus that this proposal at a conceptual level is acceptable. I will look into the implementation
details with Guillem (as mentioned, in a smaller forum).

I fully anticipate that there will be a transition for this feature
(such as a debhelper compat bump) to ensure we have a controlled
migration. Notably substvar demotion does not work out of the box (see
below) as one of my arguments to ensure it happens in a controlled manner.




= Detailed explanations =

From here on, I will expand on the substvars cases and how they work.
If you are not interested in those, you can stop reading as the
remainder of the email is dedicated only to this topic.


# Promotion and demotion of substvars

For those, who are curious or concerned about promotion or demotion of a substvar, here is an extended coverage of cases presented in the
discussion and how they work.

First, a bit of terminology as people might not have read the full
thread. I use the word "promotion" when the substvar is used in a
**stronger** field that the one it is named for. Example:

# The substvar in this example is promoted to Pre-Depends
Pre-Depends: ${shlib:Depends}

Demotion is the opposite. Here the substvars implies a strong field than
the one it is used in:

# The substvar in this example is demoted to Recommends
Recommends: ${shlib:Depends}


For the case, where the tool can split the substvar into multiple
substvars, I will use the phrase selective promotion or selective
demotion of the content. The only known tool that supports this is `dpkg-shlibdeps` and the only known usage involves the ${shlib:*} namespace.


There are multiple cases to cover and how they would interact with this proposal:

* Selective promotion/demotion of content (Unaffected)

* Full substvar promotion (Unaffected)

* Full substvar demotion (Breaks)

* Manual fiddling with substvars (Unaffected)

Each will be expanded in their own subsection below. The `(Unaffected)`
and `(Breaks)`-marker represents what happens in a rebuild of an
unchanged source package with with this proposal suddenly active. As
mentioned, I expect we will do this as an a opt-in style transition to
avoid unexpectedly triggering any cases that might break.


## Selective promotion/demotion of content


Selective promotion and demotion of the content works out of the box
with this proposal.

* The logic for splitting a substvars will generally be in debian/rules
via manual calls to dpkg-shlibdeps or dh_shlibdeps. This part remains
unaltered.

* The main difference is that you no longer have to manually any of the
substvars in debian/control.

This method generally only works with dpkg-shlibdeps, since that is the
only tool with infrastructure to do the splitting. At the same time, it
is also the only substvar provider mentioned in the discussion so far,
where anyone had an example of needing promotion or demotion.


Note in this case, the split off substvars will be named are the field
they go in. Strictly speaking, none of the substvars have been promoted
nor demoted in this particular case. This is also why it is promotion / demotion of **content** rather than of the substvar itself.


## Full substvar promotion

This is the case of doing `Pre-Depends: ${shlib:Depends}`. This example
is also the only discussed use-case so far and is relevant for
`Essential: yes` packages.

This would work correctly out of the box. A naive implementation of the proposal would lead to the following pseudo example:

Pre-Depends: ${shlib:Depends}
# The Depends field would be implicit and is only shown
# to assist the reader.
Depends: ${shlib:Depends}


The `dpkg-gencontrol` tool will de-duplicate relationship fields by
pruning relations from weaker fields that are implied by stronger fields
per second paragraph of man:dpkg-gencontrol(1). So there is generally no
loss of functionality nor extra bloat in the final output.

Final remark: Guillem suggested that it would make sense for
`dpkg-shlibdeps` to special case `Essential: yes` packages such that it
puts dependencies into `${shlib:Pre-Depends}` by default for essential packages. This would reduce the boilerplate needed for essential
packages. Details about how to transition to this will be handled in a
smaller forum.


## Full substvar demotion

This is the only case that does not work out of the box with the new
world. This is the case of doing `Recommends: ${shlib:Depends}`.

The reason why this does not work, is exactly the reason why the
promotion case works. Namely, the effective behavior becomes:


Recommends: ${shlib:Depends}
# The Depends field would be implicit and is only shown
# to assist the reader.
Depends: ${shlib:Depends}

And as mentioned for the promotion case, the weaker field will be pruned
by `dpkg-gencontrol`. Even if you could magically skip the pruning logic
in `dpkg-gencontrol`, the Depends field would still be there and
overrule in practice.


When looking at how to handle this case, we have two solutions.
Specifically for ${shlib:Depends}, selective demotion is preferable.
Particularly because a full field demotion only works if **all** ELF binaries are optional features of the packages. The rationale here is
that any ELF binary would need a libc dependency. Any non-optional ELF
binaries implies that the package must have a `Depends:
${shlib:Depends}` (or stronger).
A full field demotion with a non-optional ELF binary would
technically be an RC bug for the shlib case. Nonetheless, I am still
going with the "no surprises" road here. It is not for me to judge
whether a concrete package has all its ELF binaries as optional features
even when I assume such cases to be exceedingly rare.

I have not seen any other substvar being mentioned for a "full substvar" demotion and I am not going to invest a lot of effort on them for this
reason. Even if they appear, the following hack presented in the next
section would work for them. The main question is whether we need this
hack enough to provide a proper solution.


## Manual fiddling with substvars

As mentioned by Colin Watson, we do have one "get out of jail" card that
can be played in our current packaging stack. Namely, manually fiddling
with debian/foo.substvars to rename or tweak the substvar as needed.

This solution already existed and is unaffected by this proposal.
Basically, roll your own substvar "fixer" and throw it at the right spot
in `debian/rules`.

If you find yourself in a corner, it will solve your problem.


However, if we find ourselves repeatedly in weird corners, we should
provide better tooling to solve this problem. I do not think we want
every debhelper tool to grow its own "selective promotion/demotion"
feature as they are not trivial to do.
While I am open to providing better support at a central level, I
will expect multiple concrete real world use-cases before providing any supporting logic. This is because debhelper is not built around having
logic to support every special-case in the world. Instead, it covers
common cases[1] and provides its hook target cop-out for truly
special-cases.
If it turns out full-field demotion is a common case, then debhelper
will support while if it is an unique snowflake case, the manual
substvar fiddling will have to do for that handful of packages.


Best regards,
Niels

[1]: The original debhelper maintainer used "~10 cases in the archive"
as a rule of thumb for whether it made sense to consider if a build
system should be added into debhelper itself.
I have largely adopted this rule of thumb for adding features for
where I am unsure if Debian at large needs them. I fully anticipate to
apply that rule of thumb to whether debhelper should be involved in
reducing the number of "fiddling with substvars" cases.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Can we also consider ${*:Built-Using} as typically seen in ${sphinxdoc:Built-Using}?
This is another field that people keep forget adding. While missing
this field is not severely harmful, having it automatically handled
would be beneficial.

Automatic expansion of ${*:(Static-)Built-Using} would improve the
situation for variables managed by packaging helpers.

But for the record, dh-builtusing [1] already provides an
auto-definition of ${dh-builtusing:[DPSa-z]+} variables expanded by
the maintainer in the (Static-)Built-Using fields.

The use cases should rarely overlap, but the mechanisms seem
compatible. For example, dh_builtusing parses debian/*.substvars so
that dh_sphinxdoc may one day set sphinxdoc:Built-Using=${dh-builtusing:libjs-sphinxdoc}.

[1] https://manpages.debian.org/testing/dh-builtusing/dh_builtusing.1.en.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:

For example, when I implemented libuuid, if you want to create a huge
number of UUID's very quickly, because you're a large enterprise
resource planning application, the the uuidd daemon will allow
multiple processes to request "chunks" of UUID space, and create
unique UUID's without having to having to go through some kind of
locking protocol using a single shared state file.

So libuuid works just fine without uuidd, but if you are populating a
large ERP system, then you very much will want uuidd to be installed.
So in that case, you can make the dependency relationship be either
suggests or recommends, instead of a hard dependency.

Except that in Debian, this is a "Recommends:", and "Recommends:"
are normally installed by default... except by the Debian installer!
This is inconsistent.

So, in the present case, uuid-runtime wasn't installed by default,
though libuuid1 was installed and had a "Recommends: uuid-runtime".

But with the 64-bit time_t transition, libuuid1 got replaced by
libuuid1t64 a few days ago, which pulled uuid-runtime.

--
Vincent Lef�vre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 05/03/2024 9:22 pm, Vincent Lefevre wrote:

On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:

For example, when I implemented libuuid, if you want to create a huge
number of UUID's very quickly, because you're a large enterprise
resource planning application, the the uuidd daemon will allow
multiple processes to request "chunks" of UUID space, and create
unique UUID's without having to having to go through some kind of
locking protocol using a single shared state file.

So libuuid works just fine without uuidd, but if you are populating a
large ERP system, then you very much will want uuidd to be installed.
So in that case, you can make the dependency relationship be either
suggests or recommends, instead of a hard dependency.

Except that in Debian, this is a "Recommends:", and "Recommends:"
are normally installed by default... except by the Debian installer!
This is inconsistent.

This is not correct. The majority of the packages installed by the
installer are in fact installed via tasksel, and it does install
"Recommends:". The command is there: https://salsa.debian.org/installer-team/tasksel/-/blob/546b5b99e81bfb69b88de105b6fc78fceacb5ee1/tasksel.pl#L930.

However it's true that some packages are installed before that, at the debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?

So, in the present case, uuid-runtime wasn't installed by default,
though libuuid1 was installed and had a "Recommends: uuid-runtime".

But with the 64-bit time_t transition, libuuid1 got replaced by
libuuid1t64 a few days ago, which pulled uuid-runtime.

Looking at some install logs, I can confirm that libuuid1 is installed
by debootstrap (as a dependency of e2fsporogs), and that explains why uuid-runtime is not installed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Arnaud Rebillout (2024-03-06 02:26:00)

On 05/03/2024 9:22 pm, Vincent Lefevre wrote:

On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:

For example, when I implemented libuuid, if you want to create a huge
number of UUID's very quickly, because you're a large enterprise
resource planning application, the the uuidd daemon will allow
multiple processes to request "chunks" of UUID space, and create
unique UUID's without having to having to go through some kind of
locking protocol using a single shared state file.

So libuuid works just fine without uuidd, but if you are populating a
large ERP system, then you very much will want uuidd to be installed.
So in that case, you can make the dependency relationship be either
suggests or recommends, instead of a hard dependency.

Except that in Debian, this is a "Recommends:", and "Recommends:"
are normally installed by default... except by the Debian installer!
This is inconsistent.

This is not correct. The majority of the packages installed by the
installer are in fact installed via tasksel, and it does install "Recommends:". The command is there: https://salsa.debian.org/installer-team/tasksel/-/blob/546b5b99e81bfb69b88de105b6fc78fceacb5ee1/tasksel.pl#L930.

However it's true that some packages are installed before that, at the debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?

Correct. This is tracked as bug#742977


- 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 --==============t47246202523385550=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIyBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXn/y8ACgkQLHwxRsGg ASEpZA/4siYlx8eVJzo04g/LotAh4634qsoCGkjItjR0yx7wlyJ48bn4e7ZpG4wf Bdlcgd85FtRt0gWq2JpZAbMs79LKmDLycYU21FNeDcr9WjDYwvAy+yDIHJFQ6hXs mAMYuV0SiRCVyOxJ4/cIXPBjvz9VfPdEq/Swxv3YjpyurYYLqTrRQQoRFje79+EM EQOyf+eHvWlQJzj12nHuEmCY+JW4sH5o+gWcsCHSJ0p6lEUuDSqjCeCsJB+KSxyN c8cVwSCyKx0MLu08CJWWuM0iSO1238wzvJYxElp3/jXpq0Drf3/xKuGzFrIMGWDu vrP7uuBK5hM1I775iyb6C2J1+8BxTPc977pZ+YMZqmSMcA035YxkdOjocZuQSQJQ tAXdRQJBZvTLLdgh2yZAupfn5LIq9XLFekGdU1lacwcawlz5J1gpS4uqS5gU+biL O4YEnMCoh9Vmh9N8SlVKsxXknFJEBlx23djeUemM

On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote:

Quoting Arnaud Rebillout (2024-03-06 02:26:00)

However it's true that some packages are installed before that, at the debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?

Correct. This is tracked as bug#742977

Bug#742977 is about whether to mark installed packages as
auto-installed or not. It is not about Recommends.

--
Vincent Lef�vre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Vincent Lefevre (2024-03-06 12:17:55)

On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote:

Quoting Arnaud Rebillout (2024-03-06 02:26:00)

However it's true that some packages are installed before that, at the debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?

Correct. This is tracked as bug#742977

Bug#742977 is about whether to mark installed packages as
auto-installed or not. It is not about Recommends.

Sorry. You are right, of course.

It is another related issue.


- 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 --==============&19969586071816989=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXoWbkACgkQLHwxRsGg ASFxkBAAiRFlETE+YCuwNHAAt3zPMxI6IyonZZUsDhlLVOSY55Ib6dVDmrfDKAFd 2zffO4Pp0adMHDfvxD1y3bRMGcEuikfc5xxKzNRogEkh+mlIptFdU4BmhBUYLNCA Z9FPe3d+KcYSlXy61w4kUSnrVZJEZY7u5ah23cEt0YWCAnrffRX3jPPVdOVUXFsD MTADrgCBMzzSOLw1livriJg76Cn7b4Gq5OXfMQUhLMffMFdcE1fS1YUnTH/g23eR 8yEQqBOl8stUj1imu/4vVxoG/bLIljmqWpWPVfBcnNxjMQxxhy77HIvuTwpkdAWq JcbcnmDhDnAhRgwHeVrERDTFHhEakExKm0ucmVYhvRIJB3Vo2xGm9r9ABWb+LdUh Ryb4GQsONY22kDT/MTKlpr09kqk5Bnqe6GDFQV00jVfr/rHPxSjFtHOMxIkW9I2z RPhUOswZWD75EGTaFwFPIqvOxbxGOXijm7zQgWst

------W4Q955HVHS0MY6HS5N9SYIETRXHLJK
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

The time_t transition seems to be stalled due to issues on armel/armhf architecture. My understanding is, as long as this transition isn't over, uploaders of affected packages are discouraged to upload anything unrelated to this transition (to avoid any
delays to get it through).

Do we have an updated rough idea for how long this transition will take? Is it in the range of day, weeks or months? I have no clue...

Regards,
Micha

Am 27. Februar 2024 08:19:21 MEZ schrieb Steve Langasek <vorlon@debian.org>: >Hi Simon,

On Mon, Feb 26, 2024 at 11:40:56AM +0000, Simon McVittie wrote:

glib2.0 # already in experimental

The upstream version in experimental is unsuitable for unstable, but it's
"the same shape" as the version in unstable in all the places that matter, >> and we ack'd the earlier NMU to experimental already, so I'm confident
that similar changes will apply cleanly to the version in unstable. The
GNOME team can probably handle this one when the time comes, if that
would help (I know your Canonical colleague Jeremy Bícha was asking to
let the GNOME team do coordinated team-uploads rather than NMUs, I'm not
sure what the resolution of that was).

Yes, this is on the list to flag that it is a package for which we do not >have a guarantee of dumat coverage in experimental prior to uploading to >unstable, and thus we might hit usrmerge problems for the first time in >unstable.

In this particular case the t64 NMU sat in experimental for 2 weeks >(31Jan-13Feb) before being replaced by a maintainer upload. So I trust that >Helmut would have screamed at me if glib2.0 had gone pear-shaped.

But that is a finer level of investigation than we have the capacity for at >this stage for each of these 50+ packages.

Also, if it's valid to apply this reasoning:

- libhigh0 depends on liblow0
- liblow0 will transition to liblow0t64
- libhigh0 does not really need to change its name because we know that the >> version built against liblow0 is the old ABI, the version built against
liblow0t64 is the new ABI, and they cannot be co-installable

then we can cross all of the GLib-based packages off the list
immediately, and handle them by transitioning glib2.0 from libglib2.0-0
to libglib2.0-0t64. That covers at least these:

evolution # no sane ABI info, but maintainer handling via e-d-s >> > gimp # already in experimental
gtk+2.0 # false positive
gtk+3.0 # false positive
libvirt-glib # ftbfs
mutter # already in experimental
telepathy-farstream # known ftbfs

... and similar logic could be applied to in the Qt ecosystem, with Qt
as the low-level package. Does that help to reduce the numbers?

Special-casing these stacks because they don't "need" to be renamed is, on >our side, more work and more prone to mistakes than if we just include them >in the mass NMU. *Not* renaming is not meaningfully better as a user >experience than renaming, so I don't think it's valuable from the
perspective of the overall transition to carve out these exceptions.

If maintainers are confident that the renames are unnecessary and want to >remove the 'pending' tag from the bug reports to exclude them, or want to >revert the renames after upload, that's their choice.

The only caveat I would raise is that on the Ubuntu side, we're working to a >very tight deadline now: Feature Freeze for Ubuntu 24.04 LTS is this >Thursday, and while I think we're going to vary our Debian Import Freeze in >order to get the time_t transition through, we aren't going to vary it by >much. So maintainer name reverts in unstable that happen after this are not >guaranteed to be picked up, and whatever package names we have on the Ubuntu >side are going to be locked in for a 10-year LTS cycle. So I think any >maintainer who's concerned about dependency compatibility with third-party >debs should bear this in mind.

--
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/ >slangasek@ubuntu.com vorlon@debian.org

------W4Q955HVHS0MY6HS5N9SYIETRXHLJK
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div dir="auto">Hi all,<br><br>The time_t transition seems to be stalled due to issues on armel/armhf architecture. My understanding is, as long as this transition isn't over, uploaders of affected packages are discouraged to
upload anything unrelated to this transition (to avoid any delays to get it through).<br><br>Do we have an updated rough idea for how long this transition will take? Is it in the range of day, weeks or months? I have no clue...<br><br>Regards,<br>Micha</

<br><br><div class="gmail_quote"><div dir="auto">Am 27. Februar 2024 08:19:21 MEZ schrieb Steve Langasek &lt;vorlon@debian.org&gt;:</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);

padding-left: 1ex;">
<pre class="k9mail"><div dir="auto">Hi Simon,<br><br>On Mon, Feb 26, 2024 at 11:40:56AM +0000, Simon McVittie wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><
blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><div dir="auto">glib2.0 # already in experimental<br></div></blockquote></blockquote><div dir="auto"><br></div><blockquote class="gmail_
quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><div dir="auto">The upstream version in experimental is unsuitable for unstable, but it's<br>"the same shape" as the version in unstable in all the places that
matter,<br>and we ack'd the earlier NMU to experimental already, so I'm confident<br>that similar changes will apply cleanly to the version in unstable. The<br>GNOME team can probably handle this one when the time comes, if that<br>would help (I know
your Canonical colleague Jeremy Bícha was asking to<br>let the GNOME team do coordinated team-uploads rather than NMUs, I'm not<br>sure what the resolution of that was).<br></div></blockquote><div dir="auto"><br>Yes, this is on the list to flag that it
is a package for which we do not<br>have a guarantee of dumat coverage in experimental prior to uploading to<br>unstable, and thus we might hit usrmerge problems for the first time in<br>unstable.<br><br>In this particular case the t64 NMU sat in
experimental for 2 weeks<br>(31Jan-13Feb) before being replaced by a maintainer upload. So I trust that<br>Helmut would have screamed at me if glib2.0 had gone pear-shaped.<br><br>But that is a finer level of investigation than we have the capacity for
at<br>this stage for each of these 50+ packages.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><div dir="auto">Also, if it's valid to apply this reasoning:<br></div></
blockquote><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><div dir="auto">- libhigh0 depends on liblow0<br>- liblow0 will transition to liblow0t64<br>-
libhigh0 does not really need to change its name because we know that the<br> version built against liblow0 is the old ABI, the version built against<br> liblow0t64 is the new ABI, and they cannot be co-installable<br></div></blockquote><div dir="auto">
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><div dir="auto">then we can cross all of the GLib-based packages off the list<br>immediately, and handle them by transitioning
glib2.0 from libglib2.0-0<br>to libglib2.0-0t64. That covers at least these:<br></div></blockquote><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote
class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><div dir="auto">evolution # no sane ABI info, but maintainer handling via e-d-s<br>gimp # already in experimental<br>gtk+2.0 # false positive<

gtk+3.0 # false positive<br>libvirt-glib # ftbfs<br>mutter # already in experimental<br>telepathy-farstream # known ftbfs<br></div></blockquote></blockquote><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.

8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><div dir="auto">... and similar logic could be applied to in the Qt ecosystem, with Qt<br>as the low-level package. Does that help to reduce the numbers?<br></div></blockquote><div dir="auto"><br>
Special-casing these stacks because they don't "need" to be renamed is, on<br>our side, more work and more prone to mistakes than if we just include them<br>in the mass NMU. *Not* renaming is not meaningfully better as a user<br>experience than renaming,
so I don't think it's valuable from the<br>perspective of the overall transition to carve out these exceptions.<br><br>If maintainers are confident that the renames are unnecessary and want to<br>remove the 'pending' tag from the bug reports to exclude
them, or want to<br>revert the renames after upload, that's their choice.<br><br>The only caveat I would raise is that on the Ubuntu side, we're working to a<br>very tight deadline now: Feature Freeze for Ubuntu 24.04 LTS is this<br>Thursday, and while I
think we're going to vary our Debian Import Freeze in<br>order to get the time_t transition through, we aren't going to vary it by<br>much. So maintainer name reverts in unstable that happen after this are not<br>guaranteed to be picked up, and whatever
package names we have on the Ubuntu<br>side are going to be locked in for a 10-year LTS cycle. So I think any<br>maintainer who's concerned about dependency compatibility with third-party<br>debs should bear this in mind.<br><br></div></pre></blockquote>
</div></body></html>
------W4Q955HVHS0MY6HS5N9SYIETRXHLJK--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Thu, Mar 14, 2024 at 10:47:02PM +0100, Micha Lenk wrote:

The time_t transition seems to be stalled due to issues on armel/armhf architecture. My understanding is, as long as this transition isn't over, uploaders of affected packages are discouraged to upload anything
unrelated to this transition (to avoid any delays to get it through).

Do we have an updated rough idea for how long this transition will take?
Is it in the range of day, weeks or months? I have no clue...

Well, I think I should send an update about this probably, because I don't think you should be discouraged from uploading right now. The source
packages with the renames have landed in unstable, and will take a while (probably weeks) to get all of the build-dependency loops worked out and the binNMUs all done. There's no real need to hold off on other uploads at this point in the face of that, I don't expect it to significantly change the timeline.

There may be some rare cases of pending transitions that would add to the
set of packages that need to migrate to testing all at once (though this
seems unlikely to me when there are already so many!), so those should still
be coordinated with the Release Team.

Am 27. Februar 2024 08:19:21 MEZ schrieb Steve Langasek <vorlon@debian.org>: >Hi Simon,

On Mon, Feb 26, 2024 at 11:40:56AM +0000, Simon McVittie wrote:

glib2.0 # already in experimental

The upstream version in experimental is unsuitable for unstable, but it's >> "the same shape" as the version in unstable in all the places that matter, >> and we ack'd the earlier NMU to experimental already, so I'm confident
that similar changes will apply cleanly to the version in unstable. The
GNOME team can probably handle this one when the time comes, if that
would help (I know your Canonical colleague Jeremy B�cha was asking to
let the GNOME team do coordinated team-uploads rather than NMUs, I'm not >> sure what the resolution of that was).

Yes, this is on the list to flag that it is a package for which we do not >have a guarantee of dumat coverage in experimental prior to uploading to >unstable, and thus we might hit usrmerge problems for the first time in >unstable.

In this particular case the t64 NMU sat in experimental for 2 weeks >(31Jan-13Feb) before being replaced by a maintainer upload. So I trust that >Helmut would have screamed at me if glib2.0 had gone pear-shaped.

But that is a finer level of investigation than we have the capacity for at >this stage for each of these 50+ packages.

Also, if it's valid to apply this reasoning:

- libhigh0 depends on liblow0
- liblow0 will transition to liblow0t64
- libhigh0 does not really need to change its name because we know that the
version built against liblow0 is the old ABI, the version built against >> liblow0t64 is the new ABI, and they cannot be co-installable

then we can cross all of the GLib-based packages off the list
immediately, and handle them by transitioning glib2.0 from libglib2.0-0
to libglib2.0-0t64. That covers at least these:

evolution # no sane ABI info, but maintainer handling via e-d-s
gimp # already in experimental
gtk+2.0 # false positive
gtk+3.0 # false positive
libvirt-glib # ftbfs
mutter # already in experimental
telepathy-farstream # known ftbfs

... and similar logic could be applied to in the Qt ecosystem, with Qt
as the low-level package. Does that help to reduce the numbers?

Special-casing these stacks because they don't "need" to be renamed is, on >our side, more work and more prone to mistakes than if we just include them >in the mass NMU. *Not* renaming is not meaningfully better as a user >experience than renaming, so I don't think it's valuable from the >perspective of the overall transition to carve out these exceptions.

If maintainers are confident that the renames are unnecessary and want to >remove the 'pending' tag from the bug reports to exclude them, or want to >revert the renames after upload, that's their choice.

The only caveat I would raise is that on the Ubuntu side, we're working to a >very tight deadline now: Feature Freeze for Ubuntu 24.04 LTS is this >Thursday, and while I think we're going to vary our Debian Import Freeze in >order to get the time_t transition through, we aren't going to vary it by >much. So maintainer name reverts in unstable that happen after this are not >guaranteed to be picked up, and whatever package names we have on the Ubuntu >side are going to be locked in for a 10-year LTS cycle. So I think any >maintainer who's concerned about dependency compatibility with third-party >debs should bear this in mind.

--
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/ >slangasek@ubuntu.com vorlon@debian.org

--
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/ slangasek@ubuntu.com vorlon@debian.org

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmXzw48ACgkQVo0w8yGy Ez3WqQ/8Dk3NZ5jhzoYh90D8atav2FJxQPWDKklOfYpz/12xZb1dUdMK/12VNcmZ M+G3wAHF9fQKRHDQnWe2/i6Q3e0A3IMO7IECFtGcwdjtmjDg9qfImhwiXv5cJ2Xf P5CQU7iYnFEcXfn+FbXeVfxjW06ELDvw4wDjDA7PpUDaWqByKuSHLDqoO+FWRwnr 1yCM+klBcYU5xVZdiOhqIj404QLzQRu/EzDAEW0acYPbtzTgASecAXqMgRMXMVel bRIKKCpI8kySm1LNS6AWuGui+Mncf6tyiXN/r9eQZccRI3kCv96HCUkw9x3Pli+z dvnYsZjIhUs4C43QhSsdmTcw4UIE28c5crNk0TFACSXSPbg+OwS96tc+o1PSL9s2 6tMrO8YPoDyLgFbB5haJaNTfzpyyCnaJdueKAKxx4xiVuBxl76/lQBla4XyKfNPG +NKkOZWnPMx30275mXgH818Iy0GRnm8w1uNvNOcIpCLsIgLJGeM+kEUC3NW8Ln4J 7aBCdlbYNStWnNTep+TBJ5iQg3aQngC+Q8rUcsK5ul1kTk18m15uYYn4mnDXnSDu oKbgrQ7VVVzL6oktKN/F

On Thu, Mar 14, 2024 at 08:42:14PM -0700, Steve Langasek wrote:

On Thu, Mar 14, 2024 at 10:47:02PM +0100, Micha Lenk wrote:

The time_t transition seems to be stalled due to issues on armel/armhf architecture. My understanding is, as long as this transition isn't over, uploaders of affected packages are discouraged to upload anything
unrelated to this transition (to avoid any delays to get it through).

Do we have an updated rough idea for how long this transition will take? Is it in the range of day, weeks or months? I have no clue...

Well, I think I should send an update about this probably, because I don't think you should be discouraged from uploading right now. The source packages with the renames have landed in unstable, and will take a while (probably weeks) to get all of the build-dependency loops worked out and the binNMUs all done. There's no real need to hold off on other uploads at this point in the face of that, I don't expect it to significantly change the timeline.

That's great to hear. A more visible progress update would be greatly appreciated.

There may be some rare cases of pending transitions that would add to the
set of packages that need to migrate to testing all at once (though this seems unlikely to me when there are already so many!), so those should still be coordinated with the Release Team.

It would be nice if the update included information on how to figure
out whether one's packages are likely to fall into this "rare cases"
bucket. Something like that might have provided in the past, but
giving it greater visibility would help a lot IMO.

--
Andrea Bolognani <eof@kiyuko.org>
Resistance is futile, you will be garbage collected.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEO48t9niVypx3EjLf954fxUKFg6wFAmX0crwACgkQ954fxUKF g6z6yxAA8bkFx2TYNjaMPCvKZnFqltDnv0QQjPjN5YyyBvsTy9Ux8mbNwP+4HBfJ 5oYATgWB4dx60AYxXdvfWzWbJCa6adgR/uICUnvPcTHlE5yBF85TPFbCXVkKYL8H KWodnyTh0+oWWzNcV5bu/7zMVzvbU5HKhqmcIzlkyP+njRfnlSWvGSzyyeM1hCbF WnmgjXilGe3jJVGiLQtuPTgAz389HgaG3QVUYP8lXCd5HeiU3uKQ02rbjH9hivyt uomC2wswsQK3Ugs6Qp3vkPWtEKWq44/AQH/y+7ijdSfro9Y2wSLn1/T9iL1J4hxA O2cxOlHEDaGDtWL+Ad6GH+2mCgIqc5luOP8Fl6T3c7KtAkLGBeB87R72bwzwGOtm QUQ+RoxFLkGwILKoNoVOBy+oc9jdfnInraJP3vobk+T7RpUZY3wQ6PIBPiv0dUpJ lTSKXr/anZYwSK5CVPUn04gCWw+n/Lz1Nim8YF5F8iQdCmA/pi8yUOu4zu7ZvFUA /t1Xp/jh5X+Uead1LJvei06v4w+1Fbe3EU+4j8X4FxW7OZ/moCLUKvbdRDu3O68s AQ2gtt7z1GGhTEnu7Oo9t2nq3KYajLICKGK+X2iPPgPdz8YFGKbiBd6DVY9ws+2W 5qDX1h5IFScDFfd2FJ2heMzqe5N9YvrrEMisO+HutjbWAoLO9Zg=
=AurU
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Wondering about the current state of this transition. Is there a tracker of any kind for this? Or would someone be willing to post an email here periodically? Weekly maybe?

I looked at the release goals wiki and at the "brain dump" page but failed to find anything dated more precisely than "***The t64 transition is ongoing (March 2024) in Debian***".

There are five milestones listed on the release goal page. I would hazard that
the first three are done but I'm not sure whether the last two are complete?

The Milestones are:

1. Make a complete list of libraries with changed public ABI changes that must transition together.

2. Change gcc-* to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 by default.

3. Change dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 on
all 32-bit arches except i386 and hurd-i386 (filter this out for 100-odd packages which are sensitive to LFS but not time_t).

4. NMU all libraries with binaries renamed from libfoo to libfoot64, removing old suffixes (c102, c2, ldbl, g…) if present, and emit a Provides/Replaces/ Breaks libfoo on 64-bit arches + i386 and hurd-i386.

5. Do unchanged source rebuilds (binNMUs on all architectures) of 5000-6000 packages which depend on those. By the magic of transitions this just works.


I'm guessing that we're somewhere in the midst of Milestone 5?

In looking at packages I maintain, I find things like "blocked by ${pkg}". But
when I go to the blocker, there's often no upload for 2-3 weeks and no other visible sign of progress. What's holding things up? Are we waiting for folks to identify the 5-6k packages that need binNMU?

Can we help? I tried filing a binNmu bug for a package, but then found out the
package was nmu'd later -- without closing my bug. So clearly someone is looking at things. Where are we in the process?

Appreciate all the good work going into this. Just wondering whether there's something constructive I could pitch in on? If there is nothing for me but to wait, that is useful information, too.

Thanks,
-Steve

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEy89k8fa3rclNjyokyeVeL63I9LkFAmX/TrgACgkQyeVeL63I 9LnyaA//WDpxWxgRoO1UrnVBhaA2Q1nEb6+E726w7GlH0MlHgIfDaF18UMcmyL6z IXKxy7VJS2h6nkK1awcUF6rueusByJD6CF0Mnuk6tgsnvClm+sI5vUADzXr74VVj M60ynrrHwulC/wU41z1bBaoeInCunW9WzQABcbukjlS8HAZ6qYk7AZsjwFLpfudu WQ+/iY4w0ErfzxbxnT8UTiB0yKBE2E7cIxzRTLj4v9ySjxrL6k2XVkkWvO9c5Cxe HWow2e4UkYzerQ4wkfkbmA8JGsdpAKkf7PNmHuF3p++V77REkmKCNJjU1MTxNLRo CIy3CdnXW3cmL57/HF/dHgL0x6ZPJOa7Ka6YynlujNwmVXZWsDBK507mwkkrtaiP MJwDpa+0u6xUZgLQaNJRMdHf/UCcue4SMTTlJ0bFwHwJGXU9FX5IxFAYvDe1dQJz pUDtiyGVcO1PqwfsZTQ6j0DjhoVnI8l3Q0ooWwK5X5UG4fwhgmq/vZ8/M251EC/3 76uL//nHNjuKv1mj8r1kFlvJwjFTv8ka78qpgrGO/VbnLDCHwiXHOh2FAhLG2PLI y6rVZ+hgi57Ok/Q9vVHhkJfJNufvlLDNjvfsDe81+9FB+c67P4xYa6bnNbyJQ2KQ Qbu2kh7M9yW/nz5It6qXHYXuacNudtBywRRjqRkNFRBSlMub0ZA=
=h7SS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Mar 23, 2024 at 04:50:48PM -0500, Steven Robbins wrote:

Wondering about the current state of this transition.

It's still in the stage of re-bootstrapping armel and armhf. https://buildd.debian.org/stats/armel.png https://buildd.debian.org/stats/armhf.png https://buildd.debian.org/stats/graph-week-big.png

5. Do unchanged source rebuilds (binNMUs on all architectures) of 5000-6000 packages which depend on those. By the magic of transitions this just works.

I'm guessing that we're somewhere in the midst of Milestone 5?

Yes.

In looking at packages I maintain, I find things like "blocked by ${pkg}". But
when I go to the blocker, there's often no upload for 2-3 weeks and no other visible sign of progress.

Just don't look at migration data now, it's intentionally blocked by dpkg anyway. If a package B is successfully updated it won't migarte for now
and if a package A depends/build-depends on B it will say "B is blocked by
A" but no further action is needed for either of them.

What's holding things up? Are we waiting for folks to identify the 5-6k packages that need binNMU?

We are waiting for:

1. Dependency cycles to be broken manually (both cases when A B-D: B, B
B-D: A and cases when A B-D: A), like when a new arch is bootstrapped.
This requires developer time, local build time and in the former cases sometimes additional effort for finding where to break the cycle.
An example of a currently existing obstacle of this kind is openjdk-17.

2. FTBFSing packages (those that block further work, anyway) to be fixed
by their maintainers or NMUed. There are many FTBFSing packages, because
of
2.1. not being ready for 64-bit time_t (like assigning those to long);
2.2. not supporting -Werror=implicit-function-declaration;
2.3. symbol file changes due to 64-bit time_t;
2.3. usual bitrot.
An example of a currently existing obstacle of this kind is snapd-glib
(mainly because it blocks pipewire).

3. Not all binNMUs being scheduled yet.

4. buildd time to rebuild packages that can be rebuilt, when there are
any (currently not applicable).

Can we help? I tried filing a binNmu bug for a package, but then found out the
package was nmu'd later -- without closing my bug. So clearly someone is looking at things. Where are we in the process?

From my experience in the past week, you (or any DD, and for parts not involving uploads anyone) can do these things to speed up the process:

1. Help with FTBFS bugs. The options here are the usual ones: triage; fix
and attach the patch; fix and upload a NMU; find a patch in the upstream source/upstream tracker/trackers of other distros; suggest general ideas
for a fix or at least for the reason of the problem.
This is more helpful for non-leaf packages.
2. File FTBFS bugs if you see something FTBFS but there is no bug reported
yet.
3. Identify packages that were not binNMUed against *t64 libraries (packages.d.o helps with this, showing deps for all architectures), at all
or on some arches (usually armel and armhf) and file binNMU bugs against release.debian.org for those.
4. Find packages that need to be rebuilt but can't, because they FTBFS or
B-D on packages that also can't be rebuilt, while blocking many packages,
and build them locally (most likely by enabling some build profile already specified in the package) for armel and armhf and upload those binaries.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmX/3MQtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 7O8P/jj6Y61j4vXgTjXQvAJJgoXaTOz4W8CJCRJFXL3srdlk0ziENAyjufSIXVsP fY4tXxr1/WNLmaO8xC4EVraF37J9Db1HoP4nm0sX24yK/tdUFRTKSllUOyBN1VJ6 z2PVYntqpleohuXTmPum2Gv4+cW+0KOKs1fFwrjv3v3k7fSk2eXxNhiy7q6rltmN fT2+45KVcjC5pLhXbv5ahp5PjoyLgEIu6JIsTHzAAALOJ4F0Hfy5bbnmFkTNErZt 6SkrPHPm+xg5fxfFsnxl7vXB1P7CcW/XEBiFhJvg5ay/3LK92RTteD7w1UxGfCgy 2ar84uvGMw59d3JswBzA30Lg7ACgLyZCK2ZfOk9o/Gvcu82xQTJodDrGsl5twAJO S78wBEy0D79rm6COMyoRublpMsnLH8TQZJUbfPdKZL68DGZYuy4sFuHqKMeFWnoA NPTGdOCrNY/FgohGIVnf2oP2lmDtxbyGRp/AyfdXbSFzUSGrIBSQ2z7oHbATq2mm cYFw7SffSrlc4z9fiMgwMosUlMuzDEVvv1icw1TNyZORoJO5kj6sTLYf+0McyQm2 Ee0xKzTgXT5fClpJrvfDsSyKttK8ngaBLeGo3BorbwZUEgLTp/k20WckC5ir0CaU JIiP02+gDnRr+TdBmhDZsAOhLefMU8G+CuauNTbS6q1amPXK
=ZSAJ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Simon McVittie, le dim. 24 mars 2024 11:59:50 +0000, a ecrit:

On Sun, 24 Mar 2024 at 12:56:52 +0500, Andrey Rakhmatullin wrote:

2. FTBFSing packages (those that block further work, anyway)

...

An example of a currently existing obstacle of this kind is snapd-glib (mainly because it blocks pipewire).

For the specific example of pipewire, I've suggested temporarily
dropping that feature from pipewire on the affected architectures <https://bugs.debian.org/1067558> which would get the rebuilds further
along (particularly if it unblocks weston, which lots of packages use
in their tests). There are various places where targeted changes like
this can unblock a whole tree of dependencies.

Could we use build profiles for this? That'd avoid full uploads, and
document for architecture bootstrapping.

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 24 Mar 2024 at 12:56:52 +0500, Andrey Rakhmatullin wrote:

2. FTBFSing packages (those that block further work, anyway)

...

An example of a currently existing obstacle of this kind is snapd-glib (mainly because it blocks pipewire).

For the specific example of pipewire, I've suggested temporarily
dropping that feature from pipewire on the affected architectures <https://bugs.debian.org/1067558> which would get the rebuilds further
along (particularly if it unblocks weston, which lots of packages use
in their tests). There are various places where targeted changes like
this can unblock a whole tree of dependencies.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote:

Simon McVittie, le dim. 24 mars 2024 11:59:50 +0000, a ecrit:

For the specific example of pipewire, I've suggested temporarily
dropping that feature from pipewire on the affected architectures <https://bugs.debian.org/1067558> which would get the rebuilds further along (particularly if it unblocks weston, which lots of packages use
in their tests). There are various places where targeted changes like
this can unblock a whole tree of dependencies.

Could we use build profiles for this? That'd avoid full uploads, and
document for architecture bootstrapping.

Only if a porter is willing to do a binary build with the relevant
build profile on each of the affected architectures, and upload it as binary-only, after making a note to get it binNMU'd later. The official
buildds for release architectures always build with no build profiles,
and do not have any way (that I'm aware of) to vary this.

The porter-binary-upload approach is necessary for the actual bootstrap
phase of the dependency stack, but doesn't seem to be scaling well in
higher layers, because the number of porters is limited. I'd prefer
to give porters the opportunity to work on more difficult issues where
their architecture-specific knowledge is actually relevant, so I'm doing
my best to unblock some of the dependency chains without having to block
on porter uploads.

However, I'm not an armel/armhf porter (and certainly not an hppa, m68k,
or powerpc porter) and I don't have the relevant hardware up and running,
so I'm not going to sign a specific binary build that I have no ability to test. Similarly, there doesn't seem to be consensus on whether porterboxes should be considered to be a trusted environment, so I'm not comfortable
with signing test-builds that have been done on a porterbox. I'm sorry
if my limitations are inconveniencing people: if other developers have different policies and resources then they are welcome to take over.

When suggesting a cut-down version, what I'm often doing is suggesting
a change of the form "when building on 32-bit non-i386, always build
as though profile pkg.foo.bar was active" - although if there isn't
already a convenient build-profile to do this with, I admit I haven't
always been adding one, because that adds complexity, and I don't want maintainers' response to my suggestions to be "that looks too hard, I'm
not going to touch this".

Build-profiles are at their most useful where they are "safe" or
"reproducible" (no functional effect on the built binaries, except
that some binary packages are skipped entirely), and in many cases
the features we're having to disable at this stage of the transition
*do* have a functional impact. I'd personally prefer for changes with
a functional impact to be documented in the changelog so that we know
they have happened, and built on the same trusted buildds as any other
official package.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Simon McVittie, le dim. 24 mars 2024 16:45:02 +0000, a ecrit:

On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote:

Simon McVittie, le dim. 24 mars 2024 11:59:50 +0000, a ecrit:

For the specific example of pipewire, I've suggested temporarily
dropping that feature from pipewire on the affected architectures <https://bugs.debian.org/1067558> which would get the rebuilds further along (particularly if it unblocks weston, which lots of packages use
in their tests). There are various places where targeted changes like this can unblock a whole tree of dependencies.

Could we use build profiles for this? That'd avoid full uploads, and document for architecture bootstrapping.

Only if a porter is willing to do a binary build with the relevant
build profile on each of the affected architectures, and upload it as binary-only, after making a note to get it binNMU'd later. The official buildds for release architectures always build with no build profiles,
and do not have any way (that I'm aware of) to vary this.

The porter-binary-upload approach is necessary for the actual bootstrap
phase of the dependency stack, but doesn't seem to be scaling well in
higher layers, because the number of porters is limited. I'd prefer
to give porters the opportunity to work on more difficult issues where
their architecture-specific knowledge is actually relevant, so I'm doing
my best to unblock some of the dependency chains without having to block
on porter uploads.

I understand these, but

- making sure that the Debian release eventually only contains
non-profile builds should be relatively easy thanks to the buildinfo
files (they currently only contain them in the DEB_BUILD_PROFILES
environment variable, they could be added as proper field). We already
track against packages built on non-buildd, we could track packages
built with profiles.

- it's indeed better to avoid loading porters with this, notably because
it'll be most often the same for a set of architectures. The buildd
infrastructure could have an additional build-profile parameter that
can be set on a binNMU, so that such temporary-profile binNMUs can be
requested easily.

I'm not saying that this is trivial now, of course, but it seems to
me that it's not so far, and thus something we'd want to aim for
longterm-wise?

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Samuel Thibault (2024-03-24 18:20:30)

- making sure that the Debian release eventually only contains non-profile builds should be relatively easy thanks to the buildinfo files (they currently only contain them in the DEB_BUILD_PROFILES environment variable, they could be added as proper field). We already track against packages built on non-buildd, we could track packages built with profiles.

the information is also stored in the .changes file in the Built-For-Profiles field. The main reason why the information is not stored in the .deb itself is, because that would make it impossible for packages to be bit-by-bit identical compared those built without certain build profiles active.

Thanks!

cheers, josc
--==============�35137751418047191=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmYAhD4ACgkQ8sulx4+9 g+FROBAAqISpId1s/Eet7gjiotF3AR6PbCEP+kmMQX2EQEAMRVrT54DmAYvcmYof GnYmgrtWFTiNQMIaIRCe8c9talPOic0R7uEmXLw8rU6muHJEJj1tqnfPYk3GTbXs pj+g2Be5DyEdmQrGmtlyJKHz3OPzF6NA20SdzVMWQ2dWt98WIwEl95ZLzg4T+cKw 8exKMU2ZgAOjanurx0WBjReyMENRihsEoFiWpTlpJwd4WvqjCWCseBQVa1PDayF9 fnPaNEGwoFQ8ykDWBSUC6OAQc0GmPTQ2xCyL5a+OdR/IrEurYaHu020c4d2ftocc FJS98zYHp6SeV+qYlCINOqu8/K29j5g+aXpxZb+hdtqvMMHO4N0w6Ix7pDC6nhCM L8Kpn2Tm/ARl+7EN/rN4pdVg/RNwGxGb0GoI5b+IRTMMubZ/dodeB4pcp/3zxaRV YRulJ9AF8LjEPa7UTLaQmdX7H7rZTUhtzAJPW7v11PKWV3JTxXgt1bEF3XI57xIl Db81SdzvOmG/PBFdvyctlhyycWxzqudEGVfNRXXgPGj9f5yxMal1Zbuoh+UCzdXf FQTLhdBRA5CUMn1FjMee5EPWj6K6mTgXjswyTXOzFGtMcNg449Rbr9GafiCt5WXU W7FC0HfBKofa2MAU6Xe0c8sQjFApGyrRYsZxBjRjFUMZ35BxDPs=
=zYmZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Niels Thykier:

Hi

It seems the discussion on this topic has settled, so I am now doing a summary of the discussion as I understand it.

 * Generally, the original proposal seems to have been received
   favorably at a conceptual level.

[...]

A follow up on this:

* The proposal is now implemented in debhelper compat 14 (as of version
13.15+) and debputy (0.1.21+).

* The `debputy` migration tool will flag any obsolete substvars that
are 1:1 with what `debputy` would have applied for you. No tool for
debhelper-based packages exist at this time.

* Lintian is not updated yet and will still complain about missing
relationship substvars. I have filed #1067653 to have that changed.

I expect this to be final on this topic for this round. :)

Best regards,
Niels

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

CgpTZW50IGZyb20gV29ya3NwYWNlIE9ORSBCb3hlcgoKT24gTWFyIDI1LCAyMDI0IDc6NDQgQU0s IE5pZWxzIFRoeWtpZXIgPG5pZWxzQHRoeWtpZXIubmV0PiB3cm90ZToKCj4KCj4gTmllbHMgVGh5 a2llcjogCgo+IEEgZm9sbG93IHVwIG9uIHRoaXM6IAoKPgoKPiAgICogVGhlIHByb3Bvc2FsIGlz IG5vdyBpbXBsZW1lbnRlZCBpbiBkZWJoZWxwZXIgY29tcGF0IDE0IChhcyBvZiB2ZXJzaW9uIAoK PiAgICAgMTMuMTUrKSBhbmQgZGVicHV0eSAoMC4xLjIxKykuIAoKPgoKPiAgICogVGhlIGBkZWJw dXR5YCBtaWdyYXRpb24gdG9vbCB3aWxsIGZsYWcgYW55IG9ic29sZXRlIHN1YnN0dmFycyB0aGF0 IAoKPiAgICAgYXJlIDE6MSB3aXRoIHdoYXQgYGRlYnB1dHlgIHdvdWxkIGhhdmUgYXBwbGllZCBm b3IgeW91LiBObyB0b29sIGZvciAKCj4gICAgIGRlYmhlbHBlci1iYXNlZCBwYWNrYWdlcyBleGlz dCBhdCB0aGlzIHRpbWUuIAoKPgoKPiAgICogTGludGlhbiBpcyBub3QgdXBkYXRlZCB5ZXQgYW5k IHdpbGwgc3RpbGwgY29tcGxhaW4gYWJvdXQgbWlzc2luZyAKCj4gICAgIHJlbGF0aW9uc2hpcCBz dWJzdHZhcnMuIEkgaGF2ZSBmaWxlZCAjMTA2NzY1MyB0byBoYXZlIHRoYXQgY2hhbmdlZC4gCgo+ Cgo+IEkgZXhwZWN0IHRoaXMgdG8gYmUgZmluYWwgb24gdGhpcyB0b3BpYyBmb3IgdGhpcyByb3Vu ZC4gOikgCgo+Cgo+IEJlc3QgcmVnYXJkcywgCgo+IE5pZWxzIAoKCkhpIE5pZWxzLAoKClRoYW5r cyBhIGxvdCBmb3IgeW91ciB3b3JrIG9uIHRoaXMsIEkgdmVyeSBtdWNoIGFncmVlZCB3aXRoIHRo ZSBwcmVtaXNzIHRoYXQgc3Vic3QgdmFycyB3ZXJlIGEgdGhpbmcgZWFzeSB0byBmYWxsIGludG8g dHJhcHMuIEl0IGlzIGEgdmVyeSB3ZWxjb21lZCBpbXByb3ZlbWVudCB0byBhdXRvbWF0ZSB0aGVt IGFuZCBhdm9pZCBtaXN0YWtlcy4KCgpJcyB0aGVyZSBhIHBsYWNlIHdoZXJlIHlvdSB3cm90ZSBz b21lIGtpbmQgb2YgZG9jIGFib3V0IGhvdyB0byB1c2UgZGVicHV0eSBvciBkZWJoZWxwZXIgY29t cGF0IDE0PyBEb2VzIG9uZSBuZWVkIHRvIGFkZCBkZWJwdXR5IGFzIGJ1aWxkLWRlcGVuZHMsIGFu ZCB0aGF0IGlzIGl0PyBQb2ludGVycyB0byBVUkxzIHdlbGNvbWUuCgoKQ2hlZXJzLAoKClRob21h cyBHb2lyYW5kICh6aWdvKQoKCg== PGh0bWw+PGJvZHk+PGJyPjxicj48ZGl2IGRpcj0ibHRyIj5TZW50IGZyb20gV29ya3NwYWNlIE9O RSBCb3hlcjwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj5PbiBNYXIgMjUsIDIwMjQgNzo0NCBBTSwgTmll bHMgVGh5a2llciAmbHQ7bmllbHNAdGh5a2llci5uZXQmZ3Q7IHdyb3RlOjwvZGl2Pgo8ZGl2IGRp cj0ibHRyIj4mZ3Q7PC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgTmllbHMgVGh5a2llcjogPC9k aXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgQSBmb2xsb3cgdXAgb24gdGhpczogPC9kaXY+CjxkaXYg ZGlyPSJsdHIiPiZndDs8L2Rpdj4KPGRpdiBkaXI9Imx0ciI+Jmd0OyDCoCAqIFRoZSBwcm9wb3Nh bCBpcyBub3cgaW1wbGVtZW50ZWQgaW4gZGViaGVscGVyIGNvbXBhdCAxNCAoYXMgb2YgdmVyc2lv biA8L2Rpdj4KPGRpdiBkaXI9Imx0ciI+Jmd0OyDCoMKgwqAgMTMuMTUrKSBhbmQgZGVicHV0eSAo MC4xLjIxKykuIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7PC9kaXY+CjxkaXYgZGlyPSJsdHIi PiZndDsgwqAgKiBUaGUgYGRlYnB1dHlgIG1pZ3JhdGlvbiB0b29sIHdpbGwgZmxhZyBhbnkgb2Jz b2xldGUgc3Vic3R2YXJzIHRoYXQgPC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgwqDCoMKgIGFy ZSAxOjEgd2l0aCB3aGF0IGBkZWJwdXR5YCB3b3VsZCBoYXZlIGFwcGxpZWQgZm9yIHlvdS4gTm8g dG9vbCBmb3IgPC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgwqDCoMKgIGRlYmhlbHBlci1iYXNl ZCBwYWNrYWdlcyBleGlzdCBhdCB0aGlzIHRpbWUuIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7 PC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgwqAgKiBMaW50aWFuIGlzIG5vdCB1cGRhdGVkIHll dCBhbmQgd2lsbCBzdGlsbCBjb21wbGFpbiBhYm91dCBtaXNzaW5nIDwvZGl2Pgo8ZGl2IGRpcj0i bHRyIj4mZ3Q7IMKgwqDCoCByZWxhdGlvbnNoaXAgc3Vic3R2YXJzLiBJIGhhdmUgZmlsZWQgIzEw Njc2NTMgdG8gaGF2ZSB0aGF0IGNoYW5nZWQuIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7PC9k aXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgSSBleHBlY3QgdGhpcyB0byBiZSBmaW5hbCBvbiB0aGlz IHRvcGljIGZvciB0aGlzIHJvdW5kLiA6KSA8L2Rpdj4KPGRpdiBkaXI9Imx0ciI+Jmd0OzwvZGl2 Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7IEJlc3QgcmVnYXJkcywgPC9kaXY+CjxkaXYgZGlyPSJsdHIi PiZndDsgTmllbHMgPC9kaXY+Cjxicj48ZGl2IGRpcj0ibHRyIj5IaSBOaWVscyw8L2Rpdj4KPGJy PjxkaXYgZGlyPSJsdHIiPlRoYW5rcyBhIGxvdCBmb3IgeW91ciB3b3JrIG9uIHRoaXMsIEkgdmVy eSBtdWNoIGFncmVlZCB3aXRoIHRoZSBwcmVtaXNzIHRoYXQgc3Vic3QgdmFycyB3ZXJlIGEgdGhp bmcgZWFzeSB0byBmYWxsIGludG8gdHJhcHMuIEl0IGlzIGEgdmVyeSB3ZWxjb21lZCBpbXByb3Zl bWVudCB0byBhdXRvbWF0ZSB0aGVtIGFuZCBhdm9pZCBtaXN0YWtlcy48L2Rpdj4KPGJyPjxkaXYg ZGlyPSJsdHIiPklzIHRoZXJlIGEgcGxhY2Ugd2hlcmUgeW91IHdyb3RlIHNvbWUga2luZCBvZiBk b2MgYWJvdXQgaG93IHRvIHVzZSBkZWJwdXR5IG9yIGRlYmhlbHBlciBjb21wYXQgMTQ/IERvZXMg b25lIG5lZWQgdG8gYWRkIGRlYnB1dHkgYXMgYnVpbGQtZGVwZW5kcywgYW5kIHRoYXQgaXMgaXQ/ IFBvaW50ZXJzIHRvIFVSTHMgd2VsY29tZS48L2Rpdj4KPGJyPjxkaXYgZGlyPSJsdHIiPkNoZWVy cyw8L2Rpdj4KPGJyPjxkaXYgZGlyPSJsdHIiPlRob21hcyBHb2lyYW5kICh6aWdvKTwvZGl2Pgo8 YnI+PC9ib2R5PjwvaHRtbD4=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 24 Mar 2024 at 18:20:30 +0100, Samuel Thibault wrote:

- it's indeed better to avoid loading porters with this, notably because
it'll be most often the same for a set of architectures. The buildd
infrastructure could have an additional build-profile parameter that
can be set on a binNMU, so that such temporary-profile binNMUs can be
requested easily.

For this particular transition, since that feature doesn't currently exist
in our production infrastructure, we need to get by without it. But, for
the longer term, if someone is able to work on developing what you suggest:

Instead of applying a temporary build profile to all architectures,
ideally we'd be able to say something like "build with nocheck on armel,
armhf, hppa, m68k and powerpc, and normally everywhere else". I think
as well as being able to perform binNMUs with a specified set of build
profiles on particular architectures, this transition would have needed
a way to get the initial build (no +b suffix) to be done with specified
build profiles, because we're often seeing this pattern:

- a developer uploads foo_1.2-3.1 to rename libfoo0 to libfoo0t64
- on the 64-bit architectures plus i386, it builds fine
- on the 32-bit non-x86 architectures, it's blocked waiting for libbar1t64
to become available
- armel is unblocked when a porter does a binary build of foo on armel
with <pkg.foo.nobar>, which means it no longer needs libbar1t64
- and so on for the other architectures

and I don't think creating a binNMU is allowed if the sourceful upload
hasn't been built successfully yet.

Also, if this feature existed as you describe it, then we'd be moving the bottleneck from porters to the release team / wanna-build operators, who
can schedule binNMUs (unilaterally or on request from other contributors).

If this feature existed *and* DDs could schedule binNMUs on a self-service basis (the same way we can give back failed builds now), then yes,
that would spread out the load to all DDs. Or, if the maintainer or NMU uploader could do a source upload with something like this in either
the .dsc, the .changes or some accompanying file:

Use-Build-Profiles: nocheck [armel armhf hppa m68k powerpc], ...

then that would be a way to get the same result as some of the temporary changes I've been making, but without having to write custom code in debian/rules.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi all,

Pierre-Elliott Bécue <peb@debian.org> on Wed, 27 Sep 2023 14:19:20:

Otto Kekäläinen <otto@debian.org> wrote on 27/09/2023 at 06:35:07+0200:

Hi!

Thanks for the context - so there is no need technical incompatibility
at play, but mostly a matter of having resources and time to do it.
..

Regarding the 301 redirection I'll see with the interested parties (DSA
and Lintian maintainers) if this option is fine with everyone.

I could easily write Ansible code to maintain a simple Nginx server,
with 302 redirects https://lintian.debian.org/tags/(.*)/?$ ->
https://udd.debian.org/lintian-tag.cgi?tag=$1, use same Ansible style
as salsa.debian.org is maintained on
(https://salsa.debian.org/salsa/salsa-ansible), and also donate a tiny
virtual machine for Debian project if needed. Is there some special
bureaucracy on top of that work to do to be able to contribute with
this?

Don't worry, the server still exists, it's just down, and reputting the
DNS takes little to no time.

Regarding apache config, I'm fine with doing it. It's a matter of
checking with everyone that we want to do that as the plan was nuking
the server from orbit.

Providing debian.org infrastructure requires to be a member of the
Debian System Administrators (DSA) team, which in turn requires to be a Debian Developer, so, sadly, you can't really help on that part.

That being said, thank you for offering your time.

I sent the following email in reply to Bug#1042428 but I didn't see it
was archived, so I repost it here:

As I just recently started making Debian packages, I clicked multiple times on links to <https://lintian.debian.org> that led me to a dead end, for instance from mentors.debian.org, or on the hyperlinks that lintian itself produce in the terminal

output. It was not a very pleasant experience, especially for a newbie.

In my opinion, redirecting lintian.debian.org to the UDD links posted above is not a good option, because as I understand it, they only were intended to show the extended explanation for each tag. Having the list of all the affected packages in this

page it not helpful, and it makes the pages very slow to load (and to produce).

So instead I thought that it would be quite easy to generate a static website that would be very fast to generate once, and then to serve and load. So I made my own implementation that generates a website that could be directly uploaded to lintian.

debian.org, as it follows strictly the previous URL structure (I also added the manual of lintian as I also stumbled on links to it).

For now I hosted it on my server so you can see the result there:

<https://static.club1.fr/nicolas/lintian/>

For instance the link above translates to:

<https://static.club1.fr/nicolas/lintian/tags/superfluous-file-pattern.html>

And here are the sources:

<https://github.com/n-peugnet/lintian-ssg>

It is not meant to replace the corresponding UDD link, in fact I added a link to it in the page of each tag, to see all the affected packages. But I think it is better to first arrive on a very fast to load page that simply explains the tag, and then

be able to follow a link to see the list of affected packages.

Please telle me what you think about it and if you think it can be uploaded to lintian.debian.org?

In the meantime I added some features and hosted it on its own domain to
make the custom 404 page work correctly: <https://lintian.club1.fr/>.
So, do you think it could be used to make the lintian.debian.org website
back up?

P.S. I'm not subscribed to this list, so please CC me.

Regards
--
Nicolas Peugnet

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: debian-lint-maint@lists.debian.org

Le mercredi 7 août 2024, 17:05:01 UTC Nicolas Peugnet a écrit :

Hi all,

Pierre-Elliott Bécue <peb@debian.org> on Wed, 27 Sep 2023 14:19:20:

Otto Kekäläinen <otto@debian.org> wrote on 27/09/2023 at 06:35:07+0200:

Hi!

Thanks for the context - so there is no need technical incompatibility
at play, but mostly a matter of having resources and time to do it.
..

Regarding the 301 redirection I'll see with the interested parties (DSA >>> and Lintian maintainers) if this option is fine with everyone.

I could easily write Ansible code to maintain a simple Nginx server,
with 302 redirects https://lintian.debian.org/tags/(.*)/?$ ->
https://udd.debian.org/lintian-tag.cgi?tag=$1, use same Ansible style
as salsa.debian.org is maintained on
(https://salsa.debian.org/salsa/salsa-ansible), and also donate a tiny
virtual machine for Debian project if needed. Is there some special
bureaucracy on top of that work to do to be able to contribute with
this?

Don't worry, the server still exists, it's just down, and reputting the
DNS takes little to no time.

Regarding apache config, I'm fine with doing it. It's a matter of
checking with everyone that we want to do that as the plan was nuking
the server from orbit.

Providing debian.org infrastructure requires to be a member of the
Debian System Administrators (DSA) team, which in turn requires to be a Debian Developer, so, sadly, you can't really help on that part.

That being said, thank you for offering your time.

I sent the following email in reply to Bug#1042428 but I didn't see it
was archived, so I repost it here:

As I just recently started making Debian packages, I clicked multiple times on links to <https://lintian.debian.org> that led me to a dead end, for instance from mentors.debian.org, or on the hyperlinks that lintian itself produce in the terminal

output. It was not a very pleasant experience, especially for a newbie.

In my opinion, redirecting lintian.debian.org to the UDD links posted above is not a good option, because as I understand it, they only were intended to show the extended explanation for each tag. Having the list of all the affected packages in this

page it not helpful, and it makes the pages very slow to load (and to produce).

So instead I thought that it would be quite easy to generate a static website that would be very fast to generate once, and then to serve and load. So I made my own implementation that generates a website that could be directly uploaded to lintian.

debian.org, as it follows strictly the previous URL structure (I also added the manual of lintian as I also stumbled on links to it).

For now I hosted it on my server so you can see the result there:

<https://static.club1.fr/nicolas/lintian/>

For instance the link above translates to:

<https://static.club1.fr/nicolas/lintian/tags/superfluous-file-pattern.html>

And here are the sources:

<https://github.com/n-peugnet/lintian-ssg>

It is not meant to replace the corresponding UDD link, in fact I added a link to it in the page of each tag, to see all the affected packages. But I think it is better to first arrive on a very fast to load page that simply explains the tag, and then

be able to follow a link to see the list of affected packages.

What will be wonderfull is to retrieve number of package affected and do a svg graph along time... Using a static script

nicolas did you contact the the infrasture team ?

Bastien

Please telle me what you think about it and if you think it can be uploaded to lintian.debian.org?

In the meantime I added some features and hosted it on its own domain to make the custom 404 page work correctly: <https://lintian.club1.fr/>.
So, do you think it could be used to make the lintian.debian.org website back up?

P.S. I'm not subscribed to this list, so please CC me.

Regards

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAma1ERsACgkQADoaLapB CF+xTQ//S4UlMT4OG7bjQLtj7kJ2ZP6LcIuSFidEwwCBJKm+h/1FUiBE2S7e2wsf kmwp4Cl3f2hTUzGv1D6kmiKbheJppdTB/oxGZoLhhzPKJzmlng7zEJeOrb8u6IgG YPo3x2ivV/4Ablg1cZJCqXhxhrbm0p7OrVuMgv3K8/Z8sKPiW0Y4FmgPfkt0IkMn 8Yc37mEIpzb+KOTjFplUThKGVASKvjWK+Xe8vQ4L83Kq9qSLjhOzSIWLuRSTYJY/ DumVtMDZtPoVAVxgsWHP6UJdTCnh+TX98/kLqcmoQPk1BklUAoblkvX62AK/DxVR S6ZkHjQkS3rGi3coxe0FZitOFzF1uqu+iteVOlqFfZal25Jolh8b5R+u87xTwLqB 7o9da+XOYb/zil09m6bdTYQovlKLg0vJ6zQXAUygizRuZVSQk8H2IMXSZ0qUL4Xn rz4pneqTqSIohyRwGqjBHzaI+rSWV33ufXa8wfMLQHprm6YI75NFr8w/tRfBBeS0 ZumLtmqBPkAvnkXGBbVSgXp5CTkivzRIexz6Af7avKMGe+Vtv95Zv0xdJbEOsYCC /rCAxHPsmVr5sMTCKESNsOcAZvYzcjiW8BwNXJSdGy2/jy0lC9m03sNUEZCDQY5r UWyBr/kHVe/Zt5cS8T5kyJ76AZzmrnLV159YaPKlH9mv+cv4uRM=
=tNDn
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07/08/24 at 19:05 +0200, Nicolas Peugnet wrote:

Hi all,

Pierre-Elliott B�cue <peb@debian.org> on Wed, 27 Sep 2023 14:19:20:

Otto Kek�l�inen <otto@debian.org> wrote on 27/09/2023 at 06:35:07+0200:

Hi!

Thanks for the context - so there is no need technical incompatibility
at play, but mostly a matter of having resources and time to do it.
..

Regarding the 301 redirection I'll see with the interested parties (DSA and Lintian maintainers) if this option is fine with everyone.

I could easily write Ansible code to maintain a simple Nginx server,
with 302 redirects https://lintian.debian.org/tags/(.*)/?$ -> https://udd.debian.org/lintian-tag.cgi?tag=$1, use same Ansible style
as salsa.debian.org is maintained on (https://salsa.debian.org/salsa/salsa-ansible), and also donate a tiny virtual machine for Debian project if needed. Is there some special bureaucracy on top of that work to do to be able to contribute with
this?

Don't worry, the server still exists, it's just down, and reputting the
DNS takes little to no time.

Regarding apache config, I'm fine with doing it. It's a matter of
checking with everyone that we want to do that as the plan was nuking
the server from orbit.

Providing debian.org infrastructure requires to be a member of the
Debian System Administrators (DSA) team, which in turn requires to be a Debian Developer, so, sadly, you can't really help on that part.

That being said, thank you for offering your time.

I sent the following email in reply to Bug#1042428 but I didn't see it was archived, so I repost it here:

As I just recently started making Debian packages, I clicked multiple times on links to <https://lintian.debian.org> that led me to a dead end, for instance from mentors.debian.org, or on the hyperlinks that lintian itself produce in the terminal

output. It was not a very pleasant experience, especially for a newbie.

In my opinion, redirecting lintian.debian.org to the UDD links posted above is not a good option, because as I understand it, they only were intended to show the extended explanation for each tag. Having the list of all the affected packages in this

page it not helpful, and it makes the pages very slow to load (and to produce).

So instead I thought that it would be quite easy to generate a static website that would be very fast to generate once, and then to serve and load. So I made my own implementation that generates a website that could be directly uploaded to lintian.

debian.org, as it follows strictly the previous URL structure (I also added the manual of lintian as I also stumbled on links to it).

For now I hosted it on my server so you can see the result there:

<https://static.club1.fr/nicolas/lintian/>

For instance the link above translates to:

<https://static.club1.fr/nicolas/lintian/tags/superfluous-file-pattern.html>

And here are the sources:

<https://github.com/n-peugnet/lintian-ssg>

It is not meant to replace the corresponding UDD link, in fact I added a link to it in the page of each tag, to see all the affected packages. But I think it is better to first arrive on a very fast to load page that simply explains the tag, and then

be able to follow a link to see the list of affected packages.

Please telle me what you think about it and if you think it can be
uploaded to lintian.debian.org?

In the meantime I added some features and hosted it on its own domain to
make the custom 404 page work correctly: <https://lintian.club1.fr/>. So, do you think it could be used to make the lintian.debian.org website back up?

P.S. I'm not subscribed to this list, so please CC me.

Hi,

If there is interest in providing a page that only list the tag
description (without the affected packages), it would be easier to add
it to the existing UDD page (with an additional parameter for example)
than to create a separate service.

However I haven't seen any interest from DSA in setting a redirect from lintian.debian.org to somewhere else. As I wrote in #1042428, if
lintian.d.o was served by ullmann and managed by the uddadm group, I
would be willing to manage those redirects.

Lucas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/08/24 at 18:40 +0000, Bastien Roucari�s wrote:

It is not meant to replace the corresponding UDD link, in fact I added a link to it in the page of each tag, to see all the affected packages. But I think it is better to first arrive on a very fast to load page that simply explains the tag, and

then be able to follow a link to see the list of affected packages.

What will be wonderfull is to retrieve number of package affected and do a svg graph along time... Using a static script

Hi Bastien,

Are you aware of https://trends.debian.net/ ?

Best,

Lucas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le vendredi 9 août 2024, 06:39:04 UTC Lucas Nussbaum a écrit :

On 08/08/24 at 18:40 +0000, Bastien Roucariès wrote:

It is not meant to replace the corresponding UDD link, in fact I added a link to it in the page of each tag, to see all the affected packages. But I think it is better to first arrive on a very fast to load page that simply explains the tag, and

then be able to follow a link to see the list of affected packages.

What will be wonderfull is to retrieve number of package affected and do a svg graph along time... Using a static script

Hi Bastien,

Are you aware of https://trends.debian.net/ ?

No but the same with every tag will be really really nice

It is a really nice tool

Best,

Lucas

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAma1yzoACgkQADoaLapB CF+1lxAAow/P84GasjbiDBX4p8gQVy3GTw6r4K9S2B2kb6ba1DYzWUznuUHdfEPo gZkY9HBPDF3ODUJaoqqETrcOpZxMcl7t3SLJYrhZnmMNV6Rf1ykct7Mt1SleA97z Nw/hUMVtvuv36d3rRsNiZG+cgJkMM79HW0+j/snVwSxitNkJK5phFJzPv1Pqfr85 4gE9/AHnNIh6VR9PebBuzYPbE5tkHmMhxAANj0cKVp0+ha9Z9pkEUCVdZBrOdM1w JccC1auwpy0Kxk8Svdxiw9ytsaJoumr4o+YJNPyM8db59aw+d3aY+TQo9+XHZr53 jbwl4mBdSVA32l6R77peGDpsIneeZR6Sft/PI58VhhQ5NCLZQ7wySx4DsmZ6xi9w Rgp8M9Y8R9o08/+EKhT3TgJ4TDymkUvRsKLHv4s/tSJHJwGnkjyTQ2mpvVvmx4mO nxnTaUrqfSTb/8U3aZOKY7Syah4auIJtc9vxI8sITGQ08Ux95u4iIX8zIJI1nbMJ MARTp1ub9I0ly2PKOTMgsmfKUYmK2tMOoqT+K6rUYzBisGXkaiyIRlc5E/aJNmN1 AV1znpxOCBlIPaIUHBvIVJbYw9IbA5Rn03oFghpQp5aJLizU4vb2lX+odJkk8ndL IBaotYNIK7g9t0URCPF/unKFaopda7V1JgR9jD/o7MECT7YNy8E=
=UQ66
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/2024 8:43 AM, Lucas Nussbaum wrote:

On 07/08/24 at 19:05 +0200, Nicolas Peugnet wrote:

[...]

I sent the following email in reply to Bug#1042428 but I didn't see it was >> archived, so I repost it here:

As I just recently started making Debian packages, I clicked multiple times on links to <https://lintian.debian.org> that led me to a dead end, for instance from mentors.debian.org, or on the hyperlinks that lintian itself produce in the terminal

output. It was not a very pleasant experience, especially for a newbie.

In my opinion, redirecting lintian.debian.org to the UDD links posted above is not a good option, because as I understand it, they only were intended to show the extended explanation for each tag. Having the list of all the affected packages in this

page it not helpful, and it makes the pages very slow to load (and to produce). >>>

So instead I thought that it would be quite easy to generate a static website that would be very fast to generate once, and then to serve and load. So I made my own implementation that generates a website that could be directly uploaded to lintian.

debian.org, as it follows strictly the previous URL structure (I also added the manual of lintian as I also stumbled on links to it).

For now I hosted it on my server so you can see the result there:

<https://static.club1.fr/nicolas/lintian/>

For instance the link above translates to:

<https://static.club1.fr/nicolas/lintian/tags/superfluous-file-pattern.html>

And here are the sources:

<https://github.com/n-peugnet/lintian-ssg>

It is not meant to replace the corresponding UDD link, in fact I added a link to it in the page of each tag, to see all the affected packages. But I think it is better to first arrive on a very fast to load page that simply explains the tag, and then

be able to follow a link to see the list of affected packages.

Please telle me what you think about it and if you think it can be
uploaded to lintian.debian.org?

In the meantime I added some features and hosted it on its own domain to
make the custom 404 page work correctly: <https://lintian.club1.fr/>. So, do >> you think it could be used to make the lintian.debian.org website back up? >>
P.S. I'm not subscribed to this list, so please CC me.

Hi,

If there is interest in providing a page that only list the tag
description (without the affected packages), it would be easier to add
it to the existing UDD page (with an additional parameter for example)
than to create a separate service.

As I said, The reason I made this is because it was very frustrating to
click on links to lintian.debian.org as a newbie. Each time, I expected
to see more information about the tag to help me understand what it
exactly meant and how to fix it.
Currently these links lead to nowhere. I think this should be fixed as
it adds a lot of friction for newcomers.

You proposed to fix it by adding the description of the tag on UDD, but
I don't think this is an optimal solution.

1. The page is very slow to load, around 6 to 10 seconds. This is a
problem both for the user, and for the server that need to generate the
page dynamically.
2. The long list of affected packages it costly to render client side so
it is not very inclusive for people with low end devices.
3. The lists of affected packages is not helpful at all in the context
of clicking on a lintian.debian.org link, simply expecting to get more information on the tag.

For all these reasons I think a static website is a lot more suited than
a dynamic website. So I disagree that "it would be easier to add it to
the existing UDD page", as it is fundamentally a dynamic website.
Moreover, the static site generator is already done, it takes 3 seconds
to generate the whole static website (2.7 of them being lintian
execution itself).
Maybe what you meant by "easier" was "easier to maintain", and I think maintenance will indeed be very important. Currently, the generator is
under 1000 lines of Go code with a single dependency (outside of the
stdlib). I think it would be very easy for anyone to take over the
project if I become unable to maintain it.
And being a static site, it will be extremely easy to host and will
require almost no resources, so hosting maintenance will also be very low.

However I haven't seen any interest from DSA in setting a redirect from lintian.debian.org to somewhere else. As I wrote in #1042428, if
lintian.d.o was served by ullmann and managed by the uddadm group, I
would be willing to manage those redirects.

I don't suggest making any redirection of lintian.debian.org to
anywhere. What I am suggesting is uploading a static website back to lintian.debian.org itself, to fix all the existing broken links out there.
As I already said, the page of each tag includes a link to UDD for
people interested in the list of all affected packages.

Regards
--
Nicolas Peugnet

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/24 at 07:54 +0000, Bastien Roucari�s wrote:

Le vendredi 9 ao�t 2024, 06:39:04 UTC Lucas Nussbaum a �crit :

On 08/08/24 at 18:40 +0000, Bastien Roucari�s wrote:

It is not meant to replace the corresponding UDD link, in fact I added a link to it in the page of each tag, to see all the affected packages. But I think it is better to first arrive on a very fast to load page that simply explains the tag,

and then be able to follow a link to see the list of affected packages.

What will be wonderfull is to retrieve number of package affected and do a svg graph along time... Using a static script

Hi Bastien,

Are you aware of https://trends.debian.net/ ?

No but the same with every tag will be really really nice

The raw data used by trends.d.n is not publicly available (mainly
because it's a bit too large). By if you are interested in specific
tags, I can probably look into extending trends.d.n to cover those tags.

Note that trends.d.n works by running a given lintian version over all
packages (fetched from snapshot.d.o), not by running lintian on a
regular basis, because when lintian changes, the list of generated tags
also changes.

Lucas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/24 at 13:12 +0200, Nicolas Peugnet wrote:

You proposed to fix it by adding the description of the tag on UDD, but I don't think this is an optimal solution.

1. The page is very slow to load, around 6 to 10 seconds. This is a problem both for the user, and for the server that need to generate the page dynamically.
2. The long list of affected packages it costly to render client side so it is not very inclusive for people with low end devices.
3. The lists of affected packages is not helpful at all in the context of clicking on a lintian.debian.org link, simply expecting to get more information on the tag.

Note that the reason the page takes a long time to generate and load is
because of the listing of affected packages, so this isn't really 3
independant reasons.

For all these reasons I think a static website is a lot more suited than a dynamic website. So I disagree that "it would be easier to add it to the existing UDD page", as it is fundamentally a dynamic website. Moreover, the static site generator is already done, it takes 3 seconds to generate the whole static website (2.7 of them being lintian execution itself).
Maybe what you meant by "easier" was "easier to maintain", and I think maintenance will indeed be very important. Currently, the generator is under 1000 lines of Go code with a single dependency (outside of the stdlib). I think it would be very easy for anyone to take over the project if I become unable to maintain it.
And being a static site, it will be extremely easy to host and will require almost no resources, so hosting maintenance will also be very low.

However I haven't seen any interest from DSA in setting a redirect from lintian.debian.org to somewhere else. As I wrote in #1042428, if lintian.d.o was served by ullmann and managed by the uddadm group, I
would be willing to manage those redirects.

I don't suggest making any redirection of lintian.debian.org to anywhere. What I am suggesting is uploading a static website back to
lintian.debian.org itself, to fix all the existing broken links out there.
As I already said, the page of each tag includes a link to UDD for people interested in the list of all affected packages.

The crux of the issue is that there isn't sufficient interest from DSA
to provide something on https://lintian.debian.org, so I don't think
it's worth comparing the merits of UDD-based vs standalone or static vs
dynamic implementations.

Lucas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le vendredi 9 août 2024, 12:08:29 UTC Lucas Nussbaum a écrit :

On 09/08/24 at 07:54 +0000, Bastien Roucariès wrote:

Le vendredi 9 août 2024, 06:39:04 UTC Lucas Nussbaum a écrit :

On 08/08/24 at 18:40 +0000, Bastien Roucariès wrote:

It is not meant to replace the corresponding UDD link, in fact I added a link to it in the page of each tag, to see all the affected packages. But I think it is better to first arrive on a very fast to load page that simply explains the tag,

and then be able to follow a link to see the list of affected packages.

What will be wonderfull is to retrieve number of package affected and do a svg graph along time... Using a static script

Hi Bastien,

Are you aware of https://trends.debian.net/ ?

No but the same with every tag will be really really nice

The raw data used by trends.d.n is not publicly available (mainly
because it's a bit too large). By if you are interested in specific
tags, I can probably look into extending trends.d.n to cover those tags.

Yes

- source-is-missing
- source-include*

And all ftp reject tags

Note that trends.d.n works by running a given lintian version over all packages (fetched from snapshot.d.o), not by running lintian on a
regular basis, because when lintian changes, the list of generated tags
also changes.

We have here a mapping of renamed tag in a file in order to ease this kind of stuff.

If you could put vertical bar every lintian version change, it will give clue about breaking series

Bastien

Lucas

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAma2GKgACgkQADoaLapB CF8t7g//cO5NMgflP8rwai5/5RquWIpk53T/nmagjDxw1iXpk/IishA0u53xUjoV hL17aTR7hqcPNsXWWDS/vq6DGSHZJqx63mLSek+J+I49lZWAH85BZrYQjy5XrSpx s9JsMX9i2GHBrBCnrt6gZvTrmIJfBBruju9oLavro8Zy/Uv/QhSo57GTOnDT+w40 2ekTuWmczLiVrR+W7/hYuI5/DOEhCroxGgs5aS2lPIaLDwizk5NM+GWzxj5t40MI NRPEAKHLTaUKlLzNDeDRagxa7ttFYM+Emm8ysbZxGTZbxzLy8Xkj7ulXHKL0RfMq Wm8qmYXGO2bwUdfIsAkL2IoZyZSd9DhvxT4QXI+lMFNAgk7xL46ThVud068GvEm2 R7CICHD0GA6IUH0iL2jbAIUSwAA8WnG69/KGDfA5mM5t8AHBD/EvBkN8K1Qn1KtC 3z05HKq1FYKdQ+bO4Z+E5PLyWkhxfWdpnXZIdLmJ1Fic07BjaAcLThWavHBv7G6h 2eqt6Lmup8fOC918zCKxeMlfLue3Jh8wMAET0dcIbBXHVVJDptfKC7tswtk4aOlm CWG42Vm/RrQ/KD7YRBK+KNaKnoFvRmhLxt6bn35qDCPPDv5IZ3sGY/v8QGfjAPj4 3GuUJlMsMOW90y9BZbIi0/bGHVlcrNHrvZGgMTIQmB8tDQV6X2I=
=Kadi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

On Fri, 9 Aug 2024 at 04:12, Nicolas Peugnet <nicolas@club1.fr> wrote:

If there is interest in providing a page that only list the tag
description (without the affected packages), it would be easier to add
it to the existing UDD page (with an additional parameter for example)
than to create a separate service.

As I said, The reason I made this is because it was very frustrating to
click on links to lintian.debian.org as a newbie. Each time, I expected
to see more information about the tag to help me understand what it
exactly meant and how to fix it.
Currently these links lead to nowhere. I think this should be fixed as
it adds a lot of friction for newcomers.

+1 to this and the rest of Nicolas' message.

Additionally I wanted to raise that a lot of newcomers use search
engines to learn what the issues are. Also when discussing code
quality with upstream developers, they might be interested to learn
more, and when they enter in a search machine e.g. 'executable-in-usr-share-docbase' they will get zero relevant results.

When lintian.debian.org was running, it used to always be the top
result and an easy place to refer upstreams and newcomers to read up
on the issue.

Nicolas' implementation (https://lintian.club1.fr/) to list all tags
on one page and link to UDD seems like a reasonable compromise in
functionality and maintenance effort.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Aug 09, 2024 at 10:32:13PM -0700, Otto Kekäläinen wrote:

Nicolas' implementation (https://lintian.club1.fr/) to list all tags
on one page and link to UDD seems like a reasonable compromise in functionality and maintenance effort.

any DD can point lintian.debian.net to that machine (or anywhere else).


--
cheers,
Holger

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

There are no jobs on a dead planet. (Also many other things but people mostly seem to care about jobs.)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAma458MACgkQCRq4Vgaa qhxiFg/8DELAF++v85KKW+5WrvzcnCR1iTWQiROj4w+U4kpN+eBZOd6cEkxEoXBM 4YJlz6+8SDz02N1B6v5D6t3pb02ObfoKof0Z23RQlGlrns/SeehsZQ07eQ4pA4JA iiue+xTKDilwipPKKw+BNbo6a6QkDi+9WIg1GFyBdYzsbXhPR+O1La3ayLGnwME/ Zaw5ASYFZivlP6ywLPP6B+H9XhBxIhwKBD+o59qVtYOo/W9oXhHbkCO1CYgFBCJI 2MiR3OFv0KFua16hvuMzuQ10v4SkBznL4ajdTUz6wBQYaQ1aV0Qa+odRYrwoKgrT Gr73mST0tSaas/ygob2a2lQt/qmnI/I6+euSH/3BmVIL9EApbcyiTQEAU4gR4vlq Ctig/2jZMOR5SpAtyzhs6NiUSqt9zBLNrlIgLEFCe4y+vtHvikZjdoFXkc4dl58n uHaKlFKlfO+FXU8+QQulvNbx8+e7sDh39/NUiIbRqX7xkqvbFP62mujmvn1MGHnX fp6n3szs5RqWGh0bPM2k9BjEJozQFXeLlAF6hpXmCu40+zSYQBUIiJeoS8gxiOAK
mYnZjUSS

On 08/08/2024 8:40 PM, Bastien Roucariès wrote:

Le mercredi 7 août 2024, 17:05:01 UTC Nicolas Peugnet a écrit :

Hi all,

Pierre-Elliott Bécue <peb@debian.org> on Wed, 27 Sep 2023 14:19:20:

Otto Kekäläinen <otto@debian.org> wrote on 27/09/2023 at 06:35:07+0200: >>>

Hi!

Thanks for the context - so there is no need technical incompatibility >>>> at play, but mostly a matter of having resources and time to do it.
..

Regarding the 301 redirection I'll see with the interested parties (DSA >>>>> and Lintian maintainers) if this option is fine with everyone.

I could easily write Ansible code to maintain a simple Nginx server,
with 302 redirects https://lintian.debian.org/tags/(.*)/?$ ->
https://udd.debian.org/lintian-tag.cgi?tag=$1, use same Ansible style
as salsa.debian.org is maintained on
(https://salsa.debian.org/salsa/salsa-ansible), and also donate a tiny >>>> virtual machine for Debian project if needed. Is there some special
bureaucracy on top of that work to do to be able to contribute with
this?

Don't worry, the server still exists, it's just down, and reputting the
DNS takes little to no time.

Regarding apache config, I'm fine with doing it. It's a matter of
checking with everyone that we want to do that as the plan was nuking
the server from orbit.

Providing debian.org infrastructure requires to be a member of the
Debian System Administrators (DSA) team, which in turn requires to be a
Debian Developer, so, sadly, you can't really help on that part.

That being said, thank you for offering your time.

I sent the following email in reply to Bug#1042428 but I didn't see it
was archived, so I repost it here:

As I just recently started making Debian packages, I clicked multiple times on links to <https://lintian.debian.org> that led me to a dead end, for instance from mentors.debian.org, or on the hyperlinks that lintian itself produce in the terminal

output. It was not a very pleasant experience, especially for a newbie.

In my opinion, redirecting lintian.debian.org to the UDD links posted above is not a good option, because as I understand it, they only were intended to show the extended explanation for each tag. Having the list of all the affected packages in this

page it not helpful, and it makes the pages very slow to load (and to produce). >>>

So instead I thought that it would be quite easy to generate a static website that would be very fast to generate once, and then to serve and load. So I made my own implementation that generates a website that could be directly uploaded to lintian.

debian.org, as it follows strictly the previous URL structure (I also added the manual of lintian as I also stumbled on links to it).

For now I hosted it on my server so you can see the result there:

<https://static.club1.fr/nicolas/lintian/>

For instance the link above translates to:

<https://static.club1.fr/nicolas/lintian/tags/superfluous-file-pattern.html>

And here are the sources:

<https://github.com/n-peugnet/lintian-ssg>

It is not meant to replace the corresponding UDD link, in fact I added a link to it in the page of each tag, to see all the affected packages. But I think it is better to first arrive on a very fast to load page that simply explains the tag, and then

be able to follow a link to see the list of affected packages.

What will be wonderfull is to retrieve number of package affected and do a svg graph along time... Using a static script

nicolas did you contact the the infrasture team ?

Not yet, I wanted to request feedback on my proposal beforehand.
I just added debian-admin@lists.debian.org in CC, I hope it was the
right thing to do.

Please telle me what you think about it and if you think it can be uploaded to lintian.debian.org?

In the meantime I added some features and hosted it on its own domain to
make the custom 404 page work correctly: <https://lintian.club1.fr/>.
So, do you think it could be used to make the lintian.debian.org website
back up?

P.S. I'm not subscribed to this list, so please CC me.

Regards

--
Nicolas Peugnet

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-09-02 07:27, Louis-Philippe Véronneau wrote:

Apparently I'm a Lintian maintainer now. I had a quick look at Lintian and lintian.debian.org is referenced in multiple places.

I feel quite happy on reading this and seeing that you also just did a
lintian release to unstable.
Thank you, thank you, thank you! :)

Greetings,
Nilesh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 02/09/2024 03:57, Louis-Philippe Véronneau wrote:

Thanks for the work you did trying to fix this issue.

Apparently I'm a Lintian maintainer now. I had a quick look at Lintian
and lintian.debian.org is referenced in multiple places.

It seems like actually fixing lintian.debian.org will be faster and more productive than going wack-a-mole and trying to retcon it ever existing.

IF I were to do the job of getting DSA to spin a VM and point lintian.debian.org to it, I'd have to be confident you'll be maintaining
the code you wrote in the future.

Please be honest :) I don't mind it at all if you tell me: "yeah, that
was only a proof of concep", or "I'm motivated now, but I don't know if
I'll still be in 3 years".

I definitely built it with maintenance in mind. I am willing to maintain
this code for as long as possible, but I cannot guarantee that I will be
able to do it forever!
I will be responsive if contacted by email or if an issue is created on
the GitHub repository.

I also took the time to setup a CI with most of the code properly
tested. This should allow to minimize future breakages when modifying
the code.

If you aren't interested in maintaining that codebase for the next few
years, I'll just steal some of your templates and rewrite everything in Python :P

One problem I forsee is that if that machine is hosted by DSA, we won't
be able to call lintian directly, as everything will need to be
installed from Debian packages and that machine will be running Debian Stable.

A way to fix this issue would be to point the static generator to a
.json file instead.

Yes this would only imply very minor changes to the program. The
question now would be where should be this file located and how/when/by
whom would it be updated?

Another option I imagined would be to generate the website on another machine/VM that would run on testing/unstable and then rsync it to the production machine (which is what I am currently doing).

Anyways, don't hesitate to contact me if you have other specific needs
to simplify the deployment of this website.

Thank you for your interest and time.
--
Nicolas Peugnet

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

Thank you, Nicolas and Luis-Philippe, stepping up here is highly
appreciated and will benefit a large amount of Debian packagers and
their collaborators.

Please be honest :) I don't mind it at all if you tell me: "yeah, that
was only a proof of concep", or "I'm motivated now, but I don't know if I'll still be in 3 years".

I definitely built it with maintenance in mind. I am willing to maintain
this code for as long as possible, but I cannot guarantee that I will be
able to do it forever!
I will be responsive if contacted by email or if an issue is created on
the GitHub repository.

I also took the time to setup a CI with most of the code properly
tested. This should allow to minimize future breakages when modifying
the code.

I am happy to help with writing a GitLab CI pipeline and do occasional
code reviews, if you want to consider hosting the code at https://salsa.debian.org/lintian, Debian's official code hosting and collaboration platform. It can be instead of or in parallel with your
GitHub repository.

- Otto

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

--190f962ad9eb5c0f16e4719a72d9b4e0c428903ed43a1013b2a39cf4e044 Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

hello,

On Mon Sep 2, 2024 at 7:19 PM CEST, Otto Kekäläinen wrote:
[..]

I am happy to help with writing a GitLab CI pipeline and do occasional
code reviews, if you want to consider hosting the code at https://salsa.debian.org/lintian, Debian's official code hosting and collaboration platform. It can be instead of or in parallel with your
GitHub repository.

for what it's worth, I'd also be happy to help with code reviews, in salsa (or patches over email, but not over github)

serafi

--190f962ad9eb5c0f16e4719a72d9b4e0c428903ed43a1013b2a39cf4e044
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEA2RWqo7IwLCLSFYbT59tVQ7WEioFAmbWDucACgkQT59tVQ7W EiqJgRAAwiKW5jGFuTEaHpsamkhd4EsA095IjGY3cxXiQWkgeUP+WjWJJq805dPL gnIuZh4p3gBj6cQS8F99GYOy4F5t+UHyVIvvuNIQG7TpF6ZlNx78WJOjJ/MhUGeK 3sV5Mx3g6q3umrbW5f3FxUsl+nTsXLnydGONOUUD4LzEv3jG8yFnAxajkX/3sP/F CXRzPwIZlUECMv+42WAzQxJIuDZGTsCK5JKBhpAu/Gv1lYTauawNsN32qUgHyZdb ij/lha0q1RXUcXVnt9alAxAwCOHxmHCmNc2vo5ffNWWcUBup/IiRJVGdXghU6NGb w+IglVFNGDv2fDCBpgo0x/OiRDXnmqD2XEumsUy63xoxiwHG/xiBaGmU0botst8Q V+xi83ypTNh/7iwnDwPb484arFVKae1woZ1ouefaPpTNNBZGXI7t5peFCw1lSSGc eeorsKMaZcN2U3XRj8j/HREi1KtMsghR07zaIR+tI/67wkKG7NTyQ/07Xek+VLjL +E0FaOLmi7ReQxIjVi3+uJenzTZlGTALnyj/ypQNkmMb/9WGBnCQMPKmpl7o6aSJ KT2HdFEdFq31+XIdSgxT6vXFEiGB7m07xM8RBmQyualdUr078x0iL7ujPUZj9/2t Z0mZkS8GfNL8MNc9XY1b8tUk5ts7zWRy1ltKQIg44Z1Mv8pCcwc=RGT3
-----END PGP SIGNATURE-----

--190f962ad9eb5c0f16e4719a72d9b4e0c428903ed43a1013b2a39cf4e044--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-09-02 10:45, Nicolas Peugnet wrote:

Hi,

On 02/09/2024 03:57, Louis-Philippe Véronneau wrote:

Thanks for the work you did trying to fix this issue.

Apparently I'm a Lintian maintainer now. I had a quick look at Lintian
and lintian.debian.org is referenced in multiple places.

It seems like actually fixing lintian.debian.org will be faster and
more productive than going wack-a-mole and trying to retcon it ever
existing.

IF I were to do the job of getting DSA to spin a VM and point
lintian.debian.org to it, I'd have to be confident you'll be
maintaining the code you wrote in the future.

Please be honest :) I don't mind it at all if you tell me: "yeah, that
was only a proof of concep", or "I'm motivated now, but I don't know
if I'll still be in 3 years".

I definitely built it with maintenance in mind. I am willing to maintain
this code for as long as possible, but I cannot guarantee that I will be
able to do it forever!
I will be responsive if contacted by email or if an issue is created on
the GitHub repository

I also took the time to setup a CI with most of the code properly
tested. This should allow to minimize future breakages when modifying
the code.

Great news! As proposed by Otto, one thing we could do would be to move
the codebase to https://salsa.debian.org/lintian/lintian-ssg

If you're OK with this, I'll create an empty project and give you
permissions on it.

If you aren't interested in maintaining that codebase for the next few
years, I'll just steal some of your templates and rewrite everything
in Python :P

One problem I forsee is that if that machine is hosted by DSA, we
won't be able to call lintian directly, as everything will need to be
installed from Debian packages and that machine will be running Debian
Stable.

A way to fix this issue would be to point the static generator to
a .json file instead.

Yes this would only imply very minor changes to the program. The
question now would be where should be this file located and how/when/by
whom would it be updated?

Another option I imagined would be to generate the website on another machine/VM that would run on testing/unstable and then rsync it to the production machine (which is what I am currently doing).

Anyways, don't hesitate to contact me if you have other specific needs
to simplify the deployment of this website.

Thank you for your interest and time.

I have a few other ideas, but I'll wait to see what issue tracker you
want to keep :)

FYI, I opened an RT ticket asking DSA for a VM to host all of this.

Cheers,

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org
⠈⠳⣄

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/09/2024 18:31, Louis-Philippe Véronneau wrote:

On 2024-09-02 10:45, Nicolas Peugnet wrote:

Hi,

On 02/09/2024 03:57, Louis-Philippe Véronneau wrote:

Thanks for the work you did trying to fix this issue.

Apparently I'm a Lintian maintainer now. I had a quick look at
Lintian and lintian.debian.org is referenced in multiple places.

It seems like actually fixing lintian.debian.org will be faster and
more productive than going wack-a-mole and trying to retcon it ever
existing.

IF I were to do the job of getting DSA to spin a VM and point
lintian.debian.org to it, I'd have to be confident you'll be
maintaining the code you wrote in the future.

Please be honest :) I don't mind it at all if you tell me: "yeah,
that was only a proof of concep", or "I'm motivated now, but I don't
know if I'll still be in 3 years".

I definitely built it with maintenance in mind. I am willing to
maintain this code for as long as possible, but I cannot guarantee
that I will be able to do it forever!
I will be responsive if contacted by email or if an issue is created
on the GitHub repository

I also took the time to setup a CI with most of the code properly
tested. This should allow to minimize future breakages when modifying
the code.

Great news! As proposed by Otto, one thing we could do would be to move
the codebase to https://salsa.debian.org/lintian/lintian-ssg

If you're OK with this, I'll create an empty project and give you
permissions on it.

I'm Ok with this, my username on salsa is @n-peugnet.

If you aren't interested in maintaining that codebase for the next
few years, I'll just steal some of your templates and rewrite
everything in Python :P

One problem I forsee is that if that machine is hosted by DSA, we
won't be able to call lintian directly, as everything will need to be
installed from Debian packages and that machine will be running
Debian Stable.

A way to fix this issue would be to point the static generator to a
.json file instead.

Yes this would only imply very minor changes to the program. The
question now would be where should be this file located and
how/when/by whom would it be updated?

Another option I imagined would be to generate the website on another
machine/VM that would run on testing/unstable and then rsync it to the
production machine (which is what I am currently doing).

Anyways, don't hesitate to contact me if you have other specific needs
to simplify the deployment of this website.

Thank you for your interest and time.

I have a few other ideas, but I'll wait to see what issue tracker you
want to keep :)

I am also OK with using the issue tracker of salsa.

FYI, I opened an RT ticket asking DSA for a VM to host all of this.

Thank you very much for this!
--
Nicolas Peugnet

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/09/24 at 12:31 -0400, Louis-Philippe V�ronneau wrote:

FYI, I opened an RT ticket asking DSA for a VM to host all of this.

Hi,

I still don't understand the long term strategy here.

UDD provides the same information. I recently did the work so that it is properly indexed by search engines, see for example https://www.google.com/search?q=archive-liberty-mismatch
(it will probably take some time to get indexed by other search engines)

What is the point in duplicating efforts?

Lucas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/09/24 at 20:49 +0200, Fabio Fantoni wrote:

Il 03/09/2024 20:05, Lucas Nussbaum ha scritto:

On 03/09/24 at 12:31 -0400, Louis-Philippe V�ronneau wrote:

FYI, I opened an RT ticket asking DSA for a VM to host all of this.

Hi,

I still don't understand the long term strategy here.

UDD provides the same information. I recently did the work so that it is properly indexed by search engines, see for example https://www.google.com/search?q=archive-liberty-mismatch
(it will probably take some time to get indexed by other search engines)

What is the point in duplicating efforts?

Lucas

I don't see UDD in the result of the link above but https://lintian.club1.fr/tags/archive-liberty-mismatch.html as first result.

It's probably a matter of cache/propagation.

I saw lintian.club1.fr result also in other tags I searched recently but I never saw UDD if I remember good

As I said I fixed indexation recently (previously it was disallowed in robots.txt).

Lucas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/09/2024 8:05 PM, Lucas Nussbaum wrote:

On 03/09/24 at 12:31 -0400, Louis-Philippe Véronneau wrote:

FYI, I opened an RT ticket asking DSA for a VM to host all of this.

Hi,

I still don't understand the long term strategy here.

UDD provides the same information. I recently did the work so that it is properly indexed by search engines, see for example https://www.google.com/search?q=archive-liberty-mismatch
(it will probably take some time to get indexed by other search engines)

What is the point in duplicating efforts?

I simply don't think they serve the same purpose. UDD lists the affected packages, which could be interested to some, but not to the persons that
follow (currently broken) links to lintian.debian.org, as these links
are present where one just want to see the explanation of the tag
(mostly mentors.debian.org and lintian's CLI output).

IMO it is a lot more interesting to arrive on a simple and lightweight
page that simply show the explanation.

The reasons I made another program was that:

1. Seeing that nothing was done for almost 1 year to fix this problem, I thought it was not going to be fixed anytime soon, and I didn't want to
just complain about it, so I decided to make it myself
2. I don't know anything about ruby or perl, so I was not going to
contribute to UDD
3. As the scope is a lot more contrained, it could be a Static Site
Generator to make the pages fast to load

I see that by proposing something I motivated you to update UDD, this is
good, but I still think it is interesting to leave them as separated
projects. UDD is more appropriated to display statistics about affected packages, liantian.debian.org could then be a lightweight front page
that simply shows the explanation.

Also I still think my proposition has advantages over the current state
of the UDD tag pages. For example, I made sure that the URLs of the
generated website match the existing links to lintian.debian.org and
pages for renamed tags are generated to make sure old links are still
valid. I added proper markup rendering of the explanation and a
Debianish theme. And finally I added Lintian's manual (as there are
links to that as well).

You could of course implement all that in UDD, but I am proposing a
solution that is already done. Where would be the duplication of efforts
then?
--
Nicolas Peugnet

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-09-03 14:05, Lucas Nussbaum wrote:

On 03/09/24 at 12:31 -0400, Louis-Philippe Véronneau wrote:

FYI, I opened an RT ticket asking DSA for a VM to host all of this.

Hi,

I still don't understand the long term strategy here.

UDD provides the same information. I recently did the work so that it is properly indexed by search engines, see for example https://www.google.com/search?q=archive-liberty-mismatch
(it will probably take some time to get indexed by other search engines)

What is the point in duplicating efforts?

Lucas

I took for granted that when you said DSA wasn't interested in pointing lintian.debian.org to something else you meant they wanted a replacement
for lintian.debian.org.

I really, really like UDD and I use it all the time, but I feel there is
still some value in having a very lightweight, static website that
explains all the tags.

The current implementation also provides the lintian man page, but could
be extended to have an FAQ. I don't think it would be the role of UDD to
host that kind of info.

Lintian tags on UDD are much more snappy since you've added the 5000
results limit (I like the improved loading time, but I'm afraid it
removes a convenient way to access the data, but that's another debate),
but for tags with a lot of results, it's still a pretty large page.

For example, uses-deprecated-python-stdlib is a 2.31MB page, because of
the large number of results. In comparison, the lintian-ssg result
(which also points to UDD) is 69KB.

The whole SEO thing isn't my cup of tea, I don't really want to debate
that. SEO whatever :P

In the end, I don't care about this enough to wage a war or to hurt
anyone's feelings. I want to help solving issues with Lintian; this
looked like one. If you disagree or really want lintian.debian.org to be pointed at UDD, I'll be happy to assist.

Cheers,

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org
⠈⠳⣄

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

Thanks both Lucas and Nicolas for your contributions to Debian.

Can we agree to have both UDD and lintian.debian.org, as the work to
develop the required systems already happened?

I think both websites have their benefits. Having a lintian.debian.org
site with links to man pages and additional information caters well to
the newbie packager or occasional package collaborator. The
lintian.debian.org page can link to the equivalent UDD page, and the
UDD page and continue to list all affected packages.

Debian should be a place open for collaboration, and we should welcome contributions, in particular in this case as it is a legit and working implementation to produce renewed contents for lintian.debian.org.

- Otto

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: lucas@debian.org (Lucas Nussbaum)

On Tuesday, September 3, 2024 11:21:04 PM MST Lucas Nussbaum wrote:

After lintian.debian.org went unmaintained (beginning of 2022) and it
was clear noone was going to adopt it, I worked on a UDD-backed
replacement (in July 2022, see https://lists.debian.org/debian-qa/2022/07/msg00001.html and https://lists.debian.org/debian-qa/2022/07/msg00006.html ). Then I
raised the question of the future of lintian.debian.org.

After providing stale data for a long time, which confused many people, lintian.debian.org was shutdown in September 2023.

Pointing it to UDD was discussed (I think I proposed serving the
lintian.d.o vhost on ullmann.debian.org so that the old URLs would work
but be backed by UDD). Another option that was mentioned was pointing it
to a wiki page that explains where to find the data (I wrote https://wiki.debian.org/UltimateDebianDatabase/ReplacingLintianDebianOrg
at some point). But those discussions never reached a conclusion.

Thanks for all the work you have put into this.

Also, I don't want to sound like I'm telling someone how to contribute
to Debian, but it looks to me like there are more urgent issues to solve around lintian...

I don’t really have a strong opinion as to which software serves these pages,
but I do think solving this issue is one of the more important things we can do for lintian (especially because it is so easy to resolve compared to some of the other things that need to be done).

I personally spent a lot of time as an early packager trying to figure out what
some of the lintian tags meant because internet searches turned up dead links.
I ended up resorting to grepping through the lintian source code to find the answers (efficient once you know how to do it, but it shouldn’t be that hard to
approach as a new maintainer). In my work mentoring new maintainers, I find that they also run into a lot of confusion that would be easily resolved if the links on mentors.debian.net just pointed them in the right direction.

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmbX/o8ACgkQwufLJ66w tgPQ/Q/+PvSVG9oG9LlZlQF/m+Anc7yuDtq5Ibm5U+pG5gmOa4zLYOzlZEjiLkQI HkkktwG1WCG/ToAqN9Myyq5S1+WzdIo1BhKDpbz6oE3P7aaYd2QFuRoV45wNsFeO IuTYRjwxBgHzYZYvwzIKhhwCHCXO9f+YnFgPaSWFWqByDLY6RJenM5Yyi7dpmK09 pYhX96pFNTwzRkH5yPzpxrlqUBspjuoe8+GW+ACywLhm4bF7wKt9mR/MlWhY9Kt/ GaessLJbT3Hop9Pduar8nnYKw5FoXGpNMx7F6xn0BH2aWT7mGswdAnodDGZmAkwR 4obLAwr4QUUQPnH6PMSDvyRaPaoEhNwEX8lg4SO+wEuCxfH3IQgY7XLYyXdD5l7Y 9ZrAVOIv2MjTYD3j4kBl78smWQc45WzHfKGCG2fI1y4AucLcQPSeMObGEvoJKZYW QeGdtdyKTT6ye9sB0MocvIGjbI3FyUTtNni2e3idFOylC4UiZ8rqx2W7w7Q6U4G5 a5YG4meNIDS2YuR9i75U2WlM+b5JpmCDA/rwvR0m0LjH1hRbmLMJq4NNHPeUpM0c /WQVtJ0lVS4Hgw+ZTJ1y7qMQNj+8FWxvsIhTDz+aGStt6UOruJRaC9CTU125/8Gw kiZPtviGH5Cg7zfBRV0X/kU3uDv3AyHFJTkGjMENEcRQ8MUtQc8=
=eehs
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/09/24 at 16:56 -0400, Louis-Philippe V�ronneau wrote:

On 2024-09-03 14:05, Lucas Nussbaum wrote:

On 03/09/24 at 12:31 -0400, Louis-Philippe V�ronneau wrote:

FYI, I opened an RT ticket asking DSA for a VM to host all of this.

Hi,

I still don't understand the long term strategy here.

UDD provides the same information. I recently did the work so that it is properly indexed by search engines, see for example https://www.google.com/search?q=archive-liberty-mismatch
(it will probably take some time to get indexed by other search engines)

What is the point in duplicating efforts?

Lucas

I took for granted that when you said DSA wasn't interested in pointing lintian.debian.org to something else you meant they wanted a replacement for lintian.debian.org.

After lintian.debian.org went unmaintained (beginning of 2022) and it
was clear noone was going to adopt it, I worked on a UDD-backed
replacement (in July 2022, see https://lists.debian.org/debian-qa/2022/07/msg00001.html and https://lists.debian.org/debian-qa/2022/07/msg00006.html ). Then I
raised the question of the future of lintian.debian.org.

After providing stale data for a long time, which confused many people, lintian.debian.org was shutdown in September 2023.

Pointing it to UDD was discussed (I think I proposed serving the
lintian.d.o vhost on ullmann.debian.org so that the old URLs would work
but be backed by UDD). Another option that was mentioned was pointing it
to a wiki page that explains where to find the data (I wrote https://wiki.debian.org/UltimateDebianDatabase/ReplacingLintianDebianOrg
at some point). But those discussions never reached a conclusion.

At this point, I think it's too late: it would have been useful to
replace lintian.debian.org, preserving URLs, with something else when it
was shut down, but now all the links have have been updated, so I don't
see the point anymore.

I really, really like UDD and I use it all the time, but I feel there is still some value in having a very lightweight, static website that explains all the tags.

The current implementation also provides the lintian man page, but could be extended to have an FAQ. I don't think it would be the role of UDD to host that kind of info.

Lintian tags on UDD are much more snappy since you've added the 5000 results limit (I like the improved loading time, but I'm afraid it removes a convenient way to access the data, but that's another debate), but for tags with a lot of results, it's still a pretty large page.

For example, uses-deprecated-python-stdlib is a 2.31MB page, because of the large number of results. In comparison, the lintian-ssg result (which also points to UDD) is 69KB.

I don't think load times or page size are a big issue here, but since
this has been raised multiple times, I changed the page to not list
affected packages by default.

The whole SEO thing isn't my cup of tea, I don't really want to debate that. SEO whatever :P

In the end, I don't care about this enough to wage a war or to hurt anyone's feelings. I want to help solving issues with Lintian; this looked like one. If you disagree or really want lintian.debian.org to be pointed at UDD, I'll be happy to assist.

I'm fine with whatever DSA decides on this topic. I'm just puzzled with
the smell of duplication of efforts here.

Also, I don't want to sound like I'm telling someone how to contribute
to Debian, but it looks to me like there are more urgent issues to solve
around lintian...

Lucas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Sep 04, 2024 at 08:21:04AM +0200, Lucas Nussbaum wrote:

After lintian.debian.org went unmaintained (beginning of 2022)

[...]

After providing stale data for a long time, which confused many people, lintian.debian.org was shutdown in September 2023.

in Debian timeframes, this is basically yesterday and the day before.

At this point, I think it's too late: [...]

I disagree: lintian.debian.org was around for more than a decade, so it's
still in the minds (and finger memory) of many.

On Wed, Sep 04, 2024 at 12:07:39AM -0700, Otto Kekäläinen wrote:

Can we agree to have both UDD and lintian.debian.org, as the work to
develop the required systems already happened?

I think both websites have their benefits. Having a lintian.debian.org
site with links to man pages and additional information caters well to
the newbie packager or occasional package collaborator. The lintian.debian.org page can link to the equivalent UDD page, and the
UDD page and continue to list all affected packages.

I very much agree with Otto here.

& many thanks to everyone who contribut(s|d) to lintian!


--
cheers,
Holger

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

The moon landing 50 years ago was paid by taxes, while Bezos space trip was paid by not paying taxes.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmbYDZ0ACgkQCRq4Vgaa qhyz0BAAm0FLSapg7NXYns2PN5DapgsQz5mGDhEnGAw5x46PI/jCfTxG5VwhJO71 q2zxvaLaZKXaH3iv3lcTYgLuj3/w4L0W3+A4/EvZMPYrox5lM7jt1yt6J0OMhv+c 9+LGijRnFhRWyv2OOyPZjrDhSIqGTGq6wrmrXpmG3v5zMRM7KJ7GV7TtVMNuFV/q 1lgL4dsyI/dSEN0Krzn+2pVUjOTaXHEcek1IM9+5GhZkSMOweeU14QT2tOC1ouuK SGlR9YWsnAnEvITPTfqJnUAv//VjfIBtUrnb4pDZjeFozQiGpK/iAikpSJbmXj/m wH6NBPrdOZ3bLcGLz2o7Bl4o5pl4R4izUnMnbpB7ySwFviuGsxIde86qvv17n0Jh s9vevDIir/AnEV/wRhO3hIHoHdjWOMbwnaVeYxBYzvujawFFtKPAoD0n1cWHnGwO 1PuX/SpZo77Go8pDsCan5lqrbj7Th+Twk6haIldytfQ5rb2xuME5IpGUs9a+KE7+ fjZmGayyV7T9yG9aSFjdsYEBFmL/rv/OFpwv1e3rOwvpWoK3SERlMuAu7FqU+4mX
uY3bF74kuB

--064e42fa7d6a4c7015329a943dce8d512494c751af91ca5312b57eb896be Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

On Wed Sep 4, 2024 at 8:21 AM CEST, Lucas Nussbaum wrote:
[..]

Also, I don't want to sound like I'm telling someone how to contribute
to Debian, but it looks to me like there are more urgent issues to solve around lintian...

lintian's in perl and Nicolas already pointed out that he's not familiar with it. incidentally, lots of Debian native code is in perl, and like it or not, we should allow for, or even encourage [0] (partial) rewrites if we want to attract
new contributors, especially below the average DD age

[0] see slide 6 of https://raw.githubusercontent.com/samueloph/personal_website_files/main/slides/samueloph_slides_2024_08_i_use_debian_btw.pdf

--064e42fa7d6a4c7015329a943dce8d512494c751af91ca5312b57eb896be
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEA2RWqo7IwLCLSFYbT59tVQ7WEioFAmbYtgQACgkQT59tVQ7W Eip9ehAAn0tJzpZwOOqKzRvS0QlExMO0itpqz3z6Zt8XHz+L2ybDElNN8AXhpjKE Zl493e4cfDyuFyNBCO1MQsZ/swExa57kw26V0VceaMndOrDsAoXqrxlQ29TsqTJl lQRlFWwD4aZ+ZcXiY4ThHIinZwCGD0o+xYZJ7Ovdv1YHoVhXpAJHM+nIKiHys0/C aB8PWxgZTqHqz0qCgoyJVq05NEX7ctuLws7T9qk7jNcsfVBJN23pRzd2a6JomU4I F/lQLY8Bk4aVo6hX1RoClFVwcuGxETvsV3zeqOisETutu+J8ztJMicw4kk64iOM1 VoRVTZDVqPjqBvnZQhOtQnV3xOG8NjEfcN0sqtFf0boQsu6b3gE13vJiRJ//M0bg eYl5bvKjA5UDMdV0IQK2zBrxwb5jJgcGbl/r1/37jHX4MDA6yaYW+xaOG4mgWuaD bUzBZvMIEVczuzduD6iVquTiiRdvEwbJZAHpVgL44yrZABOKsfVEZoCRe4535f4c GlplDLDx7wvos5TqHVuWXIHOQjIr1+kFI8ZrUPYzKUMG/IzWZ2dpHyzpkVHojWuF M23vvtg2ypTXpC5CGaYKyzHVw0k3/pCMY9xRqKX28gb3I6zjSa1yxKLEwjjKJLD0 qQbKryEKZSGm8QNyiTPrh1SXFzV4UR3+7dlKTmfslFGo5d4B2wg=dQB5
-----END PGP SIGNATURE-----

--064e42fa7d6a4c7015329a943dce8d512494c751af91ca5312b57eb896be--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Holger Levsen <holger@layer-acht.org> wrote on 04/09/2024 at 09:34:53+0200:

On Wed, Sep 04, 2024 at 08:21:04AM +0200, Lucas Nussbaum wrote:

After lintian.debian.org went unmaintained (beginning of 2022)

[...]

After providing stale data for a long time, which confused many people,
lintian.debian.org was shutdown in September 2023.

in Debian timeframes, this is basically yesterday and the day before.

At this point, I think it's too late: [...]

I disagree: lintian.debian.org was around for more than a decade, so it's still in the minds (and finger memory) of many.

On Wed, Sep 04, 2024 at 12:07:39AM -0700, Otto Kekäläinen wrote:

Can we agree to have both UDD and lintian.debian.org, as the work to
develop the required systems already happened?

I think both websites have their benefits. Having a lintian.debian.org
site with links to man pages and additional information caters well to
the newbie packager or occasional package collaborator. The
lintian.debian.org page can link to the equivalent UDD page, and the
UDD page and continue to list all affected packages.

I very much agree with Otto here.

& many thanks to everyone who contribut(s|d) to lintian!

To be honest, I view respawning lintian.d.o as a waste of time.

But, and I'm already regretting this, I'm okay respawning a VM anyway,
*after* we've handled our ganeti cluster migration, if none of my DSA
teammates have a strong objection.

I'm okay putting an apache2 config and a static website based on
Nicolas' (I think it was him?) work.

BUT: I need at least two DDs committing to maintain the info up-to-date
as I do not intend to do it.

If the data becomes more than six months old, I'd consider this a good
argument in favour of wiping the VM and getting rid of lintian.d.o for
good.

Otherwise, I'm also okay adding a CNAME from lintian.d.o to a web
redirector that points to the wiki page Lucas provided.

Bests,
--
PEB

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEE5CQeth7uIW7ehIz87iFbn7jEWwsFAmbYyTUPHHBlYkBkZWJp YW4ub3JnAAoJEO4hW5+4xFsLKpkQAL/ZL7oqTvxJm0xrPs2TlH5FeNmxBOb6x6m6 zRe89FGo5xwu5B7EBIYkZ2sEp6o6zKgg0DZTV9GJWZNmLR6CHd1jha7VS+l2HsSi e2zpPEzzsyh+wvz2rk4VF+HQzQArM1Rjd4HbeP188VlooEjNBzcg3gJNWVNNl2eK XX0I7aH1ug97JEHnKvPa625Z0X+A+nSeexYCl1KWhVPd3jq5V44jMpjnXLHYX+VO Ss2AuO2cAj0xbFluiqzy0r6kfMXPw69K7fehbHFgwlbFdyYNPNukXki7FvFjnBre 33u3iyvfIma4n5u+yCTUIXskfb7lFgl7WSg3CymNMsaAAYoFFclmr8LpFvuxiLLh iSatsZo/xrGo4+pQ6iC4ecfOQrkpX9JRnAnylsorwXu+xnvk0JDbp4D4BvdRZ96/ qUcvJZVH5i0KEcBgVARgXnRf1TE6XPehtBPiE79vFzqXz1MKzaiVdnn3TYme/MRK pvTkVcUXlE61bpdEtxML2QYKL2YeUEbvR5MoZqQBJ1aQjmEfpJ1+5YMQXXO70Y1G zMNbDdG7dp6riId0D+DsJYlkPkk+0ItDxFwtPzVUERt6a4QqFh1N/65wq+b8P51e lk6aDT8/QR0X0IvzuCDlc+AQb++iTt9PEJeRHMLl/8TnnQSz0KoKAGFBn+ygw4ez
VlfzHkLP
=kvWF
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Soren Stoutner <soren@debian.org> wrote on 04/09/2024 at 08:30:39+0200:

On Tuesday, September 3, 2024 11:21:04 PM MST Lucas Nussbaum wrote:

After lintian.debian.org went unmaintained (beginning of 2022) and it
was clear noone was going to adopt it, I worked on a UDD-backed
replacement (in July 2022, see
https://lists.debian.org/debian-qa/2022/07/msg00001.html and
https://lists.debian.org/debian-qa/2022/07/msg00006.html ). Then I
raised the question of the future of lintian.debian.org.

After providing stale data for a long time, which confused many people,
lintian.debian.org was shutdown in September 2023.

Pointing it to UDD was discussed (I think I proposed serving the
lintian.d.o vhost on ullmann.debian.org so that the old URLs would work
but be backed by UDD). Another option that was mentioned was pointing it
to a wiki page that explains where to find the data (I wrote
https://wiki.debian.org/UltimateDebianDatabase/ReplacingLintianDebianOrg
at some point). But those discussions never reached a conclusion.

Thanks for all the work you have put into this.

Also, I don't want to sound like I'm telling someone how to contribute
to Debian, but it looks to me like there are more urgent issues to solve
around lintian...

I don’t really have a strong opinion as to which software serves these pages,
but I do think solving this issue is one of the more important things we can do for lintian (especially because it is so easy to resolve compared to some of the other things that need to be done).

I personally spent a lot of time as an early packager trying to figure out what
some of the lintian tags meant because internet searches turned up dead links.
I ended up resorting to grepping through the lintian source code to find the answers (efficient once you know how to do it, but it shouldn’t be that hard to
approach as a new maintainer).

The binary package lintian provides lintian-explain-tags which is a
great resource to get such information.

In my work mentoring new maintainers, I find that they also run into a
lot of confusion that would be easily resolved if the links on mentors.debian.net just pointed them in the right direction.

Then it's probably what needs to be addressed.

--
PEB

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEE5CQeth7uIW7ehIz87iFbn7jEWwsFAmbYx0kPHHBlYkBkZWJp YW4ub3JnAAoJEO4hW5+4xFsLHxEQAJOvplpSZYgergOgIT5e7yQwXUNO5Mjsz61r OXBNPWDQYJYG5/5IOC3nEM0T9tB/Vn299xxQe0YsGCZDohLOHRimnaZlywhKHbZQ gX2C5rpEM607rrAKStFcHfCPCFNEvQAY8UOSHu3Ncy4DsTJBJUEpnnh1/sBFmRuQ CqS/VrTmp6fTbNJml3k2tUyIm/rJ+vNrw0rZzyjPpXyApdnhbbX8q2fqTYWX6zaz UrU/XoQoxKyksu0qBz8JXcCgtWgI2irOEoZKpulaX5KzXcft3pM8wSpMkh7d0Rem MmGpINOxNEhJA6KOUSFDtf8Ch7nxNC/JZXGWD3fjpshUpCG2ptfR/9/+2SejpPkT zSSt+0KfjRsxXyLGshA5xOt1pqy9a5KeQ+t8Z80F14SHoj+yVeNVY+ntLfKBPZmN IRKTnV4gLPQ03bKJnqAlhE2jWskd/ze2PpwDQprDv3yhxBsncLevuc0Q6UQ+yuVC oTxJSnPVDtJ6psLsWe0S+6kbL/2X6k/gIXMM5JXoHTgaYGGei0nXVJtaiPiZtPq7 YgT740+TzmteWZ1x3MS9bU2MZNilHERxoXuXB53eWoN13nTU2P7aVK6GBCgF1Jmp 8Ui4oCmdAAfR1y5rBDX7gNt8v+VXVLAF3LMsAqGY4wGoQD/Q7gaApJstcdFGyL7c
mgNlr5up
=Ht19
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)