Bug#1069625: Acknowledgement (gstreamer1.0: Don't build ptp-helper on hppa)
Hello, the suggested patch is incomplete as it breaks the installation of ptp-helper on architectures with Rust support by just removing it from the .install file. I have improved the patch in this regard by employing dh-exec and extended it for the remaining Debian Ports architectures without Rust support (alpha, m68k and sh4). I intentionally omitted ia64 as it will be dropped from Debian Ports within the next days. NB: For dh-exec to work, the file libgstreamer1.0-0.install *must* be executable. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru old/gstreamer1.0-1.24.3/debian/changelog new/gstreamer1.0-1.24.3/debian/changelog --- old/gstreamer1.0-1.24.3/debian/changelog 2024-04-30 10:40:18.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/changelog 2024-05-28 07:57:26.535826780 +0200 @@ -1,3 +1,9 @@ +gstreamer1.0 (1.24.3-1+ports) unreleased; urgency=medium + + * Disable rustc for unsupported architectures + + -- John Paul Adrian Glaubitz Tue, 28 May 2024 07:57:09 +0200 + gstreamer1.0 (1.24.3-1) unstable; urgency=medium * New upstream version 1.24.3 diff -Nru old/gstreamer1.0-1.24.3/debian/control new/gstreamer1.0-1.24.3/debian/control --- old/gstreamer1.0-1.24.3/debian/control 2024-04-30 10:40:18.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/control 2024-05-28 11:16:10.247257446 +0200 @@ -6,6 +6,7 @@ Sjoerd Simons , Marc Leeman , Build-Depends: debhelper-compat (= 13), + dh-exec, dh-sequence-gir, meson (>= 0.62), pkgconf, @@ -18,7 +19,7 @@ libdw-dev [i386 amd64 armel armhf arm64 powerpc ppc64 ppc64el mipsel mips64el riscv64], bison, flex, - rustc, + rustc [!alpha !hppa !m68k !sh4], libgirepository1.0-dev, gir1.2-glib-2.0, gir1.2-freedesktop, diff -Nru old/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install new/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install --- old/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install 2024-04-30 10:37:47.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install 2024-05-28 07:55:56.540429867 +0200 @@ -1,5 +1,6 @@ +#!/usr/bin/dh-exec usr/lib/*/gstreamer-1.0/*.so usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner -usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper +[!alpha !hppa !m68k !sh4] usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper usr/lib/*/*.so.* usr/share/locale diff -Nru old/gstreamer1.0-1.24.3/debian/rules new/gstreamer1.0-1.24.3/debian/rules --- old/gstreamer1.0-1.24.3/debian/rules 2024-04-30 10:37:47.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/rules 2024-05-28 09:39:31.503804282 +0200 @@ -44,6 +44,10 @@ conf_flags += -Dlibunwind=disabled -Dlibdw=disabled endif +ifneq (,$(filter $(DEB_HOST_ARCH),alpha hppa m68k sh4)) +conf_flags += -Dptp-helper=disabled +endif + infiles := \ libgstreamer1.0-0.postinst
Bug#1072071: gcc-13: Please add libatomic for 32-bit SPARC for Ada
Source: gcc-13 Version: 13.2.0-25 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, I just tried to build a cross-compiler for 32-bit SPARC (Debian arch sparc) with Ada enabled. The build failed with a linker failure which indicates that linking against libatomic is required: checking float.h presence... yes checking for float.h... yes checking fp.h usability... /usr/sparc-linux-gnu/bin/ld: libgnat-13.so: undefined reference to `__atomic_compare_exchange_8' collect2: error: ld returned 1 exit status Such a patch already exists for armel [1], so it should be easy to extend it for 32-bit SPARC. 64-bit SPARC (Debian arch sparc64) is not affected, linking against libatomic is therefore not required. Thanks, Adrian > [1] > https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-13-debian/debian/patches/ada-armel-libatomic.diff -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#970043: Request to help test ia64 build for galera-4
evel/2023-05/msg00051.html > > In general I thought that UEFI was derived from EFI, so I don't really > see, why both can't coexist together. But I might have to do further > research on that. Apart from that, ELILO is working perfectly fine both > for diskless boots and booting from disk. ELILO is unmaintained and has had various issues and bugs in the past which is why I switched to GRUB on Debian back then. But it also looks like that ia64 support is going to stay in GRUB for a while, I haven't seen any new efforts for removing it lately on the grub-devel mailing list. > > - ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual > >address space found on x86_64; > > Yes, it was done earlier than x86_64. > > > this causes problems with languages like > >JavaScript which use tagged pointers to encode type information in the > >bits unused on x86_64, see: > > > >> https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18) > > > >(NB: This is expected to improve in the future as x86_64 optionally > > supports > > larger virtual address spaces in the kernel nowadays as well). > > > > - the math error handling ABI on ia64 in glibc is different from other > > architectures > >and the code for it in sysdeps/ia64/fpu/libm_error.c is quite > > convoluted; as glibc > >tries to unify and simplify FPU error handling, the different semantics > > of the ia64 > >ABI would require - quoting Adhemerval here - »a lot boilerplate and > > mechanical > >changes« which he doesn't think is worth the effort > > I think we could have done more in this regard, if ia64 support wouldn't > have been removed from Linux last year, requiring additional work > everywhere. But I don't complain, I think it also forced our hands. Well, I have done a lot of work in this regard in the past to get JavaScript fixed on targets with virtual address space sizes beyond 48 bits. But it's still not fixed everywhere, especially not in Qt5. It has been fixed in Qt6 though. > > There are probably more issues and quirks that I don't remember, but I > > think the list > > above already mentions enough show stoppers which mean that upstream > > projects won't be > > willing to re-add support for the architecture. > > Thanks for your assessment. I consider that much more useful than to > advise people against working on ia64. I'm not advising against you to do anything. You are free to spend your free time with whatever you want and if you think that keeping ia64 is worth the effort, more power to you! All I did was giving an elaborate explanation why ia64 is going to be removed from Debian within the next days and why I personally think it's a lost cause. > > Of course, I am not going to stop you from continuing your work and I think > > such efforts > > are always laudable. I just don't think the very limited interest in this > > architecture > > will be enough to overcome the difficulties that ia64 maintainers have to > > face. > > > > This is also the reason why the ia64 maintainers of neither Debian nor > > Gentoo were against > > the removal of support for the architecture in Ruby, the Linux kernel, > > glibc and so on. > > Being not against something and taking care of something are two > different things. But why would maintainers start an argument with upstream developers over something they don't really care about? That makes no sense. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#970043: Request to help test ia64 build for galera-4
Hello Frank, On Sat, 2024-05-25 at 18:29 +0200, Frank Scheiner wrote: > > ia64 support has been removed from glibc, the Linux kernel and soon gcc, > > First - ia64 support was actually removed from the glibc **because** it > was removed from Linux. It was also removed because there was no maintainer for it in glibc and suffered from a lot of testsuite failures. I tried for a long time to convince Adhemerval to fix these issues, but he explained that it would involve rewriting large parts of the math code for ia64 which he thought wasn't worth the effort. > Second, how did you come to the conclusion that ia64 support will be > removed from the gcc soon? gcc usually drops support for a target when it's no longer present in the kernel and glibc. That happened in the past and that will happen in the future, although there are some targets like Blackfin, CRIS and M32R that are still supported by gcc while being dropped by the kernel. And since ia64 support has already been marked as deprecated, I expect it to be removed from gcc soon. Especially, since ia64 adds a lot of complexity to gcc due to its VLIW design. > Rene said he would step up as maintainer for ia64 in gcc - see the > thread at [1] - and I haven't heard any different since then. > > [1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html > > @Rene: Can you confirm? As of now, gcc is still marked as deprecated: > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=a37113bd00aef1412771f7dd630abebabd444c1f;hb=HEAD#l273 > > so it will be removed within the next weeks after we have made an archive > > copy. > > > > There is no need to fix any bugs on ia64. > > Let me correct that for you: > > There is no need to fix any bugs for ia64 in Debian (Ports) - as sad as > that is. Have you already sorted out who is going to maintain ia64 support in glibc and the Linux kernel? And do you already know how to get Ruby upstream to re-add ia64 support? Ruby is required for a lot of other packages that depend on it. As someone who has been maintaining many exotic or deprecated architectures both in Debian and in the Linux kernel, I know how much work it involves to keep a port alive and running. And since I have also maintained ia64 in the past and know about all the quirks and problems the port has, I think the possibility that the port will ever return upstream to the kernel, glibc and the Ruby interpreter is nearly zero. To summarize the known issues and quirks on ia64: - ia64 has two stacks growing in opposite directions making exception handling in languages like Ruby more complicated and requiring additional code, see: > https://github.com/ruby/ruby/blob/master/doc/NEWS/NEWS-2.7.0 (search for IA64) - the VLIW design adds a lot of complexity to the compiler; when it was created, designers expected the design to be superior but it turned out that the implementation was more challenging than expected and left gcc with a lot of unresolved problems on ia64, see: > https://gcc.gnu.org/projects/ia64.html - ia64 comes with its own implementation of EFI which is not fully compatible with UEFI and requires additional support code; this was the main reason why some GRUB developers wanted to get rid of ia64 support, see: > https://lists.gnu.org/archive/html/grub-devel/2023-05/msg00051.html - ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual address space found on x86_64; this causes problems with languages like JavaScript which use tagged pointers to encode type information in the bits unused on x86_64, see: > https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18) (NB: This is expected to improve in the future as x86_64 optionally supports larger virtual address spaces in the kernel nowadays as well). - the math error handling ABI on ia64 in glibc is different from other architectures and the code for it in sysdeps/ia64/fpu/libm_error.c is quite convoluted; as glibc tries to unify and simplify FPU error handling, the different semantics of the ia64 ABI would require - quoting Adhemerval here - »a lot boilerplate and mechanical changes« which he doesn't think is worth the effort There are probably more issues and quirks that I don't remember, but I think the list above already mentions enough show stoppers which mean that upstream projects won't be willing to re-add support for the architecture. Of course, I am not going to stop you from continuing your work and I think such efforts are always laudable. I just don't think the very limited interest in this architecture will be enough to overcome the difficulties that ia64 maintainers have to face. This is also the reason why the ia64 maintainers of neither Debian nor Gentoo were against the removal of support for the architecture in Ruby, the Linux kernel, glibc and so on. Adrian -- .''`. Joh
Bug#970043: Request to help test ia64 build for galera-4
Hi Otto, On Fri, 2024-05-24 at 21:24 -0700, Otto Kekäläinen wrote: > I have a patch to tentatively fix Debian package galera-4 builds on > ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19 > > Would anybody be interested in helping out and testing if the build > fully passes now? > > Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043 ia64 support has been removed from glibc, the Linux kernel and soon gcc, so it will be removed within the next weeks after we have made an archive copy. There is no need to fix any bugs on ia64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1071759: firebird4.0 FTBFS with libre2-dev 20240501
Source: firebird4.0 Version: 4.0.4.3010.ds6-3 Severity: serious Tags: ftbfs patch Forwarded: https://github.com/FirebirdSQL/firebird/commit/936e045d50f4f6632017e1cb0edea6ef960fc80c https://buildd.debian.org/status/logs.php?pkg=firebird4.0=4.0.4.3010.ds6-3%2Bb1 ... In file included from /usr/include/absl/base/config.h:86, from /usr/include/absl/base/internal/invoke.h:40, from /usr/include/absl/base/call_once.h:34, from /usr/include/re2/re2.h:222, from /<>/src/common/../common/SimilarToRegex.h:25, from /<>/src/common/SimilarToRegex.cpp:22: /usr/include/absl/base/policy_checks.h:79:2: error: #error "C++ versions less than C++14 are not supported." 79 | #error "C++ versions less than C++14 are not supported." | ^ ...
Bug#1070852: transition: gdal
On Fri, May 24, 2024 at 11:29:46AM +0200, Emilio Pozuelo Monfort wrote: > On 24/05/2024 11:02, Sebastiaan Couwenberg wrote: > > On 5/24/24 9:30 AM, Emilio Pozuelo Monfort wrote: > > > If that's the case, gdal should probably break older versions of > > > libgdal-grass so that that combination is not possible. That will > > > also make britney happy, otherwise it will block gdal due to the > > > test regression. > > > > gdal, grass, and libgdal-grass just need to be tested together. > > > > I'd rather drop the autopkgtest test than having to maintain the Breaks in > > gdal. > > *shrug*. If that's a runtime check, then there's an issue with the > dependencies/breaks, as one could have old libgdal-grass with newer gdal (as > is happening in the autopkgtest) and then libgdal-grass is broken. > > If it's a check that's being done in libgdal-grass, then maybe that check > can be dropped? > > With the information that autopkgtest has, the current situation is broken > and testing migration will be (rightly) blocked. This is the old problem that the release team wants smooth transitions, but mixing several so-versions of a library in one binary works only sometimes. Symbol versions fix some cases, but even that is not sufficient in all cases. Package: libgdal35 Breaks: libgdal34t64, libgdal32 would be the safe way to ensure no breakage during upgrades or after a partial upgrade from bookworm or trixie. > Cheers, > Emilio cu Adrian
Bug#1070256: closed by Debian FTP Masters (reply to Alec Leamas ) (Bug#1070256: fixed in libcxx-serial 1.2.1-6)
Control: reopen -1 On Sun, May 12, 2024 at 07:09:07PM +, Debian Bug Tracking System wrote: >... > Changes: > libcxx-serial (1.2.1-6) trixie; urgency=medium > . >* Avoid crash when running with nocheck profile. Closes: #1070256 >... 1.2.1-7 does still FTBFS: https://buildd.debian.org/status/fetch.php?pkg=libcxx-serial=sh4=1.2.1-7=1715548569=0 ifeq (,$(findstring nocheck,$(DEB_BUILD_PROFILES))) ENABLE_TESTS := ON else ENABLE_TESTS := OFF endif This should be DEB_BUILD_OPTIONS, not DEB_BUILD_PROFILES. cu Adrian
Bug#1071680: ocaml-linenoise FTBFS on bytecode architectures
Source: ocaml-linenoise Version: 1.5.1-1 Severity: important Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=ocaml-linenoise=1.5.1-1 ... dh_missing -a -O--buildsystem=ocaml_dune dh_missing: warning: usr/lib/ocaml/linenoise/liblinenoise_stubs.a exists in debian/tmp but is not installed to anywhere dh_missing: error: missing files, aborting The following debhelper tools have reported what they installed (with files per package) * dh_install: liblinenoise-ocaml (3), liblinenoise-ocaml-dev (7) * dh_installdocs: liblinenoise-ocaml (0), liblinenoise-ocaml-dev (2) * dh_installexamples: liblinenoise-ocaml (0), liblinenoise-ocaml-dev (2) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.md.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built If the omission is intentional or no other helper can take care of this consider adding the paths to debian/not-installed. make: *** [debian/rules:7: binary-arch] Error 255
Bug#1064938: isospec - maintainer does not access email from ftp-master
Hi Bastian, The Debichem Group maintains ~ 140 packages with this maintainer address at lists.alioth.debian.org. Was this any misconfiguration on the debian.org side, or is/was this any issue at alioth-lists.debian.net, or what else might have gone wrong here? Thanks Adrian On Tue, Feb 27, 2024 at 11:23:14PM +0100, Bastian Blank wrote: > Package: isospec > Severity: serious > > - Forwarded message from debichem-devel-ow...@alioth-lists.debian.net > - > > From: debichem-devel-ow...@alioth-lists.debian.net > To: ftpmas...@ftp-master.debian.org > Subject: Processing of isospec_2.2.1-4.1~exp2_source.changes > > You are not allowed to post to this mailing list From: a domain which > publishes a DMARC policy of reject or quarantine, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > debichem-devel-ow...@alioth-lists.debian.net. > > > Date: Sat, 24 Feb 2024 02:03:38 + > From: Debian FTP Masters > To: debichem-de...@lists.alioth.debian.org > Subject: Processing of isospec_2.2.1-4.1~exp2_source.changes > > isospec_2.2.1-4.1~exp2_source.changes uploaded successfully to localhost > along with the files: > isospec_2.2.1-4.1~exp2.dsc > isospec_2.2.1-4.1~exp2.debian.tar.xz > isospec_2.2.1-4.1~exp2_source.buildinfo > > Greetings, > > Your Debian queue daemon (running on host usper.debian.org) > > > > - End forwarded message - > > -- > Hailing frequencies open, Captain.
Bug#1059133: dogecoin: FTBFS: error: invalid ‘static_cast’ from type ‘boost::detail::function::function_buffer_members::obj_ptr_t’ {aka ‘void*’} to type ‘void (*)(bool, const CBlockIndex*)’
Control: reassign -1 libboost1.83-dev 1.83.0-2.1 Control: retitle -1 libboost1.83-dev: Please add upstream fix needed for dogecoin Control: affects -1 src:dogecoin Control: tags -1 patch Control: forwarded -1 https://github.com/boostorg/function/pull/47 On Tue, Jan 09, 2024 at 06:37:44PM -0500, Chad Jacob Milios wrote: > Please see https://github.com/boostorg/function/pull/47 and let us know if > that minor modification helps you out. Yes, it does. cu Adrian
Bug#1028634: closed by Sergio Durigan Junior (Re: Bug#1028634: tiledarray: FTBFS: Could not find a package configuration file provided by "blaspp")
On Wed, Jan 24, 2024 at 08:09:03PM +, Debian Bug Tracking System wrote: >... > Date: Wed, 24 Jan 2024 14:59:30 -0500 > From: Sergio Durigan Junior > To: 1028634-cl...@bugs.debian.org > Subject: Re: Bug#1028634: tiledarray: FTBFS: Could not find a package > configuration file provided by "blaspp" > > On Tuesday, January 24 2023, Adrian Bunk wrote: > > > On Fri, Jan 13, 2023 at 11:59:48PM +0100, Sebastian Ramacher wrote: > >> Source: tiledarray > >> Version: 1.0.0-1 > >> Severity: serious > >> Tags: ftbfs > >>... > >> blasppConfig.cmake > >> blaspp-config.cmake > >> > >> Add the installation prefix of "blaspp" to CMAKE_PREFIX_PATH or set > >> "blaspp_DIR" to a directory containing one of the above files. If > >> "blaspp" > >> provides a separate development package or SDK, be sure it has been > >> installed. > >> Call Stack (most recent call first): > >> /usr/lib/cmake/BTAS/btas-config.cmake:104 (find_dependency) > >> cmake/modules/FindOrFetchBTAS.cmake:1 (find_package) > >> CMakeLists.txt:279 (include) > > > > This looks like a problem in libbtas-dev (unpackaged dependency blaspp?). > > The package is building correctly now. Closing the bug. >... It does still FTBFS: https://buildd.debian.org/status/logs.php?pkg=tiledarray=1.0.0-1 cu Adrian
Bug#1071643: horizon-eda: Missing build dependency on cppzmq-dev
On Thu, May 23, 2024 at 09:34:48AM +0200, Uwe Steinmann wrote: > Thanks Adrian! > > Quite strange. It does have a build depend on cppzmq-dev ... No, it does not: https://tracker.debian.org/media/packages/h/horizon-eda/control-2.6.0-2 >... > So I restarted from ground in pbuilder and > 1. copied >horizon-eda_2.6.0-3.debian.tar.xz, >... 2.6.0-3 is not in the archive. cu Adrian
Bug#1071643: horizon-eda: Missing build dependency on cppzmq-dev
Source: horizon-eda Version: 2.6.0-2 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=horizon-eda=2.6.0-2 ... Has header "zmq.hpp" : NO ../meson.build:46:8: ERROR: Problem encountered: cppzmq not found I haven't checked whether this is the only missing build dependency. BTW: The build dependency on libzmq5 looks wrong and is already covered by the build dependency on libzmq3-dev, please remove libzmq5 since this will break with the next soname change of libzmq.
Bug#1071542: boost1.83: Please enable context library on ppc64
Source: boost1.83 Version: 1.83.0-2.1+b1 Severity: normal User: debian-powe...@lists.debian.org Usertags: ppc64 X-Debbugs-Cc: debian-powe...@lists.debian.org Hello, the context library is not being installed on ppc64 in debian/control despite being enabled in debian/rules. Please add ppc64 to the list of supported architectures for the context library and make sure it's actually being built and installed. Tests can be performed on the porterbox perotto.debian.net. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1071524: git: Please add patch to fix testsuite on sparc64
Source: git Version: 1:2.45.1-1 Severity: normal Tags: patch upstream User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, the attached patch fixes the Git testsuite on sparc64. I've already sent it upstream [1]. Could you include it for the next package upload? Thanks, Adrian > [1] > https://lore.kernel.org/git/2024052009.99882-1-glaub...@physik.fu-berlin.de -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >From 6580fdb9004e2d61fcb3d1f04c31bc7e328ed442 Mon Sep 17 00:00:00 2001 From: John Paul Adrian Glaubitz Date: Mon, 20 May 2024 13:03:49 +0200 Subject: [PATCH] chainlint.pl: Extend regexp pattern for /proc/cpuinfo on Linux SPARC On SPARC systems running Linux, individual processors are denoted with "CPUnn:" in /proc/cpuinfo instead of the usual "processor NN:" so that the current regexp in ncores() returns 0. Extend the regexp to match lines with "CPUnn:" as well to properly detect the number of available cores on these systems. Signed-off-by: John Paul Adrian Glaubitz --- t/chainlint.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/chainlint.pl b/t/chainlint.pl index 556ee91a15..63cac942ac 100755 --- a/t/chainlint.pl +++ b/t/chainlint.pl @@ -718,7 +718,7 @@ sub ncores { # Windows return $ENV{NUMBER_OF_PROCESSORS} if exists($ENV{NUMBER_OF_PROCESSORS}); # Linux / MSYS2 / Cygwin / WSL - do { local @ARGV='/proc/cpuinfo'; return scalar(grep(/^processor[\s\d]*:/, <>)); } if -r '/proc/cpuinfo'; + do { local @ARGV='/proc/cpuinfo'; return scalar(grep(/^processor[\s\d]*:||^CPU[\d]*:/, <>)); } if -r '/proc/cpuinfo'; # macOS & BSD return qx/sysctl -n hw.ncpu/ if $^O =~ /(?:^darwin$|bsd)/; return 1; -- 2.39.2
Bug#1071452: dnsdbq FTBFS on 32bit with 64bit time_t
Source: dnsdbq Version: 2.6.6-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=dnsdbq=2.6.6-1 ... time.c: In function ‘timeval_str’: time.c:83:36: error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘__suseconds64_t’ {aka ‘long long int’} [-Werror=format=] 83 | sprintf(dst, ".%03ld", src->tv_usec % 1000); |^ ~~~ ||| |long int __suseconds64_t {aka long long int} |%03lld time.c:85:36: error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘__suseconds64_t’ {aka ‘long long int’} [-Werror=format=] 85 | sprintf(dst, ".%06ld", src->tv_usec % 100); |^ ~~ ||| |long int __suseconds64_t {aka long long int} |%06lld cc1: all warnings being treated as errors make[1]: *** [Makefile:76: time.o] Error 1
Bug#1071277: petsc4py: binary-all FTBFS
Source: petsc4py Version: 3.20.5-2 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=petsc4py=sid ... debian/rules execute_after_dh_auto_build-indep make[1]: Entering directory '/<>' PYTHONPATH=/<>/.pybuild/cpython3_3.11_petsc4py_real3.20/build http_proxy='127.0.0.1:9' sphinx-build -N -bhtml docs/source build/html # HTML generator Running Sphinx v7.2.6 Using PETSC inventory from https://petsc.org/release/objects.inv making output directory... done [autosummary] generating autosummary for: citing.rst, demo/demo.rst, demo/poisson2d/poisson2d.rst, documentation_standards.rst, index.rst, install.rst, overview.rst, petsc_options.rst, petsc_python_types.rst, reference.rst WARNING: [autosummary] failed to import petsc4py. Possible hints: * ValueError: not enough values to unpack (expected 2, got 1) * ModuleNotFoundError: No module named 'petsc4py' * KeyError: 'petsc4py' Extension error (sphinx.ext.autosummary): Handler for event 'builder-inited' threw an exception (exception: no module named petsc4py) make[1]: *** [debian/rules:78: execute_after_dh_auto_build-indep] Error 2
Bug#1071193: libqt6core6t64/experimental breaks ABI
On Wed, May 15, 2024 at 11:27:25PM +0300, Adrian Bunk wrote: > Package: libqt6core6t64 > Version: 6.6.2+dfsg-7 > Severity: serious > Tags: ftbfs > Control: affects -1 libqt6core5compat6 src:kf6-kwallet > > https://buildd.debian.org/status/logs.php?pkg=kf6-kwallet=6.0.0-1 > > ... > Get:32 https://deb.debian.org/debian experimental/main arm64 libqt6core6t64 > arm64 6.6.2+dfsg-7 [1579 kB] > ... > Get:291 https://deb.debian.org/debian unstable/main arm64 libqt6core5compat6 > arm64 6.4.2-4+b2 [126 kB] > ... > /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined > reference to `QUtf16::convertToUnicode(QByteArrayView, > QStringConverterBase::State*, DataEndianness)@Qt_6' > /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined > reference to `QUtf16::convertFromUnicode(QStringView, > QStringConverterBase::State*, DataEndianness)@Qt_6' > /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined > reference to `QUtf32::convertToUnicode(QByteArrayView, > QStringConverterBase::State*, DataEndianness)@Qt_6' > /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined > reference to `QUtf8::convertFromUnicode(QStringView)@Qt_6' > /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined > reference to `QUtf32::convertFromUnicode(QStringView, > QStringConverterBase::State*, DataEndianness)@Qt_6' > /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined > reference to `QUtf8::convertFromUnicode(QStringView, > QStringConverterBase::State*)@Qt_6' > /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined > reference to `QUtf8::convertToUnicode(QChar*, QByteArrayView)@Qt_6' > /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined > reference to `QUtf8::convertToUnicode(QByteArrayView, > QStringConverterBase::State*)@Qt_6' > collect2: error: ld returned 1 exit status > > > This is due to: > https://salsa.debian.org/qt-kde-team/qt6/qt6-base/-/commit/b1d2e462c65933b577ec49b4e4156ec8ad426b26 Apparently the symbols were moved to PRIVATE_API: _ZN5QUtf816convertToUnicodeE14QByteArrayViewPN20QStringConverterBase5StateE@@Qt_6_PRIVATE_API _ZN5QUtf816convertToUnicodeEPDs14QByteArrayView@@Qt_6_PRIVATE_API _ZN6QUtf1616convertToUnicodeE14QByteArrayViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API _ZN6QUtf3216convertToUnicodeE14QByteArrayViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API _ZN5QUtf818convertFromUnicodeE11QStringView@@Qt_6_PRIVATE_API _ZN5QUtf818convertFromUnicodeE11QStringViewPN20QStringConverterBase5StateE@@Qt_6_PRIVATE_API _ZN6QUtf1618convertFromUnicodeE11QStringViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API _ZN6QUtf3218convertFromUnicodeE11QStringViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API This is an upstream(?) ABI break, but since libqt6core5compat6 seems to be the only affected package something like Breaks: libqt6core5compat6 (<< 6.6) might be the best available option to avoid issues when upgrading from bookworm. cu Adrian
Bug#1071193: libqt6core6t64/experimental breaks ABI
Package: libqt6core6t64 Version: 6.6.2+dfsg-7 Severity: serious Tags: ftbfs Control: affects -1 libqt6core5compat6 src:kf6-kwallet https://buildd.debian.org/status/logs.php?pkg=kf6-kwallet=6.0.0-1 ... Get:32 https://deb.debian.org/debian experimental/main arm64 libqt6core6t64 arm64 6.6.2+dfsg-7 [1579 kB] ... Get:291 https://deb.debian.org/debian unstable/main arm64 libqt6core5compat6 arm64 6.4.2-4+b2 [126 kB] ... /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined reference to `QUtf16::convertToUnicode(QByteArrayView, QStringConverterBase::State*, DataEndianness)@Qt_6' /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined reference to `QUtf16::convertFromUnicode(QStringView, QStringConverterBase::State*, DataEndianness)@Qt_6' /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined reference to `QUtf32::convertToUnicode(QByteArrayView, QStringConverterBase::State*, DataEndianness)@Qt_6' /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined reference to `QUtf8::convertFromUnicode(QStringView)@Qt_6' /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined reference to `QUtf32::convertFromUnicode(QStringView, QStringConverterBase::State*, DataEndianness)@Qt_6' /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined reference to `QUtf8::convertFromUnicode(QStringView, QStringConverterBase::State*)@Qt_6' /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined reference to `QUtf8::convertToUnicode(QChar*, QByteArrayView)@Qt_6' /usr/bin/ld: /lib/aarch64-linux-gnu/libQt6Core5Compat.so.6: undefined reference to `QUtf8::convertToUnicode(QByteArrayView, QStringConverterBase::State*)@Qt_6' collect2: error: ld returned 1 exit status This is due to: https://salsa.debian.org/qt-kde-team/qt6/qt6-base/-/commit/b1d2e462c65933b577ec49b4e4156ec8ad426b26
Bug#1071191: elfkickers attempts to write to /usr/local during the build
Source: elfkickers Version: 0+git20240221+ds-1 Severity: serious Tags: ftbfs X-Debbugs-Cc: Gürkan Myczko https://buildd.debian.org/status/logs.php?pkg=elfkickers=0%2Bgit20240221%2Bds-1 ... dh_auto_install --destdir=debian/elfkickers/ -a make -j4 install DESTDIR=/<>/elfkickers-0\+git20240221\+ds/debian/elfkickers AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true" make[1]: Entering directory '/<>' mkdir -p /usr/local/bin cp bin/* /usr/local/bin/. cp: cannot create regular file '/usr/local/bin/./ebfc': Permission denied cp: cannot create regular file '/usr/local/bin/./elfls': Permission denied cp: cannot create regular file '/usr/local/bin/./elftoc': Permission denied cp: cannot create regular file '/usr/local/bin/./infect': Permission denied cp: cannot create regular file '/usr/local/bin/./objres': Permission denied cp: cannot create regular file '/usr/local/bin/./rebind': Permission denied cp: cannot create regular file '/usr/local/bin/./sstrip': Permission denied make[1]: *** [Makefile:28: install] Error 1
Bug#1071138: falkon/experimental FTBFS: missing build dependencies
Source: falkon Version: 24.04.80-2 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=falkon=24.04.80-2 ... CMake Error at CMakeLists.txt:108 (find_package): By not providing "FindKF6I18n.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "KF6I18n", but CMake did not find one. Could not find a package configuration file provided by "KF6I18n" with any of the following names: KF6I18nConfig.cmake kf6i18n-config.cmake Add the installation prefix of "KF6I18n" to CMAKE_PREFIX_PATH or set "KF6I18n_DIR" to a directory containing one of the above files. If "KF6I18n" provides a separate development package or SDK, be sure it has been installed. -- Configuring incomplete, errors occurred! This is likely a missing build dependency on libkf6i18n-dev (untested). Looking at CMakeLists.txt, there are also optional dependencies where packages are now available in experimental.
Bug#1071137: pytorch-audio FTBFS with pytorch 2.1.2
Source: pytorch-audio Version: 0.13.1-1 Severity: serious Tags: ftbfs trixie sid patch Forwarded: https://github.com/pytorch/audio/commit/d1cc1da6a4d6cb2fa44eda457c141aa2ac73e11a https://buildd.debian.org/status/logs.php?pkg=pytorch-audio=0.13.1-1%2Bb3 ... In file included from /usr/include/torch/csrc/api/include/torch/types.h:3, from /usr/include/torch/script.h:3, from /<>/torchaudio/csrc/rnnt/compute_alphas.cpp:1: /usr/include/ATen/ATen.h:4:2: error: #error C++17 or later compatible compiler is required to use ATen. 4 | #error C++17 or later compatible compiler is required to use ATen. | ^ ...
Bug#1071133: firebird4.0: binary-all FTBFS
Source: firebird4.0 Version: 4.0.4.3010.ds6-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=firebird4.0=all ... dh_lintian sed -i -e "s/TRIPLET/x86_64-linux-gnu/g" \ debian/libib-util/usr/share/lintian/overrides/libib-util sed: can't read debian/libib-util/usr/share/lintian/overrides/libib-util: No such file or directory make[1]: *** [debian/rules:185: override_dh_lintian] Error 2
Bug#1071132: ovito accesses the internet during the build
Source: ovito Version: 3.10.5~ds-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=ovito=all=3.10.5~ds-1=1713769268=0 ... Running Sphinx v7.2.6 loading intersphinx inventory from https://ovito.org/docs/current/python/objects.inv... loading intersphinx inventory from https://docs.scipy.org/doc/scipy/objects.inv... Warning, treated as error: failed to reach any of the inventories with the following issues: intersphinx inventory 'https://ovito.org/docs/current/python/objects.inv' not fetchable due to : HTTPSConnectionPool(host='ovito.org', port=443): Max retries exceeded with url: /docs/current/python/objects.inv (Caused by NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary failure in name resolution')) ...
Bug#1071131: pytorch-geometric FTBFS (several reasons)
Source: pytorch-geometric Version: 2.3.1-2 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=pytorch-geometric=all
Bug#1058130: closed by Debian FTP Masters (reply to Ulises Vitulli ) (Bug#1058130: fixed in python-nmea2 1.19.0-1)
Control: reopen -1 On Mon, Feb 12, 2024 at 10:57:03PM +, Debian Bug Tracking System wrote: >... > python-nmea2 (1.19.0-1) unstable; urgency=medium > . >* New upstream release (Closes: #1058130). >... > Relevant part (hopefully): > > fakeroot debian/rules clean > > dh clean --with python3 --buildsystem=pybuild > >dh_auto_clean -O--buildsystem=pybuild > > I: pybuild base:310: python3.12 setup.py clean > > Traceback (most recent call last): > > File "/<>/setup.py", line 3, in > > import imp > > ModuleNotFoundError: No module named 'imp' > > E: pybuild pybuild:395: clean: plugin distutils failed with: exit code=1: > > python3.12 setup.py clean > > dh_auto_clean: error: pybuild --clean -i python{version} -p "3.12 3.11" > > returned exit code 13 > > make: *** [debian/rules:7: clean] Error 25 >... The fix is not included in 1.19.0-2: https://buildd.debian.org/status/fetch.php?pkg=python-nmea2=all=1.19.0-2=1715629490=0 cu Adrian
Bug#1070854: clc-intercal FTBFS: dpkg-genbuildinfo: error: binary build with no binary artifacts found
On Tue, May 14, 2024 at 11:16:28AM +0100, Mark Brown wrote: > On Fri, May 10, 2024 at 05:25:35PM +0300, Adrian Bunk wrote: > > > chmod +x `pwd`/debian/clc-intercal/usr/bin/* > > dpkg-genbuildinfo --build=any > > -O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo > > dpkg-genbuildinfo: error: binary build with no binary artifacts found; > > .buildinfo is meaningless > > dpkg-buildpackage: error: dpkg-genbuildinfo --build=any > > -O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo subprocess returned exit > > status 25 > > I can't reproduce this, and nothing about the build I'm seeing in the > log looks meaningfully different to what I get when I build locally. I can reproduce it with dpkg-buildpackage -B > AFAICT there are .so files being installed among the various perl things > and dpkg-genbuildinfo runs happily. ... build-arch: build-indep: build-stamp ... # Build architecture-dependent files here. binary-arch: build install # We have nothing to do by default. # Build architecture-independent files here. binary-indep: build install ... This looks wrong for a package that builds no Architecture: all packages. cu Adrian
Bug#1071081: phpunit-environment/experimental FTBFS: Error: Call to undefined method SebastianBergmann\Environment\Runtime::getRawBinary()
Source: phpunit-environment Version: 7.1.0-1 Severity: serious Tags: ftbfs Forwarded: https://github.com/sebastianbergmann/environment/commit/ff8e9b0dc10315e13f3a7951eec6b227e66997e7 https://buildd.debian.org/status/fetch.php?pkg=phpunit-environment=all=7.1.0-1=1715633007=0 ... There was 1 error: 1) SebastianBergmann\Environment\RuntimeTest::testRawBinaryCanBeRetrieved Error: Call to undefined method SebastianBergmann\Environment\Runtime::getRawBinary() /<>/tests/RuntimeTest.php:48 ERRORS! Tests: 22, Assertions: 13, Errors: 1, Skipped: 8. make[1]: *** [debian/rules:12: override_dh_auto_test] Error 2
Bug#1063004: synfig: NMU diff for 64-bit time_t transition
On Sat, Feb 24, 2024 at 12:41:14PM -0800, Steve Langasek wrote: > Control: tags -1 - pending > Control: severity -1 serious > > Unfortunately, it appears synfig ftbfs in unstable and experimental: > > [...] > checking for Magick++ >= 6.4.2... configure: error: *** Unable to find > Magick++ > cd synfig-core && tail -v -n \+0 config.log > [...] > > > (https://buildd.debian.org/status/fetch.php?pkg=synfig=amd64=1.5.1%2Bdfsg-3.1%7Eexp1=1707063449=0) > > Therefore we will not be able to NMU this. Marking the bug serious as the > mass NMUs are imminent within a few days and this becomes a serious bug once > the toolchain changes land. This is due to experimental using a different dependency resolver than unstable, and graphicsmagick-libmagick-dev-compat also providing libmagick++-dev An upload to unstable will likely build fine, but technically it would in any case be more correct to Build-Depends: libmagick++-dev (>= 7:6.4.2) cu Adrian
Bug#1071075: python-easydev accesses the internet during the build
Source: python-easydev Version: 0.13.2+dfsg1-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=python-easydev=all=0.13.2%2Bdfsg1-1=1714380640=0 ... === FAILURES === __ test_isurl __ def test_isurl(): > assert isurl_reachable("www.google.com") == True E AssertionError: assert False == True E+ where False = isurl_reachable('www.google.com') test/test_url.py:7: AssertionError === short test summary info FAILED test/test_url.py::test_isurl - AssertionError: assert False == True = 1 failed, 56 passed in 2.36s = ...
Bug#1071039: iptux FTBFS on 32bit with 64bit time_t
Source: iptux Version: 0.9.1-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=iptux=0.9.1-1 ... FAILED: src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o c++ -Isrc/iptux-core/libiptux-core.so.0.9.1.p -Isrc/iptux-core -I../src/iptux-core -Isrc -I../src -Isrc/api -I../src/api -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/sysprof-6 -I/usr/include/jsoncpp -I/usr/include/sigc++-2.0 -I/usr/lib/arm-linux-gnueabihf/sigc++-2.0/include -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -Wall -Winvalid-pch -Wextra -Wpedantic -std=c++14 -Werror=format -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD -MQ src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o -MF src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o.d -o src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o -c ../src/iptux-core/internal/SendFileData.cpp ../src/iptux-core/internal/SendFileData.cpp: In member function ‘void iptux::SendFileData::SendDirFiles()’: ../src/iptux-core/internal/SendFileData.cpp:205:16: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 8 has type ‘__time64_t’ {aka ‘long long int’} [-Werror=format=] 205 |":%s:%.9" PRIx64 ":%lx:%lx=%lx:%lx=%lx:", dirname, |^~~~ ../src/iptux-core/internal/SendFileData.cpp:205:16: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 10 has type ‘__time64_t’ {aka ‘long long int’} [-Werror=format=] 205 |":%s:%.9" PRIx64 ":%lx:%lx=%lx:%lx=%lx:", dirname, |^~~~ ../src/iptux-core/internal/SendFileData.cpp:243:36: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘__time64_t’ {aka ‘long long int’} [-Werror=format=] 243 |":.:0:%lx:%lx=%lx:%lx=%lx:", IPMSG_FILE_RETPARENT, | ~~^ || |long unsigned int | %llx ../src/iptux-core/internal/SendFileData.cpp:243:44: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 8 has type ‘__time64_t’ {aka ‘long long int’} [-Werror=format=] 243 |":.:0:%lx:%lx=%lx:%lx=%lx:", IPMSG_FILE_RETPARENT, | ~~^ || |long unsigned int | %llx ../src/iptux-core/internal/SendFileData.cpp:264:32: warning: cast between incompatible function types from ‘int (*)(DIR*)’ to ‘GFunc’ {aka ‘void (*)(void*, void*)’} [-Wcast-function-type] 264 | g_queue_foreach(, GFunc(closedir), NULL); |^~~ cc1plus: some warnings being treated as errors ... FAILED: src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o c++ -Isrc/iptux-core/libiptux-core.so.0.9.1.p -Isrc/iptux-core -I../src/iptux-core -Isrc -I../src -Isrc/api -I../src/api -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/sysprof-6 -I/usr/include/jsoncpp -I/usr/include/sigc++-2.0 -I/usr/lib/arm-linux-gnueabihf/sigc++-2.0/include -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -Wall -Winvalid-pch -Wextra -Wpedantic -std=c++14 -Werror=format -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD -MQ src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o -MF src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o.d -o src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o -c ../src/iptux-core/internal/TcpData.cpp ../src/iptux-core/internal/TcpData.cpp: In member function ‘void iptux::TcpData::RecvSublayer(uint32_t)’: ../src/iptux-core/internal/TcpData.cpp:146:35: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=] 146 | snprintf(path, MAX_PATHLEN, "%s" PIC_PATH "/%" PRIx32 "-%" PRIx32 "-%lx", | ^~~~ 147 |g_get_user_cache_dir(), inAddrToUint32(pal->ipv4()), count++, 148 |time(NULL)); |~~ || |time_t {aka long long int}
Bug#1070956: octave-fits FTBFS with Octave 9.1.0
Source: octave-fits Version: 1.0.7-7 Severity: serious Tags: ftbfs trixie sid https://buildd.debian.org/status/fetch.php?pkg=octave-fits=amd64=1.0.7-7%2Bb4=1715454563=0 ... g++ -c -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/octave-9.1.0/octave/.. -I/usr/include/octave-9.1.0/octave -pthread -fopenmp -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wall save_fits_image_multi_ext.cc -o /tmp/oct-bxJQR8.o save_fits_image_multi_ext.cc: In function ‘octave_value_list Fsave_fits_image_multi_ext(const octave_value_list&, int)’: save_fits_image_multi_ext.cc:140:60: error: passing ‘const NDArray’ as ‘this’ argument discards qualifiers [-fpermissive] 140 | double * datap = const_cast( image.fortran_vec() ); | ~^~ In file included from /usr/include/octave-9.1.0/octave/../octave/Array-util.h:31, from /usr/include/octave-9.1.0/octave/../octave/MSparse.h:31, from /usr/include/octave-9.1.0/octave/../octave/MatrixType.h:33, from /usr/include/octave-9.1.0/octave/../octave/mx-base.h:33, from /usr/include/octave-9.1.0/octave/../octave/Matrix.h:34, from /usr/include/octave-9.1.0/octave/../octave/oct.h:33, from save_fits_image_multi_ext.cc:19: /usr/include/octave-9.1.0/octave/../octave/Array.h:666:20: note: in call to ‘T* Array::fortran_vec() [with T = double; Alloc = std::allocator]’ 666 | OCTARRAY_API T * fortran_vec (); |^~~ save_fits_image.cc: In function ‘octave_value_list Fsave_fits_image(const octave_value_list&, int)’: save_fits_image.cc:132:58: error: passing ‘const NDArray’ as ‘this’ argument discards qualifiers [-fpermissive] 132 | double * datap = const_cast( image.fortran_vec() ); | ~^~ In file included from /usr/include/octave-9.1.0/octave/../octave/Array-util.h:31, from /usr/include/octave-9.1.0/octave/../octave/MSparse.h:31, from /usr/include/octave-9.1.0/octave/../octave/MatrixType.h:33, from /usr/include/octave-9.1.0/octave/../octave/mx-base.h:33, from /usr/include/octave-9.1.0/octave/../octave/Matrix.h:34, from /usr/include/octave-9.1.0/octave/../octave/oct.h:33, from save_fits_image.cc:19: /usr/include/octave-9.1.0/octave/../octave/Array.h:666:20: note: in call to ‘T* Array::fortran_vec() [with T = double; Alloc = std::allocator]’ 666 | OCTARRAY_API T * fortran_vec (); |^~~ make[1]: *** [Makefile:9: save_fits_image_multi_ext.oct] Error 1
Bug#1070915: hiredict: Circular build dependency with redict
Source: hiredict Version: 1.3.1-1 Severity: important Tags: ftbfs X-Debbugs-Cc: Debian Redict Maintainers , Maytham Alsudany Control: affects -1 src:redict https://buildd.debian.org/status/package.php?p=redict=sid https://buildd.debian.org/status/package.php?p=hiredict=sid Circular build dependencies are a pain since they require bootstrapping on every single architecture. I would suggest to drop the buildtime test in hiredict, and run it as autopkgtest instead.
Bug#1070912: libuv1: latest upload reverts time_t transition
Source: libuv1 Version: 1.48.0-2 Severity: serious The latest upload reverts the the time_t transition rename from libuv1 to libuv1t64.
Bug#1070872: libm.a lost fmod + fmodf on i386 + m68k
Package: libc6-dev Version: 2.38-7 Severity: serious Tags: ftbfs Control: affects -1 src:zsh https://buildd.debian.org/status/logs.php?pkg=zsh=5.9-6%2Bb1 ... gcc -static -o zsh main.o `cat stamp-modobjs` -lpcre2-8 -lgdbm -lcap -lncursesw -ltinfo -ltinfo -lrt -lm -lc ... ./obj-static/Src/../../Src/math.c:1260:(.text+0x1d8e): undefined reference to `fmod' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:228: zsh] Error 1 $ objdump -t /usr/lib/i386-linux-gnu/libm.a | grep fmod w_fmodl_compat.o: file format elf32-i386 w_fmod_compat.o: file format elf32-i386 w_fmodf_compat.o: file format elf32-i386 e_fmodl.o: file format elf32-i386 g F .text 0013 __ieee754_fmodl w_fmodl.o: file format elf32-i386 g F .text 0085 __fmodl *UND* __ieee754_fmodl wF .text 0085 fmodf64x wF .text 0085 fmodl e_fmod.o: file format elf32-i386 g F .text 0013 __ieee754_fmod w_fmod.o: file format elf32-i386 e_fmodf.o: file format elf32-i386 g F .text 0013 __ieee754_fmodf w_fmodf.o: file format elf32-i386 e_fmodf128.o: file format elf32-i386 g F .text 0c9b __ieee754_fmodf128 *UND* __ieee754_fmodf128 *UND* __ieee754_fmodf128 w_fmodf128.o: file format elf32-i386 g F .text 0237 __fmodf128 *UND* __ieee754_fmodf128 wF .text 0237 fmodf128 $ With 2.37-13 this is instead: $ objdump -t /usr/lib/i386-linux-gnu/libm.a | grep fmod w_fmodl_compat.o: file format elf32-i386 w_fmod_compat.o: file format elf32-i386 w_fmodf_compat.o: file format elf32-i386 e_fmodl.o: file format elf32-i386 g F .text 0013 __ieee754_fmodl w_fmodl.o: file format elf32-i386 g F .text 0085 __fmodl *UND* __ieee754_fmodl wF .text 0085 fmodf64x wF .text 0085 fmodl e_fmod.o: file format elf32-i386 g F .text 0013 __ieee754_fmod w_fmod.o: file format elf32-i386 g F .text 006b __fmod *UND* __ieee754_fmod wF .text 006b fmodf32x wF .text 006b fmodf64 wF .text 006b fmod e_fmodf.o: file format elf32-i386 g F .text 0013 __ieee754_fmodf w_fmodf.o: file format elf32-i386 g F .text 0063 __fmodf *UND* __ieee754_fmodf wF .text 0063 fmodf32 wF .text 0063 fmodf e_fmodf128.o: file format elf32-i386 g F .text 0cc5 __ieee754_fmodf128 *UND* __ieee754_fmodf128 *UND* __ieee754_fmodf128 w_fmodf128.o: file format elf32-i386 g F .text 0237 __fmodf128 *UND* __ieee754_fmodf128 wF .text 0237 fmodf128 $
Bug#1070853: strace: test failures on 32bit with 64bit time_t
Control: retitle -1 strace: test failures on 32bit The tests also fail on i386, so do not seem to be related to time_t. cu Adrian
Bug#1070865: webkit2gtk/experimental FTBFS on big endian
Source: webkit2gtk Version: 2.45.1-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=webkit2gtk=2.45.1-1 ... In file included from /<>/Source/ThirdParty/skia/include/private/base/SkAPI.h:11, from /<>/Source/ThirdParty/skia/include/private/base/SkAssert.h:11, from /<>/Source/ThirdParty/skia/src/base/SkArenaAlloc.h:11, from /<>/Source/ThirdParty/skia/src/base/SkArenaAlloc.cpp:8: /<>/Source/ThirdParty/skia/include/private/base/SkLoadUserConfig.h:57:6: error: #error "The Skia team is not endian-savvy enough to support big-endian CPUs." 57 | #error "The Skia team is not endian-savvy enough to support big-endian CPUs." | ^ /<>/Source/ThirdParty/skia/include/private/base/SkLoadUserConfig.h:58:6: error: #error "If you still want to use Skia," 58 | #error "If you still want to use Skia," | ^ /<>/Source/ThirdParty/skia/include/private/base/SkLoadUserConfig.h:59:6: error: #error "please define I_ACKNOWLEDGE_SKIA_DOES_NOT_SUPPORT_BIG_ENDIAN." 59 | #error "please define I_ACKNOWLEDGE_SKIA_DOES_NOT_SUPPORT_BIG_ENDIAN." | ^ ...
Bug#1070854: clc-intercal FTBFS: dpkg-genbuildinfo: error: binary build with no binary artifacts found
Source: clc-intercal Version: 1:1.00-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=clc-intercal=1%3A1.00-1 ... chmod +x `pwd`/debian/clc-intercal/usr/bin/* dpkg-genbuildinfo --build=any -O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo dpkg-genbuildinfo: error: binary build with no binary artifacts found; .buildinfo is meaningless dpkg-buildpackage: error: dpkg-genbuildinfo --build=any -O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo subprocess returned exit status 25
Bug#1070853: strace: test failures on 32bit with 64bit time_t
Source: strace Version: 6.8-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=strace=armhf=6.8-1=1715348223=0 https://buildd.debian.org/status/fetch.php?pkg=strace=armel=6.8-1=1715346678=0 https://buildd.debian.org/status/fetch.php?pkg=strace=powerpc=6.8-1=1715349316=0 ... FAIL: strace-k.test PASS: umovestr_cached.test FAIL: strace-k-with-depth-limit.test FAIL: strace-k-demangle.test PASS: strace-DD.test FAIL: strace-k-p.test PASS: strace--tips-full.test PASS: qual_fault-syscall.test PASS: qual_fault.test PASS: filtering_syscall-syntax.test PASS: looping_threads.test == strace 6.8: tests/test-suite.log == # TOTAL: 1350 # PASS: 1057 # SKIP: 289 # XFAIL: 0 # FAIL: 4 # XPASS: 0 # ERROR: 0 ... FAIL: strace-k == + ../src/strace -V + TIMEOUT=timeout -k 5 -s XCPU 1500 + timeout -k 5 -s XCPU 1500 true + [ 1 -eq 0 ] + exec timeout -k 5 -s XCPU 1500 ../../tests/strace-k.test + : 0 + : -k + : --stack-trace + : + [ -f /proc/self/maps ] + check_prog grep + type grep + check_prog readlink + type readlink + check_prog sed + type sed + check_prog tr + type tr + command -v sed + path_to_sed=/usr/bin/sed + [ -x /usr/bin/sed ] + readlink -ev -- /usr/bin/sed + path_to_sed=/usr/bin/sed + /usr/bin/sed -n s/^[^/]\+[[:space:]]\(\/.*\)$/\1/p /proc/self/maps + grep -F -x -e /usr/bin/sed + run_prog ../stack-fcall + [ 1 -eq 0 ] + args=../stack-fcall + ../stack-fcall + [ x0 = x1 ] + run_strace -e chdir -k ../stack-fcall + + args=-e chdir -k ../stack-fcall + ../../src/strace -o log -e chdir -k ../stack-fcall + expected=../../../tests/strace-k.expected + awk_script_common= /^[^ ]/ { if (out != "") print out syscall = gensub(/^([[:alnum:]_]+)\(.*/, "\\1", 1) signal = gensub(/^--- ([A-Z]+) .*/, "\\1", 1) if (syscall != $0) { out = syscall stop = 0 } else if (signal != $0) { out = signal stop = 0 } else { out = "" } } /^ > too many stack frames/ { out = out " _too_many_stack_frames_" stop = 1 } + awk_script_symbol= /^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) / && !stop { sym = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) .*$/, "\\1", 1) out = out " " sym if (sym == "main") stop = 1 } + awk_script_source= /^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) \[0x[a-f0-9]+\] ([^:]+):([0-9]+)$/ && !stop { sym = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) .*$/, "\\1", 1) if (sym == "main" || sym ~ /f[0-9]/) { file = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) \[0x[a-f0-9]+\] ([^:]+):([0-9]+)$/, "\\2", 1) line = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) \[0x[a-f0-9]+\] ([^:]+):([0-9]+)$/, "\\3", 1) sub(".*/", "", file) out = out " " sym "<" file ":" line ">" if (sym == "main") stop = 1 } } + [ --stack-trace = --stack-trace ] + awk_script= /^[^ ]/ { if (out != "") print out syscall = gensub(/^([[:alnum:]_]+)\(.*/, "\\1", 1) signal = gensub(/^--- ([A-Z]+) .*/, "\\1", 1) if (syscall != $0) { out = syscall stop = 0 } else if (signal != $0) { out = signal stop = 0 } else { out = "" } } /^ > too many stack frames/ { out = out " _too_many_stack_frames_" stop = 1 } /^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) / && !stop { sym = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) .*$/, "\\1", 1) out = out " " sym if (sym == "main") stop = 1 } + awk /^[^ ]/ { if (out != "") print out syscall = gensub(/^([[:alnum:]_]+)\(.*/, "\\1", 1) signal = gensub(/^--- ([A-Z]+) .*/, "\\1", 1) if (syscall != $0) { out = syscall stop = 0 } else if (signal != $0) { out = signal stop = 0 } else { out = "" } } /^ > too many stack frames/ { out = out " _too_many_stack_frames_" stop = 1 } /^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) / && !stop { sym = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) .*$/, "\\1", 1) out = out " " sym if (sym == "main") stop = 1 } log + LC_ALL=C grep -E -x -f ../../../tests/strace-k.expected + cat ../../../tests/strace-k.expected + cat out + cat Failed pattern of expected output: ^chdir (__kernel_vsyscall )?(__)?chdir f3 f2 f1 f0 main ^SIGURG (__kernel_vsyscall )?(__)?kill f3 f2 f1 f0 main Actual output: chdir chdir f3 SIGURG kill f3 + pattern= + pattern=No DWARF information found + [ -n No DWARF information found ] + LC_ALL=C grep -x > No DWARF information found + dump_log_and_fail_with ../../src/strace -e chdir -k ../stack-fcall
Bug#1070838: xine-lib-1.2 FTBFS with glibc 2.38
Source: xine-lib-1.2 Version: 1.2.13+hg20230710-2 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=xine-lib-1.2=1.2.13%2Bhg20230710-2%2Bb6 ... dh_makeshlibs -a dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libxine2-bin/DEBIAN/symbols doesn't match completely debian/libxine2-bin.symbols --- debian/libxine2-bin.symbols (libxine2-bin_1.2.13+hg20230710-2+b6_amd64) +++ dpkg-gensymbolsgeNc6J 2024-05-10 10:16:36.253605552 + @@ -404,8 +404,8 @@ xine_post_wire@Base 1.2.0 xine_post_wire_audio_port@Base 1.2.0 xine_post_wire_video_port@Base 1.2.0 - xine_private_strlcat@Base 1.2.9 - xine_private_strlcpy@Base 1.2.9 +#MISSING: 1.2.13+hg20230710-2+b6# xine_private_strlcat@Base 1.2.9 +#MISSING: 1.2.13+hg20230710-2+b6# xine_private_strlcpy@Base 1.2.9 xine_profiler_allocate_slot@Base 1.2.0 xine_profiler_init@Base 1.2.0 xine_profiler_print_results@Base 1.2.0 dh_makeshlibs: error: failing due to earlier errors make: *** [debian/rules:43: binary-arch] Error 25
Bug#1069389: kiwi: FTBFS on arm64: ImportError: sys.meta_path is None, Python is likely shutting down
Hello, On Sat, 2024-04-20 at 14:05 +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on arm64. > (...) > The full build log is available from: > http://qa-logs.debian.net/2024/04/20/kiwi_9.25.22-1_unstable-arm64.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240420;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240420=lu...@debian.org=1=1=1=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please mark it as 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. FWIW, I am already working on updating the kiwi package in Debian to the latest upstream version. However, I ran into some testsuite issues that need to be sorted out upstream first [1]. Thanks, Adrian > [1] https://github.com/OSInside/kiwi/issues/2548 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1070777: onscripter: Please use the same build dependencies on all architectures
Package: onscripter Version: 20220816-1 Severity: normal Build-Depends: ... libvorbis-dev [!arm64 !armel !armhf !mips !mipsel], libvorbisidec-dev [arm64 armel armhf mips mipsel], libsmpeg-dev [!arm64 !armel !armhf !mips !mipsel], libmad0-dev [arm64 armel armhf mips mipsel], ... mips and mipsel are no longer built in unstable. Using libvorbisidec on armhf or arm64 sounds wrong, these architectures do have an FPU in their baseline. Using libvorbisidec on armel sounds justifiable since there is not FPU in the baseline, but since it's unlikely that there are actual users of this package (left) on armel it might be an option to also use libvorbis there. I don't see a good justification for libmad0 instead of libsmpeg, especially on arm64 which has quite powerful processors (e.g. in some Lenovo laptops).
Bug#1070766: gcc-13: Please add sparc64 to gcc-as-needed.diff
Package: gcc-13 Severity: normal Tags: patch X-Debbugs-Cc: debian-sp...@lists.debian.org sparc64 has some spurios library dependencies due to gcc-as-needed.diff currently only adding --as-needed to 32bit-only sparc builds, please append the attached patch to gcc-as-needed.diff Thanks in advance --- a/src/gcc/config/sparc/linux64.h +++ b/src/gcc/config/sparc/linux64.h @@ -90,7 +90,7 @@ along with GCC; see the file COPYING3. If not see { "link_arch_default", LINK_ARCH_DEFAULT_SPEC }, \ { "link_arch",LINK_ARCH_SPEC }, -#define LINK_ARCH32_SPEC "-m elf32_sparc %{shared:-shared} \ +#define LINK_ARCH32_SPEC "-m elf32_sparc %{shared:-shared} %{!fsanitize=*:--as-needed} \ %{!shared: \ %{!static: \ %{rdynamic:-export-dynamic} \ @@ -98,7 +98,7 @@ along with GCC; see the file COPYING3. If not see %{static:-static}} \ " -#define LINK_ARCH64_SPEC "-m elf64_sparc %{shared:-shared} \ +#define LINK_ARCH64_SPEC "-m elf64_sparc %{shared:-shared} %{!fsanitize=*:--as-needed} \ %{!shared: \ %{!static: \ %{rdynamic:-export-dynamic} \
Bug#1064516: Debdifffs for ruby-rack DSA
Hi, attached are debdiffs for a ruby-rack DSA, with the same fixes as in sid and buster. cu Adrian diffstat for ruby-rack-2.1.4 ruby-rack-2.1.4 changelog | 10 + patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch | 51 ++ patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch | 46 + patches/0003-Fixing-ReDoS-in-header-parsing.patch | 30 + patches/series |3 5 files changed, 140 insertions(+) diff -Nru ruby-rack-2.1.4/debian/changelog ruby-rack-2.1.4/debian/changelog --- ruby-rack-2.1.4/debian/changelog2023-06-08 00:52:23.0 +0300 +++ ruby-rack-2.1.4/debian/changelog2024-05-02 23:46:12.0 +0300 @@ -1,3 +1,13 @@ +ruby-rack (2.1.4-3+deb11u2) bullseye-security; urgency=medium + + * Non-maintainer upload. + * CVE-2024-25126: ReDoS in Content Type header parsing + * CVE-2024-26141: Reject Range headers which are too large + * CVE-2024-26146: ReDoS in Accept header parsing + * Closes: #1064516 + + -- Adrian Bunk Thu, 02 May 2024 23:46:12 +0300 + ruby-rack (2.1.4-3+deb11u1) bullseye-security; urgency=high * Add patch to restrict broken mime parsing. diff -Nru ruby-rack-2.1.4/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch ruby-rack-2.1.4/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch --- ruby-rack-2.1.4/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch 1970-01-01 02:00:00.0 +0200 +++ ruby-rack-2.1.4/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch 2024-05-02 23:46:12.0 +0300 @@ -0,0 +1,51 @@ +From bad2b5be29349b285e08d343f060f7c18065d416 Mon Sep 17 00:00:00 2001 +From: Jean Boussier +Date: Wed, 6 Dec 2023 18:32:19 +0100 +Subject: Avoid 2nd degree polynomial regexp in MediaType + +--- + lib/rack/media_type.rb | 13 + + 1 file changed, 9 insertions(+), 4 deletions(-) + +diff --git a/lib/rack/media_type.rb b/lib/rack/media_type.rb +index 41937c99..7fc1e39d 100644 +--- a/lib/rack/media_type.rb b/lib/rack/media_type.rb +@@ -4,7 +4,7 @@ module Rack + # Rack::MediaType parse media type and parameters out of content_type string + + class MediaType +-SPLIT_PATTERN = %r{\s*[;,]\s*} ++SPLIT_PATTERN = /[;,]/ + + class << self + # The media type (type/subtype) portion of the CONTENT_TYPE header +@@ -15,7 +15,11 @@ module Rack + # http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 + def type(content_type) + return nil unless content_type +-content_type.split(SPLIT_PATTERN, 2).first.tap &:downcase! ++if type = content_type.split(SPLIT_PATTERN, 2).first ++ type.rstrip! ++ type.downcase! ++ type ++end + end + + # The media type parameters provided in CONTENT_TYPE as a Hash, or +@@ -27,9 +31,10 @@ module Rack + return {} if content_type.nil? + + content_type.split(SPLIT_PATTERN)[1..-1].each_with_object({}) do |s, hsh| ++ s.strip! + k, v = s.split('=', 2) +- +- hsh[k.tap(&:downcase!)] = strip_doublequotes(v) ++ k.downcase! ++ hsh[k] = strip_doublequotes(v) + end + end + +-- +2.30.2 + diff -Nru ruby-rack-2.1.4/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch ruby-rack-2.1.4/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch --- ruby-rack-2.1.4/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch 1970-01-01 02:00:00.0 +0200 +++ ruby-rack-2.1.4/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch 2024-05-02 23:46:12.0 +0300 @@ -0,0 +1,46 @@ +From ef52af28b6ac43789fd8fc05df098b56f220f0fa Mon Sep 17 00:00:00 2001 +From: Aaron Patterson +Date: Tue, 13 Feb 2024 13:34:34 -0800 +Subject: Return an empty array when ranges are too large + +If the sum of the requested ranges is larger than the file itself, +return an empty array. In other words, refuse to respond with any bytes. + +[CVE-2024-26141] +--- + lib/rack/utils.rb | 3 +++ + test/spec_utils.rb | 4 + 2 files changed, 7 insertions(+) + +diff --git a/lib/rack/utils.rb b/lib/rack/utils.rb +index 16457f90..87c2a946 100644 +--- a/lib/rack/utils.rb b/lib/rack/utils.rb +@@ -382,6 +382,9 @@ module Rack + end + ranges << (r0..r1) if r0 <= r1 + end ++ ++ return [] if ranges.map(&:size).sum > size ++ + ranges + end + module_function :get_byte_ranges +diff --git a/test/spec_utils.rb b/test/spec_utils.rb +index 5fd92241..67b77b0d 100644 +--- a/test/spec_utils.rb b/test/spec_utils.rb +@@ -548,6 +548,10 @@ describe Rack::Utils, "cookies" do + end + + describe Rack::Utils, "byte_range" do ++ it "returns
Bug#1070720: tpm2-tss: test/unit/tcti-spidev failure on 32bit with 64bit time_t
Source: tpm2-tss Version: 4.1.0-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=tpm2-tss=4.1.0-1 ... SKIP: test/unit/tcti-libtpms WARNING:test:test/unit/tcti-libtpms.c:1793:main() _FILE_OFFSET == 64 would produce cmocka errors. SKIP test/unit/tcti-libtpms (exit status: 77) SKIP: test/unit/tcti-device === WARNING:tests:test/unit/tcti-device.c:454:main() _FILE_OFFSET == 64 would produce cmocka errors. SKIP test/unit/tcti-device (exit status: 77) SKIP: test/unit/tcti-pcap = WARNING:tests:test/unit/tcti-pcap.c:736:main() _FILE_OFFSET == 64 would produce cmocka errors. SKIP test/unit/tcti-pcap (exit status: 77) FAIL: test/unit/tcti-spidev === [==] tests: Running 1 test(s). [ RUN ] tcti_spi_init_test ERROR:tcti:src/tss2-tcti/tcti-spidev.c:48:platform_spi_acquire() SPI acquire failed: Bad file descriptor ERROR:tcti:src/tss2-tcti/tcti-spi-helper.c:164:spi_tpm_helper_log_register_access() READ register 0xd40f00 (4 bytes) failed in transaction start ERROR:tcti:src/tss2-tcti/tcti-spidev.c:68:platform_spi_release() SPI release failed: Bad file descriptor ERROR:tcti:src/tss2-tcti/tcti-spidev.c:48:platform_spi_acquire() SPI acquire failed: Bad file descriptor ERROR:tcti:src/tss2-tcti/tcti-spi-helper.c:164:spi_tpm_helper_log_register_access() READ register 0xd40f00 (4 bytes) failed in transaction start ERROR:tcti:src/tss2-tcti/tcti-spidev.c:68:platform_spi_release() SPI release failed: Bad file descriptor ERROR:tcti:src/tss2-tcti/tcti-spidev.c:48:platform_spi_acquire() SPI acquire failed: Bad file descriptor ERROR:tcti:src/tss2-tcti/tcti-spi-helper.c:164:spi_tpm_helper_log_register_access() READ register 0xd40f00 (4 bytes) failed in transaction start ERROR:tcti:src/tss2-tcti/tcti-spidev.c:68:platform_spi_release() SPI release failed: Bad file descriptor ... ERROR:tcti:src/tss2-tcti/tcti-spi-helper.c:164:spi_tpm_helper_log_register_access() READ register 0xd40f00 (4 bytes) failed in transaction start ERROR:tcti:src/tss2-tcti/tcti-spidev.c:68:platform_spi_release() SPI release failed: Bad file descriptor ERROR:tcti:src/tss2-tcti/tcti-spi-helper.c:728:Tss2_Tcti_Spi_Helper_Init() Probing TPM failed [ ERROR ] --- 0xa000a != 0 [ LINE ] --- test/unit/tcti-spidev.c:200: error: Failure! [ FAILED ] tcti_spi_init_test [==] tests: 1 test(s) run. [ PASSED ] 0 test(s). [ FAILED ] tests: 1 test(s), listed below: [ FAILED ] tcti_spi_init_test 1 FAILED TEST(S) FAIL test/unit/tcti-spidev (exit status: 1) SKIP: test/unit/fapi-io === WARNING:tests:test/unit/fapi-io.c:370:main() _FILE_OFFSET == 64 would produce cmocka errors. SKIP test/unit/fapi-io (exit status: 77) Testsuite summary for tpm2-tss 4.1.0 # TOTAL: 61 # PASS: 56 # SKIP: 4 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See ./test-suite.log Please report to https://github.com/tpm2-software/tpm2-tss/issues make[3]: *** [Makefile:33547: test-suite.log] Error 1
Bug#1070715: libboost-regex: Is the libboost-regex*-icu* Provides still needed?
Package: libboost-regex1.83.0 Severity: normal This is something to be checked, perhaps for the next Boost transition. libboost_regex.so is no longer linked with libicu*, likely due to[1]: Regex: Regex is now header only except in C++03 mode. Support for C++03 is now deprecated. [1] https://www.boost.org/users/history/version_1_76_0.html
Bug#1070659: transition: re2
On Mon, May 06, 2024 at 01:09:37PM -0400, Stefano Rivera wrote: >... > included a new dependency on abseil. This broke most of the > reverse-dependencies. It also means that transitions will get more > frequent, as every abseil transition will change re2's ABI. >... Could this be solved through Provides, so that it could be handled with binNMUs during abseil transitions? Example: Package: libboost-regex1.74.0 Depends: ..., libicu72 (>= 72.1~rc-1~),... Provides: libboost-regex1.74.0-icu72 $ cat /var/lib/dpkg/info/libboost-regex1.74.0\:amd64.shlibs libboost_regex 1.74.0 libboost-regex1.74.0-icu72 $ > Stefano cu Adrian
Bug#1070490: libc6: Unpacking libc6:amd64 2.28-10+deb10u3 over 2.28-10+deb10u2 breaks system
On Mon, May 06, 2024 at 05:37:37PM +0100, Adam D. Barratt wrote: > On Mon, 2024-05-06 at 13:02 +0200, Jan Krčmář wrote: > > Package: libc6 > > Version: 2.28-10+deb10u3 > > > > Upgrading the system (Debian 10/Buster) causes corrupted system, > > ending with kernel panic and unbootable system. > > > [...] > > The following packages will be upgraded: > > apt apt-transport-https apt-utils base-files ca-certificates > > The fact that APT is being upgraded here seems strange - APT hasn't > changed in buster for 3 years. What's your base system? There's also > > Unpacking base-files (10.3+deb10u13) over (10.3+deb10u5) ... That's outdated since September 2020. > > Unpacking libc6:amd64 (2.28-10+deb10u3) over (2.28-10+deb10u2) ... > > Replaced by files in installed package libcrypt1:amd64 (1:4.4.18-4) > > ... > > This, on the other hand, looks like you've done something odd to your > system. libcrypt1 doesn't exist until bullseye, so at some point you > have partially upgraded your base system. In conjunction with your pre- > upgrade system apparently having an APT version that's /older/ than the > one in buster, this feels odd. There is related nastiness with partial upgrades from buster to bullseye, see the last two items at [1]. I am not sure whether it is the root cause here, but it's at least plausible that not being able to have the Breaks in libcrypt1 causes problems for such partially upgraded systems. > Regards, > > Adam cu Adrian [1] https://tracker.debian.org/news/1239066/accepted-libxcrypt-14418-3-source-into-unstable/
Bug#1070499: systemd: Please update Homepage
Source: systemd Version: 255.5-1 Severity: minor debian/control:Homepage: https://www.freedesktop.org/wiki/Software/systemd This page has been obsoleted and replaced. All the new contents are on the new website: https://systemd.io/.
Bug#1054109: ocaml: lack of LoongArch support
Hi LiXing, > [0001-Add-LoongArch-support-for-ocaml.patch (text/plain, attachment)] I'm afraid this patch is way too large to be included in a Debian package. Please make sure these changes are being upstreamed, so that native LoongArch support will be part of the next major Ocaml upstream release in Debian. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1070498: libvirt attempts to write to $HOME during the build
Source: libvirt Version: 10.3.0-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=libvirt=amd64=10.3.0-1=1714824148=0 ... 53) completion-command... In '/<>/tests/virshtestdata/completion-command.out': Offset 6 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 54) completion-command-complete ... In '/<>/tests/virshtestdata/completion-command-complete.out': Offset 6 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 55) completion-args ... In '/<>/tests/virshtestdata/completion-args.out': Offset 47 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 56) completion-arg-partial... In '/<>/tests/virshtestdata/completion-arg-partial.out': Offset 26 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 57) completion-arg-full-bool ... In '/<>/tests/virshtestdata/completion-arg-full-bool.out': Offset 7 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 58) completion-arg-full-bool-next ... In '/<>/tests/virshtestdata/completion-arg-full-bool-next.out': Offset 47 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 59) completion-arg-full-string... In '/<>/tests/virshtestdata/completion-arg-full-string.out': Offset 10 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 60) completion-arg-full-string-next ... In '/<>/tests/virshtestdata/completion-arg-full-string-next.out': Offset 47 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 61) completion-arg-full-argv ... In '/<>/tests/virshtestdata/completion-arg-full-argv.out': Offset 10 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 62) completion-arg-full-argv-next ... In '/<>/tests/virshtestdata/completion-arg-full-argv-next.out': Offset 6 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 63) completion-argv-multiple ... In '/<>/tests/virshtestdata/completion-argv-multiple.out': Offset 5 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 64) completion-argv-multiple-next ... In '/<>/tests/virshtestdata/completion-argv-multiple-next.out': Offset 268 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 65) completion-argv-multiple-positional ... In '/<>/tests/virshtestdata/completion-argv-multiple-positional.out': Offset 5 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 66) completion-argv-multiple-positional-next ... In '/<>/tests/virshtestdata/completion-argv-multiple-positional-next.out': Offset 268 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ] ... FAILED 67) completion-arg-positional-empty ... In '/<>/tests/virshtestdata/completion-arg-positional-empty.out': Offset 19 Expect [] Actual [error: Failed to create '/home/buildd/.cache/libvirt/virsh': Permission denied ]
Bug#1070497: webrtc-audio-processing/experimental FTBFS with gcc 13
Source: webrtc-audio-processing Version: 1.0-0.2 Severity: serious Tags: ftbfs https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/webrtc-audio-processing.html https://buildd.debian.org/status/fetch.php?pkg=webrtc-audio-processing=riscv64=1.0-0.2=1706028598=0 ... FAILED: webrtc/modules/audio_processing/libwebrtc-audio-processing-1.so.0.p/transient_file_utils.cc.o c++ -Iwebrtc/modules/audio_processing/libwebrtc-audio-processing-1.so.0.p -Iwebrtc/modules/audio_processing -I../webrtc/modules/audio_processing -Iwebrtc -I../webrtc -I/usr/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++14 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -DWEBRTC_LIBRARY_IMPL -DWEBRTC_ENABLE_SYMBOL_EXPORT -DNDEBUG -DWEBRTC_POSIX -DWEBRTC_LINUX -DWEBRTC_THREAD_RR -DWEBRTC_APM_DEBUG_DUMP=0 -MD -MQ webrtc/modules/audio_processing/libwebrtc-audio-processing-1.so.0.p/transient_file_utils.cc.o -MF webrtc/modules/audio_processing/libwebrtc-audio-processing-1.so.0.p/transient_file_utils.cc.o.d -o webrtc/modules/audio_processing/libwebrtc-audio-processing-1.so.0.p/transient_file_utils.cc.o -c ../webrtc/modules/audio_processing/transient/file_utils.cc In file included from ../webrtc/modules/audio_processing/transient/file_utils.cc:11: ../webrtc/modules/audio_processing/transient/file_utils.h:36:35: error: ‘uint8_t’ does not name a type 36 | int ConvertByteArrayToFloat(const uint8_t bytes[4], float* out); | ^~~ ../webrtc/modules/audio_processing/transient/file_utils.h:17:1: note: ‘uint8_t’ is defined in header ‘’; did you forget to ‘#include ’? 16 | #include "rtc_base/system/file_wrapper.h" +++ |+#include 17 | ../webrtc/modules/audio_processing/transient/file_utils.h:41:36: error: ‘uint8_t’ does not name a type 41 | int ConvertByteArrayToDouble(const uint8_t bytes[8], double* out); |^~~ ../webrtc/modules/audio_processing/transient/file_utils.h:41:36: note: ‘uint8_t’ is defined in header ‘’; did you forget to ‘#include ’? ../webrtc/modules/audio_processing/transient/file_utils.h:46:42: error: ‘uint8_t’ has not been declared 46 | int ConvertFloatToByteArray(float value, uint8_t out_bytes[4]); | ^~~ ../webrtc/modules/audio_processing/transient/file_utils.h:51:44: error: ‘uint8_t’ has not been declared 51 | int ConvertDoubleToByteArray(double value, uint8_t out_bytes[8]); |^~~ ...
Bug#1070495: Should qbe be Architecture: amd64 arm64 riscv64 ?
Source: qbe Version: 1.2-1 Severity: important Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=qbe=1.2-1 ... dh_auto_test -a make -j8 check make[1]: Entering directory '/<>' tools/test.sh all abi1.ssa... /tmp/qbe..s: Assembler messages: /tmp/qbe..s:3: Error: unrecognized opcode: `pushq' /tmp/qbe..s:4: Error: unrecognized opcode: `movq' /tmp/qbe..s:5: Error: unrecognized opcode: `movq' /tmp/qbe..s:6: Error: unrecognized opcode: `addq' /tmp/qbe..s:8: Error: unrecognized opcode: `movb' /tmp/qbe..s:9: Error: unrecognized opcode: `movq' ... 50 of 50 tests failed! make[1]: *** [Makefile:72: check] Error 50 This is due to explicit support required for every architecture, and defaulting to amd64 otherwise: https://sources.debian.org/src/qbe/1.2-1/Makefile/#L44-L54 (The package also builds on m68k/sh4 in ports since these are building with nocheck.) An explicit Architecture: amd64 arm64 riscv64 might be a better option for such a package that needs a backend written for every architecture it supports?
Bug#1070491: rust-pipewire FTBFS on 32bit with 64bit time_t
Source: rust-pipewire Version: 0.8.0-4 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=rust-pipewire=0.8.0-4 ... error[E0308]: mismatched types --> src/thread_loop.rs:142:43 | 142 | nix::sys::time::TimeSpec::new(abstime.tv_sec, abstime.tv_nsec) | - ^^ expected `i64`, found `i32` | | | arguments to this function are incorrect | note: associated function defined here --> /usr/share/cargo/registry/nix-0.27.1/src/sys/time.rs:339:18 | 339 | pub const fn new(seconds: time_t, nanoseconds: timespec_tv_nsec_t) -> Self { | ^^^ help: you can convert an `i32` to an `i64` | 142 | nix::sys::time::TimeSpec::new(abstime.tv_sec.into(), abstime.tv_nsec) | +++ error[E0308]: mismatched types --> src/thread_loop.rs:152:25 | 152 | tv_sec: abstime.tv_sec(), | expected `i32`, found `i64` For more information about this error, try `rustc --explain E0308`. error: could not compile `pipewire` (lib) due to 2 previous errors ...
Bug#1070489: rust-hypothesis FTBFS: test failures
Source: rust-hypothesis Version: 0.11.1-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=rust-hypothesis=0.11.1-1 https://buildd.debian.org/status/logs.php?pkg=rust-hypothesis=0.11.1-2 ... Running `/<>/target/x86_64-unknown-linux-gnu/release/deps/cli-60d293523176a82c --test-threads=1 --skip it_works --skip make --skip sync --skip tag_filter` running 5 tests test add_and_delete_annotation ... FAILED test create_and_leave_group ... FAILED test search_annotations ... FAILED test update_annotation ... FAILED test update_group ... FAILED failures: add_and_delete_annotation stdout Error: path not found Caused by: path not found Location: tests/cli.rs:33:5 create_and_leave_group stdout Error: path not found Caused by: path not found Location: tests/cli.rs:177:5 search_annotations stdout Error: path not found Caused by: path not found Location: tests/cli.rs:114:5 update_annotation stdout Error: path not found Caused by: path not found Location: tests/cli.rs:69:5 update_group stdout thread 'update_group' panicked at 'assertion failed: group_id.is_ok()', tests/cli.rs:218:5 stack backtrace: 0: rust_begin_unwind at /usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5 1: core::panicking::panic_fmt at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14 2: core::panicking::panic at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:117:5 3: cli::update_group at ./tests/cli.rs:218:5 4: cli::update_group::{{closure}} at ./tests/cli.rs:212:22 5: core::ops::function::FnOnce::call_once at /usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5 6: core::ops::function::FnOnce::call_once at /usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. failures: add_and_delete_annotation create_and_leave_group search_annotations update_annotation update_group test result: FAILED. 0 passed; 5 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s error: test failed, to rerun pass `--test cli` Doc-tests hypothesis Running `rustdoc --edition=2021 --crate-type lib --crate-name hypothesis --test /<>/src/lib.rs --target x86_64-unknown-linux-gnu -L dependency=/<>/target/x86_64-unknown-linux-gnu/release/deps -L dependency=/<>/target/release/deps -L native=/<>/target/x86_64-unknown-linux-gnu/release/build/ring-21217903804af83c/out --test-args --test-threads=1 --test-args --skip --test-args it_works --test-args --skip --test-args make --test-args --skip --test-args sync --test-args --skip --test-args tag_filter --extern assert_cmd=/<>/target/x86_64-unknown-linux-gnu/release/deps/libassert_cmd-134b03450b103fd5.rlib --extern chrono=/<>/target/x86_64-unknown-linux-gnu/release/deps/libchrono-366b82fe4c132a7f.rlib --extern clap=/<>/target/x86_64-unknown-linux-gnu/release/deps/libclap-0253bc5809b2cb30.rlib --extern clap_complete=/<>/target/x86_64-unknown-linux-gnu/release/deps/libclap_complete-e7897de87192b73b.rlib --extern color_eyre=/<>/target/x86_64-unknown-linux-gnu/release/deps/libcolor_eyre-9811652bc2e783d9.rlib --extern derive_builder=/<>/target/x86_64-unknown-linux-gnu/release/deps/libderive_builder-b3eb91696292575e.rlib --extern dotenv=/<>/target/x86_64-unknown-linux-gnu/release/deps/libdotenv-9f37bf59e8da3298.rlib --extern eyre=/<>/target/x86_64-unknown-linux-gnu/release/deps/libeyre-913f1aee7266adfa.rlib --extern futures=/<>/target/x86_64-unknown-linux-gnu/release/deps/libfutures-badab9fb8631b2a1.rlib --extern hypothesis=/<>/target/x86_64-unknown-linux-gnu/release/deps/libhypothesis-12767b8516e42793.rlib --extern predicates=/<>/target/x86_64-unknown-linux-gnu/release/deps/libpredicates-53aab59c9f2a01ff.rlib --extern reqwest=/<>/target/x86_64-unknown-linux-gnu/release/deps/libreqwest-1c860df583615e4b.rlib --extern serde=/<>/target/x86_64-unknown-linux-gnu/release/deps/libserde-c2f81dc8b529eb86.rlib --extern serde_json=/<>/target/x86_64-unknown-linux-gnu/release/deps/libserde_json-86e653e5692938d9.rlib --extern thiserror=/<>/target/x86_64-unknown-linux-gnu/release/deps/libthiserror-a30286b97953be04.rlib --extern tokio=/<>/target/x86_64-unknown-linux-gnu/release/deps/libtokio-f2e0886742c2d315.rlib --extern url=/<>/target/x86_64-unknown-linux-gnu/release/deps/liburl-a6463baef11a8609.rlib -C embed-bitcode=no --cfg 'feature="clap"' --cfg 'feature="clap_complete"' --cfg 'feature="cli"' --cfg 'feature="color-eyre"' --cfg 'feature="default"' --cfg 'feature="eyre"' --error-format human` running 18 tests test src/annotations.rs - annotations::InputAnnotation (line 27) ... ok test src/lib.rs - (line 44) - compile ... ok test src/lib.rs - Hypothesis::create_annotation (line 213) ... FAILED test src/lib.rs -
Bug#1056778: Bug is fixed
Dear Maintainer of the gnome-shell package, the bug I have described before, in that the gnome-shell process is leaking memory, is fixed now. Steps I followed and the bug is fixed: * Disable the Open Weather temperature plugin for the Avtivities bar on the top of the screen * Upgrade all packages inside Debian/testing to the newest packages at the 2024-05-02 and 2024-05-03 with apt -u dist-upgrade The gnome-shell process stays now between 400MB and 450MB usage size in random access memory. Thank you very much for your kind attention. Sincerely, Adrian Kiess
Bug#1064516: ruby-rack: diff for NMU version 2.2.7-1.1
Control: tags 1064516 + patch Control: tags 1064516 + pending Dear maintainer, I've prepared an NMU for ruby-rack (versioned as 2.2.7-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it. cu Adrian diffstat for ruby-rack-2.2.7 ruby-rack-2.2.7 changelog | 10 + patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch | 51 ++ patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch | 46 + patches/0003-Fixing-ReDoS-in-header-parsing.patch | 30 + patches/series |3 5 files changed, 140 insertions(+) diff -Nru ruby-rack-2.2.7/debian/changelog ruby-rack-2.2.7/debian/changelog --- ruby-rack-2.2.7/debian/changelog 2023-07-10 17:32:41.0 +0300 +++ ruby-rack-2.2.7/debian/changelog 2024-05-02 22:55:26.0 +0300 @@ -1,3 +1,13 @@ +ruby-rack (2.2.7-1.1) unstable; urgency=high + + * Non-maintainer upload. + * CVE-2024-25126: ReDoS in Content Type header parsing + * CVE-2024-26141: Reject Range headers which are too large + * CVE-2024-26146: ReDoS in Accept header parsing + * Closes: #1064516 + + -- Adrian Bunk Thu, 02 May 2024 22:55:26 +0300 + ruby-rack (2.2.7-1) unstable; urgency=medium * Team Upload diff -Nru ruby-rack-2.2.7/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch ruby-rack-2.2.7/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch --- ruby-rack-2.2.7/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch 1970-01-01 02:00:00.0 +0200 +++ ruby-rack-2.2.7/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch 2024-05-02 22:55:26.0 +0300 @@ -0,0 +1,51 @@ +From e5c0e03f70624433d7132a5eb039f5f04787d20c Mon Sep 17 00:00:00 2001 +From: Jean Boussier +Date: Wed, 6 Dec 2023 18:32:19 +0100 +Subject: Avoid 2nd degree polynomial regexp in MediaType + +--- + lib/rack/media_type.rb | 13 + + 1 file changed, 9 insertions(+), 4 deletions(-) + +diff --git a/lib/rack/media_type.rb b/lib/rack/media_type.rb +index 41937c99..7fc1e39d 100644 +--- a/lib/rack/media_type.rb b/lib/rack/media_type.rb +@@ -4,7 +4,7 @@ module Rack + # Rack::MediaType parse media type and parameters out of content_type string + + class MediaType +-SPLIT_PATTERN = %r{\s*[;,]\s*} ++SPLIT_PATTERN = /[;,]/ + + class << self + # The media type (type/subtype) portion of the CONTENT_TYPE header +@@ -15,7 +15,11 @@ module Rack + # http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 + def type(content_type) + return nil unless content_type +-content_type.split(SPLIT_PATTERN, 2).first.tap &:downcase! ++if type = content_type.split(SPLIT_PATTERN, 2).first ++ type.rstrip! ++ type.downcase! ++ type ++end + end + + # The media type parameters provided in CONTENT_TYPE as a Hash, or +@@ -27,9 +31,10 @@ module Rack + return {} if content_type.nil? + + content_type.split(SPLIT_PATTERN)[1..-1].each_with_object({}) do |s, hsh| ++ s.strip! + k, v = s.split('=', 2) +- +- hsh[k.tap(&:downcase!)] = strip_doublequotes(v) ++ k.downcase! ++ hsh[k] = strip_doublequotes(v) + end + end + +-- +2.30.2 + diff -Nru ruby-rack-2.2.7/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch ruby-rack-2.2.7/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch --- ruby-rack-2.2.7/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch 1970-01-01 02:00:00.0 +0200 +++ ruby-rack-2.2.7/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch 2024-05-02 22:55:26.0 +0300 @@ -0,0 +1,46 @@ +From e4a334bba45d1f66499973d65ba4db2679129153 Mon Sep 17 00:00:00 2001 +From: Aaron Patterson +Date: Tue, 13 Feb 2024 13:34:34 -0800 +Subject: Return an empty array when ranges are too large + +If the sum of the requested ranges is larger than the file itself, +return an empty array. In other words, refuse to respond with any bytes. + +[CVE-2024-26141] +--- + lib/rack/utils.rb | 3 +++ + test/spec_utils.rb | 4 + 2 files changed, 7 insertions(+) + +diff --git a/lib/rack/utils.rb b/lib/rack/utils.rb +index c8e61ea1..72700503 100644 +--- a/lib/rack/utils.rb b/lib/rack/utils.rb +@@ -380,6 +380,9 @@ module Rack + end + ranges << (r0..r1) if r0 <= r1 + end ++ ++ return [] if ranges.map(&:size).sum > size ++ + ranges + end + +diff --git a/test/spec_utils.rb b/test/spec_utils.rb +index 90676258..6b069914 100644 +--- a/test/spec_utils.rb b/test/spec_utils.rb +@@ -590,6 +590,10 @@ describe Rack::Utils, "cookies" do + end + + describe Rack::Utils, "byte_range" do ++ it "returns
Bug#661461: ITA: unadf -- Extract files from an Amiga Disk File dump (.adf)
On Wed, 2024-05-01 at 23:36 +0200, Petter Reinholdtsen wrote: > Hi, > > [John Paul Adrian Glaubitz 2020-05-10] > > I would like to adopt this package. There is a new upstream available and > > the > > repository has been moved to Github with some recent activity [1]. > > What came out of this intent? > > I just migrated the package to a git repository on > https://salsa.debian.org/debian/unadf >. I started working on this, but I got stuck because of the fact that the upstream package is actually not just unadf but a whole library that might need different treatment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1070042: libarchive: archive_entry_stat returns zero size on mips64el with _FILE_OFFSET_BITS=64
On Mon, Apr 29, 2024 at 11:12:54AM +0200, Johannes Schauer Marin Rodrigues wrote: >... > I attached a minimal reproducer. It includes an embedded gzipped tarball with > a > single file called "myfilename" of size 10. It works fine if _FILE_OFFSET_BITS > is not set but with it, it reports a wrong archive member size of zero on > mips64el: >... > st_uid = 1000, st_gid = 1000, st_rdev = 0, st_pad2 = {0, 0, 10}, st_size = > 0, >... > As one can see, the size "10" is not in st_size but in the padding before the > st_size member. This only happens when _FILE_OFFSET_BITS=64 and only on > mips64el. > > Any idea what is going on with mips64el? The assumption that _FILE_OFFSET_BITS=64 would be a NOP on 64-bit is not true on MIPS, where stat and stat64 differ in padding and _FILE_OFFSET_BITS=64 switches stat to the stat64 padding: https://sources.debian.org/src/glibc/2.36-9%2Bdeb12u4/sysdeps/unix/sysv/linux/mips/bits/struct_stat.h/#L149-L156 AC_SYS_LARGEFILE was added to e2fsprogs configure.ac 2 years ago, therefore manual #define _FILE_OFFSET_BITS 64 #define _LARGEFILE64_SOURCE 1 should no longer be necessary for architectures where it is needed. > Thanks! > > cheers, josch cu Adrian BTW: e2fsprogs added AC_USE_SYSTEM_EXTENSIONS 10 years ago, therefore manual #define _GNU_SOURCE 1 could also be removed.
Bug#1070022: libretro-beetle-psx FTBFS on mips64el with -Werror=implicit-function-declaration
Source: libretro-beetle-psx Version: 0.9.38.6+git20151019-3 Severity: serious Tags: ftbfs patch trixie sid https://buildd.debian.org/status/fetch.php?pkg=libretro-beetle-psx=mips64el=0.9.38.6%2Bgit20151019-3%2Bb1=1714231581=0 ... libretro-common/rthreads/rthreads.c: In function ‘scond_wait_timeout’: libretro-common/rthreads/rthreads.c:410:4: error: implicit declaration of function ‘gettimeofday’ [-Werror=implicit-function-declaration] 410 |gettimeofday(, NULL); |^~~~ cc1: some warnings being treated as errors make[2]: *** [Makefile:264: libretro-common/rthreads/rthreads.o] Error 1
Bug#1070021: libretro-beetle-pce-fast FTBFS on mips64el with -Werror=implicit-function-declaration
Source: libretro-beetle-pce-fast Version: 0.9.38.7+git20160609-2 Severity: serious Tags: ftbfs patch trixie sid Forwarded: https://github.com/libretro/libretro-common/commit/20a43ba79fe6b4ec094b3b20b7bc88f4cfe916fa https://buildd.debian.org/status/fetch.php?pkg=libretro-beetle-pce-fast=mips64el=0.9.38.7%2Bgit20160609-2%2Bb1=1714231411=0 ... libretro-common/rthreads/rthreads.c: In function ‘scond_wait_timeout’: libretro-common/rthreads/rthreads.c:423:4: error: implicit declaration of function ‘gettimeofday’ [-Werror=implicit-function-declaration] 423 |gettimeofday(, NULL); |^~~~ cc1: some warnings being treated as errors make[2]: *** [Makefile:332: libretro-common/rthreads/rthreads.o] Error 1
Bug#1070018: ausweisapp: Mising dependency to libqt6svg6
Hello Juergen, On Sun, 2024-04-28 at 18:09 +0200, Juergen Bausa wrote: > I run ausweisapp backport on bookworm. However, it doesnt display an icon in > the control panel of KDE. > Ausweisapp2 (which is actually a slightly older version) did display an icon. > While ausweisapp2 depended > on libqt6svg6, ausweisapp does not. Aftre installing libqt6svg6 manually the > icon is displayed in ausweisapp > also. So I think the dependency on libqt6svg6 is just missing in ausweisapp. This is a known issue and a result of a potential bug in Qt6 which results in dpkg-shlibdeps not adding the runtime dependency for libqt6svg6 during build. While I could hardwire libqt6svg6 as a runtime dependency into debian/control, this would cause problems when the ABI of the Qt6 SVG library is being bumped resulting in the library package being renamed from libqt6svg6 to libqt6svg7. Currently, the workaround is to install the missing libqt6svg6 package manually. > In addition it seems to me that the window of AusweisApp looks extremely > clean (just white background). > Ausweisapp2 was much more colourful. I guess that another lib is missing for > ausweisapp to display > the intended look. No, this is by design. The upstream developers have decided to make the user interface as minimalistic as possible. I'm not such a fan of the new design either, but that's just how it looks now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1070002: rust-alsa FTBFS on 32bit with 64bit time_t
Source: rust-alsa Version: 0.8.1-3 Severity: serious Tags: ftbfs Control: affects -1 src:rust-cpal https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/rust-alsa.html https://buildd.debian.org/status/fetch.php?pkg=rust-cpal=armhf=0.15.2-3%2Bb1=1714250098=0 ... error: cannot construct `timespec` with struct literal syntax due to private fields --> /usr/share/cargo/registry/alsa-0.8.1/src/pcm.rs:1113:21 | 1113 | let mut h = timespec {tv_sec: 0, tv_nsec: 0}; | | = note: ... and other private field `__pad` that was not provided error: cannot construct `timespec` with struct literal syntax due to private fields --> /usr/share/cargo/registry/alsa-0.8.1/src/pcm.rs:1119:21 | 1119 | let mut h = timespec {tv_sec: 0, tv_nsec: 0}; | | = note: ... and other private field `__pad` that was not provided error: cannot construct `timespec` with struct literal syntax due to private fields --> /usr/share/cargo/registry/alsa-0.8.1/src/pcm.rs:1125:21 | 1125 | let mut h = timespec {tv_sec: 0, tv_nsec: 0}; | | = note: ... and other private field `__pad` that was not provided error: could not compile `alsa` due to 3 previous errors ...
Bug#1070001: rust-net2 FTBFS on 32bit with 64bit time_t
Source: rust-net2 Version: 0.2.37-1 Severity: serious Tags: ftbfs trixie sid https://buildd.debian.org/status/fetch.php?pkg=rust-net2=armhf=0.2.37-1%2Bb1=1714277125=0 ... error[E0308]: mismatched types --> src/ext.rs:902:22 | 902 | tv_usec: (d % 1000) as suseconds_t, | ^ expected `i64`, found `i32` For more information about this error, try `rustc --explain E0308`. error: could not compile `net2` due to previous error ...
Bug#1070000: rust-time-0.1 FTBFS on 32bit with 64bit time_t
Source: rust-time-0.1 Version: 0.1.44-2 Severity: serious Tags: ftbfs trixie sid https://buildd.debian.org/status/fetch.php?pkg=rust-time-0.1=armhf=0.1.44-2%2Bb1=1714295931=0 ... error: cannot construct `timespec` with struct literal syntax due to private fields --> src/sys.rs:521:26 | 521 | let mut tv = libc::timespec { tv_sec: 0, tv_nsec: 0 }; | ^^ | = note: ... and other private field `__pad` that was not provided error: cannot construct `timespec` with struct literal syntax due to private fields --> src/sys.rs:527:26 | 527 | let mut ts = libc::timespec { tv_sec: 0, tv_nsec: 0 }; | ^^ | = note: ... and other private field `__pad` that was not provided error: cannot construct `timespec` with struct literal syntax due to private fields --> src/sys.rs:555:24 | 555 | t: libc::timespec { |^^ | = note: ... and other private field `__pad` that was not provided error: could not compile `time` due to 3 previous errors ...
Bug#1069999: rust-unix-socket FTBFS on 32bit with 64bit time_t
Source: rust-unix-socket Version: 0.5.0-2 Severity: serious Tags: ftbfs trixie sid https://buildd.debian.org/status/fetch.php?pkg=rust-unix-socket=armhf=0.5.0-2%2Bb1=1714298139=0 ... error[E0308]: mismatched types --> src/lib.rs:122:30 | 122 | tv_usec: usecs, | ^ expected `i64`, found `i32` For more information about this error, try `rustc --explain E0308`. warning: `unix_socket` (lib) generated 31 warnings error: could not compile `unix_socket` due to previous error; 31 warnings emitted ...
Bug#1069998: rust-datetime FTBFS on 32bit with 64bit time_t
Source: rust-datetime Version: 0.5.2-5 Severity: serious Tags: ftbfs trixie sid Control: affects -1 src:rust-zoneinfo-compiled https://buildd.debian.org/status/fetch.php?pkg=rust-datetime=armhf=0.5.2-5%2Bb1=1714252645=0 ... error: cannot construct `timespec` with struct literal syntax due to private fields --> src/system.rs:74:18 | 74 | let mut tv = libc::timespec { tv_sec: 0, tv_nsec: 0 }; | ^^ | = note: ... and other private field `__pad` that was not provided ...
Bug#1069993: rust-filetime FTBFS on 32bit with 64bit time_t
Source: rust-filetime Version: 0.2.22-1 Severity: serious Tags: ftbfs Control: affects -1 src:rust-notify src:rust-async-tar src:rust-cargo-util src:rust-cp-r https://buildd.debian.org/status/fetch.php?pkg=rust-filetime=armhf=0.2.22-1%2Bb1=1714259218=0 ... error[E0308]: mismatched types --> src/unix/utimes.rs:117:18 | 117 | tv_usec: (ft.nanoseconds() / 1000) as libc::suseconds_t, | ^^ expected `i64`, found `i32` For more information about this error, try `rustc --explain E0308`. error: could not compile `filetime` due to previous error ...
Bug#1069992: rust-socket2 FTBFS on 32bit with 64bit time_t
Source: rust-socket2 Version: 0.5.5-1 Severity: serious Tags: ftbfs Control: affects -1 src:rust-quinn-udp src:rust-oauth2 src:rust-nispor src:rust-netlink-proto src:rust-nb-connect src:rust-debbugs src:rust-dns-lookup src:rust-erbium-net src:rust-ethtool src:rust-genetlink src:rust-git2-curl src:rust-hyper-tls src:rust-mozim src:rust-mptcp-pm src:rust-curl https://buildd.debian.org/status/fetch.php?pkg=rust-socket2=armhf=0.5.5-1%2Bb1=1714293496=0 ... error[E0308]: mismatched types --> src/sys/unix.rs:1137:22 | 1137 | tv_usec: duration.subsec_micros() as libc::suseconds_t, | ^ expected `i64`, found `i32` For more information about this error, try `rustc --explain E0308`. error: could not compile `socket2` due to previous error ...
Bug#1069980: haskell-futhark FTBFS: Missing build dependency on alex
Source: haskell-futhark Version: 0.25.15-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=haskell-futhark=0.25.15-1 ... CallStack (from HasCallStack): withMetadata, called at libraries/Cabal/Cabal/src/Distribution/Simple/Utils.hs:370:14 in Cabal-3.8.1.0:Distribution.Simple.Utils Error: hlibrary.setup: The program 'alex' is required but it could not be ...
Bug#1069834: sccache FTBFS with itoa != 0.3.4
Source: sccache Version: 0.8.0-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=sccache=0.8.0-1 ... test test_rust_cargo_cmd_readonly_preemtive_block ... FAILED failures: test_rust_cargo_cmd_readonly_preemtive_block stdout Error: Unexpected failure. code=101 stderr=`` error: failed to select a version for the requirement `itoa = \"^0.3.4\"` (locked to 0.3.4) candidate versions found which didn\'t match: 1.0.9 location searched: directory source `/<>/debian/cargo_registry` (which is replacing registry `crates-io`) required by package `test-crate v0.1.0 (/<>/tests/test-crate)` perhaps a crate was updated and forgotten to be re-vendored? ``` ``` command=`cd "tests/test-crate" && CARGO_INCREMENTAL="0" CARGO_TARGET_DIR="/<>/debian/sccache_test_rust_cargoG4h5iT/cargo" RUSTC_WRAPPER="/<>/target/x86_64-unknown-linux-gnu/release/sccache" TEST_ENV_VAR="1" "/usr/bin/cargo" "build" "--color=never"` code=101 stdout="" stderr=``` error: failed to select a version for the requirement `itoa = \"^0.3.4\"` (locked to 0.3.4) candidate versions found which didn\'t match: 1.0.9 location searched: directory source `/<>/debian/cargo_registry` (which is replacing registry `crates-io`) required by package `test-crate v0.1.0 (/<>/tests/test-crate)` perhaps a crate was updated and forgotten to be re-vendored? ``` Stack backtrace: 0: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: failures: test_rust_cargo_cmd_readonly_preemtive_block test result: FAILED. 2 passed; 1 failed; 5 ignored; 0 measured; 0 filtered out; finished in 11.18s error: test failed, to rerun pass `--test sccache_cargo` dh_auto_test: error: env DEB_BUILDDIR= /<>/debian/dh-cargo/bin/cargo test returned exit code 101 make[1]: *** [debian/rules:29: override_dh_auto_test] Error 25
Bug#1069685: haskell-language-c-quote: Missing build dependency on alex
Source: haskell-language-c-quote Version: 0.13.0.1-1 Severity: serious Tags: ftbfs X-Debbugs-Cc: Debian Haskell Group , Kari Pahula https://buildd.debian.org/status/logs.php?pkg=haskell-language-c-quote=0.13.0.1-1 ... Error: hlibrary.setup: The program 'alex' version >=3 is required but it could not be found. ...
Bug#1069607: retroarch is built without optimization
Package: retroarch Version: 1.18.0+dfsg-1 Severity: important Tags: ftbfs X-Debbugs-Cc: Jonathan McDowell debian/rules:export DEB_CXXFLAGS_MAINT_STRIP=-O2 debian/rules:export DEB_CFLAGS_MAINT_STRIP=-O2 Building without optimization makes binaries both slower and bigger. The latter is likely also the root cause of the FTBFS on m68k and powerpc.
Bug#1069309: xfractint FTBFS: error: implicit declaration of function
Source: xfractint Version: 20.4.10-4 Severity: serious Tags: ftbfs X-Debbugs-Cc: Petter Reinholdtsen https://buildd.debian.org/status/logs.php?pkg=xfractint=20.4.10-4 ... /usr/bin/gcc -I../headers -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -I./headers -DXFRACT -DNOBSTRING -g -DBIG_ANSI_C -DLINUX -fno-builtin -fcommon -O2 -Wdate-time -D_FORTIFY_SOURCE=2 -c -o 3d.o 3d.c 3d.c: In function ‘longvmultpersp’: 3d.c:290:20: error: implicit declaration of function ‘multiply’ [-Werror=implicit-function-declaration] 290 | tmp[j] += multiply(s[i],m[i][j],bitshift); |^~~~ 3d.c:318:20: error: implicit declaration of function ‘divide’ [-Werror=implicit-function-declaration] 318 | tmpview[0] = divide(lview[0],denom,bitshift); |^~ cc1: some warnings being treated as errors make[3]: *** [: 3d.o] Error 1
Bug#1069222: purple-xmpp-carbons: debian/shlibs.local hardcodes dependency on libpurple0
Package: purple-xmpp-carbons Version: 0.2.3-1 Severity: serious Tags: trixie sid debian/shlibs.local hardcodes a dependency on libpurple0, which makes the package uninstallable on armel/armhf due to the 64-bit time_t rename to libpurple0t64.
Bug#1069136: wabt: Typo in repacksuffix
Source: wabt Version: 1.0.34+dsfg2+~cs1.0.32-1 Severity: normal https://sources.debian.org/src/wabt/1.0.34%2Bdsfg2%2B~cs1.0.32-1/debian/watch/#L2 opts=filenamemangle=s/.+\/@ANY_VERSION@(@ARCHIVE_EXT@)$/@PACKAGE@-$1$2/,repacksuffix=+dsfg \ It's dfsg, not dsfg.
Bug#1062719: bumping qpdf 64-bit time_t for 11.9.0 in experimental
On Sat, Feb 24, 2024 at 05:36:53PM -0500, Jay Berkenbilt wrote: > I need to upload qpdf 11.9.0-1 to unstable. Since this is newer than > 11.8.0-1.1~exp1 in experimental with the 64-bit time_t NMU, it will > cause that to disappear. In an effort to avoid that and keep things in > sync with the time_t transition, I have ported the NMU forward to > 11.9.0-1 and will upload 11.9.0-2~exp1 with the time_t changes to > experimental right after I upload 11.9.0-1 to experimental. I am > hoping that I am not messing anything up with this. Please feel free > to adjust tags, do a separate NMU, or whatever is needed if I have > gotten things out of sync. In any case, I want to get 11.9.0-1 > uploaded right away since I'd like it to sync to Ubuntu before the > 24.04 feature freeze. >... It seems the new version of qpdf in experimental was by accident uploaded to unstable instead of the old version in unstable? It doesn't seem to be a problem in any way, just FYI. cu Adrian
Bug#1061300: lcm: Update to version 1.5.0
On Sat, Feb 03, 2024 at 08:23:05PM +0100, Jose Luis Rivero wrote: > Thanks Vagrant for the reply and the information. > > Updating the info about the 1.5 update, the merge-request is ready to > review and sponsored: > - https://salsa.debian.org/debian/lcm/-/merge_requests/1 It is unlikely that many people would see your merge request, please file a sponsorship request as described at https://mentors.debian.net/sponsors/rfs-howto/ cu Adrian
Bug#1066216: hfsutils: diff for NMU version 3.2.6-15.1
On Sun, 2024-04-14 at 12:57 +0200, Sebastian Ramacher wrote: > I've prepared an NMU for hfsutils (versioned as 3.2.6-15.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. Yes, please set it to 14 days. I am currently going through all my packages one after another to fix these issues. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1060196: fixed in ghc 9.4.7-5
On Fri, 2024-04-12 at 22:35 +, Debian FTP Masters wrote: >* Build unregisterised on powerpc (Closes: #1060196) I am not 100% sure what happened, but this upload produced another broken GHC compiler on powerpc. Lots of packages fail to build now due to GHC segfaulting [1]: Running dh_listpackages libghc-splitmix-dev libghc-splitmix-prof libghc-splitmix-doc -e: error: debian/hlibrary.setup build --builddir=dist-ghc died with signal 11 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 875. Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup build --builddir=dist-ghc died with sig"...) called at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 614 Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup build --builddir=dist-ghc") called at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 477 Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "build", "--builddir=dist-ghc") called at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 656 Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called at -e line 1 make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned exit status 2 Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=haskell-splitmix=powerpc=0.1.0.5-1%2Bb1=1713046430=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1062881: mia: NMU diff for 64-bit time_t transition
On Sat, Feb 03, 2024 at 09:20:05PM +, Graham Inggs wrote: > Source: mia > Version: 2.4.7-13 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t >... Was this forgotten to upload to unstable, or was there a reason why it was deemed unnecessary? Thanks Adrian
Bug#1046444: virtualjaguar: Fails to build source after successful build
Hi, On Sun, 2023-08-13 at 21:21 +0200, Lucas Nussbaum wrote: > Relevant part of the build log: > > cd /<> && runuser -u user42 -- dpkg-buildpackage > > --sanitize-env -us -uc -rfakeroot -S > > - > > > > dpkg-buildpackage: info: source package virtualjaguar > > dpkg-buildpackage: info: source version 2.1.3-2 > > dpkg-buildpackage: info: source distribution unstable > > dpkg-buildpackage: info: source changed by John Paul Adrian Glaubitz > > > > dpkg-source --before-build . > > fakeroot debian/rules clean > > dh clean > > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) > >dh_auto_clean > > dh_auto_clean: warning: Compatibility levels before 10 are deprecated > > (level 9 in use) > > make -j1 clean > > make[1]: Entering directory '/<>' > > -ne [01;33m***[00;32m Cleaning out the garbage...[00m > > done! > > make[1]: Leaving directory '/<>' > >dh_clean > > dh_clean: warning: Compatibility levels before 10 are deprecated (level 9 > > in use) > > dpkg-source -b . > > dpkg-source: info: using source format '3.0 (quilt)' > > dpkg-source: info: building virtualjaguar using existing > > ./virtualjaguar_2.1.3.orig.tar.bz2 > > dpkg-source: info: using patch list from debian/patches/series > > dpkg-source: warning: ignoring deletion of file src/m68000/m68kdasm.c.bak, > > use --include-removal to override > > dpkg-source: info: local changes detected, the modified files are: > > virtualjaguar-2.1.3/.qmake.stash > > virtualjaguar-2.1.3/src/version.h > > dpkg-source: error: aborting due to unexpected upstream changes, see > > /tmp/virtualjaguar_2.1.3-2.diff.v1VkyG > > dpkg-source: info: Hint: make sure the version in debian/changelog matches > > the unpacked source tree > > dpkg-source: info: you can integrate the local changes with dpkg-source > > --commit > > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2 > > > > E: Command 'cd /<> && runuser -u user42 -- dpkg-buildpackage > > --sanitize-env -us -uc -rfakeroot -S' failed to run. After close inspection of the build log and the original tarball, it turns out that the tarball used is not identical to the one available from the upstream FTP server [1]: glaubitz@z6:~/debian> wget -q http://icculus.org/virtualjaguar/tarballs/virtualjaguar-2.1.3.tar.bz2 -O virtualjaguar-upstream-2.1.3.tar.bz2 glaubitz@z6:~/debian> md5sum virtualjaguar-upstream-2.1.3.tar.bz2 virtualjaguar_2.1.3.orig.tar.bz2 17af87b3a7cfd9106e49afc56d4858e6 virtualjaguar-upstream-2.1.3.tar.bz2 0e3f30737c171c096ac2690a38f7029a virtualjaguar_2.1.3.orig.tar.bz2 glaubitz@z6:~/debian> Further inspection reveals that the file src/m68000/m68kdasm.c.bak that is deleted during build and prevents a second successful build is not part of the original source: glaubitz@z6:~/debian> tar tf virtualjaguar_2.1.3.orig.tar.bz2 |grep bak linux-2.1.3/src/m68000/m68kdasm.c.bak glaubitz@z6:~/debian> tar tf virtualjaguar-upstream-2.1.3.tar.bz2 |grep bak glaubitz@z6:~/debian> I don't really remember how I created the first upload of the 2.1.3 upstream version, but since upstream development has ceased, I can upload a fixed version only with a forged upstream version using "really" or similar since there won't be a new upstream release unless the upstream project is forked. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1066383: virtualjaguar: FTBFS: ./inlines.h:82:20: error: implicit declaration of function ‘m68k_read_memory_32’ [-Werror=implicit-function-declaration]
Control: tags -1 +patch Hi, On Wed, 2024-03-13 at 12:46 +0100, Lucas Nussbaum wrote: > Relevant part (hopefully): > > gcc -MMD -g -O2 -Werror=implicit-function-declaration > > -ffile-prefix-map=/<>=. -fstack-protector-strong > > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection > > -I. -I./obj `sdl-config --cflags` -c obj/cpustbl.c -o obj/cpustbl.o > > In file included from obj/cpustbl.c:3: > > ./inlines.h: In function ‘m68k_do_rts’: > > ./inlines.h:82:20: error: implicit declaration of function > > ‘m68k_read_memory_32’ [-Werror=implicit-function-declaration] > >82 | m68k_setpc(m68k_read_memory_32(m68k_areg(regs, 7))); > > |^~~ > > ./inlines.h: In function ‘m68k_do_bsr’: > > ./inlines.h:89:9: error: implicit declaration of function > > ‘m68k_write_memory_32’ [-Werror=implicit-function-declaration] > >89 | m68k_write_memory_32(m68k_areg(regs, 7), oldpc); > > | ^~~~ > > ./inlines.h: In function ‘get_ibyte_prefetch’: > > ./inlines.h:111:25: error: implicit declaration of function > > ‘m68k_read_memory_8’ [-Werror=implicit-function-declaration] > > 111 | #define get_ibyte(o)m68k_read_memory_8(regs.pc + (o) + 1) > > | ^~ > > ./inlines.h:158:16: note: in expansion of macro ‘get_ibyte’ > > 158 | return get_ibyte(o); > > |^ > > ./inlines.h: In function ‘get_iword_prefetch’: > > ./inlines.h:112:25: error: implicit declaration of function > > ‘m68k_read_memory_16’ [-Werror=implicit-function-declaration] > > 112 | #define get_iword(o)m68k_read_memory_16(regs.pc + (o)) > > | ^~~ > > ./inlines.h:183:16: note: in expansion of macro ‘get_iword’ > > 183 | return get_iword(o); > > |^ > > cc1: some warnings being treated as errors > > make[2]: *** [Makefile:58: obj/cpustbl.o] Error 1 Thanks for the bug report! The attached patch fixes the problem for me. I'm going to upload an updated packages soon which will also include fixes for #1038585 [1]. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038585 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From d0c699e0c6a0781a6dd2f89492b38f9a1d50fa9c Mon Sep 17 00:00:00 2001 From: John Paul Adrian Glaubitz Date: Sat, 13 Apr 2024 11:18:38 +0200 Subject: [PATCH] Fix missing inclusion of m68kinterface.h in src/m68000/inlines.h --- src/m68000/inlines.h | 1 + 1 file changed, 1 insertion(+) diff --git a/src/m68000/inlines.h b/src/m68000/inlines.h index 54de932..c037bd9 100644 --- a/src/m68000/inlines.h +++ b/src/m68000/inlines.h @@ -11,6 +11,7 @@ #define __INLINES_H__ #include "cpudefs.h" +#include "m68kinterface.h" STATIC_INLINE int cctrue(const int cc) { -- 2.44.0
Bug#1068880: fwbuilder FTBFS: error: debhelper compat level specified both in debian/compat and in debian/control
Source: fwbuilder Version: 5.3.7-7 Severity: serious Tags: ftbfs X-Debbugs-Cc: Jeremy Bícha https://buildd.debian.org/status/logs.php?pkg=fwbuilder=5.3.7-7 ... fakeroot debian/rules clean dh clean dh: warning: Please specify the debhelper compat level exactly once. dh: warning: * debian/compat requests compat 9. dh: warning: * debian/control requests compat 12 via "debhelper-compat (= 12)" dh: warning: dh: warning: Hint: If you just added a build-dependency on debhelper-compat, then please remember to remove debian/compat dh: warning: dh: error: debhelper compat level specified both in debian/compat and in debian/control make: *** [debian/rules:13: clean] Error 255
Bug#1067141: kcemu: FTBFS with -Werror=implicit-function-declaration
Hello Zixing, On Wed, 2024-04-10 at 17:34 -0600, Zixing Liu wrote: > In Ubuntu, the attached patch was applied to achieve the following: > > * debian/patches/add-missing-includes.patch: Add missing includes. > Closes LP: #2060887. The issue has already been fixed upstream. I am waiting for upstream to make a new release as this would also fix #970666 [1]. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970666 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1068655: lomiri-telephony-service FTBFS with abseil 20230802.1
On Wed, Apr 10, 2024 at 09:02:50PM +, Mike Gabriel wrote: > Hi Adrian, Hi Mike, >... > I'd appreciate if you could take a look and shed some light on this. >... I would have mentioned if I had a clue about this, but I don't. In places like #debian-devel there might be people who understand at first sight what the problem might be. > Thanks! > Mike cu Adrian
Bug#1068586: ghc: Broken on arm{el,hf} because of time_t transition
[ Steve added, for the symbol list question ] On Tue, Apr 09, 2024 at 09:44:43PM +0300, Ilias Tsitsimpis wrote: > On Tue, Apr 09, 2024 at 08:53PM, Adrian Bunk wrote: > > On Tue, Apr 09, 2024 at 07:23:29PM +0300, Ilias Tsitsimpis wrote: > > > I believe it's not. haskell-hourglass used to work on arm{el,hf} just > > > before the time64 transition. > > > > before this transition x32 was the only 32bit architecture with 64bit > > time_t. > > Aha! Didn't know that, thanks for flagging this. I am surprised that we > hadn't noticed this earlier (as we see now, GHC is completely broken). I wouldn't call it "completely broken". I'm too lazy to get exact numbers, but the arm{el,hf} situation is more like 1000 packages built (a large part with tests) and 10 failed. >... > > > We need a way to identify every package that is broken. > > > > $ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | > > grep gettimeofday > > U gettimeofday@GLIBC_2.4 > > ... > > > > $ nm -D > > /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSdirectory-1.3.7.1-ghc9.4.7.so | > > grep utimensat > > ... > > U utimensat@GLIBC_2.6 > > > > $ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | > > grep localtime > > U __localtime64_r@GLIBC_2.34 > > Thank you! Can we maybe run this against all Haskell libraries and > identify the ones that are currently broken? Maybe we have such a script > already for the time64 transition. Steve, do you have a list of all bad symbols for the time_t transition? With this list it should be possible to just install all currently installable Haskell packages on a porterbox and do something like $ for s in gettimeofday utimensat localtime localtime_r; do for f in /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/*.so /usr/lib/haskell-packages/ghc/lib/arm-linux-ghc-9.4.7/*.so; do nm -D $f | grep $s@ && echo $f; done; done U gettimeofday@GLIBC_2.4 /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so U utimensat@GLIBC_2.6 /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSdirectory-1.3.7.1-ghc9.4.7.so U utimensat@GLIBC_2.6 /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSunix-2.7.3-ghc9.4.7.so $ That last one is likely libraries/unix/System/Posix/Files/Common.hsc:foreign import ccall unsafe "utimensat" > > But the last one is the broken localtime_r one, is anything going wrong > > with the ccall from TimeZone.hs to cbits there? > > > > get_current_timezone_seconds() returning long is wrong, > > and might contribute to that bug: > > > > foreign import ccall unsafe "HsTime.h get_current_timezone_seconds" > > get_current_timezone_seconds :: > > CTime -> Ptr CInt -> Ptr CString -> IO CLong > > ... > > getTimeZoneCTime ctime = > > ... > > secs <- get_current_timezone_seconds ctime pdst pcname > > > > I don't know Haskell, but is this declaring ctime as CLong, > > and then passing it instead of a CTime? > > I believe it returns the timezone in seconds (i.e., 3600 for +1 hour > timezone), so CLong should be large enough to hold this value. My guess > right now is that it fails due to the bogus CTime value that we pass, we > need to test this. Yes, I suspect that this function with CTime -> Ptr CInt -> Ptr CString -> IO CLong gets called as CLong -> Ptr CInt -> Ptr CString -> IO CLong but I'm surprised if Haskell does not catch something like that at compile time. > Ilias cu Adrian
Bug#1068723: quickflux: binary-any FTBFS
Source: quickflux Version: 1.1.3+git20201110.2a37acf-1 Severity: serious Tags: ftbfs X-Debbugs-Cc: Debian UBports Team https://buildd.debian.org/status/logs.php?pkg=quickflux=1.1.3%2Bgit20201110.2a37acf-1 ... debian/rules override_dh_installexamples make[1]: Entering directory '/<>' dh_installexamples rm debian/quickflux-doc/usr/share/doc/quickflux-doc/examples/middleware/.gitignore rm: cannot remove 'debian/quickflux-doc/usr/share/doc/quickflux-doc/examples/middleware/.gitignore': No such file or directory make[1]: *** [debian/rules:33: override_dh_installexamples] Error 1
Bug#1068586: ghc: Broken on arm{el,hf} because of time_t transition
On Tue, Apr 09, 2024 at 07:23:29PM +0300, Ilias Tsitsimpis wrote: > Hi Adrian, Hi Ilias, > On Tue, Apr 09, 2024 at 12:56PM, Adrian Bunk wrote: > > FTR, in haskell-hourglass this is #1001686 which already failed on x32 > > for this reason. > > I believe it's not. haskell-hourglass used to work on arm{el,hf} just > before the time64 transition. before this transition x32 was the only 32bit architecture with 64bit time_t. > > My reading of the code is that this happens when > > libraries/time/lib/cbits/HsTime.c returns 0x8000 due to > > localtime_r() called in this function returning an error. > > > > The "localtime_r failed" is from > > libraries/time/lib/Data/Time/LocalTime/Internal/TimeZone.hs >... > The fix here is to backport (at least) the following patches which > change these calls to use the capi calling convention: > > * > https://gitlab.haskell.org/ghc/packages/time/-/commit/d52314edb138b6ecd7e888c588f83917b0ee2c29 > * > https://gitlab.haskell.org/ghc/packages/directory/-/commit/f6b288bd96fba5a955d1f73663eb52c1859ee765 This localtime_r issue I mentioned is not covered in the above commit in time. >... > We need a way to identify every package that is broken. $ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | grep gettimeofday U gettimeofday@GLIBC_2.4 ... $ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSdirectory-1.3.7.1-ghc9.4.7.so | grep utimensat ... U utimensat@GLIBC_2.6 $ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | grep localtime U __localtime64_r@GLIBC_2.34 But the last one is the broken localtime_r one, is anything going wrong with the ccall from TimeZone.hs to cbits there? get_current_timezone_seconds() returning long is wrong, and might contribute to that bug: foreign import ccall unsafe "HsTime.h get_current_timezone_seconds" get_current_timezone_seconds :: CTime -> Ptr CInt -> Ptr CString -> IO CLong ... getTimeZoneCTime ctime = ... secs <- get_current_timezone_seconds ctime pdst pcname I don't know Haskell, but is this declaring ctime as CLong, and then passing it instead of a CTime? > Ilias cu Adrian
Bug#1068586: ghc: Broken on arm{el,hf} because of time_t transition
On Sun, Apr 07, 2024 at 05:18:06PM +0300, Ilias Tsitsimpis wrote: > Package: ghc > Version: 9.4.7-3 > Severity: grave > Justification: renders package unusable > > I recently uploaded a new version of GHC to unstable, in order to fix > #1068179. As a result, GHC got rebuilt taking into account the new size > for time_t on arm{el,hf}. This is evident from the build logs, where > we now see: > > > https://buildd.debian.org/status/fetch.php?pkg=ghc=armel=9.4.7-4=1712410679=0 > > checking Haskell type for time_t... Int64 > > whereas previously we had: > > > https://buildd.debian.org/status/fetch.php?pkg=ghc=armel=9.4.7-3=1708366014=0 > > checking Haskell type for time_t... Int32 > > > After this change, a number of Haskell packages have started to FTBFS: > > * > https://buildd.debian.org/status/fetch.php?pkg=haskell-filestore=armel=0.6.5-3%2Bb2=1712457355=0 > * > https://buildd.debian.org/status/fetch.php?pkg=haskell-fold-debounce=armel=0.2.0.11-1%2Bb2=1712466208=0 > * > https://buildd.debian.org/status/fetch.php?pkg=haskell-hourglass=armel=0.2.12-5%2Bb2=1712462130=0 FTR, in haskell-hourglass this is #1001686 which already failed on x32 for this reason. > Looking into this, I see that (at least) the getPOSIXTime method is > broken on arm{el,hf}. >... https://buildd.debian.org/status/fetch.php?pkg=haskell-lambdahack=armhf=0.11.0.0-4%2Bb1=1712562043=0 https://buildd.debian.org/status/fetch.php?pkg=haskell-hledger-lib=armhf=1.30-1%2Bb1=1712566894=0 Exception: user error (localtime_r failed) My reading of the code is that this happens when libraries/time/lib/cbits/HsTime.c returns 0x8000 due to localtime_r() called in this function returning an error. The "localtime_r failed" is from libraries/time/lib/Data/Time/LocalTime/Internal/TimeZone.hs > Ilias cu Adrian
Bug#1068691: util-linux: enosys program missing on m68k and sh4
Hi Christian, On Tue, 2024-04-09 at 10:00 +0200, Chris Hofstaedtler wrote: > * John Paul Adrian Glaubitz [240409 09:36]: > > the program enosys doesn't seem to be available on m68k and sh4, so it > > needs to > > be excluded from the install files with the help of dh-exec: > > I imagine the other option is to expand audit-arch.h to cover these > archs. Do you mind reviewing this, then I could sent it upstream? Do > note that I've mostly guessed what might be right. Ah, I wasn't aware it's related to seccomp ;-). > Relevant uapi header: > https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/audit.h#L432 > > diff --git a/include/audit-arch.h b/include/audit-arch.h > index ade182417..9afc663cd 100644 > --- a/include/audit-arch.h > +++ b/include/audit-arch.h > @@ -35,6 +35,8 @@ > #endif > #elif __powerpc__ > #define SECCOMP_ARCH_NATIVE AUDIT_ARCH_PPC > +#elif __m68k__ > +#define SECCOMP_ARCH_NATIVE AUDIT_ARCH_M68K > #elif __mips__ > #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ > # define SECCOMP_ARCH_NATIVE AUDIT_ARCH_MIPS > @@ -47,6 +49,12 @@ > #else > # define SECCOMP_ARCH_NATIVE AUDIT_ARCH_ARCV2 > #endif > +#elif __sh__ > +#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ > +# define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SH > +#else > +# define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SHEL > +#endif > #elif __sparc__ > #if __SIZEOF_POINTER__ == 4 > # define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SPARC Looks good to me. I was actually the person who added support for m68k and sh4 to libseccomp. Unfortunately, upstream still hasn't released the a new stable version which includes my patches. This is planned for 2.6.0. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1068691: util-linux: enosys program missing on m68k and sh4
Source: util-linux Version: 2.40-5 Severity: normal User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hello, the program enosys doesn't seem to be available on m68k and sh4, so it needs to be excluded from the install files with the help of dh-exec: dh_install \ -Nfdisk-udeb -Nlibblkid1-udeb \ -Nlibfdisk1-udeb -Nlibsmartcols1-udeb -Nlibuuid1-udeb \ -Nutil-linux-udeb dh_install: warning: Cannot find (any matches for) "usr/bin/enosys" (tried in ., debian/tmp) Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1068657: pkcs11-provider FTBFS with openssl 3.2.1-3
Source: pkcs11-provider Version: 0.3-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=pkcs11-provider=ppc64el=0.3-1%2Bb2=1712517987=0 ... FAIL: basic-softhsm === Executing ./tbasic ## Raw Sign check error openssl pkeyutl -sign -inkey "${BASEURI}" -pkeyopt pad-mode:none -in ${TMPPDIR}/64Brandom.bin -out ${TMPPDIR}/raw-sig.bin Public Key operation error 00493C8EFF7F:error:027A:rsa routines:p11prov_sig_operate:data too small for key size:signature.c:894: ## Sign and Verify with provided Hash and RSA openssl dgst -sha256 -binary -out ${TMPPDIR}/sha256.bin ${SEEDFILE} openssl pkeyutl -sign -inkey "${PRIURI}" -in ${TMPPDIR}/sha256.bin -out ${TMPPDIR}/sha256-sig.bin openssl pkeyutl -verify -inkey "${PUBURI}" -pubin -in ${TMPPDIR}/sha256.bin -sigfile ${TMPPDIR}/sha256-sig.bin Signature Verified Successfully ## Sign and Verify with provided Hash and RSA with DigestInfo struct openssl dgst -sha256 -binary -out ${TMPPDIR}/sha256.bin ${SEEDFILE} openssl pkeyutl -sign -inkey "${PRIURI}" -pkeyopt digest:sha256 -in ${TMPPDIR}/sha256.bin -out ${TMPPDIR}/sha256-sig.bin openssl pkeyutl -verify -inkey "${PUBURI}" -pkeyopt digest:sha256 -pubin -in ${TMPPDIR}/sha256.bin -sigfile ${TMPPDIR}/sha256-sig.bin Signature Verified Successfully ## DigestSign and DigestVerify with RSA openssl pkeyutl -sign -inkey "${BASEURI}" -digest sha256 -in ${RAND64FILE} -rawin -out ${TMPPDIR}/sha256-dgstsig.bin openssl pkeyutl -verify -inkey "${BASEURI}" -pubin -digest sha256 -in ${RAND64FILE} -rawin -sigfile ${TMPPDIR}/sha256-dgstsig.bin Signature Verified Successfully openssl pkeyutl -verify -inkey "${PUBURI}" -pubin -digest sha256 -in ${RAND64FILE} -rawin -sigfile ${TMPPDIR}/sha256-dgstsig.bin Signature Verified Successfully RSA basic encrypt and decrypt openssl pkeyutl -encrypt -inkey "${PUBURI}" -pubin -in ${SECRETFILE} -out ${SECRETFILE}.enc openssl pkeyutl -decrypt -inkey "${PRIURI}" -in ${SECRETFILE}.enc -out ${SECRETFILE}.dec ## Test Disallow Public Export openssl pkey -in $PUBURI -pubin -pubout -text ## Test CSR generation from RSA private keys openssl req -new -batch -key "${PRIURI}" -out ${TMPPDIR}/rsa_csr.pem openssl req -in ${TMPPDIR}/rsa_csr.pem -verify -noout Certificate request self-signature verify OK ## Test fetching public keys without PIN in config files openssl pkey -in $PUBURI -pubin -pubout -out ${TMPPDIR}/rsa.pub.nopin.pem openssl pkey -in $ECPUBURI -pubin -pubout -out ${TMPPDIR}/ec.pub.nopin.pem openssl pkey -in $ECXPUBURI -pubin -pubout -out ${TMPPDIR}/ecx.pub.nopin.pem ## Test fetching public keys with a PIN in URI openssl pkey -in $BASEURIWITHPIN -pubin -pubout -out ${TMPPDIR}/rsa.pub.uripin.pem openssl pkey -in $ECBASEURIWITHPIN -pubin -pubout -out ${TMPPDIR}/ec.pub.uripin.pem openssl pkey -in $ECXBASEURIWITHPIN -pubin -pubout -out ${TMPPDIR}/ecx.pub.uripin.pem ## Test prompting without PIN in config files ## Test EVP_PKEY_eq on public RSA key both on token ## Test EVP_PKEY_eq on public EC key both on token ## Test EVP_PKEY_eq on public explicit EC key both on token Failed to load key from URI: pkcs11:type=public;id=%00%07 FAIL basic-softhsm.t (exit status: 1) ... Testsuite summary for pkcs11-provider 0.3 # TOTAL: 34 # PASS: 15 # SKIP: 18 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See tests/test-suite.log Please report to s...@redhat.com make[4]: *** [Makefile:1070: test-suite.log] Error 1
Bug#1068656: pgsql-http accesses the internet during the build
Source: pgsql-http Version: 1.6.0-1 Severity: serious Tags: ftbfs X-Debbugs-Cc: Debian PostgreSQL Maintainers https://buildd.debian.org/status/fetch.php?pkg=pgsql-http=arm64=1.6.0-1=1712600451=0 ... regression.diffs diff -U3 /<>/expected/http.out /<>/results/http.out --- /<>/expected/http.out 2023-08-10 16:17:30.0 + +++ /<>/results/http.out 2024-04-08 18:20:45.564039027 + @@ -9,11 +9,7 @@ -- Status code SELECT status FROM http_get('https://httpbun.org/status/202'); - status - -202 -(1 row) - +ERROR: Could not resolve host: httpbun.org ...
Bug#1068655: lomiri-telephony-service FTBFS with abseil 20230802.1
Source: lomiri-telephony-service Version: 0.5.3-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=lomiri-telephony-service=amd64=0.5.3-1%2Bb3=1712518065=0 ... /<>/libtelephonyservice/contactwatcher.cpp: In member function ‘void ContactWatcher::updateAlias()’: /<>/libtelephonyservice/contactwatcher.cpp:157:21: error: ‘dgettext’ is not a member of ‘C’; did you mean ‘dgettext’? 157 | setAlias(C::dgettext("telephony-service", "Private Number")); | ^~~~ In file included from /usr/include/x86_64-linux-gnu/c++/13/bits/messages_members.h:36, from /usr/include/c++/13/bits/locale_facets_nonio.h:2064, from /usr/include/c++/13/locale:43, from /usr/include/c++/13/iomanip:45, from /usr/include/absl/strings/internal/str_format/arg.h:23, from /usr/include/absl/strings/str_format.h:78, from /usr/include/absl/crc/crc32c.h:32, from /usr/include/absl/crc/internal/crc_cord_state.h:23, from /usr/include/absl/strings/cord.h:79, from /usr/include/absl/container/internal/hash_function_defaults.h:56, from /usr/include/absl/container/node_hash_set.h:42, from /usr/include/phonenumbers/phonenumberutil.h:33, from /<>/libtelephonyservice/phoneutils.h:27, from /<>/libtelephonyservice/contactwatcher.cpp:25: /usr/include/libintl.h:44:14: note: ‘dgettext’ declared here 44 | extern char *dgettext (const char *__domainname, const char *__msgid) | ^~~~ /<>/libtelephonyservice/contactwatcher.cpp:159:21: error: ‘dgettext’ is not a member of ‘C’; did you mean ‘dgettext’? 159 | setAlias(C::dgettext("telephony-service", "Unknown Number")); | ^~~~ /usr/include/libintl.h:44:14: note: ‘dgettext’ declared here 44 | extern char *dgettext (const char *__domainname, const char *__msgid) | ^~~~ ...
Bug#1068613: lomiri-history-service FTBFS with abseil 20230802.1
Source: lomiri-history-service Version: 0.5-1 Severity: serious Tags: ftbfs Forwarded: https://gitlab.com/ubports/development/core/history-service/-/merge_requests/35 https://buildd.debian.org/status/fetch.php?pkg=lomiri-history-service=amd64=0.5-1%2Bb2=1712518035=0 ... In file included from /usr/include/absl/base/config.h:86, from /usr/include/absl/algorithm/algorithm.h:29, from /usr/include/absl/algorithm/container.h:53, from /usr/include/absl/container/node_hash_set.h:40, from /usr/include/phonenumbers/phonenumberutil.h:33, from /<>/src/phoneutils.cpp:28: /usr/include/absl/base/policy_checks.h:79:2: error: #error "C++ versions less than C++14 are not supported." 79 | #error "C++ versions less than C++14 are not supported." | ^ ...
Bug#1068612: libopenmpi3t64: mca_pmix_pmix3x.so: undefined symbol: pmix_value_load on 32bit
Package: libopenmpi3t64 Version: 4.1.6-8 Severity: serious Tags: ftbfs Control: affects -1 src:hypre src:h5py src:fenics-dolfinx src:dune-uggrid src:dolfinx-mpc src:dolfin src:liggghts https://buildd.debian.org/status/fetch.php?pkg=dune-uggrid=i386=2.9.0-2%2Bb3=1712511034=0 ... orted: symbol lookup error: /usr/lib/i386-linux-gnu/openmpi/lib/openmpi3/mca_pmix_pmix3x.so: undefined symbol: pmix_value_load ...
Bug#1068610: dico: binary-all FTBFS
Source: dico Version: 2.11-4 Severity: serious Tags: ftbfs X-Debbugs-Cc: Helmut Grohne https://buildd.debian.org/status/logs.php?pkg=dico=all ... debian/rules execute_after_dh_installsystemd make[1]: Entering directory '/<>' ln -s dicod.service debian/dicod/`test -e debian/dicod/lib/systemd/system/dicod.service || echo usr/`lib/systemd/system/dictd.service ln: failed to create symbolic link 'debian/dicod/usr/lib/systemd/system/dictd.service': No such file or directory make[1]: *** [debian/rules:52: execute_after_dh_installsystemd] Error 1
Bug#1068483: dpkg-genbuildinfo: Should buildinfo files copy the hash of the source package?
Package: dpkg-dev Version: 1.22.6 Severity: normal X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org A thought I already wrote in a recent debian-devel discussion: In theory source package filenames should be eternally and globally unique, but in practice there are cornercases where this assumption might break like for example: - *stable-security does not currently have a copy of the sources in the main archive, one always have to upload the source archive there and this might accidentally be a different orig.tar - dak does not keep an eternal history of everything it ever knew, e.g. RM and later re-NEW of a source version might have a different source .orig.tar or even different sources for a Debian revision - Debian and Ubuntu might have different orig.tar for the same version, if Ubuntu updated a package before Debian did, or with packages were development is completely independent in Debian and Ubuntu (e.g. OpenStack, KDE) The reason for different files might be as trivial as "git archive" not always producing the same output when running in different environments, e.g. the autogenerated tarball for a git tag on Github might have different checksums depending on whether it is downloaded today or next year despite identical contents due to slightly different gzip compression. Should buildinfo files contain the hashes of the source package, to clearly define what sources have been used?