Bug#1022726: dillo: Upstream domain/website no more under control by the upstream developers
Control: retitle -1 dillo: Upstream domain/website no more under control by the
upstream developers, maybe switch to DilloNG as upstream?
Hi again,
Axel Beckert wrote:
> It seems that the owner of the domain dillo[.]org changed on 10th of
> October 2022 and no more belongs to the Dillo upstream developers.
>
> It still worked on 6th of October:
> https://web.archive.org/web/2022100608/https://www.dillo.org/
>
> Also the project leader only used an @dillo[.]org e-mail address, so
> there seems no easy way to contact him. (There are a few other upstream
> developers with e.g. GMX addresses who might still be reachable.)
>
> This unfortunately means that the upstream project has fallen asleep
> even more than before — despite there still was some demand for the
> project as could be seen by several requests for making a new release on
> the mailing list the past few years.
Someone from the orbit of Bunsenlab Linux reminded me that there is a
fork named DilloNG at https://github.com/w00fpack/dilloNG/
Bunsenlab seems to have based their Dillo package on Debian's plus
that repo as upstream version. So maybe we should do that, too. They
actually even made a 3.1X (tag name) / 3.1.0 (versions in file name)
release about 11 months ago.
I just looked through all additional commits seemingly not coming from
the original Dillo developers. They so far looked sane although some
might be a matter of taste or need to be reverted for data privacy
reasons, like preferring Google over DuckDuckGo as default search
engine which from my point of view is inacceptable.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1022726: dillo: Upstream domain/website no more under control by the upstream developers
Package: dillo Severity: important It seems that the owner of the domain dillo[.]org changed on 10th of October 2022 and no more belongs to the Dillo upstream developers. It still worked on 6th of October: https://web.archive.org/web/2022100608/https://www.dillo.org/ Also the project leader only used an @dillo[.]org e-mail address, so there seems no easy way to contact him. (There are a few other upstream developers with e.g. GMX addresses who might still be reachable.) This unfortunately means that the upstream project has fallen asleep even more than before — despite there still was some demand for the project as could be seen by several requests for making a new release on the mailing list the past few years. (This bug report is to track the domain loss on the one hand, but also in the long run to me maybe remove Dillo from Debian.) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages dillo depends on: ii libc62.35-3 ii libfltk1.3 1.3.8-5 ii libjpeg62-turbo 1:2.1.2-1+b1 ii libpng16-16 1.6.38-2 ii libssl3 3.0.5-4 ii libstdc++6 12.2.0-7 ii libx11-6 2:1.8.1-2 ii wget 1.21.3-1+b2 ii zlib1g 1:1.2.11.dfsg-4.1 Versions of packages dillo recommends: ii perl 5.36.0-4 dillo suggests no packages. -- no debconf information
Bug#1022364: qutebrowser: FTBFS: dh_usrlocal: error: debian/qutebrowser/usr/local/bin/qutebrowser is not a directory
Hi Yannick, Yannick Roehlly wrote: > Isn't this linked to https://github.com/pypa/pip/issues/10978 ? Yes, looks related. But as far as I can see, it indeed seems to be a Debian-specific issue as some people in there already commented. Interesting though that Fedora seems to have similar issues. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1022364: qutebrowser: FTBFS: dh_usrlocal: error: debian/qutebrowser/usr/local/bin/qutebrowser is not a directory
Hi Lucas, Lucas Nussbaum wrote: > > > Actually the following override in debian/rules would fix it and the > > > resulting .deb has no debdiff to 2.5.2-1 as in unstable/testing, but > > > I'd first like to understand what actually goes wrong instead of > > > fixing symptoms: > > > > > > override_dh_usrlocal: > > > rm -rvf debian/qutebrowser/usr/local/ > > > > I'm quite sure the culprit lies hidden somewhere in an > > python3-setuptools upstream release between probably 65.3.0 (seems to > > have worked for the past 5 weeks unless Lucas' rebuilds happen more > > seldom, in which case 59.6.0 would be the last known working version) > > and 65.5.0 (clearly broken, installs qutebrowser and only that file > > into /usr/bin/ _and_ /usr/local/bin/). > > I attached the two previous build logs for qutebrowser (17/09 and > 13/08). It might be useful to identify the culprit. Yeah, already looked at them on buildd.d.o: Downgrading python3-setuptools to 59.6.0-1.2 solves the issue as well. But that's already no more in testing. Currently trying to figure out with qutebrowser upstream if this is caused by a change in setuptools or Debian's patches against setuptools. We're currently suspecting a change in Debian's patches against setuptools because setuptools seems to ignore --prefix=/usr now according to a short test of mine. And we're trying to understand if this is a bug in qutebrowser's setup.py respectively qutebrowser's misc/Makefile or in Debian's python3-setuptools. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1022364: qutebrowser: FTBFS: dh_usrlocal: error: debian/qutebrowser/usr/local/bin/qutebrowser is not a directory
Control: tag -1 + pending Hi again, Axel Beckert wrote: > > >dh_usrlocal -O--buildsystem=pybuild -O--link-doc=qutebrowser > > > dh_usrlocal: error: debian/qutebrowser/usr/local/bin/qutebrowser is not a > > > directory > > This is clearly the one which makes the build stop at the end. > > Looks like something suddenly installs the qutebrowser binary _also_ > into /usr/local/bin/. I so far just have no idea yet what or why. > > Actually the following override in debian/rules would fix it and the > resulting .deb has no debdiff to 2.5.2-1 as in unstable/testing, but > I'd first like to understand what actually goes wrong instead of > fixing symptoms: > > override_dh_usrlocal: > rm -rvf debian/qutebrowser/usr/local/ I'm quite sure the culprit lies hidden somewhere in an python3-setuptools upstream release between probably 65.3.0 (seems to have worked for the past 5 weeks unless Lucas' rebuilds happen more seldom, in which case 59.6.0 would be the last known working version) and 65.5.0 (clearly broken, installs qutebrowser and only that file into /usr/bin/ _and_ /usr/local/bin/). Since the upstream changelog is rather terse about potential huge changes like e.g. … * #3576: Updated version of ``validate_pyproject``. * #3617: Merge with pypa/distutils@6852b20 including fix for pypa/distutils#181. … I have no idea which of the changes actually could have triggered this issue. So I'm going with the above mentioned hardball fix. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1022364: qutebrowser: FTBFS: dh_usrlocal: error: debian/qutebrowser/usr/local/bin/qutebrowser is not a directory
Control: tag -1 + confirmed
Hi Lucas,
Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
Thanks for the bug report. Can reproduce it here.
> Relevant part (hopefully):
[…]
> > I: dh_python3 pydist:302: Cannot find package that provides dataclasses.
> > Please add package that provides it to Build-Depends or add "dataclasses
> > python3-dataclasses" line to debian/py3dist-overrides or add proper
> > dependency to Depends by hand and ignore this info.
> > I: dh_python3 pydist:302: Cannot find package that provides dataclasses.
> > Please add package that provides it to Build-Depends or add "dataclasses
> > python3-dataclasses" line to debian/py3dist-overrides or add proper
> > dependency to Depends by hand and ignore this info.
I first thought that this is the relevant hint. But it also showed up
in previous successful builds, e.g. 2.5.2-1, so it was a red herring:
https://buildd.debian.org/status/fetch.php?pkg=qutebrowser=all=2.5.2-1=1655941699=0
> >dh_usrlocal -O--buildsystem=pybuild -O--link-doc=qutebrowser
> > dh_usrlocal: error: debian/qutebrowser/usr/local/bin/qutebrowser is not a
> > directory
This is clearly the one which makes the build stop at the end.
Looks like something suddenly installs the qutebrowser binary _also_
into /usr/local/bin/. I so far just have no idea yet what or why.
Actually the following override in debian/rules would fix it and the
resulting .deb has no debdiff to 2.5.2-1 as in unstable/testing, but
I'd first like to understand what actually goes wrong instead of
fixing symptoms:
override_dh_usrlocal:
rm -rvf debian/qutebrowser/usr/local/
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1018754: telegram-cli: Outdated app that is no longer supported
Hi Paul, Ying-Chun Liu (PaulLiu) wrote: > Neither szqdong nor kenorb-contrib is working. > I've tried both. Meh. I had hope because at least their build CI seems to have been passed. Thanks a lot for having a look at it and testing! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1018754: telegram-cli: Outdated app that is no longer supported
Hi, aexlfow...@web.de wrote: > when I start the program it asks for my phone number. When I give it it > says following: > *** 1661844939.688455 Notification API_64BIT_LOGIN_APP_OUTDATED_39: > You are using an outdated app that is no longer supported. To access > your messages, please update your app to the latest version. […] > I don't think it will be fixed, The original developer clearly seems to have stalled working on it: https://github.com/vysheng/tg says last commit was on Mar 23, 2016. But there seem at least two very active forks: * https://github.com/szqdong/tg * https://github.com/kenorb-contrib/tg Last commit in both is from 2022 Jul 26. (It's the same commit of kenorb — not kenorb-contrib — in both cases.) I'm though not sure which of these would be better to base the package on in the future. Bastian Germann wrote: > Setting appropriate severity. The application is not usable. Thanks! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1022113: gpm: division by 0 in processMouse()
Control: tag -1 + upstream
Control: forwarded -1 https://github.com/telmich/gpm/issues/45
Hi Jakub,
Jakub Wilk wrote:
> gpm crashes when I do "stty cols 1".
[…]
> I think the culprit is the get_console_size() function, which does:
>
>(which_mouse->opt_scaley)=(which_mouse->opt_scale)*50*maxx/80/maxy;
>
> If maxx is small and maxy is large (200 in my case), you could indeed end up
> with opt_scaley set to 0.
Thanks for the bug report. Forwarded to upstream at
https://github.com/telmich/gpm/issues/45 as non of the Debian patches
seem to touch the related lines.
I wonder how to fix this properly? Setting opt_scaley hardcoded to 1
(or another sane value) in case it's 0 or close to? Not sure what side
effects this might have.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1021810: Should firefox-esr be dropped on 32bit architectures in bookworm?
Hi, Emilio Pozuelo Monfort wrote: > I don't see why we should preemptively remove firefox from architectures for > a build issue that may or may not happen 3 years from now. If it happens and > we can't fix/workaround it, then we can discontinue FF security updates > there. But until then, I think providing FF is better than not providing it. Excatly that. Seconded. P.S.: Due to making this bug report "release critical", automatic updates on stable with apt-listbugs stopped applying firefox-esr security updates. Otherwise I wouldn't have noticed it. :-P Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1021775: Last apt update: -0.0 day(s) ago
Hi,
Christoph Berg wrote:
> Re: Axel Beckert
> > I wonder if we should generally ignore negative values here (might
> > hide some "wrong time" issues, but then again they should reported by
> > another check) or just accept tiny negative values?
>
> The check was introduced in 2013 by 8fca9ab199:
>
> -} elsif ($last_update >= 1.5) {
> +} elsif ($last_update >= 1.5 or $last_update < 0) {
> $updatecolor = 'yellow';
Ah, I remember. I think there was a false positive (maybe on a SBC
without RTC like a Raspberry Pi) when the time was totally wrong and
hence the last update was in the future, but it hadn't been updated
for quite a while because of that. (HTTPS as well as APT itself is
quite picky about having the proper time these days.)
> The value is coming directly from perl's -M operator, so I don't see
> how the code can/should be fixed
It's definition is:
-M Script start time minus file modification time, in days.
So if apt update started running and then e.g. ntpd or so sets the
time back a bit, this time can get negative.
> and we should probably just ignore the issue by using "or
> $last_update < -0.1".
Ack, let's check against < -0.1 for now.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-.el
Hi again, Axel Beckert wrote: > And just for the record: This only happens on some of my hosts. I have > several hosts (also with a lot of elpa plugins, but probably still not > as many as on the host where it happens reproducibly) where the > upgrade from 27.x to 28.x worked fine on the first run. > > It seems that those hosts with this issue are desktops or laptops with > emacs-gtk installed while others are VMs or Raspberry Pi based servers > where I only install emacs-lucid or emacs-nox and also no unnecessary > desktop bloat like dbus, etc. One counter argument: I have one Thinkpad which has emacs-gtk, dbus and systemd and there it doesn't happen either. So maybe that desktop criteria was a red herring. If I find time, I'll try to figure out if there are elpa package which are solely installed on those boxes where it happens. Maybe we find the culprit that way. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1021775: Last apt update: -0.0 day(s) ago
Control: tag -1 + confirmed Hi Christoph, Christoph Berg wrote: > Apparently when apt update and the check are running at the same time, > the following can happen: […] > yellow Last apt update: -0.0 day(s) ago Confirmed. I've seen this, too. I suspect that this actually a tiny negative value (unclear why) which gets rounded to zero. I wonder if we should generally ignore negative values here (might hide some "wrong time" issues, but then again they should reported by another check) or just accept tiny negative values? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-.el
Control: found -1 1:28.2+1-1 Hi Sean, Sean Whitton wrote: > On Sun 21 Aug 2022 at 02:46PM +02, Axel Beckert wrote: > > Version: 1:28.1+1-2 […] > > upgrading emacs respectively emacs-gtk from 27.1 to 28.1 causes an > > endless fork loops during package configuration time: > > Are you able to reproduce this with what's in sid at present? Oh, a new upstream release! Let's try… :-) Nothing obvious in the output of apt: Setting up emacs-el (1:28.2+1-1) ... Setting up emacs-common (1:28.2+1-1) ... Setting up emacs-bin-common (1:28.2+1-1) ... Setting up emacs-gtk (1:28.2+1-1) ... Deep recursion on subroutine "main::generate_relevant_tsort_dependencies_internals" at /usr/lib/emacsen-common/lib.pl line 127. Install a2ps for emacs Install develock-el for emacs Install ecb for emacs Install emacsen-common for emacs emacsen-common: Handling install of emacsen flavor emacs Install haml-elisp for emacs Skipping byte-compilation for emacs: Not supported Install post-el for emacs Install pylint for emacs Install quilt-el for emacs Install ratpoison for emacs Install rdtool-elisp for emacs Install sawfish for emacs Install whizzytex for emacs Install elpa-gitignore-mode for emacs install/gitignore-mode-1.4.0: Handling install of emacsen flavor emacs install/gitignore-mode-1.4.0: byte-compiling for emacs But unfortunately, it's still reproducible: 11054 root20 0 2724 960 864 S 0.0 0.0 0:00.00 │ │ │ └─ /bin/sh /var/lib/dpkg/info/emacs-gtk.postinst configure 1:27.1+1-3.1+b1 11058 root20 0 20372 14448 4916 S 0.0 0.0 0:00.29 │ │ │ └─ /usr/bin/perl -w /usr/lib/emacsen-common/emacs-install emacs 11377 root20 0 0 0 0 Z 0.0 0.0 0:00.00 │ │ │ ├─ emacs-install 11438 root20 0 2724 960 864 S 0.0 0.0 0:00.00 │ │ │ └─ /bin/sh /usr/lib/emacsen-common/packages/install/elpa-gitignore-mode emacs 11439 root20 0 2724 956 864 S 0.0 0.0 0:00.00 │ │ │ └─ /bin/sh /usr/lib/dh-elpa/helper/install emacs gitignore-mode 1.4.0 11442 root20 0 2724 112 0 S 0.0 0.0 0:00.00 │ │ │ └─ /bin/sh /usr/lib/dh-elpa/helper/install emacs gitignore-mode 1.4.0 11443 root20 0 168M 58500 36544 S 0.0 0.1 0:00.58 │ │ │ └─ emacs --quick --batch -l package --eval (setq package-user-dir "/nonexistent") --eval (add-to-list 'package-directory-list "/usr/share/emacs/site-lisp/elpa-src") -f package-initialize -f batch-byte-compile gitignore-mode-aut 11444 root20 0 170M 61168 36708 S 0.0 0.1 0:02.24 │ │ │ └─ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-63616c6c2d696e7465726163746976656c79_call_interactively_0-VtJDks.el 11448 root20 0 170M 60524 36284 S 0.0 0.1 0:01.97 │ │ │ └─ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Wu7AW4.el 11449 root20 0 170M 61244 36792 S 0.0 0.1 0:02.01 │ │ │ └─ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-XKbTq1.el 11450 root20 0 170M 61200 36744 S 0.0 0.1 0:02.07 │ │ │ └─ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-2Zc2GB.el 11453 root20 0 170M 61176 36728 S 0.0 0.1 0:02.02 │ │ │ └─ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Ro5jje.el 11454 root20 0 170M 61308 36852 S 0.0 0.1 0:02.14 │ │ │ └─ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-2uNzTS.el 11461 root20 0 170M 61192 36736 S 0.0 0.1 0:02.01 │ │ │ └─ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Ex5VpA.el 11462 root20 0 170M 60696 36456 S 0.0 0.1 0:02.03 │ │ │ └─ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Q91LV9.el 11463 root20 0 170M 61228 36776 S 0.0 0.1 0:02.01 │ │ │ └─ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-boXgPR.el 11469 root20 0 170M 61184 36724 S 0.0 0.1 0:02.00 │ │ │ └─ /usr/b
Bug#1008649: ITS: dokuwiki
Hi Daniel, Daniel Baumann wrote: > On Mon, 10 Oct 2022 17:22:37 +0200 Axel Beckert wrote: > > now I'm admittedly a bit time-starved myself. > > It's not forgotten, though. > > do you think you'll make it in time for bookworm, Yes, definitely. Due to the age of this issue, it's in the meanwhile on the top of my TODO list. And there's some hope that I get it done this week. (The weekend is already booked though.) But as its a thing which definitely needs a few hours of leisure in a row and to be on the safe side: If you don't see any obvious activity until the end of the month, feel free to take over without asking again. > or should/can I take over? Shall I add you to Uploaders? I'd be happy to have another one on board because Anton looks a bit time-starved as well. (And we still have that GMail fsckup communication issue as the — much appreciated — DSA workaround is not suitable for all setups. I'm sparing Cc'ing him as the Cc in my previous mail bounced once again. Hopefully he gets that mail via the team on tracker.d.o.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1021502: lintian: incorrectly complains about debian-news-entry-has-unknown-version
Control: clone -1 -2
Control: reassign -2 debhelper 13.10
Control: clone -2 -3
Control: retitle -2 debhelper: Also trim (or delete) NEWS.Debian.gz if
changelog.Debian.gz is trimmed
Control: block -1 by -2
Control: retitle -3 debhelper: Revert change to trim changelog.Debian.gz by
default
Control: severity -3 wishlist
Control: tag -1 + wontfix
Hi,
gregor herrmann wrote:
> > The report does not look right: it seems to me that version 0.1.14 is
> > indeed present in the changelog file of my package!
>
> Well, yes and no. It's in debian/changelog in the source package but
> as debhelper has started to trim the changelog in binary packages
> (13.10, dh_installchangelogs), it's probbaly not in
> /usr/share/doc//changelog.Debian.gz.
Urgs. IMHO it is a really bad idea to set this as default as such a
change does only make sense for a few packages with really large
changelog entries like e.g. the Linux kernel. (So doing this
automatically size-based, e.g. if the uncompressed debian/changelog is
over 1 MB, the trim it by default to the release-date of oldstable,
would be ok IMHO.)
At least I regularily read changelog.Debian.gz files (usually by
searching in them with "/") and are always very annoyed if I notice
that they're truncated like e.g. on Ubuntu. Always to have to check if
they are truncated before searching in them and then consult the
source package for getting the full changelog is IMHO inacceptable.
It is though nice to see a standardized possibility to truncate Debian
changelogs in debhelper for those packages which actually need it. But
doing this by default is IMHO a horrible idea.
> > Please investigate and fix this bug in lintian.
I see no possibility how to do that in Lintian except for switching
the check from a binary to a source package check. Not sure if this is
that easily doable. Additionally it will become more complex as it
would have each per-binary-package debian/.NEWS files
separately. (It would also invalidate any lintian override about it.)
But I actually would prefer to not have to do that at all as IMHO that
tag is validly emitted and this is IMHO a newly introduced bug in
debhelper. Cloning an according (wishlist) bug report against
debhelper
> Or maybe dh_installchangelogs should trim NEWS.Debian as well?
Definitely (and not just IMHO), this is a bug in debhelper. And
debhelper probably should even delete NEWS.Debian.gz completely if
there are only ancient entries in there. (Actually with these files
trimming by default IMHO even makes sense — but not for
changelog.Debian.gz.)
Cloning another bug report (same severity as this bug report, i.e.
#1021502) against debhelper for not trimming NEWS.Debian.gz as well
and blocking this bug report with it.
But better just don't enable changelog.Debian.gz trimming by default
at all or use the version proposed in MR !79 instead of the one from
!80. MR !79 IMHO is much more sensitive than !80.
IMHO trimming changelog.Debian.gz should not be enabled without either
an explicitly set option (and never by default, except maybe
size-based) or at least only with a dh compat level bump (as suggested
in !79).
The current situation is IMHO a rather bad surprise for many package
maintainers as well as many users (as it was back then in Ubuntu as
well).
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
signature.asc
Description: PGP signature
Bug#1021556: elpa-embark: Fails to install: embark-consult.el:68:1:Error: Cannot open load file: No such file or directory, consult // embark.el:4278:1:Warning: the function ‘vc-ignore’ is not known t
Package: elpa-embark Version: 0.17-1 Severity: serious Hi, elpa-embark fails to install for me as follows: Install elpa-embark for emacs install/embark-0.17: Handling install of emacsen flavor emacs install/embark-0.17: byte-compiling for emacs In toplevel form: embark-consult.el:68:1:Error: Cannot open load file: No such file or directory, consult In end of data: embark.el:4278:1:Warning: the function ‘vc-ignore’ is not known to be defined. ERROR: install script from elpa-embark package failed dpkg: error processing package elpa-embark (--configure): installed elpa-embark package post-installation script subprocess returned error exit status 1 I'm not sure which of the two lines is the actual error triggering the failure. Emacs is still 1:27.1+1-3.1 from Testing due to one of the currently still present RC bugs in 1:28.1+1-4. (In case that makes a difference.) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages elpa-embark depends on: ii dh-elpa-helper 2.0.14 ii emacsen-common 3.0.4 Versions of packages elpa-embark recommends: ii elpa-marginalia 0.14-1 elpa-embark suggests no packages. -- no debconf information
Bug#1008649: ITS: dokuwiki
Hi Daniel, Daniel Baumann wrote: > I was wondering if you're still going forward with this ITS. Yeah, initially Anton and me had a bit of communication issue due to the GMail fuckup and now I'm admittedly a bit time-starved myself. It's not forgotten, though. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1021425: debmany: "The package does not exist" when in exists in cwd
f the requested package on the current system as well as of the current directory. So maybe we need an "apt-get print-uris" (or "apt-cache print-uris") subcommand analogous to the "apt reinstall" shortcut for "apt --reinstall install") which reliably shows that URI independent of any current package state or downloaded files. Or is such a possibility already present in apt and I just can't find it even after digging through the apt-get and apt-cache man pages and trying out commands for over an hour now? In general I currently see these options to solve this issue: A) In debian-goodies alone: * Let debmany dig around in /var/lib/apt/lists/ itself. * Let debmany parse the output of "apt-cache show $pkg" to get the proper path on the mirror and the output of "apt-cache policy $pkg" (or maybe better "apt-cache madison $pkg") to get the proper mirror base URL. Both sound like being duplicated work and error-prone — at varying proportions. B) In apt first, then in debian-goodies: * Make "apt-get --print-uris download" always show the URI. * Make "apt-get --print-uris --simulate download" work and always show the URI. * Create a new apt(-get|cache) subcommand "print-uris". Let's first see what the APT developers think about this issue. To the APT developers: Feel free to set the severity of the bug report against apt to wishlist if you consider the current behaviour of "apt-get --print-uris download" to be a feature and hence the addition of another behaviour to be a feature request. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1021350: assaultcube: Fails to configure on IPv6-only hosts
Package: assaultcube Version: 1.3.0.2+dfsg-4 Severity: minor Tags: ipv6 Forwarded: https://github.com/orgs/community/discussions/10539 Dear Tobi, at least on one host, the new assaultcube package fails to upgrade as follows: Setting up assaultcube (1.3.0.2+dfsg-4) ... Downloading game data…dpkg: error processing package assaultcube (--configure): installed assaultcube package post-installation script subprocess returned error exit status 4 […] Errors were encountered while processing: assaultcube Interestingly there's not even an error message from the postinst script. It just seems to die. Adding a "set -x" reveals that it aborts at this position: # dpkg --configure -a Setting up assaultcube (1.3.0.2+dfsg-4) ... + set -e + version=1.3.0.2 + hash=9b3118e7929253f0114fa06cad8310faab646d177b4660406011152f34086b55 + file=AssaultCube_v1.3.0.2_LockdownEdition_RC1.tar.bz2 + url=https://github.com/assaultcube/AC/releases/download/v1.3.0.2/AssaultCube_v1.3.0.2_LockdownEdition_RC1.tar.bz2 + fqfn=/var/cache/assaultcube/AssaultCube_v1.3.0.2_LockdownEdition_RC1.tar.bz2 + targetdir=/var/lib/assaultcube/gamedata/ + cachedir=/var/cache/assaultcube/ + [ configure = configure ] + rm -rf /var/cache/assaultcube/ + mkdir -p /var/cache/assaultcube/ + echo -n Downloading game data… Downloading game data…+ wget -q https://github.com/assaultcube/AC/releases/download/v1.3.0.2/AssaultCube_v1.3.0.2_LockdownEdition_RC1.tar.bz2 -O /var/cache/assaultcube/AssaultCube_v1.3.0.2_LockdownEdition_RC1.tar.bz2 dpkg: error processing package assaultcube (--configure): installed assaultcube package post-installation script subprocess returned error exit status 4 Errors were encountered while processing: assaultcube Running the wget call without "-q" reveals that https://github.com/orgs/community/discussions/10539 (Github lacking IPv6 support in many places) is actually the culprit: # wget https://github.com/assaultcube/AC/releases/download/v1.3.0.2/AssaultCube_v1.3.0.2_LockdownEdition_RC1.tar.bz2 -O /var/cache/assaultcube/AssaultCube_v1.3.0.2_LockdownEdition_RC1.tar.bz2 --2022-10-06 14:34:26-- https://github.com/assaultcube/AC/releases/download/v1.3.0.2/AssaultCube_v1.3.0.2_LockdownEdition_RC1.tar.bz2 Resolving github.com (github.com)... 140.82.121.4 Connecting to github.com (github.com)|140.82.121.4|:443... failed: Network is unreachable. # echo $? 4 Unfortunately I see no possibility to fix this easily without Github finally supporting IPv6. (Hence setting the above mention Github issue as "forwarded" URL. Feel free to change that.) So please at least remove that "-q" from the wget call in the postinst script for easier diagnostics of such download failures. (And feel free to clone this bug report if you want to track the removal of -q separated from the download issue itself.) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (110, 'experimental') merged-usr: no Architecture: i386 (i686) Kernel: Linux 5.19.0-2-686-pae (SMP w/1 CPU thread; PREEMPT) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: OpenRC (via /run/openrc), PID 1: init Versions of packages assaultcube depends on: ii bzip21.0.8-5+b1 ii libc62.35-2 ii libgcc-s112.2.0-5 ii libgl1 1.5.0-1 ii libopenal1 1:1.19.1-2 ii libsdl2-2.0-02.24.1+dfsg-1 ii libsdl2-image-2.0-0 2.6.2+dfsg-1 ii libstdc++6 12.2.0-5 ii libvorbisfile3 1.3.7-1 ii libx11-6 2:1.8.1-2 ii wget 1.21.3-1+b1 ii zlib1g 1:1.2.11.dfsg-4.1 assaultcube recommends no packages. assaultcube suggests no packages. -- no debconf information
Bug#1020286: [Aptitude-devel] Bug#1020286: aptitude 0.8.13 @ Microknoppix
Control: retitle -1 aptitude: Removal of thousands of packages on Microknoppix Control: tag -1 + moreinfo Hi Anton, Anton Wessel wrote: > Package: aptitude > Version: 0.8.13 @ Microknoppix Which package version exactly? > When downloading and installing a few packages, aptitude 0.8.13 @ > Microknoppix had removed thousend and more packages -- even with option > "--save-resolver". If they're marked as "automatically installed" and there's no dependency on them anymore, aptitude will do that. (And apt would by default show a huge "apt autoremove" list.) >From my mind: --save-resolver makes aptitude to prefer keeping packages rather not updated instead of removing conflicting packages in case of dependency conflicts. (I must admit the wording "it will never remove a package" in the man page might be suboptimal. It is meant to be in the context of the beginning of the paragraph which says "When package dependency problems are encountered".) But with such few details (more or less none), there's no chance to track the real reason down, especially not if it's a bug or just an unlucky set of "automatically installed" flags. Were you able to stop before this happened? Would it still happen if you start aptitude again? If that's the case, please run aptitude-create-state-bundle /tmp/large-package-removal-0.8.13-microknoppix (or similar, the file name actually doesn't matter) and send the resulting file to us. If it's too large for e-mail, please try to upload it somewhere and send the link. The file will contain all subscribed package lists as well as the state of all installed packages as aptitude seems them. So if you consider these to be too personal information, feel free to just send the file or link to me and feel free to encrypt it with PGP for one of my PGP keys shown below. (The 4096 bits key is also available in the file /usr/share/keyrings/debian-keyring.gpg if the package debian-keyring is installed.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019375: Not started under wayland/plasma
Hi Didier,
first thanks for the bug report.
I only have a single Wayland system and that's clearly not yet ready
for production use and currently offline.
Didier 'OdyX' Raboud wrote:
> https://bugs.debian.org/855868 suggests that a similar script as
> present in /etc/Xsession.d should be placed in
> /usr/lib/systemd/user-environment-generators/ for systemd/wayland
> systems to benefit from unburden-home-dir.
So this is only needed in the combination of Wayland AND systemd? That
kinda sounds weird.
> As a temporary local configuration, I've done this;
>
> # mkdir -p /etc/systemd/user-environment-generators/
> # cp /etc/X11/Xsession.d/95unburden-home-dir
> /etc/systemd/user-environment-generators/
Thanks for that tip. Is there a reason why you've copied it instead of
e.g. a symlink?
> Will report back if that helps.
And thanks for that, too, in advance.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019335: fixed in grep 3.8-2
Hi, On Mon, Sep 12, 2022 at 03:21:01PM +, Debian FTP Masters wrote: >* Add 01-disable-egrep-fgrep-warnings.patch (Closes: #1019335) >* Add 02-man_egrep_fgrep_rgrep.patch >* Reintroduce and updated 05-grep-wrapper-sh.patch >* Add test to check availability of egrep and fgrep >* Add links for egrep.1 and fgrep.1 man pages A huge thanks to Christoph, Santiago and Paul! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019556: sse3-support: version 14 fails to install where version 13 installs fine due to different binary capitalization: test-sse3 vs test-SSE3
Hi, Axel Beckert wrote: > * preinst of sse3-support version 13 and 14 are identical. Especially > this line is identical: > > 5 FILE="/usr/libexec/x86_64-linux-gnu/isa-support/test-sse3" > > * But isa-support 14 does not have such a file anymore, instead there is > now a file /usr/libexec/x86_64-linux-gnu/isa-support/test-SSE3. Note > the different capitalization. > > * The same probably counts for sse4.1-support and sse4.2-support as > well: > > Only in isa-support_13/usr/libexec/x86_64-linux-gnu/isa-support: test-sse3 > Only in isa-support_13/usr/libexec/x86_64-linux-gnu/isa-support: test-sse4.1 > Only in isa-support_13/usr/libexec/x86_64-linux-gnu/isa-support: test-sse4.2 > Only in isa-support_14/usr/libexec/x86_64-linux-gnu/isa-support: test-SSE3 > Only in isa-support_14/usr/libexec/x86_64-linux-gnu/isa-support: test-SSE4.1 > Only in isa-support_14/usr/libexec/x86_64-linux-gnu/isa-support: test-SSE4.2 On i386 this very like also affects sse2-support as that one suddenly claims that Salsa's CI doesn't have sse2-support which now makes Lintian's CI test "build-i386" fail: https://salsa.debian.org/lintian/lintian/-/jobs/3221323 → debdiff isa-support_13_i386.deb isa-support_14_i386.deb [The following lists of changes regard files as different if they have different names, permissions or owners.] Files in second .deb but not in first - -rwxr-xr-x root/root /usr/libexec/i386-linux-gnu/isa-support/test-SSE2 -rwxr-xr-x root/root /usr/libexec/i386-linux-gnu/isa-support/test-SSE3 -rwxr-xr-x root/root /usr/libexec/i386-linux-gnu/isa-support/test-SSE4.1 -rwxr-xr-x root/root /usr/libexec/i386-linux-gnu/isa-support/test-SSE4.2 Files in first .deb but not in second - -rwxr-xr-x root/root /usr/libexec/i386-linux-gnu/isa-support/test-sse2 -rwxr-xr-x root/root /usr/libexec/i386-linux-gnu/isa-support/test-sse3 -rwxr-xr-x root/root /usr/libexec/i386-linux-gnu/isa-support/test-sse4.1 -rwxr-xr-x root/root /usr/libexec/i386-linux-gnu/isa-support/test-sse4.2 Control files: lines which differ (wdiff format) -------- […] Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019556: sse3-support: version 14 fails to install where version 13 installs fine due to different binary capitalization: test-sse3 vs test-SSE3
Package: sse3-support,isa-support Version: 14 Severity: grave Justification: Completely fails to serve its purpose Hi, on my Thinkpad X250 with an "Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz" CPU, sse3-support version 14 fails to install where version 13 installs fine, despite sse3-support's changelog entry for version 14 claims that only the package description was changed -- which according to "git diff debian/13..HEAD" (the "debian/14" tag seems missing) is not true as a lot of Perl code changed as well. ┌┤ Configuring sse3-support ├─┐ │ │ │ Support for sse3 required │ │ │ │ Alas, your machine doesn't support the sse3 instruction set. It is needed by software that depends on this dummy package. Sorry. │ │ │ │ Aborting installation. │ │ │ │ │ │ │ └─┘ This machine doesn't support sse3, sorry. Aborting. dpkg: error processing archive /tmp/apt-dpkg-install-KpVFwZ/0-sse3-support_14_amd64.deb (--unpack): new sse3-support package pre-installation script subprocess returned error exit status 2 Additionally the package description claims "It is available on almost any 64-bit-capable processor except for some early AMD models (Sledgehammer and Clawhammer). This CPU is neither an AMD one nor an early 64-bit CPU, being only about 7 years old. https://ark.intel.com/content/www/us/en/ark/products/85213/intel-core-i55300u-processor-3m-cache-up-to-2-90-ghz.html says the launch date of this CPU was Q1'15. Full CPU details: → cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 61 model name : Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz stepping: 4 microcode : 0x2f cpu MHz : 700.000 cache size : 3072 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 20 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap intel_pt xsaveopt dtherm ida arat pln pts md_clear flush_l1d vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple shadow_vmcs bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds bogomips: 4589.74 clflush size: 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 61 model name : Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz stepping: 4 microcode : 0x2f cpu MHz : 2575.752 cache size : 3072 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 20 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
Bug#1019541: lintian: New spelling corrections should be automatically checked against an american and a british english dictionary
Hi again, Axel Beckert wrote: > > $ grep -v ^# /usr/share/lintian/data/spelling/corrections | cut -d '|' -f 1 > > | while read word ; do grep "^$word\$" /usr/share/dict/american-english > > /usr/share/dict/british-english ; done > > Thanks for figuring out this nice little command! I though will try to > optimize it to not call grep for each word but use something like: > > grep -Fw -f <(grep -v '^#' /usr/share/lintian/data/spelling/corrections | > cut -d '|' -f 1) /usr/share/dict/american-english > /usr/share/dict/british-english In the end this probably will be implemented in Perl instead as there are similar checks in t/scripts/spellintian.t already. > I now wonder if we should use wamerican/wbritish or > wamerican-insane/wbritish-insane for that. Maybe wamerican/wbritish is > a good start and if we still get too many false posiives, we can > extend it to use wamerican-insane/wbritish-insane. (The latter will > probably also take longer. But then again with my optimized query > above it also just takes less than a second on a 7 year old laptop. > And it yields about 350 hits.) Some more points on this question: t/scripts/spellintian.t already has (only) two checks for seldom, but valid words so that they don't get added again, namely "iff" and "publically". Both these words are not in /usr/share/dict/*-english but in /usr/share/dict/*-english-insane. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019540: lintian: Multiline dependency in Build-Depends leads to bad-relation & invalid-profile-name-in-source-relation
Hi, Fab Stz wrote: > I have a debian/control file with such a Build-Depends: > > Build-Depends: debhelper-compat (= 13), >android-sdk-build-tools > > > > , >android-sdk-platform-tools > > > > , > > Running lintian toward this reports 2 lintian errors: > - bad-relation Interesting. Thanks a lot for that bug report! > - invalid-profile-name-in-source-relation This is probably something where we need to add valid prefix. I recently also saw "profile." as prefix. Will need to check the specs, though. > FYI, I changed to multiline for readability and because otherwise lintian > reports this other Error: > - field-too-long Build-Depends (6191 chars > 5000) Urgs. Thanks for that information as well! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019235: lintian: 'licence' is not a misspelling
Control: clone -1 -2 Control: tag -1 + confirmed pending Control: retitle -2 lintian: New spelling corrections should be automatically checked against an american and a british english dictionary Control: severity -2 wishlist Hi Andreas, Andreas Beckmann wrote: > 'licence' is a valid (mostly british) variant of license Yep, noticed this as well before I saw your bug report. Already fixed in https://salsa.debian.org/lintian/lintian/-/commit/7d801b2c9c88683051afe0937b46f065cb8873a2 > Perhaps (new) spelling corrections should be automatically checked > against an american and a british english dictionary and carefully > reconsidered if they are found? Good idea! Cloning the bug report for that accordingly as this is a separate thing. Still don't have an idea how to actually do that, but I guess it will be part of the test suite, not a commit hook. > Without implying to delete all the matches (I haven't heard most of the > matching words and would need to look up their meaning...): > > $ grep -v ^# /usr/share/lintian/data/spelling/corrections | cut -d '|' -f 1 | > while read word ; do grep "^$word\$" /usr/share/dict/american-english > /usr/share/dict/british-english ; done Thanks for figuring out this nice little command! I though will try to optimize it to not call grep for each word but use something like: grep -Fw -f <(grep -v '^#' /usr/share/lintian/data/spelling/corrections | cut -d '|' -f 1) /usr/share/dict/american-english /usr/share/dict/british-english I now wonder if we should use wamerican/wbritish or wamerican-insane/wbritish-insane for that. Maybe wamerican/wbritish is a good start and if we still get too many false posiives, we can extend it to use wamerican-insane/wbritish-insane. (The latter will probably also take longer. But then again with my optimized query above it also just takes less than a second on a 7 year old laptop. And it yields about 350 hits.) Some comments about some of those you found: > /usr/share/dict/american-english:bellow > /usr/share/dict/british-english:bellow > /usr/share/dict/american-english:singed > /usr/share/dict/british-english:singed Would keep these. The chances that it is a misspelling of "below" or "signed" are IMHO much higher than the chance that it is used in Debian in its actual meaning. So in case we write a test for this, we should probably list exceptions we want to keep in that test. > /usr/share/dict/american-english:convertor > /usr/share/dict/british-english:convertor > /usr/share/dict/american-english:dependance > /usr/share/dict/american-english:dependant > /usr/share/dict/british-english:dependant > /usr/share/dict/american-english:extravert > /usr/share/dict/british-english:extravert > /usr/share/dict/american-english:extraverts > /usr/share/dict/british-english:extraverts > /usr/share/dict/american-english:licence > /usr/share/dict/british-english:licence > /usr/share/dict/american-english:miniscule > /usr/share/dict/british-english:miniscule > /usr/share/dict/american-english:venders > /usr/share/dict/american-english:vender > /usr/share/dict/american-english:want's > /usr/share/dict/british-english:want's These should probably be removed. They all look like alternative spellings, either historic or local. Not sure about the remaining ones. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019465: [Aptitude-devel] Bug#1019465: Bug#1019465: aptitude: wants to remove the required package lsb-base with a broken reason
Control: tag -1 - moreinfo Hi Vincent, Vincent Lefevre wrote: > > > Linux Standard Base init script functionality > > > lsb-base (remove, 11.2) will be automatically removed because of > > > dependency▒ > > > errors: > > > ▒ > > > > Where did this show up? I didn't get this. Or at least can't remember > > it. Was this a pop-up message? > > After typing 'g' (to "perform all pending installations, removals, > and upgrades") and putting the cursor over the > > id lsb-base -50.2 kB 11.2 11.2 > > line (in order to learn why this package is removed). This is what > the bottom part of the window shows. Ah, I didn't see that because I have the description window hidden by default. Thanks for the explanation. > > > but no errors shown!!! > > > > Because they were resolved. > > OK, so the real reason should be given. Ack. > > > It seems to be triggered by the upgrade of sysvinit packages from > > > 3.04-1 to 3.05-2. In the sysvinit 3.05-1 log message: > > > > > > * Take over library scripts from lsb-base. > > > > Yes, but because of this: > > > > Conflicts: lsb-base > > Normally conflicts produce an error on packages that must not be > removed. Here, I suppose that this is OK because of > > Provides: lsb-base (= 11.1.0) > > (by default, this is not shown by aptitude in the package description). Hmmm, yeah, that probably should be fixed, too. > > So from my point of view aptitude did everything correctly and I don't > > see a bug here. > > Well, the "because of dependency errors" in the above message is > incorrect and very confusing. Since there are no dependency errors, > this cannot be because of dependency errors. Indeed. Thanks for the additional information! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019494: localepurge: uses egrep and fgrep: fgrep/egrep: warning: egrep is obsolescent; using grep -F/-E
Package: localepurge
Version: 0.7.3.10
Severity: normal
localepurge's hook under /etc/apt/apt.conf.d/99-localepurge uses egrep:
Post-Invoke {"if [ -x /usr/sbin/localepurge ] && [ $(ps w -p $PPID | egrep -c
'(remove|purge)') != 1 ]; then /usr/sbin/localepurge; else exit 0; fi";};
Which since grep 3.8 unfortunately emits this annoying warning:
egrep: warning: egrep is obsolescent; using grep -E
Additionally it uses fgrep in /usr/sbin/localepurge itself:
/usr/sbin/localepurge: if [ -f $NOPURGECONF ] && fgrep --quiet
--line-regexp USE_DPKG $NOPURGECONF ; then
/usr/sbin/localepurge: if fgrep --quiet --line-regexp USE_DPKG $NOPURGECONF
/usr/sbin/localepurge: elif fgrep --quiet --line-regexp NEEDSCONFIGFIRST
$NOPURGECONF
/usr/sbin/localepurge:if fgrep --quiet --line-regexp DONTBOTHERNEWLOCALE
$NOPURGECONF; then
/usr/sbin/localepurge:if fgrep --quiet --line-regexp SHOWFREEDSPACE
$NOPURGECONF; then
/usr/sbin/localepurge:if fgrep --quiet --line-regexp MANDELETE $NOPURGECONF;
then
/usr/sbin/localepurge:if fgrep --quiet --line-regexp VERBOSE $NOPURGECONF \
/usr/sbin/localepurge:if fgrep --quiet --line-regexp QUICKNDIRTYCALC
$NOPURGECONF; then
See /usr/share/doc/grep/NEWS.Debian.gz for details.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'),
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'),
(105, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages localepurge depends on:
ii debconf [debconf-2.0] 1.5.79
ii locales2.34-7
ii perl 5.34.0-5
ii procps 2:3.3.17-7+b1
ii ucf3.0043
localepurge recommends no packages.
Versions of packages localepurge suggests:
ii bleachbit 4.4.2-1
pn debfoster
ii deborphan 1.7.35
-- debconf information:
* localepurge/nopurge: de, de_CH.UTF-8, de_DE.UTF-8, en, en_DK.UTF-8,
en_GB.UTF-8, en_US.UTF-8
localepurge/verbose: false
localepurge/remove_no:
localepurge/quickndirtycalc: true
localepurge/showfreedspace: true
localepurge/dontbothernew: false
* localepurge/mandelete: true
localepurge/none_selected: false
* localepurge/use-dpkg-feature: true
Bug#1019465: [Aptitude-devel] Bug#1019465: aptitude: wants to remove the required package lsb-base with a broken reason
Control: tag -1 + moreinfo
Hi Vincent,
Vincent Lefevre wrote:
> After marking some packages for upgrade, I get:
>
> --\ Packages being deleted due to unsatisfied dependencies (1)
> id lsb-base -50.2 kB 11.2 11.2
which is correct, yes.
> Linux Standard Base init script functionality
> lsb-base (remove, 11.2) will be automatically removed because of dependency
> ▒
> errors:
> ▒
Where did this show up? I didn't get this. Or at least can't remember
it. Was this a pop-up message?
> but no errors shown!!!
Because they were resolved.
> It seems to be triggered by the upgrade of sysvinit packages from
> 3.04-1 to 3.05-2. In the sysvinit 3.05-1 log message:
>
> * Take over library scripts from lsb-base.
Yes, but because of this:
Conflicts: lsb-base
So from my point of view aptitude did everything correctly and I don't
see a bug here.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019447: [Aptitude-devel] Bug#1019447: aptitude: Wrong "Press Return to continue" after succesful installation
raction. I see. Thanks for this explicit hint. It really helped to see that you really want that. (Previously I couldn't really imagine this as I'm quite happy that it stops there. I'm just annoyed that can't say "quit" when starting the run, hence the fourth item above. :-) > Again, that is stupid: I disagree. :-) > when you run some lengthy installation you go away from display and > when you return back it asks for Enter then it forces you to wait > until UI is reloaded. JFTR: We're talking about a second on a 5 year old PC with SSDs and at most a minute or two on a very old legacy system with slow CPU (e.g. a Pentium 4 Mobile) and a slow, rotating disk. I see your point, but if its worse or better than the initial variant which you want back depends a lot on how you use aptitude. Let me summarize: * Initially there seemed no "Press Enter" at all. There you then had to press "q" and aptitude would save its stuff, but you don't have to wait unless you need the shell prompt directly again. * In between you had to press Enter, then wait until you can press "q" to quit and then wait again in case you need the shell prompt directly again. This was clearly the worst combination. * Now you have the option to press "q" before it is returning to the TUI for saving some stuff to disk, but you also only have to wait for that if need the shell prompt directly again. From my point of view this is slightly better than the initial variant as the pressing of "q" comes earlier (before the TUI is loaded again and not afterwards) and hence saves you these seconds (or minutes) you argue about by only having to wait for them in case you want back to the shell prompt. I though see that if you start such a run and get back only later, you loose a few seconds. Seems to depend a lot on the way how someone's using the TUI. > That interaction didn't help me in any single case. At least some people (obviously the person implemented or requested this and me myself :-) want to see that output in any case. I see quite a few cases where it makes sense to wait before the user is acknowledging that the output has been seen (or is not relevant): E.g. it is very useful if you have APT plugins like how-can-i-help which output some information at the end of each run. Also with local post-action hooks which e.g. run hardlink over /usr/share/doc/ and then display some statistics about the save disk space benefit from that prompt. Anyway, let's see this as a feature request. It might count as UI regression, too, but I don't see it really as a bug. Hence I set the severity to wishlist, but also tagged the issue as confirmed, i.e. that there is indeed need for such a feature. I'm though aware that adding a configurable option is way less trivial than hardcoding a different behaviour. Nevertheless: Patches for such a feature are of course welcome. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019447: [Aptitude-devel] Bug#1019447: aptitude: Wrong "Press Return to continue" after succesful installation
Control: tag -1 + moreinfo
Hi Aleksey,
thanks for the bug report.
Aleksey Midenkov wrote:
> Since some version aptitude started to behave strangely: it asks user
> interaction after each successful installation.
I thought that the "Press Return to continue" was always there, just
the "'q' followed by Return to quit" has been added as a feature
somewhen 7 or 8 years ago. But now I'm no more sure if that "Press
Return to continue" was really there before.
What definitely has been added around that time (in 0.7.3 from October
2015) was this "Perfoming actions" line when switching from TUI to
installation output. (https://bugs.debian.org/323371)
> Press Return to continue, 'q' followed by Return to quit.
>
> That is strange because 'q' returns first into the UI and then
> quits.
This is correct and is intended.
> So no obvious reason to use 'q' from the above interaction because 'q'
> also works from the UI.
No, the reason is that you don't have to wait to reload the database
before being able to press "q" again.
> I guess the above pause was added to display
> the errors if any happened
There is no pause in that sense. The time the UI is displayed is AFAIK
needed to properly write down the current state of aptitude's package
list after the package installation.
> but the condition in the code for that was chosen wrongly.
The only thing I remember from discussions back then is that querying
for a "q" keypress without the following "Enter" press was much more
work than worth it and would have required a rewrite of the whole
input handling at that point in the workflow.
> I hope you will find the below patch well-suited for stopping
> bugging you with that useless pause.
>
> --- b/src/ui.cc 2020-05-21 06:32:38.0 +0300
> +++ b/src/ui.cc 2022-09-09 13:41:49.752101187 +0300
> @@ -1276,7 +1276,7 @@
> pkgPackageManager::OrderResult rval = f(-1);
>
> bool quit_after_dpkg_run = false;
> -if(rval != pkgPackageManager::Incomplete)
> +if(rval != pkgPackageManager::Completed)
>{
> cout << _("Press Return to continue, 'q' followed by Return to
> quit.") << endl;
Doesn't make sense to me. But maybe I also still haven't understood
what you're actually trying to achieve.
What exactly do you expect aptitude to do when the package
installation/update/removal run ended?
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019444: recap: Cron generates warning mail "egrep: warning: egrep is obsolescent; using grep -E" with GNU grep 3.8 every 5 minutes
Package: recap Version: 2.1.0-1 Severity: important >From /usr/share/doc/grep/NEWS.Debian.gz of grep 3.8-1: From upstream's NEWS: The egrep and fgrep commands, which have been deprecated since release 2.5.3 (2007), now warn that they are obsolescent and should be replaced by grep -E and grep -F. To follow upstream's behaviour, the Debian-specific rgrep command is obsolescent. For the moment, it is just no longer documeted. Hence that warning emitted by the cron job which runs every 5 minutes and hence generates a mail every 5 minutes. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages recap depends on: ii gawk 1:5.1.0-1 ii iotop 0.6-42-ga14256a-0.1 ii iproute2 5.19.0-1 ii links 2.27-1+b1 ii procps2:3.3.17-7+b1 ii sysstat 12.5.6-1 recap recommends no packages. recap suggests no packages. -- no debconf information
Bug#1019328: debian-goodies: please replace obsolescent egrep / fgrep by grep -E / grep -F
Control: tag -1 + confirmed Hi Vincent, Vincent Lefevre wrote: > In the grep 3.8 NEWS file: > > The egrep and fgrep commands, which have been deprecated since > release 2.5.3 (2007), now warn that they are obsolescent and should > be replaced by grep -E and grep -F. Yeah, unfortunately. IMHO a very bad decision. This will cause as much havoc as the removal/deprecation of which brought. Luckily that one has been force-reverted by the TC. > They occur in checkrestart.8 (man page), dglob, dgrep and dgrep.pod, > dman and which-pkg-broke-build. Thanks for the analysis. Oh, and JFTR: degrep, dfgrep, dzegrep and dzfgrep will not be deprecated and continue to work. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1017845: Fwd: Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-
Hi,
I received the following mail which might be of interest for those
debugging this issue:
- Forwarded message from "Mark E. Shoulson" -
Date: Mon, 5 Sep 2022 09:47:32 -0400
From: "Mark E. Shoulson"
To: a...@debian.org
Subject: Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs
--batch -l
/tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-.el
I'm not on the mailing list in question, came across your email while
researching the same problem when I had it, and I might have something useful
to contribute, in the form of a "golfed" minimal example that causes the
problem, so you don't have to pore over huge libraries. My emacs, upon
upgrading, did the exact same looping just when executing this:
(fset 'yes-or-no-p (symbol-function 'y-or-n-p))
That's all it takes. Finally dawned on me to downgrade emacs.
Just in case it helps.
~mark
- End forwarded message -
(And yes, I asked if I may forward this mail.)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1018773: libgnuradio-funcube3.10.0: Missing Breaks and Replaces headers: trying to overwrite '/usr/lib/x86_64-linux-gnu/libgnuradio-funcube.so.3.10.0.0', which is also in package libgnuradio-funcu
Package: gr-funcube Severity: serious Version: 3.10.0~rc2-3 Hi, libgnuradio-funcube3.10.0 fails to install as follows due to missing Breaks and Replaces headers against libgnuradio-funcube1.0.0: Preparing to unpack .../libgnuradio-funcube3.10.0_3.10.0~rc2-3_amd64.deb ... Unpacking libgnuradio-funcube3.10.0 (3.10.0~rc2-3) ... dpkg: error processing archive /var/cache/apt/archives/libgnuradio-funcube3.10.0_3.10.0~rc2-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libgnuradio-funcube.so.3.10.0.0', which is also in package libgnuradio-funcube1.0.0 3.10.0~rc2-1 Errors were encountered while processing: /var/cache/apt/archives/libgnuradio-funcube3.10.0_3.10.0~rc2-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: bookworm/sid [Bug report written on a different system than the issue showed up.]
Bug#990739: buster-pu: package iptables-netflow/2.3-5+deb10u1
Hi Adrian, Adrian Bunk wrote: > Since it was easy to verify with kernel 4.19.249-2 that the module did > not compile before but does after the fix, I've uploaded a package with > the debdiff from the bug to buster. Thanks a lot! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1017817: Bug#1017845: merging with #1017817
Hi Liam, Liam Stitt wrote: > Hi. #1017817 is obviously the same issue as this one, but I have been having > trouble talking the bug server into merging the two and have run > out of patience. Perhaps you could persuade it to DWIM from this > end? Done now. Not sure what in the end still was the issue (I think you were really close at the end), but "forcemerge" solved it. I also marked the packages, which Thorsten Bonow mentioned, as affected, too. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1017530: lintian: dwz generated file false positive
Control: tag -1 + moreinfo Control: user lintian-ma...@debian.org Control: usertag -1 + false-positive Hi Bastien, thanks for the bug report. Unfortunately I don't get what actually is the bug. Can you be a bit more verbose? Some questions below. Bastien Roucariès wrote: > I have an interesting interaction between dwz and lintian > https://salsa.debian.org/debian/isa-support/-/commits/lintianbug > > dh_dwz create a small technically without common debug file, "a small technically" what? File? And if so, where? > so without debug symbols Here also the relevant corollary seems missing. > It is a new variation of false positive #955752... Please describe the bug more detailed. Which file triggers it and why should it not trigger it? Disclaimer: I have no idea of dwz. I just know that it is on the verge of being dropped from the default debhelper sequences because of too many problems for not much gain. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1017908: dpkg: Setting to change the diff tool to view conffile difference
Package: dpkg Version: 1.21.9 Severity: wishlist Dear Guillem, it would be nice if there would be a setting (or environment variable or interactive option) to use a different tool than "diff" to view conffile differences. This would add the possibility to e.g. use colorized diffs as provided by tools like colordiff, "dwdiff -c" or icdiff which allows to review changes more easily (like the adduser.conf changes which came in today). P.S.: I've looked and searched through the man pages of dpkg(1) and dpkg.cfg(5) but found no such setting, hence the wishlist bug report. -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-5 ii libc62.34-4 ii liblzma5 5.2.5-2.1 ii libselinux1 3.4-1+b1 ii tar 1.34+dfsg-1 ii zlib1g 1:1.2.11.dfsg-4.1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.5.2 ii debsig-verify 0.25+b2 -- no debconf information
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Hi Guillem, Guillem Jover wrote: > Control: tag -1 patch > Control: forwarded -1 > https://salsa.debian.org/lintian/lintian/-/merge_requests/414 > > On Mon, 2022-06-27 at 15:14:10 +0200, Axel Beckert wrote: > > Guillem Jover wrote: > > > I'd have to re-dig all this. I might just try to provide a patch, I > > > think should probably be a one-liner. > > > > A patch of course would be nice, but I won't mind if you don't provide > > one. > > I've sent an MR now, which passes the test suite locally, and seems to > work on a manually modified package too. Thanks! Much appreciated. Will merge once we got Salsa CI autopkgtest working again. Currently fails because of dpatch removal _and_ the emacs 27.1 to 28.1 upgrade. *sigh* Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1017632: lintian: False positive on partial match for bin-sbin-mismatch
Hi Guillem,
Guillem Jover wrote:
> The bin-sbin-mismatch triggers false positives on partial matches such
> as /usr/bin/dpkg-www and /usr/sbin/dpkg-www-installer, or
> /usr/bin/dpkg and /usr/sbin/dpkg-fsys-usrunmess.
Urgs. Thanks! Nice catch!
>
> This is due to the check in lib/Lintian/Check/Files/Contents.pm, where
> it essentially does the following:
>
> perl -E '$str = "/bin/dpkg-www-installer"; \
>say "wrong-match" if $str =~ m{\B/\Qbin/dpkg-www\E\b}x'
>
> I've got false-positives in dpkg and dpkg-www.
So that last \b should be a $, right?
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1012289: Some questions about dpatch-related checks inside lintian (was: Re: Bug#1012289: RFH: lintian -- Debian package checker)
Hi again,
this mail contains several points. I separated them with markdown-like
headlines.
Removing dpatch stuff from Lintian?
---
Axel Beckert wrote:
> Bastien Roucariès wrote:
> > could you please check why autotest fail
>
> Done now:
>
> Lintian's autopkgtest fails on Salsa for a week now because dpatch has
> been removed from unstable a week ago: https://bugs.debian.org/1010626
> (Cc'ed)
[…]
> dpatch seems to be mentioned in 269 files of the test suite. I assume
> that at least all dpatch related tags can be removed now as there's no
> point in arguing about dpatch being used (or even used wrongly) if any
> package using it will FTBFS anyway.
Then again most of these cases seem to be the same case which was
split up in dozen cases (of which most still use but actually don't
seem to require dpatch anymore) when the test suite was changed from
running all checks against all test suite packages to running just
specific checks against each test suite package.
In other words: Code duplication and cruft at its best! :-(
But this also means that
a) in many cases we can just remove all the dpatch cruft without any
impact. It's just not yet clear to me which cases those are were we
can't remove the dpatch cruft.
b) It's currently unclear to me which test suite packages are just
checked for source package checks. Those likely don't need dpatch
as it's not needed to build the .dsc source package files.
So after a first try with removing all traces of dpatch, I decided
otherwise and I tried to just remove dpatch from debian/tests/control
and see what happens. I used a feature branch called "dpatch-removal"
for that (which I likely will force-push occasionally).
New test suite failures after dropping dpatch
-
But what happened was something completely unexpected and unrelated to
dpatch:
Errors were encountered while processing:
emacs-nox
dh-elpa
autopkgtest-satdep
So this time it was the still very RC-buggy emacs 28.1 upload which
broke our test suite. *sigh*
I guess in this case we just have to wait until the emacs package is
fixed again.
At least locally we can still use emacs from testing for testing, but
that also makes it a bit more annoying if I later need dpatch again
in case I need to convert some test package with quilt2dpatch which
actually uses dpatch. (Hmmm, quilt ships that script, but has no
package relation with dpatch. Isn't that an RC bug?!? SCNR ;-)
What about the tags patch-system and more-than-one-patch-system?
Another question which popped up is if we still need that
classification tag "patch-system" and the warning
"more-than-one-patch-system" since these only new about quilt and
dpatch and nothing more. So shall we remove these completely? Or keep
the dpatch detection?
More test suite failures / How to run the test suite
Additionally the test suite now fails due to
lib/Lintian/Check/Cruft.pm no more being tidy:
Failed test 'Test::Perl::Critic for "lib/Lintian/Check/Cruft.pm"'
# at /usr/share/perl5/Test/Perl/Critic.pm line 121.
#
# lib/Lintian/Check/Cruft.pm:82:1:Use '{' and '}' to delimit multi-line
regexps
# lib/Lintian/Check/Cruft.pm:107:1:Use '{' and '}' to delimit multi-line
regexps
# lib/Lintian/Check/Cruft.pm:232:17:Useless use of $_
# lib/Lintian/Check/Cruft.pm:238:1:Subroutine "full_text_check" does not end
with "return"
# lib/Lintian/Check/Cruft.pm:249:21:Subroutine called with "&" sigil
# lib/Lintian/Check/Cruft.pm:263:9:"%matchedkeyword" is declared but not used
(And after fixing these, some more return-related issues inside
full_text_check popped up.)
I've tried to fix these. Will push that commit later today if the test
suite run currently running here locally doesn't find anything
related. (Usually such a run takes around 40 minutes here and I really
should go to bed now.)
Hint: The test suite can be run by calling "private/runtests" nowadays.
P.S.: I'm generally open to changing what perlcritic considers bad and
what not inside lintian. For now I just haven't changed anything, but
am not 100% happy with the current settings.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
signature.asc
Description: PGP signature
Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-.el
Control: severity -1 grave
Control: retitle -1 emacs-common: Endless fork loop at installation and at run
time: /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-_{scroll_other_window,delete_frame}_0-.el
Hi,
raising from serious (package installation fails) to grave (unusable)
as starting emacs ends (or rather does not starting) in an endless
loop for me now as well:
Axel Beckert wrote:
> > So far I had to unsinstall the following packages to make it go away,
> > i.e. these packages trigger the issue:
[List fixed to give actual package names]
> > elpa-folding
> > elpa-org
> > elpa-git-timemachine
> > elpa-password-store
> >
> > There might be more.
>
> Another one:
>
> elpa-git-commit
In the meanwhile I also found elpa-smart-mode-line-powerline-theme and
elpa-ement being affected.
After removing all these packages and their reverse dependencies,
emacs' package installation finally passed through without endless
loops.
But when starting emacs, a very similar despite not identical endless
loop showed up — even twice and in parallel:
abe 25900 1.4 0.0 249576 60944 pts/14 Sl 23:53 0:01 \_
emacs
abe 25902 2.4 0.0 254052 61232 pts/20 Ssl+ 23:53 0:03 |
\_ /usr/bin/emacs --batch -l /tmp/emacs-async-comp-seq-25-EX7HYr.el
abe 25908 2.4 0.0 254056 61284 ?Ssl 23:54 0:03 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Oknfek.el
abe 25913 2.4 0.0 254060 61256 ?Ssl 23:54 0:03 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-LRg59v.el
abe 25917 2.5 0.0 254056 61060 ?Ssl 23:54 0:03 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-V984rp.el
abe 25927 2.5 0.0 254060 63184 ?Ssl 23:54 0:02 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-36KQ3Y.el
abe 25931 2.6 0.0 254056 61212 ?Ssl 23:54 0:03 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-rc7Hc7.el
abe 25943 2.8 0.0 254060 61184 ?Ssl 23:54 0:03 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-iHJ6VG.el
abe 25959 2.8 0.0 254056 61176 ?Ssl 23:54 0:03 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-KPWHZf.el
abe 25973 2.8 0.0 254060 61284 ?Ssl 23:54 0:02 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-ujNMu4.el
abe 25987 2.8 0.0 254056 61292 ?Ssl 23:54 0:02 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-5spOXr.el
abe 25998 3.0 0.0 254060 61228 ?Ssl 23:54 0:02 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-QU5Rk4.el
abe 26002 3.1 0.0 254056 61220 ?Ssl 23:54 0:02 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-knkQvC.el
abe 26006 3.3 0.0 254060 61248 ?Ssl 23:54 0:03 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-emW4ym.el
abe 26016 3.3 0.0 254056 61352 ?Ssl 23:54 0:02 | |
\_ /usr/bin/emacs --batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-CGyFmX.el
abe 26035 3.4 0.0 254060 61276 ?Ssl 23:54 0:02 | |
\_ /usr/bin/emacs --batch
-l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Rfnh3y.el
abe 26050 3.6 0.0 254056 63220 ?Ssl 23:54 0:02 | |
\_ /usr/bin/emacs
--batch -l
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-yb58VI.el
abe 26062 3.8 0.0 254060 61228 ?Ssl 23:54 0:03 | |
\_ /usr/bin/emacs
--batch -l
/tmp/emacs-int-comp-subr--tram
Bug#1010626: Bug#1012289: RFH: lintian -- Debian package checker
Hi Bastien, Bastien Roucariès wrote: > could you please check why autotest fail Done now: Lintian's autopkgtest fails on Salsa for a week now because dpatch has been removed from unstable a week ago: https://bugs.debian.org/1010626 (Cc'ed) It seems as if package removals do not take into account autopkgtest dependencies yet. :-/ dpatch seems to be mentioned in 269 files of the test suite. I assume that at least all dpatch related tags can be removed now as there's no point in arguing about dpatch being used (or even used wrongly) if any package using it will FTBFS anyway. Thanks for notifying me of that issue! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-.el
Control: affects -1 + elpa-git-commit
Hi,
Axel Beckert wrote:
> upgrading emacs respectively emacs-gtk from 27.1 to 28.1 causes an
> endless fork loops during package configuration time:
One more interesting line of output at the very beginning:
Setting up emacs-gtk (1:28.1+1-2) ...
Deep recursion on subroutine
"main::generate_relevant_tsort_dependencies_internals" at
/usr/lib/emacsen-common/lib.pl line 127.
> So far I had to unsinstall the following packages to make it go away,
> i.e. these packages trigger the issue:
>
> aelpa-folding
> org-mode
> git-timemachine
> elpa-password-store
>
> There might be more.
Another one:
elpa-git-commit
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-.el
Package: emacs-common Version: 1:28.1+1-2 Severity: serious X-Debbugs-Cc: a...@debian.org Control: affects -1 elpa-folding elpa-org elpa-git-timemachine elpa-password-store Hi, upgrading emacs respectively emacs-gtk from 27.1 to 28.1 causes an endless fork loops during package configuration time: root 31971 0.0 0.0 2708 944 pts/10 S+ 14:05 0:00 | \_ /bin/sh /var/lib/dpkg/info/emacs-gtk.postinst configure 1:27.1+1-3.1+b1 root 31975 0.0 0.0 21200 13980 pts/10 S+ 14:05 0:00 | \_ /usr/bin/perl -w /usr/lib/emacsen-common/emacs-install emacs root 32250 0.0 0.0 0 0 pts/10 Z+ 14:05 0:00 | \_ [emacs-install] root 1496 0.0 0.0 2708 952 pts/10 S+ 14:08 0:00 | \_ /bin/sh /usr/lib/emacsen-common/packages/install/elpa-password-store emacs root 1497 0.0 0.0 2708 952 pts/10 S+ 14:08 0:00 | \_ /bin/sh /usr/lib/dh-elpa/helper/install emacs password-store 2.1.4 root 1500 0.0 0.0 2708 120 pts/10 S+ 14:08 0:00 | \_ /bin/sh /usr/lib/dh-elpa/helper/install emacs password-store 2.1.4 root 1501 0.6 0.0 253396 62048 pts/10 Sl+ 14:08 0:01 | \_ emacs --quick --batch -l package --eval (setq package-user-dir "/nonexistent") --eval (add-to-list 'package-directory-list "/usr/share/emacs/site-lisp/elpa-src") -f package-initialize -f batch-byte-compile password-store-autoloads.el password-store-pkg.el password-store.el root 1534 1.1 0.0 254684 61876 ?Ssl 14:09 0:03 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-6d616b652d70726f63657373_make_process_0-rZME2o.el root 1536 1.1 0.0 254680 61848 ?Ssl 14:09 0:03 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-hNB5Cs.el root 1538 1.1 0.0 254684 61872 ?Ssl 14:09 0:02 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-ybucTI.el root 1543 1.2 0.0 254680 62036 ?Ssl 14:09 0:02 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-h2cpn1.el root 1545 1.3 0.0 254684 61920 ?Ssl 14:09 0:03 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-xAswlm.el root 1547 1.3 0.0 254680 61980 ?Ssl 14:09 0:03 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-nJWdN3.el root 1555 1.2 0.0 254684 61992 ?Ssl 14:09 0:03 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-BB0YM6.el root 1557 1.2 0.0 254680 62004 ?Ssl 14:09 0:02 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-XiRm2f.el root 1559 1.3 0.0 254684 61968 ?Ssl 14:09 0:03 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-bEF8Rf.el root 1561 1.2 0.0 254680 61808 ?Ssl 14:09 0:02 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-Pk7AH2.el root 1563 1.3 0.0 254684 61932 ?Ssl 14:09 0:03 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-2sptbI.el root 1565 1.3 0.0 254680 62028 ?Ssl 14:09 0:02 | \_ /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-cHWZzN.el root 1567 1.3 0.0 254684 61964 ?Ssl 14:09 0:02 | \_ /usr/bin/emacs --batch -l
Bug#1012289: RFH: lintian -- Debian package checker
Hi Bastien, Bastien Roucariès wrote: > I have just reinstanced the sliding windows on master. Yay, thanks! > could you please check why autotest fail Will do, but probably not before the weekend. > BTW I am really supprised that test are not run at build time The test suite currently runs around 35-40 minutes on my 6 year old 4-core workstation and even longer on Salsa CI (1h30m to 1h45m). (At least those were the numbers when I last measured it. There are a few commits in there now which probably reduce that time a bit.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1017622: gdu: Does not honour Ctrl-Z to suspend the application
Package: gdu Version: 5.13.2-1+b2 Severity: normal Hi, gdu does not honour the pressing of Ctrl-Z to allow to suspend the application to temporarily get back to the commandline. ncdu (after which it seems to be modeled) does honour Ctrl-Z and can be suspended. So please allow gdu to be suspended with Ctrl-Z as with nearly all other TUI applications. (The only other one I know is mutt where it is configurable if mutt should suspend on Ctrl-Z or ignore it.) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages gdu depends on: ii libc6 2.34-4 gdu recommends no packages. gdu suggests no packages. -- no debconf information
Bug#1012289: RFH: lintian -- Debian package checker
Hi Bastien,
Bastien Roucariès wrote:
> I will restep to be a lintian maint.
Yay, thanks! Much appreciated.
You're still in the "lintian" group of Salsa, so you should be still
able to commit to the repo.
> Could you please prepare a list of urgent action ?
Usually, if I consider a lintian bug to be urgent-ish, I bumped its
severity to important. (And you bumped one to serious already, too.
:-) So anything RC or "important" on
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=lintian;dist=unstable
is what we should focus on first, if possible. Those marked confirmed
are those I already looked at closer:
* #993613
* #1014083
* #1014162
Then there are two other topics I have a focus on, because I think,
they're important for all of us, because they're annoying:
* False Positives:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=lintian-maint%40debian.org=false-positive
* Automatically migrating non-bracketed lintian overrides to bracketed
ones. I started here, but it's mostly lacking migration regexp
mappings for the hundreds of tags being affected:
https://salsa.debian.org/lintian/lintian/-/blob/migrate-overrides/bin/lintian-migrate-overrides-to-pointed-hints
Note that this is currently only inside a feature branch which is
not yet merged as it is far from helpful yet.
This is actually my fix for https://bugs.debian.org/1007002
Oh, and one more thing: I want to adhere to Semantic Versioning — the
real one (https://semver.org/), not the one which Felix called
"Semantic Versioning" despite it wasn't Semantic Versioning.
So the versioning from now on will be BREAK.FEATURE.BUGFIX:
* Changing configuration semantic or syntax or exit codes will be a BREAK.
* Adding new tags will be a FEATURE.
* No functional changes except bug fixes will be a BUGFIX.
* Pure documentation or build-system changes will be a BUGFIX, too.
And probably also:
* Renaming tags will be a BREAK. (Feel free to discuss if you
disagree. :-))
Not yet sure about:
* Will be removing a tag a BREAK, too?
P.S.: Yeah, there was a bit of silence (despite not complete silence)
from me on lintian, but that was mostly due to holidays (in which was
way less online that I expected), some pre-holiday and some
post-holidays stress. And also because of RC bugs in some of my other
similarily important packages. Expect some more activity on Lintian
towards to next weekend. :-)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
signature.asc
Description: PGP signature
Bug#1017388: yt-dlp: trying to overwrite '/usr/lib/python3/dist-packages/devscripts/__init__.py', which is also in package devscripts 2.22.2
Package: yt-dlp Version: 2022.08.14-1 Severity: serious Hi, trying to upgrade yt-dlp from version 2022.07.18-1 to 2022.08.14-1 fails for me as follows: Preparing to unpack .../yt-dlp_2022.08.14-1_all.deb ... Unpacking yt-dlp (2022.08.14-1) over (2022.07.18-1) ... dpkg: error processing archive /var/cache/apt/archives/yt-dlp_2022.08.14-1_all.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/devscripts/__init__.py', which is also in package devscripts 2.22.2 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/yt-dlp_2022.08.14-1_all.deb There might be additional file conflicts as dpkg-deb always only reports the first one and then aborts. The inclusion of any file under /usr/lib/python3/dist-packages/devscripts/ in a binary package not built from src:devscripts looks like an error to me. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), (111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), (105, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages yt-dlp depends on: ii python33.10.6-1 ii python3-brotli 1.0.9-2+b4 ii python3-certifi2020.6.20-1 ii python3-mutagen1.45.1-3 ii python3-pkg-resources 59.6.0-1.2 ii python3-pycryptodome 3.11.0+dfsg1-3 ii python3-websockets 10.2-1 Versions of packages yt-dlp recommends: ii aria21.36.0-1 ii ca-certificates 20211016 ii curl 7.84.0-2 ii ffmpeg 7:5.1-2+b1 ii python3-pyxattr 0.7.2-2+b1 ii rtmpdump 2.4+20151223.gitfa8646d.1-2+b2 ii wget 1.21.3-1+b2 Versions of packages yt-dlp suggests: ii libfribidi-bin 1.0.8-2.1 ii mplayer 2:1.4+ds1-3+b2 ii mpv 0.34.1-1+b4 pn phantomjs -- no debconf information
Bug#1017065: libwacom-bin: Missing package relation with python3-libevdev for libwacom-show-stylus: "Error: No module named 'libevdev'"
Package: libwacom-bin Version: 2.4.0-1 Severity: serious Hi, using one of the programs in libwacom-bin fails as follows: $ libwacom-show-stylus Error: No module named 'libevdev' One or more python modules are missing. Please install those modules and re-run this tool. After installing python3-libevdev, the tool works again: $ libwacom-show-stylus Using "Wacom Bamboo 16FG 4x5 Pen": /dev/input/event25 Using stylus file(s): /usr/share/libwacom/libwacom.stylus Insufficient permissions, please run me as root So the package is missing a package relation with python3-libevdev, probably a Recommends, maybe also a Suggests or Depends. (I'll leave that choice to the package maintainer.) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libwacom-bin depends on: ii libc6 2.34-3 ii libglib2.0-02.72.3-1+b1 ii libgudev-1.0-0 237-2 ii libwacom9 2.4.0-1 ii python3 3.10.6-1 libwacom-bin recommends no packages. libwacom-bin suggests no packages. -- no debconf information
Bug#1012895: cwidget RC bug: Please upload or grant me cwidget team membership on Salsa
Hi Manuel,
Manuel A. Fernandez Montecelo wrote:
> > I know you're busy with RISC-V and other stuff, but please do me a
> > small favour and add me to the cwidget team on Salsa, probably via
> > https://salsa.debian.org/groups/cwidget-team/-/group_members
>
> Yeah, I dedicate my stuff mostly to RISC-V because I have nothing to
> spare in the last few years, and even there I'm lacking :-(
Oh. :-/
> I had seen this from pabs but will not have time at least until mid
> next week, so better if you do it and have permissions in general
> anyway, as you say.
Thanks for adding my to the cwidget team. I will do an cwidget upload
within the next few days and afterwards an aptitude upload.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1012895: cwidget RC bug: Please upload or grant me cwidget team membership on Salsa
Hi Manuel, TL;DR: Please grant me cwidget team membership on Salsa so we don't have to NMU it. Or just do an upload of cwidget with the patch from #1015925. I know you're busy with RISC-V and other stuff, but please do me a small favour and add me to the cwidget team on Salsa, probably via https://salsa.debian.org/groups/cwidget-team/-/group_members Background: There are currently RC bugs in aptitude and cwidget which both cause aptitude to FTBFS with GCC 12: https://bugs.debian.org/1015925 https://bugs.debian.org/1012895 Both bug reports have patches by pabs (Cc'ed). Without having the cwidget bugs (#1015925) fixed, I can't fix the aptitude one (#1012895). Currently you're the only "cwidget team" member on Salsa. I've requested team membership there a few days ago, so I can do proper "Team uploads" for cwidget, too. Otherwise pabs or me would have to NMU cwidget. And I think having a second uploader for cwidget would be good in the long run anyway, especially because aptitude is its only library user. Other options beside the NMU are (obviously) that you do a quick upload of cwidget with pabs' patch from #1015925. (Sent from my non-debian address to your non-debian address due to the current GMail fuckup which causes tons of false positive mail rejections by GMail, especially with mails forwarded by the BTS.) Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: a...@deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: a...@noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/ signature.asc Description: PGP signature
Bug#1016565: liblibrecast0.5: Missing Breaks+Replaces headers against liblibrecast0.4: trying to overwrite '/usr/share/man/man3/lc_ctx_new.3.gz', which is also in package liblibrecast0.4:amd64 0.4.5-1
Package: liblibrecast0.5 Severity: serious Version: 0.5.1-1 Control: affects -1 lcsync lcsync fails to upgrade due to this issue: Unpacking liblibrecast0.5:amd64 (0.5.1-1) ... dpkg: error processing archive /var/cache/apt/archives/liblibrecast0.5_0.5.1-1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man3/lc_ctx_new.3.gz', which is also in package liblibrecast0.4:amd64 0.4.5-1 Errors were encountered while processing: /var/cache/apt/archives/liblibrecast0.5_0.5.1-1_amd64.deb There seem to be Breaks and Replaces headers missing for moving this and potentially further files from liblibrecast0.4 to liblibrecast0.5. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled
Bug#1012895: [Aptitude-devel] Bug#1012895: aptitude: ftbfs with GCC-12
Hi Paul, Paul Wise wrote: > On Tue, 2022-07-26 at 00:28 +0200, Axel Beckert wrote: > > Paul Wise wrote: > > > I tried to build aptitude, found it fails due to cwidget bug #1015925. > > > > Do you intend to NMU that? > > I'd prefer the cwidget team take care of it, […] > > Not really true. It's just that we haven't made a real "upstream" > > release for quite a while because Manuel is mostly busy with the RISC > > V port. Manuel is "the cwidget team": https://salsa.debian.org/groups/cwidget-team/-/group_members I've requested team membership now as it kinda doesn't make sense that Manuel does this alone despite aptitude is AFAIK the only consumer so far. > > As far I understood, it doesn't make sense to upload a new aptitude > > package before #1015925 is fixed. > > Agreed. Ok, so let's see if I get into that team. I'll also try to nudge separately due to the current GMail fuckup. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#998367: perlcritic: "Code not tidy' after perltidy
Control: reassign -1 perltidy
Control: found -1 20220217-1
Control: affects -1 + libperl-critic-perl
Hi,
Felix Lechner wrote:
> > The bug lies in the interaction between these 2 tools.
>
> Yay, the problem was solved! […]
> https://github.com/Perl-Critic/Perl-Critic/issues/925#issuecomment-1048340859
Actually that "fix" still would have needed code changes in Lintian
and other consumers. These code changes additionally would have had to
check the version of perltidy and behave differently based on the version.
But according to
https://github.com/Perl-Critic/Perl-Critic/issues/925#issuecomment-1194737842
the issue should be fixed "in the most recent release of Perl::Tidy
(v20220613 or later)" due to a changed default value which seemingly
no more needs to the above mentioned code changes.
So please update perltidy to the most recent upstream release.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1012895: aptitude: ftbfs with GCC-12
Hi Paul, Paul Wise wrote: > I tried to build aptitude, found it fails due to cwidget bug #1015925. Do you intend to NMU that? > The issue is that the operator<< functions are not declared before the > call site, so forward declarations before HelperMacros.h are needed: Thanks for having looked into this. > I'm not sure how to contribute this change to the package because this > should be a native package but isn't I'm not that sure about this. But it is probably historically grown. > and has debian/patches/ Correct, this is mostly used for short-term fixes. > but also an upstream master branch Correct. This is where actual development and new "upstream" releases happen. > that seems to be unused. Not really true. It's just that we haven't made a real "upstream" release for quite a while because Manuel is mostly busy with the RISC V port. > I suggest merging the contents of debian/patches/ to the upstream > master branch IIRC this is partially already done. > and then cherry-picking the FTBFS patches to a new minor > release branch instead of using debian/patches/. If it needs to be done quick, it will not happen that way. > I've filed two merge requests with two different approaches, one is a > commit for the master branch and one a patch for the debian-sid branch. Thanks. Attaching the patch here would have sufficed, though. As far I understood, it doesn't make sense to upload a new aptitude package before #1015925 is fixed. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1014841: libguvcview-2.1-2: Missing Breaks+Replaces header → trying to overwrite '/usr/lib/x86_64-linux-gnu/libgviewaudio-2.0.so.2.0.0', which is also in package libguvcview-2.0-2:amd64 2.0.7-2-1
Package: libguvcview-2.1-2 Severity: serious Version: 2.0.8-1 Upgrading gucview with the switch to a new library package name (probably due to an SONAME bump) fails as follows due to missing Breaks and Replaces headers in libguvcview-2.1-2: Preparing to unpack .../libguvcview-2.1-2_2.0.8-1_amd64.deb ... Unpacking libguvcview-2.1-2:amd64 (2.0.8-1) ... dpkg: error processing archive /var/cache/apt/archives/libguvcview-2.1-2_2.0.8-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libgviewaudio-2.0.so.2.0.0', which is also in package libguvcview-2.0-2:amd64 2.0.7-2-1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled
Bug#1014724: FBTFS: test failure in t/connection.t
Hi gregor,
gregor herrmann wrote:
> Source: libmojo-sqlite-perl
> Version: 3.001-2
That's the version in oldstable. Are you sure you wanted to report
this bug report against that version instead of the version 3.009-1 in
unstable?
> Use of uninitialized value in string eq at
> /build/libmojo-sqlite-perl-3.009/blib/lib/Mojo/SQLite.pm line 70.
Because this at least says "3.009".
> Maybe I'm wrong, but there's a coincidence with the recent upload of
> URI 5.11 and some other test failures in other packages. And the
> tests pass in testing (with URI 5.10).
Sounds reasonable.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1014584: lintian: False positive binary-nmu-debian-revision-in-source and source-nmu-has-incorrect-version-number with Ubuntu version
Hi,
Alberto Contreras wrote:
> When I invoke `lintian` over a package with a version like
> `22.2-64-g1fcd55d6-0ubuntu1~22.10.1` it emits
> `binary-nmu-debian-revision-in-source` and
> `source-nmu-has-incorrect-version-number` source warnings. This looks like
> a false positive.
[…]
> We think it could be related to the following
> detection:
> https://salsa.debian.org/lintian/lintian/-/blob/ecc04980869462c5c71f4f71e9b8a71bd5b944b5/lib/Lintian/Check/Fields/Version.pm#L87
> regex:
> https://salsa.debian.org/lintian/lintian/-/blob/ecc04980869462c5c71f4f71e9b8a71bd5b944b5/lib/Lintian/Check/Fields/Version.pm#L65
Nope, it's likely
https://salsa.debian.org/lintian/lintian/-/blob/ecc04980869462c5c71f4f71e9b8a71bd5b944b5/lib/Lintian/Check/Fields/Version.pm#L70
which needs to be updated.
Note to myself: There's a similar albeit not identical issue reported
in https://bugs.debian.org/1001399.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1014511: sysvinit: debian/copyright reports incorrect licenses
Hi, binh1.tran...@toshiba.co.jp wrote: > > debian/copyright _IS_ the canonical place for copyright statements about > > debian/* > > So this is wrong and MUST NOT be changed as it would mean we would LOOSE > > the copyright statements for the remaining files in debian/*. > > Thank you for your sharing. > > In the original debian/copyright file, debian/* paragraph is missing > copyright of some files as below: Ok, that's very possible. > I'd like to send you the new copyright without removing debian/* at > the attachment. Thanks. > Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > Hmmm, this should be HTTPS nowadays. (Likely not your fault. :-) > Files: debian/* > Copyright: 2015 Adam Conrad >2018 Dmitry Bogatov >2018 Vincenzo (KatolaZ) Nicosia >2006 Henrique de Moraes Holschuh >2017 Ian Jackson >2014 Robert Millan >2014 Thomas Goirand >2006 Thomas Hood >2015-2016 Andreas Henriksson >2011,2016 Ben Hutchings >2010-2012 Christian Perrier >2015-2016 Martin Pitt >2014-2018 Michael Biebl >1996-2004 Miquel van Smoorenburg >2005-2010, 2014 Petter Reinholdtsen >2011-2013 Roger Leigh >2006-2007 Steinar H. Gunderson >2012-2013 Steve Langasek >2009 Adriano Rafael Gomes , 2009-2020. >2019 sysvinit & Joe Hansen. >2009 Software in the Public Interest >2012 Martin Bagge >2012 Debian French l10n Team >2009 Hideki Yamane > License: GPL-2.0+ Generally looks fine that way. I'd though leave the decision if the additions should be listed separately for these files or in summary as above to the actual package maintainers. (I'm just generally interested in the shape of this package as I'm a heavy user of it. And I did a lot of debian/copyright conversions to the machine-readable format in the past.) Additionally I would recommend to the package maintainers to sort this list in some way. Usually they're sorted by the first contribution, e.g. sorted alphabetically like this: Copyright: 1996-2004 Miquel van Smoorenburg 2005-2010, 2014 Petter Reinholdtsen 2006 Henrique de Moraes Holschuh 2006 Thomas Hood 2006-2007 Steinar H. Gunderson 2009 Adriano Rafael Gomes , 2009-2020. 2009 Hideki Yamane 2009 Software in the Public Interest 2010-2012 Christian Perrier 2011,2016 Ben Hutchings 2011-2013 Roger Leigh 2012 Debian French l10n Team 2012 Martin Bagge 2012-2013 Steve Langasek 2014 Robert Millan 2014 Thomas Goirand 2014-2018 Michael Biebl 2015 Adam Conrad 2015-2016 Andreas Henriksson 2015-2016 Martin Pitt 2017 Ian Jackson 2018 Dmitry Bogatov 2018 Vincenzo (KatolaZ) Nicosia 2019 sysvinit & Joe Hansen. > Files: debian/po/vi.po > Copyright: 2009 Free Software Foundation, Inc. Clytie Siddall > , 2009. The 2009 at the beginning and end looks odd. This probably should better be: Copyright: 2009 Free Software Foundation, Inc. 2009 Clytie Siddall > License: ^^^ Here's the license name missing. Just an empty "License:" field without value is not valid syntax (nor valid semantic). But I do see that the file has a copyright statement without a license statement. Actually having an explicit copyright statement in that file without having a license declared actually makes the file's license situation a bit being in limbo. Then again, seeing no license in combination with a copyright statement of the FSF is very odd. It is very likely that the license statement got lost at some point in time. Unfortunately this must have happened before the import into Debian in 2009 as the file got committed to git with that statement as it is today: https://bugs.debian.org/550220 — I guess the only way to find out is to contact Clytie Siddall and ask for clarification. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#743694: lintian: Downgrade most of privacy-breach* tags from severity: error to pedantic
Control: tag -1 wishlist Control: tag -1 + wontfix Hi, Paul Wise wrote on 11. Sep. 2021: > I think that the privacy breaches that lintian complains about > represent several sets of bugs that all need fixing: I strongly agree with pabs and his (no more copied) explanations and reasoning. These are real issues which are clearly neither minor nor even pedantic. These are issues which need to be fixed. >From my point of view, this is not even a bug, but a feature request. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1014156: lintian: very-long-line-length-in-source-file for non-text source files
Hi Peter, Peter B wrote: > > The suffix "icns" is already in the blacklist since 2.115.2. With > > which version of Lintian did you generate that list? > > I use Testing, so it was 2.115.1 It is indeed fixed in 2.115.2 Yay! Thanks for the reply. :-) > Trying on duma, I got several hits on binary files (with 2.115.1 & 2.115.2) > > P: duma source: very-long-line-length-in-source-file 1628 > 512 > [win32-msvc.net/detoursexample1/detoursexample1.suo:2] > P: duma source: very-long-line-length-in-source-file 2810 > 512 > [win32-msvc.2005/example2/example2.suo:7] > P: duma source: very-long-line-length-in-source-file 2938 > 512 > [win32-msvc.2005/example1/example1.suo:8] > P: duma source: very-long-line-length-in-source-file 6371 > 512 > [win32-msvc.2005/dumadll/dumadll.aps:5] > P: duma source: very-long-line-length-in-source-file 6371 > 512 > [win32-msvc.net/dumadll/dumadll.aps:5] Ok, all .suo and .aps files in the duma package seem to be binary. I though have never heard of these file formats. Added nevertheless: https://salsa.debian.org/lintian/lintian/-/commit/5b70ce07fdc10b81a99049b6a2be50cbe4ae7009 > P: duma source: very-long-line-length-in-source-file 5025 > 512 > [docs-data/Data/SymbolTable.nd:6] > P: duma source: very-long-line-length-in-source-file 814 > 512 > [kduma/docs-data/Data/SymbolTable.nd:18] Only some of the .nd files in duma seem to be binary, others seem to be text. So I'm not declaring these suffixes as (always) being binary files. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1014511: sysvinit: debian/copyright reports incorrect licenses
Hi, binh1.tran...@toshiba.co.jp wrote: > Issue 1: The original debian/copyright reports incorrect licenses in > the most files from debian/ folder as below: > > Files: debian/* > License: GPL-2+ > Copyright: 2015 Adam Conrad >2018 Dmitry Bogatov >... >2012-2013 Steve Langasek > > Because "License: GPL-2.0+" is existed in files from debian/po/ folder, > and I didn't found any license in the most files from debian/ > folder. debian/copyright _IS_ the canonical place for copyright statements about debian/* > The correct licenses information should be: > > Files: debian/po/* > License: GPL-2+ > Copyright: ... So this is wrong and MUST NOT be changed as it would mean we would LOOSE the copyright statements for the remaining files in debian/*. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1014156: lintian: very-long-line-length-in-source-file for non-text source files
Control: tag -1 + confirmed Control: clone -1 -2 Control: retitle -2 lintian: very-long-line-length-in-source-file should use file/magic to distinguish text from binary files Control: submitter -2 Matt Barry Control: severity -2 wishlist Control: clone -1 -3 Control: retitle -2 lintian: very-long-line-length-in-source-file should ignore lines starting with INSERT or SELECT (i.e. commonly long SQL statements) Control: submitter -2 Peter B Hi, Daniel Kahn Gillmor wrote: > lintian 2.115.2 complains (in --pedantic) in the following way about > these non-text files in the gnupg2 sources: Thanks for this list. >From my point of view while many of these binary files might not be in the preferred representation (especially for the .gmo files I'd expect a plain text file to be the source), very-long-line-length-in-source-file should not be emitted for binary files. > I'd prefer it if lintian instead just wouldn't flag non-text source > files with this tag. Correct. Currently this is handled via a blacklist of common binary file suffixes. > - some of them are GNU message catalogs -- compiled output of .po files >that upstream prefers to ship in the tarball for folks building the >package without l10n toolchains. we rebuild them in debian, but i'd >still rather ship the upstream tarball if possible. Yep. Do expect that there will be a future lintian tag for these kind of files which is meant to be overriden if and only if the build system rebuilds them at build time. Matt Barry wrote: > Looking at the check, it seems there is an exemption for SVG files > built in; At least not at the suffix list. > would it make any sense to search for a text/* mime type > instead (ala libfile-libmagic-perl)? Yes, that would probably make more sense than manually curating a list of suffixes. Also the performance impact should be low as Lintian seems to run "file" over nearly every file anyways. That's nevertheless not a short term fix. Cloning this bug report into a new one to track this separately. Peter B wrote: > On 01/07/2022 06:08, Daniel Kahn Gillmor wrote: > > Package: lintian > > Version: 2.115.2 > > Severity: minior > > Control: affects -1 src:gnupg2 > > > > lintian 2.115.2 complains (in --pedantic) in the following way about > > these non-text files in the gnupg2 sources: > > > > P: gnupg2 source: very-long-line-length-in-source-file 1008 > 512 > > [po/eo.gmo:7] Please refrain from doing fullquotes in the Debian bug tracking system unless really necessary. Thanks! > I'm also seeing this with strawberry. Several hits from binary sound > files in it's test suite. Thanks for that list as well. One item though caught my eye: > > P: strawberry source: very-long-line-length-in-source-file 3435 > 512 > > [dist/macos/strawberry.icns:5678] The suffix "icns" is already in the blacklist since 2.115.2. With which version of Lintian did you generate that list? > > P: strawberry source: very-long-line-length-in-source-file 543 > 512 > > [CMakeLists.txt:535] > > P: strawberry source: very-long-line-length-in-source-file 687 > 512 > > [3rdparty/SPMediaKeyTap/README.md:4] > > P: strawberry source: very-long-line-length-in-source-file 756 > 512 > > [3rdparty/SPMediaKeyTap/LICENSE:8] These are likely a valid cases. > > P: strawberry source: very-long-line-length-in-source-file 559 > 512 > > [data/schema/schema-8.sql:587] > > P: strawberry source: very-long-line-length-in-source-file 566 > 512 > > [data/schema/schema-11.sql:235] These are corner cases IMHO. Not really binary files, but also files where long lines are very common, especially for INSERT and SELECT. I tend to write code which explicitly ignores lines starting with INSERT or SELECT for that. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1014254: lintian: Complex regular subexpression recursion limit (65534) exceeded at /usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Package: lintian
Version: 2.115.2
Severity: important
Checking a current firefox source package emits thousands of these perl
warnings:
[…]
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable firefox_102.0-1.dsc: Complex regular subexpression
recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
[…]
The code in question is:
# from perl faq strip comments
$lowercase =~ s{
# Strip /* */ comments
/\* [^*]*+ \*++ (?: [^/*][^*]*+\*++ ) */
# Strip // comments (C++ style)
| // (?: [^\\] | [^\n][\n]? )*? (?=\n)
| (
# Keep "/* */" (etc) as is
"(?: \\. | [^"\\]++)*"
# Keep '/**/' (etc) as is
| '(?: \\. | [^'\\]++)*'
# Keep anything else
| .[^/"'\\]*+
)
}{defined $1 ? $1 : ""}xgse;
This could be one reason (but very likely not the only one) to known
performance issues with lintian when checking postgresql (see #1014162)
or firefox. (Running lintian on a current firefox is said to take
several hours; which is the reason why I was trying to run lintian
against a current version of firefox.)
On a side note, lintian also needs more than approx. 10x the size of the
(compressed) source package for analysing, i.e. for the ca. 590 MB
source package, but it also first copies the tarball(s) which seems
rather unnecessary. Anyway:
Warning in processable firefox_102.0-1.dsc: No space left on device writing to
temp file at /usr/share/perl5/IPC/Run3.pm line 150.
$ du -sh /tmp/lintian-pool-*
5.2G/tmp/lintian-pool-OrasJ73xZK
Not really unexpected if it unpacks the whole source code, but still
caused troubles. Need to do these kind of tests on bigger RAM
disks. Which means in the end also to use boxes with more RAM. I've now
started such a run on rotating disks… Lets see how long that one takes.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'),
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1,
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages lintian depends on:
ii binutils2.38.50.20220629-4
ii bzip2 1.0.8-5
ii clzip [lzip-decompressor] 1.13-3
ii diffstat1.64-1
ii dpkg1.21.9
ii dpkg-dev1.21.9
ii file1:5.41-4
ii gettext 0.21-6
ii gpg 2.2.35-3
ii intltool-debian 0.35.0+20060710.5
ii iso-codes 4.10.0-1
ii libapt-pkg-perl 0.1.40+b1
ii libarchive-zip-perl 1.68-1
ii
Bug#1013331: lintian: Tag hints inside Lintian's own test suite should support wild cards to allow running it on non-amd64 hosts
Just another thought on this topic:
Axel Beckert wrote:
> https://ci.debian.net/data/autopkgtest/unstable/arm64/l/lintian/22908861/log.gz
[…]
> But simply replacing all occurrences of "x86_64" with "*" does not
> work. It though would be a start if it would work.
While having wildcards would be nice, there's probably an easier
because already implemented way:
Test description files ("desc") know about a field "Test-Architecure":
~/lintian/lintian → find t/recipes/checks -name desc | xargs fgrep amd64
t/recipes/checks/fields/multi-arch/fields-multi-arch-same-package-has-arch-specific-overrides/eval/desc:Test-Architectures:
amd64
t/recipes/checks/debian/lintian-overrides/mystery/fields-multi-arch-same-package-has-arch-specific-overrides/eval/desc:Test-Architectures:
amd64
t/recipes/checks/debian/lintian-overrides/restricted/amd64-on-arch-all/eval/desc:Testname:
amd64-on-arch-all
t/recipes/checks/debian/lintian-overrides/restricted/fields-multi-arch-same-package-has-arch-specific-overrides/eval/desc:Test-Architectures:
amd64
t/recipes/checks/debian/shlibs/binaries-multiarch/eval/desc:Test-Architectures:
i386 amd64
t/recipes/checks/files/architecture/binaries-multiarch/eval/desc:Test-Architectures:
i386 amd64
t/recipes/checks/files/architecture/binaries-multiarch-wrong-dir/eval/desc:Test-Architectures:
i386 amd64
t/recipes/checks/binaries/corrupted/binaries-from-other-arch/eval/desc:Test-Architectures:
amd64 i386
t/recipes/checks/binaries/static/binaries-from-other-arch/eval/desc:Test-Architectures:
amd64 i386
t/recipes/checks/binaries/architecture/other/binaries-from-other-arch/eval/desc:Test-Architectures:
amd64 i386
t/recipes/checks/binaries/hardening/binaries-hardening/eval/desc:Test-Architectures:
amd64 i386 armhf arm64
So we hopefully just need to add the currently on non-amd64 failing
tests to sport a "Test-Architectures: amd64" in their desc file.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1014083: Leaves many mldbm files in /tmp without cleanup
Control: found -1 2.115.1 Control: severity -1 important Control: tag -1 + confirmed Hi Josh, Josh Triplett wrote: > The current version of lintian seems to create numerous temporary files > in /tmp/mldbm-elf-* and /tmp/mldbm-elf-by-member-* and while some of > them disappear by the time lintian finishes, others remain around > without getting cleaned up. Thanks! I also already noticed it a few days ago, too, but so far assumed that this was mostly caused by the test suite (which runs lintian only check by check), not by running lintian in its normal mode with all checks. So it's already on my mental TODO list to figure out why these files are not cleaned up properly. The fact that this also happens in Lintian's normal operation and not just when running via test suite makes this issue more severe than I thought and I'll raise my priority for it (and also the severity in the BTS). So thanks again for this bug report and and reminder! (And yes, my /tmp/ was filled with ten thousands of these files. I noticed it after investigating why a GUI file open dialog in /tmp/ froze for many seconds until I could interact with it.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013946: lintian: wrongly report unknown-locale-code ber
Hi Tobias,
Dr. Tobias Quathamer wrote:
> The safest way for lintian would probably be to use ISO 639-3 as a source
> for locale checking, because those codes represent an individual language.
> The vast majority of program translations are into an individual language,
> so the check seems plausible.
>
> For bonus points, you could also check ISO 639-5 and print a warning (or
> info) that this locale code represents a language group rather than an
> individual language. :-)
>
> This is essentially Axel's latest suggestion -- except that I'd suggest to
> use ISO 639-3 instead of ISO 639-2 as authoritative source.
Thanks for this summary and especially also all the history! (And for
reading our long mails which showed bit by bit our experiences and
discoveries. :-)
> Sorry for this long e-mail, but languages and their codes are pretty
> hard ...
No need to be sorry!
Will try to implement this in lintian.
Thanks again!
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1007002: Lintian breaks existing lintian-overrides due to added []
Hi again,
Axel Beckert wrote:
> Andreas Tille wrote:
> > I'll start editing lintian-overrides then.
>
> Maybe wait a bit with that. Given Lucas' comment, I feel a bit more
> urged to provide such a migration script.
>
> I will look into this for the next upload. No promises as of now,
> though.
A first prototype is now available in git in the branch
"migrate-overrides":
https://salsa.debian.org/lintian/lintian/-/blob/migrate-overrides/bin/lintian-migrate-overrides-to-pointed-hints
So far the script only knows about the tags spelling-error-in-binary
and package-contains-documentation-outside-usr-share-doc, but it is
explicitly written to be expandable. Of course it will also get
support for more tags in the (near) future.
Additionally it currently only prints the transformed result to
STDOUT. The plan is to also support inline editing, either with an -i
option or maybe even by default if it detects that the package is
maintained in git.
Please give me feedback if this approach (especially after inline
editing is supported) is feasible — preferably from those who are
annoyed. :-)
It's not yet in the master branch as neither Perl::Critic nor myself
are happy about the usage of (the expression form of) "eval" in there.
(Maybe one of the other JAPH has an idea on this. :-)
Patches and other improvements suggestions as well as pattern sets for
further tags are of course welcome as well.
(Note: I will probably force-push that feature branch over and over
again until I'm satisfied. If someone else wants to work on the same
branch, too, we can also work without forced pushes and squash-merge
the result at the end. Please contact me, if you're interested.)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1007002: Lintian breaks existing lintian-overrides due to added []
Hi Lucas, Lucas Nussbaum wrote: > Just a note that since the last version of lintian to migrate to testing > was 2.111 (which was also the last one to be backported to stable), some > of us might not have updated since 2.111 and might be hit by changes > that happened since then. Oh, right! Thanks for that view on Andreas' mail. I indeed did not think about that case because I do nearly all Debian development work on Unstable (and occassionally on Stable when a new package starts as a quick and dirty hack to scratch my own itches at work :-). And until my reply to Andreas I also wasn't aware of when Felix actually started with this. Just knew that it wasn't a one-shot thing, but quite distributed over at least the past half year (because that's the timeframe of git commits I most often looked into in the past few weeks). Andreas: Sorry if I was a bit too opposing because of assuming that every DD uses Unstable by default. (Actually I think the Dev Ref says you should, though. ;-) Or if DDs pinned Lintian to 2.111.0 from Testing… Andreas Tille wrote: > I'll start editing lintian-overrides then. Maybe wait a bit with that. Given Lucas' comment, I feel a bit more urged to provide such a migration script. I will look into this for the next upload. No promises as of now, though. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1007002: Lintian breaks existing lintian-overrides due to added []
Hi Andreas, Andreas Tille wrote: > I realised that lintian (at least) starting with version 2.115.1 (may be > earlier) wraps file names into [] which breaks existing > lintian-overrides. Correct, except that it happened for quite a while (7 months at least) and was (and maybe still is — see below) a continuous transition. It is present since at least 2.114.0 from November 2021. According to the git history, the implementation started shortly before the 2.114.0 upload, but the bug report which requested this is actually from 2014: https://bugs.debian.org/743226 And yes, 2.115.0 (but not 2.115.1 or 2.115.2 from today) had more such changes as there were over 200 commits from Felix included which he did after 2.114.0, but which weren't uploaded since then. Many of them were (IMHO irresponsibly) marked "Gbp-Dch: Ignore" and hence didn't show up in debian/changelog when I generated it with "gbp dch". (I though ignored that in some cases and added them manually to the debian/changelog entry, partially even retroactively.) > I consider these [] not helpful […] no visible advantage. The advantage is to clearly mark what is a file with potentially a line number in the output of lintian so that further processors like the lintian website can do deep links to the proper code position on e.g. sources.debian.org or salsa.debian.org. Felix called it "pointed hints". From my point of view, that's quite an advantage. See also https://bugs.debian.org/1007002 for the proper bug report about the issue with invalidating overrides by this transition. I've added it to the Cc of this thread and dropped lintian-ma...@debian.org instead as mails to that bug report get forwarded to the Lintian Team anyway. > since it breaks lots of lintian-overrides Felix decided that it's worth to implement this requested feature and I at least partially agree as I do clearly see the advantage and also like the possibilities which this now offers. > Could this change in lintian please be reverted? I clearly won't do that — for multiple reasons: * Far too much work for the gain (IMHO) * Losing a requested feature. * Invalidating 7 months of already updated overrides. * Better ways to invest your (and my) time. (See my proposition below.) Background: This seems not to have been one big commit but many small commits whenever a tag was touched by Felix. Reverting it to the old format would be a huge effort for which I don't have the time as there are way more pressing issues in lintian. And I'm very sure it can't be done by just doing a bunch of "git revert". So far I found 15 commits by Felix mentioning "pointed hint" reaching from November 2021 to March 2022. With about 200 other, partially quite invasive commits inbetween. And in addition to that, it's IMHO _far_ too late, because many maintainers already have updated their overrides in the past 7 months. And I'm currently not sure if I would even accept a Merge Request which tries to do that. But I doubt that anyone would a) make that effort and b) make all those maintainers angry who already updated their overrides in the past 7 months or more. Roberto C. Sánchez wrote: > Or perhaps make the new format default That was Felix' plan, yes. I just have currently no idea how many tags have been and how many haven't been converted yet. If there aren't too many tags left, I might finish this transition. If there are many tags left, I'd only do that if we have a way to cope with it with much less effort than it so far caused. And from my point of view, the only way to get out of this mess without causing too much work for anyone (maintainers of packages with affected overrides as well as the current Lintian maintainers): Someone should write a converter from the old to the new format. That doesn't sound too difficult. Main work would be gathering for each tag involved how it looked beforehand and how it looked now. This probably can be gathered from changes in git to Lintian's test suite. And maybe it should even try to output overrides which are compatible with the old and new format, at least in cases where the order of parameters didn't change. See lintian's own overrides for some examples: https://salsa.debian.org/lintian/lintian/-/blob/master/debian/source/lintian-overrides (Although this also accounts for a bug which only ever was present in Lintian's git repository and never got uploaded, but still got an RC bug report because people started using lintian off the git repo due to it no having been maintained for months: https://bugs.debian.org/1003353) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1013946: lintian: wrongly report unknown-locale-code ber
Hi Russ, Russ Allbery wrote: > So in short, I think I talked myself back around to your solution. > :) Same to me, I talked myself back around to your (previous) opinion. :-) Hilarious! So we both seem to have had good arguments. :-) Hrm, a serious thought on this: Why not implement both variants? What if we * make unknown-locale-code look at ISO 639-1, 639-2, 639-3 and even 639-5 for generally valid codes, and then * add a new, maybe pedantic-level warning which is only emitted if a language group is used in a locale name, i.e. check locales against ISO 639-5 and if one of these (which IIRC include the language groups present in ISO 639-2) is used as locale, we emit a tag which might be named locale-uses-language-group-code or similar? This currently sounds if it would make use of all our arguments for and against including ISO 639-2, would be backwards compatible and more precise and helpful. Ok, and I should really go to bed now. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013946: lintian: wrongly report unknown-locale-code ber
Hi,
one more comment:
Russ Allbery wrote:
> I worked out the same thing, and I'm fairly sure that means that this is
> not a valid locale. It's the code for the Berber language *group*, and
> the individual members of that group have their own 639-3 codes, so that
> seems to imply to me that those translations were tagged with the wrong
> code.
So I wondered what they should actually be tagged as. "Judeo-Berber"
is the only language with the string "berber" I found in ISO 639-3.
Unfortunately I found no mapping between ISO 639-2/-5 language groups
and actual languages in ISO 639-3 — in neither of JSON files for these
three parts.
So I dug around in Wikipedia and figured out that Judeo-Berber is a
"Non-Zenati Northern Berber language". And it using the Hebrew
alphabet seems to be a unique characteristic. Which again seems rather
specific and if it's a Berber language and hasn't Hebrew letters, it's
likely not Judeo-Berber.
Given https://en.wikipedia.org/wiki/File:Linguistic_Diagram_Berber.png
(from https://en.wikipedia.org/wiki/Berber_languages) there are tons
of possible languages gathered under "Berber languages", so the longer
the more I tend to agree with Russ' arguments to stay with ISO 639-3
only.
Plus maybe add a few more notes to the tag description to explain why
language groups are probably no good idea for locales.
Still would be happy about input from Toddy on this. :-)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013946: lintian: wrongly report unknown-locale-code ber
Control: tag -1 + help Hi Russ, Russ Allbery wrote: > > But upon deeper inspection I found that this is likely not an issue in > > iso-codes as "ber" is correctly not in > > /usr/share/iso-codes/json/iso_639-3.json but in …/iso_639-2.json and > > …/iso_639-5.json as it is a code for a language group. (Which kinda > > makes it suspicious for me to be used in locales. But then again I'm > > not a linguist.) > > Sorry, I followed up on the bug and forgot to explicitly cc Lintian Not needed. I got the message via the lintian ML / maintainer address. (Somehow I though didn't get my own messages to that bug report back via the list.) > I worked out the same thing, and I'm fairly sure that means that this is > not a valid locale. It's the code for the Berber language *group*, and > the individual members of that group have their own 639-3 codes, so that > seems to imply to me that those translations were tagged with the wrong > code. Yep, I also noticed that. I'm just not sure where exactly the border between just a group of languages, which has no common grounds to be spoken anywhere, and a group of very similar languages, which likely can be understood by members of another language from the same group and maybe even have a common written language, is. Toddy may indeed have some more input for us here. > Fabio also followed up and noted that there are a few translations for ber > in Launchpad, but they're all partial and probably not usable. Ok, I didn't get that mail. So maybe I really didn't get your initial mail, just another mail from you to the bug report. :-) > Tobias probably knows more, as iso-codes maintainer, but my guess is that > this is a mistake on the Launchpad side and those translations should be > for one of the specific languages of the group rather than being coded to > the 639-5 language group code. I think Lintian should still continue to > use 639-3. > > That said, I'll leave it to you to decide if you want to hang on to the > bug or not. :) Thanks for your input here. Actually that variant so far was my second choice (the stricter one) so far. See the very end of that one long mail from me. :-) Anyway, JFTR: I just looked at how lintian in Debian Stable (i.e. 2.104.0 in Bullseye) does the locale code lookup. It had it's own data file for that (and hence now using iso-codes is good as it is no more duplicating these 33kB of data) and that file (/usr/share/lintian/data/files/locale-codes) states: # List of locale codes. This is derived from the ISO 639-1, ISO # 639-2, and ISO 639-3 standards. And indeed, "ber" was in that file. So previously lintian did use ISO 639-1, 639-2 and 639-3. So using just ISO 639-3 was either an accident, on purpose or a regression and has been introduced when lintian was switching to iso-code's files as data source in commit https://salsa.debian.org/lintian/lintian/-/commit/fcaded19 Unfortunately this commit was tagged "Gbp-Dch: ignore" in git (why?!?), so it didn't appear in debian/changelog. *g* (I may retroactively add it to the debian/changelog entry of 2.115.0 like I already added the item about switching to Text::Glob which also caused bugs.) Anyway, with you proposing a more strict checking here and I was at least initially proposing to get back to the more laxer parsing used previously, it would be really good to have some additionaly input from someone with a bit more experience on that topic. I hope that Toddy can provide that. :-) Tagging as help for that reason. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013946: lintian: wrongly report unknown-locale-code ber
Control: affects -1 - lintian
Control: reassign -1 lintian
Control: found -1 2.115.1
Hi Russ,
Russ Allbery wrote:
> Thanks for the report! Lintian gets the canonical list of locales from
> the iso-codes package, and if I'm reading the last modification times from
> its Salsa repository correctly, it may have been a bit since it was
> updated.
>
> I'm reassigning this bug to iso-codes for further investigation and cc'ing
> the maintainer.
Thanks for your effort, Russ! That was my first guess, too.
But upon deeper inspection I found that this is likely not an issue in
iso-codes as "ber" is correctly not in
/usr/share/iso-codes/json/iso_639-3.json but in …/iso_639-2.json and
…/iso_639-5.json as it is a code for a language group. (Which kinda
makes it suspicious for me to be used in locales. But then again I'm
not a linguist.)
Lintian only uses …/iso_639-3.json as of now. And according to source
code comments it thinks that ISO 639-1 and ISO 639-2 are both subsets
of ISO 639-3 which is clearly wrong.
In the end it is one of the cases where the POSIX specification is
ambiguous as it doesn't state which part of ISO 639 is relevant. (And
ISO doesn't make this easier as ISO 639-1 was just called "ISO 639"
when it was first published in 1967.)
So reassigning back to lintian. :-)
I'll implement a change in lintian which also takes ISO 639-2 into
account.
Toddy: I though wouldn't be unhappy if you could have a look at my
reasoning in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013946#33 which I
unfortunately didn't Cc to you. My main question is: Which parts of
ISO 639 are valid for usage in POSIX locales? I couldn't answer it
even after like 2 hours of digging standards and Wikipedia. Maybe you
can. :-)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013946: lintian: wrongly report unknown-locale-code ber
-3 covers most languages but neither macrolanguages nor language families and hence should be included, too. * ISO 639-5 only includes language families and groups and hence should _not_ be included. If anyone has a different opinion on this topic, please speak up (and preferably also explain why :-). But actually there are only two other options which I consider to be feasible: * Keep ISO 639-3 as only source for valid locales. (Which would make this issue a true positive.) * Allow any (non-withdrawn) ISO 639 part as source for a valid locale name, i.e. use ISO 639-2, 639-3 and 639-5. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013873: lintian: "Cannot open" warnings on symlinks to files in other packages from same source
Control: severity -1 important Hi Andreas, Andreas Metzler wrote: > lintian has recently started throwing errors like this for when run on > exim4_..._amd64.changes (source + binary upload): > > -- > Warning in processable ../exim4-daemon-heavy_4.96-1_amd64.deb: Cannot open > /dev/shm/lintian-pool-b_2HrMSwnf/exim4/exim4-daemon-heavy_4.96-1_amd64_binary/unpacked/usr/share/doc/exim4-daemon-heavy/README.Debian.gz > at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109. > warning: cannot run debian/readme check on package > binary:exim4-daemon-heavy_4.96-1_amd64 > -- Interesting. Thanks for the bug report! > The respective file is a symlink to the file in exim4-base/: > (sid)ametzler@argenau:/tmp/EXIM4/exim-4.96$ ls -l > debian/exim4-daemon-heavy/usr/share/doc/exim4-daemon-heavy/README.Debian.gz > lrwxrwxrwx 1 ametzler ametzler 30 Jun 26 11:53 > debian/exim4-daemon-heavy/usr/share/doc/exim4-daemon-heavy/README.Debian.gz > -> ../exim4-base/README.Debian.gz Since ../exim4-base/README.Debian.gz is actually existing, I wonder if that "<:gzip" in 109 open($fd, '<:gzip', $item->unpacked_path) plays a role here. My current guess is that there is a "use PerlIO::gzip;" missing in lib/Lintian/Check/Debian/Readme.pm since it it seems required to make "<:gzip" work (wonder why it does only spew runtime warnings because of that and doesn't bail out at compile time already) and it is present in quite some other Lintian Perl modules: ~/lintian/lintian → git grep PerlIO::gzip lib/Lintian/Data/Debhelper/Addons.pm:use PerlIO::gzip; lib/Lintian/Data/Debhelper/Commands.pm:use PerlIO::gzip; lib/Lintian/Data/Fonts.pm:use PerlIO::gzip; lib/Lintian/Data/InitD/VirtualFacilities.pm:use PerlIO::gzip; lib/Lintian/Processable/Installable/Overrides.pm:use PerlIO::gzip; ~/lintian/lintian → Will check. And if I'm right with my guess, I'll likely will write a test first for this type of bug as there are quite some more such cases: ~/lintian/lintian → git grep -Fl '<:gzip' | xargs fgrep -L 'use PerlIO::gzip;' lib/Lintian/Check/Debian/Readme.pm lib/Lintian/Check/Documentation.pm lib/Lintian/Check/Documentation/Manual.pm lib/Lintian/Check/Documentation/Texinfo.pm lib/Lintian/Check/Languages/Fortran/Gfortran.pm lib/Lintian/Check/Languages/R.pm lib/Lintian/Data/Authority/DocBaseManual.pm lib/Lintian/Data/Authority/VimPolicy.pm ~/lintian/lintian → Raising severity to important because this issue has quite some impact if my guess above is correct. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013918: lintian: False positive: `chown --reference=foo bar.baz` triggers chown-with-dot
Control: user lintian-ma...@debian.org
Control: usertag -1 false-positive
Hi,
Guilhem Moulin wrote:
> roundcube-core's postinst contains
>
> chown --reference="$CONFFILE" "$CONFFILE.ucftmp"
>
> which triggers a false positive with tag chown-with-dot. Indeed
> "chown --reference=foo bar.baz" matches
>
> m{ \b chown \s+ (?: -\S+ \s+ )* ( \S+ [.] \S+ ) \b }x,
>
> but that chown command has no ambiguous user.group argument.
Nice catch! Thanks for the bug report!
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Control: tag -1 - moreinfo Hi Guillem, Guillem Jover wrote: > > Can you please elaborate what exactly is the bug? You refer to > > something being problematic without explaining what actually is > > problematic. > > lintian used to exit with a non-zero value when it emitted at least > one error tag. This was changed, for some reason, and then it stopped > doing that, instead requiring users to specify --fail-on=error. This > was supposedly reverted, but the patch that got applied that fixed > this at the time of submission did not apply at the time it got > committed due to refactoring, and it was ineffective. As such the > --help output now is misleading, mentioning that the default --fail-on > is "error" when it is not. Thanks for that summary, it helped a lot. I'll have a look. > I'd have to re-dig all this. I might just try to provide a patch, I > think should probably be a one-liner. A patch of course would be nice, but I won't mind if you don't provide one. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013417: lintian: dkms updates
Control: tag -1 + confirmed
Hi Andreas,
Andreas Beckmann wrote:
> Package: lintian
> Version: 2.115.1
[…]
> I recently split a dh-dkms package from the dkms binary package.
I'm aware of that. It is partially already supprted in Lintian since
commit cfafa44256133c458011e3f13440de6538dd6045 which is part of the
2.115.0 release already:
https://salsa.debian.org/lintian/lintian/-/commit/cfafa44256133c458011e3f13440de6538dd6045#78b2b372e63b40b17bfc9c37d820cbf5b2ebb24c_103_108
I'm just not sure if such a hard cut is a good way to actually handle
the old and new variant for a transition period. Then again, lintian
is probably the last place which should care about old packages. :-)
> Please update lintian's suggestions for the respective B-D:
>
> for 'dh --with dkms', there should be a B-D: dh-dkms (instead of
> B-D: dkms) for 'dh_dkms', there should be a B-D: dh-dkms (instead of
> B-D: dkms)
I thought that's already done by the change mentioned above, but then
again a quick git grep also found this as of the current git HEAD:
lib/Lintian/Check/Debhelper.pm:dh_dkms => 'dkms:any | dh-sequence-dkms:any',
> or (preferably) B-D: dh-sequence-dkms (lintian already knows about that).
Looking for that is how I found the line above. :-)
> And the I'd like to have all *-dkms binary packages to have
> Testsuite: autopkgtest-pkg-dkms
> on their source package.
That's on my TODO list to figure out how it actually works for my own
dkms-based package. :-)
> Not sure how to model that in lintian.
I think I can figure out. :-)
> Either on the source package: B-D: dh-dkms | B-D: dh-sequence-dkms
> or on the binary package relationships: Depends: dkms
> or on the binary package content: /usr/src/*/dkms.conf
Indeed, package name matches /-dkms$/ is probably not enough.
Will think about it.
Thanks!
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013414: lintian: spurious unknown-field Autobuild
Control: severity -1 important
Control: user lintian-ma...@debian.org
Control: usertags -1 false-positive
Hi Andreas,
Andreas Beckmann wrote:
> after #999768 (false report: adopted-extended-field XS-Autobuild) was
> fixed, I'm now getting
>
> W: nvidia-graphics-drivers source: unknown-field Autobuild
>
> $ grep Autobuild debian/control
> XS-Autobuild: yes
Thanks for the bug report!
The fact that this happened is a side effect of Lintian's test suite
no more running _all_ lintian checks against all test packages but
always only the targeted ones. Otherwise I likely would have caught
that. :-( — Then again running Lintian's autopkgtest already takes 1
hour and 40 minutes on Salsa CI and about 40 minutes on my workstation
at home and that's already long enough. :-/
>From the hours I put into "fixing" #999768, I'm inclined to rewrite
the check behind it from scratch (without changing the tag format)
because its current logic seems rather unlogic to me: From what I
remember, it's mostly stripping the X[SB]?- prefixes first and then
checking the remainder against some list of well-known fields.
Don't expect a fix (in unstable) before the current release of Lintian
has migrated to testing, though. No promises for 2.116.0 at this time
either.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013331: lintian: Tag hints inside Lintian's own test suite should support wild cards to allow running it on non-amd64 hosts
Package: lintian Version: 2.115.1 Severity: wishlist Citing from https://ci.debian.net/data/autopkgtest/unstable/arm64/l/lintian/22908861/log.gz -O debci-lintian-sid-arm64-22908861.log.gz: # Hints do not match # # --- ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/hints.specified.calibrated # +++ ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/hints.actual.parsed # -gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/x86_64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/GoodExtras-42.typelib] # -gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/x86_64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/Good-42.typelib] # +gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/aarch64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/GoodExtras-42.typelib] # +gir1.2-good-42 (binary): typelib-not-in-multiarch-directory usr/lib/aarch64-linux-gnu/girepository-1.0 [usr/lib/girepository-1.0/Good-42.typelib] # # Failed test 'Lintian passes for gir' # at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343. # Looks like you failed 1 test of 1. ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t ... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests # Hints do not match # # --- ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/config-scripts/files-old-config-script/hints.specified.calibrated # +++ ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/config-scripts/files-old-config-script/hints.actual.parsed # -config-ma-foreign (binary): old-style-config-script-multiarch-path full text contains architecture specific dir x86_64-linux-gnu [usr/bin/arch-foreign-config] # -config-ma-foreign (binary): old-style-config-script-multiarch-path full text contains architecture specific dir i386-linux-gnu [usr/bin/x86_64-linux-gnu_-arch-cross-foreign-config] # -config-ma-foreign (binary): old-style-config-script-multiarch-path full text contains architecture specific dir i386-linux-gnu [usr/bin/arch-cross-foreign-config] # -config-ma-foreign (binary): old-style-config-script [usr/bin/x86_64-linux-gnu_-arch-foreign-config] # -config-ma-foreign (binary): old-style-config-script [usr/bin/x86_64-linux-gnu_-arch-cross-foreign-config] # -config-all (binary): old-style-config-script-multiarch-path-arch-all full text contains architecture specific dir x86_64-linux-gnu [usr/bin/arch-all-config] # -config-all (binary): old-style-config-script-multiarch-path-arch-all full text contains architecture specific dir i386-linux-gnu [usr/bin/x86_64-linux-gnu_-arch-cross-all-config] # -config-all (binary): old-style-config-script-multiarch-path-arch-all full text contains architecture specific dir i386-linux-gnu [usr/bin/arch-cross-all-config] # -config-all (binary): old-style-config-script [usr/bin/x86_64-linux-gnu_-arch-cross-all-config] # -config-all (binary): old-style-config-script [usr/bin/x86_64-linux-gnu_-arch-all-config] # +config-ma-foreign (binary): old-style-config-script-multiarch-path full text contains architecture specific dir x86_64-linux-gnu [usr/bin/arch-cross-foreign-config] # +config-ma-foreign (binary): old-style-config-script-multiarch-path full text contains architecture specific dir x86_64-linux-gnu [usr/bin/aarch64-linux-gnu_-arch-cross-foreign-config] # +config-ma-foreign (binary): old-style-config-script-multiarch-path full text contains architecture specific dir aarch64-linux-gnu [usr/bin/arch-foreign-config] # +config-ma-foreign (binary): old-style-config-script [usr/bin/aarch64-linux-gnu_-arch-foreign-config] # +config-ma-foreign (binary): old-style-config-script [usr/bin/aarch64-linux-gnu_-arch-cross-foreign-config] # +config-all (binary): old-style-config-script-multiarch-path-arch-all full text contains architecture specific dir x86_64-linux-gnu [usr/bin/arch-cross-all-config] # +config-all (binary): old-style-config-script-multiarch-path-arch-all full text contains architecture specific dir x86_64-linux-gnu [usr/bin/aarch64-linux-gnu_-arch-cross-all-config] # +config-all (binary): old-style-config-script-multiarch-path-arch-all full text contains architecture specific dir aarch64-linux-gnu [usr/bin/arch-all-config] # +config-all (binary): old-style-config-script [usr/bin/aarch64-linux-gnu_-arch-cross-all-config] # +config-all (binary): old-style-config-script [usr/bin/aarch64-linux-gnu_-arch-all-config] # # Failed test 'Lintian passes for files-old-config-script' # at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343. # Looks like you failed 1 test of 1. ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/config-scripts/files-old-config-script/generic.t Dubious,
Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way
Hi, chiming in as the new Lintian maintainer. :-) Felix Lechner wrote: > Your package is the only known consumer of Lintian's internal Perl > modules. [] I haven't read all the discussion in this bug report, but I stumbled upon it due to these lines in debian/lintian.install: # the next line will be removed when libconfig-model-dpkg-perl stops using Lintian data (Bug#968000) private/latest-policy-version usr/share/lintian/private private/latest-policy-version also seems to be the current way, how libconfig-model-dpkg-perl interacts with this data in Lintian. Actually the fact that this script is used in libconfig-model-dpkg-perl's autopkgtest caused a regression in (or by and for) lintian 2.115.0 because Felix moved one method used in this script from Lintian::Profile to Lintian::Data and forgot to update this script (which Lintian itself doesn't seem to use). So I'll soon upload lintian 2.115.1 to fix this issue to finally get the current Lintian version into testing. On the other it seems as if no lintian-internal check caught this issue, so I'm kinda happy that this has happend. But it also shows what happens if internal modules or so are used. ;-) For a potential long term solution: On #debian-qa, pabs (Cc'ed) was suggesting to the Lintian and DUCK maintainers (Cc'ed as well) to use a common data package for data currently synced occassionally between both source packages. I suggested to build that data out of src:lintian and the duck maintainer was happy with that. Hence I suggest that libconfig-model-dpkg-perl, cme, etc. are then using this planned data packages in the future as well. I currently the following: * Create a new binary package lintian-data, which is built from src:lintian. It will more or less contain /usr/share/lintian/data/. * Additionally I will create a file named /usr/share/lintian/data/debian-policy/latest.txt (or similar) at lintian build time based on the output of private/latest-policy-version. (Can even do that already before splitting off that data package.) That way you have the wanted data in an easily consumable form without having to call any script or module from Lintian and without having to parse a huge bunch of JSON. And we can easily ship that file in a pure data package, not requiring you to pull in all dependencies of Lintian, either. Would that work out for you? If so: What are your requirements for such a transition? Do we have to just care about Unstable and Testing or are Stable-Backports a topic, too? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1003456: marked as pending in lintian
Hi Ben,
Ben Hutchings wrote:
> > https://salsa.debian.org/lintian/lintian/-/commit/192e15ae2eda7535622d44d2f3f382783b110ee5
> [...]
>
> This didn't fix the issue. It is still reproducible by building linux
> for amd64 and then running lintian over the resulting .changes file.
>
> Running lintian over a single linux-image--amd64-dbg binary
> package also shows the issue, but requires "only" about 12 GB of VM and
> does complete on my development system.
Thanks for these details and for reopening!
Will also have a look at it.
Given that it is a debug package, I'll see if I can either
* find the cause by debugging the code,
* find the cause by bisecting, or
* reduce the amount of checks run against it as many
make no sense for debug packages.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1003353: tagging 1012326, tagging 1012690, tagging 1012464, tagging 1001317, tagging 1012221, tagging 1011807 ...
Hi Andreas, Andreas Beckmann wrote: > On 19/06/2022 16.27, Axel Beckert wrote: > > please explain what makes you think that this issue is present in > > lintian 2.114.0 as currently in Debian Unstable. > > The BTS does not understand made up versions (i.e. versions not in the > archive), Yes, I'm aware of that. > so this bug shows up e.g. as a RC bug in stable. Ah! I wasn't aware of that. Thanks for the explanation. I mostly consider these non-official versions to be informational for humans. Didn't expect such an impact. > So limiting this bug with an incorrect version to sid+ was the > smaller lie ... Well, I prefer the tagging much more than the wrong version, even if it's the same lie. That way there's more information in there for us humans. And yes, that weird versioning the previous maintainers started and even claim that it is semantic versioning despite it's not semantic versioning (https://semver.org/) at all, will likely be killed, once I understand how lintian.d.o works (or not) nowadays. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1003353: lintian: Cannot use brackets in suppression rules?
Control: tag -1 + pending patch
Hi Samuel,
Samuel Thibault wrote:
> Seeing that qa.debian.org is using version 2.114.123 of lintian, I
> upgraded my lintian from its git tree, only to find that it seems I
> cannot update my suppression rule according to the new output:
>
> W: libbrlapi-dev: bad-whatis-entry
> [usr/share/man/man3/brlapi_authClientPacket_t.3.gz]
> W: libbrlapi-dev: mismatched-override bad-whatis-entry
> [usr/share/man/man3/brlapi_*] [usr/share/lintian/overrides/libbrlapi-dev:2]
>
> I did have updated this rule to include brackets:
>
> bad-whatis-entry [usr/share/man/man3/brlapi_*]
>
> but that doesn't seem to be working. I also tried to use escaping (which
> had fixed things for the ${} case), but to no avail:
>
> bad-whatis-entry \[usr/share/man/man3/brlapi_*\]
Using * or ? in place of the brackets probably would have worked.
Cause was the switch of was this commit from 6 months ago:
commit 139009d5a54225ebff4509ec37b979cb898c17fe
Author: Felix Lechner
Date: Wed Dec 1 21:46:24 2021 -0800
Use Text::Glob to match hint contexts with override patterns.
Replaces a trusted homegrown routine.
Gbp-Dch: ignore
I neither understand why you would replace something "trusted" and
additionally not even plan to mention such a invasive commit in the
changelog.
And because Text::Glob also interprets brackets (and curly braces) and
you can't disable that, such issues were just waiting to happen.
And together with the brackets using "pointed hints" concept
introduced at around the same time, this caused really havoc.
> Lintian has recently been annoying enough that I'm unsure I'd continue
> monitoring its output any more.
*nod* JFYI, in case you didn't notice it (it happend months after your
bug report), but there was an "O: lintian" WNPP bug report in the
meantime: https://bugs.debian.org/1012289
So I'm now trying to clean up the shattered remains which the previous
(recent) Lintian maintainer(s) left behind.
For now I'm trying to get a current lintian version back into Testing,
i.e. I'm concentrating on RC and important bugs as well as bugs which
are annoying and easy to fix, e.g. those with a patch or MR.
At least the lintian internal test suite is no more failing. Although
it likely has some false negatives as it seems that the test suite is
no more able to run more than one check in one test. And running a
test against multiple checks at the same time seems critical to write
tests for issues like this one. Meh.
Anyway, my feature branch for this bug report is
https://salsa.debian.org/lintian/lintian/-/commits/brackets-in-overrides-rc-bug-1003353
but I will likely force-push that branch some more times, so the
commit message in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003353#50 might
become stale soon while I refine the commit before that (which
contains a test for this bug), but the patch will likely stay valid.
You also might get further such mails when I force-push new histories
in that feature branch. I hope you don't mind, but I wanted to publish
what I already have.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
signature.asc
Description: PGP signature
Bug#1013247: telegram-desktop: Crashes on entering a chat if the window is too narrow (less wide than ca. 380 pixel) or resized to below ca. 380 pixel width while a chat is open
Package: telegram-desktop Version: 3.7.3+ds-2+b1 Severity: important Hi, telegram-desktop crashes for me if I make its window smaller than some specific window width or start it and it gets resized to such a width by i3 (tiling window manager) and then open e.g. a group chat. It basically happens once the speech bubbles don't become less wide than the available space anymore. If I first make the window too small and then enter the group chat, I only see the very last speech bubble before it crashes (probably during trying to display the remaining speech bubbles). A window size of 381x572 was fine, and a window size of 378x572 or less wide triggered the crash. The crash output ends as follows: DSvgRenderer::load: XML parse error: Input file is too short /usr/include/c++/11/bits/stl_algo.h:3658: constexpr const _Tp& std::clamp(const _Tp&, const _Tp&, const _Tp&) [with _Tp = int]: Assertion '!(__hi < __lo)' failed. [4] + 8736 IOT instruction (core dumped) This is reproducible for me: ~crash/1000 → ls -ltr *telegram* -rw--- 1 abe abe 2875678720 Jun 19 23:53 12097-1000-1000-6-1655675593-c6--usr-bin-telegram-desktop--deleted-.core -rw--- 1 abe abe 628158464 Jun 19 23:53 1764-1000-1000-6-1655675638-c6--usr-bin-telegram-desktop.core -rw--- 1 abe abe 538529792 Jun 19 23:54 2201-1000-1000-6-1655675651-c6--usr-bin-telegram-desktop.core -rw--- 1 abe abe 538755072 Jun 19 23:54 2932-1000-1000-6-1655675678-c6--usr-bin-telegram-desktop.core -rw--- 1 abe abe 538767360 Jun 19 23:56 4579-1000-1000-6-1655675773-c6--usr-bin-telegram-desktop.core -rw--- 1 abe abe 537563136 Jun 20 00:08 8736-1000-1000-6-1655676533-c6--usr-bin-telegram-desktop.core -rw--- 1 abe abe 535805952 Jun 20 00:19 10857-1000-1000-6-1655677151-c6--usr-bin-telegram-desktop.core -rw--- 1 abe abe 545185792 Jun 20 00:19 12650-1000-1000-6-1655677178-c6--usr-bin-telegram-desktop.core -rw--- 1 abe abe 523145216 Jun 20 00:34 15104-1000-1000-6-1655678091-c6--usr-bin-telegram-desktop.core -rw--- 1 abe abe 537464832 Jun 20 00:35 19830-1000-1000-6-1655678103-c6--usr-bin-telegram-desktop.core Backtraces available in private upon request. The one core dump containing the word "deleted" was from before the BinNMU for the Qt transistion. So I suspect that it is _NOT_ related to it. I just tried this for the first time (in a long time) after that transition by chance. -- Package-specific info: -- BEGIN ATTACHMENTS -- /home/abe/.local/share/TelegramDesktop/log.txt -- END ATTACHMENTS -- -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages telegram-desktop depends on: ii libabsl20210324 0~20210324.2-4 ii libavcodec-extra58 [libavcodec58] 7:4.4.2-1+b3 ii libavformat-extra58 [libavformat58] 7:4.4.2-1+b3 ii libavutil56 7:4.4.2-1+b3 ii libc6 2.33-7 ii libgcc-s1 12.1.0-4 ii libglib2.0-02.72.2-2 ii libglibmm-2.4-1v5 2.66.4-1 ii libhunspell-1.7-0 1.7.0-4 ii libjpeg62-turbo 1:2.1.2-1 ii libkf5waylandclient54:5.94.0-2 ii liblz4-11.9.3-2 ii libminizip1 1.1-8+b1 ii libopenal1 1:1.19.1-2 ii libopus01.3.1-1 ii libqrcodegencpp11.8.0-1.1 ii libqt5core5a [qtbase-abi-5-15-4]5.15.4+dfsg-3 ii libqt5gui5 5.15.4+dfsg-3 ii libqt5network5 5.15.4+dfsg-3 ii libqt5svg5 5.15.4-2 ii libqt5waylandclient5 [qtwayland-client-abi-5-15-4] 5.15.4-2 ii libqt5widgets5 5.15.4+dfsg-3 ii librlottie0-1 0.1+dfsg-2 ii libsigc++-2.0-0v5 2.10.8-1 ii libssl3 3.0.3-8 ii libstdc++6 12.1.0-4 ii libswresample3 7:4.4.2-1+b3 ii libswscale5 7:4.4.2-1+b3 ii
Bug#1003353: tagging 1012326, tagging 1012690, tagging 1012464, tagging 1001317, tagging 1012221, tagging 1011807 ...
Control: notfound 1003353 2.114.0 Hi Andreas, Andreas Beckmann wrote: > found 1003353 2.114.0 please explain what makes you think that this issue is present in lintian 2.114.0 as currently in Debian Unstable. The submitter clearly said he ran into it when he bumped his lintian copy to git HEAD. And as far as I can see that problem is only present if Lintian uses Text::Glob for evaluating wildcards in overrides and that got introduced 32 commits _AFTER_ the 2.114.0 release: commit 139009d5a54225ebff4509ec37b979cb898c17fe Author: Felix Lechner Date: Wed Dec 1 21:46:24 2021 -0800 Use Text::Glob to match hint contexts with override patterns. Replaces a trusted homegrown routine. Gbp-Dch: ignore (No idea why this was marked "Gbp-Dch: Ignore" as it has quite some impact, also on dependencies and build-dependencies. *grrr*) And: ~/lintian/lintian → git describe 139009d5a54225ebff4509ec37b979cb898c17fe 2.114.0-32-g139009d5a ^^ Which is the reason why I marked this bug report as NOT being found in 2.114.0 a few days ago. (And now again.) So please refrain from marking this specific bug report as found in 2.114.0 again unless you have a really good reason to do so. Thanks in advance! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1008415: libnih: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2
Hi Marius, Marius Gripsgard wrote: > libnih has been removed as dependency for lomiri-donwload-manager > for a good while upstream [0] Ah, nice! > but has not had a release with this in it yet. So I make a new > released lomiri-download-manager 0.1.1 with libnih removed as dep, > and uploaded this to unstable. Yay! Thanks a lot. > So nih can be removed IMO. Done so now: https://bugs.debian.org/1013225 Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1013225: RM: libnih -- RoQA; RC buggy, orphaned, upstream dead, no more reverse deps
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: Axel Beckert , Marius Gripsgard , Mike Gabriel Hi, libnih is: * orphaned since 2016: https://bugs.debian.org/826286 * RC buggy (FTBFS due to test suite failures) since March and nobody cares (except for getting rid of it): https://bugs.debian.org/1008415 * upstream dead since 2012-ish: https://code.launchpad.net/libnih * reverse-dependency-free as the last reverse dependency has dropped its dependency on libnih, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008415#20 and https://tracker.debian.org/news/1338387/accepted-lomiri-download-manager-011-1-source-into-unstable/ So please finally remove it from Unstable.
Bug#1012759: debian-goodies: dgrep doesn't work with regexp for the package names
Hi again, Axel Beckert wrote: > Thanks for this bug report. These are actually multiple issues: Actually no … > * Documentation issue in the dgrep man page: dgrep uses dglob for > pattern matching That's correct. > and that one uses wildcard pattern matching. That's actually not correct. It solely seems to support substring matching and calls that a "pattern" which is IMHO a bit misleading. So actually the main bug is that the documentation in dgrep's man page is wrong. And the secondish issue is that dglob's man page could be less misleading. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1012759: debian-goodies: dgrep doesn't work with regexp for the package names
Hi Vincent,
Vincent Lefevre wrote:
> The dgrep(1) man page says:
>
> You can use POSIX regular expressions for the package names.
>
> But
>
> dgrep represents 'libc6'
>
> return matches, while
>
> dgrep represents 'libc6.*'
>
> doesn't.
Thanks for this bug report. These are actually multiple issues:
* Documentation issue in the dgrep man page: dgrep uses dglob for
pattern matching and that one uses wildcard pattern matching. I've
fixed this one in git.
* dglob still doesn't work as documented:
~ → dglob libc6
libc6:amd64
libc6:i386
libc6-dbg:amd64
libc6-dev:amd64
libc6-dev-i386:amd64
libc6-dev-x32:amd64
libc6-i386:amd64
libc6-x32:amd64
~ → dglob libc6\*
~ → dglob libc6:\*
grep-dctrl: *scratch*:1: expected a colon.
~ →
I'm now considering the latter the actual bug tracked by this bug
report.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013112: closed by Sebastian Ramacher (Re: Bug#1013112: angelfish: Uninstallabale due to Qt transition, but not listed on https://release.debian.org/transitions/html/qtbase-
Hi Sebastian, Debian Bug Tracking System wrote: > > So I assume that this transition misses relations to > > qtwebengine-abi-5-15-10 and qtwebengine-abi-5-15-5. […] > The tracker now also checks qtwebengine-abi-5-15 and I have scheduled > binNMUs for angelfish. Thanks! Angelfish (at least on amd64) is now installable again. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013112: angelfish: Uninstallabale due to Qt transition, but not listed on https://release.debian.org/transitions/html/qtbase-abi-5-15-4.html
Package: angelfish,release.debian.org Version: angelfish/22.04-1 Severity: serious Hi, seemingly due to the current Qt transition (https://release.debian.org/transitions/html/qtbase-abi-5-15-4.html), angelfish becomes uninstallable (i.e. aptitude wants to remove it) if I try to upgrade all the Qt packages in unstable. Reason seems this dependency: ii libqt5webenginecore5 [qtwebengine-abi-5-15-5] 5.15.8+dfsg-1+b2 The current libqt5webenginecore5 in Unstable only "Provides: qtwebengine-abi-5-15-10". But angelfish is not listed on https://release.debian.org/transitions/html/qtbase-abi-5-15-4.html — not even if I display the "good" ones. So I assume that this transition misses relations to qtwebengine-abi-5-15-10 and qtwebengine-abi-5-15-5. (Filing primarily against angelfish, but also against release.debian.org as it seems to be an oversight in this transition and a BinNMU by the release team might fix this already.) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages angelfish depends on: ii libc6 2.33-7 ii libgcc-s1 12.1.0-2 ii libkf5configcore5 5.94.0-3 ii libkf5configgui5 5.94.0-3 ii libkf5coreaddons5 5.94.0-1 ii libkf5dbusaddons5 5.94.0-1 ii libkf5i18n55.94.0-1 ii libkf5notifications5 5.94.0-1 ii libkf5windowsystem55.94.0-1 ii libqt5core5a 5.15.2+dfsg-16+b2 ii libqt5gui5 5.15.2+dfsg-16+b2 ii libqt5network5 5.15.2+dfsg-16+b2 ii libqt5qml5 5.15.2+dfsg-10 ii libqt5quick5 5.15.2+dfsg-10 ii libqt5sql5 5.15.2+dfsg-16+b2 ii libqt5webengine5 5.15.8+dfsg-1+b2 ii libqt5webenginecore5 [qtwebengine-abi-5-15-5] 5.15.8+dfsg-1+b2 ii libqt5widgets5 5.15.2+dfsg-16+b2 ii libstdc++6 12.1.0-2 ii qml-module-org-kde-kirigami2 5.94.0-1 ii qml-module-qtfeedback 5.0~git20180903.a14bd0b-3 ii qml-module-qtwebengine 5.15.8+dfsg-1+b2 angelfish recommends no packages. angelfish suggests no packages. -- no debconf information
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Control: tag -1 + moreinfo Control: severity -1 important Hi Guillem, I'm trying to catch up with that chaos which is in lintian's current state. Guillem Jover wrote: > So the problematic --fail-on default change never got actually reverted > as the patch applied in commit 3758bfafd5dd742c327f2312dac8e3a71b1f036e > omitted the relevant part that would make it work. :( Can you please elaborate what exactly is the bug? You refer to something being problematic without explaining what actually is problematic. You refer to 3758bfafd5dd742c327f2312dac8e3a71b1f036e and https://bugs.debian.org/962158 which has been closed about 2 years and ca. 35 Lintian releases ago. That thread in #962158 is quite long and difficult to grasp. > None of the previous arguments against the default change brought up > in #962158 have stopped being relevant (also contrary to the commit > message…). Worse, this sneaked in what has shipped now in a stable > Debian release. :( So any errors found in CI systems and through other > tooling has been silently ignored since then. :/ This doesn't really makes the issue easier to understand. I don't ask for a patch, but at least for a list of defects what is wrong where and probably why. So far I got that there is an issue with the exit codes having changed to be somewhat less helpful for automatic usage. (When did it change and how? Do you happen to know a commit id? What condition should in your opinion cause which exit code?) > Only noticed now due to #994414, a great excuse to now keep the broken > behavior I guess. So this bug report actually should no more be fixed?!? > (Where the --help output still does not match…) So --help seems outdated. At which line or option exactly and what should it say instead? Downgrading to import for now as I can't really fix something which is totally unclear, both, the how and the why. P.S.: Sorry if you explained that in the past, but the whole situation in general and with this issue in specific is quite tangled, so that I'd really appreciate a summary to get an idea what this bug report exactly is about. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1007002: lintian: transition to "pointed hints" has invalidated many overrides
Hi Simon, Simon McVittie wrote: > Control: unblock 1006348 by -1 Thanks! > #1007002 was marked as blocking #1006348 "lintian: Tag > improbable-bug-number-in-closes condition considers 7-digit bug numbers > improbable", but I think that was a side-effect of the merge Definitely. All three unmerged bug reports had that block. > and I don't consider #1007002 to be RC or a blocker for #1006348, so > I'm removing that metadata. Actually it was still on my TODO list to find out which of the bug reports was related to #1006348 and why. You reduced that part of my TODO list to 2/3 by no more having to check this bug report. Thanks! :-) > > Since at least I will not revert such huge changes, I'll tag #1007002 > > as "wontfix" for now and downgrade it to its original severity. > > > > We can continue working on that bug report if we find someone who > > either will work on reverting all the related work (although I think, > > it's both, too late and also probably way too much work given all the > > other recent changes) or, probably much better, provide either a > > migration script or some code which also accepts the old override > > formats. In that case, I'd remove the "wontfix" again. (Sorry, Simon, > > I generally agree with #1007002, but we currently have way more severe > > issues with Lintian than #1007002. Hence I also didn't remove the > > confirmed tag.) Oh, JFTR: This refers to Lintian as it was in Git when I took over. There are parts of that tag format transition already committed in Git which aren't yet in Debian Unstable. :-/ There were nearly 200 commits in git since 2.114.0 before I started working again on Lintian. I won't triage and revert them either unless they are outright buggy in a technical sense. Sorry. As mentioned it would need much more man power to "fix" this issue, even with what is so far only in git. And with Felix and Chris left the Lintian development, there's much less man power so far. At least so far I'm the only one who did commits since then, but there were at least three DDs asking for group membership on Salsa (Thanks!), so I hope they will start working on Lintian as well. I'm also updating the development how-tos where I notice that they're outdated. > That makes sense to me. I should have reported #1007002 earlier No offence meant. > (or, ideally, a Lintian co-maintainer should have pointed out the > problems with a major tag format transition before it got that far), That's more a thing. Actually I already thought if we should setup a similar rule for Lintian tag syntaxes as we did for using epoch in package versions, maybe just not as stringent. I'm though not sure where such a rule should be placed. The Debian Policy seems the wrong place. So that rule should be probably documented inside Lintian itself or so. > which would have made pausing or reverting the transition > lower-cost. Ack. > Thank you for picking up this package! It's an important QA tool and > I'm glad someone is looking after it again. Should have noticed the resignation of Felix and Chris (or looked for such a thing after noticing that there were no lintian uploads for a while) earlier, too. Probably would have been less (or at least more distributed) work to get it back in shape as the remainder of Debian Unstable didn't stand still while Lintian did. Especially I found one case where the amount of lines replacing the #DEBHELPER# token caused test suite failures after a debhelper update seem to have added some lines. Took a few hours to understand what went wrong and why. (Granted, because many things I knew about Lintian's test suite had changed since I last used it, I first had to relearn how to use the current setup and this took probably some of that time as well.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1003272: lintian: chokes on overrides with "(" but no ")"
unmerge 1003272 unmerge 1003353 unmerge 1007002 tag 1003272 + pending notfound 1003272 2.114.123 retitle 1003353 lintian: Override processing defective for square brackets and curly brackets notfound 1003353 2.114.0 severity 1007002 important notfound 1007002 2.114.123 tag 1007002 + wontfix kthxbye Hi again, I disagree that #1003272, #1003353 and #1007002 are the same bug. The former two are similar, but not identical and the latter was only the reason why the second one is showing up more often. Hence unmerging all three. Axel Beckert wrote in #1003272: > Tobias Frost wrote: > > Package: lintian > > Version: 2.114.0 > > Felix Lechner wrote: > > On Fri, Jan 7, 2022 at 2:57 AM Tobias Frost wrote: > > > > > > Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE > > > > That is a consequence of switching to Text::Glob for overrides. > > No. That feature only came _after_ 2.114.0 against which Tobias > reported the bug: > > https://salsa.debian.org/lintian/lintian/-/commit/139009d5a54225ebff4509ec37b979cb898c17fe And it actually fixed Tobias' issue. I can reproduce Tobias' issue with 2.114.0, but no more the current git HEAD (which is approximately 2.114.211, git commit 1c7bb81662e5e23a64fc272a008ddfc75c855537 or so). > Ack. For the current version in git, I suggest using "?" or "*" to > match problematic characters. E.g. for myself > > links2 source: very-long-line-length-in-source-file * > 512 *graphics/font/* > > worked while > > links2 source: very-long-line-length-in-source-file * > 512 [graphics/font/* This is actually #1003353 which claims that processing of parentheses is broken, too, but actually only seems to be about brackets. This issue is still present in the current git HEAD. Will handle that one separately later. And #1007002 is only (!) about design decision to change nearly all tag formats involving file paths and line numbers. It has nothing to do with the other two real bugs and I have no idea why they have been merged. While I was (and still am) annoyed by these changes, I do value the goal behind it. I currently suspect that we're mostly through this migration and I do hope that no such mass-changes will ever be needed again. Especially since — as I wrote — the following will likely never happen without Felix working on Lintian: > > We will likely allow globbing on the file pointer, regular expressions > > on the annotation and require literal matches for the tag name. To > > keep those fields separate, we may switch to a Deb822 format for > > override files, but hope to provide automated tools for migration and > > management similar to those we already use internally to interactively > > recalibrate Lintian's test suite. > > Given that Felix quit working on Lintian, this will likely not happen > unless someone steps up and continues the ideas and his work. > > I will only try to fix things for now. (And I'm not sure how I'll > handle this, maybe mitigate it by more fitting documentation and > maybe some sanity checks.) Since at least I will not revert such huge changes, I'll tag #1007002 as "wontfix" for now and downgrade it to its original severity. We can continue working on that bug report if we find someone who either will work on reverting all the related work (although I think, it's both, too late and also probably way too much work given all the other recent changes) or, probably much better, provide either a migration script or some code which also accepts the old override formats. In that case, I'd remove the "wontfix" again. (Sorry, Simon, I generally agree with #1007002, but we currently have way more severe issues with Lintian than #1007002. Hence I also didn't remove the confirmed tag.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
