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.
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
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
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
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).
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 Bcha 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?
So you configured apt on the user systems to support riscv64,
but didn't change anything in the repository?
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.
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
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.
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.
On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:
For example, when I implemented libuuid, if you want to create a hugeExcept that in Debian, this is a "Recommends:", and "Recommends:"
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.
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.
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 hugeExcept that in Debian, this is a "Recommends:", and "Recommends:"
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.
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:"?
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
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.
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
<br><br><div class="gmail_quote"><div dir="auto">Am 27. Februar 2024 08:19:21 MEZ schrieb Steve Langasek <vorlon@debian.org>:</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);padding-left: 1ex;">
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>
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...
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 Bcha 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
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.
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}". ButJust 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
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?We are waiting for:
Can we help? I tried filing a binNmu bug for a package, but then found out theFrom 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:
package was nmu'd later -- without closing my bug. So clearly someone is looking at things. Where are we in the process?
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.
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).
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.
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.
- 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.
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.
[...]
- 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.
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.
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 terminaloutput. 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 thispage 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:be able to follow a link to see the list of affected packages.
<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
Please telle me what you think about it and if you think it can be uploaded to lintian.debian.org?
Hi all,output. It was not a very pleasant experience, especially for a newbie.
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
page it not helpful, and it makes the pages very slow to load (and to produce).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
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).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.
be able to follow a link to see the list of affected packages.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
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
Hi all,output. It was not a very pleasant experience, especially for a newbie.
Pierre-Elliott Bcue <peb@debian.org> on Wed, 27 Sep 2023 14:19:20:
Otto Keklinen <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
page it not helpful, and it makes the pages very slow to load (and to produce).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
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).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.
be able to follow a link to see the list of affected packages.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
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.
then be able to follow a link to see the list of affected packages.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
What will be wonderfull is to retrieve number of package affected and do a svg graph along time... Using a static script
On 08/08/24 at 18:40 +0000, Bastien Roucariès wrote:then be able to follow a link to see the list of affected packages.
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
No but the same with every tag will be really really niceWhat 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
On 07/08/24 at 19:05 +0200, Nicolas Peugnet wrote:output. It was not a very pleasant experience, especially for a newbie.
[...]
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
page it not helpful, and it makes the pages very slow to load (and to produce). >>>
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
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).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.
be able to follow a link to see the list of affected packages.
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
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.
Le vendredi 9 aot 2024, 06:39:04 UTC Lucas Nussbaum a crit :and then be able to follow a link to see the list of affected packages.
On 08/08/24 at 18:40 +0000, Bastien Roucaris 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,
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
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.
On 09/08/24 at 07:54 +0000, Bastien Roucariès wrote:and then be able to follow a link to see the list of affected packages.
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,
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
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.
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.
Le mercredi 7 août 2024, 17:05:01 UTC Nicolas Peugnet a écrit :output. It was not a very pleasant experience, especially for a newbie.
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
page it not helpful, and it makes the pages very slow to load (and to produce). >>>
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
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).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.
be able to follow a link to see the list of affected packages.
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
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 ?
--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
Apparently I'm a Lintian maintainer now. I had a quick look at Lintian and lintian.debian.org is referenced in multiple places.
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".
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.
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.
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.
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.
FYI, I opened an RT ticket asking DSA for a VM to host all of this.
Il 03/09/2024 20:05, Lucas Nussbaum ha scritto:
On 03/09/24 at 12:31 -0400, Louis-Philippe Vronneau 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.
I saw lintian.club1.fr result also in other tags I searched recently but I never saw UDD if I remember good
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?
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
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.
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...
On 2024-09-03 14:05, Lucas Nussbaum wrote:
On 03/09/24 at 12:31 -0400, Louis-Philippe Vronneau 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.
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.
At this point, I think it's too late: [...]
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.
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...
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!
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:09:37 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |