Bug#1069934: 4.9.2. The dak ls utility should mention rmadison
Package: developers-reference Version: 13.6 Severity: normal Hello Holger, 4.9.2. The dak ls utility could mention rmadison from devscripts that does not require to log to ftp-master.debian.org. There is also a be interface: % curl 'https://api.ftp-master.debian.org/madison?package=evince' evince | 3.30.2-3+deb10u1 | oldoldstable | source, amd64, arm64, armhf, i386 evince | 3.30.2-3+deb10u1 | oldoldstable-debug | source evince | 3.38.2-1 | oldstable | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x evince | 43.1-2 | stable | source evince | 43.1-2+b1| stable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x evince | 45.0-1 | testing| source evince | 45.0-1+b1| testing| amd64, arm64, armel, armhf, i386, mips64el, ppc64el, s390x evince | 46.0-1 | unstable | source evince | 46.0-1 | unstable-debug | source evince | 46.0-1+b1| unstable | amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x Cheers, -- Bill. Imagine a large red swirl here.
Bug#877337: single-page html of debian-policy to be revived?
On Sat, Apr 27, 2024 at 10:15:19AM +0100, Sean Whitton wrote: > Hello, > > On Mon 15 Apr 2024 at 09:59am GMT, Holger Levsen wrote: > > > On Sun, Apr 14, 2024 at 08:43:51PM +0800, Sean Whitton wrote: > >> ... but if dev-ref is already shipping both, maybe singlepage is indeed > >> usable these days ... > > > > I think it is. > > > >> > Could the Policy Editors team check, if everything is fine now, and if > >> > this should be published again? > >> > At least there is still an issue with the footnotes, there are 16 > >> > occurrences > >> > of #id1 for example... (search for "[1]" in policy-1.html). > >> Hrm. That seems like a pretty serious problem :\ > > > > I wouldnt call it serious. annoying yes, maybe. > > > >> Holger L., did you know about this issue? > >> Did you decide it was worth publishing anyway? > > > > yes. > > > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages > > or (single page) > > https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages > > both show four footnotes, right where they belong, it's just that > > each foot note is numbered and that [1] or [2] or whatever is > > a link, pointing to a wrong place. > > > > I agree it's a bug, but I do think it's a pretty harmless one. > > Thanks. I'd be grateful for some feedback from other regular Policy > contributors. My view is that any issue with single-page is much more likely to be fixed if we use it than if we do not. I note that the links from the text to the footnotes are correct, it is only the backlink from the footnotes to the text which are wrong. I consider this minor. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
On Tue, Jan 30, 2024 at 09:52:39AM +, MOESSBAUER, Felix wrote: > On Fri, 04 Aug 2023 10:44:38 + sohe4b+2fz7rb0ixc53g@cs.email wrote: > > Package: base-files > > Version: 12.4+deb12u1 > > Followup-For: Bug #1039979 > > Control: tags -1 patch > > > > I attach a patch to change absolute symlinks to relative symlinks, > which would fix this bugreport if you choose to do so. > > At least the /var/run directory is also created as a symlink to ../run > by tmpfiles.d: > > /usr/lib/tmpfiles.d/var.conf from the systemd package contains: > L /var/run - - - - ../run Why not fix /usr/lib/tmpfiles.d/var.conf to create the correct link then ? /usr/lib/tmpfiles.d/var.conf is not policy-compliant as it is. Cheers, -- Bill. Imagine a large red swirl here.
Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors
On Wed, Apr 10, 2024 at 09:33:50PM +0200, Holger Wansing wrote: > Hello www team and debian-policy editor team, > > Note: apparently we have no alternative beside js, if we want full-text > search for html output (single-page html could be a possible way, but > that output format has been disabled due to various other issues). Sorry, but why is this so hard to generate a single-page html ? debiandoc could do it. Using the browser intra-page search is always much easier/faster that using a search box. Cheers, Bill.
Bug#1068498: new upstream version 4.0.2
Source: xeus Severity: wishlist Dear Xeus maintainers, There is a new major upstream release available (4.0.2). Do you plan to package it ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
On Thu, Apr 04, 2024 at 01:22:19PM -0700, Russ Allbery wrote: > I'm not sure what I think about that. We have a general escape hatch > already for non-free packages in Policy 2.2.3 that says they may not fully > comply with Policy, which may be sufficient. But precisely, we _do_ want non-free packages that are built on the autobuilders to comply with this requirement. So we do not want 2.2.3 to apply in that specific case. It seems cleaner to say that the requirement only apply if Autobuild: yes is declared. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
On Thu, Apr 04, 2024 at 09:25:36PM +0200, Philipp Kern wrote: > Hi, > > On 04.04.24 20:51, Bill Allombert wrote: > > I still think we should allow Autobuild: no as an escape hatch. > > If we want to require non-free package to be autobuildable, we should > > be more explicit about it (and probably require more feedback from > > debian-devel). > > There is no requirement for non-free to be autobuildable today. This change > also does not introduce this, except for everything that is to be built on > official builders to not require network access. Sorry, could you point me where the diff is limiting its scope to "everything that is to be built on official builders" ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
On Thu, Apr 04, 2024 at 11:42:34AM -0700, Russ Allbery wrote: > Tobias Frost writes: > > On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote: > > >> Thanks Philipp. Following that result, please find a patch proposal: > >> > >> --- a/policy/ch-source.rst > >> +++ b/policy/ch-source.rst > >> @@ -338,9 +338,9 @@ > >> For example, the build target should pass ``--disable-silent-rules`` > >> to any configure scripts. See also :ref:`s-binaries`. > >> > >> -For packages in the main archive, required targets must not attempt > >> -network access, except, via the loopback interface, to services on the > >> -build host that have been started by the build. > >> +Required targets must not attempt network access, except, via the > >> +loopback interface, to services on the build host that have been started > >> +by the build. > >> > >> Required targets must not attempt to write outside of the unpacked > >> source package tree. There are two exceptions. Firstly, the binary > > > LGTM, Seconded. > > Also looks good to me. Seconded. I still think we should allow Autobuild: no as an escape hatch. If we want to require non-free package to be autobuildable, we should be more explicit about it (and probably require more feedback from debian-devel). Cheers, -- Bill. Imagine a large red swirl here.
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
On Tue, Apr 02, 2024 at 09:21:02AM +0800, Sean Whitton wrote: > Hello, > > On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote: > > > Package: debian-policy > > Version: 4.6.2.1 > > Severity: normal > > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org > > Control: affects -1 buildd.debian.org > > > > Hi, > > > > The debian policy, section 4.9, forbids network access for packages in > > the main archive, which implicitly means they are authorized for > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > fixed). > > > > This gives constraints on the build daemons infrastructure and also > > brings some security concerns. Would it be possible to extend this > > restriction to all archives? > > We need to know if this is going to break existing packages and allow > some input from their maintainers. Are you able to prepare a list of > the affected packages? What I suggested was that "Autobuild: yes" imply no network access. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1068192: debian-policy: extend forbidden network access to contrib and non-free
On Mon, Apr 01, 2024 at 06:08:10PM +0200, Aurelien Jarno wrote: > On 2024-04-01 17:52, Bill Allombert wrote: > > On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote: > > > Package: debian-policy > > > Version: 4.6.2.1 > > > Severity: normal > > > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org > > > Control: affects -1 buildd.debian.org > > > > > > Hi, > > > > > > The debian policy, section 4.9, forbids network access for packages in > > > the main archive, which implicitly means they are authorized for > > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > > fixed). > > > > > > This gives constraints on the build daemons infrastructure and also > > > brings some security concerns. Would it be possible to extend this > > > restriction to all archives? > > > > Does the build daemons actually build non-free ? > > Yes, they do, though only part of non-free, only the packages that have > Autobuild: yes and that have been put on an allow list after review. Is your concern is that the package start to do network acces during build after it has been added to the allow list ? Do you need "Autobuild: yes" to preclude network access ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote: > Package: debian-policy > Version: 4.6.2.1 > Severity: normal > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org > Control: affects -1 buildd.debian.org > > Hi, > > The debian policy, section 4.9, forbids network access for packages in > the main archive, which implicitly means they are authorized for > packages in contrib and non-free (and non-free-firmware once #1029211 is > fixed). > > This gives constraints on the build daemons infrastructure and also > brings some security concerns. Would it be possible to extend this > restriction to all archives? Does the build daemons actually build non-free ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1064800: menu: installs same filename to both bin and sbin
On Sun, Feb 25, 2024 at 11:21:26PM +, ca...@allfreemail.net wrote: > Source: menu > Version: 2.1.50 > Severity: normal > > Dear Maintainer, > > your package installs the filenames `install-menu` and `su-to-root` to both > bin and sbin as opposed to just one of those locations. > > This causes a problem on a filesystem layout where bin and sbin are merged > into a single real directory, typically by sbin being a symlink to bin. Such > a filesystem layout has become standard on some distributions now, and others > are moving onto in their next releases. > > Please pick one location and install it only there. /usr/bin is preferred > over any other location. I would suggest you find out why the binaries are in both directories in the first place. Then we can discuss a solution! Cheers, -- Bill. Imagine a large red swirl here.
Bug#1012289: RFH: lintian -- Debian package checker
On Mon, Feb 05, 2024 at 01:20:07PM +, Bastien Roucariès wrote: > Le lundi 5 février 2024, 12:42:04 UTC Bill Allombert a écrit : > > On Mon, Feb 05, 2024 at 12:28:02PM +0100, Axel Beckert wrote: > > > Hi Bill, > > > > > > Bill Allombert wrote: > > > > By the way, what happened to lintian.debian.org ? > > > > > > Seems as if someone (not me, just noticed it today when > > > "private/refresh-data" failed…) pulled the plug on at least the DNS > > > name. Probably because it hasn't been updated since Felix' try to > > > rewrite it, which AFAIK was never finished, but the old thing also no > > > more worked. (There's probably a lot of legacy code in > > > "lib/Lintian/Output" related to one of these two website generations, > > > maybe even both.) > > > > I used to generate my own copy of it because the official one was > > out of date. > > Help here is welcome. I really like the l.d.o site particularly the graph But does the host lintian.debian.org still exist ? Is it possible to get access to it ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1063210: pari: NMU diff for 64-bit time_t transition
On Mon, Feb 05, 2024 at 02:43:30PM -0300, Lucas Kanashiro wrote: > Source: pari > Version: 2.15.4-2 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > pari as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for pari > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. My concern is, as you can see, that the new library package is empty: libpari-gmp-tls8t64_2.15.4-2.1~exp1_amd64.deb - drwxr-xr-x root/root 0 2024-02-05 17:43 ./ drwxr-xr-x root/root 0 2024-02-05 17:43 ./usr/ drwxr-xr-x root/root 0 2024-02-05 17:43 ./usr/share/ drwxr-xr-x root/root 0 2024-02-05 17:43 ./usr/share/doc/ drwxr-xr-x root/root 0 2024-02-05 17:43 ./usr/share/doc/libpari-gmp-tls8t64/ -rw-r--r-- root/root 1463 2024-02-05 17:43 ./usr/share/doc/libpari-gmp-tls8t64/changelog.Debian.gz -rw-r--r-- root/root 9997 2023-06-27 18:38 ./usr/share/doc/libpari-gmp-tls8t64/changelog.gz -rw-r--r-- root/root 766 2022-09-05 21:10 ./usr/share/doc/libpari-gmp-tls8t64/copyright Compare to the one in unstable: libpari-gmp-tls8_2.15.4-2_amd64.deb --- drwxr-xr-x root/root 0 2023-07-12 10:08 ./ drwxr-xr-x root/root 0 2023-07-12 10:08 ./usr/ drwxr-xr-x root/root 0 2023-07-12 10:08 ./usr/lib/ drwxr-xr-x root/root 0 2023-07-12 10:08 ./usr/lib/x86_64-linux-gnu/ -rw-r--r-- root/root 13002328 2023-07-12 10:08 ./usr/lib/x86_64-linux-gnu/libpari-gmp-tls.so.2.15.4 lrwxrwxrwx root/root 0 2023-07-12 10:08 ./usr/lib/x86_64-linux-gnu/libpari-gmp-tls.so.8 -> libpari-gmp-tls.so.2.15.4 drwxr-xr-x root/root 0 2023-07-12 10:08 ./usr/share/ drwxr-xr-x root/root 0 2023-07-12 10:08 ./usr/share/doc/ drwxr-xr-x root/root 0 2023-07-12 10:08 ./usr/share/doc/libpari-gmp-tls8/ -rw-r--r-- root/root 1368 2023-07-12 10:08 ./usr/share/doc/libpari-gmp-tls8/changelog.Debian.gz -rw-r--r-- root/root 9997 2023-06-27 18:38 ./usr/share/doc/libpari-gmp-tls8/changelog.gz -rw-r--r-- root/root 766 2022-09-05 21:10 ./usr/share/doc/libpari-gmp-tls8/copyright It is missing all the important files. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1063605: debian-policy: mandate use of `dpkg-buildflags` for all software compilation on Debian
On Fri, Feb 09, 2024 at 09:16:00PM +0100, Ansgar wrote:
> Package: debian-policy
> Version: 4.6.2.0
> Severity: important
>
> Hi,
>
> with the upcoming time_t & friends 64-bit transition, dpkg-buildflags
> will be used to configure the ABI in use.
This decision comes from the wrong premise that the use of dpkg-buildflags
is universal, which is not the case. Hence it needs to be reconsidered.
There is not magic that will make all packages use dpkg-buildflags consistently
in the timeframe of this migration.
> Thus all compiler
> invocations *must* use the flags specified by dpkg-buildflags to avoid
> ABI inconsistencies like this one:
>
> struct T { time_t a; time_t b; };
>
> If this struct is accessed from both `libfoo1t64` (built respecting
> dpkg-buildflags and thus time_t is 64-bit) and `bar` (built by a user
> invoking gcc themselves), the result is probably not what one wants.
>
> Thus `dpkg-buildflags` *must* be used by all packages *and* all users,
> including users building their own software. There is one exception
> when libraries provide both 32-bit and 64-bit time_t ABIs like glibc
> itself (but I doubt there are many of those).
No, it is required that packages use correctly the right compiler flags.
Since packages need to be reuploaded anyway this is not a real issue.
dpkg-buildflags is not required for that, and does not necessarily achieve it
either, since upstream build system might not honor the environment variables
CFLAGS etc. consistently.
> Any compiler invocation missing these *should* be a serious bug.
> (This should probably be mentioned in user documentation as well.)
This a different issue than mandating dpkg-buildflags.
dpkg-buildflags leads to build flags which are significantly different from
upstream, that have not been tested by users building from source, and they
can change without notice. It is very reasonable not to trust them.
In general we discourage diverging from upstream for similar reasons.
I offered #724621 as an option which would let packages maintainers control
which buildflags are used while still providing the benefit of buildflags.
Cheers,
--
Bill.
Imagine a large red swirl here.
Bug#1019980: lintian: source-is-missing check for HTML is much too sensitive
On Thu, Feb 08, 2024 at 08:27:40PM +, Bastien Roucariès wrote: > > > > > > source package, though I can't see how Lintian could possibly > > > > > > expect to > > > > > > know that. > > > > > > Are you sure it is not embdeded base64 encoded png or minified > > > javascript* ? > > > > > > If not we could try to know why it choke ? > > > > > > In this particular case, it is the source package that choke. If halibut > > > include the name of the source > > > in the html we could magically remove the source is missing warnings. > > > > > > Another alternative if we could determine the file was compiled by > > > halibut, we could demote to pedantic warning > > > and ask to repack in order to be sure to recompile from source. > > > > There are far too many different HTML generators out there to handle. > > We have done this for doxyen and sphinx, so maybe not for more This is two out of how many ? For example, my packages use TtH, GAPDoc, hevea, pod2html. I do not think it is sustainable. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1019980: lintian: source-is-missing check for HTML is much too sensitive
On Thu, Feb 08, 2024 at 06:39:18PM +, Bastien Roucariès wrote: > Le jeudi 8 février 2024, 18:31:28 UTC Santiago Ruano Rincón a écrit : > > On Sat, 14 Oct 2023 20:23:18 +0200 Bill Allombert > > wrote: > > > On Sun, Sep 18, 2022 at 12:14:07AM +0100, Colin Watson wrote: > > > > Package: lintian > > > > Version: 2.115.3 > > > > Severity: normal > > > > > > > > Lintian issues these errors for putty 0.77-1: > > > > > > > > E: putty source: source-is-missing [doc/html/AppendixA.html] > > > > E: putty source: source-is-missing [doc/html/AppendixB.html] > > > > E: putty source: source-is-missing [doc/html/AppendixE.html] > > > > E: putty source: source-is-missing [doc/html/Chapter10.html] > > > > E: putty source: source-is-missing [doc/html/Chapter2.html] > > > > E: putty source: source-is-missing [doc/html/Chapter3.html] > > > > E: putty source: source-is-missing [doc/html/Chapter4.html] > > > > E: putty source: source-is-missing [doc/html/Chapter5.html] > > > > E: putty source: source-is-missing [doc/html/Chapter7.html] > > > > E: putty source: source-is-missing [doc/html/Chapter8.html] > > > > E: putty source: source-is-missing [doc/html/Chapter9.html] > > > > E: putty source: source-is-missing [doc/html/IndexPage.html] > > > > > > > > This is pretty oversensitive. Firstly, it's HTML, which is still often > > > > enough written by hand anyway. As it happens, these particular HTML > > > > files are generated from halibut input that's also provided in the > > > > source package, though I can't see how Lintian could possibly expect to > > > > know that. > > Are you sure it is not embdeded base64 encoded png or minified javascript* ? > > If not we could try to know why it choke ? > > In this particular case, it is the source package that choke. If halibut > include the name of the source > in the html we could magically remove the source is missing warnings. > > Another alternative if we could determine the file was compiled by halibut, > we could demote to pedantic warning > and ask to repack in order to be sure to recompile from source. There are far too many different HTML generators out there to handle. You would need to define a standard way to indicate the path to the source in the generated file. But some generator authors might consider this is an inacceptable data leak, so this would only be done if some environment variable is defined. In the short term, I suggest to disable it since there is no policy requirement for the source code to be in a particular path, so it is not an error. At the very least, it should not be generated more than once per package. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1063210: pari: NMU diff for 64-bit time_t transition
On Mon, Feb 05, 2024 at 02:43:30PM -0300, Lucas Kanashiro wrote: > Source: pari > Version: 2.15.4-2 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > pari as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for pari > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. Have you actually checked that pari will really be build with the relevant flags ? If there is a new ABI, then one should take the opportunity to remove CFLAGS_i386 := -mpc64 There is no need for a lintian override, this is a well-known lintian bug... Cheers, Bill
Bug#1061972: gap: NMU diff for 64-bit time_t transition
On Thu, Feb 01, 2024 at 04:07:38PM +0100, Lukas Märdian wrote: > thanks for the heads-up! > The same debdiff should apply to the version in unstable (4.12.1). > We'll make sure to NMU the version from unstable. > > Waiting for libgap.so.9 would also be an option, if timing works out. Fortunately libgap.so.9 was prereleased today. Would that mess anything if I upload it to experimental ? I expect not. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1062983: Developers Reference in A4 instead of US Letter
On Mon, Feb 05, 2024 at 10:23:39AM +, Holger Levsen wrote: > On Mon, Feb 05, 2024 at 11:00:42AM +0800, Paul Wise wrote: > > > I think for English at least I'd prefer to offer both A4 and letter, for > > > eg > > > the German translation I think it's enough to only provide A4. > > Looks like that info can be gotten from the locales on glibc systems: > [...] > > nice, thanks. > > > For languages with one translation instead of one per dialect, > > you could produce documents in each of the unique sizes. > > I don't understand, what do you mean with "one per dialect" here? I assume dialect means pt_PT vs pt_BR. Each locale can have a different page size even if the translation is the same. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1012289: RFH: lintian -- Debian package checker
On Mon, Feb 05, 2024 at 12:28:02PM +0100, Axel Beckert wrote: > Hi Bill, > > Bill Allombert wrote: > > By the way, what happened to lintian.debian.org ? > > Seems as if someone (not me, just noticed it today when > "private/refresh-data" failed…) pulled the plug on at least the DNS > name. Probably because it hasn't been updated since Felix' try to > rewrite it, which AFAIK was never finished, but the old thing also no > more worked. (There's probably a lot of legacy code in > "lib/Lintian/Output" related to one of these two website generations, > maybe even both.) I used to generate my own copy of it because the official one was out of date. > IMHO it's generally a good thing, except that it would have been > better to redirect it to the according UDD pages instead. Yes, because there are ton of places still linking to lintian.debian.org (e.g. wikipedia). We should ask DSA to redirect to salsa or UDD. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1012289: RFH: lintian -- Debian package checker
On Mon, Feb 05, 2024 at 03:26:29AM +0100, Axel Beckert wrote: > Hi, > > Bastien Roucariès wrote: > > Le dimanche 4 février 2024, 14:02:58 UTC Bill Allombert a écrit : > > > Areyou still available as lintian maintainer ? It sure would need an > > > upload. > > I can > > > > I am doing some pull request update > > By coincidence I started to work on Lintian today (well, actually > yesterday) again, too, but saw these two mails only afterwards. Mostly > fixed the systemd/udev/usrmerge related test suite failures as well as > merged some of the open merge requests. > > Let's try together to get a release done soon. By the way, what happened to lintian.debian.org ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1012289: RFH: lintian -- Debian package checker
On Tue, Aug 16, 2022 at 11:56:20AM +, Bastien Roucariès wrote: > Source: lintian > Version: 2.115.2 > Followup-For: Bug #1012289 > > Dear Maintainer, > > I will restep to be a lintian maint.Could you please prepare a list of urgent > action ? Are you still available as lintian maintainer ? It sure would need an upload. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1012289: Bug #1012289: Following up on Lintian
On Mon, Jan 08, 2024 at 02:57:18PM +0100, Jakub Ružička wrote: > Hello, > > > On Wed, 27 Dec 2023 18:54:14 + Simon Quigley wrote: > > In most recent Ubuntu cycles, I've taken on the "archive bootstrapping" > > responsibility of adding the new Ubuntu codename to Lintian. I remember > > having some deeper conversations with the former Lintian maintainer > > regarding further contributions and maintenance, but I also recall some > > politics, and quite frankly, *I don't care*. Regardless, Lintian is > > something I look at every cycle. > > Same. > > > > I'm writing today to express my concern about the current state of > > Lintian maintenance. I already understand that there is an RFH filed > > against Lintian, but that has not received any sort of followup since > > 2022. The most recent Lintian upload is from March 2023, and as of the > > time of writing, there are 26 open merge requests[1]. > > Currently, there are quite a few merged patches ready in VCS as well, > including the one I'm interested in (added support for loong64). > > Just being able to actually release new version of lintian would be nice. Hello, I volunteer to help with Lintian. I have worked on lintian a long time ago, I should be able to make new releases at least. Cheers, -- Bill. Imagine a large red swirl here. signature.asc Description: PGP signature
Bug#1061972: gap: NMU diff for 64-bit time_t transitiono
On Thu, Feb 01, 2024 at 04:30:40PM +0100, Lukas Märdian wrote: > Am 01.02.24 um 16:13 schrieb Bill Allombert: > > On Thu, Feb 01, 2024 at 04:07:38PM +0100, Lukas Märdian wrote: > > > Hi Bill, > > > > > > thanks for the heads-up! > > > The same debdiff should apply to the version in unstable (4.12.1). > > > We'll make sure to NMU the version from unstable. > > > > How do you plan to make sure libgap8t64 actually use 64-bit time_t ? > > This issue will also need to be solved with libgap9. > > It will pick up the new 64-bit time_t ABI automatically, by recompilation > with corresponding buildflags. > Those are currently staged in src:dpkg in experimental and will eventually > move to unstable. I do not think this actualy works. Can you check the packages in experimental ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1061972: gap: NMU diff for 64-bit time_t transition
On Thu, Feb 01, 2024 at 04:07:38PM +0100, Lukas Märdian wrote: > Hi Bill, > > thanks for the heads-up! > The same debdiff should apply to the version in unstable (4.12.1). > We'll make sure to NMU the version from unstable. How do you plan to make sure libgap8t64 actually use 64-bit time_t ? This issue will also need to be solved with libgap9. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1061972: gap: NMU diff for 64-bit time_t transition
On Tue, Jan 30, 2024 at 03:18:23PM +, Lukas Märdian wrote: > Source: gap > Version: 4.12.1-2 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for gap > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. Hello Lukas, you uploaded 4.12.2-1.1 to experimental. The upstream version (4.12.2) in experimental should never be uploaded to unstable, because it breaks the build interface. There will be a new upstream version (4.13.0) with a new soname (libgap.so.9) that will replace it and that I will eventually upload to unstable. Secondly, your patch do not actually make libgap8t64 to actually use 64-bit time_t, and it seem very dangerous to have a library named libgap8t64 that do not actually use 64-bit time_t. There is a single package that depend on libgap8 (python3-sage) and it is seriously out of date, so we should probably wait for the new upstream version instead of introducing libgap8t64. So if one really need to introduce libgap8t64, we need a patch for the version of GAP in unstable that actually use 64-bit time_t. Cheers, -- Bill. Imagine a large red swirl here.
Bug#238687: popularity-contest: popularity contest should provide subarch info.
On Sat, Jan 13, 2024 at 12:51:47PM -0800, Matt Taggart wrote: > It's been quite a while since this bug was discussed, but I have another use > case where it might be interesting... > > There has been some recent discussion about "Architecture Variants" and in > particular amd64 variants. Fedora and Ubuntu are both working on experiments > with the goal of being able to optimize for newer versions of the amd64 > architecture (and potentially dropping older variants at some point as > well). Here is a page that gathers info on this idea for Debian > > https://wiki.debian.org/ArchitectureVariants > > Knowing information about which variants our installed base is using would > help make these decisions easier. The past i386 decisions were a little > easier because there were particular packages we could look at to get those > numbers. Hello Matt, thanks for reviving this bug. Note that unfortunately, none of the requirement I set up in the my previous answer to this bug have been addressed. In particular, there is no official definition of subarchitecture and tool that report it that popcon could use. However, I doubt the practicality of reporting subarchitectures: 1/ users might not be running the latest Debian release, and there is no way to know if they plan to upgrade. 2/ the number of users running some subarchitectures is likely to be very small, which breaks anonymity. Cheers, Bill
Bug#1060164: libxeus9 incompatible with nlohmann::json_abi_v3_11_3
Package: xeus-dev Version: 3.1.3-1 Severity: serious Dear Debian Science maintainers, I have trouble with linking with libxeus9 since I upgraded nlohmann-json3-dev to 3.11.3-1. It seems to me nlohmann-json3-dev 3.11.3-1. is changing the API of libxeus9 in an incompatible way. /lib/x86_64-linux-gnu/libxeus.so.9 defines xeus::make_null_debugger(xeus::xcontext&, xeus::xconfiguration const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, nlohmann::json_abi_v3_11_2::basic_json, std::allocator >, bool, long, unsigned long, double, std::allocator, nlohmann::json_abi_v3_11_2::adl_serializer, std::vector > > const&) while programs compiled with xeus-dev and nlohmann-json3-dev require xeus::make_null_debugger(xeus::xcontext&, xeus::xconfiguration const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, nlohmann::json_abi_v3_11_3::basic_json, std::allocator >, bool, long, unsigned long, double, std::allocator, nlohmann::json_abi_v3_11_3::adl_serializer, std::vector >, void> const&)' That is 'nlohmann::json_abi_v3_11_3' instead of 'nlohmann::json_abi_v3_11_2' This causes xeus-based kernels to fail to link. main.cpp:(.text+0x58b): undefined reference to `xeus::make_null_debugger(xeus::xcontext&, xeus::xconfiguration const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, nlohmann::json_abi_v3_11_3::basic_json, std::allocator >, bool, long, unsigned long, double, std::allocator, nlohmann::json_abi_v3_11_3::adl_serializer, std::vector >, void> const&)' Downgrading nlohmann-json3-dev to 3.11.2-2 fixes this issue. binNMUing libxeus9 might fix this issue, but will probably silently change the ABI of libxeus9 without updating the shlibs. This is worrysome. I hope I am wrong about that. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1060163: packages.debian.org should offer https links to binaries
Package: www.debian.org Severity: normal Dear packages.d.o team, Binary download pages like this one: https://packages.debian.org/bookworm/all/nlohmann-json3-dev/download only offer http links to packages and not https links. firefox flags downloading binaries through http links as dangerous Hopefully most mirrors should support https download now. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness
On Wed, Dec 13, 2023 at 10:27:20PM +0100, Daniel Gröber wrote: > On Wed, Dec 13, 2023 at 07:24:49PM +, Holger Levsen wrote: > > On Wed, Dec 13, 2023 at 07:04:01PM +0100, Daniel Gröber wrote: > > > That's fine, but in that case this fact should be documented instead no? > > > Right now there's confusion across the docs what criticality levels are > > > available. Britney.conf and d-policy mention critical/emergency but > > > nothing > > > else even acknowledges they exist which is just confusing. > > > > I believe Debian policy should be changed then and not mention a severity > > which is not used in practice. > > Easier said than done. I see debian-policy@d.o is already CCed on this bug > so, opinions? > > Doesn't policy document the reality that these urgency values are in fact > usable? Do you not agree that britney does in fact support these? If I go > ahead and upload a package with urgency=critical will this be REJECTed by > ftp-master? Theses urgency values are historical. Their current behaviour is not defined. A long time ago in a distro not far away, packages for non-i386 were built manually by porters that used the urgency to decide which packages to build first. I do not think this is still the case, except that the security queue is build first by the autobuilders. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1057238: debian-policy: Take dpkg-build-api into account for Rules-Requires-Root
On Sat, Dec 02, 2023 at 01:22:04AM +0100, Guillem Jover wrote: > Package: debian-policy > Version: 4.6.2.0 > Severity: wishlist > > Hi! > > Starting with dpkg 1.22.0, it implements a dpkg-build-api mechanism > similar in concept to the debhelper-compat levels. > > You can check its documentation in the dpkg-build-api(7) and > dpkg-buildapi(1) manual pages. > > I think at least the part that involves the Rules-Requires-Root field > which in level 1 defaults to value «no» instead of «binary-targets» > should be documented in the Debian policy. Note that I proposed that in bug #229357 in 2004, this was even fully implemented, commited to the VCS and finally reverted without explanation. I am still not sure why I suffered so much hostility over such a simple design. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1055903: typo in description: assmebly instead of assembly
Source: fp-units-win Version: 3.2.2+dfsg-20 Severity: normal Dear Pascal Packaging Team, The description of fp-units-win-wasm says Free Pascal - Web assmebly support units dependency package % apt-cache search assmebly fp-units-win-wasm - Free Pascal - Web assmebly support units dependency package fp-units-win-wasm-3.2.2 - Free Pascal - Web assmebly support units fp-units-wasm - Free Pascal - Web assmebly support units dependency package fp-units-wasm-3.2.2 - Free Pascal - Web assmebly support units Cheers, -- Bill. Imagine a large red swirl here.
Bug#1019980: lintian: source-is-missing check for HTML is much too sensitive
On Sun, Sep 18, 2022 at 12:14:07AM +0100, Colin Watson wrote: > Package: lintian > Version: 2.115.3 > Severity: normal > > Lintian issues these errors for putty 0.77-1: > > E: putty source: source-is-missing [doc/html/AppendixA.html] > E: putty source: source-is-missing [doc/html/AppendixB.html] > E: putty source: source-is-missing [doc/html/AppendixE.html] > E: putty source: source-is-missing [doc/html/Chapter10.html] > E: putty source: source-is-missing [doc/html/Chapter2.html] > E: putty source: source-is-missing [doc/html/Chapter3.html] > E: putty source: source-is-missing [doc/html/Chapter4.html] > E: putty source: source-is-missing [doc/html/Chapter5.html] > E: putty source: source-is-missing [doc/html/Chapter7.html] > E: putty source: source-is-missing [doc/html/Chapter8.html] > E: putty source: source-is-missing [doc/html/Chapter9.html] > E: putty source: source-is-missing [doc/html/IndexPage.html] > > This is pretty oversensitive. Firstly, it's HTML, which is still often > enough written by hand anyway. As it happens, these particular HTML > files are generated from halibut input that's also provided in the > source package, though I can't see how Lintian could possibly expect to > know that. Dear Lintian maintainers, This test is causing hundreds of false positive and should be disabled as soon as possible. This is a huge waste of time for everybody. If you need help with that, please tell me, I have worked on lintian in the past. Cheers, -- Bill. Imagine a large red swirl here. signature.asc Description: PGP signature
Bug#1052450: Failure: /etc/cron.daily/popularity-contest
On Fri, Sep 22, 2023 at 11:14:52AM +0300, Martin-Éric Racine wrote: > Package: popularity-contest > Version: 1.77 > Severity: normal > > × cron-daily-popularity-contest.service - [Cron] > /etc/cron.daily/popularity-contest > Loaded: loaded (/etc/cron.daily/popularity-contest; generated) > Active: failed (Result: exit-code) since Fri 2023-09-22 10:43:21 EEST; > 228ms ago > TriggeredBy: ● cron-daily-popularity-contest.timer >Docs: man:systemd-crontab-generator(8) > Process: 631 ExecStart=/etc/cron.daily/popularity-contest (code=exited, > status=2) >Main PID: 631 (code=exited, status=2) > CPU: 2.512s > 2023-09-22T10:41:55+0300 u1400 systemd[1]: Starting > cron-daily-popularity-contest.service - [Cron] > /etc/cron.daily/popularity-contest... > 2023-09-22T10:43:21+0300 u1400 popularity-contest[1690]: gpg: can't open > '/var/log/popularity-contest.631': Tiedostoa tai hakemistoa ei ole > 2023-09-22T10:43:21+0300 u1400 popularity-contest[1690]: gpg: > /var/log/popularity-contest.631: encryption failed: Tiedostoa tai hakemistoa > ei ole > 2023-09-22T10:43:21+0300 u1400 systemd[1]: > cron-daily-popularity-contest.service: Main process exited, code=exited, > status=2/INVALIDARGUMENT > 2023-09-22T10:43:21+0300 u1400 systemd[1]: > cron-daily-popularity-contest.service: Failed with result 'exit-code'. Hello Martin-Éric, Does it happen every time or it is just this time ? Do you have files /var/log/popularity-contest.* ? Sorry for the trouble! Cheers, -- Bill. Imagine a large red swirl here.
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
Hello Russ, In my view the main purpose of policy is to allow interoperability by defining interfaces between packages. We used to have a separate Packaging Manual, but it has been merged with Policy a long time ago. The intent was to reduce duplication which lead to outdated information. However, this directly lead to the structural problem we have now. While it would be OK for a Packaging Manual to say "just use debhelper" that does not help the debhelper developers that need to know what it is expected of debhelper. Cheers, -- Bill. Imagine a large red swirl here.
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Sun, Sep 17, 2023 at 08:28:56AM -0700, Russ Allbery wrote: > Bill Allombert writes: > > On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote: > >> On Sep 17, Russ Allbery wrote: > > >>> (I am a little confused by this wording, but I think what you're > >>> saying is that /usr is encrypted and read-only, and /var is recreated > >>> on each boot. That at least is my understanding of the pattern that > >>> you're trying to enable.) > > >> The general idea is to be able to create /var on the first boot. > > > Does not that would break users expectation that the system image > > contains /var before the first boot ? > > > A lot of things in /var are caches that are mostly instance-independent > > and can be prefilled, but for that, users expect a minimal directory > > hierarchy to be present before first boot. > > Not that I think we're particularly close to achieving this design > currently (and to be clear we haven't decided we're working towards this > yet), but while I understand why a user would have that expectation today, > I'm not sure why it would practically matter. If all of that directory > structure appears on first boot, and no static data is stored in /var, > what use case requires the directory structure already exist in /var > before the first boot? As I said, filling the caches in /var/cache. For that they need to exist with correct ownership and permissions. Most of the cache in /var/cache/ (some are in /var/lib actually) do not depend on the host configuration, and can be regenerated/redownloaded as needed, but not for free. For example you might want to populate /var/cache/apt/archives/ with the debs you need install later on (for example for a pbuilder-like system), populate /var/lib/texmf/fonts/ with your fonts, or even populate /var/www with your website, etc. Cheers, -- Bill. Imagine a large red swirl here.
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote: > On Sep 17, Russ Allbery wrote: > > > (I am a little confused by this wording, but I think what you're saying is > > that /usr is encrypted and read-only, and /var is recreated on each boot. > > That at least is my understanding of the pattern that you're trying to > > enable.) > The general idea is to be able to create /var on the first boot. Does not that would break users expectation that the system image contains /var before the first boot ? A lot of things in /var are caches that are mostly instance-independent and can be prefilled, but for that, users expect a minimal directory hierarchy to be present before first boot. It seems your scheme favors some usecase over some others. Cheers -- Bill. Imagine a large red swirl here.
Bug#1051371: Post-/usr-merge paths for script interpreters
On Sun, Sep 17, 2023 at 08:52:17AM +0200, Ansgar wrote: > > Control: unblock 1051371 by 1050001 > > > > Ansgar writes: > > > > > However, there is a proposal by Jackson for an alternative filesystem > > > layout based on symlink farms in consideration by the technical > > > committee. This advocates removing compat symlinks in /bin, /sbin over > > > time[1], thus requiring (c). > > > > This is not a correct summary of Ian's proposal. In the message that you > > linked, Ian says: > > > > /bin and /lib etc. remain directories (so there is no aliasing). All > > actual files are shipped in /usr. / contains compatibility symlinks > > pointing into /usr, for those files/APIs/programs where this is needed > > (which is far from all of them). Eventualloy, over time, the set of > > compatibility links is reduced to a mere handful. > > > > I am absolutely certain that Ian would consider /bin/sh to be one of the > > programs for which a compatibility symlink is needed, and one of the > > remaining handful of links that would exist indefinitely into the future. > > Indeed, he mentions /bin/sh explicitly later in that message. > > But the subject of this issue talks about "script interpreters", not > just `/bin/sh` (which I guess is safe to assume would be one of the > "handful"). > > It is unclear what files the Jackson symlink farm proposal would leave > in /bin. Would /bin/python3 stay? Or would it stay first, but dropped > at some later point? What about /bin/perl, /bin/zsh, /bin/env, ...? /bin/perl, /bin/env, /bin/python3 did not exist in the old scheme, so there is no point in creating them now. /bin/zsh and /bin/sed existed, though. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1051371: Post-/usr-merge paths for script interpreters
On Wed, Sep 13, 2023 at 10:47:48AM +0200, Bill Allombert wrote: > On Tue, Sep 12, 2023 at 08:48:04PM -0700, Russ Allbery wrote: > > Control: retitle -1 Post-/usr-merge paths for script interpreters > > > > Simon pointed out that this bug is not yet ready to act on, which was very > > helpful. Thank you. However, presumably the buildds will be /usr-merged > > at some point in the not-too-distant future, and we do need to decide what > > to do after that point. > > > > I think the root problem behind this bug is that it is revealing we have > > not made a decision about /bin and /usr/bin path references in Debian > > after /usr-merge. Various people, myself included, made assumptions about > > what the policy would be, but we never actually decided anything that I am > > aware of and people's assumptions are not matching. I think we need to > > talk about this directly, after which what to do with this bug will > > probably become obvious. > > Russ, there is a quite related point I do not think the TC addressed > directly, > but I can easily be mistaken: the default PATH. > It is currently defined in /etc/login.defs (unless my copy of this file is > out of date): > as > ENV_SUPATH > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > ENV_PATHPATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games > > so in pratice, tools like 'which' will always favor /usr/bin over /bin > > $ which sh > /usr/bin/sh > > One of the issue in the past is that reproducible build was broken because > different > build environment lead to different paths. We at least need to address that. To be specific, I needed to add SHELL=/bin/sh GREP=/bin/grep SED=/bin/sed DD=/bin/dd to configure to get reproducible build. (This was in December 2018). Cheers, -- Bill. Imagine a large red swirl here.
Bug#1051801: document DEB_BUILD_OPTIONS value nopgo
On Mon, Sep 11, 2023 at 09:25:11AM +0200, Helmut Grohne wrote: > Package: debian-policy > Version: 4.6.2.0 > Severity: wishlist > X-Debbugs-Cc: > debian-cr...@lists.debian.org,rb-gene...@lists.reproducible-builds.org > > Hi, > > more and more packages implement a technique called profile guided > optimization. The general idea is that it performs a build that is > instrumented for profiling first. It then runs a reasonable workload to > collect profiling data, which in turn is used to guide the optimizer of > a second build which is not thus instrumented. The idea is that this > second build probably is faster than a regular build. Hi! Is it possible to save the profile data to reperform the second build later ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1051371: Post-/usr-merge paths for script interpreters
On Tue, Sep 12, 2023 at 08:48:04PM -0700, Russ Allbery wrote: > Control: retitle -1 Post-/usr-merge paths for script interpreters > > Simon pointed out that this bug is not yet ready to act on, which was very > helpful. Thank you. However, presumably the buildds will be /usr-merged > at some point in the not-too-distant future, and we do need to decide what > to do after that point. > > I think the root problem behind this bug is that it is revealing we have > not made a decision about /bin and /usr/bin path references in Debian > after /usr-merge. Various people, myself included, made assumptions about > what the policy would be, but we never actually decided anything that I am > aware of and people's assumptions are not matching. I think we need to > talk about this directly, after which what to do with this bug will > probably become obvious. Russ, there is a quite related point I do not think the TC addressed directly, but I can easily be mistaken: the default PATH. It is currently defined in /etc/login.defs (unless my copy of this file is out of date): as ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin ENV_PATHPATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games so in pratice, tools like 'which' will always favor /usr/bin over /bin $ which sh /usr/bin/sh One of the issue in the past is that reproducible build was broken because different build environment lead to different paths. We at least need to address that. Personnally, I favor keeping /bin/sh for consistency, but that is aside. Cheers, -- Bill. Imagine a large red swirl here.
Bug#885698: What licenses should be included in /usr/share/common-licenses?
On Tue, Sep 12, 2023 at 10:49:02AM -0700, Russ Allbery wrote: > To take an example that I've been trying to get rid of for over a decade, > many of the /usr/share/common-licenses/BSD references currently in the > archive are incorrect. There are a few cases where the code is literally > copyrighted only by the Regents of the University of California and uses > exactly that license text, but this is not the case for a lot of them. It > looks like a few people have even tried to say "use common-licenses but > change the name in the license" rather than reproducing the license text, > which I don't believe meets the terms of the license (although it's of > course very unlikely that anyone would sue over it). Note that my proposal makes detecting the discrepancy more visible rather than less, since you can compare the generated copyright file with the actual license statement without chasing files. Also, overengineering aside, the copyright generator could support parameter substitution to accomodate small discrepancies in license. For example an option to replace in /usr/share/common-licenses/BSD the line "Copyright (c) The Regents of the University of California." by whatever is required when generating DEBIAN/copyright. Cheers, Bill
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
On Mon, Sep 11, 2023 at 09:21:56AM -0600, Sam Hartman wrote: > > "Santiago" == Santiago Vila writes: > > Santiago> El 10/9/23 a las 4:09, Russ Allbery escribió: > >> I therefore would like to propose a first: I think Policy should > >> simply say that any package that provides a system service should > >> use debhelper and rely on dh_installsystemd to put the > >> appropriate commands in its maintainer scripts. (We can then > >> discuss whether we should do the same for init scripts and > >> dh_installinit, although its stanzas are simpler.) > > Santiago> Hello. I don't like this approach, and I believe we are > Santiago> mixing two different things here. One of them is our > Santiago> ability (or lack thereof) of policy to catch up with real > Santiago> development done elsewhere. Another one is the fact that > Santiago> policy does not mandate any given implementation. > > The question in my mind is whether it is valuable to support multiple > implementations, and I think the answer is no. But we do: we support debhelper 13.11.4 and debhelper 13.11.6. Even if we support a single implementation, we still need to know what is expected of it. Cheers, -- Bill. Imagine a large red swirl here.
Bug#567033: Decide if we should continue recommending /usr/games
On Mon, Sep 11, 2023 at 02:38:14PM -0400, Antoine Beaupré wrote: > On 2023-09-11 11:25:34, Russ Allbery wrote: > > Antoine Beaupré writes: > > > >> I get the argument against bad binaries not being in PATH but we have > >> some tooling for that, don't we? /usr/libexec, no? > > > > /usr/libexec isn't a replacement because it's not on any user's PATH. > > /usr/games is intended to be added to a regular user's path but not > > root's, which is a distinct use case. > > That's an odd argument to make: /usr/games isn't on any user's PATH > either, is it? % grep games /etc/profile /etc/login.defs /etc/profile: PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" /etc/login.defs:ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games Cheers, -- Bill. Imagine a large red swirl here.
Bug#567033: Decide if we should continue recommending /usr/games
On Mon, Sep 11, 2023 at 12:51:33PM -0400, Antoine Beaupré wrote: > On 2018-06-14 11:42:22, Simon McVittie wrote: > > Debian can choose to put games in the /.../games directories, or in the > > standard directories /usr/bin, /usr/share etc., or any mixture of our > > choice, orthogonal to whether/when we move to FHS 3.0. > > It's been a while since this was discussed, but I have just learned of > this issue, so sorry for bumping an old thread but... > > I have recently learned that FreeBSD moved their games out of /usr/games > and into /usr/bin. Things like rot13(6), fortune(6), primes(6) are all > in the main PATH now, amazing no? :) > > That happened in 2015: > > https://cgit.freebsd.org/src/commit/ObsoleteFiles.inc?id=11d9aa670723f508821f2bf6980a555360783a80 > > I wonder if we should just do the same. I'm not sure I see the point of > having all that stuff in a separate directory, personnally, but at least > in this case we shouldn't needlessly diverge from upstream... although > in terms of upstream for bsd-games, things are kind of hazy, at best, > from what I understand. I do not see any advantage over /usr/games. On the other hand, /usr/games allows: - priviledged accounts to omit /usr/games in their path (root does not have it e.g) - quickly find which games are installed on a system (ls /usr/games). - have a separate partitions for game data (which are amongst the largest Debian package) - have a specific policy for /var/games Cheers, Bill
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
On Mon, Sep 11, 2023 at 12:47:15PM +0200, Santiago Vila wrote: > El 10/9/23 a las 4:09, Russ Allbery escribió: > > I therefore would like to propose a first: I think Policy should simply > > say that any package that provides a system service should use debhelper > > and rely on dh_installsystemd to put the appropriate commands in its > > maintainer scripts. (We can then discuss whether we should do the same > > for init scripts and dh_installinit, although its stanzas are simpler.) > > Hello. I don't like this approach, and I believe we are mixing two different > things > here. One of them is our ability (or lack thereof) of policy to catch up with > real development done elsewhere. Another one is the fact that policy does > not mandate any given implementation. I agree. The issue is that we need to document what dh_installsystemd should do, otherwise we will not be able to distinguish between bug in dh_installsystemd and intended behaviour, and we will end up freezing dh_installsystemd to avoid introducing problem by breaking incidental interfaces. Cheers, -- Bill. Imagine a large red swirl here.
Bug#885698: What licenses should be included in /usr/share/common-licenses?
On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote: > Jonas Smedegaard writes: > > Quoting Hideki Yamane (2023-09-10 11:00:07) > > >> Hmm, how about providing license-common package and that depends on > >> "license-common-list", and ISO image provides both, then? It would be > >> no regressions. > > I do wonder why we've never done this. Does anyone know? common-licenses > is in an essential package so it doesn't require a dependency and is > always present, and we've leaned on that in the past in justifying not > including those licenses in the binary packages themselves, but I'm not > sure why a package dependency wouldn't be legally equivalent. We allow > symlinking the /usr/share/doc directory in some cases where there is a > dependency, so we don't strictly require every binary package have a > copyright file. Or we could generate DEBIAN/copyright from debian/copyright using data in license-common-list at build time. So maintainers would not need to manage the copying themselves. Cheers, Bill
Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters
On Wed, Sep 06, 2023 at 04:51:10PM -0600, Sam Hartman wrote: > > "Luca" == Luca Boccassi writes: > Luca> /bin/sh is not universally compatible with non-Linux OSes. > > I claim it is more compatible. > > > Luca> Also I thought that policy should not be used to beat other > Luca> developers (it is because of this) and it should reflect the > Luca> common practices adopted in Debian (it does not because of > Luca> this). Is that no longer the case? > > I'd consider it a non-RC bug if someone were manually writing > #!/usr/bin/sh > > We can debate about normal vs minor. > > I do not think it should be a bug if some automated build process found > /usr/bin/sh and stuck that into a script. > I'd support a policy change to make that clear. I would. Having two paths for the same thing is a technical debt going forward. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1050322: Partial versus complete replacement of a package by another
On Wed, Aug 23, 2023 at 09:22:41AM +0200, julien.pu...@gmail.com wrote:
> Package: debian-policy
> Version: 4.6.2.0
> Severity: normal
>
> Hi,
>
> over at bug #1050027 there is a discussion of applicable policy when
> splitting a package. I'll first explain what the bug is about and then
> why that's a problem with the Policy.
>
> The src:mathcomp-analysis package provided a single binary package
> libcoq-mathcomp-analysis until 0.6.3-2 ; with 0.6.4-1, it's now
> providing two binary packages libcoq-mathcomp-analysis and libcoq-
> mathcomp-classical. The binary package libcoq-mathcomp-analysis Depends
> on libcoq-mathcomp-classical (= ${binary:Version}). And with 0.6.4-1,
> that Depends was the only information, so of course file conflicts
> weren't handled correctly, and that is what #1050027 is about.
>
> In src:mathcomp-analysis 0.6.4-2, I declared that libcoq-mathcomp-
> classical Breaks libcoq-mathcomp-analysis (<< 0.6.4) and closed the
> bug. It was swiftly re-opened because I hadn't used Breaks+Replaces
> according to Policy 7.6.1. But I don't want to use Replaces as libcoq-
> mathcomp-classical isn't a *complete* replacement for libcoq-mathcomp-
> analysis (<< 0.6.4) -- it only provides a small part of it!
>
>
> So what does the Policy actually say?
The main purpose of Replaces: is that dpkg normally does not allow two
different packages
to provide the same files. When the second package is installed dpkg will issue
an
overwrite error, unless the second package has the same name as the first or
when
the second package Replaces: the first.
Mostly there are two cases:
1/ you decide to move the file /usr/share/foo/data from foo to foo-data:
foo-data needs to Replaces: foo for at least one release.
2/ you decide to rename the package foo to foo1:
foo1 need to Replaces: foo for at least one release.
Cheers,
Bill
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
On Sun, Jul 30, 2023 at 08:22:54PM +0100, Luca Boccassi wrote: > On Fri, 30 Jun 2023 00:04:29 +0100 Luca Boccassi > wrote: > > This happened a few days ago and nobody complained (if we ignore > > grumblings because of the fact that I used lintian.debian.org queries > > which are hopelessly and silently out of date, sigh), and bugs are > > filed, there have been a couple of uploads too already. > > > > Can we go ahead, or do you want to wait a specified amount of time? > > If > > so, how long (just so that I know when to come back)? > > Hi, monthly ping. Anything I can do to move this forward? I consider this proposal to be premature. Policy should document current practice, and I do not think this proposal does that. It would it more useful to help maintainers adapt their script to conform to this first, and change policy later. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE
On Sun, Jul 16, 2023 at 12:42:11PM +0100, Luca Boccassi wrote: > If there is somebody who's ignoring things, that would be yourself, > given this change has been not only been explicitly requested, but even > provided _BY_ the CTTE, as you would have easily found out if you > actually went and checked: > > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/93 > http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-07-11-17.58.log.html > > Debian Community Team, Adam is once again sabotaging the CTTE's work > with hostile NMUs, could you please intervene? Thank you. This is premature. > In the meanwhile, I'll immediately revert the sabotage. If this package is so important, why is it maintained by NMUs ? Why cannot the maintainers do a proper upload ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1040775: package description mention wrong package name
Source: audit Version: 1:3.0.9-1 Severity: normal Hello Laurent, The package descriptions do not match the package names: For example libaudit-dev: ' The audit-libs-devel package contains the static libraries and header' when there is no debian package audit-libs-devel. But actually there is no need to spell out the package name in the package own description. I suggest you write a generic header like "audit is a framework for monitoring systems for security related events." and then adds "This package contains ..." for each package as needed. Package: auditd Description: User space tools for security auditing The audit package contains the user space utilities for storing and searching the audit records generated by the audit subsystem in the Linux 2.6 kernel. . Also contains the audit dispatcher "audisp". Do not mention 2.6, this is quite outdated now. This package contains the user space utilities for storing and searching the audit records generated by the audit subsystem in the Linux kernel Package: libauparse0 Description: Dynamic library for parsing security auditing The libauparse package contains the dynamic libraries needed for applications to use the audit framework. It is used to monitor systems for security related events. . This package contains the libauparse0 library. Package: libauparse-dev Description: Header files and static library for the libauparse0 library The audit-libs parse package contains the dynamic libraries needed for applications to use the audit framework. It is used to monitor systems for security related events. Should be 'This package contains...' Package: libaudit1 Description: Dynamic library for security auditing The audit-libs package contains the dynamic libraries needed for applications to use the audit framework. It is used to monitor systems for security related events. Should be 'This package contains...' Package: libaudit-common Description: Dynamic library for security auditing - common files The audit-libs package contains the dynamic libraries needed for applications to use the audit framework. It is used to monitor systems for security related events. . This package contains the libaudit.conf configuration file and the associated manpage. "audit is a framework used to monitor systems for security related events. This package contains the libaudit.conf configuration file and the associated manpage. " Package: libaudit-dev Description: Header files and static library for security auditing The audit-libs-devel package contains the static libraries and header files needed for developing applications that need to use the audit framework libraries. Should be 'This package contains...' Package: python3-audit Description: Python3 bindings for security auditing The package contains the Python3 bindings for libaudit and libauparse, which are used to monitor systems for security related events. Python can be used to parse and process the security event messages. Should be 'This package' Package: golang-redhat-audit-dev Description: Go client bindings for the libaudit library The package contains the Go bindings to libaudit that only allows for logging audit events. . This package contains the source. Should be 'This package' "This package contains the source." is unclear. Package: audispd-plugins Description: Plugins for the audit event dispatcher The audispd-plugins package provides plugins for the real-time interface to the audit system, audispd. These plugins can do things like relay events to remote machines or analyze events for suspicious behavior. OK. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1039500: menu: reproducible builds: embeds timestamp in menu.info.gz
On Mon, Jun 26, 2023 at 11:05:11AM -0700, Vagrant Cascadian wrote: > Source: menu > Severity: normal > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: timestamps > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > The timestamp is embedded in the gzip headers of menu.info.gz: > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/menu.html > > /usr/share/info/menu.info.gz > > > gzip·compressed·data,·was·"menu.info",·last·modified:·Mon·Jun·26·13:22:38·2023,·max·compression,·from·Unix > vs. > > gzip·compressed·data,·was·"menu.info",·last·modified:·Sun·Jul·28·19:49:45·2024,·max·compression,·from·Unix > > The attached patch to debian/rules works around this by uncompressing > the menu.info.gz and letting dh_compress handle the compression. > > A better solution might be to fix this upstream, by using "gzip > --no-name". It looks like doc/Makefile.* would be the place, but I had > no luck adding it to the gzip calls there. You need to rerun automake. But the actual bug is that the Makefile remove menu.info, which causes it to be regenerated with a different timestamp, which was not intended. Also if you know how to fix the C++ warning, tell me. hints.h: In constructor 'hints::hints()': hints.h:72:9: warning: member 'hints::hint_nentry' is used uninitialized [-Wuninitialized] 72 | hint_nentry), hint_nentry(6), hint_topnentry(6), max_ntry(5), | ^~~ Cheers, -- Bill. Imagine a large red swirl here.
Bug#1039493: menu: reproducible builds: embeds build path in various binarieso
On Mon, Jun 26, 2023 at 09:58:06AM -0700, Vagrant Cascadian wrote: > Source: menu > Severity: normal > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: buildpath > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > The build path is embedded in various binaries: > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/menu.html > > /usr/bin/install-menu > > /build/1st/menu-2.1.49/install-menu/install-menu.cc:126·(discriminator·1) > vs. > /build/2/menu-2.1.49/2nd/install-menu/install-menu.cc:126·(discriminator·1) > > The attached patch to debian/rules fixes this by passing > -ffile-prefix-map via CXXFLAGS and CFLAGS. Indeed, I just saw the FTBR on qa.debian.org. Thanks for the patch! Cheers, -- Bill. Imagine a large red swirl here.
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Tue, Jun 13, 2023 at 05:43:17PM +0200, Thorsten Glaser wrote: > On Mon, 5 Jun 2023, Simon McVittie wrote: > > >No init system at all, (C.), can only happen when starting with a > >minbase debootstrap or equivalent (because a default debootstrap > >includes the init metapackage due to its Priority: required). In > >this scenario it *usually* doesn't really matter whether we > >install systemd or systemd-tmpfiles-standalone. systemd is somewhat > > This is not quite true; there is one really important use case: > chroots. I have multiple chroots (sid, stretch, buster) on one > of my bullseye systems which I use with schroot, but that could > just as well be any other chroot, to run individual software in > it. They are, as is proper, configured to not run any services > (via policy-rc.d). I agree, chroots are important to consider, and the system should not make assumptions how and why there are used. Conversely, sometimes I need to use chroots to test init scripts. start-stop-daemon should not refuse to run in a chroot if policy-rc.d allows it. Cheers, Bill.
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Tue, Jun 06, 2023 at 11:34:17PM +0100, Luca Boccassi wrote: > On Wed, 7 Jun 2023 00:01:42 +0200 Bill Allombert > > This is beside the point. Your problematic statement was > > "The whole project is moving toward git and Salsa ". > > This is not conducive of productive interaction. > > It was not problematic at all, unless you are deliberately trying to > see problems where there are none. It was an hyperbole: a huge number > of packages and teams are using effectively Salsa workflows for > collaboration today. Are you denying this? This is not important. What matters is that this statement could be read as excluding from the project or belittling developers that are not moving toward Salsa. This is inappropriate. Even assuming it was not your intent, such statements creates friction in the project by making people uncomfortable without any benefit, and so should be avoided. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Wed, Jun 07, 2023 at 08:19:08AM -0700, Russ Allbery wrote: > > In general, policy proscription are only useful when the description of > > a better mechanism is provided. But there is no place for that in this > > section. > > I'm not sure I understand this statement, since describing a better > mechanism is exactly the point of that language about systemd. We link > directly to those better mechanisms (masking, drop-ins, and, for > alternatives, aliases). What I meant was that this section in not the right place for systemd or other software configuration detail, because nobody will look for systemd configuration detail in the dpkg-divert section. > I definitely agree that Policy should have a whole section devoted to > systemd and its configuration files, but I don't want to try to boil the > ocean in one bug. But yes, we should be working towards that, IMO. Yes that what I wanted to say. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Tue, Jun 06, 2023 at 07:56:14PM -0700, Russ Allbery wrote: > Sean Whitton writes: > > > I think what's a bit peculiar here is using "must" for a case where > > there might be package-specific exceptions. In other cases, Policy uses > > "should" for these cases. Typically "must" rules are simple and > > completely determinate. > > I prefer that too, but in this case, it feels like must is appropriate for > at least systemd configuration files. And also, just intuitively, I feel > like must is correct when people are using diversions rather than a native > mechanism. Diversions add weird edge cases and we really shouldn't be > using them lightly. > > The wording I proposed and that Luca has now adopted therefore uses must > with a caveat. Does that sound okay to you? I do not think appropriate for the policy to list systemd or any other packages specifically in this section. If a package set up a diversion that breaks another, then it is buggy, whatever policy say. If the diversion does not cause any breakage, there is no purpose for policy to declare it a RC bug. In general, policy proscription are only useful when the description of a better mechanism is provided. But there is no place for that in this section. It would more suitable to have a separate section or document defining the interface between systemd and other packages, that would explain how to avoid diversion by providing better solutions rather than direct proscriptions, with more details than just "use native systemd configuration files". Cheers, -- Bill. Imagine a large red swirl here.
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Tue, Jun 06, 2023 at 07:52:35PM -0700, Russ Allbery wrote: > Bill Allombert writes: > > On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote: > > >> If you prefer, I can reword the general rule to be stricter, ie: > >> "packages must not use diversions where native mechanisms are > >> available" or so. Would this be better? > > > "native mechanisms" seems to vague. > > I suggested "must not be used when a suitable override mechanism that > accomplishes the same goal is already available." Does that sound okay? > It's a bit weaker and opens the door to arguments about whether the native > override mechanism accomplishes the same goal, but I think that's a > feature here rather than a bug. It is fine with me. It is in line with the notion that diversion are a last resort, but not precluded entirely. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Tue, Jun 06, 2023 at 03:16:02PM +0100, Luca Boccassi wrote: > On Tue, 6 Jun 2023 15:23:35 +0200 Bill Allombert , > Luca Boccassi wrote: > > On Tue, Jun 06, 2023 at 01:38:51PM +0100, Luca Boccassi wrote: > > > > The diversion system is made precisely to work around other > packages > > > behavior, > > > > this is a feature not a bug. That it should only be used as last > > > resort, I > > > > think everyone agree. But when it is, it should not be a RC bug. > > > > > > This is a technical matter, I'm not sure what 'consensus' means in > this > > > context? Things _will not work_ as expected by shoe-horning dpkg's > > > overrides onto systemd mechanisms, they _will_ break in weird and > > > unexpected ways, and we as maintainers _will not support it_ - > whether > > > somebody else agrees or disagrees with this won't change any of it. > > > > Consensus is the way the Debian Policy update process works. > > But you do not need changes in Policy to report bugs about package > that breaks > > others, there is the "grave" severity already. > > That does not help, given currently policy allows it, without changes > they could just say "policy allows me, so go fix it yourself". What > then? That simply not how Policy works. Policy is for promoting interoperability and documenting current practices. "Policy is not a stick to beat people with" as Manoj used to say. If you are suggesting a policy change so that you can report RC bugs on other packages, you are on the wrong track. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Tue, Jun 06, 2023 at 09:36:31PM +0100, Luca Boccassi wrote: > On Tue, 6 Jun 2023 20:51:46 +0200 Dominik George > wrote: > > > Ok, how about: "the whole project, minus > naturesha...@debian.org who > > > appears to be unfamiliar with the concept of hyperboles, is moving > > > toward git and Salsa". Better? > > > > No. > > > > Your "hyperbole" very much read as "Come on, minority who cares about > > the mail workflow, you're weird anachronists, get onto the Salsa > train already!" > > > > So that's what I am criticizing. > > Sure, and you just coincidentally happened to leave out the part that > says the exact opposite: This is beside the point. Your problematic statement was "The whole project is moving toward git and Salsa ". This is not conducive of productive interaction. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Tue, Jun 06, 2023 at 01:38:51PM +0100, Luca Boccassi wrote: > > The diversion system is made precisely to work around other packages > behavior, > > this is a feature not a bug. That it should only be used as last > resort, I > > think everyone agree. But when it is, it should not be a RC bug. > > This is a technical matter, I'm not sure what 'consensus' means in this > context? Things _will not work_ as expected by shoe-horning dpkg's > overrides onto systemd mechanisms, they _will_ break in weird and > unexpected ways, and we as maintainers _will not support it_ - whether > somebody else agrees or disagrees with this won't change any of it. Consensus is the way the Debian Policy update process works. But you do not need changes in Policy to report bugs about package that breaks others, there is the "grave" severity already. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Tue, Jun 06, 2023 at 12:16:39PM +0100, Luca Boccassi wrote: > > > local administrators and local packages to override the behaviour of > > > Debian. Its use between Debian packages should be rare, should involve > > > coordination between the packages and their maintainers, and must only > > > be used to solve problems that cannot be handled through other > > > facilities or native mechanisms. In other words, packages in Debian > > > must not divert a file from another package unless this is arranged > > > cooperatively between the packages to solve some specific and unusual > > > problem. > > > > How about: > > > > Diversions and alternatives are primarily tools for local > > administrators and local packages to override Debian's default > > behaviour. Maintainers should prefer to use other, package-specific > > facilities for overriding configuration, such as systemd's unit file > > overrides, wherever possible. > > > > If diversions and alternatives are to be used, maintainers should > > co-ordinate with the maintainers of all the packages involved. For > > example, configuration files used by systemd components should not > > be diverted with dpkg-divert or the alternatives system without > > agreement between not only the maintainers of the packages that ship > > the files, but also the maintainers of the relevant systemd > > components. > > As above, as long as this wording makes any offending package > rc-buggy, it's fine by me, but my understanding is that using 'should' > doesn't guarantee that. Please correct me if I'm wrong here. I do not think there is consensus that this should be a RC bug outside of a case by case basis. It is already awkward to mention systemd explicitly in this paragraph. The diversion system is made precisely to work around other packages behavior, this is a feature not a bug. That it should only be used as last resort, I think everyone agree. But when it is, it should not be a RC bug. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote: > If you prefer, I can reword the general rule to be stricter, ie: > "packages must not use diversions where native mechanisms are > available" or so. Would this be better? "native mechanisms" seems to vague. Cheers, -- Bill. Imagine a large red swirl here.
Bug#865183: libjpeg6b: please build-depend on automake, not obsolete automake1.11
On Thu, May 25, 2023 at 03:18:58PM +0200, Bastian Germann wrote: > libjpeg6b is not going anywhere. What does that even mean ? > I would like to suggest to remove the package for the purpose of reducing the > automake1.11 dependent package. > libjpeg6b has not been part of a Debian release in years. What is the reason > for it staying in unstable? Historical reason. It is required for compatibility with the LSB. At least that prevent someone to reuse the name by mistake. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements
On Mon, Mar 20, 2023 at 12:05:24PM +, James Addison wrote: > On Mon, 20 Mar 2023 13:31:37 +0800, pabs wrote: > > Perhaps lintian could add classification tags for the relevant CPU > > instructions and then the i386 port could have extra autopkgtest nodes > > that only process the packages detected by lintian. > > That's not a bad idea. Are there any reasons that that might _not_ be a good > idea before filing a wishlist bug? (performance, implications of scanning > binary packages, ...) This seems logistically problematic. Is lintian actually ran on i386 binaries anymore ? lintian.debian.org only lists reports for amd64 packages. I am not sure it is worth the trouble, frankly. I do not see what this would bring us. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1005863: gcc-11: invalid opcode for Geode LX on i386
On Sun, Mar 19, 2023 at 11:47:21PM +, James Addison wrote: > Package: gcc-11 > Followup-For: Bug #1005863 > X-Debbugs-Cc: debian-...@lists.debian.org, debian-rele...@lists.debian.org, > debian-pol...@lists.debian.org > > Hi folks, > > Bug #1005863 describes a gcc-11 behaviour that results in software that exits > ungracefully on Geode LX i686 hardware. Despite self-reporting as i586 > sometimes, Geode LX is in fact an i686 CPU (without physical address > extensions > and multi-instruction noops -- both optional per spec). > > My assessment -- which may be incorrect -- is that something like 20% of > packages in the bookworm i386 suite are susceptible to the bug, so I think > that > installing bookworm on a Geode LX system would present users with a poor > experience of Debian. > > Would it be fair to raise the severity of this bug to a release-critical > level? >From a purely engineering perspective, without a way to address this problem, increasing the severity will not achieve much. Instead this should be documented in the release notes, with any relevant information. However, the fact that the the CPU is 15 year old is not a sufficient rationale to stop supporting it. It is more useful for debian-i386 to focus on CPUs that cannot run debian-amd64 than on CPUs that can. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Mon, Feb 20, 2023 at 01:59:21PM +, Jelmer Vernooij wrote: > On Thu, Feb 09, 2023 at 02:15:42PM -0700, Sean Whitton wrote: > > Hello, > > > > On Fri 03 Feb 2023 at 05:24PM GMT, Jelmer Vernooij wrote: > > > > > Package: debian-policy > > > Severity: wishlist > > > > > > Policy currently describes Vcs-* headers as something optional, but stops > > > to > > > endorse a particular Vcs. > > > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > > specifically here. Apart from technical arguments, it's the vcs that the > > > majority of packages in the archive uses - and thus will have the better > > > tooling, less of a learning curve for other contributors, etc. > > > > > > There are very few holdouts of other vcses in the archive. I count 62 > > > (ignoring those with an alioth URL): > > > > > > * 26 on Svn > > > * 3 on Cvs > > > * 4 on Hg (2 are hg/hg-buildpackage) > > > * 39 on bzr (half of these are actually bzr and related packages, which > > > I maintain) > > > > This strikes me as a matter for devref not Policy? > > I've created a PR for devref - > https://salsa.debian.org/debian/developers-reference/-/merge_requests/41 > > Are you saying that it doesn't belong in policy because it'd be a > recommendation rather than a must/should (at this point?), or because it's > more about the > workflow inside of Debian than package contents? Yes this is about the workflow and not the package, and so far we have let developpers pick whatever workflows suit them. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1031315: libjpeg9: libjpeg.so.9* missing
On Wed, Feb 15, 2023 at 05:45:26AM +0800, Roy Clark (kralcyor) wrote:
> Package: libjpeg9
> Version: 1:9d-1.1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> /usr/lib/*/{libjpeg.so.9,libjpeg.so.9.4.0} are missing in the package, making
> it completely unusable:
> $ dpkg -L libjpeg9
> /.
> /usr
> /usr/share
> /usr/share/doc
> /usr/share/doc/libjpeg9
> /usr/share/doc/libjpeg9/README.gz
> /usr/share/doc/libjpeg9/changelog.Debian.gz
> /usr/share/doc/libjpeg9/changelog.gz
> /usr/share/doc/libjpeg9/copyright
>
> This issue may related to changes in the build system. While libjpeg.so.9*
> appear in the old version 1:9d-1, a rebuilt package of version 1:9d-1 on a
> latest unstable Debian system also lacks libjpeg.so.9*.
Ah thanks. I should have checked that the NMU was correct.
Cheers,
--
Bill.
Imagine a large red swirl here.
Bug#934536: info version not shipped, close this bug?
On Thu, Feb 09, 2023 at 02:35:42PM +, Holger Levsen wrote: > control: tags -1 +moreinfo > thanks > > hi, > > (originally sent to the wrong (but archived) bug number...) > > we're not shipping the manual in .info format, so I'm wondering whether this > bug should simply be closed, or why not? $ dpkg -L developers-reference | grep info /usr/share/info /usr/share/info/developers-reference.info.gz Cheers, -- Bill. Imagine a large red swirl here.
Bug#299927: debtags future unclear
On Wed, Feb 08, 2023 at 01:24:52PM +, Holger Levsen wrote: > control: tags -1 +moreinfo > control: affects -1 debtags > thanks > > hi, > > https://lists.debian.org/msgid-search/20221019132043.d4c4liyt6s6qe...@enricozini.org > and > https://lists.debian.org/msgid-search/bb7064071ebd838a9e045a1916bba49a9b960d80.ca...@debian.org > indicate that debtags.debian.org might be shutdown after the release > of bookworm, thus tagging this bug moreinfo for now, as there's not > much point documenting something which is going away. It seems this concerns only the debtags.debian.org website, not the whole debgtags system, right ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#801065: Documenting how to not fail postinst on service fails to starto
O#n Wed, Feb 08, 2023 at 04:47:37PM +, Holger Levsen wrote: > retitle -1 turn #904558 into advice - how postinst should deal with failures > thanks > > On Wed, Feb 08, 2023 at 09:26:58AM -0700, Sam Hartman wrote: > > The TC bug is 904558. > > thank you very much for this pointer, that's a pretty good discussion, > which resulted in > > - > > So, the TC declines to rule on what should maintscripts do when failing > to > (re)start a service (or otherwise encountering a similarly serious > problem). > > - > (read the full result at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904558#137 ) Note that the TC declining to rule on an issue does not override the policy group right to make a determination on that issue. So we are back to the situation before the referral to the TC. Cheers, -- Bill. Imagine a large red swirl here.
Bug#801065: consent unclear
On Wed, Feb 08, 2023 at 03:54:22PM +, Holger Levsen wrote: > hi, > > btw, as pointed out on irc: I ment consensus, not consent. :) > > On Wed, Feb 08, 2023 at 10:36:02AM -0500, Marvin Renich wrote: > > > I don't think there has been consent on the issue, thus I'm tagging it > > > moreinfo. > > > > > > I'm also wondering whether to mark this bug as wontfix (until there is > > > consent) or to reassign to debian-policy or simply to close it. > > > > I disagree. Re-reading the messages to the bug report, We have > > "strongly support" from Sam Hartman, and "also in favor" from Russ > > Allbery and Bill Allombert. > > > > The only objection was from Henrique de Moraes Holschuh based on lack of > > risk assessment from the mistaken impression > > not only based on that, but way more importantly that this would change > *years* of existing practice. Could you clarify which 'existing practices' ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Fri, Feb 03, 2023 at 05:57:21PM +, Jelmer Vernooij wrote: > On Fri, Feb 03, 2023 at 06:48:13PM +0100, Bill Allombert wrote: > > On Fri, Feb 03, 2023 at 05:24:36PM +, Jelmer Vernooij wrote: > > > Package: debian-policy > > > Severity: wishlist > > > > > > Policy currently describes Vcs-* headers as something optional, but stops > > > to > > > endorse a particular Vcs. > > > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > > specifically here. Apart from technical arguments, it's the vcs that the > > > majority of packages in the archive uses - and thus will have the better > > > tooling, less of a learning curve for other contributors, etc. > > > > > > There are very few holdouts of other vcses in the archive. I count 62 > > > (ignoring those with an alioth URL): > > > > > > * 26 on Svn > > > * 3 on Cvs > > > * 4 on Hg (2 are hg/hg-buildpackage) > > > * 39 on bzr (half of these are actually bzr and related packages, which > > > I maintain) > > > > I do not quite understand. Surely the package need to use the VCS-* header > > corresponding to the VCS used by the repository, whathever it is ? This is > > not > > a matter of preference. > > Sorry, to be clear I also meant encouraging the use of Git as a Vcs - rather > than just > of the Vcs-Git header. Then maybe it would be a better fit for the developer reference than to policy ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Fri, Feb 03, 2023 at 05:24:36PM +, Jelmer Vernooij wrote: > Package: debian-policy > Severity: wishlist > > Policy currently describes Vcs-* headers as something optional, but stops to > endorse a particular Vcs. > > At this point, it seems uncontroversial to encourage use of Vcs-Git > specifically here. Apart from technical arguments, it's the vcs that the > majority of packages in the archive uses - and thus will have the better > tooling, less of a learning curve for other contributors, etc. > > There are very few holdouts of other vcses in the archive. I count 62 > (ignoring those with an alioth URL): > > * 26 on Svn > * 3 on Cvs > * 4 on Hg (2 are hg/hg-buildpackage) > * 39 on bzr (half of these are actually bzr and related packages, which I > maintain) I do not quite understand. Surely the package need to use the VCS-* header corresponding to the VCS used by the repository, whathever it is ? This is not a matter of preference. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Sat, Jan 21, 2023 at 12:58:19PM -0800, Russ Allbery wrote: > Wouter Verhelst writes: > > On Fri, Jan 20, 2023 at 05:16:43PM +, Simon McVittie wrote: > > >> Sure, but neither of those actually require us to support GBK or GB > >> 18030 as a system locale, only as something that iconv() (or whatever > >> browsers actually use, which is probably their own thing) can convert > >> into their preferred internal representation (which is almost certainly > >> UTF-8, UTF-16 or UCS-4). > > > Those files need to be edited *somewhere*. If that somewhere is a Debian > > desktop, then you also need editors that know how to write such files, > > etc. > > Both Emacs and vim will edit files in whatever (supported) encoding you > want, regardless of the locale encoding. I would assume this is not that > uncommon of a feature for other editors as well. This is therefore a bit > like Simon's web browser example (although may be somewhat less > transparent, admittedly). This is true but this is missing an important point: it is usually not possible to detect the characther encoding of a plain text file. That is where a default encoding is required. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Thu, Jan 19, 2023 at 11:47:42AM +, Simon McVittie wrote: > On Wed, 18 Jan 2023 at 16:30:46 -0700, Anthony Fok wrote: > > In their mind, GB 18030 encompasses a lot more than just > > a character encoding mapping table. It is the full support package > > (including fonts, display, printing, input methods, etc.) for Han > > Chinese and all other minority languages used in China. > > Preferring to use Unicode does seem to be the direction that all of > computing is going in, as a simplifying assumption - for example W3C > advice for HTML is "You should always use the UTF-8 character encoding"[1] > - and as we know, things that aren't tested usually don't work. So I > think the level of functionality for non-UTF-8 locales and encodings in > the software we package is going to decline over time, whether Debian > wants it to or not. It is true for everything. Users know how to pick the software that works for their environment. It is not relevant that software they do not use do not support their environment. Telling users to switch to UTF-8 because such and such software they never used and were never going to use do not support GB18030 does not make sense. It is like saying the Linux console is deprecated because there are Debian packages that requires X or Wayland. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential
On Wed, Jan 04, 2023 at 07:13:04PM +0100, Santiago Vila wrote: > El 4/1/23 a las 18:23, Sam Hartman escribió: > > I think that the > > cost of going and adding all the build-depends on > > required-but-not-build-essential is not worth what I estimate we'd gain > > from having this extra information. > > I think you can't really estimate such thing. You seem to imply that we have > been allowing packages with missing build-dependencies for a long time, but > that's > not accurate. The *buildds* have been allowing packages with missing > build-dependencies > for a long time, but I have been reporting those bugs for a long time as well. > > So it's not as if I were proposing that we start doing something that we have > never done. > My only aim is that we detect such bugs earlier in the chain, in the buildds, > where it should be. > > BTW: Today I reported that kodi did not build without tzdata. But in the end > this was not a missing build-dependency of kodi, but a missing *binary* > dependency > of one of the build-dependencies of kodi. So is there a service that detect such missing *binary* dependency ? This seems the missing piece. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential
On Wed, Jan 04, 2023 at 08:46:39AM +0100, Santiago Vila wrote: > El 4/1/23 a las 2:32, Sam Hartman escribió: > > > > > > > "Santiago" == Santiago Vila writes: > > > > Santiago> As an example, packages tzdata, mount or e2fsprogs are not > > Santiago> build-essential and afaik have not been for a long time, > > Santiago> but there are still people who believe that they are > > Santiago> build-essential for the mere fact that they are > > Santiago> priority:required. > > > > Why not just make all required packages build-essential? > > I agree we should fix the class of bugs you are talking about, but it > > seems like in some cases it might be easier to fix them by declaring > > them not buggy. > > Because required to build != required in a _running_ system At minimum, it should not be allowed to Build-Conflicts with a required package. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1026872: menu: READMEs mention /usr/share/menu/default, which doesn't exist, as documentation
On Thu, Dec 22, 2022 at 10:41:00PM +0100, наб wrote: > Package: menu > Version: 2.1.49 > Severity: normal > > Dear Maintainer, > > -- >8 -- > $ cat usr/share/menu/README > ... > The files should have the name of the package that's installing it, > and may contain as many lines (menu entries) as is necessary. > > For examples, please look in /usr/share/menu/default > ... > -- >8 -- > but > -- >8 -- > $ find -name default > -- >8 -- > so? > > For reference, other documentation seems to indicate that /u/s/m/d Dear нaб /u/s/m/d was declared obsolete in 2.1.38, but due to recent developments, I think I will need to revive it. Thanks for using Debian menu, Bill.
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Wed, Dec 21, 2022 at 03:23:09PM +0100, Adam Borowski wrote: > On Mon, Dec 19, 2022 at 10:44:12PM +0100, Bill Allombert wrote: > > Which raise the question: does the corresponding user group moved to UTF-8 ? > > Judging from <https://en.wikipedia.org/wiki/Chinese_character_encoding>, > > neither Chinese nor Japanese users have overwhelmingly moved to UTF-8, > > so it would be problematic to stop supporting BIG5, GB18030 and EUC-JP. > > We actually do have data about locale usage in Debian. > I've copied .report files from bugs-mirror, and > grep -arm1 ^Locale: */*/*.report > shows that: > * most recent use of BIG5 is #925894 from March 2019 > * there's no use of any GB locale (other than en_GB :p) past #609517 (2011) > * for EUC there's #1001207 (2021) #953616 #939588 #939494 #893625 I do not think bug submitters expect the Locale field to be used for locale usage statistics, so it does not seem fair to use it for that purpose. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Mon, Dec 19, 2022 at 07:08:09PM +, Simon McVittie wrote:
> On Fri, 16 Dec 2022 at 19:21:37 +0100, Adam Borowski wrote:
> > As of Bookworm, legacy locales are no longer officially supported.
>
> For clarity, I think when you say "legacy locales" you mean locales
> whose character encoding is either explicitly or implicitly something
> other than UTF-8 ("legacy national encodings"), like en_US (implicitly
> ISO-8859-1 according to /usr/share/i18n/SUPPORTED) and en_GB.ISO-8859-15
> (explicitly ISO-8859-15 in its name). True?
>
> Many of the non-UTF-8 encodings are single-byte encodings in the
> ISO-8859 family, but if I understand correctly, your reasoning applies
> equally to multi-byte east Asian encodings like BIG5, GB18030 and EUC-JP.
> Also true?
>
> Meanwhile, locales with a UTF-8 character encoding, like en_AG
> (implicitly UTF-8 according to /usr/share/i18n/SUPPORTED) or en_US.UTF-8
> (explicitly UTF-8), are the ones you are considering to be non-legacy.
> Also true?
Which raise the question: does the corresponding user group moved to UTF-8 ?
Judging from ,
neither Chinese nor Japanese users have overwhelmingly moved to UTF-8,
so it would be problematic to stop supporting BIG5, GB18030 and EUC-JP.
Cheers,
--
Bill.
Imagine a large red swirl here.
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Fri, Dec 16, 2022 at 07:21:37PM +0100, Adam Borowski wrote: > Package: debian-policy > Version: 4.6.1.1 > Severity: wishlist > > Hi! > As of Bookworm, legacy locales are no longer officially supported. In order > to not break testsuites, they're mostly working if you install locales-all, > and you may manually request their generation by editing /etc/locale.gen -- > but functionality is expected to bit rot and/or be removed in the future. Hi Adam, How do you define a legacy locale ? What do you mean by "officially supported" ? By whom ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#923014: Add systemd unit - allow usage without cron installed
On Thu, Nov 17, 2022 at 09:37:27AM +0800, Paul Wise wrote: > On Wed, 2022-11-16 at 19:00 +0100, Bill Allombert wrote: > > > /etc/cron.daily/popularity-contest is a conffile, I cannot make it into > > a systemd service. > > The usual way to handle both cron and systemd timers is to move most of > the logic in the cron script into a script in /usr then make the cron > script exit under systemd or call the /usr script under sysvinit and > then add a systemd timer and service that calls the /usr script. But then the user would not be able to configure it anymore, so I do not see the upside. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1024367: In 4.9.1, the example uses not recommended install -s
On Fri, Nov 18, 2022 at 02:14:32PM +0100, Enrico Zini wrote: > Package: debian-policy > Version: 4.6.1.1 > Severity: normal > > Hello, and thank you for maintaining the Policy! > > Policy paragraph 4.9.1 has an example debian/rules which contains these > lines: > >INSTALL_PROGRAM = $(INSTALL) -p-o root -g root -m 755 > >ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS))) >INSTALL_PROGRAM += -s >endif > > However, paragraph 10.1 recommends against it: > >It is not recommended to strip binaries by passing the "-s" flag to >"install", because this fails to remove .comment and .note sections, >and also prevents the automatic creation of dbgsym binary packages by >tools like "dh_strip". > > I would personally prefer if the example built on debhelper. If the > intention is to show what are the expectations at a lower level then > I wish the example had a comment saying "This snippet serves to explain > what are the expectations as a lower level. You usually want to use > debhelper instead" I know it is not what you are after, but maybe it is time to fix install -s ? dh_strip only work if the upstream 'make install' did not already strip the binaries by using install -s itself. So packagers need to work around it each time. Cheers, -- Bill. Imagine a large red swirl here.
Bug#923014: Add systemd unit - allow usage without cron installed
On Fri, Feb 22, 2019 at 04:00:30PM -0800, Bryan Quigley wrote: > Package: popularity-contest > Version: 1.67 > > This is regards to the popularity-contest cron job. I'm looking into > running systems without anacron/cron installed - instead using systemd > timers. Hello Bryan, Why not use systemd-cron instead ? /etc/cron.daily/popularity-contest is a conffile, I cannot make it into a systemd service. Sorry for not answering sooner, systemd is still mysterious to me. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
On Sun, Nov 06, 2022 at 02:18:52PM +0100, Jerome BENOIT wrote: > Hello Bill, I got a closer look. > > It appears that [gap-]guava auxiliary binaries do not depend on gap-dev > related packages. > We must discard this dependency a part of resolving the issue. > However, these auxiliary binaries are C compiled executables, that is to say > that they are not scripts. Yes, and as I said the program output is the same on all architectures, so it does not need to match the gap architecture, so there is no reason to handle it specially. In particular there is no use to install two version of the program for two different architectures. > > > > > > > However only the last dir[ectory] may work on > > muti-architecture boxes. > > > > > Here we would need a "/usr/share/gap/pkg/guava/bin/ > > > > > between the two current ones: > > > > > can gap support this ? > > > > > > GAP does not have the notion of the Debian triplet, so it is > > difficult to write a patch > > > > to add /usr/share/gap/pkg/guava/bin/$(DEBIAN_TRIPLET)/ > > > > I guess that a patch can be written to do so. > > > > This probably requires changing the C code to define a new > > GAPInfo.DEB_HOST_MULTIARCH field. > > Do you have a better idea ? > > I am ready to write such a C patch. Is that okay with you ? Depends on messy it is, I guess ? The problem is that once packages start to use that patch, I cannot just drop the patch if it fails to apply to a new upstream version. Cheers, Bill
Bug#999306: libjpeg6b: diff for NMU version 1:6b2-3.1
On Thu, Nov 03, 2022 at 04:12:46PM -0300, Marcos Talau wrote: > Control: tags 999306 + patch > Control: tags 999306 + pending > > Dear maintainer, > > I've prepared an NMU for libjpeg6b (versioned as 1:6b2-3.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. It is a bit pointless, but if that suites you... Did you manage to test the package ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
On Thu, Nov 03, 2022 at 12:25:17PM +0100, Jerome BENOIT wrote: > > > > Indeed, the GAP patch debian/patches/program-path adds > > /usr/share/gap/pkg/guava/bin/ to this list. > > > > > However only the last dir[ectory] may work on muti-architecture boxes. > > > Here we would need a "/usr/share/gap/pkg/guava/bin/ between > > > the two current ones: > > > can gap support this ? > > > > GAP does not have the notion of the Debian triplet, so it is difficult to > > write a patch > > to add /usr/share/gap/pkg/guava/bin/$(DEBIAN_TRIPLET)/ > > I guess that a patch can be written to do so. This probably requires changing the C code to define a new GAPInfo.DEB_HOST_MULTIARCH field. Do you have a better idea ? > > There is a single /usr/bin for all archs, so in particular a single > > /usr/bin/gap, > > so I do not see why we need to support several /usr/share/gap/pkg/guava/bin, > > especially since mismatched gap-core and gap-guava-bin should work. > > Along this reasonning, > /usr/share/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv8/ has no use. Indeed. gap only need to support it for compatibility with non-debian-packaged gap packages, that uses this kind of directory name. > Please let me fix this guava issue by the week-end. OK, thanks! Bill.
Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
On Wed, Nov 02, 2022 at 11:13:07AM +0100, Jerome BENOIT wrote:
> Hello Bill, thanks for your message.
Hello Jerome,
Please keep in mind that the BTS does not forward email to the submitter so
you always need to CC them otherwise they will not see your answer!
I only found it by luck, because I see your upload.
> I was trying to fix the issue when you sent the report.
> I isolated the issue as you did.
>
> Solution 1) would the solution on box with one architecture, not on box with
> multi-architectures.
> The package test relies DirectoriesPackagePrograms gap procedure (see
> debian/tests/makecheck.tst )
>
> In Sid environment as provided by autopkgtest(1),
>
> DirectoriesPackagePrograms( "guava" )
>
> gives
>
> [ dir("/usr/share/gap/pkg/guava/bin/"),
> dir("/usr/share/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv8/") ]
>
> which is in agreement with your comments.
Indeed, the GAP patch debian/patches/program-path adds
/usr/share/gap/pkg/guava/bin/ to this list.
> However only the last dir[ectory] may work on muti-architecture boxes.
> Here we would need a "/usr/share/gap/pkg/guava/bin/ between the
> two current ones:
> can gap support this ?
GAP does not have the notion of the Debian triplet, so it is difficult to write
a patch
to add /usr/share/gap/pkg/guava/bin/$(DEBIAN_TRIPLET)/
There is a single /usr/bin for all archs, so in particular a single
/usr/bin/gap,
so I do not see why we need to support several /usr/share/gap/pkg/guava/bin,
especially since mismatched gap-core and gap-guava-bin should work.
> Meanwhile (before reading your report) I gave a new try by imposing gap >=
> 4.12 .
This is not sufficient, because it will break again when kv9 happens, for no
reason.
Without this bug, gap would be in testing today.
My only way out is to reupload gap with Breaks: gap-guava-bin (<= 3.17+ds-2),
which will waste 5 days.
Also this is an artificial dependency ( guava only requires >= 4.8.0) that will
make
upgrades more complex, again for no reason.
Cheers,
--
Bill.
Imagine a large red swirl here.
Bug#1020456: cypari2 FTBFS with PARI 2.15.0
On Fri, Oct 28, 2022 at 07:26:09PM +, Tobias Hansen wrote: > Thanks! I will apply the patch once the pari version with the other fixes is > uploaded. Great! I uploaded it today (pari 2.15.1~pre1-1). I hope it will be OK. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
Package: gap-guava-bin Version: 3.17+ds-2 Severity: normal Dear Debian Science Maintainers, gap-guava-bin includes the directory /usr/lib/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv7 but does not depend on gap-kernel-7. 1) As far as I can see, the guava binaries are not linked against the gap-kernel so are independent of it, so the binaries should just go to /usr/lib/gap/pkg/guava/bin/ 2) the new gap kernel 4.12 is gap-kernel-8 and will not find binaries in x86_64-pc-linux-gnu-default64-kv7 3) if for some reason, you really need x86_64-pc-linux-gnu-default64-kvN, you need to depend on gap-kernel-N. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1023071: please bump gap-kernel-7 to gap-kernel-8
Package: gap-io Version: 4.7.0+ds-2 Severity: important Dear Debian Science team, gap-io depends on gap-kernel-7. This need to be bumped to gap-kernel-8 and rebuild, to work with gap 4.12. Idem for gap-float Thanks in advance, -- Bill. Imagine a large red swirl here.
Bug#1020456: cypari2 FTBFS with PARI 2.15.0
On Wed, Oct 05, 2022 at 10:41:58PM +0200, Bill Allombert wrote:
> On Wed, Sep 21, 2022 at 11:57:40PM +0300, Adrian Bunk wrote:
> > Testing cypari2.gen
> > **
> > File
> > "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
> > line ?, in cypari2.gen.Gen.__complex__
> > Failed example:
> > complex(g)
> > Differences (ndiff with -expected +actual):
> > - (2.2847006554165614+0j)
> > + (1.118033988749895+0j)
> > **
> > File
> > "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
> > line ?, in cypari2.gen.__test__.Gen.__complex__ (line 2006)
> > Failed example:
> > complex(g)
> > Differences (ndiff with -expected +actual):
> > - (2.2847006554165614+0j)
> > + (1.118033988749895+0j)
> > **
> > 2 items had failures:
> >1 of 13 in cypari2.gen.Gen.__complex__
> >1 of 13 in cypari2.gen.__test__.Gen.__complex__ (line 2006)
>
> This one is a bug in PARI/GP, that has been fixed in master.
> Once we get to the point it is the only remaining show stopper, I will
> update PARI/GP in sid.
Also I consider the error message change
- PariError: call_python: forbidden multiplication t_VEC (1 elts) * t_VEC
(1 elts)
+ PariError: call_python: incorrect type in qfbcomp (t_VEC)
to be a bug in PARI/GP that I will fix too.
For the others, I join a patch.
Cheers,
--
Bill.
Imagine a large red swirl here.
Index: cypari2-2.1.2/cypari2/handle_error.pyx
===
--- cypari2-2.1.2.orig/cypari2/handle_error.pyx
+++ cypari2-2.1.2/cypari2/handle_error.pyx
@@ -123,7 +123,7 @@ class PariError(RuntimeError):
>>> pari('!@#$%^&*()')
Traceback (most recent call last):
...
-PariError: syntax error, unexpected $undefined
+PariError: syntax error, unexpected invalid token
"""
return self.errtext().rstrip(" .:")
Index: cypari2-2.1.2/cypari2/pari_instance.pyx
===
--- cypari2-2.1.2.orig/cypari2/pari_instance.pyx
+++ cypari2-2.1.2/cypari2/pari_instance.pyx
@@ -1325,9 +1325,9 @@ cdef class Pari(Pari_auto):
>>> pari = cypari2.Pari()
>>> x = pari('x')
>>> pari.genus2red([-5*x**5, x**3 - 2*x**2 - 2*x + 1])
-[1416875, [2, -1; 5, 4; 2267, 1], x^6 - 240*x^4 - 2550*x^3 - 11400*x^2
- 24100*x - 19855, [[2, [2, [Mod(1, 2)]], []], [5, [1, []], ["[V] page 156",
[3]]], [2267, [2, [Mod(432, 2267)]], ["[I{1-0-0}] page 170", []
+[1416875, [2, -1; 5, 4; 2267, 1], [-6*x^5 + 2*x^3 - x, x^3 + 1], [[2,
[2, [Mod(1, 2)]], []], [5, [1, []], ["[V] page 156", [3]]], [2267, [2,
[Mod(432, 2267)]], ["[I{1-0-0}] page 170", []
>>> pari.genus2red([-5*x**5, x**3 - 2*x**2 - 2*x + 1],2267)
-[2267, Mat([2267, 1]), x^6 - 24*x^5 + 10*x^3 - 4*x + 1, [2267, [2,
[Mod(432, 2267)]], ["[I{1-0-0}] page 170", [
+[2267, Mat([2267, 1]), [-6*x^5 + 2*x^3 - x, x^3 + 1], [2267, [2,
[Mod(432, 2267)]], ["[I{1-0-0}] page 170", [
"""
cdef Gen t0 = objtogen(P)
if p is None:
Bug#1020436: giac FTBFS with PARI 2.15.0
On Wed, Oct 19, 2022 at 09:27:23AM +, Tobias Hansen wrote: > I tried rebuilding with this patch from sagemath: Thanks! > |diff --git a/src/pari.cc b/src/pari.cc index 76ce8e1..50d08ab 100644 --- > a/src/pari.cc +++ b/src/pari.cc @@ -40,6 +40,13 @@ using namespace std; > #ifdef HAVE_LIBPARI +// Anyarg disappeared from PARI 2.15.0 +#ifdef > __cplusplus +# define ANYARG ... +#else +# define ANYARG +#endif + #ifdef > HAVE_PTHREAD_H #include #endif| > > > *** the thread stack overflows ! > current stack size: 1024000 (0.977 Mbytes) > [hint] set 'threadsizemax' to a nonzero value in your GPRC > *** matdet: Warning: increasing stack size to 2048000. > *** at top-level: matdet([-10,-7,6,-7,1,4,-1,-2,-2,-5,1,7,-6,7,- > *** ^-- > *** matdet: the thread stack overflows ! > current stack size: 1024000 (0.977 Mbytes) > [hint] set 'threadsizemax' to a nonzero value in your GPRC Probably you just need to increase threadsize or parisize, 1024000 is very small. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0
On Mon, Oct 17, 2022 at 08:44:52AM +, Tobias Hansen wrote: > Control: block -1 by 1020436 1020456 > > Before sagemath can be fixed, cypari2 and giac have to be built against pari > 2.15. OK, is there someone taking care of giac ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1020456: cypari2 FTBFS with PARI 2.15.0
On Wed, Sep 21, 2022 at 11:57:40PM +0300, Adrian Bunk wrote: > Testing cypari2.gen > ** > File > "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so", > line ?, in cypari2.gen.Gen.__complex__ > Failed example: > complex(g) > Differences (ndiff with -expected +actual): > - (2.2847006554165614+0j) > + (1.118033988749895+0j) > ** > File > "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so", > line ?, in cypari2.gen.__test__.Gen.__complex__ (line 2006) > Failed example: > complex(g) > Differences (ndiff with -expected +actual): > - (2.2847006554165614+0j) > + (1.118033988749895+0j) > ** > 2 items had failures: >1 of 13 in cypari2.gen.Gen.__complex__ >1 of 13 in cypari2.gen.__test__.Gen.__complex__ (line 2006) This one is a bug in PARI/GP, that has been fixed in master. Once we get to the point it is the only remaining show stopper, I will update PARI/GP in sid. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1020436: giac FTBFS with PARI 2.15.0
On Wed, Sep 21, 2022 at 09:01:51PM +0300, Adrian Bunk wrote: > Source: giac > Version: 1.9.0.19+dfsg2-1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/logs.php?pkg=giac=1.9.0.19%2Bdfsg2-1%2Bb1 > > ... > pari.cc: At global scope: > pari.cc:752:17: error: typedef ‘giac::PFGEN’ is initialized (use ‘decltype’ > instead) > 752 | typedef GEN (*PFGEN)(ANYARG); > | ^ > pari.cc:752:24: error: ‘ANYARG’ was not declared in this scope This is my comment on this bug: PARI used to define ANYARG as #ifdef __cplusplus # define ANYARG ... #else # define ANYARG #endif This definition was removed because newer gcc/clang do not like to call function without prototype and it was not particularly useful. So you can replace this by typedef GEN (*PFGEN)(); if you like, but recent gcc 12 will issue warning. In PARI we changed EVAL_f to cast the pointer to the right prototype before calling it. Sorry for the trouble. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1020456: cypari2 FTBFS with PARI 2.15.0
On Wed, Sep 21, 2022 at 11:57:40PM +0300, Adrian Bunk wrote:
> Source: cypari2
> Version: 2.1.2-2
> Severity: serious
> Tags: ftbfs bookworm sid
>
> https://buildd.debian.org/status/logs.php?pkg=cypari2=2.1.2-2%2Bb3
>
> Differences (ndiff with -expected +actual):
> Traceback (most recent call last):
> - ...
> - PariError: call_python: forbidden multiplication t_VEC (1 elts) * t_VEC
> (1 elts)
> + File "/usr/lib/python3.10/doctest.py", line 1350, in __run
> + exec(compile(example.source, filename, "single",
> + File " 145)[18]>", line 1, in
> + mul([1], [2])
> + File "cypari2/gen.pyx", line 4107, in cypari2.gen.Gen.__call__
> + sig_on()
> + File "cypari2/handle_error.pyx", line 213, in
> cypari2.handle_error._pari_err_handle
> + raise PariError(errnum, pari_error_string, clone_gen_noclear(E))
> + PariError: call_python: incorrect type in qfbcomp (t_VEC)
a
Some explanation for the failure.
PARI has merged t_QFI and t_QFR to a new type t_QFB. This explains this error.
This might requires some actual fix in cpari2.
> **
> File
> "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/closure.cpython-310-x86_64-linux-gnu.so",
> line ?, in cypari2.closure.objtoclosure
> Failed example:
> mul([1], [2])
> Differences (ndiff with -expected +actual):
> Traceback (most recent call last):
> - ...
> - PariError: call_python: forbidden multiplication t_VEC (1 elts) * t_VEC
> (1 elts)
> + File "/usr/lib/python3.10/doctest.py", line 1350, in __run
> + exec(compile(example.source, filename, "single",
> + File "", line 1, in
> + mul([1], [2])
> + File "cypari2/gen.pyx", line 4107, in cypari2.gen.Gen.__call__
> + sig_on()
> + File "cypari2/handle_error.pyx", line 213, in
> cypari2.handle_error._pari_err_handle
> + raise PariError(errnum, pari_error_string, clone_gen_noclear(E))
> + PariError: call_python: incorrect type in qfbcomp (t_VEC)
Idem
> **
> 2 items had failures:
>1 of 19 in cypari2.closure.__test__.objtoclosure (line 145)
>1 of 19 in cypari2.closure.objtoclosure
> ***Test Failed*** 2 failures.
>
> Testing cypari2.convert
>
> Testing cypari2.gen
> **
> File
> "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
> line ?, in cypari2.gen.Gen.__complex__
> Failed example:
> complex(g)
> Differences (ndiff with -expected +actual):
> - (2.2847006554165614+0j)
> + (1.118033988749895+0j)
> **
> File
> "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
> line ?, in cypari2.gen.__test__.Gen.__complex__ (line 2006)
> Failed example:
> complex(g)
> Differences (ndiff with -expected +actual):
> - (2.2847006554165614+0j)
> + (1.118033988749895+0j)
> **
> 2 items had failures:
>1 of 13 in cypari2.gen.Gen.__complex__
>1 of 13 in cypari2.gen.__test__.Gen.__complex__ (line 2006)
> ***Test Failed*** 2 failures.
>
> Testing cypari2.handle_error
> **
> File
> "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/handle_error.cpython-310-x86_64-linux-gnu.so",
> line ?, in cypari2.handle_error.__test__.PariError.__str__ (line 104)
> Failed example:
> pari('!@#$%^&*()')
> Differences (ndiff with -expected +actual):
> Traceback (most recent call last):
> - ...
> + File "/usr/lib/python3.10/doctest.py", line 1350, in __run
> + exec(compile(example.source, filename, "single",
> + File " 104)[3]>", line 1, in
> + pari('!@#$%^&*()')
> + File "cypari2/pari_instance.pyx", line 832, in
> cypari2.pari_instance.Pari.__call__
> + cdef Gen g = objtogen(s)
> + File "cypari2/gen.pyx", line 4810, in cypari2.gen.objtogen
> + cdef GEN g = PyObject_AsGEN(s)
> + File "cypari2/convert.pyx", line 557, in
> cypari2.convert.PyObject_AsGEN
> + sig_on()
> + File "cypari2/handle_error.pyx", line 213, in
> cypari2.handle_error._pari_err_handle
> + raise PariError(errnum, pari_error_string, clone_gen_noclear(E))
> - PariError: syntax error, unexpected $undefined
> ? -- ^
> + PariError: syntax error, unexpected invalid token
> ? + ^
This is actually a
