Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sebastian Ramacher]

On 2023-02-15 13:17:38 -0700, Sam Hartman wrote:
> > "Theodore" == Theodore Ts'o  writes:
>  the answer to your "how long" is that packages
> >> should also work with the kernel from the previous and the kernel
> >> from the next Debian release.
> 
> Theodore> This isn't a problem with the kernel.
> 
> I don't think that was Adrian's point.
> I think Adrian was making an analogy and suggesting that filesystems
> made by bookworm should be usable by bullseye and by the release after
> bookworm--usable by the bootloaders etc.
> Or at least that would be a reasonable thing to do based on stability
> guarantees we've made in other cases.
> 
> I.E. I think your question of "for how long" has a very simple answer
> based on our history: if we care about stability in this instance it's
> for +/-1 Debian release.
> 
> I'm struggling trying to figure out whether we should commit to that
> stability.
> I do find this change after the transition freeze to be kind of late.  I
> understand it's not a traditional transition.
> But for example you're not leaving a lot of time for asking programs
> like vmdb2 or fai-diskimage to adjust how they call fsck.
> If you made this change a few months ago, it would be reasonable to file
> bugs against those packages and ask them to adjust how they call
> mkfs.ext4.

To better understand the impact of this change, I was wondering which
tools / image builders in the archive would be affected by this change.
I've cloned the bug to vmdb2, but what about others?

Cheers

> 
> I want to stress that I'm not  affiliated with the release team; my
> opinion here has no official weight.
> But I would ask you to consider that it is kind of late to make  a
> change in the required filesystem features for bookworm and suggest a
> more orderly process would be to make the change in the next release and
> give packages that need to build vm images a chance to adjust.
> 
> I also think it would be reasonable for the project to decide we care
> about this stability, and that we want bullseye grub to work with a
> filesystem made on sid.
> I understand you do not support that stability decision.



-- 
Sebastian Ramacher

Bug#1031386: supertuxkart: Depends on newer version of glslang

[Rishi Cutchin]

Package: supertuxkart
Version: testing
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: rishincutc...@gmail.com

Dear Maintainer,


   * What led up to the situation?
Attempted to backport package to stable. Installed build-dependencies
with mk-build-deps --install --remove 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Attempted to build with fakeroot debian/rules binary.

   * What was the outcome of this action?
Recieved error relating to glslang::EShTargetSpv_1_6, and compilation
failed. Was able to continue compilation after backporting glslang and
it's dependencies

   * What outcome did you expect instead?
Build-dependency should require newer version so that mk-build-deps
errors to force new version.




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

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

Bug#1031387: supertuxkart: Fails to compile due to inescaped +, bug in shaderc

[Rishi Cutchin]

Package: supertuxkart
Version: testing
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: rishincutc...@gmail.com

Dear Maintainer,


   * What led up to the situation?
Attempting to backport supertuxkart, necessary to backport glslang
aswell.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Compiled with fakeroot debian/rules binary
 
   * What was the outcome of this action?
Failed to build due to 

cd 
/home/rishi/build/supertuxkart/supertuxkart-1.4+dfsg/obj-x86_64-linux-gnu/lib/shaderc/libshaderc
 && /usr/bin/ar -M < shaderc_combined.ar
+Syntax error in archive script, line 1

Appears to be an issue with cmake and shadercc not properly escaping '+'
character:
https://github.com/google/shaderc/issues/473

   
   * What outcome did you expect instead?
Successful (test) compile


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

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

Bug#1031388: icingaweb2-module-pdfexport: server software depending on chromium?

[Steve Langasek]

Package: icingaweb2-module-pdfexport
Version: 0.10.2+dfsg1-1
Severity: grave

The current version of icingaweb2-module-pdfexport depends on chromium.

icingaweb2 is a web service.  Depending on a graphical browser in a web
server component is not at all reasonable.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Processed (with 2 errors): Merge duplicates

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 1028714 python-mox3
Bug #1028714 [src:nsscache] nsscache: FTBFS: FileNotFoundError: [Errno 2] No 
such file or directory
Bug reassigned from package 'src:nsscache' to 'python-mox3'.
No longer marked as found in versions nsscache/0.42-2.
Ignoring request to alter fixed versions of bug #1028714 to the same values 
previously set
> forcemerge 1026671 1028714
Bug #1026671 [src:python-mox3] python-mox3: FTBFS: AttributeError: module 
'inspect' has no attribute 'getargspec'
Unable to merge bugs because:
package of #1028714 is 'python-mox3' not 'src:python-mox3'
Failed to forcibly merge 1026671: Did not alter merged bugs.

> affects 1026671 src:nsscache
Failed to mark 1026671 as affecting package(s): failed to get lock on 
/srv/bugs.debian.org/spool/lock/1026671 -- Unable to lock 
/srv/bugs.debian.org/spool/lock/1026671 Resource temporarily unavailable.
Unable to lock /srv/bugs.debian.org/spool/lock/1026671 Resource temporarily 
unavailable at /usr/local/lib/site_perl/Debbugs/Common.pm line 692.
Unable to lock /srv/bugs.debian.org/spool/lock/1026671 Resource temporarily 
unavailable at /usr/local/lib/site_perl/Debbugs/Common.pm line 692.
Unable to lock /srv/bugs.debian.org/spool/lock/1026671 Resource temporarily 
unavailable at /usr/local/lib/site_perl/Debbugs/Common.pm line 692.
Unable to lock /srv/bugs.debian.org/spool/lock/1026671 Resource temporarily 
unavailable at /usr/local/lib/site_perl/Debbugs/Common.pm line 692.
Unable to lock /srv/bugs.debian.org/spool/lock/1026671 Resource temporarily 
unavailable at /usr/local/lib/site_perl/Debbugs/Common.pm line 692.
Unable to lock /srv/bugs.debian.org/spool/lock/1026671 Resource temporarily 
unavailable at /usr/local/lib/site_perl/Debbugs/Common.pm line 692.
Unable to lock /srv/bugs.debian.org/spool/lock/1026671 Resource temporarily 
unavailable at /usr/local/lib/site_perl/Debbugs/Common.pm line 692.
Unable to lock /srv/bugs.debian.org/spool/lock/1026671 Resource temporarily 
unavailable at /usr/local/lib/site_perl/Debbugs/Common.pm line 692.
Unable to lock /srv/bugs.debian.org/spool/lock/1026671 Resource temporarily 
unavailable at /usr/local/lib/site_perl/Debbugs/Common.pm line 692.
 at /usr/local/lib/site_perl/Debbugs/Common.pm line 650.

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1026671: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026671
1028714: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028714
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: fixed 1031336 in 3.11.2-2

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> fixed 1031336 3.11.2-2
Bug #1031336 {Done: Matthias Klose } [python3-distutils] 
python3-distutils is not installable
Marked as fixed in versions python3-stdlib-extensions/3.11.2-2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1031336: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031336
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Merge duplicates

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 1028714 src:python-mox3
Bug #1028714 [python-mox3] nsscache: FTBFS: FileNotFoundError: [Errno 2] No 
such file or directory
Bug reassigned from package 'python-mox3' to 'src:python-mox3'.
Ignoring request to alter found versions of bug #1028714 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1028714 to the same values 
previously set
> forcemerge 1026671 1028714
Bug #1026671 [src:python-mox3] python-mox3: FTBFS: AttributeError: module 
'inspect' has no attribute 'getargspec'
Bug #1028714 [src:python-mox3] nsscache: FTBFS: FileNotFoundError: [Errno 2] No 
such file or directory
Marked as found in versions python-mox3/1.0.0-2.
Added tag(s) pending.
Merged 1026671 1028714
> affects 1026671 src:nsscache python-mox3
Bug #1026671 [src:python-mox3] python-mox3: FTBFS: AttributeError: module 
'inspect' has no attribute 'getargspec'
Bug #1028714 [src:python-mox3] nsscache: FTBFS: FileNotFoundError: [Errno 2] No 
such file or directory
Added indication that 1026671 affects src:nsscache and python-mox3
Added indication that 1028714 affects src:nsscache and python-mox3
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1026671: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026671
1028714: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028714
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: RC Bug #1030407: forward to upstream fix

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 1030407 https://github.com/HenriWahl/Nagstamon/issues/907
Bug #1030407 [src:nagstamon] nagstamon: FTBFS: 
pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: 
'3.10.1.debianunknown'
Set Bug forwarded-to-address to 
'https://github.com/HenriWahl/Nagstamon/issues/907'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1030407: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030407
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1031238: debci: fails for source packages in non-free-firmware

[Paul Gevers]

Control: tags -1 confirmed

On 13-02-2023 20:45, Andreas Beckmann wrote:

src:nvidia-graphics-drivers recently moved from non-free to
non-free-firmware since the firmware-nvidia-gsp binary package was moved
to that section, too.


Ack.


Tracker reports
  autopkgtest for nvidia-graphics-drivers/n/a: amd64: Regression ♻ (reference 
♻), ...
not sure whether the version "n/a" comes from tracker or debci.


n/a probably comes from autopkgtest (or indeed debci that interprets a 
missing version that way)



Autopkgtest regresses with
https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers/31312665/log.gz
...
autopkgtest [14:12:05]: testbed dpkg architecture: amd64
autopkgtest [14:12:05]: testbed running kernel: Linux 5.10.0-21-cloud-amd64 #1 
SMP Debian 5.10.162-1 (2023-01-21)
autopkgtest [14:12:06]:  apt-source nvidia-graphics-drivers
blame: nvidia-graphics-drivers
badpkg: rules extract failed with exit code 1
autopkgtest [14:12:06]: ERROR: erroneous package: rules extract failed with 
exit code 1

My guess is that it fails since it cannot find the source package
anywhere.


Indeed

autopkgtest [09:56:46]:  apt-source 
nvidia-graphics-drivers

autopkgtest: DBG: blame += nvidia-graphics-drivers
autopkgtest: DBG: testbed reset: modified=False, deps_installed=[], 
deps_new=[]

