Re: Any volunteers for lintian co-maintenance?
On Thu, 09 May 2024 13:57:28 -0700, Soren Stoutner 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
Re: Any volunteers for lintian co-maintenance?
I also think that Lintian is one of the most important tools in Debian packaging ecosystem. I'm not a Debian Developer, but have built packages for our Debian derivative distribution (Pardus, which I tech-led it for some time). The first step was to get the package "Lintian-clean (TM)" before even testing it. I would love to help to make Lintian faster, but unfortunately I don't know any Perl, so touching an advanced package like this will take a lot of time (learn Perl -> get somewhat proficient -> start hacking Lintian). I might be able to profile it though to understand its pain points, which I'll try to give a go. Cheers, H. On 9.05.2024 ÖS 11:57, Soren Stoutner wrote: 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 salsa.debian.org/lintian/lintian/-/merge_requests/461> 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/msg0.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 ne
Bug#1070834: ITP: python-pystow -- file management utility library for Python programs
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pystow Version : 0.5.4 Upstream Contact: Charles Tapley Hoyt * URL : https://github.com/cthoyt/pystow * License : MIT Programming Lang: Python Description : file management utility library for Python programs This library can replace the boilerplate code one is needed to write in order to maintain files in $HOME --- This is a new depedency needed to upgrade 'pybel'.
Re: Open "NMU diff for 64-bit time_t transition" bugs
Hi On 2024-05-10 08:29:28 +0300, Andrius Merkys wrote: > I care for tree packages which still have open "NMU diff for 64-bit time_t > transition" bugs: libccp4, macromoleculebuilder and rdkit. All of them have > NMU diffs applied in experimental, but not in unstable yet. What should I do > about them - apply NMU diffs to unstable as well, or wait for someone > performing the time_t64 transition to do that? You can also check iif the changes were applied in Ubuntu. For libccp4, there was an upload with this changelog entry: libccp4 (8.0.0-2ubuntu1) noble; urgency=medium * Rename libccp4c0 package as although it is not affected by the time_t transition to 64-bits, it is affected by the LFS migration which is implied by the time_t changes. If in doubt, please also try to reach out to Steve Langasek and the others that were driving the t64 transition. Cheers -- Sebastian Ramacher
Re: Any volunteers for lintian co-maintenance?
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 fea
Bug#1070846: ITP: smatch -- a static analysis tool for C
Package: wnpp Severity: wishlist Owner: "Ricardo B. Marliere" X-Debbugs-Cc: debian-devel@lists.debian.org, dan.carpen...@linaro.org, rica...@marliere.net * Package name: smatch Version : 1.73 Upstream Contact: sma...@vger.kernel.org * URL : https://smatch.sourceforge.net/ * License : GPLv2+ Programming Lang: C Description : a static analysis tool for C Smatch is a code checking framework developed by Dan Carpenter on top of Sparse [1]. It extends Sparse with useful functionality in the scope of the Linux Kernel such as data-flow analysis which makes it possible to detect such things as conditions that will always (or never) be true, pointers that might be null, and locks that end up in different states depending on which path is taken through the code [2]. A good introduction was written by Dan himself [3] and he also had a mentorship session about it [4], which goes in detail about its usefulness. [1] https://tracker.debian.org/pkg/sparse [2] https://lwn.net/Articles/691882/ [3] https://blogs.oracle.com/linux/post/smatch-static-analysis-tol-overview-by-dan-carpenter [4] https://events.linuxfoundation.org/mentorship-session-smatch/
Re: new upstream version fails older tests of rdepends packages
Le Wed, May 08, 2024 at 08:41:47PM +0200, Paul Gevers a écrit : > Hi, > > On 08-05-2024 6:06 p.m., Bill Allombert wrote: > > Agreed, but gap does not actually breaks anything, it is just the tests > > in testing that are broken. So I can do that but that seems a bit > > artificial. > > Aha, that wasn't at all clear to me. If you don't want to do the artificial > thing (which is fine, except now you depend on members of the release team), > I'll manually schedule the tests. Maybe tomorrow. Thanks a lot, this fixed the issue, all packages have migrated to testing now. I still think this is a much better outcome than a new upload with spurious Breaks:. Cheers, -- Bill. Imagine a large red swirl here.
Re: Solving a file conflict between package "nq" / "fq"
Le Mon, May 06, 2024 at 11:09:14PM +0200, Preuße, Hilmar a écrit : > Hi all, > > during the preparation of a new version of package "nq" (via NMU) it was > found that there exists a file conflict with package "fq" (#1005961), which > was incorrectly solved in the past. For now I unarchived and reopened the > old issue. According to the policy: > > "Two different packages must not install programs with different > functionality but with the same filenames. (...) If this case happens, one > of the programs must be renamed. The maintainers should report this to the > debian-devel mailing list and try to find a consensus about which program > will have to be renamed. (...)" > > Hence I contact this list. Is there a formal process to generate decisions / > consensus? Please note that I'm not the maintainer of "nq" and I'm not in > the position to rename binaries to solve file conflicts. As first approximation, the oldest package win, for the simple reason that doing the other way would break users scripts, and it is not in the interest of Debian to encourage upstream to hijack each other program names. After that the maintainers or the ctte could agree to operate a transition to other names. Cheers, -- Bill. Imagine a large red swirl here.
Re: Any volunteers for lintian co-maintenance?
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 ..
Re: Bug#963101: cozy-audiobook-player: "Request For Package"
Hi, I am currently working on this package [0]. I would need a sponsor to review and upload the package. Thanks Manuel [0] https://salsa.debian.org/manut/cozy
Re: Any volunteers for lintian co-maintenance?
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 signature.asc Description: PGP signature
Re: Any volunteers for lintian co-maintenance?
Hello, On 2024-05-10 17:35, Nilesh Patra wrote: On Fri, May 10, 2024 at 04:06:15PM +0200, Andreas Tille wrote: 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. Lintian is important to me likewise. It taught me a lot when I was learning to package, and today it is still an indispensable tool for me, helping to avoid rookie mistakes, typos and other mistakes. 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. Do you mean bugs on bugs.d.o, or are there other issues? 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. Best, Andrius
Re: Any volunteers for lintian co-maintenance?
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 signature.asc Description: PGP signature
Re: Any volunteers for lintian co-maintenance?
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 signature.asc Description: PGP signature
Bug#1070864: ITP: golang-github-stratoberry-go-gpsd -- GPSD client
Package: wnpp Severity: wishlist Owner: Francisco Vilmar Cardoso Ruviaro X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org, vil...@debian.org * Package name: golang-github-stratoberry-go-gpsd Version : 1.3.0 Upstream Contact: Josip Lisec * URL : https://github.com/stratoberry/go-gpsd * License : Expat Programming Lang: Go Description : GPSD client go-gpsd is a streaming client for GPSD's JSON service and, as such, can be used only in an async manner, unlike clients for other languages which support both async and sync modes.
Re: Any volunteers for lintian co-maintenance?
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 (
Re: Solving a file conflict between package "nq" / "fq"
On 10.05.2024 14:53, Bill Allombert wrote: Le Mon, May 06, 2024 at 11:09:14PM +0200, Preuße, Hilmar a écrit : Hi Bill, thanks for the answer! during the preparation of a new version of package "nq" (via NMU) it was found that there exists a file conflict with package "fq" (#1005961), which was incorrectly solved in the past. For now I unarchived and reopened the old issue. According to the policy: As first approximation, the oldest package win, for the simple reason that doing the other way would break users scripts, and it is not in the interest of Debian to encourage upstream to hijack each other program names. Well, then: nq is the older package and has a (slightly) higher popcon. After that the maintainers or the ctte could agree to operate a transition to other names. Is there anything, which needs to be done from maintainer side? Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Any volunteers for lintian co-maintenance?
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. Imagine a large red swirl here.
