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#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#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#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#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#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#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#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#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

Bug#1067386: anymarkup-core: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[John Paul Adrian Glaubitz]

Control: reassign -1 src:python-flexmock
Control: merge -1 1067358

Hi Lucas,

On Wed, 2024-03-20 at 21:56 +0100, Lucas Nussbaum wrote:
> >  ERRORS 
> > 
> > _ ERROR collecting 
> > .pybuild/cpython3_3.12_anymarkup-core/build/test/test_libs_not_installed.py 
> > _
> > test/test_libs_not_installed.py:1: in 
> > from flexmock import flexmock
> > /usr/lib/python3/dist-packages/flexmock/__init__.py:2: in 
> > from flexmock import _integrations  # pylint: disable=unused-import
> > /usr/lib/python3/dist-packages/flexmock/_integrations.py:101: in 
> > saved_pytest = runner.call_runtest_hook
> > E   AttributeError: module '_pytest.runner' has no attribute 
> > 'call_runtest_hook'
> > === short test summary info 
> > 
> > ERROR test/test_libs_not_installed.py - AttributeError: module 
> > '_pytest.runne...
> >  Interrupted: 1 error during collection 
> > 
> > === 1 error in 0.21s 
> > ===
> > 

I think this is the same bug you reported in #1067358 [1].

anymarkup-core is affected since it uses python-flexmock as a build-dependency.

Adrian

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

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

Bug#1066995: pulseaudio: FTBFS with _TIME_BITS=64 on 32-bit systems

[John Paul Adrian Glaubitz]

Source: pulseaudio
Version: 16.1+dfsg1-3
Severity: serious
Tags: upstream
Justification: ftbfs
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hi,

pulseaudio fails to built from source with _TIME_BITS=64 [1]:

[632/648] cc -Isrc/utils/libpulsedsp.so.p -Isrc/utils -I../src/utils -I. -I.. 
-Isrc -I../src -fdiagnostics-color=always -Wall -Winvalid-pch -std=gnu11 -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-pthread -DHAVE_CONFIG_H -D_GNU_SOURCE -Wno-nonnull-compare -MD -MQ 
src/utils/libpulsedsp.so.p/padsp.c.o -MF src/utils/libpulsedsp.so.p/padsp.c.o.d 
-o src/utils/libpulsedsp.so.p/padsp.c.o -c ../src/utils/padsp.c
FAILED: src/utils/libpulsedsp.so.p/padsp.c.o 
cc -Isrc/utils/libpulsedsp.so.p -Isrc/utils -I../src/utils -I. -I.. -Isrc 
-I../src -fdiagnostics-color=always -Wall -Winvalid-pch -std=gnu11 -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-pthread -DHAVE_CONFIG_H -D_GNU_SOURCE -Wno-nonnull-compare -MD -MQ 
src/utils/libpulsedsp.so.p/padsp.c.o -MF src/utils/libpulsedsp.so.p/padsp.c.o.d 
-o src/utils/libpulsedsp.so.p/padsp.c.o -c ../src/utils/padsp.c
In file included from /usr/include/features.h:393,
 from /usr/include/endian.h:21,
 from /usr/include/linux/soundcard.h:43,
 from /usr/include/powerpc-linux-gnu/sys/soundcard.h:1,
 from ../src/utils/padsp.c:33:
/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed 
only with _FILE_OFFSET_BITS=64"
   26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
  | ^

This needs to be fixed for the time_t transition [2].

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=pulseaudio=powerpc=16.1%2Bdfsg1-3%2Bb1=1710500596=0
> [2] https://wiki.debian.org/ReleaseGoals/64bit-time

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see <http://www.gnu.org/licenses/>.

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see <http://www.gnu.org/licenses/>.

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-scr

Bug#1065380: ausweisapp2 FTBFS with pcsc-lite 2.0.2

[John Paul Adrian Glaubitz]

Hi Adrian,

On Sun, 2024-03-03 at 18:13 +0200, Adrian Bunk wrote:
> https://buildd.debian.org/status/logs.php?pkg=ausweisapp2=2.1.0-1
> 
> ...
> /<>/src/card/pcsc/PcscUtils.h:112:46: error: 
> ‘SCARD_E_UNKNOWN_RES_MNG’ was not declared in this scope; did you mean 
> ‘SCARD_E_UNKNOWN_RES_MSG’?
>   112 | Scard_E_Unknown_Res_Mng = 
> returnCode(SCARD_E_UNKNOWN_RES_MNG), /**< An unrecognized error code 
> was returned from a layered component. */
>   |  ^~~
> ...
> 
> 
> This is not a regression in the new ausweisapp2 upload,
> but due to a change in pcsc-lite 2.0.2 (maintainer Cc'ed):
> 
> https://salsa.debian.org/rousseau/PCSC/-/commit/65f9b610138c8a4a5563d0332120f684682e0237
> "Fix typo in (unused) error code SCARD_E_UNKNOWN_RES_MSG"

I've already seen that and also notified upstream. He is also now CC'ed here.

Adrian

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

Bug#1064945: grub-efi-amd64: Sudden boot failures on ZFS systems

[John Goerzen]

Package: grub-efi-amd64
Version: 2.06-13+deb12u1
Severity: critical
Tags: upstream patch
Justification: breaks the whole system

My system suddenly refused to start up grub.  An error message flashed by, but
too quickly for me to be able to see.  Then I got the grub emergency prompt.

Upon booting from a Debian live image to attempt to fix this, after chrooting
into an appropriately-configured filesystem from the target (with bind-mount
/proc, /sys, /dev, /boot/efi, etc), grub-install failed with:

error: compression algorithm inherit not supported

I'll note that "inherit" is not really a compression algorithm for ZFS.  (root,
and also boot, are part of ZFS on this system.)

Upon researching this, I see that https://github.com/openzfs/zfs/issues/15261
discusses the problem.  https://github.com/openzfs/zfs/issues/13873 does as
well.

https://github.com/openzfs/zfs/issues/13873#issuecomment-1905182760 suggests
that it is the ZFS feature extensible_dataset that is responsible for this.
That feature can get auto-enabled by other features at runtime.

Both of these bugs indicate that grub 2.12 contains patches to fix the issue.
Indeed, the four patches listed at
https://git.savannah.gnu.org/cgit/grub.git/log/grub-core/fs/zfs/zfs.c pertaining
to ZFS are thought to fix it.

I have built a bookworm-backports version of grub 2.12 and it does indeed solve
the problem.

I think this issue justifies backporting those ZFS patches into the version in
bookworm for stable-proposed-updates.

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 grub-efi-amd64 depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  grub-common2.06-13+deb12u1
ii  grub-efi-amd64-bin 2.06-13+deb12u1
ii  grub2-common   2.06-13+deb12u1
ii  ucf3.0043+nmu1

grub-efi-amd64 recommends no packages.

grub-efi-amd64 suggests no packages.

-- debconf information excluded

Bug#961834: New release

[john faulk]

Hello everyone,
its been a while since this was last discussed, and it seemed tagging
a new release was pre-requisite to being added back to debian. Thus, I
have forked the fork, and tagged a release, shown below:
https://github.com/MrReplikant/clearlooks-phenix/releases/tag/7.0.2

I am doing this as such to volunteer to be the guardian of this
release until someone more willing/capable/knowledgeable of theming is
able to take over from me. my hopes is that this will allow
clearlooks-phenix to be allowed back into the repo.

if there are any questions or concerns, please do not hesitate to contact me

-John

Bug#1063497: zfs-dkms: Data loss bug in version in bookworm

[John Goerzen]

Package: zfs-dkms
Version: 2.1.11-1
Severity: critical
Tags: patch upstream
Justification: causes serious data loss

Hello ZFS maintainers!  Thank you for maintaining this for Debian.

In the release notes for ZFS 2.1.14 at
https://github.com/openzfs/zfs/releases/tag/zfs-2.1.14, it states:

"This release contains an important fix for a data corruption bug. Full details
are in the issue (#15526) and bug fix (#15571). There's also a developer's bug
summary that gives a good overview...  This bug is very hard to hit, and really
only came to light due to changes in cp in coreutils 9.x. It's extremely
unlikely that the bug was ever hit on EL7 or EL8 when running cp since they all
use coreutils 8.x which performs file copies differently."

I'll note that bookworm contains coreutils 9.x.

Two options would exist to get this into stable-proposed-updates:

1) Backport the patch (linked to from the release notes) onto 2.1.14 (likely
easy),

or

2) Upgrade stable to 2.1.14.

If you would like my assistance with either of these steps, I'm available to 
help.

John

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

Kernel: Linux 6.1.0-17-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 zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  dkms   3.0.10-8+deb12u1
ii  file   1:5.44-3
ii  libc6-dev [libc-dev]   2.36-9+deb12u4
ii  libpython3-stdlib  3.11.2-1+b1
ii  lsb-release12.0-1
ii  perl   5.36.0-7+deb12u1
ii  python3-distutils  3.11.2-3

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  6.5.10-1~bpo12+1
ii  zfs-zed 2.2.2-4~bpo12+1
ii  zfsutils-linux  2.2.2-4~bpo12+1

Versions of packages zfs-dkms suggests:
ii  debhelper  13.11.4

-- debconf information excluded

Bug#1062097: closed by Debian FTP Masters (reply to John Goerzen ) (Bug#1062097: fixed in gensio 2.8.2-4)

[John Goerzen]

Hi Lukas and Michael,

Thank you for your work on this large transition.

I am confused.

The gensio bug was reported with severity serious, against the version
of gensio in unstable, which prevents transition to testing.

I don't understand what action is being requested.  If the bug cannot be
fixed, it should not be filed (or not filed as serious).

Additionally, there are other bugs impacting these packages and their
symbol files, which I have addressed.  They will create a conflict with
the proposed NMU, so the NMU will need to be refreshed before being
applied.

Now the bug is reopened asking me to roll back the same patch that the
bug was opened for.  I could of course do that -- disentangling the
conflicts -- and close the bug with the upload.  But that would leave
gensio without the t64 libraries -- the same state it was in when you
reported the serious bug.

So which is it: is there a serious bug with gensio in unstable with the
t64 libraries, or without?  It cannot be both.

I don't think I've ever received a bug report, severity serious, tagged
patch, found in the version in unstable, where applying the patch is
somehow the wrong thing to do.

Please clarify what action I could take that would close this bug.

I may not be the only one confused here, and would be happy to have this
conversation on debian-devel if that would be more broadly useful.

- John

On Mon, Feb 05 2024, Lukas Märdian wrote:

> [[PGP Signed Part:Undecided]]
> reopen 1062097
>
> Dear John,
>
> please revert your latest upload to unstable.
> The time_t NMU was targeted at experimental.
> The dpkg in unstable does not yet set the compiler defaults to provide 64-bit
> time_t; so packages built as part of this upload will  now have the wrong ABI
> in the reverse direction.
>
> -- Lukas
>
> On Mon, Feb 05, 2024 at 06:39:05AM +, Debian Bug Tracking System wrote:
>> This is an automatic notification regarding your Bug report
>> which was filed against the src:gensio package:
>>
>> #1062097: gensio: NMU diff for 64-bit time_t transition
>>
>> It has been closed by Debian FTP Masters  
>> (reply to John Goerzen ).
>>
>> Their explanation is attached below along with your original report.
>> If this explanation is unsatisfactory and you have not received a
>> better one in a separate message then please contact Debian FTP Masters 
>>  (reply to John Goerzen 
>> ) by
>> replying to this email.
>>
>>
>> --
>> 1062097: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062097
>> Debian Bug Tracking System
>> Contact ow...@bugs.debian.org with problems
>
>> Date: Mon, 05 Feb 2024 06:35:44 +
>> From: Debian FTP Masters 
>> To: 1062097-cl...@bugs.debian.org
>> Subject: Bug#1062097: fixed in gensio 2.8.2-4
>>
>> Source: gensio
>> Source-Version: 2.8.2-4
>> Done: John Goerzen 
>>
>> We believe that the bug you reported is fixed in the latest version of
>> gensio, which is due to be installed in the Debian FTP archive.
>>
>> A summary of the changes between this version and the previous one is
>> attached.
>>
>> Thank you for reporting the bug, which will now be closed.  If you
>> have further comments please address them to 1062...@bugs.debian.org,
>> and the maintainer will reopen the bug report if appropriate.
>>
>> Debian distribution maintenance software
>> pp.
>> John Goerzen  (supplier of updated gensio package)
>>
>> (This message was generated automatically at their request; if you
>> believe that there is a problem with it please contact the archive
>> administrators by mailing ftpmas...@ftp-master.debian.org)
>>
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Format: 1.8
>> Date: Mon, 05 Feb 2024 00:18:56 -0600
>> Source: gensio
>> Architecture: source
>> Version: 2.8.2-4
>> Distribution: unstable
>> Urgency: medium
>> Maintainer: Marc Haber 
>> Changed-By: John Goerzen 
>> Closes: 1061614 1062097
>> Changes:
>>  gensio (2.8.2-4) unstable; urgency=medium
>>  .
>>* Apply patch from Lukas Märdian to rename libraries for 64-bit time_t
>>  transition.  Closes: #1062097.
>>* Apply patch from Matthias Klose to mark symbols not seen building
>>  with -O3 as optional.  Closes: #1061614.
>> Checksums-Sha1:
>>  be5b49300127e98911ce9c48ada186f4261590a4 2251 gensio_2.8.2-4.dsc
>>  b074438a4c893499ad22bbaf08b8f5e325f74d5b 11868 gensio_2.8.2-4.debian.tar.xz
>>  21b223330fb4412e2433fd579cd8efbd142b1ce9 8915 
>> gensio_2.8.2-4_source.buildinfo
>> Checksums-Sha256:
>>  a7c3214f8d71c44b8de526aa1ee93393468ac2e79b481a

Bug#1062333: discover: NMU diff for 64-bit time_t transition

[John Paul Adrian Glaubitz]

Hi,

On Thu, 2024-02-01 at 04:31 +, mwhud...@debian.org wrote:
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for discover
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.

Isn't a 0-day a bit too tight to give the maintainer some chance to answer?

Since this package is owned by the installer-team, I would suggest sending
a pull request on salsa instead [1].

Adrian

> [1] https://salsa.debian.org/installer-team/discover

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

Bug#1057430:

[john faulk]

I can't seem to figure why, it compiles fine on my machine. the error
you're showing is due to libsdbus-c++-dev being missing from your
system. If this is not in the build-deps, a simple fix would be to add
this package to them.

Bug#1053686: pandoc: cannot fulfill the build dependencies

[John MacFarlane]

Removing lua support would be most unfortunate!  If you need help from upstream 
in getting things to work, let me know.

Bug#1055066: usrmerge: Cannot update to version 38 on sbuild

[John Paul Adrian Glaubitz]

Control: reopen -1
Control: reassign -1 src:debootstrap

Hello!

On Tue, 2023-10-31 at 09:02 +0100, John Paul Adrian Glaubitz wrote:
> Could it be that debootstrap needs to be switched to enabled usrmerge by 
> default?

I can confirm that passing --merged-usr to debootstrap fixes the problem.

Reopening the bug and assigning accordingly.

Thanks,
Adrian

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

Bug#1055066: usrmerge: Cannot update to version 38 on sbuild

[John Paul Adrian Glaubitz]

Hello!

I am not sure whether this issue has been fixed.

We're seeing this issue on buildds and porterboxes on Debian Ports,
regenerating the chroots fails:

dpkg: warning: ignoring pre-dependency problem!
Preparing to unpack .../tar_1.34+dfsg-1.2_ppc64.deb ...
Unpacking tar (1.34+dfsg-1.2) ...
Selecting previously unselected package usr-is-merged.
Preparing to unpack .../usr-is-merged_38_all.deb ...


**
*
* The usr-is-merged package cannot be installed because this system does
* not have a merged /usr.
*
* Please install the usrmerge package to convert this system to merged-/usr.
*
* For more information please read https://wiki.debian.org/UsrMerge.
*
**


dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_38_all.deb 
(--unpack):
 new usr-is-merged package pre-installation script subprocess returned error 
exit status 1
Selecting previously unselected package util-linux.
dpkg: regarding .../util-linux_2.39.2-5_ppc64.deb containing util-linux, 
pre-dependency problem:
 util-linux pre-depends on libblkid1 (>= 2.37.2)
  libblkid1:ppc64 is unpacked, but has never been configured.

Could it be that debootstrap needs to be switched to enabled usrmerge by 
default?

Adrian

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

Bug#1053170: Apache NOTICE file missing from binary package

[John Thorvald Wodder II]

Package: bat
Version: 0.23.0-4
Severity: serious

bat's upstream source and the rust-bat_0.23.0.orig.tar.gz file both contain a
NOTICE file which, per the packages's Apache 2.0 license, must be preserved in
derivative works.  However, this NOTICE file is not present in the binary .deb
packages distributed by Debian.

Note that bat itself embeds the text of the NOTICE file in its own binary, and
the text is displayed when running `batcat --acknowledgements`.  However, Paul
Wise has stated on the debian-legal mailing list that the NOTICE should still
be distributed as a file in the .deb packages:

https://lists.debian.org/debian-legal/2023/09/msg00012.html

Bug#1050256: autopkgtest fails on debci

[John Johansen]

On 9/4/23 12:32, Michael Biebl wrote:

Am 04.09.23 um 20:23 schrieb Mathias Gibbens:

On Mon, 2023-09-04 at 01:00 -0700, John Johansen wrote:

I took a quick look through v6.1..v6.3.1

there is a patch that I think is the likely fix, it first landed in v6.2

1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets


   Thanks for the pointer John -- I think that is the fix we've been
looking for!

   Commit 1cf26c3d2c4c doesn't apply cleanly to the v6.1 tree due to the
other commits from the patchset of Oct 3, 2022 that modified a bunch of
the apparmor code. Because I couldn't quickly cherry-pick all the
changes without amassing a large diff, I made the small proof-of-
concept patch at the end of this message and applied it to the  6.1.38-
4 kernel from bookworm. Booting with the patched kernel allows services
to start up in containers without any issues. :)

   So, I think the next step should be to get that commit properly
backported to the v6.1 longterm tree and included in an upstream
release. Hopefully that would be able to happen in enough time so that
it is bundled with the kernel updates for bookworm's point release next
month. If not, we should be sure to get it into Debian's packaging so
at least there's a proper fix available.



Thanks for the update Mathias, this looks very promising.
A stable update of the Linux 6.1.x kernel would obviously be the ideal solution.

John, could you help with getting this fix into 6.1.x?



yes, I am working on a patch.

Bug#1050256: autopkgtest fails on debci

[John Johansen]

I took a quick look through v6.1..v6.3.1

there is a patch that I think is the likely fix, it first landed in v6.2

1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets

it matches up the reported audit logs. Unfortunately it does not have a Fixes
tag but as best I can figure it should be applied all the way back to.

56974a6fcfef apparmor: add base infastructure for socket mediation

how/where this bug surfaces partly depends on the userspace policy and
compiler which combines the features set supported by the kernel with what
policy claims to support. So it is possible to have an affected kernel
but not trigger the bug.

Bug#1040960: gcc-sh-elf fix is on the way

[John Scott]

Control: owner -1 John Scott 
Control: tags -1 pending

I made a boo boo. An explanation and fix will be ready shortly


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

Bug#1042935: Sage test timeouts probably fixed upstream

[John Scott]

Control: tags -1 fixed-upstream
Control: block -1 by 1010735

I think this is fixed upstream. Apparently they were made aware that this 
particular failing test just takes a long time, but if you give it a couple 
minutes it does pass.


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

Bug#1042969: vsftpd: Deletes the ftp user on remove, breaking other packages

[John Goerzen]

Package: vsftpd
Version: 3.0.3-13+b2
Severity: critical
Justification: breaks unrelated software

On removing this package, it indiscriminately removes the ftp user.
Unfortunately, that user was required for iksd in package ckermit to work, so
this broke the unrelated ckermit package.

It is likely that there are other packages and users that would also
use the ftp user.  It should not be removed on package removal.

-- Package-specific info:

-- System Information:
Debian Release: 12.1
  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-10-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_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 vsftpd depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9+deb12u1
ii  libcap21:2.66-4
ii  libpam-modules 1.5.2-6
ii  libpam0g   1.5.2-6
ii  libssl33.0.9-1
ii  libwrap0   7.6.q-32
ii  lsb-base   11.6
ii  netbase6.4
ii  procps 2:4.0.2-3
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages vsftpd recommends:
ii  logrotate  3.21.0-1
ii  ssl-cert   1.1.2

vsftpd suggests no packages.

-- debconf information:
  vsftpd/directory: /srv/ftp
  vsftpd/username: ftp
# Example config file /etc/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
#
# Run standalone?  vsftpd can run either from an inetd or as a standalone
# daemon started from an initscript.
listen=NO
#
# This directive enables listening on IPv6 sockets. By default, listening
# on the IPv6 "any" address (::) will accept connections from both IPv6
# and IPv4 clients. It is not necessary to listen on *both* IPv4 and IPv6
# sockets. If you want that (perhaps because you want to listen on specific
# addresses) then you must run two copies of vsftpd with two configuration
# files.
listen_ipv6=YES
#
# Allow anonymous FTP? (Disabled by default).
anonymous_enable=NO
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
#write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
#local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
#anon_upload_enable=YES
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# If enabled, vsftpd will display directory listings with the time
# in  your  local  time  zone.  The default is to display GMT. The
# times returned by the MDTM FTP command are also affected by this
# option.
use_localtime=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# You may override where the log file goes if you like. The default is shown
# below.
#xferlog_file=/var/log/vsftpd.log
#
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
#xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
#nopriv_user=ftpsecure
#
# Enable this and the server will recognise asynchronous ABOR requests. Not
# recommended for security (the code is non-trivial). Not enabling it,
# however, may confuse older FTP clients.
#async_abor_enable=YES
#
# By default the server will 

Bug#1042018: qt6-declarative: FTBFS on hppa - Segmentation fault in /usr/lib/qt6/bin/qsb

[John David Anglin]

Source: qt6-declarative
Version: 6.4.2+dfsg-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Build fails here:
[22/6600] cd /<>/obj-hppa-linux-gnu/src/quick && 
/usr/lib/qt6/bin/qsb --glsl 100es,120,150 --hlsl 50 --msl 12 -b -O -s -o 
/<>/obj-hppa-linux-gnu/src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb
 /<>/src/quick/scenegraph/shaders_ng/24bittextmask.frag
FAILED: src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb 
/<>/obj-hppa-linux-gnu/src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb
 
cd /<>/obj-hppa-linux-gnu/src/quick && /usr/lib/qt6/bin/qsb --glsl 
100es,120,150 --hlsl 50 --msl 12 -b -O -s -o 
/<>/obj-hppa-linux-gnu/src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb
 /<>/src/quick/scenegraph/shaders_ng/24bittextmask.frag
Segmentation fault (core dumped)

See:
https://buildd.debian.org/status/fetch.php?pkg=qt6-declarative=hppa=6.4.2%2Bdfsg-3=1690289443=0

dave@mx3210:~/debian/qt6-declarative/qt6-declarative-6.4.2+dfsg/obj-hppa-linux-g
nu/src/quick$ gdb /usr/lib/qt6/bin/qsb
GNU gdb (Debian 13.2-1) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "hppa-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/qt6/bin/qsb...
Reading symbols from 
/usr/lib/debug/.build-id/2d/3c434ee4acf266d2dc6fd1ff1289e07e4fd07c.debug...
(gdb) set args --glsl 100es,120,150 --hlsl 50 --msl 12 -b -O -s -o 
/home/dave/debian/qt6-declarative/qt6-declarative-6.4.2+dfsg/obj-hppa-linux-gnu/src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb
 
/home/dave/debian/qt6-declarative/qt6-declarative-6.4.2+dfsg/src/quick/scenegraph/shaders_ng/24bittextmask.frag
(gdb) r
Starting program: /usr/lib/qt6/bin/qsb --glsl 100es,120,150 --hlsl 50 --msl 12 
-b -O -s -o 
/home/dave/debian/qt6-declarative/qt6-declarative-6.4.2+dfsg/obj-hppa-linux-gnu/src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb
 
/home/dave/debian/qt6-declarative/qt6-declarative-6.4.2+dfsg/src/quick/scenegraph/shaders_ng/24bittextmask.frag
warning: Unable to find libthread_db matching inferior's thread library, thread 
debugging will not be available.
[Detaching after vfork from child process 24823]

Program received signal SIGSEGV, Segmentation fault.
0xf8af656c in vforkfd (flags=1,
childFn=0xf8aec7d4 
, token=0xf8f02888, ppid=0xf8f028f0)
at ./src/corelib/io/../../3rdparty/forkfd/forkfd.c:815
815 ./src/corelib/io/../../3rdparty/forkfd/forkfd.c: No such file or 
directory.
(gdb) bt
#0  0xf8af656c in vforkfd (flags=1,
childFn=0xf8aec7d4 
, token=0xf8f02888, ppid=0xf8f028f0)
at ./src/corelib/io/../../3rdparty/forkfd/forkfd.c:815
#1  QProcessPrivate::startProcess (this=0x91c80)
at ./src/corelib/io/qprocess_unix.cpp:472
#2  QProcessPrivate::start (this=0x91c80, mode=...)
at ./src/corelib/io/qprocess.cpp:2163
#3  0x0001bc20 in runProcess (binary=..., arguments=..., output=0xf8f02888,
errorOutput=0x5112) at /usr/include/hppa-linux-gnu/qt6/QtCore/qflags.h:74
#4  0x00016884 in main (argc=, argv=)
at ./tools/qsb/qsb.cpp:661
(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0xf8af655c to 0xf8af657c:
   0xf8af655c 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+708>:  
  copy r21,r26
   0xf8af6560 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+712>:  
  b,l 0xf8ad428c,rp
   0xf8af6564 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+716>:  
  stw r21,-c4(sp)
   0xf8af6568 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+720>:  
  copy r4,r19
=> 0xf8af656c 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+724>:  
  ldw 0(r8),r20
   0xf8af6570 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+728>:  
  cmpib,<> 0,r20,0xf8af6aa0 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+2056>
   0xf8af6574 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+732>:  
  copy ret0,r3
   0xf8af6578 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+736>:  
  addil L%d000,r19,r1
End of assembler dump.
(gdb) p/x $r8
$1 = 0x5112

r8 is misaligned for ldw instruction but this didn't cause fault.

(gdb) x/x 0x5110
0x5110: Cannot access memory at address 0x5110

Regards,
Dave Anglin

-- System Information:
Debian 

Bug#1037904: Xournal++ GCC 13 FTBFS fixed upstream

[John Scott]

Control: forwarded -1 
https://github.com/xournalpp/xournalpp/commit/9172ee831f4dfbb88dfeb13b66862e80e64a0d3f
Control: tags -1 fixed-upstream

It looks like this has been fixed upstream, so I'm setting the bug metadata as 
such.


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


smime.p7s
Description: S/MIME cryptographic signature

Bug#1040447: odbc-mariadb cannot set up odcb-mariadb

[John Covici]

Package: odbc-mariadb
Version: 3.1.15-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation? upgraded from bullseye
   * What exactly did you do (or not do) that was effective (or
 ineffective)? tried to install the package during the upgrade 
   * What was the outcome of this action? Got the following error:
   * odbcinst: SQLInstallDriverEx failed with Unable to find component name.
   * What outcome did you expect instead?odbc-mariadb to properly install



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

Kernel: Linux 6.1.0-9-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 odbc-mariadb depends on:
ii  libc6 2.36-9
ii  libmariadb3   1:10.11.3-1
ii  libodbcinst2  2.3.11-2+deb12u1
ii  odbcinst  2.3.11-2+deb12u1

odbc-mariadb recommends no packages.

odbc-mariadb suggests no packages.

-- no debconf information

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022

[John Paul Adrian Glaubitz]

> On Jun 18, 2023, at 3:53 PM, Simon McVittie  wrote:
> 
> On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote:
>> I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can
>> confirm that 2.54.5+dfsg-1 now fails in bookworm too. So something must
>> have triggered a regression between September 2022 and now.
> 
> It would be helpful if someone with suitable hardware could put this
> through debbisect or similar to find out which build-dependency triggered
> this.

TIL about debbisect. I can try to bisect this on big-endian PowerPC, I have 
root on multiple big-endian machines.

Adrian

Bug#1011530: FTBFS: fails to include system headers

[John Paul Adrian Glaubitz]

Hello!

On Tue, 2023-05-16 at 22:13 +0200, Bastian Germann wrote:
> I am uploading a NMU to fix this.
> Please find the debdiff attached.

Please don't do NMUs without using a delay [1]. I did not get
a chance to review your change.

Adrian

> [1] https://ftp-master.debian.org/deferred.html

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

Bug#1035079: Latest version of vice includes some ROM binaries

[John Zaitseff]

Package: vice
Version: 3.7.1+dfsg-2
Severity: serious

Thank you for packaging the Versatile Commodore Emulator!

Apologies for the "serious" severity label, but the latest version
of the package, 3.7.1+dfsg-2, inadvertently includes a ROM binary
that is not DFSG-free.  In particular, the following file should NOT
be included in the package:

  /usr/share/vice/PRINTER/mps803.bin

Yours truly,

John Zaitseff

-- 
John Zaitseff   ╭───╮   Email: j.zaits...@zap.org.au
The ZAP Group   │ Z │   GnuPG: 0x0D254111C4EE569B
Australia Inc.  ╰───╯   https://www.zap.org.au/~john/

Bug#1031439: gcc-sh-elf FTBFS: mystery solved?

[John Scott]

Hi,

I'm doing the build right now and it got past the part where it's been failing, 
so I'm pretty sure we're good!

Adrian, would you be willing to sponsor my upload? I'll send a second mail when 
it's ready. The change is extremely small, and to be frank I'll probably skip 
running the test suite, but I believe the software will be sound.


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

Bug#1032013: Handling of -e violates policy for x-terminal-emulator

[John Crawley]

Hello Louis-Philippe,
thank you for fixing the bug.
As far as I can tell, the -e option is now handled correctly by terminator when 
invoked as x-terminal-emulator.

Just for the record, I may be misunderstanding the Debian Policy [1], but:
1) neither -c nor --execute are mentioned, only -e.
2) command lines like
x-terminal-emulator -e 'if this; then that; fi'
*should not* work, any more than 'if this; then that; fi' would work in an 
actual terminal.
The outer quotes would make the whole line into a single argument, but an 
executable is required as the first word. Such commands do work on some 
terminals, but I don't think Debian Policy expects that:

" may be *multiple* arguments, which form the argument list to the executed 
program"

So this should work (and now does):
x-terminal-emulator -e sh -c 'if this; then that; fi'

Thanks again!

[1] 
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#packages-providing-a-terminal-emulator
--
John

Bug#1031895: zoph fails to purge when mariadb-client is not installed

[John Lines]

I have made this change, although on my system piuparts (1.1.7) does
not give me this result - I still get a piuparts failure due to

9m55.8s ERROR: FAIL: Package purging left files on system:
  /etc/dbconfig-common/  owned by: dbconfig-common
  /etc/mysql/owned by: mariadb-server, mysql-common, mariadb-
common, mariadb-client
  /etc/mysql/debian.cnf  not owned
  /var/lib/mysql/not owned
  /var/lib/mysql/aria_log.0001   not owned
  /var/lib/mysql/aria_log_controlnot owned
  /var/lib/mysql/debian-10.11.flag   not owned
...

which is different from the piuparts server result, and from manual
install and purge on a test virtual bookworm VM


> 
> Similar to #1031748, but for a different command.
> 
>    mysqladmin --defaults-file=/etc/mysql/debian.cnf -f drop zoph ||
> true
> should work

Bug#1031309: accountsservice: accounts-daemon service will prevent system boot if shadowconfig is off

[john amidon]

Package: accountsservice
Version: 22.08.8-5
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: jami...@helixinnovations.io

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I set shadowconfig to 'off' when I edited '/etc/group' and forgot to reset it.
Sometime later, I ran 'apt upgrade', rebooted, and found that the boot did not
complete, complaining about accounts-daemon.service not starting.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
booted into recovery mode, looked at journal and discovered that 'shadowconfig'
was set to 'off' and re-enabled it

   * What was the outcome of this action?
machine successfully rebooted


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

Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_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 accountsservice depends on:
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  libaccountsservice0 22.08.8-5
ii  libc6   2.36-8
ii  libglib2.0-02.74.5-1
ii  libpolkit-gobject-1-0   122-3

Versions of packages accountsservice recommends:
ii  libpam-systemd [logind]  252.5-2
ii  polkitd  122-3

Versions of packages accountsservice suggests:
ii  gnome-control-center  1:43.2-2

-- no debconf information

Bug#1025848: src:kiwi: unsatisfied build dependency in testing: python3-testinfra

[John Paul Adrian Glaubitz]

Hello Paul!

On 12/10/22 15:13, Paul Gevers wrote:

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.


I'm not sure what the point of this bug report is. If any of the build
dependencies are missing because someone reported a RC bug against it,
it's not really my job to fix that particular bug.

There is no apparent bug in kiwi that I know of, so I don't see what the
purpose of this bug report is and what I am supposed to do except maybe
go talk to the maintainer of python3-testinfra to tell him to fix their
bugs.

Adrian

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

Bug#1024626: Blender removal for 32-bit architectures

[John Scott]

Hi,

I see from previous mails that Blender upstream has decided not to support 
32-bit architectures anymore. This is a friendly ping that the maintainer will 
request its removal so it may migrate into Bookworm.

Thanks,
John


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

Bug#1023149: marked as done (pandoc FTBFS on i386)

[John MacFarlane]

Just an observation: adding the -O0 option here will create an unoptimized 
build, which will run more slowly.  So this is definitely not a patch that 
should remain more than short-term.

I have no idea what this issue is, by the way.  We regularly test pandoc 
upstream against ghc versions 8.6.5, 8.8.4, 8.10.7, 9.2.3, and 9.4.2, and I've 
never seen this issue.

> On Nov 24, 2022, at 1:39 AM, Debian Bug Tracking System 
>  wrote:
> 
> The patch below workarounds the issue, which indicates that it might
> be a bug in the compiler and not a problem in pandoc?
> 
> Short-term it might even be good enough to unblock migration of several
> packages to testing.
> 
> --- debian/rules.old  2022-10-30 17:52:59.643347191 +
> +++ debian/rules  2022-10-30 17:54:14.347251214 +
> @@ -192,6 +192,10 @@
> DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-optc--param 
> -optcggc-min-expand=10 -O0"
> endif
> 
> +ifneq (,$(filter $(DEB_HOST_ARCH_CPU), i386))
> +DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-O0"
> +endif
> +
> DEB_SETUP_GHC_CONFIGURE_ARGS += $(if $(filter 
> nocheck,$(DEB_BUILD_OPTIONS)),,-ftests)
> 
> DEB_INSTALL_DOCS_ALL += README.md
> 17.1.1-1.1) unstable; urgency=low
> .
>   * Non-maintainer upload.
>   * Workaround i386 FTBFS with -O0. (Closes: #1023149)
> Checksums-Sha1:
> b8474b357393a855e985003374b89cf1d8cc566a 9172 pandoc_2.17.1.1-1.1.dsc
> 14914bf918799cd45b75e9c71748f5a1c13acc2b 59012 
> pandoc_2.17.1.1-1.1.debian.tar.xz
> Checksums-Sha256:
> ccb354586541dfc3e0b121b527d10bdbc39f8369b3d7072276bee7558f56fa3e 9172 
> pandoc_2.17.1.1-1.1.dsc
> 07ef9d2654ba4cbdf018ca6c691b5330348ee5c0fd85813cf4dc91d46822127f 59012 
> pandoc_2.17.1.1-1.1.debian.tar.xz
> Files:
> ccfd9b94d62c2efea06540f914c9e8b1 9172 text optional pandoc_2.17.1.1-1.1.dsc
> 9d1452b2c9c481ef8740f81480b2b81b 59012 text optional 
> pandoc_2.17.1.1-1.1.debian.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAmN4118ACgkQiNJCh6LY
> mLF08Q//e3i2jHi91hJSH7HCyAGhCQq8KrnZWwp99EK/MgdAqDcQtLc3NR/APnUc
> DwuzqDUA1cHJb/say/MeU2tdj3k9sBAD+MzhP150u1LZQKxFnpmbQLS42e545r1g
> T2lCBNsXUleK5a3fZCjx9gwuvJCTRZX0h6HEWooirCy8e6AY0K2nptWbEiiApSDk
> q1rcgyaFjNijYldYfPxPo9DXz6cdK1TTjlyAxxcvM7EJGgGUX7ROB6FKN73Y6mU8
> DjSu4LyrgK9vmGPU55VhiKrfDQy6zQbEzhU+ovmSkul3gVSbGarutvbbfi2/FleJ
> 7MKpqgNb0mO/a9vNQ+69BJwVkYje35XtBfNNVoUjAqrgbNuCb5n8wuTYIFDyPudu
> MEFWPt615Pxn8395wvQyGBxVLbpOWwH/PPRGBm3G69n6fYXF2NcyLzCyXD7vyIjl
> FIH5K76q06E5CkTnFweXxSiDKFs/X30V4BOYiyShrLAAPBVQNYcEGFtPw7RRRrMZ
> HYnjShF5J3/+14J5ACBrO4czZhROkwxyeEAaRcGqCQevj+uJuMk3RQiiTr1zcdID
> cFYwlj9xXZZwGqGfYgcuc+w4iV1tp6OnrbDfSjEphC0hrT26dxpoT0EUv1+dKChx
> MiZsYj/5nkjpLG8MIA/MpIU9mOiAuo/bhf/3fzmw7WQSWDWDxHk=
> =PDz7
> -END PGP SIGNATURE-
> 

Bug#1018039: FTBFS on ppc64el with gcc-12

[John Paul Adrian Glaubitz]

Hi!

On 8/24/22 16:50, Frédéric Bonnard wrote:

powerpc-utils 1.3.9-1 fails to build atm with gcc-12.
I checked latest 1.3.10 and it's roughly the same.
I've opened an issue upstream.


Interestingly, the error due to "-Werror=maybe-uninitialized" does not show
on the openSUSE builds, see [1]. openSUSE does not ship any patch to address
the issue though.

Fedora doesn't seem to have a patch to address the issue either [2]. Also, no
update from upstream either.

Adrian


[1] 
https://build.opensuse.org/package/live_build_log/hardware/powerpc-utils/openSUSE_Factory_PPC/ppc64le
[2] https://src.fedoraproject.org/rpms/powerpc-utils/tree/rawhide


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

Bug#1023265: Test failures blocking migration of rust-libc and several deps to testing

[John Goerzen]

Package: rust-libc
Version: 0.2.137-1
Severity: serious
X-Debbugs-CC: plugw...@debian.org, wolfg...@silbermayr.at, infini...@debian.org

Migration of several other packages is blocked due to the issues listed
over at:

https://tracker.debian.org/pkg/rust-libc

In particular, it has caused failures in rust-capston on s390x and
rust-netlink-sys in multiple platforms.

Thanks,

John

Bug#1021404: qt6-base: FTBFS on hppa - Unknown Q_PROCESSOR_xxx macro

[John David Anglin]

Source: qt6-base
Version: 6.3.1+dfsg-10
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

The build fails here:

[357/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 -MD -MT src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o -MF 
src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o.d -o 
src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o -c 
/<>/src/corelib/text/qregularexpression.cpp
[358/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 -MD -MT src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o -MF 
src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o.d -o 
src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o -c 
/<>/src/corelib/io/qfilesystemwatcher.cpp
[359/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 

Bug#1021312: qtquickcontrols-opensource-src: FTBFS on hppa - Tests_TreeView::test_pressAndHold

[John David Anglin]

Source: qtquickcontrols-opensource-src
Version: 5.15.6-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Testsuite fails with following error:

PASS   : qtquickcontrols::Tests_TreeView::test_keys_navigation()
FAIL!  : qtquickcontrols::Tests_TreeView::test_pressAndHold() Compared values 
are not the same
   Actual   (): 0
   Expected (): 1
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(274)]
PASS   : qtquickcontrols::Tests_TreeView::test_selection_contiguousSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_extendedSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_multiSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_noSelection()
XFAIL  : qtquickcontrols::Tests_TreeView::test_selection_singleSelection() BUG 
selected state not updated with Command/Control when SingleSelection
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(402)]
XFAIL  : qtquickcontrols::Tests_TreeView::test_selection_singleSelection() BUG 
selected state not updated with Command/Control when SingleSelection
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(404)]
PASS   : qtquickcontrols::Tests_TreeView::test_selection_singleSelection()
PASS   : qtquickcontrols::Tests_TreeView::cleanupTestCase()
Totals: 498 passed, 1 failed, 6 skipped, 0 blacklisted, 410752ms
* Finished testing of qtquickcontrols *
make[5]: *** [Makefile:318: check] Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=qtquickcontrols-opensource-src=hppa=5.15.6-2=1664978713=0

Regards,
Dave Anglin

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

Kernel: Linux 5.19.13+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
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#1021310: libsdl2: FTBFS on hppa - testevdev: FAILED: 1

[John David Anglin]

Source: libsdl2
Version: 2.24.0+dfsg-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Build fails in testsuite:

Thinkpad USB keyboard with Trackpoint - Trackpoint...
Expected 0x0003
MOUSE
KEYBOARD
Got  0x
No information...
OK
testevdev: FAILED: 1
testfilesystem...
INFO: base path: '/<>/debian/build-tests/'
INFO: pref path: 
'/<>/debian/.debhelper/generated/_source/home/.local/share/libsdl/test_filesystem/'
INFO: pref path: 
'/<>/debian/.debhelper/generated/_source/home/.local/share/test_filesystem/'
testfilesystem: OK
...
testdisplayinfo: OK
make[2]: *** [Makefile:416: check] Error 1
make[2]: Leaving directory '/<>/debian/build-tests'
dh_auto_test: error: cd debian/build-tests && make -j4 check 
"TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 V=1 returned exit code 2
make[1]: *** [debian/rules:142: override_dh_auto_test-arch] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:81: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=libsdl2=hppa=2.24.1%2Bdfsg-1=1664977752=0

Similar fail occurs on powerpc.

Regards,
Dave Anglin

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

Kernel: Linux 5.19.13+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
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#1016519: ffmpeg: Still FTBFS on hppa and powerpc

[John David Anglin]

Source: ffmpeg
Followup-For: Bug #1016519

Dear Maintainer,

This is with version 7:5.1-3:
https://buildd.debian.org/status/fetch.php?pkg=ffmpeg=hppa=7%3A5.1-3=1661576231=0

/<>/tests/fate-run.sh fate-filter-overlay_yuv422 "" "" 
"/<>/debian/standard" 'framecrc -auto_conversion_filters -c:v 
pgmyuv -i /<>/debian/standard/tests/vsynth1/%02d.pgm 
-filter_complex_script 
/<>/debian/standard/tests/data/filtergraphs/overlay_yuv422' '' '' 
'' '1' '' '' '' '' '' '' '' '' '' ''
 /<>/debian/standard/ffmpeg -nostdin -nostats 
-noauto_conversion_filters -cpuflags all -auto_conversion_filters -c:v pgmyuv 
-hwaccel none -threads 1 -thread_type frame+slice -i 
/<>/debian/standard/tests/vsynth1/%02d.pgm -filter_complex_script 
/<>/debian/standard/tests/data/filtergraphs/overlay_yuv422 
-bitexact -f framecrc -
--- /<>/tests/ref/fate/filter-overlay_yuv420p102022-07-22 
17:58:40.0 +
+++ tests/data/fate/filter-overlay_yuv420p102022-08-27 04:23:18.426707238 
+
@@ -3,6 +3,6 @@
 #codec_id 0: rawvideo
 #dimensions 0: 352x288
 #sar 0: 0/1
-0,  0,  0,1,   304128, 0x524bcfc6
-0,  1,  1,1,   304128, 0xab3a13af
-0,  2,  2,1,   304128, 0xac08d718
+0,  0,  0,1,   304128, 0xd041d116
+0,  1,  1,1,   304128, 0x293f14ff
+0,  2,  2,1,   304128, 0x2a0dd868
Test filter-overlay_yuv420p10 failed. Look at 
tests/data/fate/filter-overlay_yuv420p10.err for details.
ffmpeg version 5.1-3 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 12 (Debian 12.2.0-1)
  configuration: --prefix=/usr --extra-version=3 --toolchain=hardened 
--libdir=/usr/lib/hppa-linux-gnu --incdir=/usr/include/hppa-linux-gnu 
--arch=hppa --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa 
--enable-libaom --enable-libass --enable-libbluray --enable-libbs2b 
--enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d 
--enable-libflite --enable-libfontconfig --enable-libfreetype 
--enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm 
--enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg 
--enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq 
--enable-librist --enable-librubberband --enable-libshine --enable-libsnappy 
--enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh 
--enable-libsvtav1 --enable-libtheora --enable-libtwolame --enable-libvidstab 
--enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 
--enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq 
--enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl 
--enable-opengl --enable-sdl2 --disable-sndio --enable-libdc1394 
--enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r 
--enable-libx264 --enable-libplacebo --enable-shared
  libavutil  57. 28.100 / 57. 28.100
  libavcodec 59. 37.100 / 59. 37.100
  libavformat59. 27.100 / 59. 27.100
  libavdevice59.  7.100 / 59.  7.100
  libavfilter 8. 44.100 /  8. 44.100
  libswscale  6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc56.  6.100 / 56.  6.100
Input #0, image2, from 
'/<>/debian/standard/tests/vsynth1/%02d.pgm':
  Duration: 00:00:02.00, start: 0.00, bitrate: N/A
  Stream #0:0: Video: pgmyuv, yuv420p, 352x288, 25 fps, 25 tbr, 25 tbn
Stream mapping:
  Stream #0:0 (pgmyuv) -> split:default
  overlay:default -> Stream #0:0 (rawvideo)
Output #0, framecrc, to 'pipe:':
  Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le(tv, 
progressive), 352x288, q=2-31, 38016 kb/s, 25 fps, 25 tbn
Metadata:
  encoder : Lavc rawvideo
frame=3 fps=1.2 q=-0.0 Lsize=   0kB time=00:00:00.12 bitrate=  
17.6kbits/s speed=0.0462x
video:891kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: unknown
make[2]: *** [/<>/tests/Makefile:305: 
fate-filter-overlay_yuv420p10] Error 1

Regards,
Dave Anglin

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

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

Bug#1009242: zfs-dkms: PPC get_user workaround breaks boot on ZFS root

[Dimitri John Ledkov]

This is a fix released I think.

Bug#1011743: Duplicate Bug Report

[John Wolfe]

Please mark this bug as a duplicate of bug 1011633.  
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011633)

Thanks,
John

Bug#1006008: python-cryptography: FTBFS with OpenSSL 3.0

[John Paul Adrian Glaubitz]

Hello Agathe!

On 5/17/22 18:48, Agathe Porte wrote:
> I do not know when that was done, but the two latest Fedora releases have 
> been using >=35
> versions which properly support OpenSSL 3.0 [1]. I have opened #1011155 in 
> order to discuss
> why we cannot just update to latest upstream versions, if that is the case, 
> and to not pollute
> this thread.

At least for Debian Ports, updating to python-cryptography 35 or newer would 
mean that the package
becomes BD-Uninstallable, i.e. not buildable as the Rust compiler is not 
available on all architectures
yet.

Rust support is slowly coming to more architectures with the rustc_codegen_gcc 
backend and gccrs,
so this problem will be eventually resolved. However, this work is not 
completed yet.

Adrian

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

Bug#1006008: python-cryptography: FTBFS with OpenSSL 3.0

[John Paul Adrian Glaubitz]

Control: reopen -1

On 5/17/22 08:50, John Paul Adrian Glaubitz wrote:
> I just noticed the patches for OpenSSL 3.0 support have already been added to 
> the
> Debian package [1]. I also verified that the package builds fine in unstable
> with OpenSSL 3.0.
> 
> Therefore closing this bug report.

Hmm, I was too quick here. While the build itself succeeds, 17 tests are 
failing:

=== short test summary info 
SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:192: Requires 
OpenSSL with ENGINE support and OpenSSL < 1.1.1d
SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:233: Requires 
OpenSSL with ENGINE support and OpenSSL < 1.1.1d
SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:240: Requires 
OpenSSL with ENGINE support and OpenSSL < 1.1.1d
SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:251: Requires 
OpenSSL with ENGINE support and OpenSSL < 1.1.1d
SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:262: Requires 
OpenSSL with ENGINE support and OpenSSL < 1.1.1d
SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:270: Requires 
OpenSSL with ENGINE support and OpenSSL < 1.1.1d
SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:285: Requires 
OpenSSL with ENGINE support and OpenSSL < 1.1.1d
SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:425: Requires 
OpenSSL without rsa_oaep_md (< 1.0.2)
SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:441: Requires 
OpenSSL without rsa_oaep_md (< 1.0.2)
SKIPPED [3] ../../../tests/hazmat/backends/test_openssl.py:612: Requires 
OpenSSL without EVP_PKEY_DHX (< 1.0.2)
SKIPPED [2] ../../../tests/hazmat/backends/test_openssl.py:642: Requires 
OpenSSL without EVP_PKEY_DHX (< 1.0.2)
SKIPPED [2] ../../../tests/hazmat/backends/test_openssl.py:664: Requires 
OpenSSL without EVP_PKEY_DHX (< 1.0.2)
SKIPPED [1] ../../../tests/hazmat/primitives/test_aead.py:41: Requires OpenSSL 
without ChaCha20Poly1305 support
SKIPPED [1] ../../../tests/hazmat/primitives/test_aes.py:258: AES in dummy-mode 
mode not supported
SKIPPED [1] ../../../tests/utils.py:30: 256-bit DH keys are not supported in 
OpenSSL 3.0.0+ ()
SKIPPED [1] ../../../tests/hazmat/primitives/test_dh.py:432: DH keys less than 
512 bits are unsupported
SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL without Ed25519 
support ()
SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL without Ed448 support 
()
SKIPPED [1] ../../../tests/hazmat/primitives/test_ed448.py:60: ed448 contexts 
are not currently supported
SKIPPED [1] ../../../tests/utils.py:30: Does not support IDEA ECB 
()
SKIPPED [1] ../../../tests/utils.py:30: Does not support IDEA CBC 
()
SKIPPED [1] ../../../tests/utils.py:30: Does not support IDEA OFB 
()
SKIPPED [1] ../../../tests/utils.py:30: Does not support IDEA CFB 
()
SKIPPED [480] ../../../tests/hazmat/primitives/utils.py:432: KBKDF does not 
support algorithm: cmac_aes128
SKIPPED [480] ../../../tests/hazmat/primitives/utils.py:432: KBKDF does not 
support algorithm: cmac_aes192
SKIPPED [480] ../../../tests/hazmat/primitives/utils.py:432: KBKDF does not 
support algorithm: cmac_aes256
SKIPPED [480] ../../../tests/hazmat/primitives/utils.py:432: KBKDF does not 
support algorithm: cmac_tdes2
SKIPPED [480] ../../../tests/hazmat/primitives/utils.py:432: KBKDF does not 
support algorithm: cmac_tdes3
SKIPPED [800] ../../../tests/hazmat/primitives/utils.py:438: Does not support 
counter location: middle_fixed
SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL without poly1305 
support ()
SKIPPED [1] ../../../tests/utils.py:30: Requires backend without RSA OAEP label 
support ()
SKIPPED [4] ../../../tests/hazmat/primitives/test_serialization.py:1910: 
Requires bcrypt module
SKIPPED [1] ../../../tests/utils.py:30: Requires that bcrypt exists 
()
SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL without X25519 support 
()
SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL without X448 support 
()
SKIPPED [23] 
../../../../../../usr/lib/python3/dist-packages/_pytest/config/__init__.py:1473:
 no 'wycheproof_root' option found
SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL < 1.1.0f 
()
SKIPPED [1] ../../../tests/utils.py:30: Requires LibreSSL 
()
== 17 failed, 2726 passed, 3261 skipped in 203.25s (0:03:23) ===

So, we need to ignore these failures for the package to build with OpenSSL.

Ignoring the failures should be safe as it's just the tests that assume OpenSSL 
to be version <= 1.1.1.

Adrian

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

Bug#1006008: python-cryptography: FTBFS with OpenSSL 3.0

[John Paul Adrian Glaubitz]

Hi!

> Looks like an upgrade to at least v35.0.0 is needed to fix this issue: 
> https://github.com/pyca/cryptography/issues/7039#issuecomment-1088566628=

Not necessarily. One of the Python core developers, Christian Heimes, actually
backported fixes for Python3.10 and OpenSSL 3.0.0 for Fedora [1].

I have extracted the patches and I'm attaching them to this bug report. I will
test whether they fix the build on Debian.

Adrian

> [1] 
> https://src.fedoraproject.org/rpms/python-cryptography/c/b166e77e86d756b18cd79aeced13f5f3b6341a50?branch=rawhide

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
From cb1908043d5daa7c5c38945c048c4a2477a46221 Mon Sep 17 00:00:00 2001
From: Paul Kehrer 
Date: Sun, 28 Feb 2021 16:06:11 -0600
Subject: [PATCH 1/4] fix pkcs12 parse ordering. fixes #5872 (#5879)

* fix pkcs12 parse ordering. fixes #5872

* remove an unneeded print

* simplify the test a bit more

* index

* black

* Update tests/hazmat/primitives/test_pkcs12.py

Co-authored-by: Alex Gaynor 

Co-authored-by: Alex Gaynor 
---
 .../hazmat/backends/openssl/backend.py|  5 +-
 tests/hazmat/primitives/test_pkcs12.py| 58 ++-
 2 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/src/cryptography/hazmat/backends/openssl/backend.py b/src/cryptography/hazmat/backends/openssl/backend.py
index 271873d9..a96d08d8 100644
--- a/src/cryptography/hazmat/backends/openssl/backend.py
+++ b/src/cryptography/hazmat/backends/openssl/backend.py
@@ -6,6 +6,7 @@
 import collections
 import contextlib
 import itertools
+import typing
 import warnings
 from contextlib import contextmanager
 
@@ -2562,9 +2563,7 @@ class Backend(object):
 sk_x509 = self._lib.sk_X509_new_null()
 sk_x509 = self._ffi.gc(sk_x509, self._lib.sk_X509_free)
 
-# reverse the list when building the stack so that they're encoded
-# in the order they were originally provided. it is a mystery
-for ca in reversed(cas):
+for ca in cas:
 res = self._lib.sk_X509_push(sk_x509, ca._x509)
 backend.openssl_assert(res >= 1)
 
diff --git a/tests/hazmat/primitives/test_pkcs12.py b/tests/hazmat/primitives/test_pkcs12.py
index b5de09f9..b1759a1b 100644
--- a/tests/hazmat/primitives/test_pkcs12.py
+++ b/tests/hazmat/primitives/test_pkcs12.py
@@ -4,13 +4,15 @@
 
 
 import os
+from datetime import datetime
 
 import pytest
 
 from cryptography import x509
 from cryptography.hazmat.backends.interfaces import DERSerializationBackend
 from cryptography.hazmat.backends.openssl.backend import _RC2
-from cryptography.hazmat.primitives import serialization
+from cryptography.hazmat.primitives import hashes, serialization
+from cryptography.hazmat.primitives.asymmetric import ec
 from cryptography.hazmat.primitives.serialization import load_pem_private_key
 from cryptography.hazmat.primitives.serialization.pkcs12 import (
 load_key_and_certificates,
@@ -273,3 +275,57 @@ class TestPKCS12Creation(object):
 DummyKeySerializationEncryption(),
 )
 assert str(exc.value) == "Unsupported key encryption type"
+
+
+def test_pkcs12_ordering():
+"""
+In OpenSSL < 3.0.0 PKCS12 parsing reverses the order. However, we
+accidentally thought it was **encoding** that did it, leading to bug
+https://github.com/pyca/cryptography/issues/5872
+This test ensures our ordering is correct going forward.
+"""
+
+def make_cert(name):
+key = ec.generate_private_key(ec.SECP256R1())
+subject = x509.Name(
+[
+x509.NameAttribute(x509.NameOID.COMMON_NAME, name),
+]
+)
+now = datetime.utcnow()
+cert = (
+x509.CertificateBuilder()
+.subject_name(subject)
+.issuer_name(subject)
+.public_key(key.public_key())
+.serial_number(x509.random_serial_number())
+.not_valid_before(now)
+.not_valid_after(now)
+.sign(key, hashes.SHA256())
+)
+return (key, cert)
+
+# Make some certificates with distinct names.
+a_name = "A" * 20
+b_name = "B" * 20
+c_name = "C" * 20
+a_key, a_cert = make_cert(a_name)
+_, b_cert = make_cert(b_name)
+_, c_cert = make_cert(c_name)
+
+# Bundle them in a PKCS#12 file in order A, B, C.
+p12 = serialize_key_and_certificates(
+b"p12", a_key, a_cert, [b_cert, c_cert], serialization.NoEncryption()
+)
+
+# Parse them out. The API should report them in the same order.
+(key, cert, certs) = load_key_and_certificates(p12, None)
+assert cert == a_cert
+assert certs == [b_cert, c_cert]
+
+# The ordering in the PKCS#12 file itself should also match.
+a_idx = p12.i

Bug#1010189: fs-uae-launcher is broken in Sid

[John Paul Adrian Glaubitz]

Control: severity -1 normal
Control: forcemerge 1010048 -1

Hello!

On 4/26/22 00:44, Miguel A. Vallejo wrote:
> FS-UAE-Launcher in Debian Sid is now broken. It opens with a totally
> corrupted window and the terminal outputs a ton of errors.

fs-uae-launcher is not part of Debian unstable. It's available in stable only
at the moment. Please see the explanation for the reasons here [1].

Adrian

> [1] http://bugs.debian.org/1010048

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

Bug#1010048: fs-uae-launcher: GUI is corrupted.

[John Paul Adrian Glaubitz]

Control: severity -1 normal

On 4/23/22 09:26, waxhead wrote:
> Tried to start fs-uae-launcher, the GUI looks "corrupted" like below...
> 
> ++
> |[start] [][][]  |
> ||
> |+-+ |
> |[cfgwindow] |
> || | |
> |+-+ |
> ++
> 
> A start button, a config windows and some widgets overlapping [][][].
> (...)
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

fs-uae-launcher is currently not part of Debian unstable or testing due to 
insufficient
clarification of the copyright of various files shipped with the source code, 
see [1].

However, the package is part of the stable distribution and works fine there, 
just tested
it on a freshly installed system. Thus, you are using the stable package on 
Debian testing
which may result the bug you described.

But since the package isn't part of testing/unstable anyway, I don't really 
consider this
to be a valid bug report. Therefore downgrading the severity to normal.

Adrian

> [1] https://github.com/FrodeSolheim/fs-uae-launcher/issues/143

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

Bug#1008286: Should nglister be removed?

[John Goerzen]

severity 1008286 normal
reassign 1008286 ftp.debian.org
retitle 1008286 RM: nglister -- RoM; unmaintained
thx


On Fri, Mar 25 2022, Moritz Muehlenhoff wrote:

> Source: nglister
> Version: 1.0.2
> Severity: serious
>
> Your package came up as a candidate for removal from Debian:
>
> - Last upload in 2016
> - Removed from testing since 2019
> - Multiple RC bugs
>
> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
>
> If you agree with the removal, please reassign to ftp.debian.org
> by sending the following commands to cont...@bugs.debian.org:
>
> --
> severity $BUGNUM normal
> reassign $BUGNUM ftp.debian.org
> retitle $BUGNUM RM:  -- RoM; 
> thx
> --
>
> Otherwise I'll move forward and request it's removal in a month.
>
> Cheers,
> Moritz

Bug#1006702: mariadb-10.6: Baseline violation on at least i386 via CXXFLAGS

[John Paul Adrian Glaubitz]

Source: mariadb-10.6
Version: 1:10.6.7-2
Severity: serious
Justification: baseline violation

Hello!

The file mysys/CMakeFiles.txt overrides the compiler machine flags [1] and
causes mariadb-10.6 to be build with the CPU baseline of the buildd which
results in binaries that will crash on the target platform such as i386.

As can be seen in the build log for i386, the code is being built with
"-msse4.2 -mpclmul" with at least SSE 4.2 which is not available before
Intel Core i7, according to Wikipedia [3].

On ppc64, the code is being built with VSX, Crypto and POWER8 vector 
instructions
which are all not available on the POWER5 baseline that the ppc64 port in
Debian uses.

I suggest patching out the whole section in mysys/CMakeFiles.txt which may
also help fixing testsuite failures on some architectures.

Thanks,
Adrian

> [1] 
> https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/mysys/CMakeLists.txt#L62
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.6=i386=1%3A10.6.7-2=1646205322=0
> [3] https://en.wikipedia.org/wiki/SSE4#SSE4.2

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x

[John Paul Adrian Glaubitz]

Hi Christian!

On 2/16/22 12:33, Christian Kastner wrote:
>> Bus errors are normally easy to spot. Just run the code in question through
>> GDB and see where it crashes. Then look at the backtrace with the debug
>> symbols installed.
>>
>> Usually it's a result of bad pointer arithmetics which should definitely be
>> fixed as such operations usually violate the C/C++ standards.
>>
>> I can have quick look.
> 
> one of these errors has been reported in the past, and I already did
> some analysis way back then:
> 
> https://github.com/scikit-learn/scikit-learn/issues/16443
> 
> Check the last comment. The relevant Cython code doesn't look wrong, so
> I guess the problem is with the binary result produced during build, as
> you point out.

I'm happy to look at this issue but first the baseline issue must be fixed
as this is a Debian Policy violation.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x

[John Paul Adrian Glaubitz]

HellO!

On 2/16/22 11:57, John Paul Adrian Glaubitz wrote:
> On 2/16/22 11:36, Graham Inggs wrote:
>> Is anyone able to help with the bus error on armhf please?
> 
> Bus errors are normally easy to spot. Just run the code in question through
> GDB and see where it crashes. Then look at the backtrace with the debug
> symbols installed.
> 
> Usually it's a result of bad pointer arithmetics which should definitely be
> fixed as such operations usually violate the C/C++ standards.

So, I have skimmed over the build logs and one of the main issues is the use of
-march flags to enforce a certain baseline [1]:

powerpc64le-linux-gnu-gcc: error: unrecognized command-line option 
‘-march=native’; did you mean ‘-mcpu=native’?

This is a policy violation and must be fixed in any case. Blacklisting 
architectures
is not enough in this case as forcing the baseline of the buildds can lead to 
code
that won't run on the user's machines.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=scikit-learn=ppc64el=1.0.2-1=1644956229=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x

[John Paul Adrian Glaubitz]

Hello!

On 2/16/22 11:36, Graham Inggs wrote:
> Is anyone able to help with the bus error on armhf please?

Bus errors are normally easy to spot. Just run the code in question through
GDB and see where it crashes. Then look at the backtrace with the debug
symbols installed.

Usually it's a result of bad pointer arithmetics which should definitely be
fixed as such operations usually violate the C/C++ standards.

I can have quick look.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1002143: xserver-xorg-video-qxl: FTBFS: xf86Opt.h:44:10: error: two or more data types in declaration specifiers

[John Paul Adrian Glaubitz]

Hello!

There is an upstream fix available which fixes the FTBFS, see [1].

Adrian

> [1] 
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-qxl/-/merge_requests/6

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1004454: kiwi-systemdeps-bootloaders is not installable on several architectures

[John Paul Adrian Glaubitz]

Hi Adrian!

On 1/27/22 23:40, Adrian Bunk wrote:
> The following packages have unmet dependencies:
>  kiwi-systemdeps-bootloaders : Depends: grub2 but it is not installable
> 
> 
> Package: grub2
> Architecture: any-i386 any-amd64 any-powerpc any-ppc64 any-ppc64el any-sparc 
> any-sparc64

I have already prepared a fix for that. I was just waiting for the mips* builds 
to finish
to see whether any other issues occur [1].

Adrian

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

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target

[John Paul Adrian Glaubitz]

Hi Vagrant!

On 1/11/22 02:10, Vagrant Cascadian wrote:
> Something in the toolchain recently changed which causes u-boot arch:all
> build to FTBFS... I suspect binutils, as building in "bookworm" still
> works fine where binutils hasn't yet migrated.
> 
> On arch:all builds the qemu-ppce500 target is cross-compiled.
> 
> Full log:
> 
>   
> https://buildd.debian.org/status/fetch.php?pkg=u-boot=all=2022.01%2Bdfsg-1=1641860624=0
> 
> The hopefully relevent lines from the build log:
> ...
> {standard input}: Assembler messages:
> {standard input}:127: Error: unrecognized opcode: `tlbre'
> {standard input}:418: Error: unrecognized opcode: `tlbre'
> {standard input}:821: Error: unrecognized opcode: `msync'
> {standard input}:821: Error: unrecognized opcode: `tlbwe'
> {standard input}:884: Error: unrecognized opcode: `tlbsx'
> make[4]: *** [/<>/scripts/Makefile.build:253: 
> arch/powerpc/cpu/mpc85xx/tlb.o] Error 1
> make[3]: *** [/<>/Makefile:1810: arch/powerpc/cpu/mpc85xx] Error 
> 2
> make[3]: *** Waiting for unfinished jobs
>   powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
> 
> 
> If anyone has thoughts what might be the issue, please chime in!

It's most likely this upstream change [1] in binutils that broke the build.

It also affects glibc [2] and the kernel [3][4], for example.

Adrian

> [1] 
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003847
> [3] 
> https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0
> [4] 
> https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)

[John Paul Adrian Glaubitz]

Hello!

On 1/19/22 22:38, Jeffrey Walton wrote:
> On Wed, Jan 19, 2022 at 4:08 PM John Paul Adrian Glaubitz
>  wrote:
>>
>> Unfortunately, glibc no longer builds with this change on powerpc and ppc64
>> and kernel builds still fails on both targets:
>>
>>> https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0
>>> https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0
>>
>>> https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0
>>> https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0
> 
> This seems to be related to the ones stamped 1642542048 and 1642542055
> (the first two):
> https://patchwork.sourceware.org/project/glibc/patch/20210925202746.819385-1...@us.ibm.com/

It will be fixed in glibc_2.33-4 [1] which has not been released yet.

Adrian

> [1] 
> https://salsa.debian.org/glibc-team/glibc/-/commit/20e02061f900515ebac6ee3872c5cd22ea5801d2

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)

[John Paul Adrian Glaubitz]

Hi Aurelien!

Unfortunately, glibc no longer builds with this change on powerpc and ppc64
and kernel builds still fails on both targets:

> https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0
> https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0

> https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0
> https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1003964: pandoc doesn't start: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0

[John MacFarlane]

A note from upstream, in case it's helpful:  we haven't depended
on cmark-gfm since pandoc 2.10.1 (released a year and a half
ago).  If you could move to a more recent version of pandoc, this
would avoid the problem entirely.  I'm aware that issues of
policy and packaging may make this difficult, though.

Bug#999249: Package will now be considered for auto-removal

[John Paul Adrian Glaubitz]

Hello!

On 1/8/22 20:35, Graham Inggs wrote:
> The release team no longer [1] considers popcon a criterion for
> inclusion in the list of key packages [2].
> 
> This email is a courtesy reminder of this bug, and should prevent
> instant auto-removal once the rule is changed in britney.

discover has an installation count of nearly 200.000. Do we really remove
a package that is being installed on so many machines?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer

[John Paul Adrian Glaubitz]

Hi Camm!

On 12/28/21 19:52, John Paul Adrian Glaubitz wrote:
> On 12/28/21 19:20, Camm Maguire wrote:
>> Correction, that is current autobuilders on 68k and sh4.
> 
> That's a known issue, see [1]. I will patch the glibc packages for m68k
> and sh4 again to address this issue.

I have uploaded patched versions of glibc for m68k and sh4 and blocked the
autobuild for glibc on the buildds.

You may want to merge the bug with the existing bug report [1] and adjust the
severity to normal.

Adrian


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

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer

[John Paul Adrian Glaubitz]

Hello Camm!

On 12/28/21 19:20, Camm Maguire wrote:
> Correction, that is current autobuilders on 68k and sh4.

That's a known issue, see [1]. I will patch the glibc packages for m68k
and sh4 again to address this issue.

Adrian

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#998867: debootstrap: --no-merged-usr became a no-op

[Dimitri John Ledkov]

There are multiple issues reported in a single bug.

> This means that I cannot create a Debian chroot from Debian unstable from 10 
> years ago from snapshot.debian.org without merged-/usr and thus my chroot 
> will behave differently as it did back then.
> Please re-enable --no-merged-usr so that I can re-create old chroots from 
> snapshot.d.o again.

I don't think debootstrap has such goals, or requirement to be able to
bootstrap rolling release without a changing codename like
unstable/sid. debootstrap already sets options that may not be
supported or lead to incorrect chroots if debootstrap & scripts are
used from too far away time window for a rolling release. If you
desire to re-create a debootstrap of unstable as it looked 10 years
ago, it is best to do it using 10 years old debootstrap from the said
snapshot archive too.

Note that stable/testing are not affected as much, because the rolling
alias is resolved to a codename, and hence doing debootstrap from an
old snapshot of "stable" will do what the codename "lenny" wants,
although there is no guarantee that current debootstrap will resolve
things the same way as the 10 year old debootstrap did.

Allowing --no-merged-usr option unguarded may lead to users creating
incorrect installations and chroots for the future releases,
especially since packages can assume merged-usr in the upcoming
releases.

I wonder if I can do some further checks, I.e. if unstable, and the
InRelease / Release Date is old, do split-usr. I.e. anything before
2022. Effectively implement a time guard "old-sid" vs "new-sid", since
the codename for sid has not changed. Thus allowing to bootstrap old
sid snapshots in a manner closer to what old debootstrap from said
snapshot would do. But still wIthout any guarantees that it will be
identical.

> Also, build chroots must still be created without merged-usr for 
> sid/bookworm, until something's been done to migrate user systems.

But Julien, you said that buildds run stable, meaning they are
unaffected by this debootstrap change in sid/bookworm.

> Please point out what you plan to do about this change in debootstrap so that 
> I can adapt the mmdebstrap autopkgtest accordingly.

I did notice the mmdebstrap autopkgtest regression. I also noticed
that mmdebstrap does not support --merged-usr flag, and instead offers
three ways of creating chroots that are merged-usr.
To match the current debootstrap behaviour in sid, as currently
implemented in debootstrap in sid, it seems to me that mmdebstrap
should auto-enable
`--setup-hook=/usr/share/mmdebstrap/hooks/merged-usr/setup00.sh` for
sid/bookworm, but somehow continue to honor user supplied
--setup-hooks (append? override?) I was going to file a bug report
about that after using mmdebstrap, as I have not used it yet and not
sure how that would fit into UX and user expectations.

-- 
Regards,

Dimitri.

Bug#995223: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#995223: fixed in libffi 3.4.2-3)

[John Paul Adrian Glaubitz]

Hi Matthias!

On 10/11/21 15:27, John Paul Adrian Glaubitz wrote:
> This did not fix the bug, unfortunately. libffi is still being built with
> "-mcpu=power8" on ppc64, see the full build log in [1].
> 
> We didn't need --enable-portable before, so this isn't the issue but I assume
> the problem is the new autoconf version which is not compatible with libffi 
> [2].

Julien has suggested on #debian-devel to build with --without-gcc-arch instead 
of
--enable-portable-binary and it indeed fixes the problem for me:

--- debian/rules.orig   2021-09-15 09:03:02.0 -0700
+++ debian/rules2021-10-28 05:10:01.357633494 -0700
@@ -53,6 +53,7 @@
--infodir=\$${prefix}/share/info \
--enable-pax_emutramp \
--disable-exec-static-tramp \
+   --without-gcc-arch \
CC="$(CC)" \
CXX="$(CXX)" \
CPPFLAGS="$(CPPFLAGS)" \

Could you update the debian/rules accordingly?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#997767: open-ath9k-htc-firmware: FTBFS: patching fails

[John Scott]

The fix is currently waiting in the NEW queue.


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

Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault

[John Paul Adrian Glaubitz]

On 10/18/21 13:16, Antonio Terceiro wrote:
> I don't think we are on the right track here. I need to read the failing
> test correctly. this "test case" alone is bogus, as
> 
> ruby -e 'END {Process.kill :SEGV, $$}'
> 
> is _expected_ to segfault, i.e. the process is sending a SEGV signal to
> itself. This test case is not complete.

It might be an idea to look at the Fedora package:

> https://src.fedoraproject.org/rpms/ruby/blob/rawhide/f/ruby.spec

It has a number of patches against 3.x:

> https://src.fedoraproject.org/rpms/ruby/tree/rawhide

It builds fine on ppc64el:

> https://koji.fedoraproject.org/koji/buildinfo?buildID=1801321

OTOH, ruby3.0 builds fine in openSUSE Factory on ppc64el, but they're still at
version 3.0.1, so it might be an issue that will only show with 3.0.2?

> https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/ruby3.0

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault

[John Paul Adrian Glaubitz]

On 10/18/21 12:51, Antonio Terceiro wrote:
>> So, we need a backtrace to see where the crash actually happens. I assume 
>> it's in one
>> of the build dependencies.
> 
> it happens in glibc:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x77a48f04 in kill () from /lib/powerpc64le-linux-gnu/libc.so.6

Hmm, both were built with glibc 2.32-4.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault

[John Paul Adrian Glaubitz]

Hello!

On 10/17/21 21:50, John Paul Adrian Glaubitz wrote:
> Ah, so the last successful build was 3.0.2-2 and the first failure was in 
> 3.0.2-3,
> the only difference being the mipsel patch to fix an unaligned access.
> 
> However, 3.0.2-2 was built with gcc-10:
> 
>> https://buildd.debian.org/status/fetch.php?pkg=ruby3.0=ppc64el=3.0.2-2=1633362713=0
> 
> while 3.0.2-3 was built with gcc-11:
> 
>> https://buildd.debian.org/status/fetch.php?pkg=ruby3.0=ppc64el=3.0.2-3=1634169532=0
> 
> So, first we should try building with gcc-10 and see if that makes a 
> difference.

I have tested the build with gcc-10 but the problem remains, so it's not a 
compiler
issue. Dropping the patch rand_init-fix-off-by-one-error.patch that was 
introduced
with 3.0.2-3 doesn't help either.

So, we need a backtrace to see where the crash actually happens. I assume it's 
in one
of the build dependencies.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault

[John Paul Adrian Glaubitz]

Hi!

On 10/17/21 21:47, John Paul Adrian Glaubitz wrote:
> Since ruby3.0 used to build fine on ppc64el in the past, the easiest way would
> be to just bisect the issue. I can give it a try and see if I can find the
> problematic commit.

Ah, so the last successful build was 3.0.2-2 and the first failure was in 
3.0.2-3,
the only difference being the mipsel patch to fix an unaligned access.

However, 3.0.2-2 was built with gcc-10:

> https://buildd.debian.org/status/fetch.php?pkg=ruby3.0=ppc64el=3.0.2-2=1633362713=0

while 3.0.2-3 was built with gcc-11:

> https://buildd.debian.org/status/fetch.php?pkg=ruby3.0=ppc64el=3.0.2-3=1634169532=0

So, first we should try building with gcc-10 and see if that makes a difference.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault

[John Paul Adrian Glaubitz]

Hello Antonio!

On 10/17/21 20:57, Antonio Terceiro wrote:
> I'm copying the debian-powerpc list to see if anyone can help.
> 
> ruby3.0 fails to build on ppc64el. 4 test cases results in Segmentation
> faults.
> 
> I was able to reproduce this on the porter box, and the minimal test
> case, inside a build source tree, is this:
> 
> ./miniruby -e 'END {Process.kill :SEGV, $$}'

Since ruby3.0 used to build fine on ppc64el in the past, the easiest way would
be to just bisect the issue. I can give it a try and see if I can find the
problematic commit.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#984401: vtk7: ftbfs with GCC-11

[John David Anglin]

Source: vtk7
Version: 7.1.1+dfsg2-10+b2
Followup-For: Bug #984401

Dear Maintainer,

On hppa:

[  3%] Building CXX object 
ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o
cd /<>/debian/build/ThirdParty/xdmf2/vtkxdmf2/libsrc && 
/usr/bin/mpic++ -DLinux -DMPICH_IGNORE_CXX_SEEK -DVTK_IN_VTK -D_HPUX_SOURCE 
-Dvtkxdmf2_EXPORTS -I/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc 
-I/<>/debian/build/ThirdParty/xdmf2/vtkxdmf2/libsrc 
-I/<>/debian/build/ThirdParty/xdmf2 
-I/<>/ThirdParty/xdmf2 
-I/<>/debian/build/ThirdParty/hdf5 
-I/<>/ThirdParty/hdf5 -I/usr/include/hdf5/openmpi 
-I/<>/debian/build/ThirdParty/zlib 
-I/<>/ThirdParty/zlib 
-I/<>/debian/build/ThirdParty/libxml2 
-I/<>/ThirdParty/libxml2 -I/usr/include/libxml2 
-I/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/utils -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2  -w -w -w -fPIC -MD -MT 
ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o -MF 
CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o.d -o 
CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o -c 
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmMsg.cxx
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx: In member 
function ‘virtual XdmfInt32 xdmf2::XdmfDsmComm::Receive(xdmf2::XdmfDsmMsg*)’:
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx:55:18: error: 
ordered comparison of pointer with integer zero (‘void*’ and ‘int’)
   55 | if(Msg->Data <= 0 ){
  |~~^~~~
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx: In member 
function ‘virtual XdmfInt32 xdmf2::XdmfDsmComm::Send(xdmf2::XdmfDsmMsg*)’:
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx:69:18: error: 
ordered comparison of pointer with integer zero (‘void*’ and ‘int’)
   69 | if(Msg->Data <= 0 ){
  |~~^~~~
make[4]: *** 
[ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/build.make:541: 
ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/XdmfDsmComm.cxx.o] 
Error 1
make[4]: *** Waiting for unfinished jobs

Regards,
Dave Anglin

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

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

Bug#995223: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#995223: fixed in libffi 3.4.2-3)

[John Paul Adrian Glaubitz]

Control: reopen -1

Hello!

This did not fix the bug, unfortunately. libffi is still being built with
"-mcpu=power8" on ppc64, see the full build log in [1].

We didn't need --enable-portable before, so this isn't the issue but I assume
the problem is the new autoconf version which is not compatible with libffi [2].

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=libffi=ppc64=3.4.2-3=1633957534=0
> [2] https://github.com/libffi/libffi/issues/662

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#984138: fs-uae: ftbfs with GCC-11

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Hi!

On 3/3/21 17:12, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
> severity of this report will be raised before the bookworm release,
> so nothing has to be done for the bullseye release.

FWIW, upstream has fixed the issue on the stable branch already [1], see
attached patch. I'm just waiting for the upcoming stable version to be
released.

I'll then uploaded the fixed version immediately.

Adrian

> [1] 
> https://github.com/FrodeSolheim/fs-uae/commit/bf81e7d2a60b2c8646663889e4a4431b988ae972

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
From bf81e7d2a60b2c8646663889e4a4431b988ae972 Mon Sep 17 00:00:00 2001
From: Frode Solheim 
Date: Fri, 8 Oct 2021 11:39:16 +0200
Subject: [PATCH] Work around an incompatibility with C++17

---
 src/dosbox/setup.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/dosbox/setup.h b/src/dosbox/setup.h
index db75ada8..e0a3a75d 100644
--- a/src/dosbox/setup.h
+++ b/src/dosbox/setup.h
@@ -54,6 +54,12 @@ public:

 };
 
+#ifdef FSUAE
+// Work around an incompatibility with C++17. It does not seem like these
+// functions are used anyway.
+#define throw(...) throw()
+#endif
+
 class Value {
 /* 
  * Multitype storage container that is aware of the currently stored type in it.
@@ -113,6 +119,11 @@ private:
 	void set_double(std::string const& in);
 };
 
+#ifdef FSUAE
+#undef throw
+#endif
+
+
 class Property {
 public:
 	struct Changeable { enum Value {Always, WhenIdle,OnlyAtStart};};
-- 
2.33.0

Bug#995362: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614

[John Scott]

On Thu, 2021-09-30 at 09:18 -0400, John Scott wrote:
> Outside a minimal chroot, on my desktop system, zbarimg seems to
> process SVGs just fine. So this may be a case of a Recommends
> (somewhere) not being installed wreaking havok, but in my opinion
> zbarimg should still not behave this way when a Recommends is
> missing.

I've found the culprit: if libmagickcore-6.q16-6-extra is not
installed, then this cryptic error occurs. I've reported this issue
(the lack of a helpful error message) at
https://github.com/mchehab/zbar/issues/202 .

I'll leave it to the maintainer to decide what they'd like to do:
either hardcode a dependency on libmagickcore-6.q16-6-extra, or switch
zint's output format to PNG (I personally would prefer the latter).


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

Bug#986709: rsnapshot is stable, not dead

[John Brooks]

On 2021-09-30 6:13 p.m., Michael Lustfield wrote:

On Sun, 26 Sep 2021 13:49:36 -0400
John Brooks  wrote:


[...]


So... My first response was a wordier version of the message you replied to,
emphasizing the bit where my opinion is moot. What's written below is as much
as I'm willing to dip back into #debiandrama. While reading, please remember
this point (and don't expect further response).


My original request was for a removal, which is a stance I whole-heartedly
still stand by, and which draws from experiences after adopting the package. A
removal like this is basically orphan++ ("I'm afk4eva" vs. "bad package"). That
changed slightly with zeha's bug modifications, but the effect is still largely
the same, with a touch of stability added. (Thanks zeha!)

(sensible action, but likely helps with that "limbo" perception?)
   ^ https://tracker.debian.org/pkg/rsnapshot

side note --

   > Additionally, in response to this very bug, a new upstream release has
   > now been issued. In light of this, do you plan to upload the new version

   You very correctly point out that a number of fixes and a new release came
   directly in response to certain actions. Unfortunately, we draw very 
different
   conclusions. (a hint, perhaps?)


I appreciate that you responded to that particular (#30) message of mine, where
I say that I don't intend to stand in anyone's way, and offered to help anyone
interested in package maintenance, while also maintaining my position. This is
important to me because some people have indeed taken a stab at rsnapshot
maintenance; however, they very quickly disappeared when they learned that it
would require more effort than just slapping an updated tarball onto the
packaging.


and continue to fill the role of maintainer for the rsnapshot Debian
package, or is another maintainer still needed going forward?


^ "continue" stopped at the RM-RoQA (note: this tag was not an accident)

The root of why I claim how I feel does not matter is because the end result is
the same. The only thing that's required to override my (strong) opinion is for
someone to pick it up, understand it well enough to confidently claim it's
ready for release (start w/ debian bugs), and that'll be the end of this thread.



Thank you for your reply. I admit I'm rather a dilettante in this area. 
I'm only a user and have had little or no exposure to the Debian 
development process. I didn't even see "RoQA" until you pointed it out, 
and then had to look up what it means — "Requested by the QA team".


And that's about where my ability to contribute usefully ends. My belief 
that the Debian organization and its contributors are generally 
intelligent and sensible leads me to believe that you and the QA team 
have good reasons for removing the package, even if I don't understand them.


I don't know precisely what criteria of stability and quality are used 
to judge whether a package is suitable for inclusion; my outside view is 
that this package is no more broken or unmaintained than the average 
Debian package. The only bug of "serious" severity classification is 
this one. But when my uninformed assessment is at odds with an actual 
Debian maintainer, I have no choice but to assume that there is an 
important factor which I am blind to. I understand that it's not your 
responsibility to teach me just to satisfy my idle curiosity, so we can 
leave it at that.


Thank you for your service.

John Brooks

Bug#995362: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614

[John Scott]

Control: reassign -1 zbar-tools
Control: notfound -1 zint/2.10.0-1
Control: owner -1 !


I think I've partially identified what is happening.

It turns out that the version of zint in testing, despite being passed
the --filetype=SVG flag, actually produces a PNG, which in the past has
been happily processed by zbar.

This bug in zint seems to have been fixed in the new version, so that
specifying --filetype=SVG actually produces an SVG now. And it appears
that the error is coming from zbarimg, which as a matter of fact gives
the same error in a minimal chroot trying to process any SVG.

Outside a minimal chroot, on my desktop system, zbarimg seems to
process SVGs just fine. So this may be a case of a Recommends
(somewhere) not being installed wreaking havok, but in my opinion
zbarimg should still not behave this way when a Recommends is missing.

I'll debug this more later, but for now I'm reassigning the bug to
zbar-tools, since I see this is not an issue in zint.


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

Bug#995223: libffi: SIGILL on powerpc and ppc64 systems since libffi8

[John Paul Adrian Glaubitz]

Hello!

On 9/29/21 00:38, John Paul Adrian Glaubitz wrote:
> There is actually a baseline violation on i386 as "-march=amdfam10" is
> passed to the compiler, see the build log in [1], for example.

Comparing the build logs, it seems that this an issue with the newer version
of autoconf that was used to build version 3.4.2-2. Looking at the log for
3.4.2-2, a lot of autoconf warnings can be seen which are not present in the
log for 3.4.1-1.

> https://buildd.debian.org/status/fetch.php?pkg=libffi=powerpc=3.4.2-1=1626443428=0
> https://buildd.debian.org/status/fetch.php?pkg=libffi=powerpc=3.4.2-2=1632868252=0

So, upstream needs to fix compatibility issues with the newer autoconf version.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995223: libffi: SIGILL on powerpc and ppc64 systems since libffi8

[John Paul Adrian Glaubitz]

Hi!

On 9/28/21 22:40, John Paul Adrian Glaubitz wrote:
> We should therefore pass "--enable-portable-binary" in debian/rules.

There is actually a baseline violation on i386 as "-march=amdfam10" is
passed to the compiler, see the build log in [1], for example.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=libffi=i386=3.4.2-2=1632469242=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#986709: rsnapshot is stable, not dead

[John Brooks]

On Fri, 28 May 2021 15:39:28 -0500 Michael Lustfield 
 wrote:

> On Fri, 28 May 2021 19:56:47 +0100
> David Cantrell  wrote:
>
> > [...]
> > So what, exactly, is unmaintained about it? Looks to me like it has
> > exactly the amount of maintenance that is required for mature software.
>
> I'm not going to strawman my justifications; it's not terribly 
relevant anyway.
> Absolutely anyone is free to disagree with me and continue 
maintenance of the

> package. If needed, I'll even sponsor the upload.
>
> https://mentors.debian.net/intro-maintainers (read 1-2, start at 3)
>

>

Michael,

I think it is important that you clarify or modify your stance given 
that upon further inspection by others here, there are no serious 
outstanding functional or security issues with the program. Even 
self-asserted justification (i.e. "I just don't want to maintain it 
anymore, so find someone else") is acceptable; that is your right as a 
volunteer. But it would have been prudent to either defend your initial 
assessment of the program as no longer suitable for inclusion, or 
acknowledge that you may have been incorrect. Otherwise the issue is 
just stuck in limbo.


Additionally, in response to this very bug, a new upstream release has 
now been issued. In light of this, do you plan to upload the new version 
and continue to fill the role of maintainer for the rsnapshot Debian 
package, or is another maintainer still needed going forward?


I don't seek to impose anything upon you, I just want to see that this 
doesn't fall through the cracks.


Thanks
John Brooks

Bug#994727: reportbug: Hang at boot (pre-X) with [drm] CPU Pipe A FIFO underrun [workaround included]

[John Goerzen]

Package: src:linux
Version: 5.10.46-4
Severity: critical

Hello,

After upgrading this laptop from buster to bullseye, I started to have
issues.  The laptop uses a LUKS root, so it pauses before loading X to
prompt for a password.  Therefore I know this problem is not just X.

Immediately after putting in my password, I would observe screen corruption
(random garbage on the top few rows of pixels) followed by a complete
system hang.  Occasionally I was able to see a message on the console
first:

[drm] CPU Pipe A FIFO underrun

I tried booting the Debian bullseye live image, and it too would hang a few
minutes into the session (which was X-based) with no message at all.

Quite a bit of searching brought me to #884116 and this thread
https://lists.debian.org/debian-kernel/2017/12/msg00350.html.
Unfortunately, it didn't immediately help.

I tried iommu=soft and other iommu options, but they only resolved the
corruption but not the crash.

Eventually, I found
https://askubuntu.com/questions/895329/flickering-screen-cpu-pipe-b-fifo-underrun-when-i-use-the-termnal
which recommended these kernel options:

i915.enable_psr=0 i915.edp_vswing=2

This resolved the issue and the system booted normally.  That report also
mentions screen flickering; I also have been experiencing that in the
console (but not X) and the flickering persisted, but that is not a big
deal to me since most of the time is spent in X.

The askubuntu page also referenced disabling C-states in BIOS, though that
was not necessary for me.

This system is a Dell Latitude 7480 with a Core i7-7600U and Intel HD
Graphics 620.



-- Package-specific info:
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-4 (2021-08-03)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-8-amd64 root=ZFS=rpool/ROOT/debian-1 ro 
i915.enable_psr=0 i915.edp_vswing=2

** Tainted: PUOE (12353)
 * proprietary module was loaded
 * taint requested by userspace application
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[9.961833] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD (1bcf:2b96)
[9.966740] dell_laptop: Using i8042 filter function for receiving events
[9.982813] input: Integrated_Webcam_HD: Integrate as 
/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input11
[9.987357] Console: switching to colour dummy device 80x25
[9.987385] i915 :00:02.0: vgaarb: deactivate vga console
[9.991762] usbcore: registered new interface driver uvcvideo
[9.991766] USB Video Class driver (1.1.1)
[   10.010681] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   10.013323] i915 :00:02.0: firmware: direct-loading firmware 
i915/kbl_dmc_ver1_04.bin
[   10.013611] i915 :00:02.0: [drm] Finished loading DMC firmware 
i915/kbl_dmc_ver1_04.bin (v1.4)
[   10.033304] i915 :00:02.0: [drm] Panel advertises DPCD backlight 
support, but VBT disagrees. If your backlight controls don't work try booting 
with i915.enable_dpcd_backlight=1. If your machine needs this, please file a 
_new_ bug report on drm/i915, see 
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for 
details.
[   10.042820] mei_hdcp :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: 
bound :00:02.0 (ops i915_hdcp_component_ops [i915])
[   10.043946] Intel(R) Wireless WiFi driver for Linux
[   10.044259] iwlwifi :02:00.0: enabling device ( -> 0002)
[   10.078776] iwlwifi :02:00.0: firmware: direct-loading firmware 
iwlwifi-8265-36.ucode
[   10.079252] iwlwifi :02:00.0: loaded firmware version 36.ad812ee0.0 
8265-36.ucode op_mode iwlmvm
[   10.079281] iwlwifi :02:00.0: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[   10.079283] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   10.153860] Bluetooth: Core ver 2.22
[   10.153883] NET: Registered protocol family 31
[   10.153886] Bluetooth: HCI device and connection manager initialized
[   10.153890] Bluetooth: HCI socket layer initialized
[   10.153892] Bluetoo
th: L2CAP socket layer initialized
[   10.153896] Bluetooth: SCO socket layer initialized
[   10.170927] usbcore: registered new interface driver btusb
[   10.185285] Bluetooth: hci0: Bootloader revision 0.0 build 26 week 38 2015
[   10.186286] Bluetooth: hci0: Device revision is 16
[   10.186289] Bluetooth: hci0: Secure boot is enabled
[   10.186290] Bluetooth: hci0: OTP lock is enabled
[   10.186291] Bluetooth: hci0: API lock is enabled
[   10.186292] Bluetooth: hci0: Debug lock is disabled
[   10.186293] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[   10.189271] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-12-16.sfi
[   10.189278] Bluetooth: hci0: Found device firmware: intel/ibt-12-16.sfi
[   10.281773] EXT4-fs (sda2): mounting ext2 file 

Bug#992689: dino crashing with new gnome 40

[John Scott]

On Sun, 2021-08-22 at 13:43 -0400, Taowa wrote:
> I'm planning on doing an upload this week to fix it- ideally today.

Do you still got this, Taowa?


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

Bug#978793: dnssec-trigger: ftbfs with autoconf 2.70

[John Scott]

Hey Matthias,

> checking for library containing inet_pton... none required
> checking for library containing socket... none required
> checking for GNU libc compatible malloc... yes
> configure: error: cannot run /bin/sh ./config.sub

Can you double-check this/run a rebuild and see if it was a spurious
issue? I'm not the maintainer, just a wandering passerby, but it seems
dnssec-trigger's configure script builds and works just fine with
Autoconf 2.71.

I can't explain the error from your log with being unable to run
config.sub, but it doesn't occur on my system and dnssec-trigger builds
successfully.


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

Bug#991501: linux-image-5.10.0-8-amd64: amdgpu does not let Graphics Card enter low power state, HIGH idle powerconsumption

[John Franklin]

e3]
Subsystem: Lenovo Family 17h (Models 10h-1fh) HD Audio Controller 
[17aa:5094]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel


** USB devices:
Bus 006 Device 003: ID 17ef:3070 Lenovo USB3.1 Hub 
Bus 006 Device 002: ID 17ef:3070 Lenovo USB3.1 Hub 
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 004: ID 0bda:4852 Realtek Semiconductor Corp. Bluetooth Radio
Bus 005 Device 003: ID 06cb:00bd Synaptics, Inc. Prometheus MIS Touch 
Fingerprint Reader
Bus 005 Device 006: ID 17ef:3075 Lenovo USB Billboard Device   
Bus 005 Device 008: ID 17ef:306f Lenovo ThinkPad Dock USB Audio
Bus 005 Device 013: ID 05ac:9226 Apple, Inc. LED Cinema Display
Bus 005 Device 012: ID 05ac:8508 Apple, Inc. iSight in LED Cinema Display
Bus 005 Device 011: ID 05ac:1105 Apple, Inc. Audio in LED Cinema Display
Bus 005 Device 010: ID 413c:2003 Dell Computer Corp. Keyboard SK-8115
Bus 005 Device 009: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse
Bus 005 Device 007: ID 05ac:9126 Apple, Inc. 
Bus 005 Device 005: ID 17ef:3071 Lenovo USB2.0 Hub 
Bus 005 Device 002: ID 17ef:3071 Lenovo USB2.0 Hub 
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 17ef:3074 Lenovo USB Billboard
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 04f2:b6d0 Chicony Electronics Co., Ltd Integrated 
Camera
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/16 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 linux-image-5.10.0-8-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-8-amd64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-8-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.04-20
pn  linux-doc-5.10  

Versions of packages linux-image-5.10.0-8-amd64 is related to:
ii  firmware-amd-graphics 20210315-2
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
ii  firmware-linux-nonfree20210315-2
ii  firmware-misc-nonfree 20210315-2
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20210315-2
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

-- 
John Franklin
frank...@sentaidigital.com

Bug#990627: python3-torchaudio: torchaudio import aborts

[John O'Hagan]

Package: python3-torchaudio
Version: 0.7.2-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: johnmoha...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

The line "import torchaudio" at the python interactive shell or in a python
script or imported file results in the progra aborting with the following
output:

--

terminate called after throwing an instance of 'c10::Error'
  what():  Type c10::intrusive_ptr,
c10::detail::intrusive_target_default_null_type > >
could not be converted to any of the known types.
Exception raised from call at ../aten/src/ATen/core/jit_type.h:1698 (most
recent call first):
frame #0: c10::Error::Error(c10::SourceLocation,
std::__cxx11::basic_string, std::allocator
>) + 0x5c (0x7fb37a0b925c in /usr/lib/x86_64-linux-gnu/libc10.so.1.7)
frame #1:  + 0x11d0ac2 (0x7fb376ddfac2 in
/usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7)
frame #2:  + 0xe7d991 (0x7fb376a8c991 in
/usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7)
frame #3:
c10::detail::infer_schema::make_function_schema(std::__cxx11::basic_string, std::allocator >&&,
std::__cxx11::basic_string, std::allocator
>&&, c10::ArrayRef,
c10::ArrayRef) + 0x6a (0x7fb376a8d70a
in /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7)
frame #4:  + 0x120457f (0x7fb376e1357f in
/usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7)
frame #5:  + 0x11fe28f (0x7fb376e0d28f in
/usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7)
frame #6:  + 0x11fe404 (0x7fb376e0d404 in
/usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7)
frame #7:  + 0xdb5480 (0x7fb3769c4480 in
/usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7)
frame #8:  + 0xcdd79c (0x7fb3768ec79c in
/usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7)
frame #9:  + 0xffe2 (0x7fb3d5ec1fe2 in /lib64/ld-
linux-x86-64.so.2)
frame #10:  + 0x100e9 (0x7fb3d5ec20e9 in /lib64/ld-
linux-x86-64.so.2)
frame #11: _dl_catch_exception + 0xdd (0x7fb3d5c302bd in /lib/x86_64-linux-
gnu/libc.so.6)
frame #12:  + 0x14058 (0x7fb3d5ec6058 in /lib64/ld-
linux-x86-64.so.2)
frame #13: _dl_catch_exception + 0x80 (0x7fb3d5c30260 in /lib/x86_64-linux-
gnu/libc.so.6)
frame #14:  + 0x138fa (0x7fb3d5ec58fa in /lib64/ld-
linux-x86-64.so.2)
frame #15:  + 0x1258 (0x7fb3d5e55258 in /lib/x86_64-linux-
gnu/libdl.so.2)
frame #16: _dl_catch_exception + 0x80 (0x7fb3d5c30260 in /lib/x86_64-linux-
gnu/libc.so.6)
frame #17: _dl_catch_error + 0x2f (0x7fb3d5c3031f in /lib/x86_64-linux-
gnu/libc.so.6)
frame #18:  + 0x1a65 (0x7fb3d5e55a65 in /lib/x86_64-linux-
gnu/libdl.so.2)
frame #19: dlopen + 0x44 (0x7fb3d5e552e4 in /lib/x86_64-linux-gnu/libdl.so.2)
frame #20:  + 0x14e8d (0x7fb3d5e9ce8d in
/usr/lib/python3.9/lib-dynload/_ctypes.cpython-39-x86_64-linux-gnu.so)
frame #21: /usr/bin/python3() [0x53f38a]
frame #22: _PyObject_MakeTpCall + 0x39b (0x51d89b in /usr/bin/python3)
frame #23: _PyEval_EvalFrameDefault + 0x5654 (0x5170e4 in /usr/bin/python3)
frame #24: /usr/bin/python3() [0x510fe7]
frame #25: _PyFunction_Vectorcall + 0x361 (0x528d21 in /usr/bin/python3)
frame #26: /usr/bin/python3() [0x537b80]
frame #27: _PyObject_MakeTpCall + 0x1f5 (0x51d6f5 in /usr/bin/python3)
frame #28: _PyEval_EvalFrameDefault + 0x5b2a (0x5175ba in /usr/bin/python3)
frame #29: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3)
frame #30: /usr/bin/python3() [0x53bcfb]
frame #31: _PyEval_EvalFrameDefault + 0x53e6 (0x516e76 in /usr/bin/python3)
frame #32: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3)
frame #33: /usr/bin/python3() [0x53bcfb]
frame #34: _PyEval_EvalFrameDefault + 0x53e6 (0x516e76 in /usr/bin/python3)
frame #35: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3)
frame #36: _PyEval_EvalFrameDefault + 0x525 (0x511fb5 in /usr/bin/python3)
frame #37: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3)
frame #38: _PyEval_EvalFrameDefault + 0x525 (0x511fb5 in /usr/bin/python3)
frame #39: /usr/bin/python3() [0x5106ed]
frame #40: _PyEval_EvalCodeWithName + 0x47 (0x510497 in /usr/bin/python3)
frame #41: PyEval_EvalCode + 0x23 (0x5f5be3 in /usr/bin/python3)
frame #42: /usr/bin/python3() [0x5fa670]
frame #43: /usr/bin/python3() [0x5298c4]
frame #44: _PyEval_EvalFrameDefault + 0x610b (0x517b9b in /usr/bin/python3)
frame #45: /usr/bin/python3() [0x5106ed]
frame #46: _PyFunction_Vectorcall + 0x361 (0x528d21 in /usr/bin/python3)
frame #47: _PyEval_EvalFrameDefault + 0x53e6 (0x516e76 in /usr/bin/python3)
frame #48: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3)
frame #49: _PyEval_EvalFrameDefault + 0x702 (0x512192 in /usr/bin/python3)
frame #50: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3)
frame #51: _PyEval_EvalFrameDefault + 0x525 (0x511fb5 in /usr/bin/python3)
frame #52: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3)
frame #53: _PyEval_EvalFrameDefault + 0x525 (0x511fb5 in /usr/bin/python3)
frame #54: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3)
frame #55: /usr/bin/python3() [0x52842e]
frame #56: 

Bug#986527: sagemath: FTBFS: addressing for Bullseye & newcomer suggestions

[John Scott]

On Wed, 09 Jun 2021 00:32:02 + John Scott 
wrote:
> I believe it's in the best interest of Debian users that this bug be
> downgraded for Bullseye so Sage can be used in the mostly-wholesome
> shape it's in, but since I lack expertise in maintaining it I too 
> will leave this to someone else.

If you're looking for someone that can be committed to fixing issues in
SageMath for the duration of the stable release cycle, I think I can
step up to the plate, with the caveat that I will have to learn as I go
since I don't yet know Python, but would like to learn and could seize
this opportunity. (C is my forte, so perhaps I can help with some
dependencies.)

I've sent a merge request to add a superficial autopkgtest checking
that 'sage -v' works, as it has broken in the past, and would
appreciate if it could be merged (I believe this is appropriate during
the freeze):
https://salsa.debian.org/science-team/sagemath/-/merge_requests/14

Please let me know if there is any other low-hanging fruit I could work
on as a newcomer to get acquainted with the package.


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

Bug#989645: /usr/sbin/grub-mkconfig: dpkg: error processing package linux-image-powerpc (--configure):

[John Paul Adrian Glaubitz]

Control: severity -1 normal

Hello Rick!

On 6/9/21 11:15 AM, Rick Thomas wrote:
> Package: grub-common
> Version: 2.04-18
> Severity: grave
> File: /usr/sbin/grub-mkconfig
> Justification: renders package unusable

Since powerpc is not a release architecture, setting the severity to "grave" is 
not
allowed here. I am therefore downgrading this to "normal".

> This is what happens when I attempt to do "aptitude full-upgrade" on my 
> PowerPC machine:
> 
> root@dillserver:/home/rbthomas# aptitude full-upgrade
> The following partially installed packages will be configured:
>   linux-image-5.10.0-7-powerpc linux-image-powerpc 
> No packages will be installed, upgraded, or removed.
> 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B of archives. After unpacking 0 B will be used.
> Setting up linux-image-5.10.0-7-powerpc (5.10.40-1) ...
> /etc/kernel/postinst.d/initramfs-tools:
> update-initramfs: Generating /boot/initrd.img-5.10.0-7-powerpc
> /etc/kernel/postinst.d/zz-update-grub:
> /usr/sbin/grub-mkconfig: 257: cannot create /boot/grub/grub.cfg.new: 
> Read-only file system

Your HFS filesystem on /boot/grub is read-only. This is not related to GRUB but
to either your custom environment or something in the partitioning setup in d-i
that I need to fix.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#986527: sagemath: FTBFS: how to address for Bullseye

[John Scott]

On Tue, 08 Jun 2021 17:15:44 +0200 Julien Puydt wrote:
> I've been convinced that getting a fragile sagemath in next stable
> wouldn't be a good thing.
You've put much more effort than I have into maintaining scientific
software in Debian, so I respect your opinion, but is it really
accurate to say that SageMath is fragile as a whole?

With respect to this particular issue, I'd like to share my perspective
wrangling with a package that poses a similar dilemma: GCC (I'm working
on packaging gcc-sh-elf). Like the status quo with SageMath in Debian,
GCC has a test suite where failures are normal, and in general it takes
an individual to watch out for what number of failures counts as "too
many." Rather than hardcode an arbitrary threshold for what number of
failing tests is acceptable, it seems that it's much better, and in the
interest of Debian ports and alternative build environments, to just
let the tests run for informative purposes.

This, I believe, is what the GCC team actually does; the test results
get sent to the team mailing list IIRC. Perhaps we should take a
similar philosophy towards the tests.

At least with GCC and DejaGnu, the test results get written out to a
file, so before a new upload, say, one can do a diff on the old and new
test results and see if any new regressions were introduced. In this
same respect, SageMath test results may be best consulted before new
uploads by hand.

I believe it's in the best interest of Debian users that this bug be
downgraded for Bullseye so Sage can be used in the mostly-wholesome
shape it's in, but since I lack expertise in maintaining it I too will
leave this to someone else.


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

Bug#988326: libboost-python-dev: Linking against boost_python requires the python version number ex: -lboost_python39

[Dimitri John Ledkov]

Hi,

On Mon, 10 May 2021 at 16:09, Grégory David  wrote:
>
> Package: libboost-python-dev
> Version: 1.74.0.3
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: d...@groolot.net
>
> Dear Maintainer,
>
>* What led up to the situation?
>  When I try to compile `mididings' and link against
>  `-lboost_python' the linker failed with undefined reference to
>  'libboost_python'.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  I try with a minimal `main.c' example and:
>* link against `-lboost_python', INEFFECTIVE
>* link against `-lboost_python39', EFFECTIVE
>* symlink `libboost_python.so' to `libboost_python39.so' and
>  link against `-lboost_python', EFFECTIVE
>

This is not a Debian choice, but an upstream one. Each boost_python
and which python it is built against are not interchangeable. And we
want them all to be coinstallable. All build systems have been updated
to query for a particular python version, or default one, and then use
appropriate pythonX.Y, link against libpythonX.Y (if needed), and link
against appropriate boost_pythonXY. It is incorrect to link against
-lboost_python which in the past used to mean the default python2 one.
Hence that ABI name is now burned forever.

boost now ships CMake files to make the detection and use of
boost_python slightly easier. but no, our default soname is
boost_python39, aka libboost_python39.so is the soname to link
against, which can be provided by multiple revisions of boost (ie.
libboost_python39.so.1 libboost_python39.so.1.76
libboost_python39.so.1.76.0 and so on for 1.77.0)

To find current/matching suffix by hand you can use $ py3versions -d
-v | sed 's/\.//'

This is a strong won't fix.

-- 
Regards,

Dimitri.

Bug#987441: Bug#926539: Bug#987441: s390x installation bugs

[John Paul Adrian Glaubitz]

Hi!

On 5/3/21 12:21 PM, Valentin Vidic wrote:
>>> I'd suggest at least retitling the bug report to mention s390x (release
>>> arch, affected) instead of sparc64 (port arch, no longer affected), to
>>> lower the chances people could overlook this issue, thinking it's only
>>> about a port arch.
>>
>> We could also unmerge #926539 and #961056 again, then close the former bug
>> which was sparc64-specific.
> 
> I have unmerged the bugs now, so the sparc one can be closed.

Alright, done.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#987441: Bug#926539: Bug#987441: s390x installation bugs

[John Paul Adrian Glaubitz]

Hi!

On 5/3/21 8:36 AM, Cyril Brulebois wrote:
> From skimming through the bug log, it seems it was initially a sparc64
> problem, that was fixed in the kernel (inconsistent naming) eventually.

Correct.

> The same issue exists on s390x but isn't apparently going to get fixed
> so we need to have d-i be smarter (hence the merge request)?

Seems so.

> I'd suggest at least retitling the bug report to mention s390x (release
> arch, affected) instead of sparc64 (port arch, no longer affected), to
> lower the chances people could overlook this issue, thinking it's only
> about a port arch.

We could also unmerge #926539 and #961056 again, then close the former bug
which was sparc64-specific.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

[John Scott]

Has anyone been able to reproduce this? Attempting to build Sage in a
fresh unstable environment succeeds for me; perhaps the build failure
was spurious.


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

Bug#983605: dicomscope: Files missing from distribution

[John Talbut]

Package: dicomscope
Version: 3.6.0-22
Severity: grave
Justification: renders package unusable

After attempting to install this package it does not work and various
files seem to be missing.  At
https://packages.debian.org/bullseye/all/dicomscope/filelist I get the
message "No such package in this suite on this architecture."

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

Kernel: Linux 5.10.13-20210224 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dicomscope depends on:
ii  default-jre2:1.11-72
ii  jarwrapper 0.78
ii  libdicomscope-jni  3.6.0-22+b1
ii  tk8.6  8.6.11-2

dicomscope recommends no packages.

dicomscope suggests no packages.

-- no debconf information