Bug#1084226: svg support does not work
On Mon, Oct 07, 2024 at 09:05:24AM +0200, Rafael Laboissière wrote: > Control: tags -1 + confirmed upstream > > * Bill Allombert [2024-10-06 22:52]: > > > fim does not seem to be able to display SVG even with inkscape > > installed, even while it works when doing inkscape logo.svg > > --export-filename=- --export-type=png | fim -i > > This happens because fim is still using (in file src/FbiStuff.cpp) the old > export-related cli option "--export-png". This option does not work with > inkscape >= 1.0, which is the case in Debian since bullseye. Also fim has a comment 'inkscape doesn't export to stdout ' which is no more the case as my example show. This might allow to simplify the code. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1084226: svg support does not work
Package: fim Version: 0.7.1 Severity: normal Hello Michele, fim does not seem to be able to display SVG even with inkscape installed, even while it works when doing inkscape logo.svg --export-filename=- --export-type=png | fim -i It would be nice if fim would support cairosvg in addition to inkscape for displaying SVG. cairosvg does not require X11. Also the package should probably Suggests inkscape. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1027776: mlucas: FTBFS on arm64: fermat-number feature known broken on arm64
On Mon, Jan 02, 2023 at 10:57:35PM -0800, Steve Langasek wrote: > Package: mlucas > Version: 20.1.1-1 > Severity: serious > Tags: patch > Justification: FTBFS > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu lunar ubuntu-patch > > Hi Alex, > > In addition to bug #1014547 causing mlucas to fail to build on all arm > architectures, after working around this bug the package still fails to > build on arm64 where it successfully built before. This is because the > arm64 SIMD implementation is known buggy with respect to the fermat number > feature - there is an assert in the code that causes test/fermat-test to > fail immediately: > > [...] > ERROR: at line 1150 of file upstream/src/Mlucas.c > Assertion failed: ARMv8 SIMD builds do not support Fermat-number testing! > [...] > > (https://launchpad.net/ubuntu/+source/mlucas/20.1.1-1ubuntu1/+build/24577469) > > The previous version of mlucas was removed from testing because it depends > on python2 which has been removed, so the only options here are either to > have the ftp team remove the arm64 binary, or to ignore the test failure. > > In Ubuntu, I have done the latter by applying the attached patch. I applied this patch but now I wonder: if the SIMD binary does not work, surely we should remove it rather than not test it ? Or at least run the other tests ? Cheers, Bill.
Bug#1084045: mlucas: FTBFS: /bin/bash: line 6: 190871 Segmentation fault ${dir}$tst - FAIL: tests/self-test
On Sat, Oct 05, 2024 at 01:50:14AM +0200, Santiago Vila wrote: > El 4/10/24 a las 20:37, Bill Allombert escribió: > > > The test suite works with 3th generation AMD EPYC processorss, > > > but fails with 4th generation. > > > > Ah! Does the VM set /proc/cpuinfo correctly ? > > I don't know. Is there an easy way to check that "/proc/cpuinfo is correct"? > > > Some years ago, I have seen problem when VM advertised support for CPU > > features. > > that where not actually supported. > > That would be certainly surprising from AWS, I would suppose they have > good engineers for such things. But that make them dangerous :) > On a c7a.large instance (EPYC 4th generation), the first one exits with > exit status 0, but then: "mlucas -s m" segfaults, and creates a core > which I've just put here in case it helps: > > https://people.debian.org/~sanvila/build-logs/mlucas/core.gz > > (gdb says "Core was generated by `/usr/libexec/mlucas/mlucas-avx512 -s m'") > > (Beware: It's 956 MB big when uncompressed). I get a 403 error, I suppose you need to use chmod. But maybe we should skip trying to debug mlucas-avx512 and just remove it. %wget 'https://people.debian.org/~sanvila/build-logs/mlucas/core.gz' --2024-10-05 10:43:18-- https://people.debian.org/~sanvila/build-logs/mlucas/core.gz Résolution de people.debian.org (people.debian.org)… 2607:f8f0:614:1::1274:67, 209.87.16.67 Connexion à people.debian.org (people.debian.org)|2607:f8f0:614:1::1274:67|:443… connecté. requête HTTP transmise, en attente de la réponse… 403 Forbidden 2024-10-05 10:43:19 erreur 403 : Forbidden. > I attach the contents of /proc/cpuinfo for the c6a.large and c7a.large > instances. So the Epyc 3 does not implement AVX512 but Epyc 4 does, as expected. > > Maybe one of those is broken and I can just remove it. > > (I already disabled sse2 on i386 due to crashes) > > Looks reasonable, since this is also a crash. Before I do that, could you check that /usr/libexec/mlucas/mlucas-avx2 actually pass the test-suite on epyc 4, just to be sure ? Then I make a 3rd NMU without mlucas-avx512. Thanks for all you work on this! Bill.
Bug#1083071: popularity-contest: runs twice
On Tue, Oct 01, 2024 at 12:45:13AM +0200, Thorsten Glaser wrote: > Package: popularity-contest > Version: 1.76 > Severity: normal > X-Debbugs-Cc: t...@mirbsd.de > > -rw-r--r-- 1 root root 21239 Sep 26 11:06 popularity-contest > -rw-r--r-- 1 root root 21260 Sep 26 06:25 popularity-contest.0 > -rw-r--r-- 1 root root 4875 Sep 19 11:06 popularity-contest.1.gz > -rw-r--r-- 1 root root 4883 Sep 19 06:25 popularity-contest.2.gz > -rw-r--r-- 1 root root 4864 Sep 12 11:06 popularity-contest.3.gz > -rw-r--r-- 1 root root 4893 Sep 12 06:25 popularity-contest.4.gz > -rw-r--r-- 1 root root 4878 Sep 5 11:06 popularity-contest.5.gz > -rw-r--r-- 1 root root 4871 Sep 5 06:25 popularity-contest.6.gz This is more or less intended... There are two cron jobs, one weekly and one daily. The weekly run predictably when the sysadmin has configured daily cronjob to run (6:25 by default). The daily run actually at a random time of the week. Normally if the daily succeed, then the weekly is skipped, but there is a tolerance if the daily is more than 6.5 days old, then the weekly is run anyway, so yes it will run twice in that case. You can check the detail in /etc/cron.daily/popularity-contest: if [ "$MODE" != "--crond" ] || ( [ "$DAY" ] && [ "$DAY" != "$(date +%w)" ] ) ; then # Ensure that popcon runs at least once in the last week if [ -f "$POPCONOLD" ] ; then now=$(date +%s) lastrun=$(last_sub) if [ "$MODE" = "--crond" ]; then # 7.5 days, in seconds week=648000 else # 6.5 days, in seconds week=561600 fi if [ "$(( $now - $lastrun ))" -le "$week" ]; then exit 0 fi fi fi Cheers, Bill
Bug#1079842: Should debbugs be removed from unstable?
On Sun, Sep 22, 2024 at 10:56:05AM +0200, Bill Allombert wrote: > On Sat, Sep 21, 2024 at 04:08:58PM -0700, Don Armstrong wrote: > > On Fri, 20 Sep 2024, Bill Allombert wrote: > > > On Mon, Sep 02, 2024 at 09:34:08AM -0700, Don Armstrong wrote: > > > > Control: severity -1 normal > > > > > > > > On Wed, 28 Aug 2024, Helmut Grohne wrote: > > > > > In case the package should be kept in unstable, please evaluate each > > > > > of the > > > > > RC-bugs listed above. > > > > > > > > The existing RC bugs are correct, and keeping this package in unstable > > > > is useful because it tracks issues which are specific to the debbugs > > > > tool as opposed to bugs.debian.org. > > > > > > I would favor this package to be removed from unstable. Then I could > > > issue an ITP > > > for it and maintain it as a non-native package with the debbugs team as > > > upstream. > > > > If you're up to maintain the packaging, I'd prefer to have you part of > > the debbugs team rather than you have to go through that rigamarole. > > > > Let me know what you'd like to do. > > Sorry, I drafted an answer and then I realized I might have misunderstood you. > Are you offering me to join the debbugs team ? > > Whether or not I join the debbugs team, I would like maintaining the package > as > non native, and I need a clear mandate that allows me to upload it whenever > I want. In any case, please decide either to commit to maintain this package or to let me do it before it is too late for the freeze. Bug #477182 is 16 years old now. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1084045: mlucas: FTBFS: /bin/bash: line 6: 190871 Segmentation fault ${dir}$tst - FAIL: tests/self-test
On Fri, Oct 04, 2024 at 08:05:31PM +0200, Santiago Vila wrote: > Ok, after some tests this is what seems to happen: > > The test suite works with 3th generation AMD EPYC processorss, > but fails with 4th generation. Ah! Does the VM set /proc/cpuinfo correctly ? Some years ago, I have seen problem when VM advertised support for CPU features. that where not actually supported. > > What you can do is to install the package in testing and do > > > > mlucas -fftlen 1024 -radset 4 -f 24 -iters 1000 > > mlucas -s m > > mlucas -fftlen 192 -iters 100 -radset 0 > > Thanks for the hint! > > I confirm that the second line (mlucas -s m) makes the SEGV to show. > > I think this (a test suite which segfaults) should never happen, > so I would just disable the offending line (not the whole test suite). /usr/bin/mlucas is actually a shellscript that try the various binaries in /usr/libexec/mlucas/ until it find one that works on the machine. by doing /usr/libexec/mlucas/mlucas-avx512 -fftlen 192 -iters 100 -radset 0 /usr/libexec/mlucas/mlucas-avx2 -fftlen 192 -iters 100 -radset 0 /usr/libexec/mlucas/mlucas-avx -fftlen 192 -iters 100 -radset 0 /usr/libexec/mlucas/mlucas-sse2 -fftlen 192 -iters 100 -radset 0 ... until this succeeds. Could you tell me what you get on epyc 3 and epyc 4 ? Maybe one of those is broken and I can just remove it. (I already disabled sse2 on i386 due to crashes) Cheers, -- Bill. Imagine a large red swirl here.
Bug#1084045: mlucas: FTBFS: /bin/bash: line 6: 190871 Segmentation fault ${dir}$tst - FAIL: tests/self-test
On Fri, Oct 04, 2024 at 06:31:09PM +0200, Bill Allombert wrote: > Hello Santiago, > > The package build on my laptop, on barriere.debian.org and on the > Debian buildd, so it is fair to say that I cannot reproduce this bug. > > Does it FTFBS also on the real hardware ? > > > Note: I tried 100 times, on 25 different AWS instances, and it failed 100 > > times. > > (These days I'm using instances of type c7a, m7a, and r7a, all of which have > > AMD CPUs). I suspect that this could be due to Intel/AMD differences, but if > > that's the case, it would be actually concerning, as it would mean the > > package > > could not work properly on AMD machines. I'd like to believe that we are not > > lowering support for AMD just because our autobuilders run Intel. > > The package can be built! It is only the test-suite that fail on AMD. What you can do is to install the package in testing and do mlucas -fftlen 1024 -radset 4 -f 24 -iters 1000 mlucas -s m mlucas -fftlen 192 -iters 100 -radset 0 (which is what the tests do) and see if this triggers a SEGV. Thanks ! Cheers, -- Bill. Imagine a large red swirl here.
Bug#1084045: mlucas: FTBFS: /bin/bash: line 6: 190871 Segmentation fault ${dir}$tst - FAIL: tests/self-test
On Fri, Oct 04, 2024 at 02:59:06PM +0200, Santiago Vila wrote:
> Package: src:mlucas
> Version: 20.1.1-1.2
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> (I'm adding Bill to X-debbugs-Cc, since he did the last NMU)
Thanks!
> During a rebuild of all packages in unstable, your package failed to build:
>
> NTHREADS = 1
> Setting ITERS_BETWEEN_CHECKPOINTS = 1.
> INFO: Maximum recommended exponent for FFT length (3840 Kdbl) = 73244853; p[
> = 72123137]/pmax_rec = 0.9846853949.
> Initial DWT-multipliers chain length = [short] in carry step.
> M72123137: using FFT length 3840K = 3932160 8-byte floats, initial residue
> shift count = 38904293
> This gives an average 18.341862233479816 bits per digit
> Using complex FFT radices 240161632
> Using 1 threads in carry step
> /bin/bash: line 6: 190871 Segmentation fault ${dir}$tst
> FAIL: tests/self-test
> 1 of 3 tests failed
> About the archive rebuild: The build was made on virtual machines from AWS,
> using sbuild and a reduced chroot with only build-essential packages.
>
> If you could not reproduce the bug please contact me privately, as I
> am willing to provide ssh access to a virtual machine where the bug is
> fully reproducible.
Hello Santiago,
The package build on my laptop, on barriere.debian.org and on the
Debian buildd, so it is fair to say that I cannot reproduce this bug.
Does it FTFBS also on the real hardware ?
> Note: I tried 100 times, on 25 different AWS instances, and it failed 100
> times.
> (These days I'm using instances of type c7a, m7a, and r7a, all of which have
> AMD CPUs). I suspect that this could be due to Intel/AMD differences, but if
> that's the case, it would be actually concerning, as it would mean the package
> could not work properly on AMD machines. I'd like to believe that we are not
> lowering support for AMD just because our autobuilders run Intel.
The package can be built! It is only the test-suite that fail on AMD.
The alternative to downgrading this bug is not running the test-suite or
removing the package from Debian.
We can also try an new upstream version but there are no garrantee it works
any differently.
> Also, note that there is a segfault in one of the tests. This is also
> concerning as it means we are letting a script which segfaults (for unknown
> reasons) to decide about whether the program is ok or not.
The test-suite check whether the program has been miscompiled and if the host
is reliable.
Cheers,
--
Bill.
Imagine a large red swirl here.
Bug#885698: What licenses should be included in /usr/share/common-licenses?
On Mon, Sep 30, 2024 at 06:41:03PM +0200, Matthias Geiger wrote: > Hi Russ and Sean, > > thanks for for working on this. Just today I worked on a package having > some CC-BY-SA-4.0 licensed content and wasn't too glad at having to copy > the full license. Are there any big blockers for this ? Reading the > previous discussion the techicalities seem to be mostly agreed upon > (unless I missed something ?). I think this would be a big improvement for > packagers. Let me know if > you need help finalizing any discussion to make this policy. I suggested a tool that would copy the full license inside the binary package copyright file at build time. This seems a more sustainable option. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1082916: patch from NMU
On Sat, Sep 28, 2024 at 10:38:24AM +0200, Bill Allombert wrote: > Package: mlucas > Version: 20.1.1-1.1 > Severity: normal > > Hello Alex, this is the patch for the NMU. ... and now for the second one. Cheers, -- Bill. Imagine a large red swirl here. diff -Nru mlucas-20.1.1/debian/changelog mlucas-20.1.1/debian/changelog --- mlucas-20.1.1/debian/changelog 2024-09-27 22:27:58.0 +0200 +++ mlucas-20.1.1/debian/changelog 2024-09-28 17:19:40.0 +0200 @@ -1,3 +1,12 @@ +mlucas (20.1.1-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control: + - Set Architecture to any. + * debian/rules: disable sse2 on i386 + + -- Bill Allombert Sat, 28 Sep 2024 17:19:40 +0200 + mlucas (20.1.1-1.1) unstable; urgency=medium * Non-maintainer upload. (Closes: #1080048) diff -Nru mlucas-20.1.1/debian/rules mlucas-20.1.1/debian/rules --- mlucas-20.1.1/debian/rules 2024-09-26 15:08:32.0 +0200 +++ mlucas-20.1.1/debian/rules 2024-09-28 17:19:40.0 +0200 @@ -26,7 +26,11 @@ dh_autoreconf ./bootstrap override_dh_auto_configure: - dh_auto_configure -- --enable-mlucas-default-path +ifeq ($(DEB_TARGET_ARCH), i386) + dh_auto_configure -- --enable-mlucas-default-path --enable-builds=generic-c +else + dh_auto_configure -- --enable-mlucas-default-path +endif override_dh_auto_test: ifeq ($(DEB_HOST_ARCH), arm64)
Bug#1082916: patch from NMU
Package: mlucas
Version: 20.1.1-1.1
Severity: normal
Hello Alex, this is the patch for the NMU.
Cheers,
--
Bill.
Imagine a large red swirl here.
diff -Nru mlucas-20.1.1/debian/changelog mlucas-20.1.1/debian/changelog
--- mlucas-20.1.1/debian/changelog 2021-12-21 00:07:38.0 +0100
+++ mlucas-20.1.1/debian/changelog 2024-09-27 22:27:58.0 +0200
@@ -1,3 +1,18 @@
+mlucas (20.1.1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload. (Closes: #1080048)
+Mlucas author, Mr Ernst Mayer, sadly passed away in 2023,
+see <https://www.mersenneforum.org/node/22279?t=28890>
+He will be missed. Consider this package as a tribute to him.
+ * New patch fopen-on-arm.patch from Steve Langasek (Closes: #1014547)
+ * debian/control:
+- Fix maintainer address. (Closes: #1013910)
+ * debian/rules:
+- Apply patch from Steve Langasek (Closes: #1027776)
+- build with -Wno-incompatible-pointer-types (Closes: #1081082)
+
+ -- Bill Allombert Fri, 27 Sep 2024 22:27:58 +0200
+
mlucas (20.1.1-1) unstable; urgency=medium
* New upstream release.
diff -Nru mlucas-20.1.1/debian/control mlucas-20.1.1/debian/control
--- mlucas-20.1.1/debian/control2021-12-21 00:07:38.0 +0100
+++ mlucas-20.1.1/debian/control2024-09-27 22:02:29.0 +0200
@@ -1,7 +1,7 @@
Source: mlucas
Section: math
Priority: optional
-Maintainer: Alex Vong
+Maintainer: Alex Vong
Build-Depends: debhelper-compat (= 13), libgmp-dev
Rules-Requires-Root: no
Standards-Version: 4.6.0.1
diff -Nru mlucas-20.1.1/debian/patches/fopen-on-arm.patch
mlucas-20.1.1/debian/patches/fopen-on-arm.patch
--- mlucas-20.1.1/debian/patches/fopen-on-arm.patch 1970-01-01
01:00:00.0 +0100
+++ mlucas-20.1.1/debian/patches/fopen-on-arm.patch 2024-09-26
22:40:39.0 +0200
@@ -0,0 +1,22 @@
+Description: don't use mlucas_fopen() for system files
+ mlucas_fopen() is a wrapper around fopen() that rewrites the path in
+ various cases. It is not an appropriate interface for opening system
+ files like /proc/cpuinfo, and causes the mlucas binary to be completely
+ broken on ARM architectures.
+Author: Steve Langasek
+Forwarded: no
+Last-Update: 2022-07-07
+
+Index: mlucas-20.1.1/upstream/src/util.c
+===
+--- mlucas-20.1.1.orig/upstream/src/util.c
mlucas-20.1.1/upstream/src/util.c
+@@ -1909,7 +1909,7 @@
+ int has_asimd(void)
+ {
+ char in_line[STR_MAX_LEN];
+- FILE*fp = mlucas_fopen("/proc/cpuinfo", "r");
++ FILE*fp = fopen("/proc/cpuinfo", "r");
+ ASSERT(HERE, fp != 0x0, "/proc/cpuinfo file not found!");
+ while(fgets(in_line, STR_MAX_LEN, fp) != 0x0) {
+ if(strstr(in_line, "asimd") != 0)
diff -Nru mlucas-20.1.1/debian/patches/series
mlucas-20.1.1/debian/patches/series
--- mlucas-20.1.1/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ mlucas-20.1.1/debian/patches/series 2024-09-26 22:40:39.0 +0200
@@ -0,0 +1 @@
+fopen-on-arm.patch
diff -Nru mlucas-20.1.1/debian/rules mlucas-20.1.1/debian/rules
--- mlucas-20.1.1/debian/rules 2021-12-21 00:07:38.0 +0100
+++ mlucas-20.1.1/debian/rules 2024-09-26 15:08:32.0 +0200
@@ -13,6 +13,9 @@
# configure script detects optimization and debbuging flags automatically
export DEB_CFLAGS_MAINT_STRIP = -O2 -g
+DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
+
+CFLAGS += -Wno-incompatible-pointer-types
# main packaging script based on dh7 syntax
%:
@@ -24,3 +27,10 @@
override_dh_auto_configure:
dh_auto_configure -- --enable-mlucas-default-path
+
+override_dh_auto_test:
+ifeq ($(DEB_HOST_ARCH), arm64)
+ dh_auto_test || true
+else
+ dh_auto_test
+endif
Bug#1081082: mlucas: FTBFS: upstream/src/radix144_main_carry_loop.h:144:29: error: assignment to ‘vec_dbl *’ {aka ‘struct double_x4 *’} from incompatible pointer type ‘vec_dbl **’ {aka ‘struct double_
On Sun, Sep 08, 2024 at 01:52:58AM +0200, Santiago Vila wrote:
> Package: src:mlucas
> Version: 20.1.1-1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to build:
>
>
> [...]
> debian/rules binary
In file included from upstream/src/radix144_ditN_cy_dif1.c:2236:
> upstream/src/radix144_main_carry_loop.h: In function ‘cy144_process_chunk’:
> upstream/src/radix144_main_carry_loop.h:144:29: error: assignment to ‘vec_dbl
> *’ {aka ‘struct double_x4 *’} from incompatible pointer type ‘vec_dbl **’
> {aka ‘struct double_x4 **’} [-Wincompatible-pointer-types]
> 144 | tm1 = rad9_iptr;// Stash
> head-of-array-ptrs in tmps to workaround GCC's "not directly addressable"
> macro arglist stupidity
> | ^
> upstream/src/radix144_main_carry_loop.h:145:29: error: assignment to ‘vec_dbl
> *’ {aka ‘struct double_x4 *’} from incompatible pointer type ‘vec_dbl **’
> {aka ‘struct double_x4 **’} [-Wincompatible-pointer-types]
> 145 | tm2 = rad9_optr;
> | ^
> upstream/src/radix144_main_carry_loop.h:634:29: error: assignment to ‘vec_dbl
> *’ {aka ‘struct double_x4 *’} from incompatible pointer type ‘vec_dbl **’
> {aka ‘struct double_x4 **’} [-Wincompatible-pointer-types]
> 634 | tm0 = rad9_iptr;// Can't use tm1 here
> since use that for s1p00 offsets in loop body
> | ^
> upstream/src/radix144_main_carry_loop.h:635:29: error: assignment to ‘vec_dbl
> *’ {aka ‘struct double_x4 *’} from incompatible pointer type ‘vec_dbl **’
> {aka ‘struct double_x4 **’} [-Wincompatible-pointer-types]
> 635 | tm2 = rad9_optr;// Stash
> head-of-array-ptrs in tmps to workaround GCC's "not directly addressable"
> macro arglist stupidity
> | ^
> make[1]: *** [Makefile:8486:
> upstream/src/mlucas_avx2-radix144_ditN_cy_dif1.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory '/<>'
> dh_auto_build: error: make -j2 returned exit code 2
> make: *** [debian/rules:19: binary] Error 25
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status
> 2
Hello,
The package build successfully by setting CFLAGS =
-Wno-incompatible-pointer-types
Cheers,
--
Bill.
Imagine a large red swirl here.
Bug#1082757: xlt: New upstream version 0.7.7
Source: xtl Version: 0.7.5-3 Severity: wishlist Hello Vincent, the current upstream version is 0.7.7. Do you have plans to upgrade ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1079842: Should debbugs be removed from unstable?
On Sat, Sep 21, 2024 at 04:08:58PM -0700, Don Armstrong wrote: > On Fri, 20 Sep 2024, Bill Allombert wrote: > > On Mon, Sep 02, 2024 at 09:34:08AM -0700, Don Armstrong wrote: > > > Control: severity -1 normal > > > > > > On Wed, 28 Aug 2024, Helmut Grohne wrote: > > > > In case the package should be kept in unstable, please evaluate each of > > > > the > > > > RC-bugs listed above. > > > > > > The existing RC bugs are correct, and keeping this package in unstable > > > is useful because it tracks issues which are specific to the debbugs > > > tool as opposed to bugs.debian.org. > > > > I would favor this package to be removed from unstable. Then I could issue > > an ITP > > for it and maintain it as a non-native package with the debbugs team as > > upstream. > > If you're up to maintain the packaging, I'd prefer to have you part of > the debbugs team rather than you have to go through that rigamarole. > > Let me know what you'd like to do. Sorry, I drafted an answer and then I realized I might have misunderstood you. Are you offering me to join the debbugs team ? Whether or not I join the debbugs team, I would like maintaining the package as non native, and I need a clear mandate that allows me to upload it whenever I want. I need the package to be maintained in Debian so I can update it on my server [1]. You always did a great job as upstream, so I always avoided bothering too much about the packaging. However if the package is removed from Debian, there is no reason that I cannot become the Debian maintainer. [1] <https://pari.math.u-bordeaux.fr/Bugs/> Cheers, -- Bill. Imagine a large red swirl here.
Bug#1079842: Should debbugs be removed from unstable?
On Mon, Sep 02, 2024 at 09:34:08AM -0700, Don Armstrong wrote: > Control: severity -1 normal > > On Wed, 28 Aug 2024, Helmut Grohne wrote: > > In case the package should be kept in unstable, please evaluate each of the > > RC-bugs listed above. > > The existing RC bugs are correct, and keeping this package in unstable > is useful because it tracks issues which are specific to the debbugs > tool as opposed to bugs.debian.org. I would favor this package to be removed from unstable. Then I could issue an ITP for it and maintain it as a non-native package with the debbugs team as upstream. Completely severing the package maintainance from the debbugs maintainance is the best option for all involved. There are few debbugs instances outside Debian. I maintain one of them. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1068498: new upstream version 5.1.1
On Sat, Apr 06, 2024 at 02:26:09PM +0200, Bill Allombert wrote: > Source: xeus > Severity: wishlist > > Dear Xeus maintainers, > > There is a new major upstream release available (4.0.2). > Do you plan to package it ? There is yet another major upstream release available (5.1.1). Packaging it does not seem hard, but there will be a transition. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1081886: git-http-backend: security update break common configuration
Package: git Version: 1:2.39.5-0+deb12u1 Severity: important X-Debbugs-Cc: t...@security.debian.org Hi! The last upgrade break common usage of git-backend-server, probably the 'fix' for CVE-2024-32465. git clone https:// does not work anymore >From my apache log: [Sun Sep 15 13:25:25.468431 2024] [core:notice] [pid 1874118:tid 1874118] AH00094: Command line: '/usr/sbin/apache2' fatal: detected dubious ownership in repository at '/home/www/git/unimodular.git' To add an exception for this directory, call: git config --global --add safe.directory /home/www/git/unimodular.git Obviously the git repository is not owned by www-data. At minimum, the debian/changelog should include a mention of the issue and a work-around. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1077843: popularity-contest: Have separate column for "installed but no atime"
On Sat, Aug 03, 2024 at 09:52:47AM +0200, Niels Thykier wrote: > Package: popularity-contest > Version: 1.77 > Severity: wishlist > X-Debbugs-Cc: ni...@thykier.net > > Hi, > > The popularity-contest provides the columns `Inst`, `Vote`, `Old`, `Recent` > and `No Files`. > > I feel it would be interesting to see how many are `Old` because the system > has disabled `atime` on its mount point (either directly or because the > mount point is read-only). For these systems, you can basically never get a > `Vote` - at least you will see a `Recent` as I understand the current logic. Yes, but I do not think this is a major issue, since it is uniform across all packages. For example 36libc6 233754 216998 545 1619714 (Gnu Libc Maintainers) so this affects probably less than 0.5% of submissions. > Therefore, I would like to see popularity-contest track whether the mount > points would ever update its atime (the mount flags I know of that are > relevant are `noatime` or `ro`[1]) when popularity-contest tracks whether it > should count a given file as giving a Vote. So instead of undercounting votes by 0.5%, this would overcount them by 0.5% ? This does not seem to be worth the effort. > I see this proposal as an alternative to #87619 that does not rely on a new > dependency (/etc/mtab, /proc/mounts, or `mount` can all provide the data) #87619 was reported at a time where relatime was not available and noatime was much more popular. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1074783: efax: Log directory moved from /var/log to /var/loog
Package: efax Version: 1:0.9a-22 Severity: normal Dear Maintainer, The upgrade to 1:0.9a-22 resulted in the removal of /var/log/efax and creation of /var/loog and /var/loog/efax. Bill -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.9.7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages efax depends on: ii debconf [debconf-2.0] 1.5.86 ii libc6 2.38-13 ii libpaper-utils 1.1.29+b1 ii make 4.3-4.1 efax recommends no packages. Versions of packages efax suggests: ii imagemagick 8:6.9.13.12+dfsg1-1 ii imagemagick-6.q16 [imagemagick] 8:6.9.13.12+dfsg1-1 ii xloadimage 4.1-25+b3 -- Configuration Files: /etc/efax.rc changed [not included] -- no debconf information
Bug#1052053: popularity-contest: race condition between the two cron jobs
On Sat, Sep 16, 2023 at 06:21:56PM +0200, Alexandre Detiste wrote: > Package: popularity-contest > Version: 1.77 > Severity: normal > > Hi, > > I have been unlucky and the two instance of the cronjob > triggered at the same time, stepping on eachother feets. > > (at the "savelog -c 7 popularity-contest >/dev/null" step precisely) Sorry for the delay in getting back to you. > Can you implement some locking ? I expected savelog would implement locking against itself at least but this is not the case. > Or alternatively #923014 will get you locking for free > on systemd running systems. Would you help me with this ? Do you have spurious logfiles like /var/log/popularity-contest.1010995 /var/log/popularity-contest.1010995.gpg Cheers, -- Bill. Imagine a large red swirl here.
Bug#1069027: Fixed upstreamo
On Fri, May 31, 2024 at 10:56:54AM +0200, Thomas Viehmann wrote: > This is fixed upstream in Jupyter Notebook 6.5.6 per > https://github.com/jupyter/notebook/issues/7054 Will someone from the python team will fix this or should I prepare a minimal NMU with the patch applied ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1069757: BUG#1069757 - upstream bug report submitted
Upstream kafs developers have discussed this bug report. A issue has been created on gitlab, https://gitlab.com/linux-afs/kafs-client/-/issues/2. The upshot of the discussion is that the use of -m32 and -m64 should be conditionalized based on the architecture. Bill -- Man knows so little about his fellows. In his eyes all men or women act upon what he believes would motivate him if he were mad enough to do what that other man or woman is doing. William Faulkner
Bug#1070211: ITP: krb5-wallet -- The wallet system manages secure data. It is build on top of remctl. One of the object types it supports is Kerberos keytabs, making it suitable as a user-accessible
Package: wnpp Severity: wishlist Owner: Bill MacAllister X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: krb5-wallet Version : 1.5 Upstream Contact: Bill MacAllister * URL : https://salsa.debian.org/whm/krb5-wallet * License : (Expat) Programming Lang: (C, Perl) Description : The wallet used remctl to manage secure data. The wallet is a client/server system using a central server with a supporting database and a stand-alone client that can be widely distributed to users. The server runs on a secure host with access to a local database; tracks object metadata such as ACLs, attributes, history, expiration, and ownership; and has the necessary access privileges to create wallet-managed objects in external systems (such as Kerberos service principals). The client uses the remctl protocol to send commands to the server, store and retrieve objects, and query object metadata. The same client can be used for both regular user operations and wallet administrative actions. All wallet actions are controlled by a fine-grained set of ACLs. Each object has an owner ACL and optional get, store, show, destroy, and flags ACLs that control more specific actions. A global administrative ACL controls access to administrative actions. An ACL consists of zero or more entries, each of which is a generic scheme and identifier pair, allowing the ACL system to be extended to use any existing authorization infrastructure. Supported ACL types include Kerberos principal names, regexes matching Kerberos principal names, and LDAP attribute checks. Currently, the object types supported are simple files, passwords, Kerberos keytabs, and Duo integrations. By default, whenever a Kerberos keytab object is retrieved from the wallet, the key is changed in the Kerberos KDC and the wallet returns a keytab for the new key. However, a keytab object can also be configured to preserve the existing keys when retrieved. Included in the wallet distribution is a script that can be run via remctl on an MIT Kerberos KDC to extract the existing key for a principal, and the wallet system will use that interface to retrieve the current key if the unchanging flag is set on a Kerberos keytab object for MIT Kerberos. (Heimdal doesn't require any special support.)
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#1068949: fixed in libfinance-quote-perl 1.60-1
I can confirm that Gnucash can download the YahooJSON quotes again, Thanks very much! Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the libfinance-quote-perl package: > > #1068949: libfinance-quote-perl: Quotes failing in Gnucash > > It has been closed by Debian FTP Masters > (reply to gregor herrmann ). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > (reply to gregor herrmann > ) by > replying to this email. > > > -- > 1068949: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068949 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > --- Forwarded Message > > From: Debian FTP Masters > Reply-To: gregor herrmann > To: 1068949-cl...@bugs.debian.org > X-DAK: dak process-upload > X-Debian: DAK > X-Debian-Package: libfinance-quote-perl > Debian: DAK > Debian-Changes: libfinance-quote-perl_1.60-1_source.changes > Debian-Source: libfinance-quote-perl > Debian-Version: 1.60-1 > Debian-Architecture: source > Debian-Suite: unstable > Debian-Archive-Action: accept > Subject: Bug#1068949: fixed in libfinance-quote-perl 1.60-1 > Date: Tue, 16 Apr 2024 15:49:55 + > > Source: libfinance-quote-perl > Source-Version: 1.60-1 > Done: gregor herrmann > > We believe that the bug you reported is fixed in the latest version of > libfinance-quote-perl, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 1068...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > gregor herrmann (supplier of updated > libfinance-quote-perl package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > Format: 1.8 > Date: Tue, 16 Apr 2024 17:23:22 +0200 > Source: libfinance-quote-perl > Architecture: source > Version: 1.60-1 > Distribution: unstable > Urgency: medium > Maintainer: Debian Perl Group > Changed-By: gregor herrmann > Closes: 1068949 > Changes: > libfinance-quote-perl (1.60-1) unstable; urgency=medium > . >* Import upstream version 1.60. > + Removed modules: Fidelity.pm, Cdbfundlibrary.com, Fundata.pm, >and Fool.pm. > + Fixed modules: YahooJSON.pm (closes: #1068949), Bloomberg.pm, >and NSEIndia.pm >* Install new CONTRIBUTING.pod file. >* Update (test) dependencies. >* Declare compliance with Debian Policy 4.7.0. > Checksums-Sha1: > 4cb96d909b356e08fad328b477357a0cd35c5764 3463 > libfinance-quote-perl_1.60-1.dsc > 113052d15adda5c4b59ff8f4daeae75afd7c760c 267746 > libfinance-quote-perl_1.60.orig.tar.gz > 32bc0cebc8597ef3a46ec41465e7c375f509f7de 7000 > libfinance-quote-perl_1.60-1.debian.tar.xz > Checksums-Sha256: > 23c3e66ed90bfadd21a095ea7b93ed8144d4af592d081cb582e96e6c6ef2b7a9 3463 > libfinance-quote-perl_1.60-1.dsc > 517ad840dbce8737558e7331349fdf6bb2790ca1b57edd237b4f98d5c37e 267746 > libfinance-quote-perl_1.60.orig.tar.gz > b8ae8777eeacc91254e22f1d5681bbc093eae518c842b9dbdfb6c45381e58074 7000 > libfinance-quote-perl_1.60-1.debian.tar.xz > Files: > 84e0aed294beff6aca6834cf5493fa6a 3463 perl optional > libfinance-quote-perl_1.60-1.dsc > ccf54b587f0291e734ec0b2986d0a7b1 267746 perl optional > libfinance-quote-perl_1.60.orig.tar.gz > 8503de0de2f3b85ea334012da21716b4 7000 perl optional > libfinance-quote-perl_1.60-1.debian.tar.xz > > > --- Forwarded Message > > From: Bill Wohler > To: Debian Bug Tracking System > Subject: libfinance-quote-perl: Quotes failing in Gnucash > X-Mailer: reportbug 12.0.0 > Date: Sat, 13 Apr 2024 22:37:31 -0700 > > Package: libfinance-quote-perl > Version: 1.59-1 > Severity: normal > > Dear Maintainer, > > I ran the Tools > Price Database command in Gnucash using the "Yahoo > as JSON" source and got the following response: > > Unable to retrieve quotes for these items. > > In the past, this error was resolved by editing > /usr/share/perl5/Finance/Quote/YahooJSON.pm. However, this time, I > could not find any solutions online. I tried upgrading from version > 1.54 (bookworm) to 1.59 (trixie), bu
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#1068949: libfinance-quote-perl: Quotes failing in Gnucash
Package: libfinance-quote-perl Version: 1.59-1 Severity: normal Dear Maintainer, I ran the Tools > Price Database command in Gnucash using the "Yahoo as JSON" source and got the following response: Unable to retrieve quotes for these items. In the past, this error was resolved by editing /usr/share/perl5/Finance/Quote/YahooJSON.pm. However, this time, I could not find any solutions online. I tried upgrading from version 1.54 (bookworm) to 1.59 (trixie), but that did not resolve the issue either. I hope you can do a better job finding a valid URL for the Yahoo quotes. Alternatively, if you could recommend another, more stable, source for retrieving mutual fund quotes, that would be great too. Thanks! -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (10, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libfinance-quote-perl depends on: ii libcgi-pm-perl 4.55-1 ii libdatetime-format-strptime-perl 1.7900-1 ii libdatetime-perl 2:1.59-1 pn libencode-perl ii libhtml-parser-perl3.81-1 ii libhtml-tableextract-perl 2.15-2 ii libhtml-tokeparser-simple-perl 3.16-4 ii libhtml-tree-perl 5.07-3 ii libhtml-treebuilder-xpath-perl 0.14-1.1 ii libhttp-cookiejar-perl 0.014-1 ii libhttp-cookies-perl 6.10-1 ii libhttp-message-perl 6.44-1 ii libio-string-perl 1.08-4 ii libjson-parse-perl 0.62-1+b1 ii libjson-perl 4.1-1 ii liblwp-protocol-https-perl 6.10-1 ii libreadonly-perl 2.050-3 ii libscalar-list-utils-perl 1:1.63-1+b1 ii libspreadsheet-xlsx-perl 0.17-1 ii libstring-util-perl1.34-2 ii libtext-template-perl 1.61-1 ii libtry-tiny-perl 0.31-2 ii liburi-perl5.17-1 ii libweb-scraper-perl0.38-2 ii libwww-perl6.68-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b1 ii perl [libio-compress-perl] 5.36.0-7+deb12u1 ii perl-base [libscalar-list-utils-perl] 5.36.0-7+deb12u1 libfinance-quote-perl recommends no packages. libfinance-quote-perl suggests no packages. -- no debconf information
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#1066630: Patch to address Debian Bug report #1066630
The following patch results in a clean build. I will work to get the
patch
uploaded. (I am not a Debian Developer)
Index: libnet-ldapapi-perl/Makefile.PL
===
--- libnet-ldapapi-perl.orig/Makefile.PL 2024-03-29 07:00:25.037139644
+
+++ libnet-ldapapi-perl/Makefile.PL 2024-04-02 07:07:21.401195313 +
@@ -124,7 +124,7 @@
'DEFINE'=> '-DMOZILLA_LDAP',
) : (
'LIBS' => ["-L$lib_ldap $ldap_lib"],
- 'DEFINE'=> '-DOPENLDAP',
+ 'DEFINE'=> '-DOPENLDAP -DLDAP_DEPRECATED=1',
)),
'depend'=> { 'LDAPapi.c' => 'constant.h' },
'clean' => { 'FILES' => 'constant.h' },
The patch is from Quanah Gibson-Mount . Thanks.
Bill
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#1066630: Confirming the build problem
This is a confirmed bug. I am working on a solution. Bill
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#1052304: Debian 6.1 Kernels suspect
On 2023-12-14 01:54, Bill MacAllister wrote: This took me longer that I wanted, but I have built kernels the following kernels with the patch: linux-image-6.1.0-15-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-amd64-unsigned_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-cloud-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-cloud-amd64-unsigned_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-rt-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-rt-amd64-unsigned_6.1.66-2~afs1_amd64.deb I have installed linux-image-6.1.0-15-amd64-unsigned_6.1.66-2~afs1_amd64.deb on a couple systems. Things look fine, but the problem is intermittent and I won't be convinced that it is fixed until there are no errors for at least a day. One of the systems uses kafs heavily so I should see any errors fairly quickly. I send an update tomorrow. This patch resolves this bug from my testing. The original bug was not intermittent, and the failure could be forced on demand. My reference to an intermittent problem was to another bug altogether---apologies for the confusion. Bill -- My heart is warm with the friends I make, And better friends I'll not be knowing, Yet there isn't a train I wouldn't take, No matter where it's going. Edna St Vincent Millay
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#1052304: Debian 6.1 Kernels suspect
On 2023-12-09 09:49, Bill MacAllister wrote: On 2023-12-08 15:59, Diederik de Haas wrote: On Saturday, 9 December 2023 00:28:50 CET Jeffrey Altman wrote: The bug is considered valid by upstream. A proposed fix for this issue is being reviewed. http://lists.infradead.org/pipermail/linux-afs/2023-December/007408.html Please leave this issue open until the fix has been back ported into the kernels shipped by Debian. https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4 describes a simple procedure with which one can test patches. I've attached the above referenced patch and verified that it applies (cleanly) onto a 6.1 kernel. Bill: can you test this patch and see if it resolved the issue? Yes, I can test it. Mostly likely I will not get to doing that until Sunday night here in California. For sure Monday morning at the latest. This took me longer that I wanted, but I have built kernels the following kernels with the patch: linux-image-6.1.0-15-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-amd64-unsigned_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-cloud-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-cloud-amd64-unsigned_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-rt-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-rt-amd64-unsigned_6.1.66-2~afs1_amd64.deb I have installed linux-image-6.1.0-15-amd64-unsigned_6.1.66-2~afs1_amd64.deb on a couple systems. Things look fine, but the problem is intermittent and I won't be convinced that it is fixed until there are no errors for at least a day. One of the systems uses kafs heavily so I should see any errors fairly quickly. I send an update tomorrow. Bill -- My heart is warm with the friends I make, And better friends I'll not be knowing, Yet there isn't a train I wouldn't take, No matter where it's going. Edna St Vincent Millay
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#1052304: Debian 6.1 Kernels suspect
On 2023-12-08 15:59, Diederik de Haas wrote: On Saturday, 9 December 2023 00:28:50 CET Jeffrey Altman wrote: The bug is considered valid by upstream. A proposed fix for this issue is being reviewed. http://lists.infradead.org/pipermail/linux-afs/2023-December/007408.html Please leave this issue open until the fix has been back ported into the kernels shipped by Debian. https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4 describes a simple procedure with which one can test patches. I've attached the above referenced patch and verified that it applies (cleanly) onto a 6.1 kernel. Bill: can you test this patch and see if it resolved the issue? Yes, I can test it. Mostly likely I will not get to doing that until Sunday night here in California. For sure Monday morning at the latest. Bill -- My heart is warm with the friends I make, And better friends I'll not be knowing, Yet there isn't a train I wouldn't take, No matter where it's going. Edna St Vincent Millay
Bug#1057416: Acknowledgement (ntpsec: Corrupted filtdelay/filtoffset/filtdisp in peer variables)
It looks like this was fixed upstream earlier this year in this commit: https://gitlab.com/NTPsec/ntpsec/-/commit/9931ebb3d1418b648f80510a86520a4d11bab3d6 The relevant bit is the change to ctl_putarray() to set buffer[0] = 0; It does not appear that this fix has appeared in a release yet. Exposing stack garbage like this runs the hard-to-quantify risk that keying material could be exposed over the network. See also https://gitlab.com/NTPsec/ntpsec/-/issues/806 which is another manifestation of this bug (depending on the stack garbage, it can cause other ntpq subcommands to fail).
Bug#1057416: ntpsec: Corrupted filtdelay/filtoffset/filtdisp in peer variables
Package: ntpsec Version: 1.2.2+dfsg1-1+deb12u1 Severity: important Dear Maintainer, It appears that ntpsec's ntpd returns corrupted values in the "filtdelay", "filtoffset" and "filtdisp" peer variables visible via ntpq. reproducer: $ ntpq ntpq> peers (output elided) ntpq> rv &1 filtdelay filtoffset filtdisp Expected output: three lines of 8 numbers for each variable read, looking something like: filtdelay=17.10 17.20 12.35 14.43 14.71 13.64 14.70 14.46, filtoffset= +3.57 +1.58 +0.39 +0.02 +1.04 +0.59 +0.40 -0.56, filtdisp= 0.00 15.89 31.37 47.39 63.08 78.60 94.13 109.65 Actual output is prefaced with garbage characters and repeated values from the other variables: filtdelay=M- M-W}M-HM-^?^? 0.48 0.48 0.47 0.36 0.48 0.45 0.49 0.37?, filtoffset=M- M-W}M-HM-^?^? 0.48 0.48 0.47 0.36 0.48 0.45 0.49 0.37 -0.52 0.92 1.32 0.93 1.03 0.45 1.02 2.04?, filtdisp=M- M-W}M-HM-^?^? 0.48 0.48 0.47 0.36 0.48 0.45 0.49 0.37 -0.52 0.92 1.32 0.93 1.03 0.45 1.02 2.04 0.00 15.95 31.31 47.42 63.18 78.90 95.03 110.45? Why I think the bug is in ntpd and not in ntpq: I see the expected output for these variables when using ntpsec's ntpq to query another system, and I also see the erroneous output when using that other system's ntpq to query the debian ntpsec ntpd. -- System Information: Debian Release: 12.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ntpsec depends on: ii adduser3.134 ii init-system-helpers1.65.2 ii libbsd00.11.7-2 ii libc6 2.36-9+deb12u3 ii libcap21:2.66-4 ii libssl33.0.11-1~deb12u2 ii lsb-base 11.6 ii netbase6.4 ii python33.11.2-1+b1 ii python3-ntp1.2.2+dfsg1-1+deb12u1 ii sysvinit-utils [lsb-base] 3.06-4 ii tzdata 2023c-5 Versions of packages ntpsec recommends: ii cron [cron-daemon] 3.0pl1-162 ii systemd 252.17-1~deb12u1 Versions of packages ntpsec suggests: ii apparmor 3.0.8-3 pn certbot ii ntpsec-doc 1.2.2+dfsg1-1+deb12u1 pn ntpsec-ntpviz -- Configuration Files: /etc/ntpsec/ntp.conf changed: driftfile /var/lib/ntpsec/ntp.drift statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable restrict -4 default kod notrap nomodify nopeer noquery limited restrict -6 default kod notrap nomodify nopeer noquery limited restrict 127.0.0.1 restrict ::1 restrict source notrap nomodify noquery restrict 192.168.0.0 mask 255.255.0.0 kod notrap nomodify nopeer limited server hydra.hamachi.org iburst server the-governor.hamachi.org iburst server time.cloudflare.com iburst server time.apple.com iburst pool 2.us.pool.ntp.org iburst -- no debconf information
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#1052304: Debian 6.1 Kernels suspect
After more testing Jeff Altman and Marc Dionne have reported that the problem accessing AFS files using kafs does not occur if the client has IPv6 configured. Bill -- "Can't sing louder than the guns when I'm gone, so I guess I'll have to do it while I'm here." Phil Ochs
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#1042082: Please take over udev SysV init script
When upgrading (with aptitude), initscripts (3.08-1) is set up before udev (254.4-1). Udev claims to remove the "obsolete conffile /etc/init.d/udev", but it's still there. However, the rc*.d symlinks are not -- "update-rc.d udev defaults" fixes it. Regards.. Bill
Bug#1052304: Debian 6.1 Kernels suspect
Before I started bisecting the 6.1 kernel I thought I should re-examine the assumption that 6.1.0-9 was a good kernel, i.e. a kernel where accessing AFS volumes using kafs does not cause seg faults. I tested 6.1.0-2, 6.1.0-5, and 6.1.0-7 without success. Bill -- "Can't sing louder than the guns when I'm gone, so I guess I'll have to do it while I'm here." Phil Ochs
Bug#1052304: kafs failure testing
I spent a couple days bisecting kernels attempting to isolate this bug to a specific kernel. What I found was that the simple test that I included in the initial bug report, i.e. ls /afs/ca-zephyr.org, is not sufficient to test for failure. This test can succeed multiple times and then sometime later fail. Which meant that my bisection attempts where pretty much useless. I will work on a better test for this issue. Bill -- "Can't sing louder than the guns when I'm gone, so I guess I'll have to do it while I'm here." Phil Ochs
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#884824: etckeeper: daily autocommit is run even though AVOID_DAILY_AUTOCOMMITS=1
I just noticed some temporary crap was committed last night, and upon investigation, found "daily autocommit" messages dating back to 2020-03-07 when I upgraded to bullseye. Who knows what other crap got committed that I missed with a clean "git diff"? I recently upgraded to bookworm. I have AVOID_DAILY_AUTOCOMMITS=1 in /etc/etckeeper.conf to prevent these evil commits since I'll check in my changes when they are good and ready, and I'll have a much more helpful log message. Whatever it takes to prevent these unwanted commits would be much appreciated. -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
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#1041274: passwordsafe: Editing entry crashes program
Package: passwordsafe Version: 1.16.0+dfsg-4 Severity: important Creating a new entry or editing an existing entry results in the following crash: [wohler@olgas ~ (olgas:*%)]$ pwsafe pwsafe: ./src/core/PWScore.cpp:1890: void PWScore::GetAllGroups(std::vector >&, bool) const: Assertion `!iter2->empty()' failed. Aborted I am happy to report that I was able to install Password Safe 1.17 from trixie and this fixed the problem. Fortunately, I was able to upgrade without pulling in any other packages. -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages passwordsafe depends on: ii libc62.36-9 ii libgcc-s112.2.0-14 ii libmagic11:5.44-3 ii libqrencode4 4.1.1-1 ii libstdc++6 12.2.0-14 ii libuuid1 2.38.1-5+b1 ii libwxbase3.2-1 3.2.2+dfsg-2 ii libwxgtk3.2-13.2.2+dfsg-2 ii libx11-6 2:1.8.4-2+deb12u1 ii libxerces-c3.2 3.2.4+debian-1 ii libxtst6 2:1.2.3-1.1 ii libykpers-1-11.20.0-3 ii passwordsafe-common 1.16.0+dfsg-4 Versions of packages passwordsafe recommends: ii xvkbd 4.1-2 passwordsafe suggests no packages. -- no debconf information
Bug#1036971: pwsafe: empty window after internal timeout or screen blank
Unfortunately, version 1.17 in trixie does not address this issue for me. Bill Wohler wrote: > Just confirmed that it is version 1.16 that I'm running at work. It was > built from source on a Red Hat 8 system. > > Bill Wohler wrote: > > > Hi Bill, > > > > I can confirm this regression as I experienced it when I upgraded from > > bullseye (perhaps with a more recent version than 1.12 from backports) > > to bookworm (with PasswordSafe 1.16) yesterday. > > > > Normally, when the database is locked after some time of inactivity, the > > password dialog appears. This dialog is no longer appearing. That's the > > bug. > > > > Giuseppe, there is a workaround to get the password dialog that takes > > four more button presses than we'd like: press the Close button followed > > by the Open button and double-click on your database file. > > > > Bill, I *think* I have a compiled PasswordSafe 1.16 from upstream at > > work that works as expected. I'll double-check the version tomorrow and > > let you know. > > > > I wonder if this is a GNOME 43 incompatibility... > > > > -- > > Bill Wohler aka > > http://www.newt.com/wohler/, GnuPG ID:610BD9AD > > -- > Bill Wohler aka > http://www.newt.com/wohler/, GnuPG ID:610BD9AD -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Bug#1036971: pwsafe: empty window after internal timeout or screen blank
Just confirmed that it is version 1.16 that I'm running at work. It was built from source on a Red Hat 8 system. Bill Wohler wrote: > Hi Bill, > > I can confirm this regression as I experienced it when I upgraded from > bullseye (perhaps with a more recent version than 1.12 from backports) > to bookworm (with PasswordSafe 1.16) yesterday. > > Normally, when the database is locked after some time of inactivity, the > password dialog appears. This dialog is no longer appearing. That's the > bug. > > Giuseppe, there is a workaround to get the password dialog that takes > four more button presses than we'd like: press the Close button followed > by the Open button and double-click on your database file. > > Bill, I *think* I have a compiled PasswordSafe 1.16 from upstream at > work that works as expected. I'll double-check the version tomorrow and > let you know. > > I wonder if this is a GNOME 43 incompatibility... > > -- > Bill Wohler aka > http://www.newt.com/wohler/, GnuPG ID:610BD9AD -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
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#1036971: pwsafe: empty window after internal timeout or screen blank
Hi Bill, I can confirm this regression as I experienced it when I upgraded from bullseye (perhaps with a more recent version than 1.12 from backports) to bookworm (with PasswordSafe 1.16) yesterday. Normally, when the database is locked after some time of inactivity, the password dialog appears. This dialog is no longer appearing. That's the bug. Giuseppe, there is a workaround to get the password dialog that takes four more button presses than we'd like: press the Close button followed by the Open button and double-click on your database file. Bill, I *think* I have a compiled PasswordSafe 1.16 from upstream at work that works as expected. I'll double-check the version tomorrow and let you know. I wonder if this is a GNOME 43 incompatibility... -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Bug#1037251: new version
Hi, Version 1.17.0 is now available in unstable and testing. Can you confirm whether or not this issue still happens with the new version? Regards, Bill --
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#1037971: ksh93u+m: read statement in subshell fails for 0 or 1 character followed by tab
Package: ksh93u+m Version: 1.0.4-3 Severity: normal Dear Maintainer, The following: ( read a; print "$a" ) beeps and ignores a tab if entered before two other characters have been typed. With () removed, it works in an interactive shell but fails in an invoked script. Bill -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages ksh93u+m depends on: ii libc6 2.36-9 ksh93u+m recommends no packages. Versions of packages ksh93u+m suggests: pn binfmt-support -- no debconf information
Bug#1037547: More info
pilgrim:/etc/fapolicyd/rules.d# ls 90-deny-execute.rules pilgrim:/etc/fapolicyd/rules.d# cat 90-deny-execute.rules # Deny execution for anything untrusted deny_audit perm=execute all : all pilgrim:/etc/fapolicyd# cat fapolicyd.conf # # This file controls the configuration of the file access policy daemon. # See the fapolicyd.conf man page for explanation. # permissive = 0 nice_val = 14 q_size = 640 uid = fapolicyd gid = fapolicyd do_stat_report = 1 detailed_report = 1 db_max_size = 50 subj_cache_size = 1549 obj_cache_size = 8191 watch_fs = ext2,ext3,ext4,tmpfs,xfs,vfat,iso9660,btrfs trust = rpmdb,file integrity = none syslog_format = rule,dec,perm,auid,pid,exe,:,path,ftype,trust rpm_sha256_only = 0 allow_filesystem_mark = 0 Looks like the shipped policy is to deny all execute and with permissive=0 this is enforced.
