Bug#1014885: lintian wrongly complains about XS-Go-Import-Path
Hi, I can confirm this issue for lintian 2.116.0 against src:piuparts as it is in git or unstable. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ First they came for the journalists, we don't know what happened after that. signature.asc Description: PGP signature
future of lintian.d.o?
hi, first: it's great that lintian is under active development again! second: it's great that UDD now has up2date information from current lintian runs! (I've bcc:ed abe@d.o and lucas@d.o out of courtesy, so they see this but won't get every reply cc:ed.) Now my questions, as raised on #debian-qa: < h01ger> lintian.d.o used to show verbose information how to fix those issues found. now on eg https://udd.debian.org/lintian/?packages=munin i cannot find that. are there plans to add this back? < h01ger> and is there a bug tracker for udd.d.o/lintian? < h01ger> and are there plans to shutdown lintian.d.o or redirect it to udd.d.o/lintian? The 2nd question I could answer myself by now: https://wiki.debian.org/UltimateDebianDatabase/ is pointed out in the footer of every UDD page, and that pages points to https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=udd;users=qa.debian@packages.debian.org for UDD bugs. Shall I just file a bug for question 1 and 3? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Historians have a word for Germans who joined the Nazi party, not because they hated Jews, but out of hope for restored patriotism, or a sense of economic anxiety, or a hope to preserve their religious values, or dislike of their opponents, or raw political opportunism, or convenience, or ignorance, or greed. That word is "Nazi". Nobody cares about their motives anymore. signature.asc Description: PGP signature
Bug#996943: lintian: fails to unpack strip-nondeterminism source package
Package: lintian Version: 2.109.0 Severity: normal X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, lintian fails to unpack the current strip-nondeterminism source package, and thus also fails to properly check the package: $ schroot -- lintian --info --pedantic --display-info strip-nondeterminism_1.12.0-2_source.changes N: E: strip-nondeterminism source: unpack-message-for-orig strip-nondeterminism_1.12.0.orig.tar.bz2 ar failed for strip-nondeterminism-1.12.0/t/failures/ar/857975.a N: N: Unpacking the contents of this source package produced the listed error. N: N: It probably means something is broken or the package was somehow constructed in a strange way. You may wish to report this as a bug to upstream. N: N: Visibility: error N: Show-Always: no N: Check: lintian N: N: I: strip-nondeterminism source: unpack-message-for-source ar failed for t/failures/ar/857975.a N: N: Unpacking the contents of this source package produced the listed error. N: N: It probably means something is broken or the package was somehow constructed in a strange way. N: N: Visibility: info N: Show-Always: no N: Check: lintian N: using these files, which I've just uploaded to unstable, as dpkg and pbuilder nicely cope with the same source package: d451c96fe2094b1c42c52af258f9ac88 strip-nondeterminism_1.12.0-2.debian.tar.xz 5c0c59ab0996881055ca69810c43e702 strip-nondeterminism_1.12.0-2.dsc 736f82cc28615279e6ba01e9ba8d59f7 strip-nondeterminism_1.12.0.orig.tar.bz2 (and this also can be seen with strip-nondeterminism_1.12.0-1.dsc...) I suspect this is because t/failures/ar/857975.a which is part of the package is an ar archive. Thanks for maintaining lintian! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ There are no jobs on a dead planet. (Also many other things but people mostly seem to care about jobs.) signature.asc Description: PGP signature
Bug#964013: lintian: embedded-javascript-library should flag sphinx files too
Hi, On Mon, Jul 13, 2020 at 12:24:53PM +0200, Alexis Murzeau wrote: > I'm getting this new lintian warning for language_data.js, > but I can't find which binary package I should depend on. > > "sphinx" (as suggested by lintian) is a virtual package provided by > python3-sphinx > which doesn't contain "language_data.js" [0] and libjs-sphinxdoc (which seems > more > appropriate) does not contain "language_data.js" either [1]. [...] > This will help maintainers find the correct package to use. https://salsa.debian.org/debian/developers-reference/-/commit/29014c3d02b1a44aa983557b4887f4302c2136c5 shows how to use dh_sphinxdoc (instead of dh_linktree which also does and did the right thing here), which then in turn adds the right depends/recommends to the binary packages. (The dh_linktree solution used a hack/workaround in d/rules to turn the depends into recommends, but I recommend the dh_spinxdoc solution anyway.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Bug#964111: dpkg-source: False positive 'points outside source root'
On Tue, Jul 07, 2020 at 03:52:08PM +0200, Guillem Jover wrote: > Holger, as I mentioned some days ago, I consider this case a > regression which I was planning on fixing. This fix was already > included earlier today in the dpkg 1.20.4 upload. :) yup, I've seen this today. Thank you! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Bug#964111: dpkg-source: False positive 'points outside source root'
On Mon, Jul 06, 2020 at 09:08:43PM -0700, Felix Lechner wrote: > > not sure if this is the same bug or just a similar one: > > lrwxrwxrwx 1 user user 9 Jul 3 16:07 debian/munin.service -> /dev/null > As for Holger's package, Lintian also flags that condition. Source > packages can be unpacked anywhere. We likewise consider absolute > symlink targets unacceptable there. > W: munin source: absolute-symbolic-link-target-in-source > debian/munin.service -> /dev/null sigh. so IMNSHO now lintian *and* dpkg are buggy. Or point me to policy which prohibits files pointing to /dev/null. This worked for years. (I haven't cloned the dpkg bug yet, as I believed Guillem would upload a fix quickly and thus I wanted to prevent busy paperwork. IMO the bug should be cloned and the severity raised to serious for the clone.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#964013: lintian: embedded-javascript-library should flag sphinx files too
Package: lintian Version: 2.82.0 Severity: wishlist Dear Maintainer, running lintian on developers-reference 11.0.12 from bullseye results in two warnings: W: developers-reference-ru: embedded-javascript-library usr/share/developers-reference/ru/_static/jquery.js please use libjs-jquery W: developers-reference-ru: embedded-javascript-library usr/share/developers-reference/ru/_static/underscore.js please use libjs-underscore I fixed those two in 11.0.13 in sid, but there are still embedded javascript libraries included, which lintian does not detect: $ dpkg -L developers-reference|grep js /usr/share/developers-reference/_static/doctools.js /usr/share/developers-reference/_static/documentation_options.js /usr/share/developers-reference/_static/language_data.js /usr/share/developers-reference/_static/searchtools.js /usr/share/developers-reference/_static/switchers.js /usr/share/developers-reference/searchindex.js /usr/share/developers-reference/_static/jquery.js /usr/share/developers-reference/_static/underscore.js Out of these, three of them come from Sphinx: - doctools.js - language_data.js - searchtools.js Please make lintian complain about embedding those. It seems the problem could be quite widespread: $ for i in doctools.js language_data.js searchtools.js ; do apt-file search "_static/$i" | wc -l ; done 1046 977 1046 -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning
On Fri, Apr 24, 2020 at 10:22:22AM +0100, Chris Lamb wrote: > > definitly, yes, filing this bug now. > As mentioned elsewhere, this was already fixed yesterday in fd8ee67d. ah, cool! & thanks for the quick fix! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning
package: lintian version: 2.67.0 x-debbugs-cc: Debian Med Project List , Debian Developers , Debian Lintian Maintainers , reproducible-bui...@lists.alioth.debian.org On Fri, Apr 24, 2020 at 09:56:24AM +0200, Andreas Tille wrote: > today I've seen the first time this new lintian warning: > >mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team > > > I wonder whether we could this set from severity Warning to Pedandic. definitly, yes, filing this bug now. > The point is that this address works not only as maintainer but rather > as key in several infrastrutural use case like database queries etc. > The only reason that would convince me that a change is needed would be > that the redirect to alioth-lists.debian.net would not work any more at > some foreseable point of time. So please note: I would not mind about > automatically replacing that address with something non-obsolete since > we try to do some turnover of all (about 1000) Debian Med packages per > release. But once we start this change several tools will stop working > reliably. This is to much effort for something that looks cosmetical in > my eyes. So if you insist that this should be at severity warning I'll > probably rather add a lintian override automatically for all our > packages rather than automatically change the maintainer address. we also still use reproducible-bui...@lists.alioth.debian.org as our maintainer address for Reproducible Builds related packages and it's our advertised point of contact for Debian related Reproducible Builds stuff and we don't have any plan to change this any time soon. It's true that some @lists.alioth.debian.org stopped working but *many* have been migrated to alioth-lists.debian.net and continue to work as @lists.alioth.debian.org so this lintian warning creates tons of non-actionable and doubtful (not to say false-positive) warnings. Please change this and thank you for maintaining lintian! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Bug#943957: lintian: missing-systemd-service-for-init.d-script should be a warning, not just pedantic
package: lintian severity: wishlist version: 2.32.0 x-debbugs-cc: 941...@bugs.debian.org, r...@debian.org, ans...@43-1.org On Fri, Nov 01, 2019 at 11:20:59AM -0700, Russ Allbery wrote: > > I think there is already a lintian warning: > > > > https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html > Oh! I should have checked rather than assuming. It would ideally be nice > to make it a warning rather than a pedantic tag before we add it to > Policy, but meh, and the count of tags isn't all that high. I'm pretty sure this is trival and just a matter of asking via a wishlist bug, thus doing so here. See #941198 for more context. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: lintian jobs on jenkins.d.n
Hi Chris, On Sat, Aug 10, 2019 at 12:56:21PM +0100, Chris Lamb wrote: > [Let me know if you would no longer like direct CCs for qa-jenkins-dev@ mails] not being cc:ed would indeed be nice here. > Please keep them for now; we have not totally replaced them Salsa jobs > yet (see #930487 et al.) and they sometimes catch other things. To be > investigated... ok & absolutly fine. > Thanks for asking and maintaining jenkins.debian.net. my pleasure and thanks for maintaining lintian(.d.o)! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
lintian jobs on jenkins.d.n
hi, do you still need/use the lintian related tests on jenkins.d.n or have you already replaced them with Salsa / Debian CI? I'd be happy to keep them (and extend them) if they are still useful! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#921752: lintian: file-without-copyright-information should exclude files like COPYING, LICENSE, etc
Package: lintian Version: 2.5.118 Severity: normal Dear Maintainer, gosa-plugin-pwreset (0.99.5-2) has "W: file-without-copyright-information" for the files COPYING and COPYING.CC-BY-SA-3.0. impressive-display (0.3.3-1) has "W: file-without-copyright-information" for the file LICENSE. slbackup (0.0.12-9) has "W: file-without-copyright-information" for the file COPYING. I believe those are all false-positives lintian should ignore. Thanks for maintaining lintian. -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#921084: lintian: please detect .git.git in Vcs-Git-header
Package: lintian Version: 2.5.124 Severity: wishlist Dear Maintainer, so I uploaded https://tracker.debian.org/news/1025869/accepted-anarchism-151-8-source-into-unstable/ and had this line in debian/control: Vcs-Git: https://salsa.debian.org/debian/anarchism.git.git It would be nice if lintian would point out such (and similar?) mistakes. Thanks for maintaining lintian! -- tschüß, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#918809: lintian: please don't warn if using debhelper compat 11
Package: lintian Version: 2.5.120 Severity: normal Dear Maintainer, since recently and in pedantic mode only, lintian warns when using debhelper-compat < 12, which I believe is a bit too early as https://nthykier.wordpress.com/2019/01/04/debhelper-compat-12-is-now-released/ says "We generally recommand you defer migrating to compat 12 until bullseye (to avoid having to revert that change in case you need an unblock for the buster release)." Please disable this warning until Buster has been released. Thanks for maintaining lintian! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#912040: lintian: please detect usage of the variable PIUPARTS_TEST in maintainer scripts
On Sun, Oct 28, 2018 at 04:08:09PM -0400, Chris Lamb wrote: > Fixed in Git, pending upload: > > https://salsa.debian.org/lintian/lintian/commit/47b1aae3bc72229377aaebd7c197427f1b462292 cool, thank you. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#910453: lintian: false positive for package-does-not-use-debhelper-or-cdbs when using blends-dev
On Sun, Oct 07, 2018 at 09:02:30PM +0100, Chris Lamb wrote: > Fixed in Git, pending upload: \o/ thank you! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#910453: lintian: false positive for package-does-not-use-debhelper-or-cdbs when using blends-dev
Package: lintian Version: 2.5.108 Severity: normal affects: blends-dev Dear Maintainer, since very recently lintian emits the pedantic tag 'package-does-not-use-debhelper-or-cdbs' when testing the src:debian-edu package, which build-depends on blends-dev, which depends on debhelper, which is then also used to build src:debian-edu. So this is a false positive, please fix. Thanks for maintaining lintian and making it better all the time! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#909674: lintian: please don't show changelog-empty-entry warning if distribution is UNRELEASED
Package: lintian Version: 2.5.105 Severity: normal Dear Maintainer, subject says it all: please don't show changelog-empty-entry warning if distribution is UNRELEASED. Thanks for maintaining lintian! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#897213: lintian: Please remove dependency-on-python-version-marked-for-end-of-life until after Buster releases
On Thu, May 03, 2018 at 05:48:36AM +0100, Chris Lamb wrote: > However, instead of removing it I've marked the tag as > "experimental" and with a "pedantic" severity, thus essentially > hiding it from 99.999% of Lintian users (yet allowing us to continue > to continue collect statistics and make it easier to re-introduce > later) > I also updated the tag description to say: [...] Thank you! -- cheers, Holger signature.asc Description: PGP signature
Bug#897213: lintian: Please remove dependency-on-python-version-marked-for-end-of-life until after Buster releases
On Mon, Apr 30, 2018 at 12:25:05PM -0400, Scott Kitterman wrote: > I like the idea of pushing towards python3, but my impression of the > near-term > utility of this tag has changed. Specifically, I see people being confused > about if python2.7 will be in buster (it will) and if it they should drop > python2.7 support from packages that still support it (they should not). +1 > While I originally didn't think so, I've become convinced that there's no > wording short of something like "Ignore this tag for buster" that would fix > it. At that point, I considered if the tag was useful no and concluded it is > not. That's not what I thought originally. +1 > People pay attention to lintian results and so the tags should be actionable. > > The action most people seem to read into this tag is get rid of python2.7 > support and we're one release too early for that. +1 Thanks, Scott. -- cheers, Holger signature.asc Description: PGP signature
Bug#896696: lintian: please improve tag description to explain that python 2 modules are only questioned on 1st upload
package: lintian severity: wishlist x-debbugs-cc: debian-de...@lists.debian.org On Mon, Apr 23, 2018 at 06:33:20PM +0100, Chris Lamb wrote: > For example, I think Holger is interpreting this particular tag as > "this source package is shipping a Python 2.x" module. This is not > the case. > > Rather, Lintian detects that this is the *initial* upload of the > source package and, if so, asks the maintainer just to double-check > that there is any requirement for it. > > If there is such a need, the maintainer just needs to add a short, > quick justification in the initial changelog entry and Lintian will > then be silent on the matter. > > It is thus not asking maintainers to drop Python 2 support… Then the lintian message should be appended to say this only happens on the first upload. Thanks. > As there can only be one initial upload by definition, adding an > override here is not only a little silly given that it will trigger > an "unused override" warning on the next upload, it can simply be > avoided in the changelog entry as previously discussed, which > implicitly serves as some documentation too. Maybe it's also worth pointing this out. > (This talk of overrides was why I believe Holger is accidentally > confusing the tag.) Yes. And because the tag description needs improving. ;) -- cheers, Holger signature.asc Description: PGP signature
Bug#886219: lintian should be less pedantic about latest policy version
On Wed, Jan 03, 2018 at 11:05:09PM +, Chris Lamb wrote: > > > - ancient-standards-version should be triggered when S-V contains a > > > release of Policy from the previous stable release cycle > > This sounds good to me. reading this once again I'm reminded that this feeds the notion that our current stable release is ancient :-/ But I guess that ship has sailed… > Same here Is this the consensus view? If so, I can go ahead and make > the change. thanks. -- cheers, Holger signature.asc Description: PGP signature
Bug#886259: please downgrade dependency-on-python-version-marked-for-end-of-life to info or pedantic
package: lintian severity: wishlist x-debbugs-cc: debian-de...@lists.debian.org, d...@list.debian.org On Wed, Jan 03, 2018 at 02:24:46PM +, Sean Whitton wrote: [...lots of stuff I agree with deleted...] > Lintian errors and warnings tell you, roughly, "watch out, your upload > might/will make the state of this package in unstable worse than it is > as present." By contrast, info and pedantic tags say, roughly, "here is > another improvement you could make to this package." Working through > the ugprading checklist almost always falls into the latter category. Ok, you convinced me to file this very bug now. Context: On Wed, Jan 03, 2018 at 01:38:48PM +, Chris Lamb wrote: > Hi Holger, > > > I think I would prefer to > > dependency-on-python-version-marked-for-end-of-life > > to become a pedantic warning > > FYI I initially introduced this tag (and > python-foo-but-no-python3-foo) > as a pedantic level warning following roughly the same rationale as > you > outline. > > However, it was raised later via https://bugs.debian.org/883581. As Sean explains nicely in <87vagjt3yp@zephyr.silentflame.com> I think dependency-on-python-version-marked-for-end-of-life should be info or pedanic at least until Buster is released. -- cheers, Holger signature.asc Description: PGP signature
Bug#886219: lintian should be less pedantic about latest policy version
package: lintian severity: wishlist x-debbugs-cc: debian-de...@lists.debian.org On Mon, Jan 01, 2018 at 05:26:35PM +, Sean Whitton wrote: > I think that Lintian shouldn't warn about not using the latest > Standards-Version; perhaps it should warn when you're using a really old > one. Same here. IMO warnings about the last two policy versions should only be shown in pedantic mode. If a package is 3 versions behind, then this should be a normal lintian warning. -- cheers, Holger signature.asc Description: PGP signature
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
Hi, On Sat, Dec 16, 2017 at 04:50:37PM +, Simon McVittie wrote: > Sending this specifically to you in case you missed it, since you weren't > in Cc at the time: thanks, I did indeed miss it, though Chris now made me aware, but then I postponed looking into this… so you made me revisit this earlier, thanks for that! > for debian-edu-config, you don't need documentation > for how to replace /etc/dbus-1/system.d/hal-debian-edu.conf because I'm > fairly sure it already has no practical effect: > > In this specific case: you should probably drop the file (preferably > into a bonfire), since HAL is very, very obsolete, and I very much > hope debian-edu no longer uses or ships it. The parts of HAL where > high-level APIs made sense were replaced by the DeviceKit services, > which were later renamed to or replaced by udisks, upower and possibly > others; lower-level device enumeration and change-notification were > superseded by using udev directly. > > hal was most recently in Debian as part of wheezy (oldoldstable), so > the file triggering the lintian warning in debian-edu-config is useless > and can safely be removed, unless debian-edu has some lookaside package > repository with packages that are no longer in Debian (in which case I > would still recommend dropping hal as soon as possible, because it > hasn't been maintained for years). thanks for all that information. and no, Debian Edu Wheezy was the last Debian Edu release where we had some packages different than Debian stable. Which were 5 packages where we had a bit different versions… see http://ftp.skolelinux.org/skolelinux/wheezy_needs_love.html (and change wheezy with squeeze, etch or lenny if you want to dig further ;) I've now did this change in debian-edu-config.git: + * Drop dbus-1/system.d/hal-debian-edu.conf, as Wheezy was the last Debian +version including hal, so since Jessie this file was without any effect. +(See #839124 for more information.) > If you want to configure access control for the services that replaced > hal, you'll need to write polkit policies (but if nobody has noticed a > problem with them, their defaults might well be fine for your use case). /me nods. Thanks for everyone explaining this situation! -- cheers, Holger signature.asc Description: PGP signature
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
On Sat, Dec 16, 2017 at 12:01:56PM +, Simon McVittie wrote: > Yes - if I knew how to summarize it in a form short enough for a Lintian > tag description, I would already have done so. a link to a longer description would also do :) -- cheers, Holger signature.asc Description: PGP signature
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
Hi, On Sat, Dec 16, 2017 at 10:21:40AM +, Chris Lamb wrote: > [Adding Holger, the original submitter, to the CC - please see the last two > messages for some more context] > Wow, thank you so much for the detailed explanation! indeed & thank you too for keeping me in the loop. This is great news as I'd like to get rid of these issues in src:debian-edu-config for buster and it seems there's now enough documentation that we'll be able to do so. That said, doing so is probably something for 2018 ;) -- cheers, Holger signature.asc Description: PGP signature
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
Package: lintian Severity: wishlist Hi, I reported on IRC and Niels asked me to file this bug and CC: Simon: https://lintian.debian.org/tags/dbus-policy-at-console.html is not very helpful in fixing the issue at hand, the referenced bug doesnt really tell anything about how we should modify https://anonscm.debian.org/git/debian-edu/debian-edu-config.git/tree/etc/dbus-1/system.d/hal-debian-edu.conf to get rid of this lintian warning. Please improve the tag description so it becomes more clear what should be done. Thanks for maintaining lintian! -- cheers, Holger signature.asc Description: Digital signature
Re: Bug#834616: tex4ht is uninstallable in sid: depends on experimental texlive-htmlxml
control: affects -1 src:lintian # see https://jenkins.debian.net/job/lintian-tests_sid/1243/console On Thu, Aug 18, 2016 at 09:03:07PM +0900, Norbert Preining wrote: > If you need dependencies on tex4ht, please write them out. why? we depend on packages which depend on packages… > I have checked for rdepends before uploading. maybe you made a mistake? > Enjoy we're trying… have a good trip with hopefully good network! ;-) -- cheers, Holger signature.asc Description: Digital signature
Bug#763339: lintian: please recognize squeeze-lts as suite
package: lintian severity: wishlist x-debbugs-cc: debian-...@lists.debian.org Hi, it would be great if lintian could recognize squeeze-lts as a valid suite. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Jenkins job for Lintian tests
Hi Niels, On Donnerstag, 13. März 2014, Niels Thykier wrote: I have tried to create a Jenkins job configuration for continuously checking the Lintian test suite in the master branch. I based it on the ruby-qa jobs and I would like it to run in at least sid and stable (testing is a nice addition, but not strictly necessary). running it against all three is fine. Just to confirm that I got it right; it will mail lintian-ma...@debian.org on failed builds (and the first successful one after a failure)? yes. my comments so far: [04:23] h01ger | nthykier: i've merged your lintian-tests.yaml now. http://jenkins.debian.net/job/lintian-tests_stable/1/ is the first test run [04:26] h01ger | there's some stuff missing, like triggering by git commits (and not time based as your config implies) and irc notification, but thats pretty minor, esp. compared to the failure we see in the above url :) [04:26] h01ger | /tmp/chroot-testrun: line 8: ./ci-run: No such file or directory [04:27] h01ger | nthykier: whats the test you actually want to run? [04:27] * | h01ger clones the lintian repo locally... More tomorrow/today... :) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#737867: please warn about Required-Start: $all in legacy init scripts
package: lintian severity: wishlist x-debbugs-cc: debian-de...@lists.debian.org,pkg-sysvinit-de...@lists.alioth.debian.org Hi, On Donnerstag, 6. Februar 2014, Thomas Goirand wrote: BTW, Debian has a way too many LSB header scripts with Required-Start: $all, which is very bad. A decent init system has to deal with this, and there's no sane way to do so but arbitrarily breaking what the author of the script wrote. A lintian warning telling that $all is just bad would be a very nice thing. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#498591: the cause for this was fixed 4.4 years ago, closing this one now too
Hi, #498590 was the cause for this bug, #64071, and #498590 was closed in September 2009, rather at the beginning of the squeeze release cycle. So I'm closing this bug now, as probably all packages exposing this bug have been rebuild using a newer menu version since then. Also, there is a discussion in #699390 to drop menu from the desktop-task... Lintian maintainers, I recommend you close #498591 with wontfix as well. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#527843: symlink-has-double-slash should be pedantic, or?
Hi Russ, I agree for foo/../bar symlinks, but not for foo//bar symlinks, which are those from kde which make up a huge portion of http://lintian.debian.org/tags/symlink-has-double-slash.html So please make foo/../bar symlinks minor issues and foo//bar a pedantic ones. regards, Holger signature.asc Description: This is a digitally signed message part.
Bug#464837: should warn about merciurial files
Hi, On Sonntag, 11. Januar 2009, Russ Allbery wrote: I didn't see a reply to the above comment (although there was some other further discussion about restructuring these patterns in Lintian). In the absence of further information on this, I'm going to assume that Lintian's current behavior here is okay and close this bug. If you havent changed anything in lintian, I dont think lintians behaviour is the right one, it still wont complain about left over mercurial files. If you have any more information about what these files are for and are sure that they should be omitted, please feel free to reopen. Sadly I don't know mercurial at all, so I cannot give you that information. regards, Holger, who thinks this bug should be reopened, but wont override your decision. signature.asc Description: This is a digitally signed message part.
Bug#381485: any news on the lintian check?
Hi Raphael, On Friday 12 September 2008 04:38, Raphael Geissert wrote: As promised, attached is a patch in a mbox implementing that check. I've only made it check executable scripts in /etc, as not to slow down lintian even more for just one check. Thats great, thank you! Of course the final decision is up to the lintian maintainers :) Sure :) Hint: this bug is a blocker for 438885 which is important ;-) regards, Holger pgpndnG6fY9tf.pgp Description: PGP signature
Bug#381485: any news on the lintian check?
Hi Frank, On Friday 12 September 2008 21:05, Frank Lichtenheld wrote: Which doesn't change anything about the fact that it is whishlist for lintian. Sure :) (It's definitly wishlist for lintian.) And I also (literally) wish lintian would support preventing issues which where the reason for a mass bug filing in May 2006 and were made serious in August 2007. And to say that it is a blocker is really only a BTS-technical term, not something that is really true in any meaningful sense outside of the BTS scope (I hope you know what I mean). Well, yes and no. It (not being fixed) prevents (blocks) that those issues come back again and again. That said, I applaud your effort to clean up the general package :) Thanks. Thanks also for your work on lintian, I love lintian, it rocks! :) regards, Holger pgpBTq2H0VEa6.pgp Description: PGP signature
Bug#464837: should warn about merciurial files
package: lintian version: 1.23.44 Hi, lintian doesnt warn about left over mercurial files in the source package, like it does with svn or cvs files. The following files remained unnoticed in my source package: .hg_archival.txt |2 .hgignore | 29 .hgtags | 10 regards, Holger pgpOB06RtnZJG.pgp Description: PGP signature
Bug#464837: should warn about merciurial files
Hi Frank, On Saturday 09 February 2008 17:24, Frank Lichtenheld wrote: .hg_archival.txt |2 Out of curiosity, what is this one for? I dont really know. $ cat .hg_archival.txt repo: 7efd15ce4dab28ef21588ffef8ca00550290bd1d node: a5b9cf969979239cd27f592589e9712669f6e110 $ regards, Holger pgpX9aee1LjmQ.pgp Description: PGP signature
Bug#379176: info from irc
Hi,
from #debian-release
Jul 24 11:34:05 * h01ger would be interested in comments on #379176 or
http://lists.debian.org/debian-policy/2006/07/msg00033.html - as I read the
FHS, packages (the distributor) can put stuf
f into /srv - they (the packages) just need to cope with changes a local admin
does there...
Jul 24 11:35:26 vorlonwhich Debian packages don't
Jul 24 11:35:41 vorlonso Debian packages shouldn't ship anything
under /srv...
Jul 24 11:38:16 h01gerwhy? not even directories? if its
configurable? (therefore they would be able to deal with changes..)
Jul 24 11:38:37 Ganneff they wouldnt per default, or you would add a
mess of debconf.
Jul 24 11:39:24 vorlonnothing you *ship* is ever configurable, it's
embedded in the file list of the .deb.
Jul 24 11:44:09 h01gerHowever /srv should always exist on FHS
compliant systems and _should be used as the default location_ for such
data.
Jul 24 11:48:01 vorlonand the expansion of such data does *not*
include the sorts of files that are shipped in packages.
Jul 24 11:52:05 Mithrandirit's really pointless to sasy should be used
as the default location without specifying a structure. IMNSHO.
Jul 24 11:54:15 h01gervorlon, you mean site specific? imho this
(the first sentence of the rationale) doesnt imply exclusivly site specific
Jul 24 11:54:45 h01gerand i also agree, the paragraph about /srv in
FHS is to short and unspecific :)
Jul 24 11:57:31 vorloner, of course it implies exclusively
site-specific
Jul 24 12:01:13 h01gerhow does this match with footnote 20?
Jul 24 12:05:01 vorlonuh... footnote 20 sounds like a grant of
permission to shoot ourselves in the foot which we should politely
decline. ;)
Jul 24 12:06:52 h01ger.oO( boring ;)
Jul 24 12:35:07 ajhrm?
Jul 24 12:35:15 aji wrote most of what the fhs has to say about /srv, i
think
Jul 24 12:35:55 ajmostly it should be dealt with like we deal
with /usr/local, i would've though -- mkdir to make directories, and rmdir ||
true to get rid of them
Jul 24 12:44:55 * h01ger nods. ic. so maybe some more clarification in
the next version of the FHS would be good :)
Jul 24 13:28:51 Mithrandiraj: /usr/local has a defined structure, /srv
doesn't though.
Jul 24 13:29:29 ajMithrandir: the distro can define a structure; but
just like /usr/local, it's got to cope with the administrator possibly
deciding on their own structure instead
Jul 24 13:31:08 Mithrandiraj: apart from the fact that we haven't
decided on a structure and people are using it already, so assuming a
particular structure there now would make us step on toes
.
Jul 24 13:31:53 MithrandirI know of at least two different structures in
use, /srv/{www,ftp,gopher,mail,...} and /srv/{domain1,domain2}/{www,ftp,...}
Jul 24 13:32:19 ajMithrandir: sure
Jul 24 13:32:55 ajMithrandir: you can define a template structure on an
initial install up to a point -- as per /var/www or /var/cvs or whatever
Jul 24 13:33:36 Mithrandiron an initial install, sure.
Jul 24 13:34:32 * fjp would like to see an easy way to point e.g.
apache's root to /srv/www on install
regards,
Holger
pgpGYtVOsRQiV.pgp
Description: PGP signature
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Hi, On Saturday 22 July 2006 02:49, you wrote: By my reading of FHS 2.3, no Debian-supplied package should be installing files into /srv, since /srv is reserved for the local administrator for local data. The error message may not be accurate, but it looks to me like this still should be an error. Am I missing something? I don't think you are correct: In http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM the last sentence about /srv says: --begin quote - Distributions must take care not to remove locally placed files in these directories without administrator permission. [20] [20] This is particularly important as these areas will often contain both files initially installed by the distributor, and those added by the administrator. --end quote - So, as I read it, /srv is clearly designed for files from the distribution and locally added ones. regards, Holger pgpQNIaZzhHOt.pgp Description: PGP signature
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Hi, On Saturday 22 July 2006 17:35, you wrote: How can that be reconciled with: The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data. I don't see any way that shipping files under /srv in a Debian package would be consistent with the second-to-last sentence above. I do. But I think this is getting out of scope of this bug :) Maybe the FHS should be reworded, but definitly linda should not announce this as an error. apache might ship with DocumentRoot in /srv/www - but apache must also work, if you modify this. You might have many DocumentRoots, in /srv/webserver/foo and in /srv/webserver/foo2... It says no program should rely on a specific subdirectory structure of /srv, not no program should rely on a specific directory in /srv - especially if you define this directory in the programms configuration. regards, Holger pgp5iiLMexvqT.pgp Description: PGP signature
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Hi, On Saturday 22 July 2006 18:34, you wrote: Yes, and if you ship files in /srv, then your package is creating and insisting upon a particular structure in /srv. Even if the binaries in the package don't insist, the *package* is insisting. Yup. That's a structure my package created. Obviously I can depend on that. This is different to a structure the FHS mandates, like for example in /var: in /var you can rely on /var/lib, /var/log, ... - there is no such structure the FHS mandates for /srv. That's what is ment with that sentence. If the local administrator decides they want to organize /srv differently, your files get in the way. If they delete them or move them, every time the package is upgraded, they're re-installed. To me, that seems to break the point that the above paragraph is driving at. Not to me :) I agree it's annoying, but it's the same as today with say, /var/www. If I delete it, because I use /srv/www, an upgrade of apache recreates that directory, while it doesnt change my config. Certainly, I can see shipping configuration that points to /srv for local data by default, and even a postinst that creates an initial structure in /srv for the package if this is the first install, but putting the files directly in the package seems to me to be forcing more structure than is allowed here. So you agree that the lintian error is wrong :) Maybe we should take this to debian-policy and see what other folks think? Sure. Go ahead. And thanks for caring! I could be wrong and I'm happy to change lintian accordingly if the consensus is that I'm wrong. Obviously I could be wrong as well... ;) regards, Holger pgpl46wppJEQV.pgp Description: PGP signature
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
package: lintian version: 1.23.22 Hi, the new version of policy mandates FHS 2.3, which requires /srv, so this is clearly no error :-) regards, Holger pgpgcKg6kzDZx.pgp Description: PGP signature
