Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #111703 > unrolled thread
| Started by | Andreas Tille <tille@debian.org> |
|---|---|
| First post | 2024-05-09 21:30 +0200 |
| Last post | 2024-05-21 15:30 +0200 |
| Articles | 18 — 13 participants |
Back to article view | Back to linux.debian.devel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Any volunteers for lintian co-maintenance? Andreas Tille <tille@debian.org> - 2024-05-09 21:30 +0200
Re: Any volunteers for lintian co-maintenance? Soren Stoutner <soren@debian.org> - 2024-05-09 23:00 +0200
Re: Any volunteers for lintian co-maintenance? Lucas Nussbaum <lucas@debian.org> - 2024-05-10 08:00 +0200
Re: Any volunteers for lintian co-maintenance? Marc Haber <mh+debian-devel@zugschlus.de> - 2024-05-10 09:20 +0200
Re: Any volunteers for lintian co-maintenance? Niels Thykier <niels@thykier.net> - 2024-05-10 12:20 +0200
Re: Any volunteers for lintian co-maintenance? Andreas Tille <andreas@an3as.eu> - 2024-05-10 16:10 +0200
Re: Any volunteers for lintian co-maintenance? Nilesh Patra <nilesh@debian.org> - 2024-05-10 16:40 +0200
Re: Any volunteers for lintian co-maintenance? Nilesh Patra <nilesh@debian.org> - 2024-05-10 20:10 +0200
Re: Any volunteers for lintian co-maintenance? Soren Stoutner <soren@debian.org> - 2024-05-10 22:40 +0200
Re: Any volunteers for lintian co-maintenance? Andrey Rakhmatullin <wrar@debian.org> - 2024-05-10 19:50 +0200
Re: Any volunteers for lintian co-maintenance? Bill Allombert <ballombe@debian.org> - 2024-05-10 23:30 +0200
Re: Any volunteers for lintian co-maintenance? Andreas Tille <andreas@an3as.eu> - 2024-05-19 12:50 +0200
Re: Any volunteers for lintian co-maintenance? Andrey Rakhmatullin <wrar@debian.org> - 2024-05-19 13:10 +0200
Re: Any volunteers for lintian co-maintenance? Scott Kitterman <debian@kitterman.com> - 2024-05-19 17:20 +0200
Re: Any volunteers for lintian co-maintenance? Otto Kekäläinen <otto@debian.org> - 2024-05-20 22:10 +0200
Re: Any volunteers for lintian co-maintenance? Holger Levsen <holger@layer-acht.org> - 2024-05-21 13:40 +0200
Re: Any volunteers for lintian co-maintenance? PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2024-05-21 14:20 +0200
Re: Any volunteers for lintian co-maintenance? Niels Thykier <niels@thykier.net> - 2024-05-21 15:30 +0200
| From | Andreas Tille <tille@debian.org> |
|---|---|
| Date | 2024-05-09 21:30 +0200 |
| Subject | Re: Any volunteers for lintian co-maintenance? |
| Message-ID | <IChCN-cdY6-1@gated-at.bofh.it> |
Hi, this mail is a private response from Niels to my mail to the Debian Perl team where I explicitly asked for people helping out with lintian. So far the answer from Niels is the only response. Since he gave explicit permission to quote him in public I'm doing so hereby. Niels assumed that his answer "will not help my case" - but well, I do not think that hiding problems will help anybody else. At Tue, May 07, 2024 at 15:59:21 +0200 Andreas Tille wrote > Hi Perl folks, > ... > --> see full mail at https://lists.debian.org/debian-perl/2024/05/msg00000.html > [ From here I simply quote Niels unchanged - I'll comment probably tomorrow in detail ] Hi Andreas You are welcome to quote me in public, though I feel it will not help your cause. This reply is in private to you, so you can choose whether you want to quote me. I agree with the sentiment that important Debian tools would ideally be co-maintained. However, in the passing years, I have started to feel a disconnect with lintian, its direction and what I would like to see. I no longer use lintian and I am fundamentally not interested in picking up lintian anymore - neither as a user nor as a contributor. I have even uninstalled it from my machines. For now, I still "allow" it in my salsa-ci pipeline but my patience with it is thin. For me, lintian fails in all roles it has. It is not a good tool for newbies to get help, since it can only test build artifacts. As an example, your feedback look is a full package build followed by unpacking the package just so lintian can tell you have a typo on line 4. That is a massive waste of resources - notably developer time and mental bandwidth. It also fails as an archive QA tool in my view since the FTP masters have been unwilling to upgrade to any recent version of lintian. I think FTP master's argument lies with the very poor performance in certain corner cases that adversely affects larger packages (like linux). As a consequence, people now get auto-rejects when uploading because lintian on the FTP master server does not produce the same output as current lintian in stable or newer. For the record, I support the FTP masters here since the performance was quite horrible at some point (might be fixed, might not be) and that would just block benign uploads. In fact, I would go so far as to say that the FTP masters should remove lintian from their upload checks (partly because of this, partly because only source packages are reliably checked which neuters the original point of adding lintian to the upload queue). The latter half (archive-wide qa + performance + trust) might be fixable with a dedicated effort and then a lot of lobbying to restore's people trust in lintian. But that is a lot of work, and it will not solve the former (feedback cycles). The former requires a completely different mindset and scope for the tooling. To that end, I have decided to put my effort into `debputy` where I recently added support for linting *with* quickfixes, reformatting and editor support (the latter via LSP). I think that a much better approach to half of the issues that lintian emits and helps both newcomers and long term contributors to be much more productive. Especially for the editor support related parts, where people get instant feedback both on issues and the fix, automatic reformatting on save and completion suggestions. None of which lintian or wrap-and-sort are capable of. If I am successful, then lintian can specialize its efforts into issues only visible in packaged artifacts and thereby reduce it scope a bit. In that sense, my work might be a (minor) help to the Lintian team on the assumption they are willing to specialize more. But even if I am not successful with `debputy`, I cannot imagine I would consider returning to lintian. It does not scratch my itch and years of issues (some of which are still unfixed) have made me not want to have anything to do with the tool. Best of luck to Axel and anyone joining him to stop the bleeding. I do hope they are successful, since lintian still have valuable features for Debian as a whole that can be salvaged. But I am not going to be the "hero" that salvages that mess. If I am going to do heroics in this area, then it will be related to `debputy` with the aim to enable us to spend less mental bandwidth on daily packaging work. Best regards, Niels PS: In my view, the bleeding of lintian's quality started long before Axel joined the lintian maintenance team and I do not fault Axel for being unable to stop the bleeding. In my view, only a hero could have "managed" that at the expense of their mental health.
[toc] | [next] | [standalone]
| From | Soren Stoutner <soren@debian.org> |
|---|---|
| Date | 2024-05-09 23:00 +0200 |
| Message-ID | <ICj1T-ceJj-9@gated-at.bofh.it> |
| In reply to | #111703 |
[Multipart message — attachments visible in raw view] — view raw
I would like to respectfully disagree will some of the opinions expressed in this email. First, I should say that I am painfully aware of how long it takes to run lintian on large packages. When working on qtwebengine-opensource-src it takes my system (Ryzen 7 5700G) about 2 hours to build the package and about half an hour to run lintian against it. I would be completely in favor of any efforts that could be made in the direction of making lintian more efficient, either within lintian itself or in other packages that replicate some or all of lintain’s functionality in more efficient ways. However, I personally find lintian to be one of the most helpful tools in Debian packaging. When going through the application process I found lintian to be a very useful tool in helping me learn how to produce packages that conform to Debian’s standards. The integration of lintian into mentors.debian.net was very helpful to me when I first started submitting packages to Debian, and it is still helpful to me when reviewing other people’s packages that have been submitted to mentors.debian.net. As I type this email I am building an update to qtwebengine-opensource-src. So far, lintian has caught two problems with this release that I would have otherwise missed. I admit that I am fairly new as a Debian Developer, and perhaps as I gain greater experience I would get to the point where lintian never catches things I miss. But I don’t personally expect that to ever happen, because there are too many corner cases or opportunities for typos that computers are much better at catching than humans. I do understand that lintian is in need of a lot of work. I personally have an open MR against the package that fixes a check that is wrong more often than it is right (with both false positives and false negatives). The fix is relatively simple and makes the check 100% accurate as far as I can tell. However, after over a year, it has yet to be reviewed. https://salsa.debian.org/lintian/lintian/-/merge_requests/461[1] I must admit that I have been sorely tempted to get involved with maintaining lintian because I feel it is so important. So far, I have resisted that temptation because I am already involved in a decade-long effort to clean up Qt WebEngine in Debian and get it to the point where it has proper security support. I haven’t wanted to spread myself too thin and end up accomplishing nothing because I tried to do too much. But if lintian’s need increases or if my existing commitments decrease I would be happy to find myself involved with lintian maintenance. Soren On Thursday, May 9, 2024 12:27:49 PM MST Andreas Tille wrote: > Hi, > > this mail is a private response from Niels to my mail to the Debian Perl > team where I explicitly asked for people helping out with lintian. So > far the answer from Niels is the only response. Since he gave explicit > permission to quote him in public I'm doing so hereby. Niels assumed > that his answer "will not help my case" - but well, I do not think that > hiding problems will help anybody else. > > At Tue, May 07, 2024 at 15:59:21 +0200 Andreas Tille wrote > > > Hi Perl folks, > > ... > > --> see full mail at > > https://lists.debian.org/debian-perl/2024/05/msg00000.html > [ From here I simply quote Niels unchanged - I'll comment probably tomorrow in > detail ] > >
[toc] | [prev] | [next] | [standalone]
| From | Lucas Nussbaum <lucas@debian.org> |
|---|---|
| Date | 2024-05-10 08:00 +0200 |
| Message-ID | <ICrst-ckcS-1@gated-at.bofh.it> |
| In reply to | #111704 |
On 09/05/24 at 13:57 -0700, Soren Stoutner wrote:
> First, I should say that I am painfully aware of how long it takes to run lintian on large
> packages. When working on qtwebengine-opensource-src it takes my system (Ryzen 7
> 5700G) about 2 hours to build the package and about half an hour to run lintian against it.
> I would be completely in favor of any efforts that could be made in the direction of making
> lintian more efficient, either within lintian itself or in other packages that replicate some or
> all of lintain’s functionality in more efficient ways.
If someone wants to work on lintian performance: the runtimes for the
UDD lintian importer (behind https://udd.debian.org/lintian/ ) are
available in the lintian_logs table:
udd=> select distinct ts, source, version, duration from lintian_logs order by duration desc limit 30;
ts | source | version | duration
----------------------------+-------------------------+-------------------------------------------+----------
2024-04-05 16:54:20.437828 | acl2 | 8.5dfsg-5 | 32879
2024-04-26 06:20:59.082471 | linux | 6.7.12-1 | 16472
2024-02-29 10:39:52.6379 | gcc-14-cross-ports | 4 | 14616
2024-02-29 10:39:16.350521 | gcc-14-cross-ports | 5 | 14580
2024-02-29 10:35:17.939875 | gcc-11-cross-mipsen | 6+c1+nmu1 | 14341
2024-02-29 10:35:06.549735 | gcc-13-cross-mipsen | 2+c1 | 14330
2024-02-29 10:34:54.908736 | gcc-14-cross | 4 | 14318
2024-02-29 10:34:44.720364 | gcc-12-cross-mipsen | 4+c1 | 14308
2024-02-29 10:33:50.035058 | gcc-10-cross-mipsen | 3+c6 | 14253
2024-05-09 11:24:34.446854 | llvm-toolchain-17 | 1:17.0.6-12 | 13086
2024-02-29 10:04:42.241127 | gcc-14-cross | 3 | 12505
2024-05-03 23:10:27.416567 | libreoffice | 4:24.2.3-1 | 12238
2024-02-29 09:59:52.604453 | gcc-9-cross-mipsen | 4+c2 | 12216
2024-05-07 01:51:54.054889 | llvm-toolchain-16 | 1:16.0.6-27 | 11180
2024-04-25 10:31:07.753175 | llvm-toolchain-snapshot | 1:19~++20240421021844+e095d978ba47-1~exp1 | 9881
2024-05-05 04:30:01.133898 | llvm-toolchain-18 | 1:18.1.5-2 | 9811
2024-02-29 12:48:09.931447 | gcc-arm-none-eabi | 15:13.2.rel1-2 | 9773
2024-02-29 13:22:32.331297 | gcc-10-cross | 23 | 9118
2024-05-06 22:16:07.781017 | llvm-toolchain-15 | 1:15.0.7-15 | 8976
2024-04-30 10:12:54.498582 | openblas | 0.3.27+ds-2 | 8787
2024-04-04 10:04:55.49545 | gcc-14 | 14-20240330-1 | 8307
2024-05-07 10:03:49.089649 | ghc | 9.6.5-1~exp1 | 8246
2024-05-02 10:03:49.545502 | gcc-14 | 14-20240429-1 | 8242
2024-02-29 12:54:28.975384 | gcc-13-cross-ports | 17 | 7753
2024-04-14 21:54:48.554806 | ghc | 9.4.7-5 | 7702
2024-02-29 14:38:08.333028 | gcc-13-cross | 14 | 7321
2024-02-29 15:22:27.15095 | gcc-10-cross-ports | 24 | 7192
2024-04-14 09:46:15.411926 | gcc-11 | 11.4.0-9 | 7186
2024-02-29 15:22:21.577515 | gcc-9-cross-ports | 27 | 7156
2024-05-06 09:45:44.77244 | llvm-toolchain-14 | 1:14.0.6-20 | 7155
(30 rows)
That's the time for testing the source and all binary packages on all
architectures.
Lucas
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-devel@zugschlus.de> |
|---|---|
| Date | 2024-05-10 09:20 +0200 |
| Message-ID | <ICsHT-cl86-5@gated-at.bofh.it> |
| In reply to | #111704 |
On Thu, 09 May 2024 13:57:28 -0700, Soren Stoutner <soren@debian.org> wrote: >However, I personally find lintian to be one of the most helpful tools in Debian packaging. +1. The fact that it doesn perform well on large packages is bad, but that doesnt make it less useful for smaller packages. Greetings Marc -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
[toc] | [prev] | [next] | [standalone]
| From | Niels Thykier <niels@thykier.net> |
|---|---|
| Date | 2024-05-10 12:20 +0200 |
| Message-ID | <ICvw5-cmQk-1@gated-at.bofh.it> |
| In reply to | #111704 |
Soren Stoutner:
> I would like to respectfully disagree will some of the opinions expressed in this email.
>
Hi Soren
Not sure if we disagree all that much to be honest. :)
> First, I should say that I am painfully aware of how long it takes to run lintian on large
> packages. When working on qtwebengine-opensource-src it takes my system (Ryzen 7
> 5700G) about 2 hours to build the package and about half an hour to run lintian against it.
> I would be completely in favor of any efforts that could be made in the direction of making
> lintian more efficient, either within lintian itself or in other packages that replicate some or
> all of lintain’s functionality in more efficient ways.
>
> However, I personally find lintian to be one of the most helpful tools in Debian packaging.
> When going through the application process I found lintian to be a very useful tool in
> helping me learn how to produce packages that conform to Debian’s standards. The
> integration of lintian into mentors.debian.net was very helpful to me when I first started
> submitting packages to Debian, and it is still helpful to me when reviewing other people’s
> packages that have been submitted to mentors.debian.net.
>
I agree that lintian has useful features as stated in my original email.
Though not with a very strong emphasis, so I can see how you might have
not have given that remark much thought.
After a bit more reflection, I feel lintian is currently working in
three different areas (to simplify matters a lot).
1) Support on Debian packaging files.
- You have a comma in `Architecture`, which is space separated
- The `foo` license in `d/copyright` is not defined
- The order of the `Files` stanzas are probably wrong.
- The `Files` stanza in `d/copyright` reference `foo` but that file
is not in the unpacked source tree.
=> This should *not* require a assembled package to get these
results and should provide (near) instant feedback directly
in your editor. This area should be designed around interactivity
and low latency as a consequence.
2) Checking of upstream source.
- Missing source checks
- Source files with known questionable licenses
- Here are some dependencies that might need to be packaged.
- The upstream build system seems to be `waf` so you should be
aware of this stance in Debian on `waf`, etc.
- Maybe: "Advice for how to approach this kind of package".
(like "This seems like a python package; consider looking at $TOOL
for an initial debianization. The python packaging team might be
relevant for you if you are a new maintainer, etc.)
=> This should *not* require a assembled package to get these
results. However, it will take some time to chew through all
of this. It would be a "before initial packaging" and maybe
on major upstream releases (or NEW checks). It will be a batch
process but maybe with support for interactivity.
3) Checking of assembled artifacts.
- Does the package place the systemd service in the right place?
- There is a trigger for shared libraries but no shared libraries.
(etc.)
=> This (by definition) is for assembled packages. It will be a
batch process.
Part 1) is something I feel would belong in a tool that provides on-line
/ in-editor support (see my post script for details). This is partly why
expanded `debputy` to into this field. You having a 2½ hour feedback
loop here is crazy - the `acl2` one having 9+ hours is complete madness.
Part 2) is ideally something you would run before attempting to package
a new upstream source tree. Many of these things have a high impact on
whether you want to continue with the packaging (oh, I need to package
20 dependencies first. It has non-free content, etc.). The fact that you
need to build a package only to discover that your package cannot be
distributed seems backwards to me. I feel this workflow should work from
the basis of:
$ git clone $UPSTREAM source-dir # (or tar xf ...)
$ check-upstream-code source-dir
Note: This is not an area I am going to tackle. But if I was going into
it, that would be my "vision" for the starting point.
Part 3) is where I feel lintian still has an area to be in (which also
matches its mission statement). It could also include a subset of the
results from part 1+2 as a "all-in-one-inclusive" wrapping to simplify
archive-wide QA or sponsoring checks. But as I see it, most
(non-sponsor) users would ideally get their 1) and 2) feedback from the
more specialized tools.
These are the ballparks I would split lintian into given infinite
developer time and resources. Ideally not a lot "smaller" than this to
avoid drowning people with the "Run these 1000 tools"-problem to avoid a
repeat of `check-all-the-things`. This is also why I am not again
lintian aggregating from the other areas. For some of its users (such as
sponsors) it will be a useful feature that they can just run one tool
and get the relevant results.
> As I type this email I am building an update to qtwebengine-opensource-src. So far, lintian
> has caught two problems with this release that I would have otherwise missed. I admit that
> I am fairly new as a Debian Developer, and perhaps as I gain greater experience I would get
> to the point where lintian never catches things I miss. But I don’t personally expect that to
> ever happen, because there are too many corner cases or opportunities for typos that
> computers are much better at catching than humans.
>
Even with my years of experience I make mistakes that Lintian catches to
this day. As an example, when I did `debputy`, I had mistakes in
`d/copyright` with not having the "full text" of the `GPL-2+`. This went
through NEW so either the FTP masters missed it too or they went "It's
fine, it is a native package with one contributor and everyone knows
what GPL-2+ means". Though, my key grief here is that this kind of
problem should (as said) never come with a 2½ hour feedback cycle.
Or even a 9+ hour one for acl2 package ...
To be precise, this kind of feedback belongs in the millisecond to
second range (seconds for spellchecking of changelogs, exceptionally
long deb822 files, etc.) in my view.
> [...]
>
> I must admit that I have been sorely tempted to get involved with maintaining lintian
> because I feel it is so important. So far, I have resisted that temptation because I am
> already involved in a decade-long effort to clean up Qt WebEngine in Debian and get it to
> the point where it has proper security support. I haven’t wanted to spread myself too thin
> and end up accomplishing nothing because I tried to do too much. But if lintian’s need
> increases or if my existing commitments decrease I would be happy to find myself involved
> with lintian maintenance.
>
> Soren
>
> [...]
If lintian is important to you, I strongly recommend that you do put
*some* of your volunteer time into it. I have had some 5+ years of
lintian maintenance since 2011'ish and forward. At its peak, we were at
most two people actively contributing to lintian and that was not enough
to keep my motivation going.
Especially with lintian being in the state it is right now, I think we
would need several people to stabilize it.
For me, most of the problems I have are better solved with near instant
feedback and I do not see lintian ever "getting there". The
architectural design of lintian has it locked into "high latency
diagnostics-only feedback with no quick fixes" to reduce it into a
"one-liner". In my book that should not be a newcomer facing tool.
Accordingly, I am investing my volunteer time on a different approach to
scratch my itch.
Best regards,
Niels
-- PS on better newcomer tooling support --
I also feel we have also failed to look beyond linting for assisting
newcomers. Batch linting is our go to tool for all problems, but clever
use of on-line documentation and completion support help newcomers as
well. My current example problem is the synopsis part of the
`Description` field. I recall that as being something many people
struggled with when I was new to Debian. The lintian tool can spot some
common cases and go "You probably want to try again", which is not great
but better than nothing.
For comparison, in the on-line hover docs feature of `debputy`, I
special cased the hover docs for the synopsis to provide contextualized
help. Like "This is how your Synopsis would appear in search results
from `apt search` or `apt-get search`". It also takes the synopsis and
inserts into the sentence below
This package provides [a|an|the] <SYNOPSIS>.
Which was the test sentence I learned to use when I started contributing
on how to write the package synopsis. This feature is available to the
contributor regardless of whether there is a mistake, which enables them
to refine their synopsis at all times.
That is obviously not the kind of tool that lintian is, but that is what
I feel we should provide as "first line" support tools for newcomers.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Tille <andreas@an3as.eu> |
|---|---|
| Date | 2024-05-10 16:10 +0200 |
| Message-ID | <ICz6F-cp7z-7@gated-at.bofh.it> |
| In reply to | #111712 |
Hi, Am Fri, May 10, 2024 at 12:18:29PM +0200 schrieb Niels Thykier: > Soren Stoutner: > > I would like to respectfully disagree will some of the opinions expressed in this email. > > Hi Soren > > Not sure if we disagree all that much to be honest. :) I think we all agree that we need some policy checking tool and lintian is the only available tool (at least after linda was removed in 2008 for good). > > However, I personally find lintian to be one of the most helpful tools in Debian packaging. > > When going through the application process I found lintian to be a very useful tool in > > helping me learn how to produce packages that conform to Debian’s standards. The > > integration of lintian into mentors.debian.net was very helpful to me when I first started > > submitting packages to Debian, and it is still helpful to me when reviewing other people’s > > packages that have been submitted to mentors.debian.net. > > > > I agree that lintian has useful features as stated in my original email. >From my point of view lintian has saved me *lots* of uploads that would have not compliant with Debian policy / my own quality standards. So I run lintian per default on *every* package build process (and in Salsa CI). Admittedly most of my packages are not *that* large (with a few excetions) that I was never frustrated about a slow lintian (on my _multi-tasking_ Debian system ...) > Though not with a very strong emphasis, so I can see how you might have not > have given that remark much thought. > > After a bit more reflection, I feel lintian is currently working in three > different areas (to simplify matters a lot). > > 1) Support on Debian packaging files. > - You have a comma in `Architecture`, which is space separated > - The `foo` license in `d/copyright` is not defined > - The order of the `Files` stanzas are probably wrong. > - The `Files` stanza in `d/copyright` reference `foo` but that file > is not in the unpacked source tree. > > => This should *not* require a assembled package to get these > results and should provide (near) instant feedback directly > in your editor. This area should be designed around interactivity > and low latency as a consequence. ACK > 2) Checking of upstream source. > - Missing source checks > - Source files with known questionable licenses > - Here are some dependencies that might need to be packaged. > - The upstream build system seems to be `waf` so you should be > aware of this stance in Debian on `waf`, etc. > - Maybe: "Advice for how to approach this kind of package". > (like "This seems like a python package; consider looking at $TOOL > for an initial debianization. The python packaging team might be > relevant for you if you are a new maintainer, etc.) > > => This should *not* require a assembled package to get these > results. However, it will take some time to chew through all > of this. It would be a "before initial packaging" and maybe > on major upstream releases (or NEW checks). It will be a batch > process but maybe with support for interactivity. ACK > 3) Checking of assembled artifacts. > - Does the package place the systemd service in the right place? > - There is a trigger for shared libraries but no shared libraries. > (etc.) > > => This (by definition) is for assembled packages. It will be a > batch process. > > > Part 1) is something I feel would belong in a tool that provides on-line / > in-editor support (see my post script for details). This is partly why > expanded `debputy` to into this field. You having a 2½ hour feedback loop > here is crazy - the `acl2` one having 9+ hours is complete madness. I confirm it would be a great enhancement to have some checker *before* the actual build would start. You mentioned `debputy` and I admit I need to check this out in the near future. If I imagine some policy checking debhelper-like tool that is fired up after dh_clean step I'd be all for it and it really could save some time. However, I'd consider it unfair against lintian to blame it about a missing feature if it was never written for this. If you see any chance that this could be implemented - idealy by re-using the same rule set lintian is using if possible to keep maintenance burden of those rules lower this would be really some great enhancement. > Part 2) is ideally something you would run before attempting to package a > new upstream source tree. Many of these things have a high impact on whether > you want to continue with the packaging (oh, I need to package 20 > dependencies first. It has non-free content, etc.). The fact that you need > to build a package only to discover that your package cannot be distributed > seems backwards to me. I feel this workflow should work from the basis of: > > $ git clone $UPSTREAM source-dir # (or tar xf ...) > $ check-upstream-code source-dir > > Note: This is not an area I am going to tackle. But if I was going into it, > that would be my "vision" for the starting point. This also sounds like some nifty and helpful tool - but I guess you also will not blame lintian about not doing this. > Part 3) is where I feel lintian still has an area to be in (which also > matches its mission statement). It could also include a subset of the > results from part 1+2 as a "all-in-one-inclusive" wrapping to simplify > archive-wide QA or sponsoring checks. But as I see it, most (non-sponsor) > users would ideally get their 1) and 2) feedback from the more specialized > tools. I also think that lintian has *always* a very good purpose to check for readily built packages. We have lots of old packages which are not touched over several new releases of our policy. IMHO its really necessary to learn about policy violations of old packages inside our archive which needs a lintian following the current principle of operation. > These are the ballparks I would split lintian into given infinite developer > time and resources. Ideally not a lot "smaller" than this to avoid drowning > people with the "Run these 1000 tools"-problem to avoid a repeat of > `check-all-the-things`. This is also why I am not again lintian aggregating > from the other areas. For some of its users (such as sponsors) it will be a > useful feature that they can just run one tool and get the relevant results. OK. > Even with my years of experience I make mistakes that Lintian catches to > this day. We are all humans, right. No matter what experience one has - some issues should be checked by an automated tool. > As an example, when I did `debputy`, I had mistakes in > `d/copyright` with not having the "full text" of the `GPL-2+`. This went > through NEW so either the FTP masters missed it too or they went "It's fine, > it is a native package with one contributor and everyone knows what GPL-2+ > means". Though, my key grief here is that this kind of problem should (as > said) never come with a 2½ hour feedback cycle. ... in an ideal world right and your arguments for spotting this more directly are good. But well, my initial mail was about co-maintenance of lintian and its great if you come up with those feature requests. Not sure if this might be worth a bug report severity wishlist Please add dh_lintian_source_check which is run after dh_clean. > Or even a 9+ hour one for acl2 package ... > > To be precise, this kind of feedback belongs in the millisecond to second > range (seconds for spellchecking of changelogs, exceptionally long deb822 > files, etc.) in my view. Agreed - but IMHO this is a wishlist bug report for lintian which involves changing how lintian works. > > [...] > > > > I must admit that I have been sorely tempted to get involved with maintaining lintian > > because I feel it is so important. So far, I have resisted that temptation because I am > > already involved in a decade-long effort to clean up Qt WebEngine in Debian and get it to > > the point where it has proper security support. I haven’t wanted to spread myself too thin > > and end up accomplishing nothing because I tried to do too much. But if lintian’s need > > increases or if my existing commitments decrease I would be happy to find myself involved > > with lintian maintenance. > > > > Soren > > > > [...] > > If lintian is important to you, I strongly recommend that you do put *some* > of your volunteer time into it. +1 for Soren and everybody else reading this. > I have had some 5+ years of lintian > maintenance since 2011'ish and forward. At its peak, we were at most two > people actively contributing to lintian and that was not enough to keep my > motivation going. Since I was sensing this I started this thread. > Especially with lintian being in the state it is right now, I think we would > need several people to stabilize it. > > For me, most of the problems I have are better solved with near instant > feedback and I do not see lintian ever "getting there". The architectural > design of lintian has it locked into "high latency diagnostics-only feedback > with no quick fixes" to reduce it into a "one-liner". In my book that should > not be a newcomer facing tool. Accordingly, I am investing my volunteer time > on a different approach to scratch my itch. It might be interesting if you would go even more in detail. As I said I could imagine some `lintian-data` (`lintian-rules` whatever name you might prefer) that implement current policy and can be consumed by lintian as well as your imagined instant feedback tool. > -- PS on better newcomer tooling support -- > > I also feel we have also failed to look beyond linting for assisting > newcomers. Batch linting is our go to tool for all problems, but clever use > of on-line documentation and completion support help newcomers as well. My > current example problem is the synopsis part of the `Description` field. I > recall that as being something many people struggled with when I was new to > Debian. The lintian tool can spot some common cases and go "You probably > want to try again", which is not great but better than nothing. ACK > For comparison, in the on-line hover docs feature of `debputy`, I special > cased the hover docs for the synopsis to provide contextualized help. Like > "This is how your Synopsis would appear in search results from `apt search` > or `apt-get search`". It also takes the synopsis and inserts into the > sentence below > > This package provides [a|an|the] <SYNOPSIS>. > > Which was the test sentence I learned to use when I started contributing on > how to write the package synopsis. This feature is available to the > contributor regardless of whether there is a mistake, which enables them to > refine their synopsis at all times. > > That is obviously not the kind of tool that lintian is, but that is what I > feel we should provide as "first line" support tools for newcomers. Fully ACK that such a tool would be great. Kind regards and thanks a lot for your input Andreas. -- https://fam-tille.de
[toc] | [prev] | [next] | [standalone]
| From | Nilesh Patra <nilesh@debian.org> |
|---|---|
| Date | 2024-05-10 16:40 +0200 |
| Message-ID | <ICzzH-cphZ-3@gated-at.bofh.it> |
| In reply to | #111716 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, May 10, 2024 at 04:06:15PM +0200, Andreas Tille wrote: > > If lintian is important to you, I strongly recommend that you do put *some* > > of your volunteer time into it. > > +1 > for Soren and everybody else reading this. Lintian is important for me. For the past few months, I have been reviewing and merging MRs and pushing small fixes of my own. I am not a proficient perl programmer and hence I am not the best person to be doing so. But then, nobody else was doing it and I decided to do at least a little bit. If someone would like to dedicatedly contribute sometime there, it'd be really great. The package is not in a very good shape right now. Best, Nilesh
[toc] | [prev] | [next] | [standalone]
| From | Nilesh Patra <nilesh@debian.org> |
|---|---|
| Date | 2024-05-10 20:10 +0200 |
| Message-ID | <ICCQV-crrf-7@gated-at.bofh.it> |
| In reply to | #111718 |
[Multipart message — attachments visible in raw view] — view raw
Hi Andrius, On Fri, May 10, 2024 at 05:58:24PM +0300, Andrius Merkys wrote: > Do you mean bugs on bugs.d.o, or are there other issues? As you may have seen in the other emails, there are performance issues. Other than that, there are 2 open RC bugs right now (fixed in salsa but not uploaded I don't make uploads for lintian). A pile of MRs are pending for reviews at many points in time. > I personally feel motivated to implement new features in lintian or go after > low hanging fruits, but I am somewhat driven away by the need to understand > lintian's internals. Is there a documentation on the data/control flow, or > class diagrams? This would help me a lot. Not that I know of, I suppose Axel/Bastian may be able answer this. Best, Nilesh
[toc] | [prev] | [next] | [standalone]
| From | Soren Stoutner <soren@debian.org> |
|---|---|
| Date | 2024-05-10 22:40 +0200 |
| Message-ID | <ICFc5-csGo-5@gated-at.bofh.it> |
| In reply to | #111712 |
[Multipart message — attachments visible in raw view] — view raw
Niels, On Friday, May 10, 2024 3:18:29 AM MST Niels Thykier wrote: > Soren Stoutner: > > I would like to respectfully disagree will some of the opinions expressed in > > this email. > Hi Soren > > Not sure if we disagree all that much to be honest. :) Yes, I think we do agree. From a performance perspective, I see two big problems. 1. Lintian runs after a potentially long build process. 2. Lintian takes a long time to run itself. You have done a really good job of describing point 1 above, as well as proposing ways to address it. I endorse everything you have said. For point 2, it seems the easiest way to make a significant difference would be if lintain could run multi-threaded. My current development CPU has 8 physical cores hyper-threaded, which present to the OS as 16 logical cores. Most of the build process is multi-threaded and uses all the cores to their maximum potential simultaneously. But lintian is single-threaded, so it only uses one core and the other 15 sit idle. There might be some lintian tests that depend on the output of other lintian tests, but I would imagine that most of them could be run in parallel with the results combined at the end. I don’t know enough Perl to know how easy it would be to run lintian in a multi-threaded manner, but if this was not a difficult change it would speed up lintian runs dramatically. In the case of qtwebengine-opensource-src on my hardware, assuming that all cores could be efficiently utilized and there are no other bottlenecks in RAM or disk access, it would drop lintian’s runtime from about 30 minutes to about 2 minutes. > > First, I should say that I am painfully aware of how long it takes to run > > lintian on large packages. When working on qtwebengine-opensource-src it > > takes my system (Ryzen 7 5700G) about 2 hours to build the package and > > about half an hour to run lintian against it. I would be completely in > > favor of any efforts that could be made in the direction of making lintian > > more efficient, either within lintian itself or in other packages that > > replicate some or all of lintain’s functionality in more efficient ways. > > > > However, I personally find lintian to be one of the most helpful tools in > > Debian packaging. When going through the application process I found > > lintian to be a very useful tool in helping me learn how to produce > > packages that conform to Debian’s standards. The integration of lintian > > into mentors.debian.net was very helpful to me when I first started > > submitting packages to Debian, and it is still helpful to me when reviewing > > other people’s packages that have been submitted to mentors.debian.net. > > I agree that lintian has useful features as stated in my original email. > Though not with a very strong emphasis, so I can see how you might have > not have given that remark much thought. > > After a bit more reflection, I feel lintian is currently working in > three different areas (to simplify matters a lot). > > 1) Support on Debian packaging files. > - You have a comma in `Architecture`, which is space separated > - The `foo` license in `d/copyright` is not defined > - The order of the `Files` stanzas are probably wrong. > - The `Files` stanza in `d/copyright` reference `foo` but that file > is not in the unpacked source tree. > > => This should *not* require a assembled package to get these > results and should provide (near) instant feedback directly > in your editor. This area should be designed around interactivity > and low latency as a consequence. > > 2) Checking of upstream source. > - Missing source checks > - Source files with known questionable licenses > - Here are some dependencies that might need to be packaged. > - The upstream build system seems to be `waf` so you should be > aware of this stance in Debian on `waf`, etc. > - Maybe: "Advice for how to approach this kind of package". > (like "This seems like a python package; consider looking at $TOOL > for an initial debianization. The python packaging team might be > relevant for you if you are a new maintainer, etc.) > > => This should *not* require a assembled package to get these > results. However, it will take some time to chew through all > of this. It would be a "before initial packaging" and maybe > on major upstream releases (or NEW checks). It will be a batch > process but maybe with support for interactivity. > > > 3) Checking of assembled artifacts. > - Does the package place the systemd service in the right place? > - There is a trigger for shared libraries but no shared libraries. > (etc.) > > => This (by definition) is for assembled packages. It will be a > batch process. > > > Part 1) is something I feel would belong in a tool that provides on-line > / in-editor support (see my post script for details). This is partly why > expanded `debputy` to into this field. You having a 2½ hour feedback > loop here is crazy - the `acl2` one having 9+ hours is complete madness. > > Part 2) is ideally something you would run before attempting to package > a new upstream source tree. Many of these things have a high impact on > whether you want to continue with the packaging (oh, I need to package > 20 dependencies first. It has non-free content, etc.). The fact that you > need to build a package only to discover that your package cannot be > distributed seems backwards to me. I feel this workflow should work from > the basis of: > > $ git clone $UPSTREAM source-dir # (or tar xf ...) > $ check-upstream-code source-dir > > Note: This is not an area I am going to tackle. But if I was going into > it, that would be my "vision" for the starting point. > > Part 3) is where I feel lintian still has an area to be in (which also > matches its mission statement). It could also include a subset of the > results from part 1+2 as a "all-in-one-inclusive" wrapping to simplify > archive-wide QA or sponsoring checks. But as I see it, most > (non-sponsor) users would ideally get their 1) and 2) feedback from the > more specialized tools. > > These are the ballparks I would split lintian into given infinite > developer time and resources. Ideally not a lot "smaller" than this to > avoid drowning people with the "Run these 1000 tools"-problem to avoid a > repeat of `check-all-the-things`. This is also why I am not again > lintian aggregating from the other areas. For some of its users (such as > sponsors) it will be a useful feature that they can just run one tool > and get the relevant results. > > > As I type this email I am building an update to qtwebengine-opensource- src. > > So far, lintian has caught two problems with this release that I would have > > otherwise missed. I admit that I am fairly new as a Debian Developer, and > > perhaps as I gain greater experience I would get to the point where lintian > > never catches things I miss. But I don’t personally expect that to ever > > happen, because there are too many corner cases or opportunities for typos > > that computers are much better at catching than humans. > > Even with my years of experience I make mistakes that Lintian catches to > this day. As an example, when I did `debputy`, I had mistakes in > `d/copyright` with not having the "full text" of the `GPL-2+`. This went > through NEW so either the FTP masters missed it too or they went "It's > fine, it is a native package with one contributor and everyone knows > what GPL-2+ means". Though, my key grief here is that this kind of > problem should (as said) never come with a 2½ hour feedback cycle. > > Or even a 9+ hour one for acl2 package ... > > To be precise, this kind of feedback belongs in the millisecond to > second range (seconds for spellchecking of changelogs, exceptionally > long deb822 files, etc.) in my view. > > > [...] > > > > I must admit that I have been sorely tempted to get involved with > > maintaining lintian because I feel it is so important. So far, I have > > resisted that temptation because I am already involved in a decade-long > > effort to clean up Qt WebEngine in Debian and get it to the point where it > > has proper security support. I haven’t wanted to spread myself too thin > > and end up accomplishing nothing because I tried to do too much. But if > > lintian’s need increases or if my existing commitments decrease I would be > > happy to find myself involved with lintian maintenance. > > > > Soren > > > > [...] > > If lintian is important to you, I strongly recommend that you do put > *some* of your volunteer time into it. I have had some 5+ years of > lintian maintenance since 2011'ish and forward. At its peak, we were at > most two people actively contributing to lintian and that was not enough > to keep my motivation going. > > Especially with lintian being in the state it is right now, I think we > would need several people to stabilize it. > > For me, most of the problems I have are better solved with near instant > feedback and I do not see lintian ever "getting there". The > architectural design of lintian has it locked into "high latency > diagnostics-only feedback with no quick fixes" to reduce it into a > "one-liner". In my book that should not be a newcomer facing tool. > Accordingly, I am investing my volunteer time on a different approach to > scratch my itch. > > Best regards, > Niels > > > -- PS on better newcomer tooling support -- > > I also feel we have also failed to look beyond linting for assisting > newcomers. Batch linting is our go to tool for all problems, but clever > use of on-line documentation and completion support help newcomers as > well. My current example problem is the synopsis part of the > `Description` field. I recall that as being something many people > struggled with when I was new to Debian. The lintian tool can spot some > common cases and go "You probably want to try again", which is not great > but better than nothing. > > For comparison, in the on-line hover docs feature of `debputy`, I > special cased the hover docs for the synopsis to provide contextualized > help. Like "This is how your Synopsis would appear in search results > from `apt search` or `apt-get search`". It also takes the synopsis and > inserts into the sentence below > > This package provides [a|an|the] <SYNOPSIS>. > > Which was the test sentence I learned to use when I started contributing > on how to write the package synopsis. This feature is available to the > contributor regardless of whether there is a mistake, which enables them > to refine their synopsis at all times. > > That is obviously not the kind of tool that lintian is, but that is what > I feel we should provide as "first line" support tools for newcomers. -- Soren Stoutner soren@debian.org
[toc] | [prev] | [next] | [standalone]
| From | Andrey Rakhmatullin <wrar@debian.org> |
|---|---|
| Date | 2024-05-10 19:50 +0200 |
| Message-ID | <ICCxz-cr5l-5@gated-at.bofh.it> |
| In reply to | #111703 |
[Multipart message — attachments visible in raw view] — view raw
My 1.83 RUB: lintian is one of those things that are very important and useful when you know how to use them, which quirks to apply and which parts to ignore, and without that knowledge are maybe useful, maybe useless, maybe harmful, and nobody will tell you that knowledge unless you ask directly. It's also a mandatory part of the infra and workflows, yet it's mostly unmaintained, somewhat bitrotten and in part a victim of unfortunate decisions of previous maintainers. This is a very weird and paradoxical state which also in a large part relects the state of Debian as a whole (luckily, only in a part, not completely). Random examples: - The most paradoxical thing is the recently "discovered" combination of "old lintian falsely reports a problem in certain packages", "lintian runs as a part of the package acceptance process and some problems are autorejects", "people are supposed to run lintian from sid for packages in sid", "specifically *old* lintian runs as a part of the package acceptance process" and "that lintian can't be upgraded because new one is too slow". - To get full lintian output you need to run it against binary .changes, not against a .deb, a .dsc or a source .changes. And you should run it with a bunch of args enabling lower-severity tags, because some of those are useful. Newer people don't know that even if they know about lintian. Those that don't know will see lintian output when they upload their package to mentors, and which subset they will see depends on which .changes they upload. - lintian tags have descriptions (it's still unclear to me how obvious is that). The most straightforward ways to read them are googling them if you run lintian locally and clicking links if you look at e.g. mentors. But lintian.debian.org is dead. There are also lintian -i and lintian-explain-tags but it's unclear how to learn about them, at least without reading all of lintian(1). - It's impossible to know beforehand which tags you need to address now, which you should address now or some time in the future, which are irrelevant and which must not be followed because they are wrong (in general or are false positives). Severity is also often not correlated with this. My go-to advice for sponsored uploads is "fix whatever your sponsor asks you to fix" and I won't publish my advice for direct uploads which I follow myself. As a bottom line, it's clearly not good enough for the role it currently plays and is becoming worse instead of becoming better, but we don't have a replacement and it needs a lot of man-hours to go back on track. -- WBR, wRAR
[toc] | [prev] | [next] | [standalone]
| From | Bill Allombert <ballombe@debian.org> |
|---|---|
| Date | 2024-05-10 23:30 +0200 |
| Message-ID | <ICFYt-ctbM-1@gated-at.bofh.it> |
| In reply to | #111719 |
Le Fri, May 10, 2024 at 10:47:29PM +0500, Andrey Rakhmatullin a écrit : > - The most paradoxical thing is the recently "discovered" combination of > "old lintian falsely reports a problem in certain packages", "lintian > runs as a part of the package acceptance process and some problems are > autorejects", "people are supposed to run lintian from sid for packages > in sid", "specifically *old* lintian runs as a part of the package > acceptance process" and "that lintian can't be upgraded because new one > is too slow". It would help if someone setup UDD to generate statistics about lintian tests and lintian performance. (How many package report a specific test, how much time lintian need to run etc.) This something that was done on lintian.debian.org, but it is defunct. (lintian.debian.org allowed to compare running time between version of lintian). Cheers, -- Bill. <ballombe@debian.org> Imagine a large red swirl here.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Tille <andreas@an3as.eu> |
|---|---|
| Date | 2024-05-19 12:50 +0200 |
| Message-ID | <IFMh3-eolu-1@gated-at.bofh.it> |
| In reply to | #111703 |
Hi Niels,
at first sorry for my late answer.
At Thu, May 09, 2024 Niels Thykier wrote:
> You are welcome to quote me in public, though I feel it will not help your
> cause. This reply is in private to you, so you can choose whether you want
> to quote me.
I think any answer should be discussed.
> I agree with the sentiment that important Debian tools would ideally be
> co-maintained. However, in the passing years, I have started to feel a
> disconnect with lintian, its direction and what I would like to see. I no
> longer use lintian and I am fundamentally not interested in picking up
> lintian anymore - neither as a user nor as a contributor. I have even
> uninstalled it from my machines. For now, I still "allow" it in my salsa-ci
> pipeline but my patience with it is thin.
This is not the first message I've read about insufficiencies in lintian.
That's why I initially brought up this topic. I consider a tool that checks
conformance to our policy essential. Therefore, I think it is important to
discuss critical points as soon as I become aware of them. Lintian has saved
me from countless mistakes in the past, and I heavily rely on it in my
packaging work. I use it after every package build, as well as in Salsa CI.
> For me, lintian fails in all roles it has. It is not a good tool for newbies
> to get help, since it can only test build artifacts. As an example, your
> feedback look is a full package build followed by unpacking the package just
> so lintian can tell you have a typo on line 4. That is a massive waste of
> resources - notably developer time and mental bandwidth.
I understand your point about having a tool that checks the debian/ dir for
issues like spelling errors, binary files in the upstream source, and other
concerns right within the packaging tree before the build starts. However, I
don't understand why you mention newbies in this context.
> It also fails as an archive QA tool in my view since the FTP masters have
> been unwilling to upgrade to any recent version of lintian.
Perhaps a ftpmaster could explain this in detail. As far as I understand,
it's also a DSA issue. All packages are obtained from stable. I agree that
this does not make sense for a policy checker of packages targeting
unstable. Picking Lintian from backports or implementing some serviщe
featuring latest lintian might be alternatives, but it's not my task to
decide this.
> I think FTP
> master's argument lies with the very poor performance in certain corner
> cases that adversely affects larger packages (like linux).
I did not read this argument but it would be great to hear some educated
opinion.
> As a consequence,
> people now get auto-rejects when uploading because lintian on the FTP master
> server does not produce the same output as current lintian in stable or
> newer.
I think its a bit unfair to blame lintian about the fact that its old
versions do not do a proper job when it comes to checking newer packages.
> For the record, I support the FTP masters here since the performance was
> quite horrible at some point (might be fixed, might not be) and that would
> just block benign uploads. In fact, I would go so far as to say that the FTP
> masters should remove lintian from their upload checks (partly because of
> this, partly because only source packages are reliably checked which neuters
> the original point of adding lintian to the upload queue).
I would love to hear some ftpmaster opinion to avoid speculation about this
topic.
> The latter half (archive-wide qa + performance + trust) might be fixable
> with a dedicated effort and then a lot of lobbying to restore's people trust
> in lintian.
As far as this thread has shown there are some people who do not share your
opinion and as far as it concerns me my trust into lintian is not broken.
> But that is a lot of work, and it will not solve the former
> (feedback cycles). The former requires a completely different mindset and
> scope for the tooling.
I'm convinced that we need a tool to check the final build result. Lintian
was written for this purpose, and despite its performance issues, it does a
good job IMHO. I agree with you that adding the feature to check the source
tree would be a significant enhancement. I would welcome it if Lintian
received this feature or if a new tool could fulfill this additional role.
> To that end, I have decided to put my effort into `debputy` where I recently
> added support for linting *with* quickfixes, reformatting and editor support
> (the latter via LSP).
I admit I'm very curious about debputy since all I've read about so far
sounds very interesting. Unfortunately I'm lacking the time to test it.
BTW, totally unrelated to the lintian topic: To my package maintainers
perception you are the only developer of debhelper. Feel free to contact me
if you are not happy about this situation. I'm personally always concerned
if essential tools are maintained by single person "teams".
> I think that a much better approach to half of the
> issues that lintian emits
IMHO this is the point: We need lintian for "the other half" in any case
and to cover this we need people who keep on caring for lintian - at least
as long as we do not have anything better.
> and helps both newcomers and long term
> contributors to be much more productive.
>From my point of view I would not make the distinction between newcomers and
long term contributors. IMHO the problems you state are perfectly
orthogonal to the knowledge level of the lintian user.
> Especially for the editor support
> related parts, where people get instant feedback both on issues and the fix,
> automatic reformatting on save and completion suggestions. None of which
> lintian or wrap-and-sort are capable of.
If you ask me personally I'm absolutely happy about a policy checker that
simply reports issues. I'm fine with firing up an editor in some other
terminal and be done. Maybe I'm missing your point but for me that's a
non-issue. Or is your comparison with wrap-and-sort rather targeting at
some tool that automatically fixes the issues it has found and I can check
the changes afterwards with `git diff`? Or something like the janitor tools
that even commit changes?
> If I am successful, then lintian can specialize its efforts into issues only
> visible in packaged artifacts and thereby reduce it scope a bit.
Perfect. I'd love to have some policy checking at "the right point in
time". I'd love to support this but as far as I understand even your
suggestion does not spare the work of fixing lintian itself. The problem
that motivated me to my initial mail to ask for help on lintian was about
packaged artifacts and we need to keep an eye on this - no matter how nifty
things we do before.
> In that
> sense, my work might be a (minor) help to the Lintian team on the assumption
> they are willing to specialize more.
I personally can't imagine that lintian maintainers insist on doing work
that is done by someone else in some more appropriate way. My personal
opinion about the people who grabbed up the pieces that were left after some
problematic time is that they are very sane and open for any constructive
discussion. I'd happily stir such discussion (even if I feel myself not
very competent in technical details).
> But even if I am not successful with
> `debputy`, I cannot imagine I would consider returning to lintian. It does
> not scratch my itch and years of issues (some of which are still unfixed)
> have made me not want to have anything to do with the tool.
Well, we are all volunteers and for sure nobody intends to convince you to
work on anything you don't want to. But anyway I read from your mail that
you see some need for lintian being maintained. The fact that there are
issues unfixed for years was the reason for my initial mail. I keep on
hoping that it might lead to some new contributors.
Given your very interesting input we actually need people who are able to
dedicate quite some time on restructuring lintian in a way that respects the
fact that some checks can be done / are done by some other tool on source
level. Alternatively lintian itself could be modularised to rather do what
you want.
> Best of luck to Axel and anyone joining him to stop the bleeding. I do hope
> they are successful, since lintian still have valuable features for Debian
> as a whole that can be salvaged.
Thank you for stating this explicitly.
> But I am not going to be the "hero" that
> salvages that mess. If I am going to do heroics in this area, then it will
> be related to `debputy` with the aim to enable us to spend less mental
> bandwidth on daily packaging work.
That's cool and thanks for all the work you are putting in our packaging
infrastructure.
> PS: In my view, the bleeding of lintian's quality started long before Axel
> joined the lintian maintenance team and I do not fault Axel for being unable
> to stop the bleeding. In my view, only a hero could have "managed" that at
> the expense of their mental health.
Thanks a lot for your mental support to Axel which I confirm from my side.
To draw some conclusion out of the discussion: We need to enhance the way
we are checking our packages for conformance with our policy. You made
clear that quite a part can be done at source level. I'm not fully sure
whether your main focus is on the time inside the build process or the
editing features you mentioned. It is also not clear to me whether you are
questioning the general architecture like for instance the rule sets that
are in /usr/share/lintian/data. IMHO this is a valuable set of rules that
can be used by alternative tools as well. Do you agree with this or not?
As I wrote in my other mail in this thread[1] I could imagine some policy
checker step after dh_clean. When thinking twice about it another step
could be done before dh_builddeb which could detect lots of issues before
the package is built and can save the unpackaging step. Are you targeting
at this as well?
Kind regards and thanks a lot for your inspiring input
Andreas.
[1] https://lists.debian.org/debian-devel/2024/05/msg00162.html
[toc] | [prev] | [next] | [standalone]
| From | Andrey Rakhmatullin <wrar@debian.org> |
|---|---|
| Date | 2024-05-19 13:10 +0200 |
| Message-ID | <IFMAp-eoHd-5@gated-at.bofh.it> |
| In reply to | #111803 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, May 19, 2024 at 12:49:29PM +0200, Andreas Tille wrote: > > It also fails as an archive QA tool in my view since the FTP masters have > > been unwilling to upgrade to any recent version of lintian. > > Perhaps a ftpmaster could explain this in detail. As far as I understand, > it's also a DSA issue. All packages are obtained from stable. Per e.g. the discussion on #debian-devel on 2024-04-01, this specific package is older than even that. Per the same discussion, we don't have (or at least couldn't find) an *official* reason for that, only speculation. But, sure, running lintian from stable on packages for unstable can also cause problems up to autorejects. > > As a consequence, > > people now get auto-rejects when uploading because lintian on the FTP master > > server does not produce the same output as current lintian in stable or > > newer. > > I think its a bit unfair to blame lintian about the fact that its old > versions do not do a proper job when it comes to checking newer packages. Yes. -- WBR, wRAR
[toc] | [prev] | [next] | [standalone]
| From | Scott Kitterman <debian@kitterman.com> |
|---|---|
| Date | 2024-05-19 17:20 +0200 |
| Message-ID | <IFQul-eqZE-1@gated-at.bofh.it> |
| In reply to | #111804 |
On May 19, 2024 11:00:23 AM UTC, Andrey Rakhmatullin <wrar@debian.org> wrote: >On Sun, May 19, 2024 at 12:49:29PM +0200, Andreas Tille wrote: >> > It also fails as an archive QA tool in my view since the FTP masters have >> > been unwilling to upgrade to any recent version of lintian. >> >> Perhaps a ftpmaster could explain this in detail. As far as I understand, >> it's also a DSA issue. All packages are obtained from stable. >Per e.g. the discussion on #debian-devel on 2024-04-01, this specific >package is older than even that. Per the same discussion, we don't have >(or at least couldn't find) an *official* reason for that, only >speculation. >But, sure, running lintian from stable on packages for unstable can also >cause problems up to autorejects. We run the version of lintian that was packaged for the Debian version that's in use. Currently that's oldstable. Because the override format changed between oldstable and stable, it's a particular problem at the moment. Once we're on stable again, at least that aspect of the disconnect will go away. Note: as a lowly FTP Assistant, I don't know if that is * official* enough for you or not. No, I don't know when DSA will upgrade it. It's a matter of coordination between DSA and the FTP Team that I haven't personally been involved in. Scott K
[toc] | [prev] | [next] | [standalone]
| From | Otto Kekäläinen <otto@debian.org> |
|---|---|
| Date | 2024-05-20 22:10 +0200 |
| Message-ID | <IGhux-eHlE-1@gated-at.bofh.it> |
| In reply to | #111803 |
Hi!
> > If I am successful, then lintian can specialize its efforts into issues only
> > visible in packaged artifacts and thereby reduce it scope a bit.
>
> Perfect. I'd love to have some policy checking at "the right point in
> time". I'd love to support this but as far as I understand even your
> suggestion does not spare the work of fixing lintian itself. The problem
> that motivated me to my initial mail to ask for help on lintian was about
> packaged artifacts and we need to keep an eye on this - no matter how nifty
> things we do before.
As somebody who has contributed to a bunch of Debian packaging tooling
(Lintian, Deputy, git-buildpackage, Salsa-CI) I think Niels' approach
makes a lot of sense. Deputy is great for static analysis of Debian
packaging (i.e. are the files in debian/* syntactically and
semantically correct). Lintian could over time remove those checks and
focus only on analysing the build artifacts (as anyway Lintian can be
run only _after_ the build was done). Yes, Lintian needs to continue
to be maintained, but the maintenance work could be slightly less if
Lintian adopts the strategy/architecture of focusing only on
post-build artifact analysis.
Regarding this discussion in general, I get the sense that
participants haven't actually tried Debputy and are not aware of its
capabilities. If you have Podman/Docker you can effortlessly run this
little check to get some experience:
cd my-package
podman run --interactive --tty --rm --volume=$PWD:/tmp/my-package
--workdir=/tmp/my-package debian:sid bash
apt update && apt install -y dh-debputy python3-lsprotocol
debputy lint
Examples of output:
pedantic: File: ./debian/changelog:944:82:944:89: Line exceeds 82 characters
944: -
runtime-test-file-uses-supported-python-versions-without-python-all-build-depends
informational: File: ./debian/control:64:19:64:24: Latest
Standards-Version is 4.7.0
64: Standards-Version: 4.6.2
[toc] | [prev] | [next] | [standalone]
| From | Holger Levsen <holger@layer-acht.org> |
|---|---|
| Date | 2024-05-21 13:40 +0200 |
| Message-ID | <IGw0x-eQ4j-5@gated-at.bofh.it> |
| In reply to | #111838 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, May 20, 2024 at 01:00:00PM -0700, Otto Kekäläinen wrote: > Regarding this discussion in general, I get the sense that > participants haven't actually tried Debputy and are not aware of its > capabilities. If you have Podman/Docker you can effortlessly run this > little check to get some experience: > > cd my-package > podman run --interactive --tty --rm --volume=$PWD:/tmp/my-package > --workdir=/tmp/my-package debian:sid bash > apt update && apt install -y dh-debputy python3-lsprotocol > debputy lint and if you don't have docker but "just" trixie or sid, just run sudo apt install dh-debputy python3-lsprotocol debputy lint :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "I know what you're thinking" used to be an idiom but now it's a business model.
[toc] | [prev] | [next] | [standalone]
| From | PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> |
|---|---|
| Date | 2024-05-21 14:20 +0200 |
| Message-ID | <IGwDg-eQx1-5@gated-at.bofh.it> |
| In reply to | #111861 |
I tried it on one of my package silx
warning: File: ./debian/tests/control:22:14:22:19: It is possible that the value is a typo of "i386". [Correctable via --auto-fix]
22: Architecture: !i386
It seems wrong to me, the test control file allow !i386
Cheers
Frederic
[toc] | [prev] | [next] | [standalone]
| From | Niels Thykier <niels@thykier.net> |
|---|---|
| Date | 2024-05-21 15:30 +0200 |
| Message-ID | <IGxJ0-eR9D-19@gated-at.bofh.it> |
| In reply to | #111803 |
Andreas Tille:
> Hi Niels,
>
> at first sorry for my late answer.
>
> At Thu, May 09, 2024 Niels Thykier wrote:
> [...] >> For me, lintian fails in all roles it has. It is not a good tool for
newbies
>> to get help, since it can only test build artifacts. As an example, your
>> feedback look is a full package build followed by unpacking the package just
>> so lintian can tell you have a typo on line 4. That is a massive waste of
>> resources - notably developer time and mental bandwidth.
>
> I understand your point about having a tool that checks the debian/ dir for
> issues like spelling errors, binary files in the upstream source, and other
> concerns right within the packaging tree before the build starts. However, I
> don't understand why you mention newbies in this context.
>
My core argument is the feedback cycle is excruciatingly complicated and
slow compared to what it needs to be for validation of "debian/*" files.
In my view, the problem is amplified for newcomers in multiple areas.
>> [...]
>> As a consequence,
>> people now get auto-rejects when uploading because lintian on the FTP master
>> server does not produce the same output as current lintian in stable or
>> newer.
>
> I think its a bit unfair to blame lintian about the fact that its old
> versions do not do a proper job when it comes to checking newer packages.
>
Is it now? When I maintained lintian, I was of the understanding that
the dak usage was an explicit use-case we, as lintian maintainers, were
expected to support. In my time, I would have considered this situation
as an RC bug against lintian if I had this change and the FTP masters
were unable or unwilling to install the -backports version of lintian.
On the other side of the "unfairness" coin, I feel it is unfair to have
people spend volunteer time being stuck in a painful cycle of "It works
on my machine, but dak rejects it because lintian is not updated on the
FTP masters machine" for which they are expected to ignore lintian
warnings locally to get out of (you need overrides in the old format,
which the new lintian then complains about - damned if you, damned if
you don't). Those are volunteers that wasted their Debian time being
cauhgt between lintian and dak and, in my book, that was much more
unfair than having lintian (or dak) and its maintainers own up to it.
I feel we, as a distribution, should ensure such problems do not happen.
As stated, in my time as a lintian maintainer, I felt the responsibility
was with lintian and that is why I blame lintian.
Maybe times have changed here and we, as a distribution, no longer hold
lintian accountable here. Not sure who is then, but maybe that is part
of why this problem has existed for so long.
(For the record, I think the ship sailed on this one. I am not expecting
Alex to go retroactively fix this problem on the lintian side. I expect
us not to repeat this mistake again)
>> [...]
>> Especially for the editor support
>> related parts, where people get instant feedback both on issues and the fix,
>> automatic reformatting on save and completion suggestions. None of which
>> lintian or wrap-and-sort are capable of.
>
> If you ask me personally I'm absolutely happy about a policy checker that
> simply reports issues. I'm fine with firing up an editor in some other
> terminal and be done. Maybe I'm missing your point but for me that's a
> non-issue. Or is your comparison with wrap-and-sort rather targeting at
> some tool that automatically fixes the issues it has found and I can check
> the changes afterwards with `git diff`? Or something like the janitor tools
> that even commit changes?
>
I feel my point is not coming across at all and that is frustrating me a
bit.
Imagine you need to change `debian/control` for some reason regardless
of the situation that triggered this. You open up your editor and do the
change. In the process, you make a mistake.
The current workflow is:
1) Edit file (introducing mistake)
2) No feedback in the editor, so:
a) You save the file
b) Build an artifact that lintian can check
c) Run lintian to get the feedback
3) You correct the mistake.
4) Rinse and repeat all the sub-steps of 2) to validate there are no
mistakes.
This is the workflow you have today with lintian. And it applies equally
to all kinds of mistakes from policy violations, to textual or semantic
typos.
Now, I would like you to step away from the status quo. What this
workflow *should* have been in my view is:
1) Edit file (introducing mistake)
2) Editor shows a "Here is a mistake"-marker.
3) You correct the mistake (either manually or via a quick fix)
4) Editor removes a "Here is a mistake"-marker.
5) Save the file
Notice here that I do not need to leave my editor to get feedback. I get
it automatically, so I cannot forget it nor am I inclined to skip the
check in a hurry. This is the crux of my problem with status-quo
feedback loop. I have *actively* ask for feedback. I have to wait for it
too which becomes paper cut.
These are unnecessary a mental burden and paper cuts for a
considerable part of problems you can introduce via editing `debian/*`
files. IDEs have solved this problem very well via their near instant
feedback loops. I feel we are long overdue for that.
Similarly, when you consider the reformatting flow of today, the flow is:
1) Edit file
2) Save file.
3) Run `wrap-and-sort` to reset formatting.
- Where I, by the way, have to manually pass the correct formatting
options.
In the workflow I want, the cycle is:
1) Edit file
2) Save file, which causes the editor reformat automatically *).
Here; I do not have to remember to reformat the file. The editor does it
for me. It is automatically correct rather than correction due to active
manual labor on my part.
Obviously, the status quo workflow is possible. We have been doing it
for years. However, we should not make a human do the work of a machine.
Make the machine do what it does best; follow the same procedure every
time. This enables us to free up mental bandwidth of our human
volunteers for other things.
*) For packages that have opted in to automatic styling, since this is
not a mandatory thing. Stating this explicitly to avoid the conversation
detailing into a question of this being imposed.
>> [...]
>> But even if I am not successful with
>> `debputy`, I cannot imagine I would consider returning to lintian. It does
>> not scratch my itch and years of issues (some of which are still unfixed)
>> have made me not want to have anything to do with the tool.
>
> [...]
>
> Given your very interesting input we actually need people who are able to
> dedicate quite some time on restructuring lintian in a way that respects the
> fact that some checks can be done / are done by some other tool on source
> level. Alternatively lintian itself could be modularised to rather do what
> you want.
>
Both in-editor feedback and the "debian files of an unpacked source
tree" are the parts I am trying to cover with `debputy` (via `debputy
lsp server` + `debputy lint/reformat` respectively)
I do not see lintian expanding to in-editor feedback. It is a massive
undertaking in its own. Given no one have solved the "run lintian on an
unpacked source tree" yet, which would be a prerequisite and also a
considerable undertaking on top, I doubt we will ever see it. I also do
not see any note worthy benefit of attempting direct code reuse from
lintian at this step.
When you work on in-editor feedback, you will need at least:
1) A lenient parser that keeps track of all sorts of things like
syntax errors, white space, and comments that is usually the first
thing your parser throws away to keep things simple. Ideally, it
also:
- supports reading a string or a line of lines, since the editor
content are not always persisted to the file system. Instead, you
get it from "somewhere else" (fed via socket in the LSP case)
- continues after syntax errors, since otherwise you only get one
error on syntax errors and most other feedback disappears, which
can be annoying to the user. Especially important for completion
since the half-finished typing might be syntactically be invalid.
(Also, inserting a field in a deb822 stanza will temporarily split
the stanza into two where at least one of them will definitely
be invalid. You will want to be able to compute the completion
as-if the stanzas are not split despite the file being
"stanza, empty line / syntax error, stanza")
2) Additionally, you need to know file ranges of everything. One thing
is identifying that the `foriegn` value in the `Multi-Arch` field
was a typo of `foreign`. But for editor support, you have to tell
the editor where to put the marker. That range is different in all
of the cases below:
Multi-Arch: foriegn
Multi-Arch:foriegn
Multi-Arch:
# Comment for the sake of the argument; probably breaks
foriegn
In all cases, the marker should be on the `foriegn` work because
that is where the mistake. If you are lucky, you get the line number
where `Multi-Arch:` appears and then you get retrace things
manually. That gets even more complicated for non-string types or
where parser "cleans" up things for you. As an example, with most
deb822 parsers, it is hard to tell `Multi-Arch:foreign` apart from
`Multi-Arch: foreign`, since the white space is to be trimmed in
that particular case.
Note ranges goes two ways. For diagnostics (linting), you tell the
editor where the marker goes. For completion and hover docs, the
editor tells you where the user is and you have to figure out what
is at that point (file "debian/control, line 22, column 14"). This
means you need a two-way mapping between content and position.
Here, lintian only does one way mapping, and it only does basic
positioning (like line or line + column). For code reuse, it would
have to do full range of issues.
3) You will need a lot of extra metadata that no one else will need.
As an example, a simple linter might get away with knowing that
"Multi-Arch" is a known field and has 4 allowed values. A complex
one would know about 4 values with one of them being conditional
on the Architecture field (which is less trivial to share in
data-only format). If you do an on-line editor feature with:
- hover docs, then you need the main documentation you want to show
the user for the field and each of the values (depending on what
the user requests docs for). Hover docs are partially static and
partially dynamic data, which makes general purpose sharing of
this data less trivial.
- completion, then you may want to have a one-liner documentation
for the values. Maybe some sorting hints to the editor, so it
knows it should de-emphasis "allowed". Additionally, you want
to track whether the values you offer are allowed in this context
(which for Multi-Arch means checking the `Architecture` field,
while for `Protected` it is static metadata that `no` is the
default and the default would trigger a warning.)
- In all of the above cases, you also want fields / data about
things you cannot check. A linter does not need to know about
all fields it cannot check (other than maybe for field name
canonicalization purposes, a.k.a. "cute-field"). In the editor
support, every known field is now also part of the completion
"vocabulary" and hover docs may still be useful.
4) Mentally to structure your work will be built around the user
interacting with the editor. That is, you will be forced into an
event driven architecture. Latency is visible to the user and will
annoy them. A full second is a long wait at this point.
Related, the user typing is sometimes multiple events because the
user happened to type a bit too slow or maybe they stopped typing
midway. So you want support for stopping long running diagnostics,
so you do not build up a queue of pending but now irrelevant
diagnostics.
Lintian, for comparison, is entirely in a batch driven architecture,
where latency of most steps was never important.
This is beyond the particular "idiosyncrasies" of how the LSP
specification and tracking what the editor supports, when to provide
what information to the editor, etc.
I can tell you with absolute certainty that lintian is ready for
basically none of the above. It was not built for it and parts of this
are an absolute pain to do. You do that because you have to do it to
work with the editor support, not to support another project while you
are already drowning in work trying to keep the project afloat.
Additionally, for a linter (hammer), every thing is a diagnostic (nail).
For an editor integration, you have a more varied toolbox. As an
example, `debputy` does not emit diagnostics for trailing white space
like lintian does (with `--pedantic` as I recall). Instead, `debputy`
fixes them automatically on saving where relevant. Because that is a
better solution for the user when you are not forced to solve everything
like a linter (hammer).
Accordingly, even if it was possible to share all the lintian code, I
would not want all of it meaning that lintian would now need conditions
for "things `debputy` wants vs. things `debputy` does not". Again, not
the thing you need trying to keep your project afloat.
>> [...]
>> PS: In my view, the bleeding of lintian's quality started long before Axel
>> joined the lintian maintenance team and I do not fault Axel for being unable
>> to stop the bleeding. In my view, only a hero could have "managed" that at
>> the expense of their mental health.
>
> Thanks a lot for your mental support to Axel which I confirm from my side.
>
> To draw some conclusion out of the discussion: We need to enhance the way
> we are checking our packages for conformance with our policy. You made
> clear that quite a part can be done at source level. I'm not fully sure
> whether your main focus is on the time inside the build process or the
> editing features you mentioned.
The `debputy` framework has two different "legs" here. One is the
in-editor feedback with some batch counter parts for CI pipelines, which
aims to be generally applicable to all packages.
The other leg is `debputy` self-checking the packaging instructions for
packages built with `debputy`. In a sense, this also counts as policy
checking but it is not a static analysis and therefore is not comparable
to lintian.
> It is also not clear to me whether you are
> questioning the general architecture like for instance the rule sets that
> are in /usr/share/lintian/data. IMHO this is a valuable set of rules that
> can be used by alternative tools as well. Do you agree with this or not?
>
I find that data to be of questionable value to my work at the present
time or other tools in this area:
1) I do not remember lintian every committing to these being part of
its API. Indeed, I see some files that have changed format since
my time there and they often also engineered to fit lintian specific
needs rather than being general purpose data files.
2) A large part of the files would not be relevant to my work since
I am not looking at upstream code or packaged artifacts.
3) In my work, I would need a lot extra auxiliary metadata that lintian
will not need (per my remarks above on doing your own editor
integration).
Obviously, there could be value in sharing rules, data and metadata of
this kind with other interested projects. Jelmer and I already discussed
this possibility in relation to `lintian-brush`. However, it is not
something solved by simply declaring `/usr/share/lintian/data` as stable
API. Instead, I would rather extract subsets of it into a general
purpose data package as needed.
Ideally one where we can release the data faster than checkers, so we do
not get the annoying effort that a new debian-policy upload triggers our
static analysis tools being out of date for weeks or even months.
Side-bar: This debian-policy problem is one reason why `debputy` does
not flag "newer-standards-version" as a problem (only older). I do not
want to repeat this problem in `debputy`.
It is a trade-off, because a typo could make the version too new by
mistake and that would be silent in `debputy` at the moment. So I am
definitely interested in outsourcing part of the data.
> As I wrote in my other mail in this thread[1] I could imagine some policy
> checker step after dh_clean. When thinking twice about it another step
> could be done before dh_builddeb which could detect lots of issues before
> the package is built and can save the unpackaging step. Are you targeting
> at this as well?
> > Kind regards and thanks a lot for your inspiring input
> Andreas.
>
> [1] https://lists.debian.org/debian-devel/2024/05/msg00162.html
>
No, I am not targeting this for `debhelper`. If you build a package with
`debputy` instead of `debhelper`, there are some built-in self-checks of
the provided packaging instructions compared to the "about to be
produced"-package. It is conceptually similar to `dh_install` erroring
out when you reference `usr/bin/foo` and `dh_install` cannot find said file.
It would not be difficult to add some form of policy checking layer on
top of this, though the question is what we want to check at this point
where the helper should not just fix it instead. If the tool can fix it,
then it is better than "here is a problem for you to read up on and then
fix manually even though there was only one obvious solution". One thing
requires brain-cells, the other does not.
My end goal with `debputy` is that the average contributor should spend
less brain-cells on packaging. That way, a contributor gets a better
"mileage" than they do today. That is why I am a bit hesitant about
doing "in build policy checker". Though, feel free to present concrete
cases and I will consider it.
Best regards,
Niels
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.devel
csiph-web