autopkgtest: DBG: install_deps: deps_new=[]
autopkgtest: DBG: testbed command ['sh', '-ec', 'command -v 
dpkg-source'], kind short, sout pipe, serr pipe, env []

autopkgtest: DBG: testbed command exited with code 0
autopkgtest: DBG: testbed command ['sh', '-ec', 'su --shell=/bin/sh 
debci -c \'set -e; exec 3>&1 >&2; set -x; cd /; builddir=$(mktemp -d 
/tmp/autopkgtest-lxc.julgi3d7/downtmp/build.XXX); cd $builddir; 
OUT=$(apt-get source -d -q --only-source 
nvidia-graphics-drivers/unstable 2>&1) || RC=$?;\nif [ -n "$RC" ]; 
then\n  if echo "$OUT" | grep -q "Unable to find a source package"; 
then\nexit 1;\n  else\nexit $RC;\n  fi;\nfi;\necho "$OUT" | grep 
^Get: || true;\ndpkg-source -x nvidia-graphics-drivers_*.dsc src 
>/dev/null; chmod -R a+rX .; cd [a-z0-9]*/.; pwd >&3; sed -n "1 
{s/).*//; s/ (/\\n/; p}" debian/changelog >&3\''], kind build, sout 
pipe, serr raw, env []

+ cd /
+ mktemp -d /tmp/autopkgtest-lxc.julgi3d7/downtmp/build.XXX
+ builddir=/tmp/autopkgtest-lxc.julgi3d7/downtmp/build.3aA
+ cd /tmp/autopkgtest-lxc.julgi3d7/downtmp/build.3aA
+ apt-get source -d -q --only-source nvidia-graphics-drivers/unstable
+ OUT=Reading package lists...
E: Unable to find a source package for nvidia-graphics-drivers
+ RC=100
+ [ -n 100 ]
+ echo Reading package lists...
E: Unable to find a source package for nvidia-graphics-drivers
+ grep -q Unable to find a source package
+ exit 1
autopkgtest: DBG: testbed command exited with code 1

Adding non-free-firmware to /etc/apt/sources.list fixes that problem. In 
debci, it's bin/debci-generate-apt-sources that on line 133 sets the 
components, but it does so for all suites. This means we'll get


W: Skipping acquire of configured file 
'non-free-firmware/source/Sources' as repository 
'http://deb.debian.org/debian stable InRelease' doesn't have the 
component 'non-free-firmware' (component misspelt in sources.list?)
W: Skipping acquire of configured file 
'non-free-firmware/binary-amd64/Packages' as repository 
'http://deb.debian.org/debian stable InRelease' doesn't have the 
component 'non-free-firmware' (component misspelt in sources.list?)


in our logs on stable (bullseye) if we add it without further logic. 
Just above there's already code that uses the suite, so probably we can 
borrow a bit of that.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Processed: Re: Bug#1031238: debci: fails for source packages in non-free-firmware

[Debian Bug Tracking System]

Processing control commands:

> tags -1 confirmed
Bug #1031238 [debci] debci: fails for source packages in non-free-firmware
Added tag(s) confirmed.

-- 
1031238: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031238
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1027013: marked as done (llvm-toolchain-14 autopkg test fails)

[Debian Bug Tracking System]

Your message dated Thu, 16 Feb 2023 10:17:05 +
with message-id 
and subject line Bug#1027013: fixed in llvm-toolchain-14 1:14.0.6-11
has caused the Debian Bug report #1027013,
regarding llvm-toolchain-14 autopkg test fails
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1027013: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027013
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: src:llvm-toolchain-14
Version: 1:14.0.6-9
Severity: serious
Tags: sid bookworm

no idea what this test is supposed to test ...

however the source reads:

// Test the link against libclang-cppXX
//
// REQUIRES: clang, llvm-config
// RUN: %clangxx -lclang-cpp -v %s -o %t `%llvm-config --cxxflags --ldflags 
--libs`
// RUN: ldd %t 2>&1|grep -q libclang-cpp

with --as-needed as the default in the linker this is doomed to fail, having the 
library on the command line before the object file.


unsure if that is the root cause, as it only fails on amd64 and arm64.

https://ci.debian.net/data/autopkgtest/testing/amd64/l/llvm-toolchain-14/29644065/log.gz


[...]
FAIL: LLVM regression suite :: libclang_cpp.cpp (25 of 45)
 TEST 'LLVM regression suite :: libclang_cpp.cpp' FAILED 


Script:
--
: 'RUN: at line 4';   /usr/bin/clang++-14 -lclang-cpp -v 
/tmp/autopkgtest-lxc._y_hntgm/downtmp/autopkgtest_tmp/tests/libclang_cpp.cpp -o 
/tmp/autopkgtest-lxc._y_hntgm/downtmp/autopkgtest_tmp/build/tests/Output/libclang_cpp.cpp.tmp 
`/usr/bin/llvm-config-14 --cxxflags --ldflags --libs`
: 'RUN: at line 5';   ldd 
/tmp/autopkgtest-lxc._y_hntgm/downtmp/autopkgtest_tmp/build/tests/Output/libclang_cpp.cpp.tmp 
2>&1|grep -q libclang-cpp

--
Exit Code: 1

Command Output (stderr):
--
Debian clang version 14.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
 "/usr/lib/llvm-14/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj 
-mrelax-all --mrelax-relocations -disable-free -clear-ast-before-backend 
-disable-llvm-verifier -discard-value-names -main-file-name libclang_cpp.cpp 
-mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno 
-ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 
-target-cpu x86-64 -tune-cpu generic -mllvm 
-treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -v 
-fcoverage-compilation-dir=/tmp/autopkgtest-lxc._y_hntgm/downtmp/autopkgtest_tmp/build/tests 
-resource-dir /usr/lib/llvm-14/lib/clang/14.0.6 -I /usr/lib/llvm-14/include -D 
_GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D 
__STDC_LIMIT_MACROS -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12 
-internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/x86_64-linux-gnu/c++/12 
-internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/backward 
-internal-isystem /usr/lib/llvm-14/lib/clang/14.0.6/include -internal-isystem 
/usr/local/include -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../x86_64-linux-gnu/include 
-internal-externc-isystem /usr/include/x86_64-linux-gnu 
-internal-externc-isystem /include -internal-externc-isystem /usr/include 
-std=c++14 -fdeprecated-macro 
-fdebug-compilation-dir=/tmp/autopkgtest-lxc._y_hntgm/downtmp/autopkgtest_tmp/build/tests 
-ferror-limit 19 -fgnuc-version=4.2.1 -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o 
/tmp/lit-tmp-f4zxudnz/libclang_cpp-b074e4.o -x c++ 
/tmp/autopkgtest-lxc._y_hntgm/downtmp/autopkgtest_tmp/tests/libclang_cpp.cpp

clang -cc1 version 14.0.6 based upon LLVM 14.0.6 default target 
x86_64-pc-linux-gnu
ignoring nonexistent directory 
"/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../x86_64-linux-gnu/include"

ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/llvm-14/include
 /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12

/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/x86_64-linux-gnu/c++/12
 /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/backward
 /usr/lib/llvm-14/lib/clang/14.0.6/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
 "/usr/bin/ld" -pie --hash-style=both --build-id --eh-frame-hdr -m elf_x86_64 
-dynamic-linker

Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)

[Paul Gevers]

Hi Helge,

On Thu, 12 Jan 2023 07:36:33 +0100 Helge Kreutzmann 
 wrote:

I expect upstream to release "this weekend" - but this might be
actually next monday/tuesday.

Then I might take a day or two to package this for unstable.


I think this happened in version 4.17.0-1 and 2. The latter migrated to 
testing on 25 January, right? Can we close this bug?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026713: marked as done (apache-directory-server: FTBFS due to compatibility issue with mina 2.2)

[Debian Bug Tracking System]

Your message dated Thu, 16 Feb 2023 10:49:51 +
with message-id 
and subject line Bug#1026713: fixed in apache-directory-server 2.0.0~M26-1
has caused the Debian Bug report #1026713,
regarding apache-directory-server: FTBFS due to compatibility issue with mina 
2.2
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1026713: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026713
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: apache-directory-server
Version: 2.0.0~M24-4.1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20221220 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
>  debian/rules build
> dh build
>dh_update_autotools_config
>dh_autoreconf
>dh_auto_configure
>   mh_patchpoms -plibapacheds-java --debian-build --keep-pom-version 
> --maven-repo=/<>/apache-directory-server-2.0.0\~M24/debian/maven-repo
>dh_auto_build
>   /usr/lib/jvm/default-java/bin/java -noverify -cp 
> /usr/share/maven/boot/plexus-classworlds-2.x.jar 
> -Dmaven.home=/usr/share/maven 
> -Dmaven.multiModuleProjectDirectory=/<>/apache-directory-server-2.0.0\~M24
>  -Dclassworlds.conf=/etc/maven/m2-debian.conf 
> -Dproperties.file.manual=/<>/apache-directory-server-2.0.0\~M24/debian/maven.properties
>  org.codehaus.plexus.classworlds.launcher.Launcher 
> -s/etc/maven/settings-debian.xml 
> -Ddebian.dir=/<>/apache-directory-server-2.0.0\~M24/debian 
> -Dmaven.repo.local=/<>/apache-directory-server-2.0.0\~M24/debian/maven-repo
>  --batch-mode package -DskipTests -Dnotimestamp=true -Dlocale=en_US
> OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were 
> deprecated in JDK 13 and will likely be removed in a future release.
> [INFO] Scanning for projects...
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.directory.server:apacheds-all:jar:2.0.0-M24
> [WARNING] 
> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>  must be unique: org.apache.directory.api:api-all:jar -> duplicate 
> declaration of version debian @ 
> org.apache.directory.server:apacheds-parent:2.0.0-M24, 
> /<>/pom.xml, line 497, column 16
> [WARNING] 
> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>  must be unique: org.apache.directory.api:api-all:jar -> duplicate 
> declaration of version debian @ 
> org.apache.directory.server:apacheds-parent:2.0.0-M24, 
> /<>/pom.xml, line 502, column 16
> [WARNING] 
> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>  must be unique: org.apache.directory.api:api-all:jar -> duplicate 
> declaration of version debian @ 
> org.apache.directory.server:apacheds-parent:2.0.0-M24, 
> /<>/pom.xml, line 507, column 16
> [WARNING] 
> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>  must be unique: org.apache.directory.api:api-all:jar -> duplicate 
> declaration of version debian @ 
> org.apache.directory.server:apacheds-parent:2.0.0-M24, 
> /<>/pom.xml, line 512, column 16
> [WARNING] 
> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>  must be unique: org.apache.directory.api:api-all:jar -> duplicate 
> declaration of version debian @ 
> org.apache.directory.server:apacheds-parent:2.0.0-M24, 
> /<>/pom.xml, line 517, column 16
> [WARNING] 
> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>  must be unique: org.apache.directory.api:api-all:jar -> duplicate 
> declaration of version debian @ 
> org.apache.directory.server:apacheds-parent:2.0.0-M24, 
> /<>/pom.xml, line 522, column 16
> [WARNING] 
> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>  must be unique: org.apache.directory.api:api-all:jar -> duplicate 
> declaration of version debian @ 
> org.apache.directory.server:apacheds-parent:2.0.0-M24, 
> /<>/pom.xml, line 527, column 16
> [WARNING] 
> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>  must be unique: org.apache.directory.api:api-all:jar -> duplicate 
> declaration of version debian @ 
> org.apache.directory.server:apacheds-parent:2.0.0-M24, 
> /<>/pom.xml, line 532, column 16
> [WARNING] 
> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>  must be unique: org.apache.directory.api:api-all:jar -> duplicate 
> declaration of ver

Bug#1030601: marked as done (findent: autopkgtest regression: original program does not compile)

[Debian Bug Tracking System]

Your message dated Thu, 16 Feb 2023 12:12:55 +0100
with message-id <55ab1bc2-7bc8-0b64-c9e3-89fd05474...@gmail.com>
and subject line closing bug
has caused the Debian Bug report #1030601,
regarding findent: autopkgtest regression: original program does not compile
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1030601: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030601
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Source: findent
Version: 4.2.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of findent the autopkgtest of findent fails in 
testing when that autopkgtest is run with the binary packages of findent 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
findentfrom testing4.2.5-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=findent

https://ci.debian.net/data/autopkgtest/testing/amd64/f/findent/31040771/log.gz

../test-compile.sh: ../progfixed-dos.f
will try to compile fortran sources using gfortran
findent version 4.2.5
progfixed-dos.f:  original program does not compile using: 
-fcoarray=single -cpp -fopenmp -ffixed-form -ffixed-line-length-none 
-fd-lines-as-comments -o prog ../progfixed-dos.f OK
converted program does not compile using: -fcoarray=single -cpp 
-fopenmp -ffixed-form -ffixed-line-length-none -fd-lines-as-comments -o 
prog progfixed-dos.f.try.f END TESTING FINDENT rc=1
If you are sure 
/tmp/autopkgtest-lxc.uypbn9fi/downtmp/build.fHY/src/debian/tests/test1.sh.tmpdir/progfixed-dos.f.try.f 
is correct:
copy 
/tmp/autopkgtest-lxc.uypbn9fi/downtmp/build.fHY/src/debian/tests/test1.sh.tmpdir/progfixed-dos.f.try.f

to the corresponding .in file in the test directory
 and configure again.
autopkgtest [14:13:32]: test test1.sh



OpenPGP_signature
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---

Package: findent
Version: 4.2.6-1

fixed autopkgtest error in version 4.2.5-1--- End Message ---

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Michael Prokop]

* Sebastian Ramacher [Thu Feb 16, 2023 at 09:09:08AM +0100]:
> On 2023-02-15 13:17:38 -0700, Sam Hartman wrote:

> > But for example you're not leaving a lot of time for asking programs
> > like vmdb2 or fai-diskimage to adjust how they call fsck.
> > If you made this change a few months ago, it would be reasonable to file
> > bugs against those packages and ask them to adjust how they call
> > mkfs.ext4.

> To better understand the impact of this change, I was wondering which
> tools / image builders in the archive would be affected by this change.
> I've cloned the bug to vmdb2, but what about others?

I didn't verify it yet, but AFAICT grml-debootstrap is affected as
well, since it supports installing older Debian releases from within
more recent Debian/Grml environments and uses mkfs.ext4 as default.

BTW, we had a similar situation already in the past when mkfs.ext4
of e2fsprogs >=1.43~WIP.2015.05.18-1 enabled the "metadata_csum"
feature, while this was unsupported on jessie and older releases.
(grml-debootstrap provides a workaround for this.)

regards
-mika-


signature.asc
Description: PGP signature

Bug#1031388: icingaweb2-module-pdfexport: server software depending on chromium?

[David Kunz]

> The current version of icingaweb2-module-pdfexport depends on chromium.
All versions are like thes.

> icingaweb2 is a web service.  Depending on a graphical browser in a web
> server component is not at all reasonable.
I know, but upstream considers this to be the best possible way to solve
this problem.

Now we can provide this package as it is or no package exist and all
packages that depends to it are unusable.

Greetings
David

Bug#1029261: dm-writeboost-dkms: new version available

[mtths]

Package: dm-writeboost-dkms
Version: 2.2.15-1
Followup-For: Bug #1029261

Dear Maintainer,

there is a new version - 2.2.16 - available:
https://github.com/akiradeveloper/dm-writeboost/archive/refs/tags/v2.2.16.tar.gz

Regards,
Matthias

NB: Apparently at present the watch line of uscan doesn't match the upstream 
source.

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

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

Versions of packages dm-writeboost-dkms depends on:
ii  dkms  3.0.10-6

Versions of packages dm-writeboost-dkms recommends:
ii  dmsetup 2:1.02.185-2
ii  kmod30+20221128-1
ii  writeboost  1.20170616-1.2

dm-writeboost-dkms suggests no packages.

-- no debconf information

Bug#1031386: supertuxkart: Depends on newer version of glslang

[Stephen Kitt]

Control: severity wishlist

Hi Rishi,

On Thu, 16 Feb 2023 00:25:54 -0800, Rishi Cutchin 
wrote:
>* What led up to the situation?
> Attempted to backport package to stable. Installed build-dependencies
> with mk-build-deps --install --remove 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Attempted to build with fakeroot debian/rules binary.
> 
>* What was the outcome of this action?
> Recieved error relating to glslang::EShTargetSpv_1_6, and compilation
> failed. Was able to continue compilation after backporting glslang and
> it's dependencies
> 
>* What outcome did you expect instead?
> Build-dependency should require newer version so that mk-build-deps
> errors to force new version.

Package dependencies are supposed to make sense within a given release.
supertuxkart builds fine in unstable, so this isn’t a serious issue. When you
backport, it’s part of the backporting work to determine when the stable
dependencies aren’t sufficient, as you did; but insufficient dependencies for
a backport to stable don’t constitute a bug.

It *is* useful to have versioned dependencies where appropriate, so I’m
leaving this open, but as a wishlist bug.

Regards,

Stephen


pgpiVTQxbKULW.pgp
Description: OpenPGP digital signature

Bug#1031387: supertuxkart: Fails to compile due to inescaped +, bug in shaderc

[Stephen Kitt]

Control: severity normal

Hi Rishi,

On Thu, 16 Feb 2023 00:29:33 -0800, Rishi Cutchin 
wrote:
>* What led up to the situation?
> Attempting to backport supertuxkart, necessary to backport glslang
> aswell.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Compiled with fakeroot debian/rules binary
>  
>* What was the outcome of this action?
> Failed to build due to 
> 
> cd
> /home/rishi/build/supertuxkart/supertuxkart-1.4+dfsg/obj-x86_64-linux-gnu/lib/shaderc/libshaderc
> && /usr/bin/ar -M < shaderc_combined.ar +Syntax error in archive script,
> line 1
> 
> Appears to be an issue with cmake and shadercc not properly escaping '+'
> character:
> https://github.com/google/shaderc/issues/473
> 
>
>* What outcome did you expect instead?
> Successful (test) compile

The package builds correctly in unstable, including from a directory
containing a +.

This *might* mean that other packages need to be backported too, I haven’t
checked.

Regards,

Stephen


pgpDYg4JyVrwP.pgp
Description: OpenPGP digital signature

Processed: severity of 1031387 is normal, severity of 1031386 is wishlist

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 1031387 normal
Bug #1031387 [supertuxkart] supertuxkart: Fails to compile due to inescaped +, 
bug in shaderc
Severity set to 'normal' from 'serious'
> severity 1031386 wishlist
Bug #1031386 [supertuxkart] supertuxkart: Depends on newer version of glslang
Severity set to 'wishlist' from 'serious'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1031386: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031386
1031387: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031387
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1031394: Please re-enable RTTI support in Sid/Bookworm, needed by at least Ceph

[Thomas Goirand]

Package: libsnappy1v5
Version: 1.1.8-1
Severity: grave
Tags: patch

Dear Laszlo,

During my tests with Ceph, I noticed a grave regression: Ceph OSD (the process
that does the actual storage for Ceph) cannot use Snappy anymore, because it
can't find one symbole related to RTTI.

The consequence is that it cannot load and use Snappy. This may be ok for newer
clusters, but when upgrading from a cluster let's say in Bullseye, this may be
desastrous: data wont be able to be unpacked, which means data loss.

Please find attached a very small patch to re-enable RTTI support in Ceph.

Note related upstream bug in Ceph:
https://tracker.ceph.com/issues/53060

Moving forward, what I propose is probably the easiest way forward, at least
for Ceph. Doing extra patching of the Ceph would be a way more hazardous.

Your thoughts?

Cheers,

Thomas Goirand (zigo)
diff -Nru snappy-1.1.9/debian/changelog snappy-1.1.9/debian/changelog
--- snappy-1.1.9/debian/changelog   2022-05-08 18:26:22.0 +
+++ snappy-1.1.9/debian/changelog   2023-02-16 12:37:39.0 +
@@ -1,3 +1,10 @@
+snappy (1.1.9-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Re-enable RTTI support.
+
+ -- Thomas Goirand   Thu, 16 Feb 2023 12:37:39 +
+
 snappy (1.1.9-2) unstable; urgency=medium
 
   * Upload to Sid.
diff -Nru snappy-1.1.9/debian/patches/re-enable-rtti-support.patch 
snappy-1.1.9/debian/patches/re-enable-rtti-support.patch
--- snappy-1.1.9/debian/patches/re-enable-rtti-support.patch1970-01-01 
00:00:00.0 +
+++ snappy-1.1.9/debian/patches/re-enable-rtti-support.patch2023-02-16 
12:37:39.0 +
@@ -0,0 +1,29 @@
+Description: Re-enable RTTI support
+Author: Thomas Goirand 
+Forwarded: no
+Last-Update: 2023-02-16
+
+--- snappy-1.1.9.orig/CMakeLists.txt
 snappy-1.1.9/CMakeLists.txt
+@@ -51,10 +51,6 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC"
+   string(REGEX REPLACE "/EH[a-z]+" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /EHs-c-")
+   add_definitions(-D_HAS_EXCEPTIONS=0)
+-
+-  # Disable RTTI.
+-  string(REGEX REPLACE "/GR" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /GR-")
+ else(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
+   # Use -Wall for clang and gcc.
+   if(NOT CMAKE_CXX_FLAGS MATCHES "-Wall")
+@@ -76,10 +72,6 @@ else(CMAKE_CXX_COMPILER_ID STREQUAL "MSV
+   # Disable C++ exceptions.
+   string(REGEX REPLACE "-fexceptions" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-exceptions")
+-
+-  # Disable RTTI.
+-  string(REGEX REPLACE "-frtti" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-rtti")
+ endif(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
+ 
+ # BUILD_SHARED_LIBS is a standard CMake variable, but we declare it here to 
make
diff -Nru snappy-1.1.9/debian/patches/series snappy-1.1.9/debian/patches/series
--- snappy-1.1.9/debian/patches/series  2021-12-04 18:21:57.0 +
+++ snappy-1.1.9/debian/patches/series  2023-02-16 12:37:39.0 +
@@ -4,3 +4,4 @@
 0001-Add-inline-with-SNAPPY_ATTRIBUTE_ALWAYS_INLINE.patch
 use_packaged_testing.patch
 correct_testing_link.patch
+re-enable-rtti-support.patch

Bug#1031395: tzdata 2022g-3 removes /etc/timezone while other packages depend on it, breaking these packages

[Daniel Leidert]

Package: tzdata
Version: 2022g-3
Severity: critical

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

in version 2022g-3, the /etc/timezone file has been removed and gets purged
from user's computers. This makes unrelated software break that relies on this
file. Examples are samizdat and ruby-et-orbi. But codesearch.d.o shows more
code-snippets that rely on the existence of that file. There hasn't been any
announcement, any transition, nor any mass-bug filing, leaving multiple
packages broken at this stage. I reported that issue to the release team as
#1031376 and have been asked to open a bug report against tzdata.

Regards, Daniel

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

Kernel: Linux 6.1.0-4-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 tzdata depends on:
ii  debconf [debconf-2.0]  1.5.82

tzdata recommends no packages.

tzdata suggests no packages.

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmPuJ/gACgkQS80FZ8KW
0F2CPQ/+M+A8ok4famSAdTA6Tpjw+ydaYGO2E4+NoQy/diq8KKhFMiOOdduiQji4
6J8no1J7K00eEPgqBko3lQXDJByDuRKHWXD3NFmQJme/pL9Wf4yc7+Zx4QhaBI96
UuUV4M8khv89bA9Bb6TWGUD0OkEOgpze7HAZAQqc8gnaGA2yRkh3JC9DmHe9boQJ
ywODuoFmlPIgyv+Jx8KlXgGdZWWoJpQtm8ol21WeYRtAWxPL+b/FbC1rTrSSEgka
wmw+pa4VbKC8sQIyGQPbJJk0q3PTIqKu1ia59KGKSrCox4cfAvV3EccgyH1xYliI
BRrlSEG1mau1O8jz4fq7oqMVs6W/KMRuj+pSI4n5DEFU9tEJ2G3trysusnS531tj
L++pD/aWISx76rpVzizVQjw1J63pr9sK8sh9/s/jz4s3Ddwiij/HVMaA6t7X+2DU
I3O8jgUq4N6taWw7NcBLDSyFRESqc0BcZYwfsvD7DD0UHSUeZmE5PnetHVWLwqeg
O/ljWDNuIiB61DfVWJr5nfhKXOZYFWXJEOOwDQ5zxWviHlahEGsu3wOQLGW7OA9E
bKUO2IpAOMHX0Oxx752t9eParFqs2yfAX338PGC73w7dCIB5bVowD9SHRCJi6FRX
8HhD5hgq8SsuJEej0eBS63QqN3uqxZKbZsoQgA5aS3eMffxEPRM=
=i0wy
-END PGP SIGNATURE-

Processed: Re: Bug#1031396: Unable to upgrade to *gnome* 1:43+1 with `apt full-upgrade`

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 1031396 serious
Bug #1031396 [gnome] Unable to upgrade to *gnome* 1:43+1 with `apt full-upgrade`
Severity set to 'serious' from 'normal'
> affects 1031396 src:pipewire
Bug #1031396 [gnome] Unable to upgrade to *gnome* 1:43+1 with `apt full-upgrade`
Added indication that 1031396 affects src:pipewire
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
1031396: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031396
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1030407: marked as done (nagstamon: FTBFS: pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: '3.10.1.debianunknown')

[Debian Bug Tracking System]

Your message dated Thu, 16 Feb 2023 13:19:17 +
with message-id 
and subject line Bug#1030407: fixed in nagstamon 3.10.1+ds1-4
has caused the Debian Bug report #1030407,
regarding nagstamon: FTBFS: 
pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: 
'3.10.1.debianunknown'
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1030407: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030407
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: nagstamon
Version: 3.10.1+ds1-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230203 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
>  fakeroot debian/rules binary
> dh binary --buildsystem=pybuild
>dh_testroot -O--buildsystem=pybuild
>dh_prep -O--buildsystem=pybuild
>dh_auto_install --destdir=debian/nagstamon/ -O--buildsystem=pybuild
> I: pybuild base:240: /usr/bin/python3 setup.py install --root 
> /<>/debian/nagstamon --install-scripts=/usr/share/nagstamon
> /usr/lib/python3/dist-packages/setuptools/dist.py:548: UserWarning: The 
> version specified ('3.10.1.debianunknown') is an invalid version, this may 
> not work as expected with newer versions of setuptools, pip, and PyPI. Please 
> see PEP 440 for more details.
>   warnings.warn(
> Currently Nagstamon supports only 1 config directory.
> running install
> /usr/lib/python3/dist-packages/setuptools/command/install.py:34: 
> SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and 
> pip and other standards-based tools.
>   warnings.warn(
> running build
> running build_py
> running build_scripts
> running install_lib
> creating /<>/debian/nagstamon/usr
> creating /<>/debian/nagstamon/usr/lib
> creating /<>/debian/nagstamon/usr/lib/python3.11
> creating /<>/debian/nagstamon/usr/lib/python3.11/dist-packages
> creating 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon
> copying /<>/.pybuild/cpython3_3.11/build/Nagstamon/__init__.py 
> -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon
> creating 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/qt.conf -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/nagstamon.1 
> -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/LICENSE -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/nagstamon_systrayicon_empty.svg
>  -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/nagstamon.desktop
>  -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/nagstamon.icns
>  -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/nagstamon_logo_toparea_template.svg
>  -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/nagstamon_systrayicon_template.svg
>  -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/down.wav -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources
> creating 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources/qui
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/qui/dialog_server_missing.ui
>  -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources/qui
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/qui/settings_action.ui
>  -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources/qui
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/qui/dialog_acknowledge.ui
>  -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources/qui
> copying 
> /<>/.pybuild/cpython3_3.11/build/Nagstamon/resources/qui/dialog_downtime.ui
>  -> 
> /<>/debian/nagstamon/usr/lib/python3.11/dist-packages/Nagstamon/resources/qui
> copying 
> /<>/.pybuild/cpytho

Bug#1031295: pcp fails to install without systemd

[Andras Korn]

Hi,

it seems to me that in postinst, instead of

if $do_systemd
then
systemctl start pmcd.service >/dev/null
systemctl start pmlogger.service >/dev/null
elif which invoke-rc.d >/dev/null 2>&1
then
invoke-rc.d pmcd start
invoke-rc.d pmlogger start
else
/etc/init.d/pmcd start
/etc/init.d/pmlogger start
fi

You could just do

service pmcd start
service pmlogger start

Additionally, I think a case can be made for ignoring failures to start these 
services in postinst. If the package fails to configure, that'll break 
unattended-upgrades which will then also not install security updates.

András

-- 
   A hangover: the wrath of grapes.

Bug#1031399: rsyslog: Log rotation broken on non-systemd systems

[Matthew Vernon]

Package: rsyslog
Version: 8.2212.0-1
Severity: serious

Hi,

When removing the systemv init scripts from rsyslog (which can be 
managed by orphan-sysvinit-scripts), the following was also removed from 
/usr/lib/rsyslog/rsyslog-rotate:

else
invoke-rc.d rsyslog rotate > /dev/null

This means on non-systemd systems logrotate tries but fails to tell 
rsyslog to rotate its logs.

Could you restore this, please? It will have no impact on systemd 
systems (since the else clause will never match there), and otherwise 
log rotation with rsyslog cannot work properly on non-systemd systems, 
which is quite a serious isssue. And I can't do anything about this in 
orphan-sysvinit-scripts.

Thanks,

Matthew

-- 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)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages rsyslog depends on:
ii  libc6  2.36-8
ii  libelogind0 [libsystemd0]  246.10-1debian1
ii  libestr0   0.1.11-1
ii  libfastjson4   0.99.9-2
ii  liblognorm52.0.6-4
ii  libuuid1   2.38.1-4
ii  libzstd1   1.5.2+dfsg2-3
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages rsyslog recommends:
ii  logrotate  3.21.0-1

Versions of packages rsyslog suggests:
pn  rsyslog-doc   
pn  rsyslog-gssapi
pn  rsyslog-mongodb   
pn  rsyslog-mysql | rsyslog-pgsql 
pn  rsyslog-openssl | rsyslog-gnutls  
pn  rsyslog-relp  

-- Configuration Files:
/etc/rsyslog.conf changed [not included]

-- no debconf information

Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)

[Helge Kreutzmann]

Hello Paul,
On Thu, Feb 16, 2023 at 11:20:18AM +0100, Paul Gevers wrote:
> On Thu, 12 Jan 2023 07:36:33 +0100 Helge Kreutzmann 
> wrote:
> > I expect upstream to release "this weekend" - but this might be
> > actually next monday/tuesday.
> > 
> > Then I might take a day or two to package this for unstable.
> 
> I think this happened in version 4.17.0-1 and 2. The latter migrated to
> testing on 25 January, right? Can we close this bug?

From my side (i.e., manpages-l10n) everything has happend (this was
tracked in a cloned bug), especially in backports. 

There is one small issue left, so I probably will issue another
backport upload this weekend, but otherwise - this is (hopefully)
completely resolved.


Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

> "Sebastian" == Sebastian Ramacher  writes:

Sebastian> To better understand the impact of this change, I was
Sebastian> wondering which tools / image builders in the archive
Sebastian> would be affected by this change.  I've cloned the bug to
Sebastian> vmdb2, but what about others?

It will affect fai-diskimage in the fai package..
I believe that's used by the cloud team (or was) to create cloud images;
I don't know if their use case is affected, because I don't know what OS
they use to create what images.

Bug#1026204: upstream tar bug report

[Efraim Flashner]

I came across this bug from Wookey linking to it from the debian-arm
mailing list. I also ran into this bug in Guix and I managed to track
down an upstream bug report about it¹. Short version is that upstream
now knows about it, and tar-1.35 will default to enabling 64-bit time_t.


¹ https://lists.gnu.org/archive/html/bug-tar/2021-10/msg6.html


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)

[Paul Gevers]

Hi Helge,

On 16-02-2023 15:54, Helge Kreutzmann wrote:

There is one small issue left, so I probably will issue another
backport upload this weekend, but otherwise - this is (hopefully)
completely resolved.


This bug is currently marked RC and hence it showed up on my radar. If 
you fix RC issues, we'd appreciate the closure of the bug. This bug is 
the bug against manpages-fr. If you want to use this bug for your 
remaining minor issue, a reduction of severity might be more appropriate.


Thanks for understanding.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028233: marked as done (xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1))

[Debian Bug Tracking System]

Your message dated Thu, 16 Feb 2023 16:21:59 +0100
with message-id <20230216152159.GA24101@Debian-50-lenny-64-minimal>
and subject line Re: Bug#1028233: xz-utils: tries to overwrite files in 
manpages-fr (4.16.0-3~bpo11+1)
has caused the Debian Bug report #1028233,
regarding xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1028233: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028233
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: xz-utils
Version: 5.4.0-0.1

Dear developer,

I'm not sure if it's the right place to report the bug since it involves 
a conflict with a backport.


Today I tried to upgrade a Bullseye laptop to Bookworm.

The upgrade crashed with xz-utils trying to overwrite 
/usr/share/man/fr/man1/xz.1.gz which belonged to manpages-fr from 
backports (4.16.0-3~bpo11+1).


After running dpkg --force-overwrite (it's the only way I know of in 
such situations), a whole bunch of manual pages were overwritten :


/usr/share/man/fr/man1/xz.1.gz
/usr/share/man/fr/man1/xzdiff.1.gz
/usr/share/man/fr/man1/xzless.1.gz
/usr/share/man/fr/man1/xzmore.1.gz
/usr/share/man/fr/man1/lzcat.1.gz
/usr/share/man/fr/man1/lzcmp.1.gz
/usr/share/man/fr/man1/lzdiff.1.gz
/usr/share/man/fr/man1/lzless.1.gz
/usr/share/man/fr/man1/lzma.1.gz
/usr/share/man/fr/man1/lzmore.1.gz
/usr/share/man/fr/man1/unlzma.1.gz
/usr/share/man/fr/man1/unxz.1.gz
/usr/share/man/fr/man1/xzcat.1.gz
/usr/share/man/fr/man1/xzcmp.1.gz

I don't see a clean solution to ensure a smooth upgrade for people who 
have installed this backport. Maybe coordinate with manpages-fr 
maintainer and release updated backports for both packages, before 
Bookworm is released ?


Regards,

--
Raphaël Halimi
--- End Message ---
--- Begin Message ---
Hello Paul,
On Thu, Feb 16, 2023 at 04:05:42PM +0100, Paul Gevers wrote:
> On 16-02-2023 15:54, Helge Kreutzmann wrote:
> > There is one small issue left, so I probably will issue another
> > backport upload this weekend, but otherwise - this is (hopefully)
> > completely resolved.
> 
> This bug is currently marked RC and hence it showed up on my radar. If you
> fix RC issues, we'd appreciate the closure of the bug. This bug is the bug
> against manpages-fr. If you want to use this bug for your remaining minor
> issue, a reduction of severity might be more appropriate.
> 
> Thanks for understanding.

No need to get mad.

First of all, I apologize that I did not notice that it was on
manpages-l10n at the moment, because the title was still referencing
xz-utils and the discussion was quite involved. 

And indeed, this bugs is closed in 4.17.0-2~bpo11+1, as you can see in
its changelog. Since uploads to backports don't close bugs (a bug
elsewhere …) I do so now.

Greetings

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature
--- End Message ---

Bug#1028471: cmucl: diff for NMU version 21d-2.1

[Peter Van Eynde]

Hi Adrian,

Thanks for that. I was reading up on this 'source only' uploads. In general I 
agree with the idea, however for cmucl when a new major version gets released 
the rebuilding of the new version using the old version is non-trivial and not 
automated.

So for major releases I do the rebuilding manually and then upload 
binaries+source. The binaries can rebuild the sources, but the old binaries 
cannot.

Is this setup still supported with the new rules or is this the last hurrah 
from the cmucl package?

Best regards, Peter

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Theodore Ts'o]

On Wed, Feb 15, 2023 at 07:39:28PM -0800, Russ Allbery wrote:
> It had never occurred to me before that the version of the system on which
> I run mke2fs would matter as long as I didn't pick a newer file system
> type (ext5 or something).  Now I know!  Until today, I had no idea ext4
> even *had* "incompat" features or that mke2fs could make file systems that
> grub couldn't understand.

While ext2 pioneered the whole concept of "compat", "rocompat" and
"incompat" features, these days pretty much all modern Linux file
systems have this.  As I mentioned earlier, xfs is enabling their
incompat "bigtime" feature for the first time in Bookworm.

File sysems have been evolving pretty much continuously since ext2 was
first released 30 years ago.  Poeple may have gotten lucky that grub
only (mostly) cares about incompat and rocompat features, but things
like adding extended attributes, 64-bit block number support,
post-2038 timestamps, etc., all require changes to the on-disk format.
And may of these updates did not happen at a extN to extN+1 boundary.

As far as the kernel is concerned, ext2/ext3/ext4 is really more about
allowing multiple implementations co-existing.  These days, "ext3"
file systems are handled by the code in fs/ext4/*.c, and the only
reason why we've kept fs/ext2/*.c is to provide sample file system
code more than anything else.  Many distributions (including Debian)
use fs/ext4 to support the ext2 file systems, via kernel config
CONFIG_EXT4_USE_FOR_EXT2.

As I mentioned, for the most part file system developers have tended
to care much more about kernel and file system utility
back-compatibility.  This is probably because we have our own ways of
controlling these issues using controls such as /etc/mke2fs.conf, but
also because we tend to worry much more about data disks than
installers.  And if much fewer Debian users tend to boot using say,
xfs or f2fs, perhaps people have just not noticed and complained.

Moving forward, certainly I and other fs developers will be spending
more time worrying about grub2 handling various file system features.
For example, grub2 doesn't understand the ext4 "casefold" feature, and
someday someone might want to make a Debian derivitive where users'
home directories work like MacOS and Windows...

Documenting this in ext4(5) is a bit challenging, because (a) not all
users use the grub2 bootloader, and (b) that means we'd have to
continuously update ext4(5) as grub2 changes.  But certainly we could
make a generic warning in ext4(5).

It might be that a Wiki is the best place for this.  The Arch and
Gentoo wikis have some of this already, since Arch and Gentoo users
tend to believe in enabling all file system developers (whether it is
good for them or not).  That's great for me in terms of beta testers
for features that I don't think is 100% ready for prime time, but
that's another reason why using a newer mkfs is a bad idea.

For example, the inline_data feature is *not* ready for prime time,
but it's been getting better, and someday we might enable it by
default in Debian N+x.  It'll *mostly* work so long as you don't
stress-test creating writing, truncating, etc., small files, but if
vmdb2 enables inline_data for Bookworm even though the Bookworm
e2fsprogs doesn't enable inline_data by default (but some future
Debian N+x does enable it by default), some users' lives might get
*exciting*, since the Bookworm will probably will be on the 6.1 LTS
kernel.

- Ted

Bug#1028471: cmucl: diff for NMU version 21d-2.1

[Adrian Bunk]

On Thu, Feb 16, 2023 at 04:36:33PM +0100, Peter Van Eynde wrote:
> Hi Adrian,

Hi Peter,

> Thanks for that. I was reading up on this 'source only' uploads. In general I 
> agree with the idea, however for cmucl when a new major version gets released 
> the rebuilding of the new version using the old version is non-trivial and 
> not automated.
> 
> So for major releases I do the rebuilding manually and then upload 
> binaries+source. The binaries can rebuild the sources, but the old binaries 
> cannot.
> 
> Is this setup still supported with the new rules or is this the last hurrah 
> from the cmucl package?

this setup is still supported, but you have to make second upload with a 
new Debian revision and without binaries (dpkg-buildpackage -S) 
afterwards.

If you look at the diff of my proposed NMU, it does not contain any 
changes other than a new entry in debian/changelog.

> Best regards, Peter

cu
Adrian

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
>...
> Reasons:
>...
> - - the change makes it impossible to create filesystems with this version of
>   e2fsprogs and then run a grub-install from a target system that does not 
> cope
>   with that feature; basically breaking the debootstrap method of installing
>   Debian or Ubuntu onto a server (violating #4 of the Debian social contract)
>...
> Instead, turning on this feature should be postponed for the next release 
> cycle
> where a proper transition can be done.
>...

Daniel, you are contradicting yourself when claiming that a change that 
would allegedly violate the Debian social contract could be done in the 
next release cycle.

> Daniel Leidert

cu
Adrian

Bug#988462: trac: not ready for Debian 12

[Santiago Vila]

Hello.

I'm not a trac user myself, but I've noticed that trac has just been
removed from testing today.

AFAIK, the main reason trac was not ready for Debian 12 was the
problems with python3, but those in theory have been fixed
by version 1.5.4-1 (bug #1030413).

Therefore: Should not this bug (#1024647) be closed accordingly?

(If so, I guess you will also have to ask Release Managers for an exception
so that trac enters testing again).

Thanks.

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Daniel Leidert]

Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
> On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
> > ...
> > Reasons:
> > ...
> > - - the change makes it impossible to create filesystems with this version 
> > of
> >   e2fsprogs and then run a grub-install from a target system that does not 
> > cope
> >   with that feature; basically breaking the debootstrap method of installing
> >   Debian or Ubuntu onto a server (violating #4 of the Debian social 
> > contract)
> > ...
> > Instead, turning on this feature should be postponed for the next release 
> > cycle
> > where a proper transition can be done.
> > ...
> 
> Daniel, you are contradicting yourself when claiming that a change that 
> would allegedly violate the Debian social contract could be done in the 
> next release cycle.

Actually, I'm not. I have never said that I reject the introduction of
that change. But I reject it in the current situation, and I reject the
way it is handled. And if you read the whole report and the discussion
I was involved in, then maybe you can understand that I perceive it
that both, Steve and Theodore, were very well with the idea of breaking
with Bullseye and Ubuntu and other systems, where grub doesn't support
that feature, right now and "just like that". And I think this is a
violation of #4. I have also written in [1] how I think the transition
should be handled (IMO), especially given the fact that grub has no
upstream release with a fix yet.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030939#108

Regards, Daniel

Bug#988462: trac: not ready for Debian 12

[Santiago Vila]

Sorry. I said:


Therefore: Should not this bug (#1024647) be closed accordingly?


I really meant *this* bug, #988462, i.e. "trac: not ready for Debian 12".

(But while we are at it, the other bug is fixed but not closed and maybe
it should be closed as well).

Thanks.

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote:
> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
> > On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
> > > ...
> > > Reasons:
> > > ...
> > > - - the change makes it impossible to create filesystems with this 
> > > version of
> > >   e2fsprogs and then run a grub-install from a target system that does 
> > > not cope
> > >   with that feature; basically breaking the debootstrap method of 
> > > installing
> > >   Debian or Ubuntu onto a server (violating #4 of the Debian social 
> > > contract)
> > > ...
> > > Instead, turning on this feature should be postponed for the next release 
> > > cycle
> > > where a proper transition can be done.
> > > ...
> > 
> > Daniel, you are contradicting yourself when claiming that a change that 
> > would allegedly violate the Debian social contract could be done in the 
> > next release cycle.
> 
> Actually, I'm not.
>...

If not being able to install bullseye from bookworm is a violation of 
the Debian social contract, then the same rationale applies to not
being able to install bullseye from trixie being a violation of
the Debian social contract.

In [1] you are arguing with problems installing Ubuntu 20.04 this
way from bookworm with the e2fsprogs change, the same will apply
to installing Ubuntu 22.04 from trixie.

QED

> I have also written in [1] how I think the transition
> should be handled (IMO)
>...

I am currently spending time trying to summarize the situation and open
questions, and I am a bit underwhelmed by the inaccuracies and lack of
technical detail in your emails.

The instructions you cite in [1] are for installing bullseye from
non-Debian systems. What bookworm ships does not matter much there,
these instructions will be wrong as soon as some *other* distribution
like Fedora changes the default.

I am wondering how exactly your often repeated "there is no grub 
upstream release with support for it" would be relevant in practice.
Whether it's 2.06-8 or 2.07-1 in bookworm shouldn't make a difference.

Sebastian has now created #1031364 for your original vmdb2 problem, 
everyone discussing in #1030939 seems to have missed that tools in 
bookworm creating images for < bookworm must handle such changes.
That's not different from debootstrap having code to handle 
apt-transport-https being required in some older releases.

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030939#108
> 
> Regards, Daniel

cu
Adrian

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote:
>> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
>> > On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
>> > > ...  > > Reasons: > > ...  > > - - the change makes it
>> impossible to create filesystems with this version of > >  
>> e2fsprogs and then run a grub-install from a target system that
>> does not cope > >   with that feature; basically breaking the
>> debootstrap method of installing > >   Debian or Ubuntu onto a
>> server (violating #4 of the Debian social contract) > > ...  > >
>> Instead, turning on this feature should be postponed for the next
>> release cycle > > where a proper transition can be done.  > > ...
>> > 
>> > Daniel, you are contradicting yourself when claiming that a
>> change that > would allegedly violate the Debian social contract
>> could be done in the > next release cycle.
>> 
>> Actually, I'm not.  ...

Adrian> If not being able to install bullseye from bookworm is a
Adrian> violation of the Debian social contract, then the same
Adrian> rationale applies to not being able to install bullseye from
Adrian> trixie being a violation of the Debian social contract.

I don't think that arguing about whether this is a social contract
violation makes a lot of sense.
It seems fairly clear there is not a consensus about that.

But if we're going to do that, I suggest that Adrian is putting words
into Daniel's mouth a bit.
Daniel has said he believes this situation violates the Social Contract
#4, but has not explained why.
Adrian has taken one interpretation.
I'll propose another: "This violates the social contract because we are
not prioritizing our users.  Prioritizing users requires that we give
them notice of incompatible changes."
I personally think that prioritizing users requires no such thing, and
that this change is not a violation of the SC.
But you don't need to take the straw man position Adrian is assuming
Daniel implies to believe this is a SC violation.

But seriously, let's give up the whole is this an SC violation part of
the discussion and move on with constructive aspects:

* The RT has asked to understand the impact of the change.

* Several people have proposed better documentation because it's clear
  that user (and image builder) expectations are not aligned with
  filesystem maintainer expectations.

* Anyone could prepare patches to image building software to use mkfs
  options that will work with bullseye.  You could also try to prepare
  patches to run mkfs out of a chroot or container of the guest OS for
  the image.  I appreciate Russ strongly favors this solution, but as
  someone who has dug into image building tools a fair bit over the
  years, I think there are significant complexity and performance
  downsides to that approach.  I also think that changing the mkfs
  options is more likely to get an unblock than changing the structure
  of how the tool works.
  
  
  
* People could try to judge consensus on debian-devel or debian-policy
  about whether we want a stability guarantee ?+/- 1 release on issues
  like this.  My suspicion is that you will not find a consensus, and
  that if the RT decides they don't want this change in bookworm, Ted
  will change the defaults, and if the RT is unwilling to block, we're
  left with documentation.

I think all the above is more productive than arguing about whether this
is or is not an SC violation.


signature.asc
Description: PGP signature

Bug#1017906: Bug#1017892: Ships copies of libraries that are in Debian and autogenerated files that can't be renegerated with the code in Debian main

[Sean Whitton]

Hello,

On Sun 01 Jan 2023 at 05:15PM +01, Paul Gevers wrote:

> Hi Sean,
>
> On Mon, 22 Aug 2022 14:29:56 -0700 Sean Whitton 
> wrote:
>> control: severity 1017906 wishlist
>
>> > Is there ftp team consensus that either or both of these issues are RC?
>> #1017892 is wishlist or not a bug. [...]
>
>> #1017906 *might* be a problem. [...]
>
> It seems like you mixed up the bugs in your control message? I'm currently
> staring at #1017892 (vendored copies) because it's RC, but I agree with you it
> looks much less severe. Given that, do you think #1017906 (no source) should
> be raised again until somebody has figured out if there's *no* RC problem?

Yes.  #1017892 should be wishlist, #1017906 possibly serious, depending
on the details.  My apologies!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Daniel Leidert]

Am Donnerstag, dem 16.02.2023 um 20:10 +0200 schrieb Adrian Bunk:

[..]
> I am currently spending time trying to summarize the situation and open
> questions, and I am a bit underwhelmed by the inaccuracies and lack of
> technical detail in your emails.

Well, I didn't have weeks to prepare. I had <24 hours and gave you
already enough information so you did not have to start from scratch.

I will summarize my points at the bottom.

> The instructions you cite in [1] are for installing bullseye from
> non-Debian systems.

That is simply not true. Those are general instructions, they are not
limited to non-Debian systems. Most server providers have exctly *one*
rescue system from where I can do a clean installation with deboostrap
(and that even usually is a Debian). I cannot choose to use one that
hasn't an e2fsprogs that has this breaking change enabled. Say for
example, grml, used by multiple providers I know as rescue system and
based on Debian, picks up Bookworm with e2fsprogs with that change. Now
users trying to install anything other than a Debian Bookworm using the
deboostrap method will run into the situation that "grub-install" will
fail, and it won't even indicate that they will have to tune the just
created ext4 filesystem or even change /etc/mke2fs.conf. I spent a few
hours until I tracked it down. And the situation right now is, that I
can simply install any system with the deboostrap method. I'm not aware
that there are any breakages or incompatibilities.

> What bookworm ships does not matter much there,
> these instructions will be wrong as soon as some *other* distribution
> like Fedora changes the default.

Fedora isn't used much as a rescue system, don't you think? Have you
ever encountered that? I do custom server setups with deboostrap for
almost two decades now. I haven't seen any distribution so far that
changed the created filesystem to be incomatible with grub-install from
the systems that might be installed. Most of the rescue systems were
Debian based, JFTR.

> I am wondering how exactly your often repeated "there is no grub 
> upstream release with support for it" would be relevant in practice.
> Whether it's 2.06-8 or 2.07-1 in bookworm shouldn't make a difference.

You completely miss the point here. It would lead to exactly the same
situation if 2.07 would be the *first* to support it and could be
shipped with Bookworm as long as e2fsprogs makes this breaking change
now. But it makes a huge difference if 2.07 with a fix is released in
around the same time as Bookworm and can spread until Trixie is
prepared and the breaking change is postponed to Trixie. Ubuntu 24
would have picked up that fix by then. 22 and maybe even 20 would
probably have picked it up either. Even bullseye could get a patch to
deal with that. The breakage would have less impact than it has now,
while nothing is prepared.

And it is completely illusional to say that people should first create
a Bullseye chroot to then do a deboostrap setup of a target system from
that chroot, as Theodore suggested. Well, I'm more than underwhlemed by
suggestions like this.

> Sebastian has now created #1031364 for your original vmdb2 problem, 
> everyone discussing in #1030939 seems to have missed that tools in 
> bookworm creating images for < bookworm must handle such changes.
> That's not different from debootstrap having code to handle 
> apt-transport-https being required in some older releases.

I agree. So don't you think introducing this now is a really bad
timing?

I checked a search engine to find out what this feature even does.
Turns out, there were less than 500 hits. It is a feature available
since kernel 4.4 and not widely used nor default. So what is the gain
here? I also tried to understand why our users would need to be able to
change the UUID of the filesystem. In 20 years with Debian, I haven't
encountered a situation where this has been necessary (I didn't even
know that one could). My gut feeling is, that this feature is only
useful to a handful of people. I haven't heard any explanation so far
why this needs to be turned on by default just now. The whole
discussion so far has been Theodore argueing why he doesn't care about
his actions and why he doesn't have to.

If this feature should be turned on, then I still think that doing this
for Trixie is the better choice. The tools affected can be fixed to
work around the issue. The other distributions can pick up the grub-
install fix.

And JFTR: The attitude I preceived since I got into the discussion with
the simple sentence that fixing grub in Bookworm might not be enough,
can be summarized as "I/we don't care". So, sorry, I care, even if my
less excellent mails might be underwhelming for you.

Daniel

Bug#988462: trac: not ready for Debian 12

[Martin]

On 2023-02-16 17:44, Santiago Vila wrote:
> AFAIK, the main reason trac was not ready for Debian 12 was the
> problems with python3, but those in theory have been fixed

1.5.x is the development branch of Trac and I would like to wait for the
official 1.6 release. It probably comes to late for Debian 12. The state
of trac in Debian is not very good anyway, e.g. all trac plugins are
gone and need to be reintroduced.

My plan is to wait for 1.6 and provide backports for the bookworm
release cycle.

Cheers

Bug#1031223: marked as done (python-streamz: FTBFS (failing tests))

[Debian Bug Tracking System]

Your message dated Thu, 16 Feb 2023 19:19:53 +
with message-id 
and subject line Bug#1031223: fixed in python-streamz 0.6.4-1
has caused the Debian Bug report #1031223,
regarding python-streamz: FTBFS (failing tests)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1031223: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031223
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: src:python-streamz
Version: 0.6.3-3
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in bookworm, your package failed to build:


[...]
 debian/rules binary-indep
dh binary-indep --with python3 --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:240: python3.11 setup.py config
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:240: /usr/bin/python3 setup.py build
running build
running build_py
creating /<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/utils_test.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/orderedweakset.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/collection.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/core.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/batch.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/sinks.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/utils.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/__init__.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/graph.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/plugins.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/sources.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
copying streamz/dask.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz
creating /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe
copying streamz/dataframe/core.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe
copying streamz/dataframe/utils.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe
copying streamz/dataframe/__init__.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe
copying streamz/dataframe/aggregations.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe
creating /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
copying streamz/tests/test_batch.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
copying streamz/tests/test_core.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
copying streamz/tests/py3_test_core.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
copying streamz/tests/test_graph.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
copying streamz/tests/test_kafka.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
copying streamz/tests/__init__.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
copying streamz/tests/test_dask.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
copying streamz/tests/test_sinks.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
copying streamz/tests/test_plugins.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
copying streamz/tests/test_sources.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests
creating 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe/tests
copying streamz/dataframe/tests/test_dataframes.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe/tests
copying streamz/dataframe/tests/test_dataframe_utils.py -> 
/<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe/tests
   dh_auto_test -i -O--buildsystem=pybuild
I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11_streamz/build; 
python3.11 -m pytest
= test session starts ==
platform linux -- Python 3.11.1, pytest-7.2.1, pluggy-1.0.0+repack
rootdir: /<>, configfile: setup.cfg
plugins: flaky-3.7.0
collected 1569 items / 2 skipped

streamz/dataframe/tests/test_dataframe_utils.py .s.s [  0%]
streamz/dataframe/tests/test_dataframes.py . [  2%]
 [  6%]
 

Processed: Re: Bug#1031394: Please re-enable RTTI support in Sid/Bookworm, needed by at least Ceph

[Debian Bug Tracking System]

Processing control commands:

> tags -1 +moreinfo
Bug #1031394 [libsnappy1v5] Please re-enable RTTI support in Sid/Bookworm, 
needed by at least Ceph
Added tag(s) moreinfo.

-- 
1031394: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031394
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1031394: Please re-enable RTTI support in Sid/Bookworm, needed by at least Ceph

[GCS]

Control: tags -1 +moreinfo

Dear Thomas,

On Thu, Feb 16, 2023 at 1:51 PM Thomas Goirand  wrote:
> During my tests with Ceph, I noticed a grave regression: Ceph OSD (the process
> that does the actual storage for Ceph) cannot use Snappy anymore, because it
> can't find one symbole related to RTTI.
 Isn't that because the upgrade path is not correct? New Ceph binaries
should handle this path.

> The consequence is that it cannot load and use Snappy. This may be ok for 
> newer
> clusters, but when upgrading from a cluster let's say in Bullseye, this may be
> desastrous: data wont be able to be unpacked, which means data loss.
 I don't see it as a data loss, but a data access issue.

> Moving forward, what I propose is probably the easiest way forward, at least
> for Ceph. Doing extra patching of the Ceph would be a way more hazardous.
 I'm quite surprised this was realized so late. You are probably not
the only person using Ceph. How others can use, how they upgraded
their Ceph clusters?

Regards,
Laszlo/GCS

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Russ Allbery]

Sam Hartman  writes:

> * Anyone could prepare patches to image building software to use mkfs
>   options that will work with bullseye.  You could also try to prepare
>   patches to run mkfs out of a chroot or container of the guest OS for
>   the image.  I appreciate Russ strongly favors this solution, but as
>   someone who has dug into image building tools a fair bit over the
>   years, I think there are significant complexity and performance
>   downsides to that approach.  I also think that changing the mkfs
>   options is more likely to get an unblock than changing the structure
>   of how the tool works.

Yes, I'm probably understating the difficulty of making this change in
practice inside image building software as it's currently constructed.

My concern about changing mkfs options is that I worry that this would be
a constantly-changing target that has to be synchronized across multiple
pieces of software that are not currently well-aligned with file system
development.  One thing that would make this much easier would be for mkfs
to support some sort of compatibility level flag that sets all of the
options, whatever they may be, to their defaults as of some point in the
past.  Image building software could then pick a conservative default set
point when building images for older distributions.  That change still has
to be added to all of the image building software, but it might be easier
than building a local chroot of the target distribution before using it to
build the file system the actual installation is going into.

I suspect this won't be Ted's favorite option because this isn't a natural
way to think about the option space from a file system developer
perspective, but maybe we could find some compromise along those lines?

-- 
Russ Allbery (r...@debian.org)  

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Thu, Feb 16, 2023 at 08:02:11PM +0100, Daniel Leidert wrote:
>...
> Most server providers have exctly *one*
> rescue system from where I can do a clean installation with deboostrap
> (and that even usually is a Debian). I cannot choose to use one that
> hasn't an e2fsprogs that has this breaking change enabled. Say for
> example, grml, used by multiple providers I know as rescue system and
> based on Debian, picks up Bookworm with e2fsprogs with that change. Now
> users trying to install anything other than a Debian Bookworm using the
> deboostrap method will run into the situation that "grub-install" will
> fail, and it won't even indicate that they will have to tune the just
> created ext4 filesystem or even change /etc/mke2fs.conf.
>...

You are saying that a bug report is needed against grml-debootstrap for
disabling metadata_csum_seed in <= bullseye?

The fix would likely be right next to the code that disables the new
metadata_csum default in stretch for <= jessie where it was not supported.

> Daniel

cu
Adrian

Bug#1031310: marked as done (git: CVE-2023-22490 CVE-2023-23946)

[Debian Bug Tracking System]

Your message dated Thu, 16 Feb 2023 20:52:02 +0100
with message-id 
and subject line Accepted git 1:2.39.2-1 (source) into unstable
has caused the Debian Bug report #1031310,
regarding git: CVE-2023-22490 CVE-2023-23946
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1031310: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031310
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: git
Version: 1:2.30.2-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:2.39.1-0.1

Hi,

The following vulnerabilities were published for git.

CVE-2023-22490[0] and CVE-2023-23946[1].

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-22490
https://www.cve.org/CVERecord?id=CVE-2023-22490
[1] https://security-tracker.debian.org/tracker/CVE-2023-23946
https://www.cve.org/CVERecord?id=CVE-2023-23946
[2] https://www.openwall.com/lists/oss-security/2023/02/14/5

Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Source: git
Source-Version: 1:2.39.2-1

This fixes as well #1031310.

- Forwarded message from Debian FTP Masters 
 -

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 15 Feb 2023 17:08:12 -0800
Source: git
Architecture: source
Version: 1:2.39.2-1
Distribution: unstable
Urgency: medium
Maintainer: Jonathan Nieder 
Changed-By: Jonathan Nieder 
Changes:
 git (1:2.39.2-1) unstable; urgency=medium
 .
   * new upstream point release (see RelNotes/2.39.2.txt).  Addresses
 CVE-2023-22490 and CVE-2023-23946.
Checksums-Sha1:
 2b825cd66dbe47eaa0e1ce3ab8e8f7d632ac23d9 2825 git_2.39.2-1.dsc
 3c415274f626589b37d5b0a9add11de34bcc2f5d 7163224 git_2.39.2.orig.tar.xz
 95571d76a006586245cbb20918ba5ed3bda337ff 740572 git_2.39.2-1.debian.tar.xz
 efd1d87c0c2eca411f3a622cf34aa404f09c74ed 12159 git_2.39.2-1_amd64.buildinfo
Checksums-Sha256:
 5580d3bc887e643e0c3e0f2508721944f7a6aa76e7500bc3df0667bdbd66f044 2825 
git_2.39.2-1.dsc
 475f75f1373b2cd4e438706185175966d5c11f68c4db1e48c26257c43ddcf2d6 7163224 
git_2.39.2.orig.tar.xz
 7b53684272257f7756e0bd216670fb0264ec565133c8d3bba915fbdffe7e80c9 740572 
git_2.39.2-1.debian.tar.xz
 86d5e7718c541888219574e9ea37a21c377674ad1014dc2ebe39294ae07859e3 12159 
git_2.39.2-1_amd64.buildinfo
Files:
 5c76f96f86ef43db830a406a189d1bd0 2825 vcs optional git_2.39.2-1.dsc
 32d34dc65ae0955cc68c7152b5ca8b13 7163224 vcs optional git_2.39.2.orig.tar.xz
 4560a10474153d20a2f0c816d2f7c920 740572 vcs optional git_2.39.2-1.debian.tar.xz
 3c8517bbcebfbde70e26a9e6d6e1b659 12159 vcs optional 
git_2.39.2-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEEUh5Y8X6W1xKqD/EC38Zx7rMz+iUFAmPthHATHGpybmllZGVy
QGdtYWlsLmNvbQAKCRDfxnHuszP6Je0DD/9900eZaS4fisiReqfqCckBrzpptWmM
DERfySALa9XOusxXpwdwHWMf3TtxkXCgrHkZBp/yus0tijzKEz6/OtiL2QT45EmL
8Hc2M//xCCNrPcb/DBKpD8NOV1MQJwynfeQfOrdRyWZCgg7g4wLx25aVnBOQWsxm
PycCk8nk+gogLKcyKNh4lydE9BUq/QjfgymNkRUC6ONtRpFXbp1sJwp6HQXBe+j/
p5ZFObHuIMJDYhfvbal9/fvUqePZ969wFzqM9WHzZN+/0UuiDVtxEgMGiNcA0+pl
CxjV711YhM9YumS7SmB/4PI0iboVJc2g4jXnsgOcVumwMySkkCI9gPeINxZ5Fv6o
xOXBZu7TEoweXduMtuJiXrNvQOD6+PTw+nHyRO7VJTJLhue56sIW5sH3JEMVqTyg
Baa4eXzPrSUEbVjU8/Nx12pe9Fg5IWKPJFYfJpatvDGUyeL74Bs2fQGOsUGcrB2d
dMcImhv1wkmHi2CVzENfnz/WWqwBRsuDmaV51lpLYMziakR2jcsj2O8Ekz6AKeTS
Kj5CBjtPP+IaXHwgsIcHixNzdlH5y4PHQmjrbG7x0jtP4WrByKya1NLc0cQWbrgE
bAtLu64vbYBddEK6eJz2WOWFVGxMyOPCoeiE0xiNErM1KcsEdHzQfXFb8bB+9Bk2
Y9CFhmEHaOhywA==
=+4cJ
-END PGP SIGNATURE-


- End forwarded message  End Message ---

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

Disclaimer:
Like everyone else except Sebastian who commented in this bug so far,
I am not a member of the release team.

Below is my attempt to give an overview of the situation,
feel free to amend/correct if anything is missing or wrong.


1. Image creation tools need special cases for older distibutions

Image creation tools that support installing older/other
distributions must be able to handle such differences in general
(e.g. debootstrap has code to handle apt-transport-https being
required in some older releases), and have to add the (trivial)
support for this difference.

Sebastian has already created #1031364 for the original vmdb2 problem.


2. How many packages are affected?

There are to at least two classes of affected packages:
- Bootloaders that can read (or even write) ext4.
- Image creation tools in bookworm that can create < bookworm images

For both classes it is unclear how many packages still require fixing.

This is a major unclear question.


3. Image creation versus target usage

The original #1030846 was from Debian Installer developers,
and everything discussed there is around image creation.

The original discussion was about installing bookworm from bookworm.

Daniel is discussing installing older/other distributions from bookworm.

Noone seems to have discussed on-target usage, e.g. when arguing in 
#1030846 why there would not be a need for
   Breaks: grub2-common (<< 2.06-8~)
in e2fsprogs.

The version of e2fsprogs currently in bookworm is in bullseye-backports,
if the version with the new default goes into bookworm and unchanged
into bullseye-backports it's pretty obvious how this could screw
on-target users ("target" might also be called "desktop" or "server")
when creating new bootable partitions.


4. e2fsprogs should add Breaks on non-fixed versions of packages

For e2fsprogs in bullseye-backports such Breaks might only be a reminder 
that both the Breaks and the changed default should be reverted there, 
but in bookworm it would ensure that users don't end up with an 
incompatible combination of packages (e.g. if an older version of
grub or an image creation tool is pinned in apt).


5. Combination/Mix of packages from two adjacent Debian releases should work

A rule of thumb is that any combination/mix of packages permitted by the 
package manager from two adjacent Debian releases should work whenever 
reasonably possible, since this reduces problems for our users during an 
upgrade, when using backports, or when temporarily going back to the 
version of a package from the previous stable due to a regression.

The normal case (e.g. shared library linking) is that package 
dependencies ensure that package managers will only permit working 
combinations of packages.

Do we have any case where mixing bullseye and bookworm would not work 
with Breaks on all unfixed versions of bootloaders and image creation tools?


6. Any data/experience from metadata_csum enabled by default in stretch?

There seems to have been a similar situation with metadata_csum being 
enabled by default in stretch.

What data/experience exists about required fixes and problems from
that change?


7. It is late in the release cycle for such a change

The answer to point 2 is relevant whether it might be too late.


8. User documentation should document such incompatible changes

In whatever release this feature gets enabled by default,
a fresh bug against the release-notes pseudo-package with text
describing the incompatibility and possible workarounds should
be filed (Ted has already provided a draft text[1]).


9.There seems to be a similar situation with XFS bigtime

XFS is a less common filesystem, but what is discussed above
might also apply there.


10. Documentation for installing Debian from other distributions

Instructions for installing Debian from other distributions
need updating in any case.

Anything like [2] in the Bullseye Installation Guide will
be broken as soon as a different distribution changes the
default and needs updating, no matter what Debian does
in bookworm.


cu
Adrian

[1] https://lists.debian.org/debian-release/2023/02/msg00250.html
[2] https://www.debian.org/releases/stable/amd64/apds03.en.html

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

Replying off list, because I don't think it matters much for the RT
discussion.

> "Russ" == Russ Allbery  writes:
Russ> Yes, I'm probably understating the difficulty of making this
Russ> change in practice inside image building software as it's
Russ> currently constructed.

Russ> My concern about changing mkfs options is that I worry that
Russ> this would be a constantly-changing target that has to be
Russ> synchronized across multiple pieces of software that are not
Russ> currently well-aligned with file system development.

Sadly, supporting a new distribution in image building software is a
constantly changing target that requires small tweaks all the time.


Carthage has a function debian_container_to_vm that uses FAI  to turn a
directory tree into a VM image.
For bookworm, we end up needing to deal with systemd-resolved getting
split.
There was also some change in recent memory related to
apt-transport-https and when it was needed.

It's mostly small stuff, but you end up having a series of tweaks for
the guest system, no matter how much you wish you didn't.

There are similar tweaks at the debootstrap level, at the FAI level, and
even in the container frontends to a small extent.

I absolutely agree mkfs compatibility options would be great, but
chasing down how to call mkfs is par for the course.

I haven't looked much at vmdb2 because I disagree with the design
philosophy, but I think it has tweaks too.

Bug#1031388: icingaweb2-module-pdfexport: server software depending on chromium?

[Steve Langasek]

On Thu, Feb 16, 2023 at 12:45:20PM +0100, David Kunz wrote:

> > The current version of icingaweb2-module-pdfexport depends on chromium.
> All versions are like thes.

icingaweb2-module-pdfexport 0.9.1-2 did not have such a dependency.

> > icingaweb2 is a web service.  Depending on a graphical browser in a web
> > server component is not at all reasonable.
> I know, but upstream considers this to be the best possible way to solve
> this problem.

> Now we can provide this package as it is or no package exist and all
> packages that depends to it are unusable.

Ok, well, you can do as you wish in Debian.  This dependency is
unsatisfiable in Ubuntu because chromium is not available as a .deb package
in recent releases of Ubuntu, therefore this package will be removed there
as unsupportable.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> Below is my attempt to give an overview of the situation,
Adrian> feel free to amend/correct if anything is missing or wrong.


I believe your summary is correct and includes the issues I am aware of.
I believe I am following things enough that I have confidence in that
conclusion.

Thanks much.


signature.asc
Description: PGP signature

Processed: Re: Bug#1031399: rsyslog: Log rotation broken on non-systemd systems

[Debian Bug Tracking System]

Processing control commands:

> severity -1 wishlist
Bug #1031399 [rsyslog] rsyslog: Log rotation broken on non-systemd systems
Severity set to 'wishlist' from 'serious'
> retitle -1 document log rotation on non-default inits
Bug #1031399 [rsyslog] rsyslog: Log rotation broken on non-systemd systems
Changed Bug title to 'document log rotation on non-default inits' from 
'rsyslog: Log rotation broken on non-systemd systems'.

-- 
1031399: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031399
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1031399: rsyslog: Log rotation broken on non-systemd systems

[Michael Biebl]

Control: severity -1 wishlist
Control: retitle -1 document log rotation on non-default inits

Am 16.02.23 um 15:41 schrieb Matthew Vernon:

Package: rsyslog
Version: 8.2212.0-1
Severity: serious

Hi,

When removing the systemv init scripts from rsyslog (which can be
managed by orphan-sysvinit-scripts), the following was also removed from
/usr/lib/rsyslog/rsyslog-rotate:

else
 invoke-rc.d rsyslog rotate > /dev/null

This means on non-systemd systems logrotate tries but fails to tell
rsyslog to rotate its logs.

Could you restore this, please? 


I don't plan to re-add this (btw, this would break if 
orphan-sysvinit-scripts is not installed).


I'll add a note to README.Debian to the logrotate section though, what 
users of non-default inits need to consider.


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031394: marked as done (Please re-enable RTTI support in Sid/Bookworm, needed by at least Ceph)

[Debian Bug Tracking System]

Your message dated Thu, 16 Feb 2023 20:42:52 +
with message-id 
and subject line Bug#1031394: fixed in snappy 1.1.9-3
has caused the Debian Bug report #1031394,
regarding Please re-enable RTTI support in Sid/Bookworm, needed by at least Ceph
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1031394: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031394
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libsnappy1v5
Version: 1.1.8-1
Severity: grave
Tags: patch

Dear Laszlo,

During my tests with Ceph, I noticed a grave regression: Ceph OSD (the process
that does the actual storage for Ceph) cannot use Snappy anymore, because it
can't find one symbole related to RTTI.

The consequence is that it cannot load and use Snappy. This may be ok for newer
clusters, but when upgrading from a cluster let's say in Bullseye, this may be
desastrous: data wont be able to be unpacked, which means data loss.

Please find attached a very small patch to re-enable RTTI support in Ceph.

Note related upstream bug in Ceph:
https://tracker.ceph.com/issues/53060

Moving forward, what I propose is probably the easiest way forward, at least
for Ceph. Doing extra patching of the Ceph would be a way more hazardous.

Your thoughts?

Cheers,

Thomas Goirand (zigo)
diff -Nru snappy-1.1.9/debian/changelog snappy-1.1.9/debian/changelog
--- snappy-1.1.9/debian/changelog   2022-05-08 18:26:22.0 +
+++ snappy-1.1.9/debian/changelog   2023-02-16 12:37:39.0 +
@@ -1,3 +1,10 @@
+snappy (1.1.9-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Re-enable RTTI support.
+
+ -- Thomas Goirand   Thu, 16 Feb 2023 12:37:39 +
+
 snappy (1.1.9-2) unstable; urgency=medium
 
   * Upload to Sid.
diff -Nru snappy-1.1.9/debian/patches/re-enable-rtti-support.patch 
snappy-1.1.9/debian/patches/re-enable-rtti-support.patch
--- snappy-1.1.9/debian/patches/re-enable-rtti-support.patch1970-01-01 
00:00:00.0 +
+++ snappy-1.1.9/debian/patches/re-enable-rtti-support.patch2023-02-16 
12:37:39.0 +
@@ -0,0 +1,29 @@
+Description: Re-enable RTTI support
+Author: Thomas Goirand 
+Forwarded: no
+Last-Update: 2023-02-16
+
+--- snappy-1.1.9.orig/CMakeLists.txt
 snappy-1.1.9/CMakeLists.txt
+@@ -51,10 +51,6 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC"
+   string(REGEX REPLACE "/EH[a-z]+" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /EHs-c-")
+   add_definitions(-D_HAS_EXCEPTIONS=0)
+-
+-  # Disable RTTI.
+-  string(REGEX REPLACE "/GR" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /GR-")
+ else(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
+   # Use -Wall for clang and gcc.
+   if(NOT CMAKE_CXX_FLAGS MATCHES "-Wall")
+@@ -76,10 +72,6 @@ else(CMAKE_CXX_COMPILER_ID STREQUAL "MSV
+   # Disable C++ exceptions.
+   string(REGEX REPLACE "-fexceptions" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-exceptions")
+-
+-  # Disable RTTI.
+-  string(REGEX REPLACE "-frtti" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-rtti")
+ endif(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
+ 
+ # BUILD_SHARED_LIBS is a standard CMake variable, but we declare it here to 
make
diff -Nru snappy-1.1.9/debian/patches/series snappy-1.1.9/debian/patches/series
--- snappy-1.1.9/debian/patches/series  2021-12-04 18:21:57.0 +
+++ snappy-1.1.9/debian/patches/series  2023-02-16 12:37:39.0 +
@@ -4,3 +4,4 @@
 0001-Add-inline-with-SNAPPY_ATTRIBUTE_ALWAYS_INLINE.patch
 use_packaged_testing.patch
 correct_testing_link.patch
+re-enable-rtti-support.patch
--- End Message ---
--- Begin Message ---
Source: snappy
Source-Version: 1.1.9-3
Done: Laszlo Boszormenyi (GCS) 

We believe that the bug you reported is fixed in the latest version of
snappy, 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 1031...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Laszlo Boszormenyi (GCS)  (supplier of updated snappy 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
D

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
>...
> Instead, turning on this feature should be postponed for the next release 
> cycle
> where a proper transition can be done.
>...

On Thu, Feb 16, 2023 at 08:02:11PM +0100, Daniel Leidert wrote:
>...
> You completely miss the point here. It would lead to exactly the same
> situation if 2.07 would be the *first* to support it and could be
> shipped with Bookworm as long as e2fsprogs makes this breaking change
> now. But it makes a huge difference if 2.07 with a fix is released in
> around the same time as Bookworm and can spread until Trixie is
> prepared and the breaking change is postponed to Trixie.
>...

You are contradicting yourself by first unconditionally approving making 
the change in trixie, but later trying to make this conditional on grub 
making a new upstream release around the same time as Bookworm.

We can only control what is in Debian releases, we cannot be waiting
for godot^Wgrub making a new release before making a change in Debian.

The best default assumption when discussing whether the change should be 
made in bookworm or trixie is that there will be no new grub release 
during the next 2 years - it's only 2 years since the latest release
and there was even a 5 year gap between 2.00 and 2.02.

> Daniel

cu
Adrian

Bug#982864: More info

[Dima Kogan]

The issue is a failing test in test/run_tests.bash:

  head fish1.png > ${tmpdir}/fake.png
  "$pdiff" --verbose fish1.png ${tmpdir}/fake.png 2>&1 | grep -q 'Failed to 
load'
  rm -f ${tmpdir}/fake.png

Here it's making sure that we are able to detect a corrupt .png file,
and to throw an error. The actual image load is being done by
libfreeimage. For whatever reason, on amd64 (and other non-breaking
platforms) FreeImage_Load() returns NULL when given this corrupt file,
which is what the test expects. But on the failing platforms it throws a
c++ exception instead. The test doesn't catch this exception and
crashes, causing this FTBFS.

I tried to catch this exception nicely with the attached patch, but for
some reason it doesn't work. Since this problem isn't in the main part
of the library, we should simply disable this particular test to resolve
the FTBFS and this RC bug.

If I don't hear back in a few days, I'm going to do an NMU with this
patch.

Thanks.

diff --git a/rgba_image.cpp b/rgba_image.cpp
index 2ba9a67..b91407c 100644
--- a/rgba_image.cpp
+++ b/rgba_image.cpp
@@ -147,10 +147,17 @@ namespace pdiff
 }
 
 FIBITMAP *free_image = nullptr;
-if (auto temporary = FreeImage_Load(file_type, filename.c_str(), 0))
+try
 {
-free_image = FreeImage_ConvertTo32Bits(temporary);
-FreeImage_Unload(temporary);
+if (auto temporary = FreeImage_Load(file_type, filename.c_str(), 0))
+{
+free_image = FreeImage_ConvertTo32Bits(temporary);
+FreeImage_Unload(temporary);
+}
+}
+catch (...)
+{
+throw RGBImageException("Failed to load the image " + filename);
 }
 if (not free_image)
 {
diff --git a/test/run_tests.bash b/test/run_tests.bash
index 757a164..2b25c29 100755
--- a/test/run_tests.bash
+++ b/test/run_tests.bash
@@ -84,10 +84,6 @@ rm -f diff.png
 ls ${tmpdir}/diff.png
 rm -f ${tmpdir}/diff.png
 
-head fish1.png > ${tmpdir}/fake.png
-"$pdiff" --verbose fish1.png ${tmpdir}/fake.png 2>&1 | grep -q 'Failed to load'
-rm -f ${tmpdir}/fake.png
-
 mkdir -p ${tmpdir}/unwritable.png
 "$pdiff" --output ${tmpdir}/unwritable.png --verbose fish{1,2}.png 2>&1 | grep -q 'Failed to save'
 rmdir ${tmpdir}/unwritable.png

Processed: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas

[Debian Bug Tracking System]

Processing control commands:

> found -1 clinfo/3.0.23.01.25-1
Bug #1031414 [src:clinfo, src:libgpuarray] clinfo breaks libgpuarray 
autopkgtest on i386: numerical deltas
Marked as found in versions clinfo/3.0.23.01.25-1.
> found -1 libgpuarray/0.7.6-13
Bug #1031414 [src:clinfo, src:libgpuarray] clinfo breaks libgpuarray 
autopkgtest on i386: numerical deltas
Marked as found in versions libgpuarray/0.7.6-13.

-- 
1031414: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031414
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas

[Paul Gevers]

Source: clinfo, libgpuarray
Control: found -1 clinfo/3.0.23.01.25-1
Control: found -1 libgpuarray/0.7.6-13
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of clinfo the autopkgtest of libgpuarray fails in 
testing when that autopkgtest is run with the binary packages of clinfo 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
clinfo from testing3.0.23.01.25-1
libgpuarrayfrom testing0.7.6-13
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of clinfo to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
clinfo/3.0.23.01.25-1. I.e. due to versioned dependencies or 
breaks/conflicts.

[1] https://qa.debian.org/excuses.php?package=clinfo

https://ci.debian.net/data/autopkgtest/testing/i386/libg/libgpuarray/31439784/log.gz

=== FAILURES 
===
__ test_ielemwise2_ops_mixed 
___


def test_ielemwise2_ops_mixed():
for op in ioperators2:
for dtype in dtypes_test:
for elem in elems:

  ielemwise2_ops_mixed(op, dtype, (50,), elem)


/usr/lib/python3/dist-packages/pygpu/tests/test_elemwise.py:173: _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/pygpu/tests/support.py:44: in f

func(*args, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

op = , dtype = 'float32', shape = (50,), elem = 0.3

@guard_devsup
def ielemwise2_ops_mixed(op, dtype, shape, elem):
incr = 0
if op == operator.isub and dtype[0] == 'u':
# array elements are smaller than 10 by default, so we 
avoid underflow

incr = 10
c, g = gen_gpuarray(shape, dtype, incr=incr, ctx=context,
cls=elemary)
try:
out_c = op(c, elem)
except TypeError:
# TODO: currently, we use old Numpy semantic and tolerate 
more case.

# So we can't test that we raise the same error
return
out_g = op(g, elem)
assert out_g is g
assert out_c.shape == out_g.shape
assert out_c.dtype == out_g.dtype

  assert numpy.allclose(out_c, numpy.asarray(out_g))

E   assert False
E+  where False = 0xf3ad35c8>(array([0.16798985, 0.10199559, 0.00094628, 0.284034  , 
0.00356799,\n   0.18276209, 0.06017095, 0.12363595, 0.14555043, 
0.06383288,\n   0.27849692, 0.23479545, 0.1120947 , 0.03348678, 
0.17435497,\n   0.10784233, 0.15038443, 0.08132076, 0.26949704, 
0.28150958,\n   0.08847237, 0.07874835, 0.14240652, 0.22457486, 
0.02050698,\n   0.24944574, 0.29784787, 0.03708786, 0.23751181, 
0.26554942,\n   0.26809436, 0.02403933, 0.23044948, 0.13133025, 
0.29589295,\n   0.05166197, 0.07869713, 0.10319626, 0.07735932, 
0.241211  ,\n   0.27668405, 0.16557133, 0.26950228, 0.230201  , 
0.2993518 ,\n   0.0713675 , 0.02841425, 0.04263723, 0.194592  , 
0.2564727 ],\n  dtype=float32), array([0.16798979, 0.10199571, 
0.00094652, 0.28403443, 0.00356805,\n   0.1827622 , 0.06017077, 
0.12363613, 0.14555037, 0.063833  ,\n   0.2784968 , 0.23479551, 
0.11209452, 0.03348672, 0.17435497,\n   0.10784221, 0.1503846 , 
0.08132076, 0.26949698, 0.28150946,\n   0.08847237, 0.07874823, 
0.14240658, 0.22457486, 0.0205071 ,\n   0.24944574, 0.29784793, 
0.0370878 , 0.2375117 , 0.26554942,\n   0.26809436, 0.02403933, 
0.23044948, 0.13133001, 0.29589337,\n   0.05166197, 0.07869713, 
0.10319638, 0.07735932, 0.24121124,\n   0.276684  , 0.16557115, 
0.26950234, 0.230201  , 0.29935163,\n   0.07136726, 0.02841425, 
0.04263711, 0.19459194, 0.25647253],\n  dtype=float32))

E+where  = numpy.allclose
E+and   array([0.16798979, 0.10199571, 0.00094652, 
0.28403443, 0.00356805,\n   0.1827622 , 0.06017077, 0.12363613, 
0.14555037, 0.063833  ,\n   0.2784968 , 0.23479551, 0.11209452, 
0.03348672, 0.17435497,\n   0.10784221, 0.1503846 , 0.08132076, 
0.26949698, 0.28150946,\n   0.08847237, 0.07874823, 0.14

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sebastian Ramacher]

On 2023-02-16 12:24:01 +0100, Michael Prokop wrote:
> * Sebastian Ramacher [Thu Feb 16, 2023 at 09:09:08AM +0100]:
> > On 2023-02-15 13:17:38 -0700, Sam Hartman wrote:
> 
> > > But for example you're not leaving a lot of time for asking programs
> > > like vmdb2 or fai-diskimage to adjust how they call fsck.
> > > If you made this change a few months ago, it would be reasonable to file
> > > bugs against those packages and ask them to adjust how they call
> > > mkfs.ext4.
> 
> > To better understand the impact of this change, I was wondering which
> > tools / image builders in the archive would be affected by this change.
> > I've cloned the bug to vmdb2, but what about others?
> 
> I didn't verify it yet, but AFAICT grml-debootstrap is affected as
> well, since it supports installing older Debian releases from within
> more recent Debian/Grml environments and uses mkfs.ext4 as default.

Thanks, cloned/reassigned the bug also to grml-debootstrap to check
whether it's an issue.

Cheers

> 
> BTW, we had a similar situation already in the past when mkfs.ext4
> of e2fsprogs >=1.43~WIP.2015.05.18-1 enabled the "metadata_csum"
> feature, while this was unsupported on jessie and older releases.
> (grml-debootstrap provides a workaround for this.)
> 
> regards
> -mika-



-- 
Sebastian Ramacher

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sebastian Ramacher]

On 2023-02-16 07:54:52 -0700, Sam Hartman wrote:
> > "Sebastian" == Sebastian Ramacher  writes:
> 
> Sebastian> To better understand the impact of this change, I was
> Sebastian> wondering which tools / image builders in the archive
> Sebastian> would be affected by this change.  I've cloned the bug to
> Sebastian> vmdb2, but what about others?
> 
> It will affect fai-diskimage in the fai package..
> I believe that's used by the cloud team (or was) to create cloud images;
> I don't know if their use case is affected, because I don't know what OS
> they use to create what images.

Also cloned/reassigned the bug to fai, thanks.

Cheers
-- 
Sebastian Ramacher

Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Sebastian Ramacher]

Control: clone -1 -2
Control: reassign -2 fai 6.0
Control: clone -1 -3
Control: reassign -3 grml-debootstrap 0.102

On 2023-02-15 21:04:36 +0100, Sebastian Ramacher wrote:
> Control: clone -1 -2
> Control: reassign -2 vmdb2 0.26-2
> 
> On 2023-02-14 01:01:38 +0100, Daniel Leidert wrote:
> > Hi Steve,
> > 
> > I believe that your fix to grub2 in Sid is not enough to handle
> > #1030939/#1030846.
> > 
> > This problem breaks e.g. vmdb2. I can no longer create a Bullseye
> > system image with vmdb2 on Sid, because the grub-install step in the
> > Bullseye chroot now fails, because the created filesystem (created with
> > e2fsprogs on Sid) cannot be recognized by grub. I have to downgrade
> > e2fsprogs to the version in Testing to get the build going again. It
> > also means that a Bookworm system can never be used to format and
> > debootstrap a Bullseye or Buster system that requires a grub
> > installation.
> > 
> > I guess that the fix applied to grub2 in Sid would have to be applied
> > to grub2 in Bullseye as well (and basically to any grub2 package in any
> > Debian or Ubuntu or Raspbian release supported by debootstrap).
> > 
> > This situation is really messy. It breaks basically all my image builds
> > with vmdb2.
> 
> Regardless of the outcome of #1031325, this issue will need to be fixed
> in vmdb2 eventually. vmdb2, similar to other bootstraping tools, has to
> account for the feature and disable it if necessary for older
> distributions.
> 
> Cloning and reassign to vmdb2.

Based on more feedback from #10313225, I am also cloning and reassigning
this issue to fai and grml-debootstrap. Dear maintainers, please check
whether this issue is relevant for your packages.

Cheers
-- 
Sebastian Ramacher

Processed: Re: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Debian Bug Tracking System]

Processing control commands:

> clone -1 -2
Bug #1030939 [e2fsprogs] e2fsprogs: generates filesystems that grub-install 
doesn't recognize
Bug 1030939 cloned as bug 1031415
> reassign -2 fai 6.0
Bug #1031415 [e2fsprogs] e2fsprogs: generates filesystems that grub-install 
doesn't recognize
Bug reassigned from package 'e2fsprogs' to 'fai'.
No longer marked as found in versions e2fsprogs/1.47.0-1.
Ignoring request to alter fixed versions of bug #1031415 to the same values 
previously set
Bug #1031415 [fai] e2fsprogs: generates filesystems that grub-install doesn't 
recognize
There is no source info for the package 'fai' at version '6.0' with 
architecture ''
Unable to make a source version for version '6.0'
Marked as found in versions 6.0.
> clone -1 -3
Bug #1030939 [e2fsprogs] e2fsprogs: generates filesystems that grub-install 
doesn't recognize
Bug 1030939 cloned as bug 1031416
> reassign -3 grml-debootstrap 0.102
Bug #1031416 [e2fsprogs] e2fsprogs: generates filesystems that grub-install 
doesn't recognize
Bug reassigned from package 'e2fsprogs' to 'grml-debootstrap'.
No longer marked as found in versions e2fsprogs/1.47.0-1.
Ignoring request to alter fixed versions of bug #1031416 to the same values 
previously set
Bug #1031416 [grml-debootstrap] e2fsprogs: generates filesystems that 
grub-install doesn't recognize
Marked as found in versions grml-debootstrap/0.102.

-- 
1030939: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030939
1031415: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031415
1031416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031416
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1031395: marked as pending in tzdata

[Benjamin Drung]

Control: tag -1 pending

Hello,

Bug #1031395 in tzdata reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/glibc-team/tzdata/-/commit/0a5dcdee0e45c5eb9276112925b3e5c89d829b1b


Restore generating /etc/timezone again

In version 2022g-3, the /etc/timezone file has been removed and gets
purged from user's computers. This makes unrelated software break that
relies on this file. Examples are samizdat and ruby-et-orbi.

Restore generating /etc/timezone again for the Debian 12 "Bookworm"
release. Defer the removal to after the bookworm release for the Debian
13 "Trixie" release. Then there will be enough time for mass-bug filing
and fixing the consumers.

This reverts commit 3edcce5955de5ed7b7072402e7565945bc84aea8 ("Remove
/etc/timezone on upgrades as a one-time action").

Closes: #1031376, #1031395
Signed-off-by: Benjamin Drung 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1031395

Processed: Bug#1031395 marked as pending in tzdata

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #1031395 [tzdata] tzdata 2022g-3 removes /etc/timezone while other packages 
depend on it, breaking these packages
Added tag(s) pending.

-- 
1031395: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031395
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1031293: python3-zstandard 0.19.0-3 supports only libzstd 1.5.2

[James Addison]

Package: python3-zstandard
Followup-For: Bug #1031293
X-Debbugs-Cc: b...@debian.org, gregory.sz...@gmail.com

Hi Adrian, Gregory,

Reading the comment above the version check, it seems to indicate that Gregory
isn't particularly enthusiastic to provide support for environments where
there's a mismatch between the python-zstandard module and an unbundled system
zstd library.

Although it 'might work' in practice -- and even though users may be careful
enough to figure out the correct place to complain to even if problems did
occur -- I reckon we should default to upstream's preferences unless there are
good reasons not to (and there might be; they're just not clear to me, if so).

(not only could complaints cause nuisance for upstream, but divergence could,
in my opinion, mean that Debian maintainers would take on more responsibility;
again fine if it makes sense to do that, but it might be helpful to agree why)

Thanks,
James

Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas

[Rebecca N. Palmer]

Control: reassign -1 src:pocl,src:libgpuarray
Control: found -1 pocl/3.1-3
Control: found -1 libgpuarray/0.7.6-13
Control: retitle -1 libgpuarray: i386 test fail with new pocl

The trigger is probably pocl, not clinfo.  I don't yet know whether the 
bug is in pocl or libgpuarray.

Bug#1031395: marked as done (tzdata 2022g-3 removes /etc/timezone while other packages depend on it, breaking these packages)

[Debian Bug Tracking System]

Your message dated Thu, 16 Feb 2023 21:49:40 +
with message-id 
and subject line Bug#1031395: fixed in tzdata 2022g-6
has caused the Debian Bug report #1031395,
regarding tzdata 2022g-3 removes /etc/timezone while other packages depend on 
it, breaking these packages
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1031395: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031395
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tzdata
Version: 2022g-3
Severity: critical

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

in version 2022g-3, the /etc/timezone file has been removed and gets purged
from user's computers. This makes unrelated software break that relies on this
file. Examples are samizdat and ruby-et-orbi. But codesearch.d.o shows more
code-snippets that rely on the existence of that file. There hasn't been any
announcement, any transition, nor any mass-bug filing, leaving multiple
packages broken at this stage. I reported that issue to the release team as
#1031376 and have been asked to open a bug report against tzdata.

Regards, Daniel

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

Kernel: Linux 6.1.0-4-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 tzdata depends on:
ii  debconf [debconf-2.0]  1.5.82

tzdata recommends no packages.

tzdata suggests no packages.

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmPuJ/gACgkQS80FZ8KW
0F2CPQ/+M+A8ok4famSAdTA6Tpjw+ydaYGO2E4+NoQy/diq8KKhFMiOOdduiQji4
6J8no1J7K00eEPgqBko3lQXDJByDuRKHWXD3NFmQJme/pL9Wf4yc7+Zx4QhaBI96
UuUV4M8khv89bA9Bb6TWGUD0OkEOgpze7HAZAQqc8gnaGA2yRkh3JC9DmHe9boQJ
ywODuoFmlPIgyv+Jx8KlXgGdZWWoJpQtm8ol21WeYRtAWxPL+b/FbC1rTrSSEgka
wmw+pa4VbKC8sQIyGQPbJJk0q3PTIqKu1ia59KGKSrCox4cfAvV3EccgyH1xYliI
BRrlSEG1mau1O8jz4fq7oqMVs6W/KMRuj+pSI4n5DEFU9tEJ2G3trysusnS531tj
L++pD/aWISx76rpVzizVQjw1J63pr9sK8sh9/s/jz4s3Ddwiij/HVMaA6t7X+2DU
I3O8jgUq4N6taWw7NcBLDSyFRESqc0BcZYwfsvD7DD0UHSUeZmE5PnetHVWLwqeg
O/ljWDNuIiB61DfVWJr5nfhKXOZYFWXJEOOwDQ5zxWviHlahEGsu3wOQLGW7OA9E
bKUO2IpAOMHX0Oxx752t9eParFqs2yfAX338PGC73w7dCIB5bVowD9SHRCJi6FRX
8HhD5hgq8SsuJEej0eBS63QqN3uqxZKbZsoQgA5aS3eMffxEPRM=
=i0wy
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
Source: tzdata
Source-Version: 2022g-6
Done: Benjamin Drung 

We believe that the bug you reported is fixed in the latest version of
tzdata, 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 1031...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Benjamin Drung  (supplier of updated tzdata 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: Thu, 16 Feb 2023 21:54:13 +0100
Source: tzdata
Built-For-Profiles: noudeb
Architecture: source
Version: 2022g-6
Distribution: unstable
Urgency: medium
Maintainer: GNU Libc Maintainers 
Changed-By: Benjamin Drung 
Closes: 1031211 1031376 1031395
Changes:
 tzdata (2022g-6) unstable; urgency=medium
 .
   * Restore generating /etc/timezone again. The removal of /etc/timezone
 will be done in Debian 13 "Trixie". (Closes: #1031376, #1031395)
   * Update Turkish debconf translation.
 Thanks to Atila KOÇ  (Closes: #1031211)
Checksums-Sha1:
 967c91766e4f35ec94fa32a7ebfffd3c91583e02 2332 tzdata_2022g-6.dsc
 ad872e46cc7d1901a0ea3445cde462287f470adb 116988 tzdata_2022g-6.debian.tar.xz
 3fa33f03cd3f5fcd0b6ecb3b34b963f22f896dd5 7316 tzdata_2022g-6_source.buildinfo
Checksums-Sha256:
 2b07aa4e69fbbfba51b0da5b5ad508a12117b6d116f0b18a47acfc78fb10a591 2332 
tzdata_2022g-6.dsc
 319448a7f371c60e334d7aed1897fd2f323f47a6655d8f67750af1927926856f 116988 
tzdata_2022g-6.debian.tar.xz
 a25ae3ba9dc490824605e8b255bafc47431c6f178ecac092045f1d38869d008f 7316 
tzdata_2022g-6_source.b

Processed: Re: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:pocl,src:libgpuarray
Bug #1031414 [src:clinfo, src:libgpuarray] clinfo breaks libgpuarray 
autopkgtest on i386: numerical deltas
Bug reassigned from package 'src:clinfo, src:libgpuarray' to 
'src:pocl,src:libgpuarray'.
No longer marked as found in versions clinfo/3.0.23.01.25-1 and 
libgpuarray/0.7.6-13.
Ignoring request to alter fixed versions of bug #1031414 to the same values 
previously set
> found -1 pocl/3.1-3
Bug #1031414 [src:pocl,src:libgpuarray] clinfo breaks libgpuarray autopkgtest 
on i386: numerical deltas
Marked as found in versions pocl/3.1-3.
> found -1 libgpuarray/0.7.6-13
Bug #1031414 [src:pocl,src:libgpuarray] clinfo breaks libgpuarray autopkgtest 
on i386: numerical deltas
Marked as found in versions libgpuarray/0.7.6-13.
> retitle -1 libgpuarray: i386 test fail with new pocl
Bug #1031414 [src:pocl,src:libgpuarray] clinfo breaks libgpuarray autopkgtest 
on i386: numerical deltas
Changed Bug title to 'libgpuarray: i386 test fail with new pocl' from 'clinfo 
breaks libgpuarray autopkgtest on i386: numerical deltas'.

-- 
1031414: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031414
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1030767: marked as done (imagemagick: CVE-2022-44267 CVE-2022-44268)

[Debian Bug Tracking System]

Your message dated Thu, 16 Feb 2023 21:35:48 +
with message-id 
and subject line Bug#1030767: fixed in imagemagick 8:6.9.11.60+dfsg-1.6
has caused the Debian Bug report #1030767,
regarding imagemagick: CVE-2022-44267 CVE-2022-44268
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1030767: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030767
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: imagemagick
Version: 8:6.9.11.60+dfsg-1.3
Severity: important
Tags: security
X-Debbugs-Cc: gli...@gmail.com, Debian Security Team 




-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
compare:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
convert:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
composite:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
conjure:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
display:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
identify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
import:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
mogrify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
montage:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
stream:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org

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

Kernel: Linux 5.15.0-52-generic (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages imagemagick depends on:
ii  imagemagick-6.q16  8:6.9.11.60+dfsg-1.3

imagemagick recommends no packages.

imagemagick suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: imagemagick
Source-Version: 8:6.9.11.60+dfsg-1.6
Done: Jeremy Bicha 

We believe that the bug you reported is fixed in the latest version of
imagemagick, 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 1030...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jeremy Bicha  (supplier of updated imagemagick 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: Thu, 16 Feb 2023 16:06:07 -0500
Source: imagemagick
Built-For-Profiles: noudeb
Architecture: source
Version: 8:6.9.11.60+dfsg-1.6
Distribution: unstable
Urgency: high
Maintainer: ImageMagick Packaging Team 

Changed-By: Jeremy Bicha 
Closes: 1030767
Launchpad-Bugs-Fixed: 2004580
Changes:
 imagemagick (8:6.9.11.60+dfsg-1.6) unstable; urgency=high
 .
   * Non-maintainer upload
 .
   [ Moritz Mühlenhoff ]
   * Fix CVE-2022-44267 / CVE-2022-44268 (Closes: #1030767) (LP: #2004580)
Checksums-Sha1:
 b0f5fd11d51400c7ebdac026f0b948eeb9d8ad65 5074 
imagemagick_6.9.11.60+dfsg-1.6.dsc
 44b6a8f8540e6e31e1621bb53ecaeb4496c3027b 253928 
imagemagick_6.9.11.60+dfsg-1.6.debian.tar.xz
 60689009905cbddb97414ec49fe4f33bc47ce34e 12237 
imagemagick_6.9.11.60+dfsg-1.6_source.buildinfo
Checksums-Sha256:
 3e8af11649b1711480ed49e2896d4df034b5a7b505dbad88b1c0b3d5347193df 5074 
imagemagick_6.9.11.60+dfsg-1.6.dsc
 f63bfbe6e513d42ce88578435eade5979c22ca15a5771e5a76a74e29d44bf41f 253928 
imagemagick_6.9.11.60+dfsg-1.6.debian.tar.xz
 28bb43da67634ed8b4cdb95aceac708f454e56584d066378063f010f25c6dfab 12237 
imagemagick_6.9.11.60+dfsg-1.6_source.buildinfo
Files:
 c3d94b1a1c81ec0cf6351ef5d92e4b12 5074 graphics optional 
imagemagick_6.9.11.60+dfsg-1.6.dsc
 c7c14d0ac4cbb512d2bfdf47e35b0223 253928 graphics optional 
imagemagick_6.9.11.60+dfsg-1.6.debian.tar.xz
 178d9a199675268124cb522f2d4dca4a 12237 graphics optional 
imagemagick_6.9.11.60+dfsg-1.6_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETQvhLw5HdtiqzpaW5mx3Wuv+bH0FAmPum8kACgkQ5mx3Wuv+
bH0MZxAAuYvHFlW9nDcvKUYyZ2e4fzxzyT3mDbu8ZlHvlzJOZ8KAVSh0wla9u7VV
BFlOc9/x7aU6usdm

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sebastian Ramacher]

On 2023-02-16 11:44:25 -0700, Sam Hartman wrote:
> > "Adrian" == Adrian Bunk  writes:
> 
> Adrian> On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote:
> >> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
> >> > On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
> >> > > ...  > > Reasons: > > ...  > > - - the change makes it
> >> impossible to create filesystems with this version of > >  
> >> e2fsprogs and then run a grub-install from a target system that
> >> does not cope > >   with that feature; basically breaking the
> >> debootstrap method of installing > >   Debian or Ubuntu onto a
> >> server (violating #4 of the Debian social contract) > > ...  > >
> >> Instead, turning on this feature should be postponed for the next
> >> release cycle > > where a proper transition can be done.  > > ...
> >> > 
> >> > Daniel, you are contradicting yourself when claiming that a
> >> change that > would allegedly violate the Debian social contract
> >> could be done in the > next release cycle.
> >> 
> >> Actually, I'm not.  ...
> 
> Adrian> If not being able to install bullseye from bookworm is a
> Adrian> violation of the Debian social contract, then the same
> Adrian> rationale applies to not being able to install bullseye from
> Adrian> trixie being a violation of the Debian social contract.
> 
> I don't think that arguing about whether this is a social contract
> violation makes a lot of sense.
> It seems fairly clear there is not a consensus about that.
> 
> But if we're going to do that, I suggest that Adrian is putting words
> into Daniel's mouth a bit.
> Daniel has said he believes this situation violates the Social Contract
> #4, but has not explained why.
> Adrian has taken one interpretation.
> I'll propose another: "This violates the social contract because we are
> not prioritizing our users.  Prioritizing users requires that we give
> them notice of incompatible changes."
> I personally think that prioritizing users requires no such thing, and
> that this change is not a violation of the SC.
> But you don't need to take the straw man position Adrian is assuming
> Daniel implies to believe this is a SC violation.
> 
> But seriously, let's give up the whole is this an SC violation part of
> the discussion and move on with constructive aspects:
> 
> * The RT has asked to understand the impact of the change.
> 
> * Several people have proposed better documentation because it's clear
>   that user (and image builder) expectations are not aligned with
>   filesystem maintainer expectations.
> 
> * Anyone could prepare patches to image building software to use mkfs
>   options that will work with bullseye.  You could also try to prepare
>   patches to run mkfs out of a chroot or container of the guest OS for
>   the image.  I appreciate Russ strongly favors this solution, but as
>   someone who has dug into image building tools a fair bit over the
>   years, I think there are significant complexity and performance
>   downsides to that approach.  I also think that changing the mkfs
>   options is more likely to get an unblock than changing the structure
>   of how the tool works.
>   
>   
>   
> * People could try to judge consensus on debian-devel or debian-policy
>   about whether we want a stability guarantee ?+/- 1 release on issues
>   like this.  My suspicion is that you will not find a consensus, and
>   that if the RT decides they don't want this change in bookworm, Ted
>   will change the defaults, and if the RT is unwilling to block, we're
>   left with documentation.
> 
> I think all the above is more productive than arguing about whether this
> is or is not an SC violation.

Thanks for this mail. The discussion on SC#4 is not helping us to reach
a decission on this issue.

Cheers
-- 
Sebastian Ramacher

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Theodore Ts'o]

On Thu, Feb 16, 2023 at 11:45:23AM -0800, Russ Allbery wrote:
> 
> Yes, I'm probably understating the difficulty of making this change in
> practice inside image building software as it's currently constructed.
> 
> My concern about changing mkfs options is that I worry that this would be
> a constantly-changing target that has to be synchronized across multiple
> pieces of software that are not currently well-aligned with file system
> development.  One thing that would make this much easier would be for mkfs
> to support some sort of compatibility level flag that sets all of the
> options, whatever they may be, to their defaults as of some point in the
> past.  Image building software could then pick a conservative default set
> point when building images for older distributions.  That change still has
> to be added to all of the image building software, but it might be easier
> than building a local chroot of the target distribution before using it to
> build the file system the actual installation is going into.

As a long-term solution, one could image changing the various image
creation tools to do something like "mfks.ext4 -T grub2_dumbdown
/dev/XXX", and then have something like the following in
/etc/mke2fs.conf:

[fs_types]
grub2_dumbdown = {
features = ^metadata_csum_seed,^casefold
}

If you care about being able to run fsck.ext4 on really old
distributions, one could even add things like

[fs_types]
jessie_dumbdown = {
features = ^metadata_csum_seed,^metadata_csum
}

etc.

Maintaining this would be a nightmare, and I'd want to ask for help,
since this would be change if we also want to add dumbdown file system
usage types for Ubuntu, and potentially, other Debian derivitives.

Even if we stick with grub2_dumbdown, again, how far back do we go?
Some people have said, "just one release", but I bet there will be
people wanting to create Stretch installer images using a sid
userspace.  So I'd want to have some kind of formal understanding
about what it is that we feel obliged to support.

Given the number of users of the iamge building tools, it's a pretty
specialized use case with not a lot of users, and they can also just
edit /etc/mke2fs.conf to have their favored default.  From my
e2fsprogs maintainers hat on, that's my position --- I interpret
"users" in the Debian Social Contract for the general users, and not
necessarily something that needs to work for every single exotic use
case, especially if they tend to be more of the power users.

If we're not allowed to inconvenience *any* users, then it's hard to
make forward progress.  Certainly some people (including myself) were
inconvenienced for things like /usr-unification and the transition to
systemd.  We went ahead with the transition even though some users
were inconvenienced.  And quite honestly, if a few power users need to
edit /etc/mke2fs.conf to remove metadata_csum_seed because they want
to do something which is *REALLY* not a good idea (using Debian M to
build a file system meant for use on Debian M-X) --- for *ALL* file
systems, not just ext4.  It may be that some users have gotten lucky,
and it mostly works.  But it's a bad idea, and encouraging this bad
practice is eventually going to lead to tears.

But, if the Debian Release team would like to override my position, my
suggestion would be to just change the default for /etc/mke2fs.conf
for *everyone* running Debian bookworm, and with the understanding
that this will be reverted in Debian testing after the next stable
release, and that moving forward, we make it the image building tools
problem if they want to support this highly dubious practice of using
Debian N+X's mkfs to build images for Debian N.  I would strongly
suggest that they figure out which file system features they need to
explicitly turn off for ext4, xfs, btrfs, etc., if they want to build
old distro versions using whatever random software they have installed
on their desktop.

Best release engineering practice is that you use a known, controlled
build environment, and not whatever random package versions might be
on your desktop.  While that might be "inconvenient" when building
packages, we've learned to live with it.  I use sbuild; others might
use pbuild, or their own custom schroot setup.  But I dare say all
responsible people doing release engineering use a known build
environment.  Why should this be any different if you are building
images --- especially images that you expect *your* users or customers
to be depending on?  What are your responsibilities to them?  (Whether
or not the Debian Social contract applies to them or not.)

- Ted

Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas

[Andreas Beckmann]

Control: forwarded -1 https://github.com/pocl/pocl/issues/1176

@elbrus: Why does britney try to migrate clinfo together with pocl?
IMO clinfo should be able to migrate on its own without causing new 
regressions in testing. It does not have any (transitive) dependency on 
pocl.


On Thu, 16 Feb 2023 21:46:31 + "Rebecca N. Palmer" 
 wrote:
The trigger is probably pocl, not clinfo.  I don't yet know whether the 
bug is in pocl or libgpuarray.

or llvm-15

pocl/sid is built against llvm-15, pocl/testing against llvm-14

This also causes a test regression in pyopencl due to numerical 
differences (#1030298). This was attempted to be fixed in pyopencl 
upstream by requiring the numerical difference to be below some 
tolerance level instead of requiring equality, but the numerical delta 
is too large to hide behind that ...


I'm currently trying to debug the code generation delta between llvm-14 
and llvm-15 ...


There could still be a bug in libgpuarray if the failing test is too 
strict by requiring equality of some floating point computations. (Not 
checked.)


Andreas

Processed: Re: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas

[Debian Bug Tracking System]

Processing control commands:

> forwarded -1 https://github.com/pocl/pocl/issues/1176
Bug #1031414 [src:pocl,src:libgpuarray] libgpuarray: i386 test fail with new 
pocl
Set Bug forwarded-to-address to 'https://github.com/pocl/pocl/issues/1176'.

-- 
1031414: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031414
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#972146: /usr/share/applications/mono-runtime-common.desktop: should not handle MIME type by executing arbitrary code

[Gabriel Corona]

Hi,

Thanks for the patch!

This has been fixed in Debian testing and sid. However, stable is still 
affected. I believe it would make sense to port the patch to stable and 
allocate a CVE for this.


Regards,

Gabriel

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Russ Allbery]

"Theodore Ts'o"  writes:

> As a long-term solution, one could image changing the various image
> creation tools to do something like "mfks.ext4 -T grub2_dumbdown
> /dev/XXX", and then have something like the following in
> /etc/mke2fs.conf:

> [fs_types]
> grub2_dumbdown = {
> features = ^metadata_csum_seed,^casefold
> }

This is considerably more specific than what I had in mind, but maybe I'm
misunderstanding the problem.  Here's a slightly more fleshed out version
of what I was thinking:

mke2fs when run without any options has some default upstream-shipped set
of options that it enables (possibly via the upstream-shipped mke2fs.conf,
possibly in the binary, however it works).  Those defaults presumably work
with the kernel and other system tools shipped at the time, due to the
normal compatibility due diligence that you'd naturally do while doing
file system development.

When you make changes to the *defaults* (not just the addition of any
options in general), this presumably is also aligned with what you think
is generally supported by other system tools at the time.

Each time you change the defaults in a way that could be
backward-incompatible, you could capture those new defaults in a
permanently-fixed label of, say, 20230616, which is the defaults on that
date.  Probably in the default /etc/mke2fs.conf.  I don't expect you to
care about what systems they work with, what distributions they work with,
or anything else other than the timeline of when you decided to change the
defaults, something you're presumably already doing as a maintainer.  The
only additional work would be to update these labels with the settings
required to make mke2fs with its current defaults behave compatibly with
whatever the defaults had been at each of those captured points in time.

(And obviously eventually you could drop the really old ones if it made no
sense to keep supporting them, or have some single really-ancient fallback
for really old systems, etc.)

Then, image creators can look in /etc/mke2fs.conf for the timestamp that
most closely aligns with the target system they want to create and use
that group of settings.  If that turns out to be inadequate, they can go
back to a previous date.  Some work on their part is still required, but
from their perspective I think this would have the advantage of not having
to do research to reconstruct what all the options could be and how they
changed and which ones were potentially backward-incompatible, which are
all things you would generally already know and have in mind when you
changed the defaults and thus could capture for them.

That said, this is an architectural stab in the dark and I obviously don't
work on file system development, so maybe this isn't viable for some
reason that I'm not seeing.

-- 
Russ Allbery (r...@debian.org)  

Bug#1031271: marked as done (glib2.0 [experimental]: 2.75.3 FTBFS on big-endian)

[Debian Bug Tracking System]

Your message dated Thu, 16 Feb 2023 23:20:04 +
with message-id 
and subject line Bug#1031271: fixed in glib2.0 2.75.3-2
has caused the Debian Bug report #1031271,
regarding glib2.0 [experimental]: 2.75.3 FTBFS on big-endian
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1031271: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031271
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: glib2.0
Version: 2.75.3-1
Severity: serious
Tags: ftbfs upstream pending
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://gitlab.gnome.org/GNOME/glib/-/issues/2918

See . I'm testing a
solution.

smcv
--- End Message ---
--- Begin Message ---
Source: glib2.0
Source-Version: 2.75.3-2
Done: Jeremy Bicha 

We believe that the bug you reported is fixed in the latest version of
glib2.0, 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 1031...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jeremy Bicha  (supplier of updated glib2.0 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: Thu, 16 Feb 2023 17:58:48 -0500
Source: glib2.0
Built-For-Profiles: noudeb
Architecture: source
Version: 2.75.3-2
Distribution: experimental
Urgency: medium
Maintainer: Debian GNOME Maintainers 

Changed-By: Jeremy Bicha 
Closes: 1031271
Changes:
 glib2.0 (2.75.3-2) experimental; urgency=medium
 .
   [ Simon McVittie ]
   * d/p/array-test-Don-t-rely-on-endianness-of-multi-byte-numbers.patch:
 Add proposed patch to fix FTBFS on big-endian architectures
 (Closes: #1031271)
 .
   [ Jeremy Bicha ]
   * Cherry-pick an implicit conversion change fix
Checksums-Sha1:
 c4d15355eba03235ec94b259fdf4ebd2883e8765 3659 glib2.0_2.75.3-2.dsc
 bdf3f89c51714b419d6a37616d3b619816ee52fb 116844 glib2.0_2.75.3-2.debian.tar.xz
 721e698544983e917141740b62706a9c9a1a7ec0 11458 
glib2.0_2.75.3-2_source.buildinfo
Checksums-Sha256:
 b3aa285cbfde32a75e4364e995091ac12cdcbff8e2fdcc2067f2e0e9610c 3659 
glib2.0_2.75.3-2.dsc
 6e56c0912744603b78ff6c18a629fe5a10b8a48d0f0b6835afb8e7df96651a3a 116844 
glib2.0_2.75.3-2.debian.tar.xz
 70e95728bad2ea8e1e555829993c73b19f4a65b3f4230e3dc0a6ce38ebb213a6 11458 
glib2.0_2.75.3-2_source.buildinfo
Files:
 671dab336ea750e1e38f82a852a5bdc1 3659 libs optional glib2.0_2.75.3-2.dsc
 dca36feb292eee8be70615a4bc8848d2 116844 libs optional 
glib2.0_2.75.3-2.debian.tar.xz
 685a87459e6e8bc3400ed791a21703b0 11458 libs optional 
glib2.0_2.75.3-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETQvhLw5HdtiqzpaW5mx3Wuv+bH0FAmPutWUACgkQ5mx3Wuv+
bH1Slw//S3XEdyPkh5YWPe13WX78vbt5WHc7UP+I5LUJcfHYBQzuFSBbj49piIH1
EKAJx6epq7DKETAIGaAOHXYsXh1OdFTU8Xn/gZn81W5eC6w+++wXTcWxQ4625570
UT/7Hg6tSB9I83u+ochwdAw1yJgzpd9jhu06M+acy7k1VnHn+uTo+W4T18ERhNLu
vdG1TJ/31J1BjqvqIboY+vYufHpNOFtI0k4NuQcomls9KhuEa7V6oW8oq5SCPJJk
DenwzpdRld4OVRANw2ZfUqQVu5rq7ZSLkhHAKcyW3NvbGFQ0Hhhivbv8zsWutrAu
VIrXXW/9mj1FeQam/iUYlds88FBDSsehj+IF3OlzkUYHeFQaM6/ejdgvbWQ6exzD
hmMTDQicMv5cheQfUdZmggwx8yihwQQppY9rk88VguiCq0q8TXvvwpQILIbmcldq
l+7WEJUmJpoeZcmj/Riq3x0wkjIJQopbyoo0bHvUSLjKw9gjkzfaIKjzw8ENfVrl
J2b3W1INScSeVd9lYP0oQZj5y4ULtCuReXOkRcKnhxmwqzug398mOnuYHZYhZVki
fMxGk5Cyxckb+wjQ0YhZb5HoUo5eZpHwKpUwd5HuPd2Jh9KFpl8R+sOvG5qr0cuL
rm3KGB54VUlb+vp+l4JQeWk/5XkqyRgRyKC4Z6er+nMQrQvf7wE=
=Vqcb
-END PGP SIGNATURE End Message ---

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Thu, Feb 16, 2023 at 05:24:04PM -0500, Theodore Ts'o wrote:
>...
> and that moving forward, we make it the image building tools
> problem if they want to support this highly dubious practice of using
> Debian N+X's mkfs to build images for Debian N.
>...

That's what they already have to do for many years.

But it is also our problem when we ship these image building tools,
to ensure that there are bugs against all of them that get fixed
before the release where the change is present.

> Best release engineering practice is that you use a known, controlled
> build environment, and not whatever random package versions might be
> on your desktop.  While that might be "inconvenient" when building
> packages, we've learned to live with it.  I use sbuild; others might
> use pbuild, or their own custom schroot setup.  But I dare say all
> responsible people doing release engineering use a known build
> environment.  Why should this be any different if you are building
> images --- especially images that you expect *your* users or customers
> to be depending on?
>...

controlled != identical to the target

There are different approaches to this problem with different advantages 
and disadvantages.

It is not unreasonable for an image building tool we ship in bookworm to 
use the host tools of a bookworm x86 server to create a Debian image for 
a buster ARM target.

>   - Ted

cu
Adrian

Processed: severity of 1030869 is important

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 1030869 important
Bug #1030869 {Done: Markus Koschany } [tomcat10] tomcat10: 
Catalina won't deploy applications missing class 
jakarta.websocket.DeploymentException
Severity set to 'important' from 'grave'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1030869: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030869
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1031431: debian-installer-netboot-images: FTBFS: Building 20220917, but bookworm has 20230207, failing the build

[Lucas Nussbaum]

Source: debian-installer-netboot-images
Version: 20220917+rebuild1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> if ! ./get-images.sh amd64; then \
>   if [ -n "" ]; then \
>   echo; echo; echo; \
>   echo "Version not found in bookworm, falling back to "; \
>   echo; echo; echo; \
>   sleep 5; \
>   DISTRIBUTION= ./get-images.sh amd64; \
>   else \
>   echo "Version not found in bookworm, no fallback defined"; \
>   exit 1; \
>   fi \
> fi
> --2023-02-17 01:24:15--  
> http://127.0.0.1:12990/debian/dists/bookworm/Release.gpg
> Connecting to 127.0.0.1:12990... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 1601 (1.6K) [text/plain]
> Saving to: ‘/<>/Release.gpg’
> 
>  0K . 100%  177M=0s
> 
> 2023-02-17 01:24:15 (177 MB/s) - ‘/<>/Release.gpg’ saved 
> [1601/1601]
> 
> --2023-02-17 01:24:15--  http://127.0.0.1:12990/debian/dists/bookworm/Release
> Connecting to 127.0.0.1:12990... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 171552 (168K) [text/plain]
> Saving to: ‘/<>/Release’
> 
>  0K .. .. .. .. .. 29%  329M 0s
> 50K .. .. .. .. .. 59%  276M 0s
>100K .. .. .. .. .. 89% 60.2M 0s
>150K .. ...100% 
> 13.9M=0.002s
> 
> 2023-02-17 01:24:15 (69.1 MB/s) - ‘/<>/Release’ saved 
> [171552/171552]
> 
> gpgv: Signature made Thu Feb 16 20:13:29 2023 UTC
> gpgv:using RSA key 0146DC6D4A0B2914BDED34DB648ACFD622F3D138
> gpgv: Good signature from "Debian Archive Automatic Signing Key (10/buster) 
> "
> gpgv: Signature made Thu Feb 16 20:14:07 2023 UTC
> gpgv:using RSA key A7236886F3CCCAAD148A27F80E98404D386FA1D9
> gpgv: Good signature from "Debian Archive Automatic Signing Key (11/bullseye) 
> "
> --2023-02-17 01:24:15--  
> http://127.0.0.1:12990/debian/dists/bookworm/main/binary-amd64/Packages.xz
> Connecting to 127.0.0.1:12990... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 9040064 (8.6M) [text/plain]
> Saving to: ‘amd64.Packages.xz’
> 
>  0K .. .. .. .. ..  0%  191M 0s
> 50K .. .. .. .. ..  1% 83.8M 0s
>100K .. .. .. .. ..  1%  109M 0s
>150K .. .. .. .. ..  2% 21.6M 0s
>200K .. .. .. .. ..  2% 51.3M 0s
>250K .. .. .. .. ..  3%  110M 0s
>300K .. .. .. .. ..  3%  113M 0s
>350K .. .. .. .. ..  4%  114M 0s
>400K .. .. .. .. ..  5%  100M 0s
>450K .. .. .. .. ..  5% 89.4M 0s
>500K .. .. .. .. ..  6% 99.9M 0s
>550K .. .. .. .. ..  6% 73.4M 0s
>600K .. .. .. .. ..  7%  174M 0s
>650K .. .. .. .. ..  7%  120M 0s
>700K .. .. .. .. ..  8%  133M 0s
>750K .. .. .. .. ..  9% 13.4M 0s
>800K .. .. .. .. ..  9%  102M 0s
>850K .. .. .. .. .. 10%  141M 0s
>900K .. .. .. .. .. 10%  106M 0s
>950K .. .. .. .. .. 11%  161M 0s
>   1000K .. .. .. .. .. 11% 47.5M 0s
>   1050K .. .. .. .. .. 12%  132M 0s
>   1100K .. .. .. .. .. 13% 23.4M 0s
>   1150K .. .. .. .. .. 13%  118M 0s
>   1200K .. .. .. .. .. 14%  124M 0s
>   1250K .. .. .. .. .. 14% 36.5M 0s
>   1300K .. .. .. .. .

Bug#1031432: mediaelement: FTBFS: FileNotFoundError: [Errno 2] No such file or directory: '../build/mediaelement.min.js'

[Lucas Nussbaum]

Source: mediaelement
Version: 2.15.1+dfsg-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> cd /<>/src && python3 ./Builder.py
> java.util.MissingResourceException: Can't find bundle for base name 
> com.google.javascript.rhino.head.resources.Messages, locale en
>   at 
> java.base/java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2045)
>   at 
> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1683)
>   at 
> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1586)
>   at 
> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1549)
>   at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:932)
>   at 
> com.google.javascript.rhino.head.ScriptRuntime$DefaultMessageProvider.getMessage(ScriptRuntime.java:4521)
>   at 
> com.google.javascript.rhino.head.ScriptRuntime.getMessage(ScriptRuntime.java:4501)
>   at 
> com.google.javascript.rhino.head.ScriptRuntime.getMessage0(ScriptRuntime.java:4446)
>   at 
> com.google.javascript.jscomp.RhinoErrorReporter.(RhinoErrorReporter.java:84)
>   at 
> com.google.javascript.jscomp.RhinoErrorReporter.(RhinoErrorReporter.java:32)
>   at 
> com.google.javascript.jscomp.RhinoErrorReporter$OldRhinoErrorReporter.(RhinoErrorReporter.java:162)
>   at 
> com.google.javascript.jscomp.RhinoErrorReporter$OldRhinoErrorReporter.(RhinoErrorReporter.java:158)
>   at 
> com.google.javascript.jscomp.RhinoErrorReporter.forOldRhino(RhinoErrorReporter.java:119)
>   at com.google.javascript.jscomp.Compiler.(Compiler.java:176)
>   at 
> com.google.javascript.jscomp.CommandLineRunner.createCompiler(CommandLineRunner.java:858)
>   at 
> com.google.javascript.jscomp.AbstractCommandLineRunner.doRun(AbstractCommandLineRunner.java:741)
>   at 
> com.google.javascript.jscomp.AbstractCommandLineRunner.run(AbstractCommandLineRunner.java:380)
>   at 
> com.google.javascript.jscomp.CommandLineRunner.main(CommandLineRunner.java:980)
> java.util.MissingResourceException: Can't find bundle for base name 
> com.google.javascript.rhino.head.resources.Messages, locale en
>   at 
> java.base/java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2045)
>   at 
> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1683)
>   at 
> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1586)
>   at 
> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1549)
>   at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:932)
>   at 
> com.google.javascript.rhino.head.ScriptRuntime$DefaultMessageProvider.getMessage(ScriptRuntime.java:4521)
>   at 
> com.google.javascript.rhino.head.ScriptRuntime.getMessage(ScriptRuntime.java:4501)
>   at 
> com.google.javascript.rhino.head.ScriptRuntime.getMessage0(ScriptRuntime.java:4446)
>   at 
> com.google.javascript.jscomp.RhinoErrorReporter.(RhinoErrorReporter.java:84)
>   at 
> com.google.javascript.jscomp.RhinoErrorReporter.(RhinoErrorReporter.java:32)
>   at 
> com.google.javascript.jscomp.RhinoErrorReporter$OldRhinoErrorReporter.(RhinoErrorReporter.java:162)
>   at 
> com.google.javascript.jscomp.RhinoErrorReporter$OldRhinoErrorReporter.(RhinoErrorReporter.java:158)
>   at 
> com.google.javascript.jscomp.RhinoErrorReporter.forOldRhino(RhinoErrorReporter.java:119)
>   at com.google.javascript.jscomp.Compiler.(Compiler.java:176)
>   at 
> com.google.javascript.jscomp.CommandLineRunner.createCompiler(CommandLineRunner.java:858)
>   at 
> com.google.javascript.jscomp.AbstractCommandLineRunner.doRun(AbstractCommandLineRunner.java:741)
>   at 
> com.google.javascript.jscomp.AbstractCommandLineRunner.run(AbstractCommandLineRunner.java:380)
>   at 
> com.google.javascript.jscomp.CommandLineRunner.main(CommandLineRunner.java:980)
> building MediaElement.js
> building MediaElementPlayer.js
> Minifying JavaScript
> Traceback (most recent call last):
>   File "/<>/src/./Builder.py", line 101, in 
> addHeader('js/me-header.js', '../build/' + me_filename + '.min.js')
>   File "/<>/src/./Builder.py", line 89, in addHeader
> tmp_file = open(filename)
>^^
> FileNotFoundError: [Errno 2] No such file or directory: 
> '../build/mediaelement.min.js'
> make[

Bug#1031434: conda-package-handling: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Lucas Nussbaum]

Source: conda-package-handling
Version: 2.0.1-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
>  debian/rules binary
> dh binary --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:240: python3.11 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:240: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.11/build/conda_package_handling
> copying src/conda_package_handling/__init__.py -> 
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling
> copying src/conda_package_handling/tarball.py -> 
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling
> copying src/conda_package_handling/cli.py -> 
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling
> copying src/conda_package_handling/__main__.py -> 
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling
> copying src/conda_package_handling/api.py -> 
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling
> copying src/conda_package_handling/interface.py -> 
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling
> copying src/conda_package_handling/exceptions.py -> 
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling
> copying src/conda_package_handling/conda_fmt.py -> 
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling
> copying src/conda_package_handling/validate.py -> 
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling
> copying src/conda_package_handling/streaming.py -> 
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling
> copying src/conda_package_handling/utils.py -> 
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11/build; 
> python3.11 -m pytest tests
> = test session starts 
> ==
> platform linux -- Python 3.11.2, pytest-7.2.1, pluggy-1.0.0+repack
> rootdir: /<>, configfile: setup.cfg
> plugins: mock-3.8.2
> collected 39 items / 1 error
> 
>  ERRORS 
> 
>  ERROR collecting .pybuild/cpython3_3.11/build/tests/test_interface.py 
> _
> ImportError while importing test module 
> '/<>/.pybuild/cpython3_3.11/build/tests/test_interface.py'.
> Hint: make sure your test modules/packages have valid Python names.
> Traceback:
> /usr/lib/python3.11/importlib/__init__.py:126: in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
> tests/test_interface.py:12: in 
> from conda_package_handling.conda_fmt import CondaFormat_v2
> conda_package_handling/conda_fmt.py:15: in 
> import zstandard
> /usr/lib/python3/dist-packages/zstandard/__init__.py:39: in 
> from .backend_c import *  # type: ignore
> E   ImportError: zstd C API versions mismatch; Python bindings were not 
> compiled/linked against expected zstd version (10504 returned by the lib, 
> 10502 hardcoded in zstd headers, 10502 hardcoded in the cext)
> === warnings summary 
> ===
> ../../../../../../usr/lib/python3/dist-packages/_pytest/config/__init__.py:1294
>   /usr/lib/python3/dist-packages/_pytest/config/__init__.py:1294: 
> PytestConfigWarning: Unknown config option: env
>   
> self._warn_or_fail_if_strict(f"Unknown config option: {key}\n")
> 
> ../../../../../../usr/lib/python3/dist-packages/conda_package_streaming/package_streaming.py:19
>   
> /usr/lib/python3/dist-packages/conda_package_streaming/package_streaming.py:19:
>  UserWarning: zstandard could not be imported. Running without .conda support.
> warnings.warn("zstandard could not be imported. Running without .conda 
> support.")
> 
> conda_package_handling/api.py:29
>   
> /<>/.pybuild/cpython3_3.11/build/conda_package_handling/api.py:29:
>  UserWarning: Install zstandard Python bindings for .conda support
> _warnings.warn("Install zstandard Python bindings for .conda support")
> 
> -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
> - generated xml file: /<>/.pybuild/cpython3_3.11/build/junit.xml 
> -
> === short test summary info 
> ===

Bug#1031435: python-inotify: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Lucas Nussbaum]

Source: python-inotify
Version: 0.2.10-4
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
>  debian/rules binary
> dh binary --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:240: python3.11 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:240: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.11_python-inotify/build/inotify
> copying inotify/__init__.py -> 
> /<>/.pybuild/cpython3_3.11_python-inotify/build/inotify
> copying inotify/test_support.py -> 
> /<>/.pybuild/cpython3_3.11_python-inotify/build/inotify
> copying inotify/adapters.py -> 
> /<>/.pybuild/cpython3_3.11_python-inotify/build/inotify
> copying inotify/constants.py -> 
> /<>/.pybuild/cpython3_3.11_python-inotify/build/inotify
> copying inotify/library.py -> 
> /<>/.pybuild/cpython3_3.11_python-inotify/build/inotify
> copying inotify/calls.py -> 
> /<>/.pybuild/cpython3_3.11_python-inotify/build/inotify
> running egg_info
> creating inotify.egg-info
> writing inotify.egg-info/PKG-INFO
> writing dependency_links to inotify.egg-info/dependency_links.txt
> writing top-level names to inotify.egg-info/top_level.txt
> writing manifest file 'inotify.egg-info/SOURCES.txt'
> reading manifest file 'inotify.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> adding license file 'LICENSE'
> writing manifest file 'inotify.egg-info/SOURCES.txt'
> /usr/lib/python3/dist-packages/setuptools/command/build_py.py:202: 
> SetuptoolsDeprecationWarning: Installing 'inotify.resources' as data is 
> deprecated, please list it in `packages`.
> !!
> 
> 
> 
> # Package would be ignored #
> 
> Python recognizes 'inotify.resources' as an importable package,
> but it is not listed in the `packages` configuration of setuptools.
> 
> 'inotify.resources' has been automatically added to the distribution only
> because it may contain data files, but this behavior is likely to change
> in future versions of setuptools (and therefore is considered deprecated).
> 
> Please make sure that 'inotify.resources' is included as a package by 
> using
> the `packages` configuration field or the proper discovery methods
> (for example by using `find_namespace_packages(...)`/`find_namespace:`
> instead of `find_packages(...)`/`find:`).
> 
> You can read more about "package discovery" and "data files" on setuptools
> documentation page.
> 
> 
> !!
> 
>   check.warn(importable)
> creating 
> /<>/.pybuild/cpython3_3.11_python-inotify/build/inotify/resources
> copying inotify/resources/README.rst -> 
> /<>/.pybuild/cpython3_3.11_python-inotify/build/inotify/resources
> copying inotify/resources/requirements.txt -> 
> /<>/.pybuild/cpython3_3.11_python-inotify/build/inotify/resources
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:240: cd 
> /<>/.pybuild/cpython3_3.11_python-inotify/build; python3.11 -m 
> pytest -k 'not test__cycle' --reruns 3 --reruns-delay 1
> = test session starts 
> ==
> platform linux -- Python 3.11.2, pytest-7.2.1, pluggy-1.0.0+repack
> rootdir: /<>
> plugins: rerunfailures-10.2
> collected 9 items / 3 deselected / 6 selected
> 
> tests/test_inotify.py .s...R 
> [100%]R [100%]R [100%]F [100%]
> 
> === FAILURES 
> ===
>  TestInotifyTree.test__renames 
> _
> 
> self = 
> 
> def test__renames(self):
> 
> # Since we're not reading the events one at a time in a loop and
> # removing or renaming folders will flush any queued events, we have 
> to
> # group things in order to check things first before such operations.
> 
> with inotify.test_support.temp_path() as path:
> i = inotify.adapters.InotifyTree(path)
> 
> old_path = os.path.join(path, 'old_folder')
> new_path = os.path.joi

Bug#1031436: ubuntu-dev-tools: FTBFS: make[1]: *** [debian/rules:10: override_dh_auto_test] Error 1

[Lucas Nussbaum]

Source: ubuntu-dev-tools
Version: 0.192
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> ./run-linters
> Running black...
> --- build/scripts-3.11/grep-merges2023-02-17 01:30:48.860507 +
> +++ build/scripts-3.11/grep-merges2023-02-17 01:30:49.805230 +
> @@ -52,11 +52,10 @@
>  "universe",
>  "universe-manual",
>  "multiverse",
>  "multiverse-manual",
>  ):
> -
>  url = f"https://merges.ubuntu.com/{component}.json";
>  try:
>  headers, page = Http().request(url)
>  except HttpLib2Error as e:
>  Logger.exception(e)
> would reformat build/scripts-3.11/grep-merges
> --- /<>/ubuntutools/misc.py  2023-02-01 11:45:15 +
> +++ /<>/ubuntutools/misc.py  2023-02-17 01:30:49.837949 +
> @@ -242,11 +242,11 @@
>  filesize = path.stat().st_size
>  if size and size != filesize:
>  Logger.error("File %s incorrect size, got %s expected %s", path, 
> filesize, size)
>  return False
>  
> -for (alg, checksum) in checksums.items():
> +for alg, checksum in checksums.items():
>  hash_ = hashlib.new(alg)
>  with path.open("rb") as f:
>  while True:
>  block = f.read(hash_.block_size)
>  if len(block) == 0:
> would reformat /<>/ubuntutools/misc.py
> --- grep-merges   2023-02-01 11:45:15 +
> +++ grep-merges   2023-02-17 01:30:50.160956 +
> @@ -52,11 +52,10 @@
>  "universe",
>  "universe-manual",
>  "multiverse",
>  "multiverse-manual",
>  ):
> -
>  url = f"https://merges.ubuntu.com/{component}.json";
>  try:
>  headers, page = Http().request(url)
>  except HttpLib2Error as e:
>  Logger.exception(e)
> would reformat grep-merges
> --- build/scripts-3.11/ubuntu-upload-permission   2023-02-17 
> 01:30:48.864507 +
> +++ build/scripts-3.11/ubuntu-upload-permission   2023-02-17 
> 01:30:50.219040 +
> @@ -89,11 +89,10 @@
>  component = spph.getComponent()
>  if args.list_uploaders and (
>  pocket != "Release"
>  or series.status in ("Experimental", "Active Development", 
> "Pre-release Freeze")
>  ):
> -
>  component_uploader = 
> archive.getUploadersForComponent(component_name=component)[0]
>  Logger.info("All upload permissions for %s:", args.package)
>  Logger.info("")
>  Logger.info("Component (%s)", component)
>  Logger.info("%s", "=" * len(component))
> would reformat build/scripts-3.11/ubuntu-upload-permission
> --- ubuntu-upload-permission  2023-02-01 11:45:15 +
> +++ ubuntu-upload-permission  2023-02-17 01:30:50.476410 +
> @@ -89,11 +89,10 @@
>  component = spph.getComponent()
>  if args.list_uploaders and (
>  pocket != "Release"
>  or series.status in ("Experimental", "Active Development", 
> "Pre-release Freeze")
>  ):
> -
>  component_uploader = 
> archive.getUploadersForComponent(component_name=component)[0]
>  Logger.info("All upload permissions for %s:", args.package)
>  Logger.info("")
>  Logger.info("Component (%s)", component)
>  Logger.info("%s", "=" * len(component))
> would reformat ubuntu-upload-permission
> --- /<>/ubuntutools/lp/lpapicache.py 2023-02-01 11:45:15 
> +
> +++ /<>/ubuntutools/lp/lpapicache.py 2023-02-17 
> 01:30:50.905615 +
> @@ -410,11 +410,11 @@
>  def binaryFileProperties(self, filename_or_url):
>  if not self._binary_prop_dict:
>  urls = self.binaryFileUrls()
>  props = self.getBinaryProperties()
>  self._binary_prop_dict = dict(zip(urls, props))
> -for (key, value) in copy(self._binary_prop_dict).items():
> +for key, value in copy(self._binary_prop_dict).items():
>  filename = os.path.basename(urlparse(key).path)
>  self._binary_prop_dict[filename] = value
>  return self._binary_prop_dict.get(filename_or_url, {})
>  
>  

Bug#1031433: diffoscope: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Lucas Nussbaum]

Source: diffoscope
Version: 235
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[2]: Entering directory '/<>/doc'
> { cat diffoscope.h2m.0; cat ../README.rst | \
>   sed -e '/^\.\. raw:: /d' -e '/^\.\. image:: /d' -e '/ :target: /d' | tee 
> out.txt | \
>   rst2man -q --no-doc-title | \
>   sed -e 's,^ \\- ,,' -e 's,^\[,\\[char91],g' -e 's,\.TH *"" "" "",,g' \
>   -e 's,bin/diffoscope,diffoscope,g' \
>   -e 's,\.SH \(.*\),[\1],g' -e 's,\[diffoscope\],[DESCRIPTION],gi'; } > 
> "diffoscope.h2m"
> help2man --version-string=$(cd .. && python3 setup.py -V) ../bin/diffoscope 
> -N --include="diffoscope.h2m" | \
>   sed -e '/end_of_description_header/,/positional arguments/{d}' > 
> "diffoscope.1"
> make[2]: Leaving directory '/<>/doc'
> make[1]: Leaving directory '/<>'
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild pybuild:307: flake8 --config=/dev/null --select=F821
> I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11/build; 
> python3.11 -m pytest -vv -r sxX -l --cov=diffoscope --cov-report=term-missing 
> --cov-report=html
> = test session starts 
> ==
> platform linux -- Python 3.11.2, pytest-7.2.1, pluggy-1.0.0+repack -- 
> /usr/bin/python3.11
> cachedir: .pytest_cache
> rootdir: /<>, configfile: pytest.ini
> plugins: cov-4.0.0
> collecting ... collected 711 items / 1 skipped
> 
> tests/test_diff_mask.py::test_none PASSED[  
> 0%]
> tests/test_diff_mask.py::test_all PASSED [  
> 0%]
> tests/test_diff_mask.py::test_specific PASSED[  
> 0%]
> tests/test_difference.py::test_too_much_input_for_diff PASSED[  
> 0%]
> tests/test_difference.py::test_too_long_diff_block_lines PASSED  [  
> 0%]
> tests/test_difference.py::test_size_updates PASSED   [  
> 0%]
> tests/test_difference.py::test_traverse_heapq PASSED [  
> 0%]
> tests/test_difference.py::test_non_str_arguments_to_source1_source2 PASSED [  
> 1%]
> tests/test_difference.py::test_adjust_diff_context PASSED[  
> 1%]
> tests/test_excludes.py::test_none PASSED [  
> 1%]
> tests/test_excludes.py::test_all PASSED  [  
> 1%]
> tests/test_excludes.py::test_specific PASSED [  
> 1%]
> tests/test_excludes.py::test_specific_case PASSED[  
> 1%]
> tests/test_excludes.py::test_multiple PASSED [  
> 1%]
> tests/test_excludes.py::test_nomatch PASSED  [  
> 2%]
> tests/test_excludes.py::test_wildcard PASSED [  
> 2%]
> tests/test_main.py::test_non_existing_files PASSED   [  
> 2%]
> tests/test_main.py::test_non_existing_left_with_new_file PASSED  [  
> 2%]
> tests/test_main.py::test_non_existing_right_with_new_file PASSED [  
> 2%]
> tests/test_main.py::test_non_existing_files_with_new_file PASSED [  
> 2%]
> tests/test_main.py::test_remove_temp_files_on_sigterm PASSED [  
> 2%]
> tests/test_main.py::test_ctrl_c_handling PASSED  [  
> 3%]
> tests/test_main.py::test_no_differences PASSED   [  
> 3%]
> tests/test_main.py::test_no_differences_directories PASSED   [  
> 3%]
> tests/test_main.py::test_list_tools PASSED   [  
> 3%]
> tests/test_main.py::test_list_missing_tools PASSED   [  
> 3%]
> tests/test_main.py::test_profiling PASSED[  
> 3%]
> tests/test_main.py::test_non_unicode_filename PASSED [  
> 3%]
> tests/test_main.py::test_help PASSED [  
> 4%]
> tests/test_main.py::test_usage PASSED[  
> 4%]
> tests/test_presenters.py::test_text_option_is_default PASSED [  
> 4%]
> tests/test_presenters.py::test_text_proper_indentation PASSED[  
> 4%]
> tests/test_presenters.py::test_text_option_color PASSED  [  
> 4%]
> tests/test_presenters.py::test_text_option_with_file PASSED  [  
&

Bug#1031437: pandas: FTBFS: /usr/lib/python3/dist-packages/dateutil/zoneinfo/__init__.py:26: UserWarning: I/O error(2): No such file or directory

[Lucas Nussbaum]

Source: pandas
Version: 1.5.3+dfsg-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> _ test_expanding_apply_consistency_sum_nans[all_data17-2-sum] 
> __
> request =  test_expanding_apply_consistency_sum_nans[all_data17-2-sum]>>
> all_data =  0
> 0  NaN
> 1  1.0
> 2  NaN
> 3  3.0
> 4  2.0, min_periods = 2
> f = 
> 
> @pytest.mark.parametrize("f", [lambda v: Series(v).sum(), np.nansum, 
> np.sum])
> def test_expanding_apply_consistency_sum_nans(request, all_data, 
> min_periods, f):
> if f is np.sum:
> if not no_nans(all_data) and not (
> all_na(all_data) and not all_data.empty and min_periods > 0
> ):
> request.node.add_marker(
> pytest.mark.xfail(reason="np.sum has different behavior 
> with NaNs")
> )
> expanding_f_result = all_data.expanding(min_periods=min_periods).sum()
> expanding_apply_f_result = 
> all_data.expanding(min_periods=min_periods).apply(
> func=f, raw=True
> )
> >   tm.assert_equal(expanding_f_result, expanding_apply_f_result)
> 
> pandas/tests/window/moments/test_moments_consistency_expanding.py:29: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> pandas/_libs/testing.pyx:52: in pandas._libs.testing.assert_almost_equal
> cpdef assert_almost_equal(a, b,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> 
> >   raise_assert_detail(obj, msg, lobj, robj, index_values=index_values)
> E   AssertionError: DataFrame.iloc[:, 0] (column name="0") are different
> E   
> E   DataFrame.iloc[:, 0] (column name="0") values are different (40.0 %)
> E   [index]: [0, 1, 2, 3, 4]
> E   [left]:  [nan, nan, nan, 4.0, 6.0]
> E   [right]: [nan, nan, nan, nan, nan]
> 
> pandas/_libs/testing.pyx:167: AssertionError
> - generated xml file: 
> /<>/.pybuild/cpython3_3.11/build/test-data.xml -
> = slowest 30 durations 
> =
> 0.69s call 
> .pybuild/cpython3_3.11/build/pandas/tests/window/test_apply.py::test_center_reindex_frame[False]
> 0.32s call 
> .pybuild/cpython3_3.11/build/pandas/tests/groupby/test_timegrouper.py::TestGroupBy::test_timegrouper_with_reg_groups
> 0.24s call 
> .pybuild/cpython3_3.11/build/pandas/tests/window/test_apply.py::test_time_rule_frame[False]
> 0.18s call 
> .pybuild/cpython3_3.11/build/pandas/tests/window/test_apply.py::test_frame[False]
> 0.12s call 
> .pybuild/cpython3_3.11/build/pandas/tests/groupby/test_timegrouper.py::TestGroupBy::test_groupby_with_timegrouper
> 0.07s call 
> .pybuild/cpython3_3.11/build/pandas/tests/groupby/test_timegrouper.py::TestGroupBy::test_groupby_apply_timegrouper_with_nat_apply_squeeze
> 0.07s call 
> .pybuild/cpython3_3.11/build/pandas/tests/window/test_apply.py::test_center_reindex_series[False]
> 0.06s call 
> .pybuild/cpython3_3.11/build/pandas/tests/window/test_apply.py::test_min_periods[False-None-0]
> 0.06s call 
> .pybuild/cpython3_3.11/build/pandas/tests/window/test_apply.py::test_min_periods[False-1-0]
> 0.05s call 
> .pybuild/cpython3_3.11/build/pandas/tests/window/test_apply.py::test_nans[False]
> 0.04s call 
> .pybuild/cpython3_3.11/build/pandas/tests/window/test_apply.py::test_time_rule_frame[True]
> 0.04s call 
> .pybuild/cpython3_3.11/build/pandas/tests/window/test_apply.py::test_center_reindex_frame[True]
> 0.04s call 
> .pybuild/cpython3_3.11/build/pandas/tests/groupby/test_timegrouper.py::TestGroupBy::test_timegrouper_get_group
> 0.03s call 
> .pybuild/cpython3_3.11/build/pandas/tests/window/test_apply.py::test_min_periods[False-2-0]
> 0.03s call 
> .pybuild/cpython3_3.11/build/pandas/tests/groupby/test_timegrouper.py::TestGroupBy::test_timegrouper_with_reg_groups_freq[A]
> 0.03s call 
> .pybuild/cpython3_3.11/build/pandas/tests/groupby/test_timegrouper.py::TestGroupBy::test_timegrouper_with_reg_groups_freq[D]
> 0.03s call 
> .pybuild/cpython3_3.11/build/pandas/tests/groupby/test_timegrouper.py::TestGroupBy::test_timegrouper_with_reg_groups_freq[M]
> 0.03s call 
> .pybuild/cpython3_3.11/build/pandas/tests/groupby/test_timegrouper.py::TestGroupBy::test_groupby_groups_datetimeindex_tz
> 0.03s setup
> .pybuild/cpython3_3.11/build/pandas/tests/groupby/test_timegrouper.py::TestGroupBy::test_groupby_apply_timegrouper_with_nat_dict_returns
> 0.03s cal

Bug#1031439: gcc-sh-elf: FTBFS: make[6]: *** No rule to make target '../libsframe/libsframe.la', needed by 'libbfd.la'. Stop.

[Lucas Nussbaum]

Source: gcc-sh-elf
Version: 4
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[6]: Entering directory '/<>/bld/bfd/po'
> make[6]: Nothing to be done for 'all'.
> make[6]: Leaving directory '/<>/bld/bfd/po'
> /bin/sh ./libtool --tag=CC --tag=disable-static  --mode=link 
> x86_64-linux-gnu-gcc -Wall -fcf-protection -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -Wc,-static-libgcc  -module -avoid-version -bindir /usr/libexec/gcc/sh-elf/12 
> -Wl,--version-script=../../src/lto-plugin/lto-plugin.map-Xcompiler 
> '-static-libstdc++' -Xcompiler '-static-libgcc' '-Wl,-z,relro' '-Wl,-z,now' 
> -o liblto_plugin.la -rpath /usr/libexec/gcc/sh-elf/12 lto-plugin.lo  
> -Wc,../libiberty/pic/libiberty.a 
> yes
> checking whether the compiler supports the __inline keyword... make[6]: 
> Entering directory '/<>/bld/bfd'
> rm -f bfd-tmp.h
> cp bfd-in3.h bfd-tmp.h
> /bin/sh ../../src/bfd/../move-if-change bfd-tmp.h bfd.h
> rm -f bfd-tmp.h
> touch stmp-bfd-h
> rm -f tofiles
> make[6]: *** No rule to make target '../libsframe/libsframe.la', needed by 
> 'libbfd.la'.  Stop.
> make[6]: *** Waiting for unfinished jobs
> f=""; \
> for i in elf32-sh.lo elf-vxworks.lo elf32.lo elf.lo elflink.lo elf-attrs.lo 
> elf-strtab.lo elf-eh-frame.lo elf-sframe.lo dwarf1.lo dwarf2.lo coff-sh.lo 
> cofflink.lo coffgen.lo elf32-gen.lo plugin.lo cpu-sh.lo  archive64.lo ; do \
>   case " $f " in \
> *" $i "*) ;; \
> *) f="$f $i" ;; \
>   esac ; \
> done ; \
> echo $f > tofiles
> /bin/sh ../../src/bfd/../move-if-change tofiles ofiles
> libtool: link: x86_64-linux-gnu-gcc -shared  -fPIC -DPIC  .libs/lto-plugin.o  
>   -static-libgcc -Wl,--version-script=../../src/lto-plugin/lto-plugin.map 
> -static-libstdc++ -static-libgcc -Wl,-z -Wl,relro -Wl,-z -Wl,now 
> ../libiberty/pic/libiberty.a   -Wl,-soname -Wl,liblto_plugin.so -o 
> .libs/liblto_plugin.so
> touch stamp-ofiles
> rm -f libcpp.a
> make[6]: Leaving directory '/<>/bld/bfd'
> x86_64-linux-gnu-ar cru libcpp.a charset.o directives.o errors.o expr.o 
> files.o identifiers.o init.o lex.o line-map.o macro.o mkdeps.o pch.o symtab.o 
> traditional.o
> make[5]: *** [Makefile:1955: all-recursive] Error 1


The full build log is available from:
http://qa-logs.debian.net/2023/02/16/gcc-sh-elf_4_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230216;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20230216&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=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.

Bug#1031440: open-vm-tools: FTBFS: fuse_config.h:42: error: "PACKAGE_VERSION" redefined [-Werror]

[Lucas Nussbaum]

Source: open-vm-tools
Version: 2:12.1.5-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" 
> -DPACKAGE_VERSION=\"12.1.5\" -DPACKAGE_STRING=\"open-vm-tools\ 12.1.5\" 
> -DPACKAGE_BUGREPORT=\"open-vm-tools-de...@lists.sourceforge.net\" 
> -DPACKAGE_URL=\"\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 
> -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TIME_H=1 -DSTDC_HEADERS=1 
> -DPACKAGE=\"open-vm-tools\" -DVERSION=\"12.1.5\" -DHAVE_DLFCN_H=1 
> -DLT_OBJDIR=\".libs/\" -DHAVE_FUSE3=1 -DFUSE_USE_VERSION=35 
> -DHAVE_X11_SM_SMLIB_H=1 -DHAVE_X11_ICE_ICELIB_H=1 
> -DHAVE_X11_EXTENSIONS_XCOMPOSITE_H=1 -DHAVE_DLOPEN=1 -DHAVE_ECVT=1 
> -DHAVE_FCVT=1 -DNO_DNET=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 
> -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 
> -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 
> -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 
> -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -I.   
> -I/<>/open-vm-tools/lib/include 
> -I/<>/open-vm-tools/lib/include -Wdate-time -D_FORTIFY_SOURCE=2 
> -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -DUSE_VGAUTH  -DNO_ICU -DVMX86_TOOLS 
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 
> -D_BSD_SOURCE -D_SVID_SOURCE -D_DEFAULT_SOURCE -DENABLE_RESOLUTIONKMS 
> -Dvmblock_fuse -U_XOPEN_SOURCE -D_XOPEN_SOURCE=600 -DUSERLEVEL 
> -D_FILE_OFFSET_BITS=64 -I/usr/include/fuse3  -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I../modules/shared/vmblock -I. 
> -fPIC -Wno-error=deprecated-declarations -Wno-error=address-of-packed-member 
> -Wno-nonnull -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror 
> -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas 
> -Wno-uninitialized -Wno-deprecated-declarations -Wno-unused-const-variable 
> -Wno-unused-but-set-variable -c -o stubs.o `test -f 
> '../modules/shared/vmblock/stubs.c' || echo 
> './'`../modules/shared/vmblock/stubs.c
> In file included from /usr/include/fuse3/fuse_common.h:17,
>  from /usr/include/fuse3/fuse.h:19,
>  from fsops.h:46,
>  from main.c:28:
> /usr/include/fuse3/fuse_config.h:42: error: "PACKAGE_VERSION" redefined 
> [-Werror]
>42 | #define PACKAGE_VERSION "3.13.1"
>   | 
> : note: this is the location of the previous definition
> cc1: all warnings being treated as errors
> make[2]: *** [Makefile:582: main.o] Error 1


The full build log is available from:
http://qa-logs.debian.net/2023/02/16/open-vm-tools_12.1.5-3_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230216;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20230216&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=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.

Bug#1031441: ruby-github-api: FTBFS: ERROR: Test "ruby3.1" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in block in activate_dependencies': Could not find 'oauth2' (~> 1

[Lucas Nussbaum]

Source: ruby-github-api
Version: 0.19.0-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in block 
> in activate_dependencies': Could not find 'oauth2' (~> 1.0) among 106 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-github-api/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
>  at: 
> /<>/debian/ruby-github-api/usr/share/rubygems-integration/all/specifications/github_api-0.19.0.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'oauth2' (~> 1.0) - did find: [oauth2-2.0.7] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-github-api/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> abbrev (default: 0.1.0)
> addressable (2.8.1)
> atomic (1.1.16)
> base64 (default: 0.1.1)
> benchmark (default: 0.2.0)
> bigdecimal (default: 3.1.1)
> bundler (default: 2.3.7)
> cgi (default: 0.3.5)
> csv (default: 3.2.2)
> date (default: 3.2.2)
> debug (1.4.0)
> delegate (default: 0.2.0)
> descendants_tracker (0.0.4)
> did_you_mean (default: 1.6.1)
> digest (default: 3.1.0)
> drb (default: 2.1.0)
> english (default: 0.7.1)
> erb (default: 2.2.3)
> error_highlight (default: 0.3.0)
> etc (default: 1.3.0)
> faraday (1.1.0)
> fcntl (default: 1.0.1)
> fiddle (default: 1.1.0)
> fileutils (default: 1.6.0)
> find (default: 0.1.1)
> forwardable (default: 1.3.2)
> getoptlong (default: 0.1.1)
> hashie (5.0.0)
> io-console (default: 0.5.11)
> io-nonblock (default: 0.1.0)
> io-wait (default: 0.2.1)
> ipaddr (default: 1.2.4)
> irb (default: 1.4.1)
> json (default: 2.6.1)
> jwt (2.5.0)
> logger (default: 1.5.0)
> matrix (0.4.2)
> minitest (5.15.0)
> multi_json (1.14.1)
> multi_xml (0.6.0)
> multipart-post (2.0.0)
> mutex_m (default: 0.1.1)
> net-ftp (0.1.3)
> net-http (default: 0.2.0)
> net-imap (0.2.3)
> net-pop (0.1.1)
> net-protocol (default: 0.1.2)
> net-smtp (0.3.1)
> net-telnet (0.2.0)
> nkf (default: 0.1.1)
> oauth2 (2.0.7)
> observer (default: 0.1.1)
> open-uri (default: 0.2.0)
> open3 (default: 0.1.1)
> openssl (default: 3.0.0)
> optparse (default: 0.2.0)
> ostruct (default: 0.5.2)
> pathname (default: 0.2.0)
> power_assert (2.0.1)
> pp (default: 0.3.0)
> prettyprint (default: 0.

Bug#1031442: gnustep-base: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 messages=yes returned exit code 2

[Lucas Nussbaum]

Source: gnustep-base
Version: 1.28.1+really1.28.0-5
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[3]: Entering directory '/<>/Tests'
> (\
> GNUSTEP_LOCAL_ADDITIONAL_MAKEFILES="/<>/base.make";\
> ADDITIONAL_INCLUDE_DIRS="-I/<>/Headers 
> -I/<>/Source/.";\
> ADDITIONAL_LIB_DIRS="-L/<>/Source/./obj";\
> ADDITIONAL_LDFLAGS="-Wl,-rpath,/<>/Source/./obj";\
> LD_LIBRARY_PATH="/<>/Source/./obj:";\
> PATH="/<>/Tools/./obj:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games";\
> export GNUSTEP_LOCAL_ADDITIONAL_MAKEFILES;\
> export ADDITIONAL_INCLUDE_DIRS;\
> export ADDITIONAL_LDFLAGS;\
> export ADDITIONAL_LIB_DIRS;\
> export LD_LIBRARY_PATH;\
> export PATH;\
> if [ "no" = "yes" ]; then \
>   gnustep-tests --debug 'base/';\
> else \
>   gnustep-tests 'base/';\
> fi; \
> )
> --- Running tests in base/Functions ---
> --- Running tests in base/GSMime ---
> --- Running tests in base/GSTLS ---
> --- Running tests in base/GSXML ---
> --- Running tests in base/GarbageCollection ---
> --- Running tests in base/KVC ---
> --- Running tests in base/NSAffineTransform ---
> --- Running tests in base/NSArchiver ---
> --- Running tests in base/NSArray ---
> 
> base/NSArray/basic.m:
> Skipped set:   basic.m 46 ... No collection subscripting support in the 
> compiler.
> 
> base/NSArray/blocks.m:
> Skipped set:   blocks.m 76 ... No Blocks support in the compiler.
> --- Running tests in base/NSAttributedString ---
> --- Running tests in base/NSAutoreleasePool ---
> --- Running tests in base/NSBundle ---
> 
> base/NSBundle/general.m:
> Skipped set: general.m 25 ... it looks like GNUstep-base is not yet 
> installed
> 
> base/NSBundle/resources.m:
> Skipped set:   resources.m 48 ... it looks like GNUstep-base is not yet 
> installed
> --- Running tests in base/NSCache ---
> --- Running tests in base/NSCalendar ---
> --- Running tests in base/NSCalendarDate ---
> 
> base/NSCalendarDate/test00.m:
> Failed file: test00.m aborted without running all tests!
> --- Running tests in base/NSCharacterSet ---
> --- Running tests in base/NSConnection ---
> --- Running tests in base/NSCountedSet ---
> --- Running tests in base/NSData ---
> 
> base/NSData/general.m:
> Skipped set:   general.m 128 ... No Blocks support in the compiler.
> --- Running tests in base/NSDate ---
> --- Running tests in base/NSDateFormatter ---
> --- Running tests in base/NSDictionary ---
> 
> base/NSDictionary/basic.m:
> Skipped set:   basic.m 41 ... No dictionary subscripting support in the 
> compiler.
> 
> base/NSDictionary/blocks.m:
> Skipped set:   blocks.m 49 ... No Blocks support in the compiler.
> 
> base/NSDictionary/sort.m:
> Skipped set:   sort.m 54 ... No Blocks support in the compiler.
> --- Running tests in base/NSDistributedLock ---
> --- Running tests in base/NSException ---
> --- Running tests in base/NSFileHandle ---
> --- Running tests in base/NSFileManager ---
> --- Running tests in base/NSHTTPCookie ---
> --- Running tests in base/NSHashTable ---
> 
> base/NSHashTable/weakObjects.m:
> Skipped set:   weakObjects.m 15 ... ARC support unavailable
> --- Running tests in base/NSHost ---
> --- Running tests in base/NSIndexPath ---
> --- Running tests in base/NSInvocation ---
> --- Running tests in base/NSInvocationOperation ---
> --- Running tests in base/NSJSONSerialization ---
> --- Running tests in base/NSKeyedArchiver ---
> --- Running tests in base/NSLocale ---
> --- Running tests in base/NSLock ---
> --- Running tests in base/NSMapTable ---
> 
> base/NSMapTable/weakObjects.m:
> Skipped set:   weakObjects.m 15 ... ARC support unavailable
> --- Running tests in base/NSMethodSignature ---
> --- Running tests in base/NSMutableArray ---
> --- Running tests in base/NSMutableAttributedString ---
> --- Running tests in base/NSMutableCharacterSet ---
> --- Running tests in base/NSMutableData ---
> --- Running tests in base/NSMutableDictionary ---
> --- Running tests in base/NSMutableIndexSet ---
> 
> base/NSMutableIndexSet/blocks.m:
> Skipped set:   blocks.m 83 ... No Blocks support in the compiler.
> --- Running tests in base/NSMutableSet ---
> --- Running tests in base/NSMutableString ---
> --- Running tests in base/NSNotification ---
> --- Running tests in base/NSNumber ---
> --- Running tes

Bug#1031438: qca2: FTBFS: dh_auto_test: error: cd build && make -j8 test ARGS\+=--verbose ARGS\+=-j8 returned exit code 2

[Lucas Nussbaum]

Source: qca2
Version: 2.3.5-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[2]: Entering directory '/<>/build'
> Running tests...
> /usr/bin/ctest --force-new-ctest-process --verbose -j8
> UpdateCTestConfiguration  from :/<>/build/DartConfiguration.tcl
> UpdateCTestConfiguration  from :/<>/build/DartConfiguration.tcl
> Test project /<>/build
> Constructing a list of tests
> Done constructing a list of tests
> Updating test list for fixtures
> Added 0 tests to meet fixture requirements
> Checking test dependency graph...
> Checking test dependency graph end
> test 1
>   Start  1: Base64
> 
> 1: Test command: /<>/build/bin/base64unittest
> 1: Working Directory: /<>/build/bin
> 1: Test timeout computed to be: 1000
> test 2
>   Start  2: BigInteger
> 
> 2: Test command: /<>/build/bin/bigintunittest
> 2: Working Directory: /<>/build/bin
> 2: Test timeout computed to be: 1000
> test 3
>   Start  3: Certificate
> 
> 3: Test command: /<>/build/bin/certunittest
> 3: Working Directory: /<>/build/bin
> 3: Test timeout computed to be: 1000
> test 4
>   Start  4: SymmetricCipher
> 
> 4: Test command: /<>/build/bin/cipherunittest
> 4: Working Directory: /<>/build/bin
> 4: Test timeout computed to be: 1000
> test 5
>   Start  5: ClientSidePlugin
> 
> 5: Test command: /<>/build/bin/clientplugin
> 5: Working Directory: /<>/build/bin
> 5: Test timeout computed to be: 1000
> test 6
>   Start  6: DigitalSignatureAlgorithm
> 
> 6: Test command: /<>/build/bin/dsaunittest
> 6: Working Directory: /<>/build/bin
> 6: Test timeout computed to be: 1000
> test 7
>   Start  7: FileWatch
> 
> 7: Test command: /<>/build/bin/filewatchunittest
> 7: Working Directory: /<>/build/bin
> 7: Test timeout computed to be: 1000
> test 8
>   Start  8: Hashing
> 
> 8: Test command: /<>/build/bin/hashunittest
> 8: Working Directory: /<>/build/bin
> 8: Test timeout computed to be: 1000
> 1: * Start testing of Base64UnitTest *
> 1: Config: Using QtTest library 5.15.8, Qt 5.15.8 (x86_64-little_endian-lp64 
> shared (dynamic) release build; by GCC 12.2.0), debian unknown
> 1: PASS   : Base64UnitTest::initTestCase()
> 1: PASS   : Base64UnitTest::test1(31)
> 1: PASS   : Base64UnitTest::test1(235c91)
> 1: PASS   : Base64UnitTest::test1(414)
> 1: PASS   : Base64UnitTest::test1(241)
> 1: PASS   : Base64UnitTest::test1(313)
> 1: PASS   : Base64UnitTest::test1(60e)
> 1: PASS   : Base64UnitTest::test1(3134)
> 1: PASS   : Base64UnitTest::test2(www.python.org)
> 1: PASS   : Base64UnitTest::test2(a)
> 1: PASS   : Base64UnitTest::test2(ab)
> 1: PASS   : Base64UnitTest::test2(abc)
> 1: PASS   : Base64UnitTest::test2(empty)
> 1: PASS   : Base64UnitTest::test2(a-Z)
> 1: PASS   : Base64UnitTest::test2(31)
> 1: PASS   : Base64UnitTest::test2(QCA_2.0)
> 1: PASS   : Base64UnitTest::test2(j-0)
> 1: PASS   : Base64UnitTest::cleanupTestCase()
> 1: Totals: 18 passed, 0 failed, 0 skipped, 0 blacklisted, 1ms
> 1: * Finished testing of Base64UnitTest *
> 2: * Start testing of BigIntUnitTest *
> 2: Config: Using QtTest library 5.15.8, Qt 5.15.8 (x86_64-little_endian-lp64 
> shared (dynamic) release build; by GCC 12.2.0), debian unknown
> 2: PASS   : BigIntUnitTest::initTestCase()
> 3: * Start testing of CertUnitTest *
> 3: Config: Using QtTest library 5.15.8, Qt 5.15.8 (x86_64-little_endian-lp64 
> shared (dynamic) release build; by GCC 12.2.0), debian unknown
> 3: PASS   : CertUnitTest::initTestCase()
> 4: * Start testing of CipherUnitTest *
> 4: Config: Using QtTest library 5.15.8, Qt 5.15.8 (x86_64-little_endian-lp64 
> shared (dynamic) release build; by GCC 12.2.0), debian unknown
> 4: PASS   : CipherUnitTest::initTestCase()
> 5: * Start testing of ClientPlugin *
> 5: Config: Using QtTest library 5.15.8, Qt 5.15.8 (x86_64-little_endian-lp64 
> shared (dynamic) release build; by GCC 12.2.0), debian unknown
> 5: PASS   : ClientPlugin::initTestCase()
> 5: PASS   : ClientPlugin::testInsertRemovePlugin()
> 5: PASS   : ClientPlugin::cleanupTestCase()
> 6: * Start testing of DSAUnitTest *
> 6: Config: Using QtTest library 5.15.8, Qt 5.15.8 (x86_64-little_endian-lp64 
> shared (dynamic) release build; by GCC 12.2.0), debian unknown
> 6: PASS   : DSAUnitTest::initTest

Bug#1031444: poetry: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Lucas Nussbaum]

Source: poetry
Version: 1.3.2+dfsg-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
>  debian/rules binary
> dh binary --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild plugin_pyproject:107: Building wheel for python3.11 with "build" 
> module
> I: pybuild base:240: python3.11 -m build --skip-dependency-check 
> --no-isolation --wheel --outdir 
> /<>/.pybuild/cpython3_3.11_poetry 
> * Building wheel...
> Successfully built poetry-1.3.2-py3-none-any.whl
> I: pybuild plugin_pyproject:119: Unpacking wheel built for python3.11 with 
> "installer" module
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11_poetry/build; 
> python3.11 -m pytest --ignore=tests/console/commands/env/test_list.py 
> --ignore=tests/console/commands/env/test_remove.py 
> --ignore=tests/console/commands/env/test_use.py 
> --ignore=tests/utils/test_env.py --ignore=tests/config/test_config.py 
> --ignore=tests/utils/test_helpers.py -k 'not 
> test_self_update_should_install_all_necessary_elements and not 
> test_add_file_constraint_sdist and not 
> test_add_file_constraint_sdist_old_installer and not test_publish_dry_run and 
> not test_info_from_sdist and not 
> test_installer_can_install_dependencies_from_forced_source and not 
> test_search_for_file_sdist and not test_search_for_file_sdist_with_extras and 
> not test_solver_can_resolve_sdist_dependencies and not 
> test_solver_can_resolve_sdist_dependencies_with_extras and not 
> test_solver_chooses_from_correct_repository_if_forced and not 
> test_solver_chooses_from_correct_repository_if_forced_and_transitive_dependency
>  and not test_solver_does_not_choose_from_secondary_repository_by_default and 
> not test_solver_chooses_from_secondary_if_explicit and not 
> test_get_package_information_fallback_read_setup and not 
> test_get_package_information_skips_dependencies_with_invalid_constraints and 
> not test_get_package_retrieves_packages_with_no_hashes and not 
> test_fallback_can_read_setup_to_get_dependencies and not 
> test_exporter_can_export_requirements_txt_with_file_packages and not 
> test_exporter_can_export_requirements_txt_with_file_packages_and_markers and 
> not test_lock_no_update and not 
> test_locker_dumps_dependency_information_correctly and not 
> test_package_partial_yank and not 
> test_run_installs_with_same_version_url_files and not 
> test_env_info_displays_complete_info and not test_skip_existing_output and 
> not 
> test_installer_should_use_the_locked_version_of_git_dependencies_with_extras 
> and not 
> test_installer_should_use_the_locked_version_of_git_dependencies_without_reference
>  and not test_installer_uses_prereleases_if_they_are_compatible and not 
> test_requirement_git_subdirectory and not test_check_valid and not 
> test_check_invalid and not test_packages_property_returns_empty_list and not 
> test_parse_dependency_specification and not 
> test_info_setup_missing_mandatory_should_trigger_pep517 and not 
> test_uninstall_git_package_nspkg_pth_cleanup and not 
> test_executor_should_write_pep610_url_references_for_directories and not 
> test_executor_should_write_pep610_url_references_for_git and not 
> test_executor_should_write_pep610_url_references_for_git_with_subdirectories'
> = test session starts 
> ==
> platform linux -- Python 3.11.2, pytest-7.2.1, pluggy-1.0.0+repack
> rootdir: /<>, configfile: pyproject.toml
> plugins: xdist-3.1.0, mock-3.8.2
> gw0 I / gw1 I / gw2 I / gw3 I / gw4 I / gw5 I / gw6 I / gw7 I
> gw0 [1051] / gw1 [1051] / gw2 [1051] / gw3 [1051] / gw4 [1051] / gw5 [1051] / 
> gw6 [1051] / gw7 [1051]
> 
>  [  
> 6%]
>  [ 
> 13%]
> . [ 
> 20%]
> s [ 
> 27%]
>  [ 
> 34%]
> ..F.. [ 
> 41%]
> ..s. [ 
> 48%]
> .

Bug#1031445: camv-rnd: FTBFS: build-dependency not installable: librnd4-dev (>= 3.2.0)

[Lucas Nussbaum]

Source: camv-rnd
Version: 1.1.1-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> +--+
> | Install package build dependencies  
>  |
> +--+
> 
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: debhelper (>= 11), librnd4-dev (>= 3.2.0), libgd-dev, 
> libgtkglext1-dev, build-essential, fakeroot
> Filtered Build-Depends: debhelper (>= 11), librnd4-dev (>= 3.2.0), libgd-dev, 
> libgtkglext1-dev, build-essential, fakeroot
> dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
> '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
> Ign:1 copy:/<>/apt_archive ./ InRelease
> Get:2 copy:/<>/apt_archive ./ Release [957 B]
> Ign:3 copy:/<>/apt_archive ./ Release.gpg
> Get:4 copy:/<>/apt_archive ./ Sources [394 B]
> Get:5 copy:/<>/apt_archive ./ Packages [474 B]
> Fetched 1825 B in 0s (139 kB/s)
> Reading package lists...
> Reading package lists...
> 
> Install main build dependencies (apt-based resolver)
> 
> 
> Installing build dependencies
> Reading package lists...
> Building dependency tree...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-main-dummy : Depends: librnd4-dev (>= 3.2.0) but it is 
> not installable
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.


The full build log is available from:
http://qa-logs.debian.net/2023/02/16/camv-rnd_1.1.1-1_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230216;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20230216&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=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.

Bug#1031446: lomiri-ui-toolkit: FTBFS: QWARN : components::UnknownTestFunc() file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtTest/SignalSpy.qml:258: Error: Invalid write to global property "qtest_count"

[Lucas Nussbaum]

Source: lomiri-ui-toolkit
Version: 1.3.5000+dfsg-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> Creating QML component for Lomiri.Metrics
> Failed to load Lomiri.Metrics
> import QtQuick 2.0
> import Lomiri.Metrics 0.1 as ALomiri_Metrics_0_1
> QtObject { }
> 
> file:///<>/qml/Lomiri/Metrics/qmldir:2:1: plugin cannot be 
> loaded for module "Lomiri.Metrics": Cannot protect module Lomiri.Metrics 0 as 
> it was never registered
> make[3]: *** [Makefile:745: check] Error 1


The full build log is available from:
http://qa-logs.debian.net/2023/02/16/lomiri-ui-toolkit_1.3.5000+dfsg-1_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230216;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20230216&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=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.

Bug#1031443: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z

[Lucas Nussbaum]

Source: python-zstandard
Version: 0.19.0-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> cd docs; LC_ALL=C.UTF-8 LANGUAGE=C.UTF-8 sphinx-build -bhtml . _build/html
> Running Sphinx v5.3.0
> making output directory... done
> building [mo]: targets for 0 po files that are out of date
> building [html]: targets for 14 source files that are out of date
> updating environment: [new config] 14 added, 0 changed, 0 removed
> reading sources... [  7%] api_usage
> reading sources... [ 14%] buffer
> reading sources... [ 21%] compression_parameters
> reading sources... [ 28%] compressor
> reading sources... [ 35%] concepts
> reading sources... [ 42%] contributing
> reading sources... [ 50%] decompressor
> reading sources... [ 57%] dictionaries
> reading sources... [ 64%] index
> reading sources... [ 71%] installing
> reading sources... [ 78%] misc_apis
> reading sources... [ 85%] multithreaded
> reading sources... [ 92%] news
> reading sources... [100%] projectinfo
> 
> WARNING: autodoc: failed to import class 'BufferSegment' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'BufferSegments' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'BufferWithSegments' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'BufferWithSegmentsCollection' from 
> module 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'ZstdCompressionParameters' from 
> module 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'ZstdCompressor' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'ZstdCompressionWriter' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'ZstdCompressionReader' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'ZstdCompressionObj' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'ZstdCompressionChunker' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'ZstdDecompressor' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'ZstdDecompressionWriter' from 
> module 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'ZstdDecompressionReader' from 
> module 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'ZstdDecompressionObj' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import class 'ZstdCompressionDict' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import function 'train_dictionary' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import function 'get_frame_parameters' from 
> module 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import function 'frame_header_size' from module 
> 'zstandard'; the following exception was raised:
> No module named 'zstandard'
> WARNING: autodoc: failed to import function 'frame_content_size' from module 
> 'zstandard'; the 

Bug#1031447: ffmpeg: FTBFS: src/libavutil/hwcontext_vulkan.c:363:7: error: ‘VK_EXT_VIDEO_DECODE_H264_EXTENSION_NAME’ undeclared here (not in a function); did you mean ‘VK_EXT_VIDEO_ENCODE_H264_EXTENSI

[Lucas Nussbaum]

Source: ffmpeg
Version: 7:5.1.2-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> gcc -I. -Isrc/ -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE 
> -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 
> -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC 
> -DZLIB_CONST -DHAVE_AV_CONFIG_H -DBUILDING_avutil -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-strict-overflow -fstack-protector-all -fPIE   
> -std=c11 -fomit-frame-pointer -fPIC -pthread  -I/usr/include/p11-kit-1  
> -I/usr/include/lilv-0 -I/usr/include/serd-0 -I/usr/include/sord-0 
> -I/usr/include/sratom-0 -I/usr/include/freetype2 -I/usr/include/libpng16 
> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/fribidi 
> -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/libpng16 
> -I/usr/include/bs2b-I/usr/include/libdrm -I/usr/include/freetype2 
> -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 
> -I/usr/include/fribidi  -DHWY_SHARED_DEFINE  -I/usr/include/mfx  
> -I/usr/include/openjpeg-2.5 -I/usr/include/x86_64-linux-gnu 
> -I/usr/include/opus -I/usr/include/opus  -D_REENTRANT  -I/usr/include/rav1e  
> -I/usr/include/librsvg-2.0 -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libmount 
> -I/usr/include/blkid -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
> -I/usr/include/x86_64-linux-gnu -pthread -I/usr/include/cairo 
> -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/srt 
> -I/usr/include/p11-kit-1 -I/usr/include/svt-av1 -DEB_DLL  
> -DX264_API_IMPORTS   -isystem /usr/include/mit-krb5 -I/usr/include/pgm-5.3 
> -I/usr/include/libxml2  -I/usr/include/libxml2  -I/usr/include/sphinxbase 
> -I/usr/include/pocketsphinx -I/usr/include/x86_64-linux-gnu 
> -I/usr/include/x86_64-linux-gnu/sphinxbase-I/usr/include/libdrm 
> -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization 
> -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef 
> -Wmissing-prototypes -Wstrict-prototypes -Wempty-body -Wno-parentheses 
> -Wno-switch -Wno-format-zero-length -Wno-pointer-sign 
> -Wno-unused-const-variable -Wno-bool-operation -Wno-char-subscripts -O3 
> -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security 
> -Werror=implicit-function-declaration -Werror=missing-prototypes 
> -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto 
> -Wno-maybe-uninitialized -I/usr/include/SDL2 -D_REENTRANT   -MMD -MF 
> libavutil/imgutils.d -MT libavutil/imgutils.o -c -o libavutil/imgutils.o 
> src/libavutil/imgutils.c
> src/libavutil/hwcontext_vulkan.c:363:7: error: 
> ‘VK_EXT_VIDEO_DECODE_H264_EXTENSION_NAME’ undeclared here (not in a 
> function); did you mean ‘VK_EXT_VIDEO_ENCODE_H264_EXTENSION_NAME’?
>   363 | { VK_EXT_VIDEO_DECODE_H264_EXTENSION_NAME,
> FF_VK_EXT_NO_FLAG},
>   |   ^~~
>   |   VK_EXT_VIDEO_ENCODE_H264_EXTENSION_NAME
> src/libavutil/hwcontext_vulkan.c:364:7: error: 
> ‘VK_EXT_VIDEO_DECODE_H265_EXTENSION_NAME’ undeclared here (not in a 
> function); did you mean ‘VK_EXT_VIDEO_ENCODE_H265_EXTENSION_NAME’?
>   364 | { VK_EXT_VIDEO_DECODE_H265_EXTENSION_NAME,
> FF_VK_EXT_NO_FLAG},
>   |   ^~~
>   |   VK_EXT_VIDEO_ENCODE_H265_EXTENSION_NAME
> gcc -I. -Isrc/ -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE 
> -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 
> -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC 
> -DZLIB_CONST -DHAVE_AV_CONFIG_H -DBUILDING_avutil -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-strict-overflow -fstack-protector-all -fPIE   
> -std=c11 -fomit-frame-pointer -fPIC -pthread  -I/usr/include/p11-kit-1  
> -I/usr/include/lilv-0 -I/usr/include/serd-0 -I/usr/include/sord-0 
> -I/usr/include/sratom-0 -I/usr/include/freetype2 -I/usr/include/libpng16 
> -I/usr/include/harfbuzz -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/fribidi 
> -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/libpng16 
> -I/usr/include/bs2b-I/usr/include/libdrm -I/usr/include/freetype2 
> -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 
> -I/usr/include/fribidi  -DHWY_SHARED_DEFINE  -I/usr/include/mfx  
>

Bug#1031448: fwupd: FTBFS: ./obj-x86_64-linux-gnu/meson-private/tmp7p7957mh/./obj-x86_64-linux-gnu/meson-private/tmp7p7957mh/testfile.c:17: undefined reference to `gcab_cabinet_add_allowed_compression

[Lucas Nussbaum]

Source: fwupd
Version: 1.8.10-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
>  /usr/bin/ld: /tmp/ccLdacAo.o: in function `main':
> ./obj-x86_64-linux-gnu/meson-private/tmp7p7957mh/./obj-x86_64-linux-gnu/meson-private/tmp7p7957mh/testfile.c:17:
>  undefined reference to `gcab_cabinet_add_allowed_compression'
> collect2: error: ld returned 1 exit status


The full build log is available from:
http://qa-logs.debian.net/2023/02/16/fwupd_1.8.10-2_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230216;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20230216&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=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.

Bug#1031449: python-scrapy: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10502 hardcoded in zstd

[Lucas Nussbaum]

Source: python-scrapy
Version: 2.8.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> === FAILURES 
> ===
>  ProxyConnectTestCase.test_https_connect_tunnel 
> 
> 
> self =  testMethod=test_https_connect_tunnel>
> 
> def setUp(self):
> try:
> import mitmproxy  # noqa: F401
> except ImportError:
> self.skipTest("mitmproxy is not installed")
> 
> self.mockserver = MockServer()
> self.mockserver.__enter__()
> self._oldenv = os.environ.copy()
> 
> self._proxy = MitmProxy()
> >   proxy_url = self._proxy.start()
> 
> /<>/.pybuild/cpython3_3.11_scrapy/build/tests/test_proxy_connect.py:79:
>  
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> 
> self = 
> 
> def start(self):
> from scrapy.utils.test import get_testenv
> 
> script = """
> import sys
> from mitmproxy.tools.main import mitmdump
> sys.argv[0] = "mitmdump"
> sys.exit(mitmdump())
> """
> cert_path = Path(__file__).parent.resolve() / "keys" / 
> "mitmproxy-ca.pem"
> self.proc = Popen(
> [
> sys.executable,
> "-c",
> script,
> "--listen-host",
> "127.0.0.1",
> "--listen-port",
> "0",
> "--proxyauth",
> f"{self.auth_user}:{self.auth_pass}",
> "--certs",
> str(cert_path),
> "--ssl-insecure",
> ],
> stdout=PIPE,
> env=get_testenv(),
> )
> line = self.proc.stdout.readline().decode("utf-8")
> >   host_port = re.search(r"listening at http://([^:]+:\d+)", 
> > line).group(1)
> E   AttributeError: 'NoneType' object has no attribute 'group'
> 
> /<>/.pybuild/cpython3_3.11_scrapy/build/tests/test_proxy_connect.py:52:
>  AttributeError
> - Captured stderr call 
> -
> Traceback (most recent call last):
>   File "", line 3, in 
>   File "/usr/lib/python3/dist-packages/mitmproxy/tools/main.py", line 9, in 
> 
> from mitmproxy import exceptions, master
>   File "/usr/lib/python3/dist-packages/mitmproxy/master.py", line 7, in 
> 
> from mitmproxy import eventsequence
>   File "/usr/lib/python3/dist-packages/mitmproxy/eventsequence.py", line 6, 
> in 
> from mitmproxy import http
>   File "/usr/lib/python3/dist-packages/mitmproxy/http.py", line 26, in 
> 
> from mitmproxy.net import encoding
>   File "/usr/lib/python3/dist-packages/mitmproxy/net/encoding.py", line 13, 
> in 
> import zstandard as zstd
>   File "/usr/lib/python3/dist-packages/zstandard/__init__.py", line 39, in 
> 
> from .backend_c import *  # type: ignore
> 
> ImportError: zstd C API versions mismatch; Python bindings were not 
> compiled/linked against expected zstd version (10504 returned by the lib, 
> 10502 hardcoded in zstd headers, 10502 hardcoded in the cext)
> __ ProxyConnectTestCase.test_https_tunnel_auth_error 
> ___
> 
> self =  testMethod=test_https_tunnel_auth_error>
> 
> def setUp(self):
> try:
> import mitmproxy  # noqa: F401
> except ImportError:
> self.skipTest("mitmproxy is not installed")
> 
> self.mockserver = MockServer()
> self.mockserver.__enter__()
> self._oldenv = os.environ.copy()
> 
> self._proxy = MitmProxy()
> >   proxy_url = self._proxy.start()
> 
> /<>/.pybuild/cpython3_3.11_scrapy/build/tests/test_proxy_connect.py:79:
>  
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> 
> self = 
> 
> def start(self):
> from scrapy.utils.test import get_testenv
> 
> script = """
&

Bug#1031450: gearmand: FTBFS: ld: /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so: undefined reference to `memcached_server_minor_version'

[Lucas Nussbaum]

Source: gearmand
Version: 1.1.19.1+ds-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230216 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> /bin/bash ./libtool  --tag=CXX   --mode=link c++  -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wno-unknown-pragmas -Wno-pragmas -Wall -Wextra 
> -Wno-attributes -Wvarargs -Waddress -Warray-bounds -Wchar-subscripts 
> -Wcomment -Wctor-dtor-privacy -Wfloat-equal -Wformat=2 -Wformat-y2k 
> -Wmaybe-uninitialized -Wmissing-field-initializers -Wlogical-op 
> -Wnon-virtual-dtor -Wnormalized=id -Woverloaded-virtual -Wpointer-arith 
> -Wredundant-decls -Wshadow -Wsign-compare -Wstrict-overflow=1 -Wswitch-enum 
> -Wtrampolines -Wundef -funsafe-loop-optimizations -Wc++11-compat -Wclobbered 
> -Wunused -Wunused-result -Wunused-variable -Wunused-parameter 
> -Wunused-local-typedefs -Wwrite-strings -Wformat-security -fwrapv -pipe -fPIE 
> -pie -Wsizeof-pointer-memaccess -Wpacked -std=c++0x  -Wl,-z,relro -Wl,-z,now 
> -Wl,--as-needed -o t/httpd tests/httpd_test.o libgearman/libgearman.la 
> libtest/libtest.la tests/libstartworker.la 
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_server_minor_version'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_server_instance_by_position'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_behavior_set'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_set_sasl_auth_data'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_free'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_flush'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_clone'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_server_major_version'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_version'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_behavior_get'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_server_micro_version'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_server_cursor'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_server_error_return'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_stat_free'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_server_error'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_create'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_stat'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>  undefined reference to `memcached_server_add'
> collect2: error: ld returned 1 exit status


The full build log is available from:
http://qa-logs.debian.net/2023/02/16/gearmand_1.1.19.1+ds-2_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230216;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20230216&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

A list of current common problems