Re: lintian.debian.org off ?
[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: lintian.debian.org off ?

On 2024-08-09 7 h 12 a.m., Nicolas Peugnet wrote:

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


Hi,

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. 

Cheers,

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

Attachment: OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply to: