Bug#1073835: systemd: new run0 utility fails due to missing dependency

[John Shaft]

Package: systemd
Version: 256-1
Severity: normal

Dear Maintainer,

systemd 256 introduced a 'run0' utility intended to serve a similar purpose as 
sudo(8)

run0(1) manpage states:

'Authentication takes place via polkit[1], thus isolating the authentication 
prompt from the terminal (if possible).'

As of now, polkitd is only a suggestion and not yet a dependency for systemd so 
chances are it is not installed. Trying to use run0 thus fails, eg:

$ run0 ls /tmp
Failed to start transient service unit: Access denied

(note that run0 error message could be improved, but it is an upstream issue)

-- Package-specific info:

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 systemd depends on:
ii  libacl12.3.2-2
ii  libapparmor1   3.0.13-2
ii  libaudit1  1:3.1.2-4
ii  libblkid1  2.40.1-8.1
ii  libc6  2.38-13
ii  libcap21:2.66-5
ii  libcryptsetup122:2.7.2-2
ii  libfdisk1  2.40.1-8.1
ii  libmount1  2.40.1-8.1
ii  libpam0g   1.5.3-7
ii  libseccomp22.5.5-1
ii  libselinux13.5-2+b2
ii  libssl3t64 3.2.1-3
ii  libsystemd-shared  256-1
ii  libsystemd0256-1
ii  mount  2.40.1-8.1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]  1.14.10-4+b1
ii  libzstd11.5.5+dfsg2-2
ii  ntpsec [time-daemon]1.2.3+dfsg1-3

Versions of packages systemd suggests:
ii  libgcrypt20   1.10.3-3
ii  libidn2-0 2.3.7-2
ii  liblz4-1  1.9.4-2
ii  liblzma5  5.6.1+really5.4.5-1
pn  libtss2-rc0t64
pn  libtss2-tcti-device0  
pn  polkitd   
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-4+b1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 256-1
ii  libpam-systemd 256-1
ii  udev   256-1

-- no debconf information

Bug#1073830: gcc-14: Missing build dependency on cargo on hurd-i386

[John Paul Adrian Glaubitz]

Source: gcc-14
Version: 14.1.0-2
Severity: normal
User: debian-h...@lists.debian.org
Usertags: hurd-i386
X-Debbugs-Cc: debian-h...@lists.debian.org

Hi,

gcc-14 needs to build-depend on cargo on hurd-i386 to be able to build gccrs 
[1]:

   configure: error: cargo is required to build rust

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-14=hurd-i386=14.1.0-2=1718795837=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1073590: pd-mrpeach: FTBFS on hppa - ‘x->x_sr[client]’ is a pointer

[John David Anglin]

Source: pd-mrpeach
Version: 0.1~svn17672-5
Severity: normal
Tags: ftbfs

Dear Maintainer,

Build fails here:
net/tcpserver.c: In function ‘tcpserver_send_buffer_avaliable_for_client’:
net/tcpserver.c:542:33: error: ‘x->x_sr[client]’ is a pointer; did you mean to 
use ‘->’?
  542 | int sockfd = x->x_sr[client].sr_fd;
  | ^
  | ->
cc -DPD -I "/usr/include/pd"  -DUNIX -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC  -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-Wformat -Werror=format-security -o cmos/cd4082.pd_linux.o -c cmos/cd4082.c
 info: making cmos/cd4072.pd_linux.o in lib mrpeach
make[1]: *** [/usr/share/pd-lib-builder//Makefile.pdlibbuilder:987: 
net/tcpserver.pd_linux.o] Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=pd-mrpeach=hppa=0.1%7Esvn17672-6=1718659014=0

Regards,
Dave Anglin


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.10.0-rc4 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1073046: fixed in cups 2.4.7-3

[John Paul Adrian Glaubitz]

Hi Thorsten,

On Sun, 2024-06-16 at 00:19 +, Debian FTP Masters wrote:
>[ Thorsten Alteholz ]
>* reintroduce time_t changes that were accidentally deleted
>  with last upload
>  (thanks to Michael Hudson-Doyle for this work)
>* debian/rules: no test on riscv64 (Closes: #1073046)

Would be great if the testsuite could be disabled for sparc64 as well
if there is no prospective fix for the testsuite failures in sight.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#955858: gparted: does not start, 'unable to init server', tmp.mount does not exist

[John Doe]

Package: gparted
Version: 1.5.0-1+b1
Followup-For: Bug #955858
X-Debbugs-Cc: contrapunc...@disroot.org

Dear Maintainer,

I have the same issue (cannot launch gparted from the XFCE applications menu),
with the difference that when I start gparted from the command line, I get -
```
Invalid MIT-MAGIC-COOKIE-1 key

(gpartedbin:16042): Gtk-WARNING **: 10:04:45.522: cannot open display: :0.0
```

> What display server / desktop environment are you using?

xorg v1:7.7+23 and xfce4 v4.18


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 gparted depends on:
ii  gparted-common   1.5.0-1
ii  libatkmm-1.6-1v5 2.28.4-1+b1
ii  libc62.38-13
ii  libcairomm-1.0-1v5   1.14.5-1
ii  libgcc-s114-20240330-1
ii  libglib2.0-0t64  2.80.2-2
ii  libglibmm-2.4-1t64   2.66.7-1
ii  libgtk-3-0t643.24.42-1
ii  libgtkmm-3.0-1t643.24.9-1
ii  libpangomm-1.4-1v5   2.46.4-1+b1
ii  libparted-fs-resize0t64  3.6-4
ii  libparted2t643.6-4
ii  libsigc++-2.0-0v52.12.1-2
ii  libstdc++6   14-20240330-1
ii  libuuid1 2.40.1-8.1
ii  pkexec   124-2

gparted recommends no packages.

Versions of packages gparted suggests:
pn  dmraid 
ii  dmsetup2:1.02.196-1+b1
ii  dosfstools 4.2-1.1
ii  e2fsprogs  1.47.1-1
ii  exfatprogs 1.2.2-1
pn  gpart  
pn  jfsutils   
pn  kpartx 
pn  mtools 
ii  ntfs-3g1:2022.10.3-1+b1
pn  reiser4progs   
pn  reiserfsprogs  
pn  udftools   
ii  xfsprogs   6.8.0-2
ii  yelp   42.2-1+b2

-- no debconf information

Bug#939756: mercurial: FTBFS on hppa - test-hghave.t timed out

[John David Anglin]

I'm not seeing this time out with 6.7.4-1.

Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net

Bug#1073270: mercurial: FTBFS on hppa - test-bundle.t output changed

[John David Anglin]

Source: mercurial
Version: 6.7.4-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

test-bundle.t fails:

test-bundle.t
test-bundle.t ... # Test test-bundle.t 
# Running sh "/tmp/hgtests.dnrnpeia/child163/test-bundle.t.sh" 
# Timout reached for process 2680 
# Ret was: 0 (test-persistent-nodemap.t) 
ok
test-revert.t
test-revert.t ... # Test test-revert.t 
# Running sh "/tmp/hgtests.dnrnpeia/child164/test-revert.t.sh" 
# Timout reached for process 3637 

--- /<>/tests/test-bundle.t
+++ /<>/tests/test-bundle.t.err
@@ -1106,13 +1106,7 @@
   DEBUG-UNBUNDLING: full:?? seconds (???% of total) 
(glob)
   DEBUG-UNBUNDLING:   cached:?? seconds (???% of total) 
(glob)
   DEBUG-UNBUNDLING:   manifests:
-  DEBUG-UNBUNDLING: full:?? seconds (???% of total) 
(glob)
-  DEBUG-UNBUNDLING:   cached:?? seconds (???% of total) 
(glob)
-  DEBUG-UNBUNDLING: delta:   ?? seconds (???% of total) 
(glob)
-  DEBUG-UNBUNDLING:   cached:?? seconds (???% of total) 
(glob)
   DEBUG-UNBUNDLING:   files:
-  DEBUG-UNBUNDLING: full:?? seconds (???% of total) 
(glob)
-  DEBUG-UNBUNDLING:   cached:?? seconds (???% of total) 
(glob)
   added 3 changesets with 3 changes to 3 files
   new changesets 4fe08cd4693e:4652c276ac4f (3 drafts)
   (run 'hg update' to get a working copy)

ERROR: test-bundle.t output changed
!# Ret was: 0 (test-bundle.t) 

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=mercurial=hppa=6.7.4-1=1718444852=0

test-bundle.t is the only test that fails with 6.7.4-1 when the testsuite
is run on real hardware. There are more errors with qemu buildds.

I don't see #929756 anymore.

I saw this output when I built mercurial with dpkg-buildpackage:

--- /home/dave/debian/mercurial/mercurial-6.7.4/tests/test-bundle.t
+++ /home/dave/debian/mercurial/mercurial-6.7.4/tests/test-bundle.t.err
@@ -1086,33 +1086,76 @@
   DEBUG-UNBUNDLING:   manifests:  3 ( 33%)
   DEBUG-UNBUNDLING:   files:  3 ( 33%)
   DEBUG-UNBUNDLING: total-time:  ?? seconds (glob)
-  DEBUG-UNBUNDLING:   changelog: ?? seconds (???%) (glob)
-  DEBUG-UNBUNDLING:   manifests: ?? seconds (???%) (glob)
-  DEBUG-UNBUNDLING:   files: ?? seconds (???%) (glob)
-  DEBUG-UNBUNDLING: type-count:
-  DEBUG-UNBUNDLING:   changelog:
-  DEBUG-UNBUNDLING: full: 3
-  DEBUG-UNBUNDLING:   cached: 3 (100%)
-  DEBUG-UNBUNDLING:   manifests:
-  DEBUG-UNBUNDLING: full: 1
-  DEBUG-UNBUNDLING:   cached: 1 (100%)
-  DEBUG-UNBUNDLING: delta:2
-  DEBUG-UNBUNDLING:   cached: 2 (100%)
-  DEBUG-UNBUNDLING:   files:
-  DEBUG-UNBUNDLING: full: 3
-  DEBUG-UNBUNDLING:   cached: 3 (100%)
-  DEBUG-UNBUNDLING: type-time:
-  DEBUG-UNBUNDLING:   changelog:
-  DEBUG-UNBUNDLING: full:?? seconds (???% of total) 
(glob)
-  DEBUG-UNBUNDLING:   cached:?? seconds (???% of total) 
(glob)
-  DEBUG-UNBUNDLING:   manifests:
-  DEBUG-UNBUNDLING: full:?? seconds (???% of total) 
(glob)
-  DEBUG-UNBUNDLING:   cached:?? seconds (???% of total) 
(glob)
-  DEBUG-UNBUNDLING: delta:   ?? seconds (???% of total) 
(glob)
-  DEBUG-UNBUNDLING:   cached:?? seconds (???% of total) 
(glob)
-  DEBUG-UNBUNDLING:   files:
-  DEBUG-UNBUNDLING: full:?? seconds (???% of total) 
(glob)
-  DEBUG-UNBUNDLING:   cached:?? seconds (???% of total) 
(glob)
-  added 3 changesets with 3 changes to 3 files
-  new changesets 4fe08cd4693e:4652c276ac4f (3 drafts)
-  (run 'hg update' to get a working copy)
+  transaction abort!
+  rollback completed
+  ** unknown exception encountered, please report by visiting
+  ** https://mercurial-scm.org/wiki/BugTracker
+  ** Python 3.11.9 (main, Apr 10 2024, 13:16:36) [GCC 13.2.0]
+  ** Mercurial Distributed SCM (version 6.7.4)
+  ** Extensions loaded:
+  Traceback (most recent call last):
+File "/tmp/hgtests.7tftf1lf/install/bin/hg", line 59, in 
+  dispatch.run()
+File "/tmp/hgtests.7tftf1lf/install/lib/python/mercurial/dispatch.py", 
line 142, in run
+  status = dispatch(req)
+   ^
+File "/tmp/hgtests.7tftf1lf/install/lib/python/mercurial/dispatch.py", 
line 231, in dispatch
+  status = _rundispatch(req)
+   ^
+File "/tmp/hgtests.7tftf1lf/install/lib/python/mercurial/dispatch.py", 
line 275, in _rundispatch
+  ret = _runcatch(req) or 0
+^^
+File "/tmp/hgtests.7tftf1lf/install/lib/python/mercurial/dispatch.py", 
line 456, in _runcatch
+  return 

Bug#1073189: awscli: ImportError: cannot import name DEFAULT_CIPHERS from urllib3.util.ssl_

[Simon John]

Downgrading to urllib3 v1 fixed this for me, some more info here - 
although botocore already seems to have the fix they mention:


https://github.com/aws/aws-cli/issues/7905

Package I used:

https://snapshot.debian.org/package/python-urllib3/1.26.18-2/#python3-urllib3_1.26.18-2

Regards.

--
Simon John

Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects

[John Paul Adrian Glaubitz]

On Fri, 2024-06-14 at 10:33 +0200, Sune Stolborg Vuorela wrote:
> On Friday, June 14, 2024 10:25:59 AM CEST John Paul Adrian Glaubitz wrote:
> > I'm not denying that. However, a package named "qml6-module-qtquick-effects"
> > doesn't sound like an interpreter to me.
> > 
> > Thus, I don't really see how I am supposed to know as a maintainer what
> > packages add Depends except for trial and error. Why not have one canonical
> > "qt-interpretor" package or similar that applications can depend on?
> 
> This is a module for a interpreted language. It is not much different than a 
> python package might need a hardcoded dependency on python-foo if it uses 
> that. or a perl package might need a hardcoded dependency on libperl-foo-bar-
> baz if it uses the Foo::Bar::Baz perl module for important functionality.
> 
> all qml*-module packages are qml (interpreted language) extensions.
> 
> And yes. trial and error - or reading the sources - is for many interpreted 
> languages the only way of figuring it out.

Ugh, that's truly a step backwards and way to add more burden to maintainers.

I guess we'll be seeing plenty of such bug reports in the future when extensions
get moved around or new ones get added.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)

[John Paul Adrian Glaubitz]

Hi Ilias,

On Thu, 2024-06-13 at 20:50 +0200, John Paul Adrian Glaubitz wrote:
> > Do we still have to build an unregisterised compiler for powerpc
> > or can we switch back to NCG (https://bugs.debian.org/1060196)?
> 
> I have not verified that yet. Please let's stay unregisterised for now
> and have me verify first whether the NGC has been fixed with 9.6.x or
> newer.
> 
> Please let's keep this bug report open and use #1073159 [1] for adding
> the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS.

GHC 9.6.5 still fails on powerpc with the NGC enabled:

# rts/include/rts/prof/LDV.h
| Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => 
_build/stage1/rts/build/cmm/HeapStackCheck.debug_o
| Run Ghc CompileHs Stage1: rts/PrimOps.cmm => 
_build/stage1/rts/build/cmm/PrimOps.p_o
| Run Ghc CompileHs Stage1: rts/Updates.cmm => 
_build/stage1/rts/build/cmm/Updates.thr_p_o
| Run Ghc CompileHs Stage1: rts/Compact.cmm => 
_build/stage1/rts/build/cmm/Compact.thr_p_o
| Run Ghc CompileHs Stage1: rts/Exception.cmm => 
_build/stage1/rts/build/cmm/Exception.o
| Run Ghc CompileHs Stage1: rts/PrimOps.cmm => 
_build/stage1/rts/build/cmm/PrimOps.debug_o
| Run Ghc CompileHs Stage1: rts/StgStartup.cmm => 
_build/stage1/rts/build/cmm/StgStartup.debug_p_o
| Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => 
_build/stage1/rts/build/cmm/HeapStackCheck.p_o
| Run Ghc CompileHs Stage1: rts/StgStartup.cmm => 
_build/stage1/rts/build/cmm/StgStartup.thr_debug_p_o
| Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => 
_build/stage1/rts/build/cmm/StgMiscClosures.debug_o
| Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => 
_build/stage1/rts/build/cmm/StgMiscClosures.p_o
| Run Ghc CompileHs Stage1: rts/ContinuationOps.cmm => 
_build/stage1/rts/build/cmm/ContinuationOps.debug_p_o
| Run Ghc CompileHs Stage1: rts/Updates.cmm => 
_build/stage1/rts/build/cmm/Updates.debug_p_o
| Run Ghc CompileHs Stage1: rts/StgStartup.cmm => 
_build/stage1/rts/build/cmm/StgStartup.thr_p_o
| Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.o
| Run Ghc CompileHs Stage1: rts/Exception.cmm => 
_build/stage1/rts/build/cmm/Exception.debug_o
| Run Ghc CompileHs Stage1: rts/Apply.cmm => 
_build/stage1/rts/build/cmm/Apply.thr_dyn_o
Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf debug_p_hi -osuf 
debug_p_o -hcsuf debug_p_hc -static -prof -DDEBUG -optc-DDEBUG 
-hide-all-packages -no-user-package-db '-package-env -' '-
package-db _build/stage1/inplace/package.conf.d' '-this-unit-id rts-1.0.2' -i 
-i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/rts/build 
-i/home/glaubitz/ghc-deb-9.6.5-new/ghc-
9.6.5/_build/stage1/rts/build/autogen 
-i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/rts -Irts/include 
-I_build/stage1/rts/build -I_build/stage1/rts/build/include
-I_build/stage1/rts/build/@FFIIncludeDir@ 
-I_build/stage1/rts/build/@LibdwIncludeDir@ -Irts/include -Irts/@FFIIncludeDir@ 
-Irts/@LibdwIncludeDir@ -optP-include -
optP_build/stage1/rts/build/autogen/cabal_macros.h 
-ghcversion-file=rts/include/ghcversion.h -outputdir _build/stage1/rts/build 
-fdiagnostics-color=always -Wnoncanonical-monad-instances -optc-Wno-
error=inline -optP-Wno-nonportable-include-path -c rts/ContinuationOps.cmm -o 
_build/stage1/rts/build/cmm/ContinuationOps.debug_p_o -O2 -H32m -this-unit-id 
rts -XHaskell98 -no-global-package-db -
package-db=/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/inplace/package.conf.d
 -ghcversion-file=rts/include/ghcversion.h 
-ghcversion-file=rts/include/ghcversion.h -haddock -Irts -
I_build/stage1/rts/build '-DRtsWay="rts_debug_p"' -DFS_NAMESPACE=rts 
-DCOMPILING_RTS -DPROFILING -Wno-deprecated-flags -Wcpp-undef
===> Command failed with error code: 1
ghc: panic! (the 'impossible' happened)
  GHC version 9.6.5:
PPC.Ppr.pprInstr: JMP to ForeignLabel
  CallStack (from HasCallStack):
panic, called at compiler/GHC/CmmToAsm/PPC/Ppr.hs:591:30 in 
ghc:GHC.CmmToAsm.PPC.Ppr


Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug

Error when running Shake build system:
  at want, called at src/Main.hs:124:44 in main:Main
* Depends on: binary-dist-dir
  at need, called at src/Rules/BinaryDist.hs:130:9 in main:Rules.BinaryDist
* Depends on: _build/stage1/lib/package.conf.d/rts-1.0.2.conf
  at need, called at src/Rules/Register.hs:134:5 in main:Rules.Register
* Depends on: _build/stage1/rts/build/stamp-rts-1.0.2_debug_p
  at need, called at src/Rules/Library.hs:144:3 in main:Rules.Library
* Depends on: _build/stage1/rts/build/libHSrts-1.0.2_debug_p.a
  at need, called at src/Rules/Library.hs:220:5 in main:Rules.Library
* Depends on: _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o
  at cmd', called at src/Builder.hs:387:23 in main:Builder
  at cmdArgs, called at src/Builder.hs:540:8 in main:Builder
  at cmdArgs, called at src/Builder.hs:564:18 in main:Builder
  at cmd

Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects

[John Paul Adrian Glaubitz]

On Fri, 2024-06-14 at 09:39 +0200, Sune Stolborg Vuorela wrote:
> Control: severity -1 serious
> 
> Missing dependencies are RC
> 
> > This is a common problem with Qt6 and has been reported for a different
> > dependency before, see [1]. 
> 
> It is normal for interpreted languages to have their dependencies managed 
> manually. This is just another version of that.

I'm not denying that. However, a package named "qml6-module-qtquick-effects"
doesn't sound like an interpreter to me.

Thus, I don't really see how I am supposed to know as a maintainer what packages
add Depends except for trial and error. Why not have one canonical 
"qt-interpretor"
package or similar that applications can depend on?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1073159: ghc: Please include --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS

[John Paul Adrian Glaubitz]

Source: ghc
Version: 9.4.7-5
Severity: important
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hi,

after debugging the segmentation faults with the unregisterised GHC on powerpc
for a long time, I finally found the culprit which is the fact that GHC is built
to default to the gold linker by default.

The gold linker is known to be broken on some architectures which is unlikely to
change in the future as the project has been abandoned by Google [1], so it has
been long disabled for several architectures in debian/rules by passing the flag
--disable-ld-override in EXTRA_CONFIGURE_FLAGS.

However, as I learnt today, this only affects the linker choice when building 
GHC
but not the default linker for the actual binary packages which still defaulted
to gold in /usr/lib/ghc/lib/settings.

As one of the upstream developers explained to me today [2], it's necessary to
pass --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS as well in order to
disable gold for the binary distribution, i.e. what will end up in the Debian
package.

Thus, please modify debian/rules to also include the flag --disable-ld-override
in EXTRA_INSTALL_CONFIGURE_FLAGS:

--- debian/rules.orig   2024-06-13 11:01:23.450199875 -0700
+++ debian/rules2024-06-13 11:01:26.318242288 -0700
@@ -76,6 +76,7 @@
 # See also https://bugs.debian.org/1056636
 ifneq (,$(filter mips mipsel powerpc powerpcspe sparc64, $(DEB_HOST_ARCH)))
   EXTRA_CONFIGURE_FLAGS += --disable-ld-override
+  EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override
 endif
 
 ifneq (,$(filter armhf, $(DEB_HOST_ARCH)))

Also attaching a patch.

Thanks,
Adrian

> [1] https://en.wikipedia.org/wiki/Gold_(linker)
> [2] https://gitlab.haskell.org/ghc/ghc/-/issues/24986#note_570504

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig   2024-06-13 11:01:23.450199875 -0700
+++ debian/rules2024-06-13 11:01:26.318242288 -0700
@@ -76,6 +76,7 @@
 # See also https://bugs.debian.org/1056636
 ifneq (,$(filter mips mipsel powerpc powerpcspe sparc64, $(DEB_HOST_ARCH)))
   EXTRA_CONFIGURE_FLAGS += --disable-ld-override
+  EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override
 endif
 
 ifneq (,$(filter armhf, $(DEB_HOST_ARCH)))

Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)

[John Paul Adrian Glaubitz]

Hi Ilias,

On Thu, 2024-06-13 at 21:22 +0300, Ilias Tsitsimpis wrote:
> Great job!

Thanks!

> I completely missed the fact this needs to be passes to the bindist's
> configure script as well.

It took me forever to figure this out ;-).

> You need to edit debian/rules here
> https://sources.debian.org/src/ghc/9.4.7-5/debian/rules/#L78
> and add the following line as well:
> 
> +   EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override

Yes, that's what I suggested, see my patch in [1].

> I will include that in the next upload.

Great, thank you. I uploaded a patched version to unreleased in the
mean time.

> Do we still have to build an unregisterised compiler for powerpc
> or can we switch back to NCG (https://bugs.debian.org/1060196)?

I have not verified that yet. Please let's stay unregisterised for now
and have me verify first whether the NGC has been fixed with 9.6.x or
newer.

Please let's keep this bug report open and use #1073159 [1] for adding
the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073159

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)

[John Paul Adrian Glaubitz]

Hi Jeff,

On Thu, 2024-06-13 at 03:50 -0400, Jeffrey Walton wrote:
> > Now we just need to figure out how to actually set the default linker back
> > to bfd as it was actually explicitly supposed to happen according to
> > debian/rules.
> > 
> > This will most likely also unbreak GHC on m68k.
> 
> Good job, Adrian. That's quite a bit of work to track down the issue.

Thanks. In the meantime I filed a bug upstream for this [1].

I will actually open a second bug report since this bug report is about
the broken NGC on 32-bit PowerPC which is a different issue.

Adrian

> [1] https://gitlab.haskell.org/ghc/ghc/-/issues/24986

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)

[John Paul Adrian Glaubitz]

Hi,

I finally figured out what the problem is. 

After realizing that the two-stage build of GHC works without problems,
I realized it can be a configuration issue only and, indeed, it is.

Looking at /usr/lib/ghc/lib/settings, the default linker is set to gold:

"C compiler link flags", "-fuse-ld=gold"

Since gold is broken on powerpc and shouldn't really be used anymore since
it's basically unmaintained upstream, we must use bfd on powerpc by default.

Editing the file and switching back to bfd fixes the problem for me.

Now we just need to figure out how to actually set the default linker back
to bfd as it was actually explicitly supposed to happen according to
debian/rules.

This will most likely also unbreak GHC on m68k.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1073085: hfsutils: upgrade the source package to use compat level 13

[John Paul Adrian Glaubitz]

Hello Liu,

On Wed, 2024-06-12 at 15:10 -0600, Zixing Liu wrote:
> This patch does the following:
> 
>   * d/rules: switch to use the debhelper autoreconf template.
> - d/rules: disable parallel testing.
> - d/hfsutils-tcltk.links: remove, this is auto-handled by debhelper now.
>   * d/p/0006-Fix-memory-corruption.patch: add a patch to fix memory corruption
> issues (LP: #493273).
> 
> 
> Thanks for considering the patch.

Thanks for your patch. I'll implement your changes in the weekend.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects

[John Paul Adrian Glaubitz]

Control: severity -1 normal

Hello Reinhard,

On Wed, 2024-06-12 at 18:40 +0200, Reinhard Karcher wrote:
> ausweisapp doesn't start the gui, because qml6-module-qtquick-effects
> is not installed. It should depend on that package.
> Installing qml6-module-qtquick-effects solves the problem.

This is a common problem with Qt6 and has been reported for a different
dependency before, see [1]. I haven't found a satisfactory solution as
hard-coding a dependency as suggested in your bug report would mean that
the package cannot undergo automatic transitions.

I am therefore reducing the severity to normal as the package would otherwise
be removed from testing.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070018#10

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1073046: cups: FTBFS on riscv64 due to testsuite timeouts

[John Paul Adrian Glaubitz]

Source: cups
Version: 2.4.7-2
Severity: serious
Tags: ftbfs
Justification: ftbfs
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Hello,

src:cups currently FTBFS on riscv64 due to a testsuite timeout [1]:


Running command tests...
Performing 5.1-lpadmin.sh: FAIL
Performing 5.2-lpc.sh: PASS
Performing 5.3-lpq.sh: FAIL
Performing 5.4-lpstat.sh: FAIL
Performing 5.5-lp.sh: FAIL
Performing 5.6-lpr.sh: FAIL
Performing 5.7-lprm.sh: FAIL
Performing 5.8-cancel.sh: FAIL
Performing 5.9-lpinfo.sh: FAIL
Performing restart test: ./run-stp-tests.sh: 811: kill: No such process

E: Build killed with signal TERM after 600 minutes of inactivity

This issue has been observed on sparc64, so it seems reproducible.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=cups=riscv64=2.4.7-2=1718180226=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072774: Upstream bug files

[John Cabaj]

Upstream bug filed here - https://github.com/openzfs/zfs/issues/16261


John

Bug#1072774: Also fails on upstream

[John Cabaj]

I rebuilt the Debian package using the latest upstream 
(https://github.com/openzfs/zfs), and saw the same error. Log is (hopefully 
attached). Will raise the issue there as well.


Thanks,
John

typescript
Description: Binary data

Bug#1069498: libx86emu: FTBFS on armhf: mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean ‘ins’? [-Werror=implicit-function-declaration]

[John Paul Adrian Glaubitz]

Hi Guillem,

On Tue, 2024-06-11 at 13:42 +0200, Guillem Jover wrote:
> > I had a look at this, and it seems like this package has never really
> > worked on ARM systems at all? And this was hidden due to the missing
> > declarations not being an error.
> > 
> > AFAIK, only x86 (i386 and amd64), ia64 and alpha have port I/O, other
> > systems have instead memory mapped I/O, but the code in mem.c is
> > unconditionally calling port I/O functions such as in*() and out*(),
> > provided by glibc.
> > 
> > Until the upstream code is ported to systems with memory mapper I/O, I
> > think the "best" way to resolve this would be to restrict the
> > architecture list to:
> > 
> >   any-amd64 any-i386 alpha ia64
> 
> The attached patch implements this. It should not affect reverse build
> depending packages (only hwinfo) which is already arch restricted to
> «amd64 i386».
> 
> I'm including the arm list to confirm the above, but also in case
> someone there feels like porting the library to support memory mapped
> I/O? (But perhaps that's not worth the effort.)

It's perfectly fine to disable libx86emu on ARM as it has already been
correctly stated, there are no I/O ports on ARM so the above code won't
work on ARM.

I also don't expect that to change in the future, so it's not worth bothering
about this in the future, especially since the upstream project hasn't been
very active lately [1].

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072769: libvirt-daemon: Cannot connect to hypervisor with user session after upgrade

[Simon John]

Actually adding /usr/sbin to $PATH doesn't fix this in all cases.

If you run virt-manager from Gnome on Wayland for instance, it doesn't 
connect.


You have to run it from the console or run virsh first to get it to use 
your new $PATH


I guess you could also set it in ~/.config/environment.d/*.conf instead 
of just ~/.bashrc but that's really getting ugly, seems this needs a 
proper fix not a workaround.


--
Simon John

Bug#1072769: libvirt-daemon: Cannot connect to hypervisor with user session after upgrade

[Simon John]

Nice spot!

Yes, adding /usr/sbin to the user's $PATH does seem to workaround it on 
10.4 and explains why it works for root.


It's a bit odd as installing firewalld, which uninstalls iptables, 
doesn't fix things, nor does setting the backend in the config file.


Also should lacking the ability to mess with the firewall prevent VM's 
from even being listed, created or edited, aside from started?


Seems that whole commit is sub-optimal, not just the iptables in $PATH line.

--
Simon John

Bug#1072954: python-ijson: FTBFS on hppa - ZeroDivisionError: float division by zero

[John David Anglin]

Source: python-ijson
Version: 3.3.0-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

Build fails due to testsuite problems:
FAIL: test_basic_parse (test.test_benchmark.BenchmarkTests.test_basic_parse)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.11_ijson/build/test/test_benchmark.py", 
line 38, in test_basic_parse
self._test_benchmark('basic_parse')
  File 
"/<>/.pybuild/cpython3_3.11_ijson/build/test/test_benchmark.py", 
line 33, in _test_benchmark
self._do_test_benchmark(method, "python")
  File 
"/<>/.pybuild/cpython3_3.11_ijson/build/test/test_benchmark.py", 
line 30, in _do_test_benchmark
self.assertEqual(0, status, "out:\n%s\nerr:%s" % (out.decode('utf-8'), 
err.decode('utf-8')))
AssertionError: 0 != 1 : out:
#mbytes, method, test_case, backend, time_min, time_avg, time_median, time_max, 
mb_per_sec_min, mb_per_sec_avg, mb_per_sec_median, mb_per_sec_max
0.000, basic_parse, long_list, python, 0.004, 0.004, 0.004, 0.004, 0.001, 
0.001, 0.001, 0.001
0.000, basic_parse, long_list, yajl2, 0.004, 0.004, 0.004, 0.004, 0.001, 0.001, 
0.001, 0.001

err:Traceback (most recent call last):
  File "", line 198, in _run_module_as_main
  File "", line 88, in _run_code
  File 
"/<>/.pybuild/cpython3_3.11_ijson/build/ijson/benchmark.py", line 
275, in 
main()
  File 
"/<>/.pybuild/cpython3_3.11_ijson/build/ijson/benchmark.py", line 
272, in main
run_benchmarks(args, benchmark)
  File 
"/<>/.pybuild/cpython3_3.11_ijson/build/ijson/benchmark.py", line 
214, in run_benchmarks
stats([megabytes / duration for duration in durations])
  
  File 
"/<>/.pybuild/cpython3_3.11_ijson/build/ijson/benchmark.py", line 
214, in 
stats([megabytes / duration for duration in durations])
   ~~^~
ZeroDivisionError: float division by zero

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=python-ijson=hppa=3.3.0-1=1717834294=0

I haven't looked this in detail but CLOCK_MONOTONIC timing is quite course
on hppa.  I suspect if "duration for duration in durations" is longer the
division by zero error wouldn't occur.

Similar error occurs on hurd-i386.

Regards,
Dave Anglin



-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.9.3-dirty (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1072951: racket: FTBFS on hppa - illegal pb instruction

[John David Anglin]

Source: racket
Version: 8.13+dfsg1-2
Severity: normal
Tags: ftbfs

Dear Maintainer,

Racket build fails here:
running cs/c/ChezScheme/pb/bin/pb/scheme to build 
cs/c/ChezScheme/xc-tpb32b/s/cmacros.so
illegal pb instruction
failed
 in build-one
 in loop
 in module->hash
illegal pb instruction
make[1]: *** [Makefile:22: all] Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=racket=hppa=8.13%2Bdfsg1-2=1717949065=0

Regards,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.9.3-dirty (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1072950: qtwayland-opensource-src: FTBFS on hppa - tst_xdgdecorationv1 fails

[John David Anglin]

Source: qtwayland-opensource-src
Version: 5.15.13-2
Severity: normal
Tags: ftbfs

Dear Maintainer,

As of version 5.15.13-2, we have the following test failure:

make[4]: Leaving directory '/<>/tests/auto/client/inputcontext'
FAIL!  : tst_xdgdecorationv1::clientSidePreferredByCompositor() 
'(!window.frameMargins().isNull())' returned FALSE. ()
   Loc: [tst_xdgdecorationv1.cpp(184)]

Full build log is here:
https://buildd.debian.org/status/fetch.php?pkg=qtwayland-opensource-src=hppa=5.15.13-2=1717804433=0

Regards,
Dave Anglin 

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.9.3-dirty (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1072940: mailtuils: FTBFS on sparc64 due to outdated symbols file

[John Paul Adrian Glaubitz]

Source: mailutils
Version: 1:3.17-2
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hello,

mailutils fails to build from source on sparc64 due to an outdated symbols file 
[1]:

dpkg-gensymbols: warning: debian/libmailutils9t64/DEBIAN/symbols doesn't match 
completely debian/libmailutils9t64.symbols
--- debian/libmailutils9t64.symbols (libmailutils9t64_1:3.17-2_sparc64)
+++ dpkg-gensymbolsjTYNfd   2024-06-09 13:24:35.314252567 +
@@ -1928,6 +1928,7 @@
  mu_py_script_run@Base 1:3.17
 libmu_scm.so.9 libmailutils9t64 #MINVER#
 * Build-Depends-Package: libmailutils-dev
+ _etext@Base 1:3.17-2
  _mu_scm_bugreport@Base 1:3.17
  _mu_scm_debug@Base 1:3.17
  _mu_scm_mailer@Base 1:3.17
dh_makeshlibs: error: failing due to earlier errors
make[1]: *** [debian/rules:86: override_dh_makeshlibs] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:4: binary-arch] Error 2

Thanks,
Adrian

> [1] https://buildd.debian.org/status/package.php?p=mailutils=sid

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072903: kiwi: please package v10.0.21 and remove the obsolete python3-mock build dependency

[John Paul Adrian Glaubitz]

Hello,

On Mon, 2024-06-10 at 01:17 +0200, Alexandre Detiste wrote:
> please package v10.0.21 and remove the obsolete python3-mock build dependency
> 
> > https://github.com/testing-cabal/mock
> > 
> > mock is now part of the Python standard library, available as unittest.mock 
> > in Python 3.3 onward
> 
> more information cab be find here:
> 
> https://github.com/OSInside/kiwi/pull/2470

I have tried packaging the latest upstream version but I was unable to get the
testsuite to pass successfully as setting the proper PYTHONPATH for running
the testsuite did not work.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072897: rustc: Please ignore test_arc_condvar_poison on powerpc

[John Paul Adrian Glaubitz]

Source: rustc
Version: 1.75.0+dfsg1-4
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hi,

the test test_arc_condvar_poison hangs on powerpc for rustc 1.75.0 [1]:

test time::tests::instant_monotonic_concurrent ... ok
test sync::mpsc::tests::stress_recv_timeout_two_threads ... ok
test sync::mutex::tests::test_arc_condvar_poison has been running for a long 
time
E: Build killed with signal TERM after 150 minutes of inactivity

Please include the attached patch to ignore it for the time being.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=rustc=powerpc=1.75.0%2Bdfsg1-4=1717703746=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Index: rustc-1.75.0+dfsg1/library/std/src/sync/mutex/tests.rs
===
--- rustc-1.75.0+dfsg1.orig/library/std/src/sync/mutex/tests.rs
+++ rustc-1.75.0+dfsg1/library/std/src/sync/mutex/tests.rs
@@ -145,6 +145,7 @@ fn test_mutex_arc_condvar() {
 }
 }
 
+#[cfg(not(target_arch = "powerpc"))]
 #[test]
 fn test_arc_condvar_poison() {
 let packet = Packet(Arc::new((Mutex::new(1), Condvar::new(;

Bug#1057050: qt6-multimedia: Please build with EIGEN_DONT_VECTORIZE on powerpc to fix FTBFS

[John Paul Adrian Glaubitz]

Hello,

On Sun, 2024-06-09 at 16:39 +0200, marillat wrote:
> > This can be fixed by switching off vectorization in the »eigen« using the 
> > preprocessor
> > macro EIGEN_DONT_VECTORIZE which can be defined on the cmake command line 
> > using the
> > cmake variable COMPILE_DEFINITIONS:
> > 
> > --- qt6-multimedia-6.4.2/debian/rules.orig  2023-07-26 
> > 17:52:13.0 +0200
> > +++ qt6-multimedia-6.4.2/debian/rules   2023-11-28 18:26:47.950137854 +0100
> > @@ -9,6 +9,10 @@
> > cmake_extra_args += -DQT_HOST_PATH=/usr
> >  endif
> >  
> > +ifneq (,$(filter $(DEB_HOST_ARCH),powerpc))
> > +   cmake_extra_args += -DCOMPILE_DEFINITIONS="EIGEN_DONT_VECTORIZE"
> > +endif
> > +
> >  %:
> > dh $@ --with pkgkde_symbolshelper --buildsystem=cmake+ninja
> >  
> > With the above change, cmake defines the preprocessor macro 
> > EIGEN_DONT_VECTORIZE and
> > the build succeeds on powerpc.
> 
> With qt6-multimedia 6.6.2 qt6-multimedia still fail to build even with
> this patch.
> 
> I'm unable to find a solution. Adrian do you have an idea ?

The syntax of my proposed solution was wrong. My local tests were not performed
on a clean source which is why I did not notice the suggested syntax didn't 
work.

The proper syntax is:

ifneq (,$(filter $(DEB_HOST_ARCH),powerpc))
export DEB_CXXFLAGS_MAINT_APPEND = -DEIGEN_DONT_VECTORIZE
endif

@Patrick: Could you update the debian/rules file please to use the above syntax?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1

[John Paul Adrian Glaubitz]

Hi,

On Sat, 2024-06-08 at 09:15 +0200, Chris Hofstaedtler wrote:
> > > I will take care of this myself. Please remove the upload.
> 
> Done.

Thanks.

> 
> > I will try to fix the package tomorrow. Apologies for the delay.
> 
> I'll take this opportunity to point out #1060195, a similar bug in
> hfsprogs.

Thanks for the reminder. Appreciate it.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1

[John Paul Adrian Glaubitz]

Hello,

On Fri, 2024-06-07 at 22:14 +0200, John Paul Adrian Glaubitz wrote:
> On Fri, 2024-06-07 at 21:42 +0200, Chris Hofstaedtler wrote:
> > I've prepared an NMU for linux-minidisc (versioned as 0.9.16-2.1) and
> > uploaded it to DELAYED/14. Please feel free to tell me if I
> > should delay it longer.
> 
> I will take care of this myself. Please remove the upload.

Sorry for the brevity in my previous mail.

The reason I didn't fix this bug was because I missed the bug notification
mail, so I wasn't aware this bug was around.

I will try to fix the package tomorrow. Apologies for the delay.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1

[John Paul Adrian Glaubitz]

Hello,

On Fri, 2024-06-07 at 21:42 +0200, Chris Hofstaedtler wrote:
> I've prepared an NMU for linux-minidisc (versioned as 0.9.16-2.1) and
> uploaded it to DELAYED/14. Please feel free to tell me if I
> should delay it longer.

I will take care of this myself. Please remove the upload.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072774: zfs-linux: draid autopkgtests fail on s390x architecture

[John Cabaj]

Package: zfs-linux
Version: 2.2.4-1
Severity: normal
X-Debbugs-Cc: john.ca...@canonical.com

Dear Maintainer,

Presently, zfs-linux fails when running draid tests from 
kernel-smoke-tests in debian/tests on s390x architecture with
the following error:

"kernel smoke test, create and destroy pool, draid1: FAILED: zpool create 
failed, exit code=1"

I have logs available if necessary, and have access to a s390x
machine to aid with testing if helpful.

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-35-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1072769: libvirt-daemon: Cannot connect to hypervisor with user session after upgrade

[Simon John]

Package: libvirt-daemon
Version: 10.4.0-1
Severity: important

Dear Maintainer,

I just did a Sid dist-upgrade and apart from a bunch of t64 packages, it 
upgraded libvirt-daemon (etc) to 10.4.0-1


Then I could no longer connect to qemu://session from virt-manager or 
virsh, I got the errors:


error: failed to connect to the hypervisor

virsh error: Cannot recv data: Connection reset by peer

In journalctl I was also seeing this:

internal error: could not find a usable firewall backend

Initialization of bridge state driver failed: internal error: 
could not find a usable firewall backend


I use nftables (not firewalld). I tried installing firewalld, restarting 
libvirtd and rebooting all to no avail.


Strangely enough I could run "virsh -c qemu:///system list" as my 
regular user although I got no output (I have no system VM's) it didn't 
error, so I assume its a permissions change or simply a bug in 10.4?


Downgrading to 10.3.0-3 versions of these packages fixed the issue:

libvirt0_10.3.0-3_amd64.deb
libvirt-clients_10.3.0-3_amd64.deb
libvirt-daemon_10.3.0-3_amd64.deb
libvirt-daemon-config-network_10.3.0-3_all.deb
libvirt-daemon-config-nwfilter_10.3.0-3_all.deb
libvirt-daemon-driver-lxc_10.3.0-3_amd64.deb
libvirt-daemon-driver-qemu_10.3.0-3_amd64.deb
libvirt-daemon-driver-vbox_10.3.0-3_amd64.deb
libvirt-daemon-system_10.3.0-3_amd64.deb
libvirt-daemon-system-systemd_10.3.0-3_all.deb
libvirt-l10n_10.3.0-3_all.deb
libvirt-login-shell_10.3.0-3_amd64.deb
python3-libvirt_10.3.0-1_amd64.deb

I also tried 10.0.0-2 and that seemed to fix it too (didn't try "virsh 
start" but "virsh list" worked) which I think was the version I was on 
beforehand, or 9.x


I dug around for hours trying to find a useful error message or pointer 
to a reason (logs, strace, config etc.) but found nothing, any ideas?


Regards.

--
Simon John

Bug#1051579: nomacs: segmentation fault in std::__atomic_base

[John Dorian]

On Sun, 10 Sep 2023 01:01:50 +0200 Vincent Lefevre 
wrote:> Package: nomacs
> Version: 3.17.2282+dfsg-2
> Severity: important
>
> I got a segmentation fault when doing "View -> Close Tab" then
> a double click on a directory.
>

Thank you for reporting. This has been fixed in the following pull request.

https://github.com/nomacs/nomacs/pull/1087

Bug#1071117: fccexam: update question pool and URL

[John Nogatch]

On Tue, May 14, 2024 at 4:57 PM Austen, Jeffrey  wrote:
> Package: fccexam
> Version: 1.0.7-1.1
...
> Please update the question pool. Element 7 has changed. ...
> The URL in the package description should be updated ...

fccexam 1.0.8 is available at:
https://launchpad.net/~jnogatch/+archive/ubuntu/fccexam

This version includes the updates that you requested.

-John AC6SL

Bug#1072407: Fix is coming

[John Horigan]

I am fixing this FFmpeg API change in upstream. The new version builds
under unstable and experimental. I have uploaded an updated package to
mentors.debian.net. You should see it soon.

-- john

Bug#1072574: kernel-wedge: Enable Renesas RZ/G3S and RZ/V2H boards

[John]

Package: kernel-wedge
Severity: important
Tags: d-i
X-Debbugs-Cc: john.vincent...@bp.renesas.com

Dear Maintainer,

Please enable Renesas RZ/G3S and RZ/V2H device support in Debian by updating 
the following configurations:

CONFIG_ARCH_R9A09G057=y #RZ/V2H
CONFIG_ARCH_R9A08G045=y #RZ/G3S

Best Regards
John

-- System Information:
Debian Release: 11.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-30-amd64 (SMP w/4 CPU threads)
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 kernel-wedge depends on:
pn  debhelper  
ii  make   4.3-4.1

kernel-wedge recommends no packages.

kernel-wedge suggests no packages.

Bug#1051068: sysprof: Should mark test build dependencies as

[John Paul Adrian Glaubitz]

On Tue, 2024-06-04 at 10:36 -0400, Jeremy Bícha wrote:
> On Sat, Sep 2, 2023 at 4:22 PM Jeremy Bícha  
> wrote:
> > 
> > Control: tags -1 moreinfo
> > 
> > On Sat, Sep 2, 2023 at 2:06 AM John Paul Adrian Glaubitz
> >  wrote:
> > > src:sysprof has multiple build dependencies in debian/control which are
> > > required for running the testsuite only but yet these build dependencies
> > > are not marked as  to allow the package to be bootstrapped on
> > > a new architecture.
> > 
> > I was unable to identify any build dependencies like that. Please
> > submit a merge proposal if you have specific improvements in mind.
> 
> I am closing this bug since there has been no reply and there wasn't
> enough information in this bug report to take any action.

Hmm, I'm pretty sure that these were obvious.

I will have to recheck.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072539: ipywidgets: Recent changes introduced nodejs dependency limiting portability

[John Paul Adrian Glaubitz]

Source: ipywidgets
Version: 8.1.2-3
Severity: important

Hello,

the recent change to obsolete some binary packages in ipywidgets [1] introduced 
a hard
dependency on nodejs which is available on a limited set of architectures only 
making
ipywidgets uninstallable on a number of architectures:

- alpha
- hppa
- hurd-amd64
- hurd-i386
- m68k
- powerpc
- ppc64
- sh4
- sparc64
- x32

Would it be possible to revert this change to remove the introduced dependency 
on nodejs
again?

Thanks,
Adrian

> [1] 
> https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/ab52650adf13fd9f82f66dc1b328d04128496dcf

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#635834: Revisiting inclusion of AcroTeX/eForms in TeX Live in light of advancements in libre PDF readers

[John Scott]

Hello,

I must disclaim that I've not used these packages yet and would welcome being 
informed if I'm mistaken.

It looks like both TeX Live and Debian have had reservations about shipping 
AcroTeX and eForms because at the time it was considered, the only PDF readers 
that appeared to support the features were proprietary ones. However, it seems 
that free PDF viewers have made great strides in the past several years 
especially in supporting these advanced features, so I think their inclusion in 
the standard distribution should be reconsidered.

Free PDF viewers, especially Okular with the Poppler backend, have gained 
support for many of the features that have been standardized, including non-XFA 
forms, digital/cryptographic signature support, and JavaScript, all things that 
eForms appears to assist in making. There are probably still some things that 
AcroTeX and eForms can do that only proprietary readers support, but unless 
software patents muddy the waters, it seems like this can improve in client 
software at any time.

Frankly I'm itching to use this functionality in my documents, but as a strong 
advocate for free software as well, I'd like to be informed if there are any 
freedom or distribution issues remaining.

Thanks,
John

P.S. I'm having trouble subscribing, so please CC me on replies.

-- 
Homepage: https://johnscott.me
Contact info:
as a vCard: https://johnscott.me/me/me.vcf
or as an LDAP directory entry: 
ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me


signature.asc
Description: This is a digitally signed message part


smime.p7s
Description: S/MIME cryptographic signature

Bug#944139: Another possible solution

[John Bazik]

I can confirm that Christopher's patch, 
https://salsa.debian.org/debian/debmirror/-/merge_requests/15, fixes the 
original problem.

John

Bug#1072481: RFP: cockpit-filesharing — A plugin for Cockpit to manage Samba and NFS shares.

[John Cooper]

Package: wnpp
Severity: wishlist

The software enables the capacity to manage the network shares provided by 
Samba and NFS, via Cockpit. This is for the server on which Cockpit is 
installed, or can be connected to through the multiple server functionality of 
web interface daemon.

The original official developers are concentrating on RPM based distributions, 
but do have a Debian repository. However it’s only valid for Debian 11 and 
Ubuntu Linux up to 20.04.

https://github.com/45Drives/cockpit-file-sharing

Sent from my iPad

Bug#1072479: RFP: cockpit-navigator — Web based file browser for cockpit to navigate filesystem.

[John Cooper]

Package: wnpp
Severity: wishlist 

The package is really useful as it allows users, to navigate the filesystem of 
the server, on which the instance of Cockpit installed on. In order to manage 
its filesystem without, needing to connect and login with SSH to do so.

The official developers of the software are currently concentrating on RPM 
distributions. They do have a Debian repository however the packages, are only 
built for Bullseye and not Debian Linux 12 or even the upcoming Debian Linux 13.

https://github.com/45Drives/cockpit-navigator

Sent from my iPad

Bug#1072382: nextcloud-desktop: Randomly starts, keeps restarting on exit

[John Doe]

Package: nextcloud-desktop
Version: 3.11.0-1.1+b1
Severity: normal
X-Debbugs-Cc: contrapunc...@disroot.org

Dear Maintainer,

The Nextcloud desktop application often seems to start of its own accord, and
frequently restarts when I exit it (by right clicking the tray icon - Exit
Nextcloud).


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 nextcloud-desktop depends on:
ii  libc6  2.38-11
ii  libcloudproviders0 0.3.6-1
ii  libgcc-s1  14-20240330-1
ii  libglib2.0-0t642.80.2-2
ii  libkf5archive5 5.115.0-2
ii  libnextcloudsync0t64   3.11.0-1.1+b1
ii  libqt5core5t64 5.15.10+dfsg-7.2+b1
ii  libqt5dbus5t64 5.15.10+dfsg-7.2+b1
ii  libqt5gui5t64  5.15.10+dfsg-7.2+b1
ii  libqt5keychain10.14.3-1
ii  libqt5network5t64  5.15.10+dfsg-7.2+b1
ii  libqt5qml5 5.15.10+dfsg-2+b2
ii  libqt5quick5   5.15.10+dfsg-2+b2
ii  libqt5quickcontrols2-5 5.15.10+dfsg-2+b2
ii  libqt5sql5-sqlite  5.15.10+dfsg-7.2+b1
ii  libqt5svg5 5.15.10-2+b2
ii  libqt5webenginecore5   5.15.15+dfsg-2+b1
ii  libqt5webenginewidgets55.15.15+dfsg-2+b1
ii  libqt5widgets5t64  5.15.10+dfsg-7.2+b1
ii  libssl3t64 3.2.1-3
ii  libstdc++6 14-20240330-1
ii  nextcloud-desktop-common   3.11.0-1.1
ii  nextcloud-desktop-l10n 3.11.0-1.1
ii  qml-module-qt-labs-platform5.15.10+dfsg-2+b2
ii  qml-module-qtgraphicaleffects  5.15.10-2+b2
ii  qml-module-qtqml   5.15.10+dfsg-2+b2
ii  qml-module-qtqml-models2   5.15.13+dfsg-2
ii  qml-module-qtquick-controls2   5.15.10+dfsg-2+b2
ii  qml-module-qtquick-layouts 5.15.10+dfsg-2+b2
ii  qml-module-qtquick-window2 5.15.10+dfsg-2+b2
ii  qml-module-qtquick25.15.10+dfsg-2+b2

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  3.11.0-1.1

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#1072345: gcc-14: FTBFS on x32 due to missing package gccrs-14-x86-64-linux-gnux32

[John Paul Adrian Glaubitz]

OK, it seems that this is because of x32 being part of "rs_no_cpu"
in debian/rules.defs.

So, please remove x32 from the Rust exclusion list and add cargo to
BuildDepends in debian/control.

It remains to be resolved why the build tries to enable Rust support
despite x32 being in "rs_no_cpu" in debian/rules.defs.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072345: gcc-14: FTBFS on x32 due to missing package gccrs-14-x86-64-linux-gnux32

[John Paul Adrian Glaubitz]

Source: gcc-14
Version: 14.1.0-1
Severity: normal

Hello,

trying to build gcc-14 on x32 fails because the package 
gccrs-14-x86-64-linux-gnux32
is missing in debian/control so that the call to dh_installdirs fails:

dh_installdirs -pgccrs-14-x86-64-linux-gnux32 usr/bin usr/share/man/man1 
usr/libexec/gcc/x86_64-linux-gnux32/14 usr/share/lintian/overrides
dh_installdirs: error: Requested unknown package gccrs-14-x86-64-linux-gnux32 
via -p/--package, expected one of: gcc-14-base libgcc-s1
(...)
gccrs-14-for-build gccrs-14 gcc-14-source
dh_installdirs: error: unknown option or error during option parsing; aborting

I assume the oversight was that on x32, the architecture is not used as a 
package prefix
but a package suffix, i.e. gccrs-14-x86-64-linux-gnux32 instead of 
gccrs-14-x32-linux-gnu.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072336: gcc-14: FTBFS on x32 due to outdated symbols file libasan8.symbols

[John Paul Adrian Glaubitz]

Source: gcc-14
Version: 14.1.0-1
Severity: normal

Hello,

after installing cargo manually in the chroot to work around #1072327 [1], I
ran into an FTBFS on x32 due to an outdated symbols file libasan8.symbols:

dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libasan8/DEBIAN/symbols doesn't match 
completely debian/libasan8.symbols
--- debian/libasan8.symbols (libasan8_14.1.0-1_x32)
+++ dpkg-gensymbolsRcyeWc   2024-06-01 08:50:52.822957692 +
@@ -402,7 +402,7 @@
  ___interceptor_setlocale@Base 14
  ___interceptor_setpwent@Base 14
  ___interceptor_setvbuf@Base 14
- ___interceptor_shmctl@Base 14
+#MISSING: 14.1.0-1# ___interceptor_shmctl@Base 14
  ___interceptor_sigaction@Base 14
  ___interceptor_sigaltstack@Base 14
  ___interceptor_sigandset@Base 14
@@ -1579,7 +1579,7 @@
  __interceptor_trampoline_setlocale@Base 14
  __interceptor_trampoline_setpwent@Base 14
  __interceptor_trampoline_setvbuf@Base 14
- __interceptor_trampoline_shmctl@Base 14
+#MISSING: 14.1.0-1# __interceptor_trampoline_shmctl@Base 14
  __interceptor_trampoline_sigaction@Base 14
  __interceptor_trampoline_sigaltstack@Base 14
  __interceptor_trampoline_sigandset@Base 14
dh_makeshlibs: error: failing due to earlier errors

I have uploaded the full gzipped build log in [2] since there were additional
messages regarding symbols.

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072327
> [2] http://people.debian.org/~glaubitz/gcc-14_14.1.0-1_x32.build.gz

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1063735: python-maturin - upcoming rust-indexmap update.

[John Paul Adrian Glaubitz]

Package: python-maturin
Followup-For: Bug #1063735
Control: severity -1 serious

Hello,

I am setting the severity to serious now as this actually causes python-maturin
to fails to build from source [1]:

cargo generate-lockfile --offline
error: failed to select a version for the requirement `indexmap = "^1.9.3"`
candidate versions found which didn't match: 2.2.6
location searched: directory source `/usr/share/cargo/registry` (which is 
replacing registry `crates-io`)
required by package `maturin v1.3.2 (/<>)`
perhaps a crate was updated and forgotten to be re-vendored?

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=python-maturin=sparc64=1.3.2-1=1717193660=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072328: gcc-14: Please add 32-bit SPARC (sparc) to ada_no_cpu

[John Paul Adrian Glaubitz]

Source: gcc-14
Version: 14.1.0-1
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hello,

I am currently building a cross-compiler for 32-bit SPARC (sparc) and
noticed that I had to disable Ada by adding "sparc" to "ada_no_cpu"
in debian/rules.defs to get the compiler to build due to #1072071 [1].

Since I don't expect #1072071 to be fixed quickly, it would be good to
just to add "sparc" to "ada_no_cpu" in debian/rules.defs.

PS: Please note, this bug does not affect sparc64! There are no changes
required for sparc64.

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072071

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072327: gcc-14: Missing cargo build dependency on x32

[John Paul Adrian Glaubitz]

Source: gcc-14
Version: 14.1.0-1
Severity: normal

Hello,

The gcc-14 source package is missing cargo as build dependency which is
why the build currently fails with [1]:

> configure: error: cargo is required to build rust

cargo was briefly not available on x32, but is installable again.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-14=x32=14.1.0-1=1715675531=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072283: chromium: Chromium FTBFS Depends: rustc-web but it is not installable

[John Hughes]

Package: chromium
Version: 125.0.6422.112-1~deb12u1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

   * What led up to the situation?

Tried to build chromium

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

apt source chromium
apt build-dep chromium

   * What was the outcome of this action?

Depends: rustc-web but it is not installable

   * What outcome did you expect instead?

Many hours of compilation followed by an installable chromium


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common125.0.6422.112-1~deb12u1
ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-02.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libc6  2.36-9+deb12u7
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-3+deb12u5
ii  libdav1d6  1.0.0-2+deb12u1
ii  libdbus-1-31.14.10-1~deb12u1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm22.4.114-1+b1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-5
ii  libgbm122.3.6-1+deb12u1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.6-2+deb12u2
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libharfbuzz-subset06.0.0+dfsg-3
ii  libharfbuzz0b  6.0.0+dfsg-3
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-2
ii  libminizip11.1-8+deb12u1
ii  libnspr4   2:4.35-1
ii  libnss32:3.87.1-1
ii  libopenh264-7  2.3.1+dfsg-3
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpng16-161.6.39-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.9-3
ii  libstdc++6 12.2.0-14
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3~deb12u1
ii  libxnvctrl0525.85.05-3~deb12u1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  xdg-desktop-portal-gnome [xdg-desktop-portal-back  43.1-2
end]
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backen  1.14.1-1
d]
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  125.0.6422.112-1~deb12u1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6 2.36-9+deb12u7
ii  libdrm2   2.4.114-1+b1
ii  libjsoncpp25  1.9.5-4
ii  libstdc++6

Bug#1069625: Acknowledgement (gstreamer1.0: Don't build ptp-helper on hppa)

[John Paul Adrian Glaubitz]

Hello,

the suggested patch is incomplete as it breaks the installation of ptp-helper
on architectures with Rust support by just removing it from the .install file.

I have improved the patch in this regard by employing dh-exec and extended it
for the remaining Debian Ports architectures without Rust support (alpha, m68k
and sh4). I intentionally omitted ia64 as it will be dropped from Debian Ports
within the next days.

NB: For dh-exec to work, the file libgstreamer1.0-0.install *must* be 
executable.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/gstreamer1.0-1.24.3/debian/changelog new/gstreamer1.0-1.24.3/debian/changelog
--- old/gstreamer1.0-1.24.3/debian/changelog	2024-04-30 10:40:18.0 +0200
+++ new/gstreamer1.0-1.24.3/debian/changelog	2024-05-28 07:57:26.535826780 +0200
@@ -1,3 +1,9 @@
+gstreamer1.0 (1.24.3-1+ports) unreleased; urgency=medium
+
+  * Disable rustc for unsupported architectures
+
+ -- John Paul Adrian Glaubitz   Tue, 28 May 2024 07:57:09 +0200
+
 gstreamer1.0 (1.24.3-1) unstable; urgency=medium
 
   * New upstream version 1.24.3
diff -Nru old/gstreamer1.0-1.24.3/debian/control new/gstreamer1.0-1.24.3/debian/control
--- old/gstreamer1.0-1.24.3/debian/control	2024-04-30 10:40:18.0 +0200
+++ new/gstreamer1.0-1.24.3/debian/control	2024-05-28 11:16:10.247257446 +0200
@@ -6,6 +6,7 @@
Sjoerd Simons ,
Marc Leeman ,
 Build-Depends: debhelper-compat (= 13),
+   dh-exec,
dh-sequence-gir,
meson (>= 0.62),
pkgconf,
@@ -18,7 +19,7 @@
libdw-dev [i386 amd64 armel armhf arm64 powerpc ppc64 ppc64el mipsel mips64el riscv64],
bison,
flex,
-   rustc,
+   rustc [!alpha !hppa !m68k !sh4],
libgirepository1.0-dev,
gir1.2-glib-2.0,
gir1.2-freedesktop,
diff -Nru old/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install new/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install
--- old/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install	2024-04-30 10:37:47.0 +0200
+++ new/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install	2024-05-28 07:55:56.540429867 +0200
@@ -1,5 +1,6 @@
+#!/usr/bin/dh-exec
 usr/lib/*/gstreamer-1.0/*.so
 usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner
-usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper
+[!alpha !hppa !m68k !sh4] usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper
 usr/lib/*/*.so.*
 usr/share/locale
diff -Nru old/gstreamer1.0-1.24.3/debian/rules new/gstreamer1.0-1.24.3/debian/rules
--- old/gstreamer1.0-1.24.3/debian/rules	2024-04-30 10:37:47.0 +0200
+++ new/gstreamer1.0-1.24.3/debian/rules	2024-05-28 09:39:31.503804282 +0200
@@ -44,6 +44,10 @@
 conf_flags += -Dlibunwind=disabled -Dlibdw=disabled
 endif
 
+ifneq (,$(filter $(DEB_HOST_ARCH),alpha hppa m68k sh4))
+conf_flags += -Dptp-helper=disabled
+endif
+
 infiles := \
 	libgstreamer1.0-0.postinst
 

Bug#1072071: gcc-13: Please add libatomic for 32-bit SPARC for Ada

[John Paul Adrian Glaubitz]

Source: gcc-13
Version: 13.2.0-25
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hello,

I just tried to build a cross-compiler for 32-bit SPARC (Debian arch sparc)
with Ada enabled. The build failed with a linker failure which indicates
that linking against libatomic is required:

checking float.h presence... yes
checking for float.h... yes
checking fp.h usability... /usr/sparc-linux-gnu/bin/ld: libgnat-13.so: 
undefined reference to `__atomic_compare_exchange_8'
collect2: error: ld returned 1 exit status

Such a patch already exists for armel [1], so it should be easy to extend
it for 32-bit SPARC. 64-bit SPARC (Debian arch sparc64) is not affected,
linking against libatomic is therefore not required.

Thanks,
Adrian

> [1] 
> https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-13-debian/debian/patches/ada-armel-libatomic.diff

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#970043: Request to help test ia64 build for galera-4

[John Paul Adrian Glaubitz]

evel/2023-05/msg00051.html
> 
> In general I thought that UEFI was derived from EFI, so I don't really 
> see, why both can't coexist together. But I might have to do further 
> research on that. Apart from that, ELILO is working perfectly fine both 
> for diskless boots and booting from disk.

ELILO is unmaintained and has had various issues and bugs in the past which is 
why
I switched to GRUB on Debian back then. But it also looks like that ia64 support
is going to stay in GRUB for a while, I haven't seen any new efforts for 
removing
it lately on the grub-devel mailing list.

> > - ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual
> >address space found on x86_64;
> 
> Yes, it was done earlier than x86_64.
> 
> > this causes problems with languages like
> >JavaScript which use tagged pointers to encode type information in the
> >bits unused on x86_64, see:
> > 
> >> https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18)
> > 
> >(NB: This is expected to improve in the future as x86_64 optionally 
> > supports
> > larger virtual address spaces in the kernel nowadays as well).
> > 
> > - the math error handling ABI on ia64 in glibc is different from other 
> > architectures
> >and the code for it in sysdeps/ia64/fpu/libm_error.c is quite 
> > convoluted; as glibc
> >tries to unify and simplify FPU error handling, the different semantics 
> > of the ia64
> >ABI would require - quoting Adhemerval here - »a lot boilerplate and 
> > mechanical
> >changes« which he doesn't think is worth the effort
> 
> I think we could have done more in this regard, if ia64 support wouldn't 
> have been removed from Linux last year, requiring additional work 
> everywhere. But I don't complain, I think it also forced our hands.

Well, I have done a lot of work in this regard in the past to get JavaScript 
fixed on
targets with virtual address space sizes beyond 48 bits. But it's still not 
fixed
everywhere, especially not in Qt5. It has been fixed in Qt6 though.

> > There are probably more issues and quirks that I don't remember, but I 
> > think the list
> > above already mentions enough show stoppers which mean that upstream 
> > projects won't be
> > willing to re-add support for the architecture.
> 
> Thanks for your assessment. I consider that much more useful than to 
> advise people against working on ia64.

I'm not advising against you to do anything. You are free to spend your free 
time with
whatever you want and if you think that keeping ia64 is worth the effort, more 
power to
you! All I did was giving an elaborate explanation why ia64 is going to be 
removed from Debian
within the next days and why I personally think it's a lost cause.

> > Of course, I am not going to stop you from continuing your work and I think 
> > such efforts
> > are always laudable. I just don't think the very limited interest in this 
> > architecture
> > will be enough to overcome the difficulties that ia64 maintainers have to 
> > face.
> > 
> > This is also the reason why the ia64 maintainers of neither Debian nor 
> > Gentoo were against
> > the removal of support for the architecture in Ruby, the Linux kernel, 
> > glibc and so on.
> 
> Being not against something and taking care of something are two 
> different things.

But why would maintainers start an argument with upstream developers over 
something they don't
really care about? That makes no sense.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#970043: Request to help test ia64 build for galera-4

[John Paul Adrian Glaubitz]

Hello Frank,

On Sat, 2024-05-25 at 18:29 +0200, Frank Scheiner wrote:
> > ia64 support has been removed from glibc, the Linux kernel and soon gcc,
> 
> First - ia64 support was actually removed from the glibc **because** it 
> was removed from Linux.

It was also removed because there was no maintainer for it in glibc and
suffered from a lot of testsuite failures. I tried for a long time to
convince Adhemerval to fix these issues, but he explained that it would
involve rewriting large parts of the math code for ia64 which he thought
wasn't worth the effort.

> Second, how did you come to the conclusion that ia64 support will be 
> removed from the gcc soon?

gcc usually drops support for a target when it's no longer present in the
kernel and glibc. That happened in the past and that will happen in the
future, although there are some targets like Blackfin, CRIS and M32R that
are still supported by gcc while being dropped by the kernel.

And since ia64 support has already been marked as deprecated, I expect it
to be removed from gcc soon. Especially, since ia64 adds a lot of complexity
to gcc due to its VLIW design.

> Rene said he would step up as maintainer for ia64 in gcc - see the 
> thread at [1] - and I haven't heard any different since then.
> 
> [1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html
> 
> @Rene: Can you confirm?

As of now, gcc is still marked as deprecated:

> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=a37113bd00aef1412771f7dd630abebabd444c1f;hb=HEAD#l273

> > so it will be removed within the next weeks after we have made an archive
> > copy.
> > 
> > There is no need to fix any bugs on ia64.
> 
> Let me correct that for you:
> 
> There is no need to fix any bugs for ia64 in Debian (Ports) - as sad as 
> that is.

Have you already sorted out who is going to maintain ia64 support in glibc
and the Linux kernel? And do you already know how to get Ruby upstream to
re-add ia64 support? Ruby is required for a lot of other packages that depend
on it.

As someone who has been maintaining many exotic or deprecated architectures
both in Debian and in the Linux kernel, I know how much work it involves to
keep a port alive and running. And since I have also maintained ia64 in the
past and know about all the quirks and problems the port has, I think the
possibility that the port will ever return upstream to the kernel, glibc
and the Ruby interpreter is nearly zero.

To summarize the known issues and quirks on ia64:

- ia64 has two stacks growing in opposite directions making exception handling
  in languages like Ruby more complicated and requiring additional code, see:

  > https://github.com/ruby/ruby/blob/master/doc/NEWS/NEWS-2.7.0 (search for 
IA64)

- the VLIW design adds a lot of complexity to the compiler; when it was created,
  designers expected the design to be superior but it turned out that the
  implementation was more challenging than expected and left gcc with a lot of
  unresolved problems on ia64, see:

  > https://gcc.gnu.org/projects/ia64.html

- ia64 comes with its own implementation of EFI which is not fully compatible
  with UEFI and requires additional support code; this was the main reason why
  some GRUB developers wanted to get rid of ia64 support, see:

  > https://lists.gnu.org/archive/html/grub-devel/2023-05/msg00051.html

- ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual
  address space found on x86_64; this causes problems with languages like
  JavaScript which use tagged pointers to encode type information in the
  bits unused on x86_64, see:

  > https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18)

  (NB: This is expected to improve in the future as x86_64 optionally supports
   larger virtual address spaces in the kernel nowadays as well).

- the math error handling ABI on ia64 in glibc is different from other 
architectures
  and the code for it in sysdeps/ia64/fpu/libm_error.c is quite convoluted; as 
glibc
  tries to unify and simplify FPU error handling, the different semantics of 
the ia64
  ABI would require - quoting Adhemerval here - »a lot boilerplate and 
mechanical
  changes« which he doesn't think is worth the effort

There are probably more issues and quirks that I don't remember, but I think 
the list
above already mentions enough show stoppers which mean that upstream projects 
won't be
willing to re-add support for the architecture.

Of course, I am not going to stop you from continuing your work and I think 
such efforts
are always laudable. I just don't think the very limited interest in this 
architecture
will be enough to overcome the difficulties that ia64 maintainers have to face.

This is also the reason why the ia64 maintainers of neither Debian nor Gentoo 
were against
the removal of support for the architecture in Ruby, the Linux kernel, glibc 
and so on.

Adrian

-- 
 .''`.  Joh

Bug#970043: Request to help test ia64 build for galera-4

[John Paul Adrian Glaubitz]

Hi Otto,

On Fri, 2024-05-24 at 21:24 -0700, Otto Kekäläinen wrote:
> I have a patch to tentatively fix Debian package galera-4 builds on
> ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19
> 
> Would anybody be interested in helping out and testing if the build
> fully passes now?
> 
> Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043

ia64 support has been removed from glibc, the Linux kernel and soon gcc,
so it will be removed within the next weeks after we have made an archive
copy.

There is no need to fix any bugs on ia64.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm?

[John Waffle]

Hello,

I was thinking about this a bit more and I had a question,

> Let me as well elaborate on the "ingored". This comes as the binary
packages built from the *vulnerable* source, there is no point to force an
update in bookworm and older.

It sounds like Debian uses the "ignored" state to mean "this bug does not
affect the Debian package".

Is there another state that's used to indicate "won't fix"? Can we assume
that "ignored" always means "won't fix"? Or can "ignored" mean either thing
and we'd have to look in the notes to know for sure?

Thanks,
- J

On Wed, May 22, 2024 at 9:56 AM John Waffle  wrote:

> Hello,
>
> I got a response from trivy,
> https://github.com/aquasecurity/trivy/discussions/6722#discussioncomment-9518531
>
> > Helllo @superlazyname <https://github.com/superlazyname>
> > Thanks for your report!
>
> > As you can see - we marked this vulnerability as "Status":
> "will_not_fix",.
> > We use will_not_fix for vulnerabilities with ignored State.
> > We can't parse State description, because it deoesn't have format.
>
> > [bookworm] - zlib (contrib/minizip not built and producing binary
> packages)
>
> > It seems that debian chose wrong state. not_affected looks more correct.
> --
>
> > Trivy supports VEX
> <https://aquasecurity.github.io/trivy/v0.51/docs/supply-chain/vex/>.
> > You can create VEX file to ignore this CVE.
>
> > Regards, Dmitriy
>
> I'll call out these particular points,
>
> > We can't parse State description, because it doesn't have format.
>
> > It seems that debian chose wrong state. not_affected looks more correct.
>
> It sounds like this is some kind of incompatibility between how trivy
> conceptualizes CVEs vs how Debian conceptualizes CVEs, plus a terminology
> problem on the meaning of "ignored" (won't fix vs is not affected)
>
> - Would you consider marking the vulnerability as "not_affected" instead
> of "ignored"? Or does the Debian CVE tracking system not support that?
>
> - I would agree that " [bookworm] - zlib (contrib/minizip not built and
> producing binary packages)" doesn't have a standard format, but is there no
> other viable way for a scanner to pick up on the CVE being ignored?
>
> - Do you have docs to show what method should be used to properly handle
> this issue being marked as "ignored"? Do you have any sample code / script
> snippets you can share with me? Maybe I can submit a PR?
>
> Maybe there is some way for trivy to notice that the issue is "ignored"
> and then, for only Debian, interpret that as not_affected.
>
> - John
>
> On Sat, May 18, 2024 at 5:03 AM Salvatore Bonaccorso 
> wrote:
>
>> Hi John,
>>
>> On Fri, May 17, 2024 at 04:01:56PM -0400, John Waffle wrote:
>> > This report came from a free tool, trivy, I filed a Github discussion
>> about
>> > it here: https://github.com/aquasecurity/trivy/discussions/6722
>>
>> Thanks a lot for bringing that upstream.
>>
>> So to add some additional datapoint: The issue araises here by maybe
>> thinking zlib refers to the binary package produced. It is correct,
>> for the binary package zlib then indeed you would not be vulnerable.
>>
>> Let me as well elaborate on the "ingored". This comes as the binary
>> packages built from the *vulnerable* source, there is no point to
>> force an update in bookworm and older.
>>
>> I hope this all get a better picture now on the CVE. If you still have
>> questions feel free to ask.
>>
>> Regards,
>> Salvatore
>>
>

Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm?

[John Waffle]

Hello,

I got a response from trivy,
https://github.com/aquasecurity/trivy/discussions/6722#discussioncomment-9518531

> Helllo @superlazyname <https://github.com/superlazyname>
> Thanks for your report!

> As you can see - we marked this vulnerability as "Status": "will_not_fix",
.
> We use will_not_fix for vulnerabilities with ignored State.
> We can't parse State description, because it deoesn't have format.

> [bookworm] - zlib (contrib/minizip not built and producing binary
packages)

> It seems that debian chose wrong state. not_affected looks more correct.
--

> Trivy supports VEX
<https://aquasecurity.github.io/trivy/v0.51/docs/supply-chain/vex/>.
> You can create VEX file to ignore this CVE.

> Regards, Dmitriy

I'll call out these particular points,

> We can't parse State description, because it doesn't have format.

> It seems that debian chose wrong state. not_affected looks more correct.

It sounds like this is some kind of incompatibility between how trivy
conceptualizes CVEs vs how Debian conceptualizes CVEs, plus a terminology
problem on the meaning of "ignored" (won't fix vs is not affected)

- Would you consider marking the vulnerability as "not_affected" instead of
"ignored"? Or does the Debian CVE tracking system not support that?

- I would agree that " [bookworm] - zlib (contrib/minizip not built and
producing binary packages)" doesn't have a standard format, but is there no
other viable way for a scanner to pick up on the CVE being ignored?

- Do you have docs to show what method should be used to properly handle
this issue being marked as "ignored"? Do you have any sample code / script
snippets you can share with me? Maybe I can submit a PR?

Maybe there is some way for trivy to notice that the issue is "ignored" and
then, for only Debian, interpret that as not_affected.

- John

On Sat, May 18, 2024 at 5:03 AM Salvatore Bonaccorso 
wrote:

> Hi John,
>
> On Fri, May 17, 2024 at 04:01:56PM -0400, John Waffle wrote:
> > This report came from a free tool, trivy, I filed a Github discussion
> about
> > it here: https://github.com/aquasecurity/trivy/discussions/6722
>
> Thanks a lot for bringing that upstream.
>
> So to add some additional datapoint: The issue araises here by maybe
> thinking zlib refers to the binary package produced. It is correct,
> for the binary package zlib then indeed you would not be vulnerable.
>
> Let me as well elaborate on the "ingored". This comes as the binary
> packages built from the *vulnerable* source, there is no point to
> force an update in bookworm and older.
>
> I hope this all get a better picture now on the CVE. If you still have
> questions feel free to ask.
>
> Regards,
> Salvatore
>

Bug#1071542: boost1.83: Please enable context library on ppc64

[John Paul Adrian Glaubitz]

Source: boost1.83
Version: 1.83.0-2.1+b1
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hello,

the context library is not being installed on ppc64 in debian/control
despite being enabled in debian/rules.

Please add ppc64 to the list of supported architectures for the context
library and make sure it's actually being built and installed.

Tests can be performed on the porterbox perotto.debian.net.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1071524: git: Please add patch to fix testsuite on sparc64

[John Paul Adrian Glaubitz]

Source: git
Version: 1:2.45.1-1
Severity: normal
Tags: patch upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hello,

the attached patch fixes the Git testsuite on sparc64. I've already
sent it upstream [1]. Could you include it for the next package
upload?

Thanks,
Adrian

> [1] 
> https://lore.kernel.org/git/2024052009.99882-1-glaub...@physik.fu-berlin.de

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From 6580fdb9004e2d61fcb3d1f04c31bc7e328ed442 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz 
Date: Mon, 20 May 2024 13:03:49 +0200
Subject: [PATCH] chainlint.pl: Extend regexp pattern for /proc/cpuinfo on
 Linux SPARC

On SPARC systems running Linux, individual processors are denoted with
"CPUnn:" in /proc/cpuinfo instead of the usual "processor NN:" so that
the current regexp in ncores() returns 0. Extend the regexp to match
lines with "CPUnn:" as well to properly detect the number of available
cores on these systems.

Signed-off-by: John Paul Adrian Glaubitz 
---
 t/chainlint.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/chainlint.pl b/t/chainlint.pl
index 556ee91a15..63cac942ac 100755
--- a/t/chainlint.pl
+++ b/t/chainlint.pl
@@ -718,7 +718,7 @@ sub ncores {
# Windows
return $ENV{NUMBER_OF_PROCESSORS} if exists($ENV{NUMBER_OF_PROCESSORS});
# Linux / MSYS2 / Cygwin / WSL
-   do { local @ARGV='/proc/cpuinfo'; return 
scalar(grep(/^processor[\s\d]*:/, <>)); } if -r '/proc/cpuinfo';
+   do { local @ARGV='/proc/cpuinfo'; return 
scalar(grep(/^processor[\s\d]*:||^CPU[\d]*:/, <>)); } if -r '/proc/cpuinfo';
# macOS & BSD
return qx/sysctl -n hw.ncpu/ if $^O =~ /(?:^darwin$|bsd)/;
return 1;
-- 
2.39.2

Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm?

[John Waffle]

This report came from a free tool, trivy, I filed a Github discussion about
it here: https://github.com/aquasecurity/trivy/discussions/6722

On Fri, May 17, 2024 at 12:08 PM Salvatore Bonaccorso 
wrote:

> Hi,
>
> On Fri, May 17, 2024 at 10:43:26AM -0400, John Waffle wrote:
> > Package: zlib
> > Version: 1:1.2.13.dfsg-1
> >
> > Related bug reports:
> > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054290
> > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056718
> >
> > These were marked as resolved but it seems like I'm getting some
> > contradictory information.
> >
> > - The zlib package page https://tracker.debian.org/pkg/zlib says that
> > CVE-2023-45853 <
> https://security-tracker.debian.org/tracker/CVE-2023-45853>
> > is ignored, what is the basis for ignoring this CVE?
> > - Is there a plan to backport zlib 1:1.3.dfsg-3.1 to bookworm? It looks
> > like it's currently in trixie
> >
> > The maintainer of zlib said this in a comment
> > https://github.com/madler/zlib/pull/843#issuecomment-2050417533
> >
> > > Sigh. I tried.
> >
> > > It is this page:
> > https://security-tracker.debian.org/tracker/CVE-2023-45853 , that
> > incorrectly marks 1:1.2.13.dfsg-1 as vulnerable, when in fact it has no
> > minizip code in it whatsoever. (I verified that by downloading it and
> > listing the external symbols in the .so file.) I managed to reach someone
> > at debian.org who seems to be in control of that page, but instead of
> > fixing the page, they defended it, even though it's wrong.
> >
> > Can a Debian maintainer elaborate on this? Do the Debian maintainers feel
> > like this version of zlib is vulnerable or not?
> >
> > If the Debian maintainers could confirm that this is not a real
> > vulnerability, maybe then we can get trivy to stop flagging this as a
> > critical vulnerability in their scan. This is a rather big problem
> because
> > a lot of images use Debian (bookworm specifically) and a lot of base
> images
> > (e.g. nginx) are getting flagged for this.
>
> Again, the notes explain the tracking; The zlib is *source* in the
> security-tracker not the binary package produced. Thus the entry reads
> as:
>
> - zlib 1:1.3.dfsg-2 (bug #1054290)
> [bookworm] - zlib  (contrib/minizip not built and
> producing binary packages)
> [bullseye] - zlib  (contrib/minizip not built and
> producing binary packages)
> [buster] - zlib  (contrib/minizip not built and producing
> binary packages)
>
> is there in the wording which you think needs improvement?
>
> Why does your security-scanner not consider the information gathered
> by the security-tracker including the 'ignored' state there? Can you
> bring that to your vendor of the security scanner?
>
> Regards,
> Salvatore
>

Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm?

[John Waffle]

Hi Mark,

How do I get in contact with them, should I just send a message to
secur...@debian.org?

Thanks,
- J

On Fri, May 17, 2024 at 10:54 AM Mark Brown  wrote:

> On Fri, May 17, 2024 at 10:43:26AM -0400, John Waffle wrote:
>
> > - The zlib package page https://tracker.debian.org/pkg/zlib says that
> > CVE-2023-45853 <
> https://security-tracker.debian.org/tracker/CVE-2023-45853>
> > is ignored, what is the basis for ignoring this CVE?
> > - Is there a plan to backport zlib 1:1.3.dfsg-3.1 to bookworm? It looks
> > like it's currently in trixie
>
> Please direct any questions about security updates to the security team.
>

Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm?

[John Waffle]

Package: zlib
Version: 1:1.2.13.dfsg-1

Related bug reports:
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054290
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056718

These were marked as resolved but it seems like I'm getting some
contradictory information.

- The zlib package page https://tracker.debian.org/pkg/zlib says that
CVE-2023-45853 
is ignored, what is the basis for ignoring this CVE?
- Is there a plan to backport zlib 1:1.3.dfsg-3.1 to bookworm? It looks
like it's currently in trixie

The maintainer of zlib said this in a comment
https://github.com/madler/zlib/pull/843#issuecomment-2050417533

> Sigh. I tried.

> It is this page:
https://security-tracker.debian.org/tracker/CVE-2023-45853 , that
incorrectly marks 1:1.2.13.dfsg-1 as vulnerable, when in fact it has no
minizip code in it whatsoever. (I verified that by downloading it and
listing the external symbols in the .so file.) I managed to reach someone
at debian.org who seems to be in control of that page, but instead of
fixing the page, they defended it, even though it's wrong.

Can a Debian maintainer elaborate on this? Do the Debian maintainers feel
like this version of zlib is vulnerable or not?

If the Debian maintainers could confirm that this is not a real
vulnerability, maybe then we can get trivy to stop flagging this as a
critical vulnerability in their scan. This is a rather big problem because
a lot of images use Debian (bookworm specifically) and a lot of base images
(e.g. nginx) are getting flagged for this.

Thanks,

- J

Bug#1071194: libuv1: FTBFS on hppa - uv_test and uv_test_a fail

[John David Anglin]

Source: libuv1
Version: 1.48.0-3
Severity: normal
Tags: ftbfs

Dear Maintainer,

uv_test fails in test 353 - thread_mutex_recursive:

1: ok 353 - thread_mutex_recursive
1: not ok 354 - thread_priority
1: # exit code 6
1: # Output from process `thread_priority`:
1: # Assertion failed in ./test/test-thread-priority.c on line 92: `priority == 
0` (10 == 0)

uv_test_a fails in the same way.

See full log:
https://buildd.debian.org/status/fetch.php?pkg=libuv1=hppa=1.48.0-4=1715795091=0

Some other ports fail the same way.

Regards,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.8.9-dirty (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1070875: glibc: FTBFS on hppa - Encountered regressions that don't match expected failures

[John David Anglin]

Source: glibc
Version: 2.38-10
Severity: normal
Tags: ftbfs

Dear Maintainer,

The following tests are known to fail on hppa when glibc is built with
gcc-13 or later:

FAIL: math/test-double-fma
FAIL: math/test-double-ldouble-fma
FAIL: math/test-float32x-float64-fma
FAIL: math/test-float32x-fma
FAIL: math/test-float64-fma
FAIL: math/test-ldouble-fma

The tests do not fail when glibc is built with gcc-12.

See following gcc bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709

Full build log is here:
https://buildd.debian.org/status/fetch.php?pkg=glibc=hppa=2.38-10=1715383873=0

Things get worse with gcc-14.  I suspect this is an issue with nan
representation.

Please change the above tests to xfails.

Thanks,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.90+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1069389: kiwi: FTBFS on arm64: ImportError: sys.meta_path is None, Python is likely shutting down

[John Paul Adrian Glaubitz]

Hello,

On Sat, 2024-04-20 at 14:05 +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on arm64.
> (...)
> The full build log is available from:
> http://qa-logs.debian.net/2024/04/20/kiwi_9.25.22-1_unstable-arm64.log
> 
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240420;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240420=lu...@debian.org=1=1=1=1#results
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> If you reassign this bug to another package, please mark it as 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.

FWIW, I am already working on updating the kiwi package in Debian to the latest
upstream version. However, I ran into some testsuite issues that need to be 
sorted
out upstream first [1].

Thanks,
Adrian

> [1] https://github.com/OSInside/kiwi/issues/2548

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1070774: hamexam: update question pool

[John Nogatch]

The latest version hamexam 1.11 is available at:
https://launchpad.net/~jnogatch/+archive/ubuntu/hamexam

On Wed, May 8, 2024 at 9:33 PM Austen, Jeffrey  wrote:
>
> Package: hamexam
> Version: 1.10.1-1
> Severity: wishlist
>
> Please update the extra class question pool. The new pool takes effect
> July 1, 2024.
> https://www.ncvec.org/index.php/2024-2028-extra-class-question-pool-release

Bug#1070645: libavif: Please remove dependency on libgav1 on big-endian architectures

[John David Anglin]

Source: libavif
Version: 1.0.4-2
Severity: normal
Tags: ftbfs

Dear Maintainer,

libgav1 is broken on big-endian targets.  See this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068583

As a result, libavif no longer builds on hppa and other big-endian
architectures which depend on libgav1.

This blocks building glibc:
https://buildd.debian.org/status/package.php?p=glibc=sid

Regards,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.90+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1054109: ocaml: lack of LoongArch support

[John Paul Adrian Glaubitz]

Hi LiXing,

> [0001-Add-LoongArch-support-for-ocaml.patch (text/plain, attachment)]

I'm afraid this patch is way too large to be included in a Debian package.

Please make sure these changes are being upstreamed, so that native LoongArch
support will be part of the next major Ocaml upstream release in Debian.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1070449: linux-image-6.6-rockchip: zz-u-boot-menu postrm script no such file error

[John Sullivan]

Package: linux-image-6.6-rockchip
Version: 6.6.16+rockchip-1
Severity: important
X-Debbugs-Cc: jo...@debian.org

When trying to do an upgrade on the PineTab 2, I get "cannot open 
/usr/share/u-boot-menu/read-config: No such file" when the postrm script 
zz-u-boot-menu tries to run. This blocks upgrade of the package.

-john



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6-rockchip (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.6-rockchip depends on:
it  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod31+20240202-2
ii  linux-base  4.9

linux-image-6.6-rockchip recommends no packages.

linux-image-6.6-rockchip suggests no packages.

-- no debconf information

Bug#1068583: libgav1: FTBFS on s390x: test failures

[John David Anglin]

Adding architecture-is-little-endian to build dependency is not a good solution 
as this blocks building glibc
on big endian targets:
https://buildd.debian.org/status/package.php?p=glibc=sid

Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net

Bug#661461: ITA: unadf -- Extract files from an Amiga Disk File dump (.adf)

[John Paul Adrian Glaubitz]

On Wed, 2024-05-01 at 23:36 +0200, Petter Reinholdtsen wrote:
> Hi,
> 
> [John Paul Adrian Glaubitz 2020-05-10]
> > I would like to adopt this package. There is a new upstream available and 
> > the
> > repository has been moved to Github with some recent activity [1].
> 
> What came out of this intent?
> 
> I just migrated the package to a git repository on
> https://salsa.debian.org/debian/unadf >.

I started working on this, but I got stuck because of the fact that the upstream
package is actually not just unadf but a whole library that might need different
treatment.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1070018: ausweisapp: Mising dependency to libqt6svg6

[John Paul Adrian Glaubitz]

Hello Juergen,

On Sun, 2024-04-28 at 18:09 +0200, Juergen Bausa wrote:
> I run ausweisapp backport on bookworm. However, it doesnt display an icon in 
> the control panel of KDE. 
> Ausweisapp2 (which is actually a slightly older version) did display an icon. 
> While ausweisapp2 depended 
> on libqt6svg6, ausweisapp does not. Aftre installing libqt6svg6 manually the 
> icon is displayed in ausweisapp
> also. So I think the dependency on libqt6svg6 is just missing in ausweisapp.

This is a known issue and a result of a potential bug in Qt6 which results in 
dpkg-shlibdeps not adding
the runtime dependency for libqt6svg6 during build. While I could hardwire 
libqt6svg6 as a runtime
dependency into debian/control, this would cause problems when the ABI of the 
Qt6 SVG library is being
bumped resulting in the library package being renamed from libqt6svg6 to 
libqt6svg7.

Currently, the workaround is to install the missing libqt6svg6 package manually.

> In addition it seems to me that the window of AusweisApp looks extremely 
> clean (just white background).
> Ausweisapp2 was much more colourful. I guess that another lib is missing for 
> ausweisapp to display
> the intended look.

No, this is by design. The upstream developers have decided to make the user 
interface as minimalistic
as possible. I'm not such a fan of the new design either, but that's just how 
it looks now.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1069625: Acknowledgement (gstreamer1.0: Don't build ptp-helper on hppa)

[John David Anglin]

Updated patch to fix install.

Dave

--
John David Anglin  dave.ang...@bell.net
--- control.save2024-04-21 15:25:15.368645225 +
+++ control 2024-04-21 15:14:58.183856344 +
@@ -18,7 +18,7 @@
libdw-dev [i386 amd64 armel armhf arm64 powerpc ppc64 ppc64el 
mipsel mips64el riscv64],
bison,
flex,
-   rustc,
+   rustc [!hppa],
libgirepository1.0-dev,
gir1.2-glib-2.0,
gir1.2-freedesktop,
--- libgstreamer1.0-0.install.save  2024-04-21 16:38:07.810032050 +
+++ libgstreamer1.0-0.install   2024-04-21 16:38:17.922110631 +
@@ -1,5 +1,4 @@
 usr/lib/*/gstreamer-1.0/*.so
 usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner
-usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper
 usr/lib/*/*.so.*
 usr/share/locale
--- rules.save  2024-04-21 15:25:23.96877 +
+++ rules   2024-04-21 16:40:18.347048541 +
@@ -44,6 +44,10 @@
 conf_flags += -Dlibunwind=disabled -Dlibdw=disabled
 endif
 
+ifneq (,$(filter $(DEB_HOST_ARCH),hppa))
+conf_flags += -Dptp-helper=disabled
+endif
+
 infiles := \
libgstreamer1.0-0.postinst
 
--- libgstreamer1.0-0.postinst.in.save  2024-04-21 19:15:04.053817208 +
+++ libgstreamer1.0-0.postinst.in   2024-04-21 19:15:41.034100581 +
@@ -2,7 +2,7 @@
 
 set -e
 
-if [ "$1" = configure ]; then
+if [ "$1" = configure && test -f 
/usr/lib/@MULTIARCH@/gstreamer1.0/gstreamer-1.0/gst-ptp-helper ]; then
 # If we have setcap is installed, try setting 
cap_net_bind_service,cap_net_admin+ep,
 # which allows us to install our helper binary without the setuid bit.
 if command -v setcap > /dev/null; then

Bug#1069625: gstreamer1.0: Don't build ptp-helper on hppa

[John David Anglin]

Source: gstreamer1.0
Version: 1.24.2-1
Severity: normal
Tags: ftbfs patch

Dear Maintainer,

The standalone ptp-helper application in gstreamer1.0 1.24.2-1 requires
the rust compiler to build.  rustc is not available on hppa, alpha,
hurd-amd64, hurd-i386, ia64, m68k and sh4.  The current dependence on
rustc blocks the entire package from being built.  This indirectly
blocks hundreds of packages from being built.

I do not believe the ptp-helper is useful on hppa.  PTP support
requires hardware time stamping.  None of the Ethernet hardware
commonly used in PA-RISC machines have this capability.

gstreamer1.0 builds successfully with the attached patch on hppa.
Work is needed to add other architectures without rustc and to adjust
the installation files.

Regards,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.8.7 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
--- control.save2024-04-21 15:25:15.368645225 +
+++ control 2024-04-21 15:14:58.183856344 +
@@ -18,7 +18,7 @@
libdw-dev [i386 amd64 armel armhf arm64 powerpc ppc64 ppc64el 
mipsel mips64el riscv64],
bison,
flex,
-   rustc,
+   rustc [!hppa],
libgirepository1.0-dev,
gir1.2-glib-2.0,
gir1.2-freedesktop,
--- libgstreamer1.0-0.install.save  2024-04-21 16:38:07.810032050 +
+++ libgstreamer1.0-0.install   2024-04-21 16:38:17.922110631 +
@@ -1,5 +1,4 @@
 usr/lib/*/gstreamer-1.0/*.so
 usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner
-usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper
 usr/lib/*/*.so.*
 usr/share/locale
--- rules.save  2024-04-21 15:25:23.96877 +
+++ rules   2024-04-21 16:40:18.347048541 +
@@ -44,6 +44,10 @@
 conf_flags += -Dlibunwind=disabled -Dlibdw=disabled
 endif
 
+ifneq (,$(filter $(DEB_HOST_ARCH),hppa))
+conf_flags += -Dptp-helper=disabled
+endif
+
 infiles := \
libgstreamer1.0-0.postinst
 

Bug#1068999: FTBFS due to plantuml

[John Goerzen]

reassign 1069353 plantuml
severity 1068999 serious
forcemerge 1068999 1069353
thanks

Hello,

In #1069353, the bug in #1068999 caused nncp to FTBFS in sid due to this
same issue.  nncp uses plantuml to build documentation as part of its
build.  The full build log is at
http://qa-logs.debian.net/2024/04/20/nncp_8.10.0-8_unstable-arm64.log

Thanks,

John

Bug#1035064: software-properties-qt: First tab labeled 'Ubuntu Software'

[john faulk]

Package: software-properties-qt
Version: 0.99.30-4
Followup-For: Bug #1035064
X-Debbugs-Cc: johnny.faul...@yahoo.com

Can confirm that this bug still affects software-properties-qt in Bookworm
-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Versions of packages software-properties-qt depends on:
ii  debconf-kde-helper   1.1.0-1
ii  python3  3.11.2-1+b1
ii  python3-pyqt55.15.9+dfsg-1
ii  python3-software-properties  0.99.30-4
ii  software-properties-common   0.99.30-4

software-properties-qt recommends no packages.

Versions of packages software-properties-qt suggests:
ii  plasma-discover  5.27.5-2

-- no debconf information

Bug#1066780: Checking in on this bug

[John Goerzen]

Hello,

It would probably be good to update our package to 0.42.0, since it
contains a fix for CVE-2024-22189.  Perhaps that would also contain a
fix for this?  I don't know how hard this issue is to track down, but it
will be leading to several packages being unpatched and removed from
testing otherwise.

Thanks!

- John

Bug#1069128: haskell-aeson: FTBFS from source - out of memory in SomeType2ElemArray test

[John David Anglin]

Source: haskell-aeson
Version: 2.1.2.1-5
Severity: normal
Tags: ftbfs

Dear Maintainer,

Build fails here:
ApproxDefault:  OK (0.03s)
  +++ OK, passed 100 tests.
SomeType2ElemArray: 
aeson-tests: out of memory (requested 2097152 bytes)
Test suite aeson-tests: FAIL
Test suite logged to: dist-ghc/test/aeson-2.1.2.1-aeson-tests.log
0 of 1 test suites (0 of 1 test cases) passed.
-e: error: debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct 
returned exit code 1
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 875.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup test 
--builddir=dist-ghc --show-details"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 614
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup test 
--builddir=dist-ghc --show-details"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 477
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "test", 
"--builddir=dist-ghc", "--show-details=direct") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 692
Debian::Debhelper::Buildsystem::Haskell::Recipes::check_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:163: check-ghc-stamp] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=haskell-aeson=hppa=2.1.2.1-5%2Bb1=1713288523=0

Regards,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.8.4 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1069104: maildir-utils: Version 1.12.4 is available upstream

[John Goerzen]

Package: maildir-utils
Version: 1.12.3-3~bpo12+1
Severity: wishlist

Hello, and thanks for maintaining maildir-utils!  Upstream has released 1.12.4
which fixes some bugs I have encountered.

Thanks!

- John

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
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 maildir-utils depends on:
ii  guile-3.0-libs  3.0.8-2
ii  libc6   2.36-9+deb12u4
ii  libcld2-0   0.0.0-git20150806-9
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgmime-3.0-0  3.2.13+dfsg-2
ii  libstdc++6  12.2.0-14
ii  libxapian30 1.4.22-1

maildir-utils recommends no packages.

maildir-utils suggests no packages.

-- no debconf information

Bug#1069000: secrets: Adding an entry appears to corrupt the database, causing auth to fail on next invocation

[John Darrah]

Package: secrets
Version: 9.3-1
Severity: normal

Dear Maintainer,

I added three new entries to the database and then exited
as normal. There was no indication of any issues until I
tried to re-open the database. I entered my pass phrase as
normal and it informed me that the auth had failed. I tried
several more times thinking I mistyped something. I then
selected the "view pass" button to verify that it was
correct, which it was, but it still failed.

I then pulled an old version of the database from backup and
opened it with no issue. I added and entry, saved and
exited, then attempted to re-open but it failed auth again.

I copied a BAD version of the database to a Windows machine
with the latest version of KeepPass installed. It also fails
to auth the pass phrase. From this I must assume that
something is corrupting the file when saving.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-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 secrets depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b1
ii  gir1.2-adw-1 1.5~beta-1
ii  gir1.2-gtk-4.0   4.12.5+ds-3
ii  python3  3.11.6-1
ii  python3-gi   3.47.0-3
ii  python3-pwquality1.4.5-3
ii  python3-pykcs11  1.5.14-1
ii  python3-pykeepass4.0.7-2
ii  python3-pyotp2.9.0-2
ii  python3-validators   0.20.0-2
ii  python3-yubico   1.3.3-0.3
ii  python3-zxcvbn   4.4.28-3

secrets recommends no packages.

secrets suggests no packages.

-- no debconf information

-- Journalctl Log Entries Follow

Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]: 08-04-24
18:27:28 | ERROR | Could not unlock safe
Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]: Traceback (most
recent call last):
Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]:   File
"/usr/lib/python3/dist-packages/gsecrets/unlock_database.py", line 156, in
_unlock_callback
Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]:
database_manager.unlock_finish(result)
Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]:   File
"/usr/lib/python3/dist-packages/gsecrets/database_manager.py", line 123, in
unlock_finish
Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]: _success,
db = result.propagate_value()
Apr 08 18:27:28 nyx
org.gnome.World.Secrets.desktop[60919]:

Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]:
gi.repository.GLib.GError: secrets: Invalid credentials (1)
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]: 08-04-24
18:27:52 | ERROR | Could not unlock safe
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]: Traceback (most
recent call last):
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]:   File
"/usr/lib/python3/dist-packages/gsecrets/unlock_database.py", line 156, in
_unlock_callback
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]:
database_manager.unlock_finish(result)
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]:   File
"/usr/lib/python3/dist-packages/gsecrets/database_manager.py", line 123, in
unlock_finish
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]: _success,
db = result.propagate_value()
Apr 08 18:27:52 nyx
org.gnome.World.Secrets.desktop[60919]:

Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]:
gi.repository.GLib.GError: secrets: Invalid credentials (1)

Bug#1066216: hfsutils: diff for NMU version 3.2.6-15.1

[John Paul Adrian Glaubitz]

On Sun, 2024-04-14 at 12:57 +0200, Sebastian Ramacher wrote:
> I've prepared an NMU for hfsutils (versioned as 3.2.6-15.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Yes, please set it to 14 days. I am currently going through all
my packages one after another to fix these issues.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1060196: fixed in ghc 9.4.7-5

[John Paul Adrian Glaubitz]

On Fri, 2024-04-12 at 22:35 +, Debian FTP Masters wrote:
>* Build unregisterised on powerpc (Closes: #1060196)

I am not 100% sure what happened, but this upload produced another
broken GHC compiler on powerpc. Lots of packages fail to build now
due to GHC segfaulting [1]:

Running dh_listpackages
libghc-splitmix-dev
libghc-splitmix-prof
libghc-splitmix-doc
-e: error: debian/hlibrary.setup build --builddir=dist-ghc died with signal 11
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 875.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup build 
--builddir=dist-ghc died with sig"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 614
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup build 
--builddir=dist-ghc") called at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm 
line 477
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "build", 
"--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 656
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned 
exit status 2

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=haskell-splitmix=powerpc=0.1.0.5-1%2Bb1=1713046430=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1052434: Acknowledgement (qttools-opensource-src: FTBFS on hppa - No rule to make target 'assistant.qch')

[John David Anglin]

This bug appears to have been introduced by the fix for #1045220.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1046444: virtualjaguar: Fails to build source after successful build

[John Paul Adrian Glaubitz]

Hi,

On Sun, 2023-08-13 at 21:21 +0200, Lucas Nussbaum wrote:
> Relevant part of the build log:
> > cd /<> && runuser -u user42 -- dpkg-buildpackage 
> > --sanitize-env -us -uc -rfakeroot -S
> > -
> > 
> > dpkg-buildpackage: info: source package virtualjaguar
> > dpkg-buildpackage: info: source version 2.1.3-2
> > dpkg-buildpackage: info: source distribution unstable
> > dpkg-buildpackage: info: source changed by John Paul Adrian Glaubitz 
> > 
> >  dpkg-source --before-build .
> >  fakeroot debian/rules clean
> > dh clean
> > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
> >dh_auto_clean
> > dh_auto_clean: warning: Compatibility levels before 10 are deprecated 
> > (level 9 in use)
> > make -j1 clean
> > make[1]: Entering directory '/<>'
> > -ne *** Cleaning out the garbage...
> > done!
> > make[1]: Leaving directory '/<>'
> >dh_clean
> > dh_clean: warning: Compatibility levels before 10 are deprecated (level 9 
> > in use)
> >  dpkg-source -b .
> > dpkg-source: info: using source format '3.0 (quilt)'
> > dpkg-source: info: building virtualjaguar using existing 
> > ./virtualjaguar_2.1.3.orig.tar.bz2
> > dpkg-source: info: using patch list from debian/patches/series
> > dpkg-source: warning: ignoring deletion of file src/m68000/m68kdasm.c.bak, 
> > use --include-removal to override
> > dpkg-source: info: local changes detected, the modified files are:
> >  virtualjaguar-2.1.3/.qmake.stash
> >  virtualjaguar-2.1.3/src/version.h
> > dpkg-source: error: aborting due to unexpected upstream changes, see 
> > /tmp/virtualjaguar_2.1.3-2.diff.v1VkyG
> > dpkg-source: info: Hint: make sure the version in debian/changelog matches 
> > the unpacked source tree
> > dpkg-source: info: you can integrate the local changes with dpkg-source 
> > --commit
> > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
> > 
> > E: Command 'cd /<> && runuser -u user42 -- dpkg-buildpackage 
> > --sanitize-env -us -uc -rfakeroot -S' failed to run.

After close inspection of the build log and the original tarball, it turns out 
that the tarball
used is not identical to the one available from the upstream FTP server [1]:

glaubitz@z6:~/debian> wget -q 
http://icculus.org/virtualjaguar/tarballs/virtualjaguar-2.1.3.tar.bz2 -O 
virtualjaguar-upstream-2.1.3.tar.bz2
glaubitz@z6:~/debian> md5sum virtualjaguar-upstream-2.1.3.tar.bz2 
virtualjaguar_2.1.3.orig.tar.bz2 
17af87b3a7cfd9106e49afc56d4858e6  virtualjaguar-upstream-2.1.3.tar.bz2
0e3f30737c171c096ac2690a38f7029a  virtualjaguar_2.1.3.orig.tar.bz2
glaubitz@z6:~/debian>

Further inspection reveals that the file src/m68000/m68kdasm.c.bak that is 
deleted during build
and prevents a second successful build is not part of the original source:

glaubitz@z6:~/debian> tar tf virtualjaguar_2.1.3.orig.tar.bz2 |grep bak
linux-2.1.3/src/m68000/m68kdasm.c.bak
glaubitz@z6:~/debian> tar tf virtualjaguar-upstream-2.1.3.tar.bz2  |grep bak
glaubitz@z6:~/debian>

I don't really remember how I created the first upload of the 2.1.3 upstream 
version, but since
upstream development has ceased, I can upload a fixed version only with a 
forged upstream version
using "really" or similar since there won't be a new upstream release unless 
the upstream project
is forked.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1066383: virtualjaguar: FTBFS: ./inlines.h:82:20: error: implicit declaration of function ‘m68k_read_memory_32’ [-Werror=implicit-function-declaration]

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Hi,

On Wed, 2024-03-13 at 12:46 +0100, Lucas Nussbaum wrote:
> Relevant part (hopefully):
> > gcc -MMD -g -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> > -I. -I./obj `sdl-config --cflags` -c obj/cpustbl.c -o obj/cpustbl.o
> > In file included from obj/cpustbl.c:3:
> > ./inlines.h: In function ‘m68k_do_rts’:
> > ./inlines.h:82:20: error: implicit declaration of function 
> > ‘m68k_read_memory_32’ [-Werror=implicit-function-declaration]
> >82 | m68k_setpc(m68k_read_memory_32(m68k_areg(regs, 7)));
> >   |^~~
> > ./inlines.h: In function ‘m68k_do_bsr’:
> > ./inlines.h:89:9: error: implicit declaration of function 
> > ‘m68k_write_memory_32’ [-Werror=implicit-function-declaration]
> >89 | m68k_write_memory_32(m68k_areg(regs, 7), oldpc);
> >   | ^~~~
> > ./inlines.h: In function ‘get_ibyte_prefetch’:
> > ./inlines.h:111:25: error: implicit declaration of function 
> > ‘m68k_read_memory_8’ [-Werror=implicit-function-declaration]
> >   111 | #define get_ibyte(o)m68k_read_memory_8(regs.pc + (o) + 1)
> >   | ^~
> > ./inlines.h:158:16: note: in expansion of macro ‘get_ibyte’
> >   158 | return get_ibyte(o);
> >   |^
> > ./inlines.h: In function ‘get_iword_prefetch’:
> > ./inlines.h:112:25: error: implicit declaration of function 
> > ‘m68k_read_memory_16’ [-Werror=implicit-function-declaration]
> >   112 | #define get_iword(o)m68k_read_memory_16(regs.pc + (o))
> >   | ^~~
> > ./inlines.h:183:16: note: in expansion of macro ‘get_iword’
> >   183 | return get_iword(o);
> >   |^
> > cc1: some warnings being treated as errors
> > make[2]: *** [Makefile:58: obj/cpustbl.o] Error 1

Thanks for the bug report! The attached patch fixes the problem for me. I'm 
going to upload
an updated packages soon which will also include fixes for #1038585 [1].

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038585

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
From d0c699e0c6a0781a6dd2f89492b38f9a1d50fa9c Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz 
Date: Sat, 13 Apr 2024 11:18:38 +0200
Subject: [PATCH] Fix missing inclusion of m68kinterface.h in
 src/m68000/inlines.h

---
 src/m68000/inlines.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/m68000/inlines.h b/src/m68000/inlines.h
index 54de932..c037bd9 100644
--- a/src/m68000/inlines.h
+++ b/src/m68000/inlines.h
@@ -11,6 +11,7 @@
 #define __INLINES_H__
 
 #include "cpudefs.h"
+#include "m68kinterface.h"
 
 STATIC_INLINE int cctrue(const int cc)
 {
-- 
2.44.0

Bug#1067141: kcemu: FTBFS with -Werror=implicit-function-declaration

[John Paul Adrian Glaubitz]

Hello Zixing,

On Wed, 2024-04-10 at 17:34 -0600, Zixing Liu wrote:
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * debian/patches/add-missing-includes.patch: Add missing includes.
> Closes LP: #2060887.

The issue has already been fixed upstream. I am waiting for upstream
to make a new release as this would also fix #970666 [1].

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970666

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1068691: util-linux: enosys program missing on m68k and sh4

[John Paul Adrian Glaubitz]

Hi Christian,

On Tue, 2024-04-09 at 10:00 +0200, Chris Hofstaedtler wrote:
> * John Paul Adrian Glaubitz  [240409 09:36]:
> > the program enosys doesn't seem to be available on m68k and sh4, so it 
> > needs to
> > be excluded from the install files with the help of dh-exec:
> 
> I imagine the other option is to expand audit-arch.h to cover these
> archs. Do you mind reviewing this, then I could sent it upstream? Do
> note that I've mostly guessed what might be right.

Ah, I wasn't aware it's related to seccomp ;-).

> Relevant uapi header:
> https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/audit.h#L432
> 
> diff --git a/include/audit-arch.h b/include/audit-arch.h
> index ade182417..9afc663cd 100644
> --- a/include/audit-arch.h
> +++ b/include/audit-arch.h
> @@ -35,6 +35,8 @@
>  #endif
>  #elif __powerpc__
>  #define SECCOMP_ARCH_NATIVE AUDIT_ARCH_PPC
> +#elif __m68k__
> +#define SECCOMP_ARCH_NATIVE AUDIT_ARCH_M68K
>  #elif __mips__
>  #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
>  # define SECCOMP_ARCH_NATIVE AUDIT_ARCH_MIPS
> @@ -47,6 +49,12 @@
>  #else
>  # define SECCOMP_ARCH_NATIVE AUDIT_ARCH_ARCV2
>  #endif
> +#elif __sh__
> +#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
> +# define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SH
> +#else
> +# define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SHEL
> +#endif
>  #elif __sparc__
>  #if __SIZEOF_POINTER__ == 4
>  # define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SPARC

Looks good to me. I was actually the person who added support for m68k and sh4
to libseccomp. Unfortunately, upstream still hasn't released the a new stable
version which includes my patches. This is planned for 2.6.0.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1068691: util-linux: enosys program missing on m68k and sh4

[John Paul Adrian Glaubitz]

Source: util-linux
Version: 2.40-5
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hello,

the program enosys doesn't seem to be available on m68k and sh4, so it needs to
be excluded from the install files with the help of dh-exec:

dh_install \
-Nfdisk-udeb -Nlibblkid1-udeb \
-Nlibfdisk1-udeb -Nlibsmartcols1-udeb -Nlibuuid1-udeb \
-Nutil-linux-udeb
dh_install: warning: Cannot find (any matches for) "usr/bin/enosys" (tried in 
., debian/tmp)

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1068081: rust-dns-lookup: "lookup::test_rev_localhost' panicked at 'assertion failed" on loong64

[John Paul Adrian Glaubitz]

Hi Dandan,

please report this bug upstream as it's not Debian-specific.

The upstream bug tracker can be found in [1].

Adrian

> [1] https://github.com/keeperofdakeys/dns-lookup/issues

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1056428: /usr/sbin/lparstat: Could not open /proc/ppc64/lparcfg when lauch lparstat

[John Paul Adrian Glaubitz]

Hello Thomas,

On Wed, 2024-04-03 at 12:22 +, PEPONAS Thomas wrote:
> On IBM Power paltform , add cpu entitlement can not be done  without 
> LPARCFG=Y , because /proc/ppc64/lparcfg could not open: 
> Logs from drmgr :
> ## Apr 03 10:54:41 2024 ##
> drmgr: -c cpu -r -q 10 -p ent_capacity -w 5 -d 1
> Validating CPU DLPAR capability...yes.
> Could not open "/proc/ppc64/lparcfg"
> No such file or directory
> CPU entitlement capability is not enabled on this platform.
> Could not update system parameter ent_capacity
> ## Apr 03 10:54:41 2024 ##
> 
> will the LPARCFG option be activated on future versions?

The Debian kernel maintainers are informed since I have reassigned the bug to
the kernel package. I assume this will be fixed in the near future.

I might do it myself if I find the time during the next weeks.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1057050: closed by Debian FTP Masters (reply to Patrick Franz ) (Bug#1057050: fixed in qt6-multimedia 6.6.1-1)

[John Paul Adrian Glaubitz]

Control: reopen -1

Hi,

looks like this didn't work:

> https://buildd.debian.org/status/fetch.php?pkg=qt6-multimedia=powerpc=6.4.2-11=1705003199=0

Reopening the bug therefore.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1068235: mkdocs: packaged themes require newer version of jquery than is included

[John Leach]

Package: mkdocs
Version: 1.5.3+dfsg-1
Severity: important
X-Debbugs-Cc: j...@johnleach.co.uk

building a mkdocs site using the default mkdocs theme results in html which
tries to include js/jquery-3.6.0.min.js but only js/jquery-1.10.2.min.js exists.

/usr/lib/python3/dist-packages/mkdocs/themes/mkdocs/base.html references it 
like this:


but the package doesn't include it:

$ dpkg -L mkdocs | grep jquery
/usr/lib/python3/dist-packages/mkdocs/themes/mkdocs/js/jquery-1.10.2.min.js
/usr/lib/python3/dist-packages/mkdocs/themes/readthedocs/js/jquery-2.1.1.min.js

The readthedocs theme does the same thing (but uses it's version of jquery, 
2.1.1).

The resulting site search system is unusuable.

I'm reporting this from an ubuntu system but I have confirmed this bug exists in
debian/sid.

It looks like this bug was introduced in 1.5.2+dfsg-1 when the themes were
upgraded. Somehow the updated jquery files were not committed.

I notice this package depends on libjs-jquery but I'm not sure why as jquery is
vendored with the themes, and libjs-jquery is not quite the right version of
jquery to solve this problem anyway.



-- System Information:
Debian Release: trixie/sid
  APT prefers noble-updates
  APT policy: (500, 'noble-updates'), (500, 'noble')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.0-11-generic (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mkdocs depends on:
ii  fonts-font-awesome   5.0.10+really4.7.0~dfsg-4.1
ii  ghp-import   2.1.0-3
ii  libjs-bootstrap4 4.6.1+dfsg1-4
ii  libjs-jquery 3.6.1+dfsg+~3.5.14-1
ii  libjs-lunr   2.3.9~dfsg-2
ii  libjs-modernizr  2.6.2+ds1-5
ii  python3 [python3-supported-min]  3.12.1-0ubuntu2
ii  python3-click8.1.6-2
ii  python3-importlib-metadata   4.12.0-1
ii  python3-jinja2   3.1.2-1ubuntu1
ii  python3-livereload   2.6.3-2
ii  python3-lunr 0.7.0-1
ii  python3-markdown 3.5.2-1
ii  python3-markupsafe   2.1.5-1build1
ii  python3-mergedeep1.3.4-3
ii  python3-packaging23.2-1
ii  python3-pathspec 0.12.1-1
ii  python3-pkg-resources68.1.2-2ubuntu1
ii  python3-platformdirs 4.2.0-1
ii  python3-pyyaml-env-tag   0.1-3
ii  python3-typing-extensions4.10.0-1
ii  python3-watchdog 3.0.0-1
ii  python3-yaml 6.0.1-2
ii  sphinx-rtd-theme-common  2.0.0+dfsg-1

mkdocs recommends no packages.

Versions of packages mkdocs suggests:
pn  mkdocs-doc 
ii  nodejs 18.19.1+dfsg-2ubuntu4
ii  python3-babel  2.10.3-3build1

-- no debconf information

Bug#1067603: contextfree: FTBFS on armhf: test failure with missing codec

[John Horigan]

Could this bug be the cause?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012791

If libavcodec cannot access libx264.so due to some executable stack
security issue, then it would fail to load the libx264 encoder.

-- john

Bug#1067603: contextfree: FTBFS on armhf: test failure with missing codec

[John Horigan]

That error message indicates that libavcodec60 does not support the libx264
codec for encoding H.264 files. libavcodec60 lists libx264-164 as a
dependency, with no exception for armel or armhf systems, so I don't know
why the codec won't load.

Can you run the command

ffmpeg -codecs

on an armhf system and report back the output?

-- john

On Sun, 24 Mar 2024 21:04:49 +0900 Kentaro HAYASHI  wrote:
> Package: contextfree
> Version: 3.4+dfsg-1.1
> Severity: important
> Tags: ftbfs
> X-Debbugs-Cc: ken...@xdump.org
>
> Dear Maintainer,
>
>
>* What led up to the situation?
>
>contextfree can't build on armel,armhf.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> apt-get source contextfree
> cd contextfree-3.4+dfsg
> debuild -us -uc
>
>* What was the outcome of this action?
>
> See
>
https://buildd.debian.org/status/fetch.php?pkg=contextfree=armhf=3.4%2Bdfsg-1.1=1711207519=0
>
> input/ziggy_v2.cfdg   pass Reading rules file input/mtree.cfdg
> Restarting as a version 3 design
> 8 rules loaded
> Generating 8bit gray-scale Quicktime movie, variation FFGH...
> Failed to create movie file: codec not found
> make[1]: *** [Makefile:188: test] Error 8
> make[1]: Leaving directory '/home/kenhys/work/contextfree-3.4+dfsg'
> dh_auto_test: error: make -j8 test returned exit code 2
> make: *** [debian/rules:6: build] Error 25
> dpkg-buildpackage: error: debian/rules build subprocess returned exit
> status 2 debuild: fatal error at line 1184:
> dpkg-buildpackage -us -uc -ui failed
>
>* What outcome did you expect instead?
>
> contextfree can build on armel/armhf.
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: armhf (armv8l)
>
> Kernel: Linux 6.1.0-18-arm64 (SMP w/8 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
>
> Versions of packages contextfree depends on:
> pn  libagg2
> ii  libavcodec60   7:6.1.1-3
> ii  libavformat60  7:6.1.1-3
> ii  libavutil587:6.1.1-3
> ii  libc6  2.37-15.1
> ii  libgcc-s1  14-20240315-1

Bug#1067809: maildir-utils: New upstream version 1.12.2 is available

[John Goerzen]

Package: maildir-utils
Severity: wishlist

Hi,

A new upstream version is available.  It would be nice to have it in Debian.
Thanks!



-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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 maildir-utils depends on:
ii  guile-3.0-libs  3.0.8-2
ii  libc6   2.36-9+deb12u4
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgmime-3.0-0  3.2.13+dfsg-2
ii  libstdc++6  12.2.0-14
ii  libxapian30 1.4.22-1

maildir-utils recommends no packages.

maildir-utils suggests no packages.

-- no debconf information

Bug#1067735: www.debian.org: Please update links for PowerPC CHRP port

[John Paul Adrian Glaubitz]

Package: www.debian.org
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hello,

the following page for the PowerPC CHRP has some dead links:

> https://www.debian.org/ports/powerpc/inst/chrp

These links can be updated to point to archive.debian.org:

linux.bin: 
http://archive.debian.org/debian/dists/woody/main/disks-powerpc/current/chrp/linux.bin
rescue.bin: 
http://archive.debian.org/debian/dists/woody/main/disks-powerpc/current/chrp/images-1.44/rescue.bin
driver-1.bin: 
http://archive.debian.org/debian/dists/woody/main/disks-powerpc/current/chrp/images-1.44/driver-1.bin
driver-2.bin: 
http://archive.debian.org/debian/dists/woody/main/disks-powerpc/current/chrp/images-1.44/driver-2.bin
basedebs.tar: 
http://archive.debian.org/debian/dists/woody/main/disks-powerpc/base-images-current/basedebs.tar

CHRP System from Geert Uytterhoeven: 
https://web.archive.org/web/20140625035302/http://users.telenet.be/geertu/Linux/PPC/

In the long term, it might be a good idea to move the documentation for old 
architectures to Debian Ports.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1067717: emacs-common: Security issues with emacs; remote code execution in Gnus

[John Goerzen]

Package: emacs-common
Version: 1:28.2+1-15
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

Hello,

https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-29 describes
some security issues addressed in emacs 29.3.

Among them:

** Gnus now treats inline MIME contents as untrusted.
To get back previous insecure behavior, 'untrusted-content' should be
reset to nil in the buffer.

** LaTeX preview is now by default disabled for email attachments.
To get back previous insecure behavior, set the variable
'org--latex-preview-when-risky' to a non-nil value.

I don't see anything that would explicitly indicate if the version in stable,
1.28.2, is vulnerable but the nature of this leads me to think that it is.

Thanks,

John

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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 emacs-common depends on:
ii  emacs-el 1:28.2+1-15
ii  emacsen-common   3.0.5
ii  init-system-helpers  1.65.2
ii  install-info 6.8-6+b1

emacs-common recommends no packages.

Versions of packages emacs-common suggests:
pn  emacs-common-non-dfsg  
ii  ncurses-term   6.4-4

-- no debconf information