Bug#1017693: passwordsafe is now secrets
Package: gnome-passwordsafe Version: 5.1-3 Hi, gnome-passwordsafe is now gnome-secrets. Would be nice to update links, etc. in the package info. Furthermore, a major update to v6 was released 7 months ago. Currently at 6.5. Thanks
Bug#1017691: thunderbird: ship mach utilities and test code in a binary package
Hello Daniel, Am 19.08.22 um 06:37 schrieb Daniel Kahn Gillmor: ... i'd like to do something like that with the autopkgtest for the debian package, but to do that i'd need to have the mach utility (i think it's python?) available, and i'd also need to have access to the test code. there isn't only the mach Python script, there are a lot of various peaces that act together (I haven't looked into that rabbit hole yet). But yes, the script in question is a Python script. https://sources.debian.org/src/thunderbird/1%3A102.1.2-1/mach/ I suppose the autopkgtest could do this by fetching the source for thunderbird directly, but it'd be easier to do so if there was a binary package that contained these pieces of infrastructure as shipped directly from the thunderbird source. Of course this is doable. Reading your initial ITP I think it would be reasonable to ship this all within a new binary package called thunderbird-mach-tool or mozilla-mach-tool e.g. This could be even a usual python3 package in a long term. The hardest part will be to get all the parts together that are needed to get the tooling working correctly. For me it would work best if you can start to extract the files and folders which are needed. The mach script is using these files to initialize the script itself. comm/build/mach_initialize.py build/mach_initialize.py tools/mach_initialize.py The first file is then starting to include more files and paths. MACH_MODULES = [ "comm/python/l10n/mach_commands.py", "comm/tools/lint/mach_commands.py", ] @Emilio Do you might have an (better?) idea how to archive the needs from Daniel? It's mostly a one way communication for me if I start to ask Mike. :-( Is there eventually some more or less ready we could pick up from the upstream build system? -- Regrads Carsten
Bug#1017507: vimix FTBFS on riscv64: needs to be linked with libatomic
Package: vimix Version: 0.7.0+git20220523+ds Followup-For: Bug #1017507 Tags: ftbfs, patch thanks -- Regards, -- Bo YU signature.asc Description: PGP signature
Bug#1017692: qdbus: QDBusConnection takes a long time to shutdown or reboot with systemd
Package: qdbus Version: 4:5.15.4-2 Severity: important X-Debbugs-Cc: ybx...@gmail.com Dear Maintainer, * What led up to the situation? Just shutdown or reboot the computer with KDE Plasma Wayland session logged in. * What was the outcome of this action? QDBusConnection ( 875) exited at 83.694573s, got signals: 9 * What outcome did you expect instead? Stop the program in less than 1 second. \ -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN:zh Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qdbus depends on: ii qdbus-qt5 5.15.4-2+b1 qdbus recommends no packages. qdbus suggests no packages. -- no debconf information
Bug#1017691: thunderbird: ship mach utilities and test code in a binary package
Package: thunderbird Version: 1:102.1.2-1 Severity: wishlist Control: affects -1 + libsequoia-octopus-librnp librnp0 In packaging libsequoia-octopus-librnp, i realize that i want to be able to run some tests on it. upstream, that project uses something like this to test whether it is working as expected: ./mach test --headless comm/mail/extensions/openpgp/test mail/test/browser/openpgp (see for example https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/blob/main/.gitlab-ci.yml#L228 ) i'd like to do something like that with the autopkgtest for the debian package, but to do that i'd need to have the mach utility (i think it's python?) available, and i'd also need to have access to the test code. I suppose the autopkgtest could do this by fetching the source for thunderbird directly, but it'd be easier to do so if there was a binary package that contained these pieces of infrastructure as shipped directly from the thunderbird source. That way, the autopkgtest could be run automatically against the octopus whenenver thunderbird was updated. let me know if this needs any clarification! --dkg signature.asc Description: PGP signature
Bug#1017690: debcargo: enable deletion of files using .debcargo.hint
Package: debcargo Version: 2.5.0-3+b4 currently, if debian/foo.debcargo.hint exists, debcargo will leave debian/foo alone, as long as what it wanted to put in debian/foo matches debian/foo.debcargo.hint exactly. However, in some circumstances a developer might want to entirely omit a file normally created by debcargo. The natural way to do this would be ship debian/foo.debcargo.hint and then *not ship* debian/foo at all. however, debcargo apparently sees the lack of debian/foo as an invitation to put its usual output in that file, even if debian/foo.debcargo.hint already exists. Instead, debcargo should not touch debian/foo at all if debian/foo.debcargo.hint exists. This allows a developer to declare that a file normally-generated by debcargo is entirely unwanted for this package/crate. --dkg signature.asc Description: PGP signature
Bug#1017689: ITP: libobject-result-perl -- Allow subs to build and return objects on-the-fly
Package: wnpp Severity: wishlist Owner: Gabriel Filion X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libobject-result-perl Version : 0.03 Upstream Author : Damian Conway * URL : https://metacpan.org/release/Object-Result * License : artistic2 Programming Lang: Perl Description : Allow subs to build and return objects on-the-fly Object::Result adds a new keyword to Perl: result That keyword acts like a return, but instead of a list of values to return, it takes a single block which specifies the behaviour (i.e. the methods and operator overloading) of an object to be returned. The intention is to make it much less onerous to return clean, properly encapsulated objects...instead of returning lists of values or references to arrays or hashes. This library is a requirement for libinfluxdb-http-perl, which is itself a requirement to the newer upstream release of smokeping. I plan to maintain this package from within the Perl team, and I will ask for sponsorship within the team.
Bug#1017688: ITP: rust-sequoia-octopus-librnp -- librnp reimplementation in Rust for Thunderbird
Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor
X-Debbugs-Cc: debian-de...@lists.debian.org, d...@fifthhorseman.net
Control: affects -1 + thunderbird librnp0
* Package name: rust-sequoia-octopus-librnp
Version : 1.4.1
Upstream Author : Sequoia Project
* URL : https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp
* License : LGPL-2-or-later
Programming Lang: Rust
Description : librnp reimplementation in Rust for Thunderbird
This package contains a dynamic library (shared object) with the same
interface as librnp.so.0, at least the parts used by Thunderbird.
This implementation is built in Rust by the Sequoia OpenPGP project.
This is not a complete replacement for librnp0, as Sequoia targets
only the features used by Thunderbird.
When the octopus is used in place of baseline librnp0, users should
get a number of different features, including:
- better integration with existing GnuPG keyrings, secret keys
(including smartcards), and trust annotations, for those who already
have a GnuPG installation.
- automatic background keyring refresh ("parcimonie"-style)
- carefully-planned cryptographic algorithm deprecation
- protection from surreptitious forwarding using OpenPGP's "intended
recipients" subpacket
- SHA1 collision detection
- secret keys locked while in memory, as a defense against memory
dumping attacks
The intention of this package is ultimately for a Thunderbird user to
be able to switch from librnp to the octopus with a simple package
installation (and to revert to librnp with a package uninstallation).
Early experimental versions will likely just ship the pre-built .so
and let the adventurous user handle the system integration.
Bug#1017687: RFP: xsv -- fast CSV command line toolkit
Package: wnpp Severity: wishlist * Package name: xsv Version : 0.13.0 Upstream Author : Andrew Gallant * URL : https://github.com/BurntSushi/xsv * License : MIT Programming Lang: Rust Description : fast CSV command line toolkit xsv is a command line program for indexing, slicing, analyzing, splitting and joining CSV files. Commands should be simple, fast and composable: 1. Simple tasks should be easy. 2. Performance trade offs should be exposed in the CLI interface. 3. Composition should not come at the expense of performance.
Bug#1012987: libpodofo: ftbfs with GCC-12
Hi Mattia and Yokota-san, On Mon, 25 Jul 2022 15:50:48 +0200 Mattia Rizzolo wrote: > See also me asking upstream for a real patch here: > https://sourceforge.net/p/podofo/mailman/podofo-users/thread/Yt0dvCmE/ISNNwI3%40mapreri.org/#msg37684942 > > At the very least, I'd prefer fedora's patch better since it disable > specific tests and not the whole file the failing test lives in⦠> But I really don't like either. Would you please comment on the fix Yokota cherry picked? It looks like a "real patch" that solves the actual issue. On Wed, 27 Jul 2022 10:47:59 +0900 yokota wrote: > Hello, > > > I rewrite my patch to enable all string test. > > New patch was already uploaded to salsa. > https://salsa.debian.org/debian/libpodofo/-/merge_requests/2 > It looks like the a "Source" or "Forwarded" DEP3 header with a link to Pino's pull request is missing. https://dep-team.pages.debian.net/deps/dep3 Regards, Nicholas signature.asc Description: PGP signature
Bug#1017595: [pkg-apparmor] Bug#1017595: please make apparmor less noisy
On Thu, Aug 18, 2022 at 09:46:39AM +0200, Harald Dunkel wrote: > apparmor writes a bazillion of log entries to dmesg and /var/log/\ > kern.log, hiding other important messages. Do you think it would be > reasonable to add auditd to the Recommends list? I'm slightly in favour of this, yes. One downside is that dbus apparmor enforcement doesn't go through the audit system, they'll still show up in the syslog pile, so log entries are split. But I think it's still a net win to move most of the logging to something less prone to dropping log entries. I realize 'noisy' is in the ears of the listener :) but I suspect your policy could use some tuning for your use. From a few of my own systems: $ grep -c -i apparmor /var/log/syslog 18 $ grep -c -i apparmor /var/log/audit/audit.log 110 $ grep -c -i apparmor /var/log/audit/audit.log 36 $ grep -c -i apparmor /var/log/audit/audit.log 354 (This last one covers 76 days of audit logs.) Anyway, if you ask in #apparmor on irc.oftc.net someone may be able to suggest policy changes to reduce the noise. Thanks signature.asc Description: PGP signature
Bug#1017686: RFP: solarus -- action RPG game engine
Package: wnpp Severity: wishlist X-Debbugs-Cc: okgomdjgbm...@gmail.com * Package name: solarus Version : 1.6.5 Upstream Author : Christopho * URL : http://www.solarus-games.org/ https://gitlab.com/solarus-games * License : GPL3 Programming Lang: C++ Description : 2D action RPG game engine This is a 2D game engine for action RPGs (zelda-like). Debian doesn't has anything equivalent. It's not just one game, it's a game engine and it's high quality. it has a debian PKGBUILD https://mpr.makedeb.org/packages/solarus-run demo https://www.youtube.com/watch?v=HUMcFAdBJ_g
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
From: Ben Hutchings
The mitigation for PBRSB includes adding LFENCE instructions to the
RSB filling sequence. However, RSB filling is done on some older CPUs
that don't support the LFENCE instruction.
Define and use a BARRIER_NOSPEC macro which makes the LFENCE
conditional on X86_FEATURE_LFENCE_RDTSC, like the barrier_nospec()
macro defined for C code in .
Reported-by: Martin-Éric Racine
References: https://bugs.debian.org/1017425
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Cc: Daniel Sneddon
Cc: Pawan Gupta
Fixes: 2b1299322016 ("x86/speculation: Add RSB VM Exit protections")
Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence")
Signed-off-by: Ben Hutchings
---
Re-sending this with properly matched From address and server.
Apologies if you got 2 copies.
Ben.
arch/x86/include/asm/nospec-branch.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/nospec-branch.h
b/arch/x86/include/asm/nospec-branch.h
index e64fd20778b6..b1029fd88474 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -34,6 +34,11 @@
#define RSB_CLEAR_LOOPS32 /* To forcibly overwrite all
entries */
+#ifdef __ASSEMBLY__
+
+/* Prevent speculative execution past this barrier. */
+#define BARRIER_NOSPEC ALTERNATIVE "", "lfence", X86_FEATURE_LFENCE_RDTSC
+
/*
* Google experimented with loop-unrolling and this turned out to be
* the optimal version - two calls, each with their own speculation
@@ -62,9 +67,7 @@
dec reg;\
jnz 771b; \
/* barrier for jnz misprediction */ \
- lfence;
-
-#ifdef __ASSEMBLY__
+ BARRIER_NOSPEC;
/*
* This should be used immediately before an indirect jump/call. It tells
@@ -138,7 +141,7 @@
int3
.Lunbalanced_ret_guard_\@:
add $(BITS_PER_LONG/8), %_ASM_SP
- lfence
+ BARRIER_NOSPEC
.endm
/*
signature.asc
Description: PGP signature
Bug#1017685: RFP: openutau -- Open singing synthesis platform / Open source UTAU successor / vocaloid clone
Package: wnpp Severity: wishlist X-Debbugs-Cc: okgomdjgbm...@gmail.com * Package name: openutau Version : git Upstream Author : stakira * URL : http://www.openutau.com/ * License : MIT Programming Lang: C# Description : Open singing synthesis platform / Open source UTAU successor / vocaloid clone This is a clone of a shareware clone (UTAU) of the proprietairy vocaloid software (hatsune miku etc). It's a speach synthesiser, targeting specifically singing. UTAU been closed source, windows only, very old and quirky to use (you need to install Japanese fonts...). There's plenty of demand for this kind of thing and it's pretty much unique in the open source world. Here's a demo https://www.youtube.com/watch?v=tew1EyyLASs Debian doesn't has anything like this in it's repos. It's unique, with lots of interest.
Bug#207419: [bug-inetutils] Fwd: Bug#207419: SSL support
Hi! On Thu, 2022-08-18 at 17:41:41 +0200, Bastian Germann wrote: > On Sun, 29 Mar 2020 00:45:49 + Marcos Marado > wrote: > > AFAICS, this ended up never happening. However, someone else worked on a set > > of patches that, supposedly, implement this: more info at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=143559 , if you wish to > > take a > > look. > > With OpenSSL having switched to Apache license, it would now be possible to > rebase > the http://erislabs.net/ianb/ssl/ patches and include them upstream. Ah, thanks for the pointers. Simon, perhaps you could have a look at integrating these upstream? These would be nice candidates for further default switches. :) Thanks, Guillem
Bug#1017684: tiledb-r: ftbfs on riscv64("undefined symbol: __atomic_compare_exchange_1")
Source: tiledb-r Version: 0.15.0-1 Severity: normal Tags: ftbfs, patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Dear Maintainer, The tiledb-r has a ftbfs on riscv64 due to missing -latomic explicitly after 0.13.0-1: https://buildd.debian.org/status/logs.php?pkg=tiledb-r=riscv64 The full buildd log failed is here: https://buildd.debian.org/status/fetch.php?pkg=tiledb-r=riscv64=0.15.0-1=1660431861=0 The patch attached is trying to fix issue as you suggested. And I'll check if there are other r-cran-* packages with similar problems also. -- Regards, -- Bo YU --- a/src/Makevars.in +++ b/src/Makevars.in @@ -8,7 +8,7 @@ PKG_CPPFLAGS = -I../inst/include/ @TILEDB_INCLUDE@ ## We also need the TileDB library -PKG_LIBS = @CXX17_MACOS@ @TILEDB_LIBS@ @TILEDB_RPATH@ +PKG_LIBS = @CXX17_MACOS@ @TILEDB_LIBS@ -latomic @TILEDB_RPATH@ all: $(SHLIB) # if we are signature.asc Description: PGP signature
Bug#1017683: ITP: elpa-citar -- Find and act on bibliographic references within Emacs
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-citar Version : 1.0 Upstream Author : Bruce D'Arcus * URL or Web page : https://github.com/emacs-citar/citar * License : GPL-3+ Description : Find and act on bibliographic references within Emacs This package allows to find Bibtex and Biblatex bibliographic references from a source, provide completion on it with the help of a completion framework, and provide various contextual actions on these references, in org-mode, latex and markdown files. Aymeric Agon-Rambosson
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
The mitigation for PBRSB includes adding LFENCE instructions to the
RSB filling sequence. However, RSB filling is done on some older CPUs
that don't support the LFENCE instruction.
Define and use a BARRIER_NOSPEC macro which makes the LFENCE
conditional on X86_FEATURE_LFENCE_RDTSC, like the barrier_nospec()
macro defined for C code in .
Reported-by: Martin-Éric Racine
References: https://bugs.debian.org/1017425
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Cc: Daniel Sneddon
Cc: Pawan Gupta
Fixes: 2b1299322016 ("x86/speculation: Add RSB VM Exit protections")
Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence")
Signed-off-by: Ben Hutchings
---
arch/x86/include/asm/nospec-branch.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/nospec-branch.h
b/arch/x86/include/asm/nospec-branch.h
index e64fd20778b6..b1029fd88474 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -34,6 +34,11 @@
#define RSB_CLEAR_LOOPS32 /* To forcibly overwrite all
entries */
+#ifdef __ASSEMBLY__
+
+/* Prevent speculative execution past this barrier. */
+#define BARRIER_NOSPEC ALTERNATIVE "", "lfence", X86_FEATURE_LFENCE_RDTSC
+
/*
* Google experimented with loop-unrolling and this turned out to be
* the optimal version - two calls, each with their own speculation
@@ -62,9 +67,7 @@
dec reg;\
jnz 771b; \
/* barrier for jnz misprediction */ \
- lfence;
-
-#ifdef __ASSEMBLY__
+ BARRIER_NOSPEC;
/*
* This should be used immediately before an indirect jump/call. It tells
@@ -138,7 +141,7 @@
int3
.Lunbalanced_ret_guard_\@:
add $(BITS_PER_LONG/8), %_ASM_SP
- lfence
+ BARRIER_NOSPEC
.endm
/*
signature.asc
Description: PGP signature
Bug#1017681: dh-cargo and debcargo cannot effectively build a cdylib crate
Package: dh-cargo Version: 28 Control: affects -1 + src:rust-sequoia-octopus-librnp Control: clone -1 -2 Control: reassign -2 debcargo 2.5.0-3+b4 I'm trying to build a version of the Sequoia project's "octopus", which creates a shared object (dynamic library) that can replace librnp.so.0 for all the ways that thunderbird uses it. The library is implmented in Rust, as a crate named sequoia-octopus-librnp, and it can be found at https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/ Note that the crate has no "bin" section, but its library is of type "cdylib", which means that (at least on GNU systems) it builds a .so that can be used by the C dynamic linker. A few things to note: - when building this should effectively run "cargo build --release", but the dh-cargo dh buildsystem doesn't do so during the auto_build phase of dh - i believe the produced shared object will end up in target/release/libsequoia_octopus_librnp.so, so it needs to be retrieved from there and shipped in /usr/lib/$(DEB_HOST_MULTIARCH)/ - when debcargo generates the build-deps, it needs to mark the dependencies *without* , since they are needed to actually run the build I'll try to do this manually with this crate for now, and store it in the debcargo-conf repository with a lot of .debcargo.hint files, but it'd be great to avoid these kinds of hacks by having debcargo and dh-cargo do the right thing in the future. --dkg signature.asc Description: PGP signature
Bug#1017596: openrct2: FTBFS with warnings as errors
Control: tags -1 + confirmed It looks like this is triggering a bug in g++ 12 that's been reported upstream with a simple test case: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580. For now, I'm inclined to suppress -Wnull-dereference for the affected source file, since I know that there is in fact not a null dereference occurring in the code. Mathias signature.asc Description: This is a digitally signed message part
Bug#1017680: RFS: fheroes2/0.9.18-1 [ITP] -- Free remake of Heroes of Might and Magic II game engine
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "fheroes2": * Package name : fheroes2 Version : 0.9.18-1 Upstream Author : fheroes2 team * URL : https://github.com/ihhub/fheroes2 * License : BSD-3-clause, LGPL-2.1+, GPL-2.0+, Apache-2.0, GeneralUser-2.0, CC0-1.0 * Vcs : https://salsa.debian.org/undef21/fheroes2 Section : contrib/games The source builds the following binary packages: fheroes2 - Free remake of Heroes of Might and Magic II game engine To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fheroes2/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/contrib/f/fheroes2/fheroes2_0.9.18-1.dsc Changes for the initial release: fheroes2 (0.9.18-1) unstable; urgency=medium . * Initial release. (Closes: #1017587) Regards,
Bug#1017679: RM: llvm-toolchain-13 -- ROM; Limit the number of llvm versions
Package:ftp.debian.org Severity: normal Just like with bug #974789 for -9, #974788 for -10, #1000941 for -11, #1012404 for -12 and many others before, I am opening this to keep track of all the changes needed to be able to get ride of llvm-toolchain-13. Sylvestre
Bug#1017678: mlpack: Please upgrade to llvm-toolchain-14
Source: mlpack Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017676: bpftrace: Please upgrade to llvm-toolchain-14
On 2022-08-18 23:43, Sylvestre Ledru wrote: Source: bpftrace Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. I was about to upload. Can I still proceeed or should I not?
Bug#1017676: bpftrace: Please upgrade to llvm-toolchain-14
Le 18/08/2022 à 23:58, Vincent Bernat a écrit : On 2022-08-18 23:43, Sylvestre Ledru wrote: Source: bpftrace Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. I was about to upload. Can I still proceeed or should I not? please do :)
Bug#1016418: transition: fmtlib
Control: tags -1 confirmed Control: tags 1017412 confirmed On 2022-08-17 03:42:18 +0800, Shengjing Zhu wrote: > On Wed, Aug 17, 2022 at 3:07 AM Sebastian Ramacher > wrote: > > > > On 2022-08-15 20:35:49 +0800, Shengjing Zhu wrote: > > > CC spdlog maintainer as well. > > > > > > On Mon, Aug 15, 2022 at 01:45:32PM +0200, Sebastian Ramacher wrote: > > > > Let's note hide spdlog's ABI breakage that is unreleated to the fmtlib > > > > transition. Please fix this issue first and remove the moreinfo tag once > > > > that's done. > > > > > > What's your suggestions to fix the spdlog ABI breakage? > > > > The ABI breakage was caused by adding a new argument to some functions > > with a default argument. This could be fixed by keeping the old > > functions around. > > > > TBH, given libspdlog1.10 is in experimental, I feel it's more correct > to just do a spdlog transition. Please go ahead with both uploads. Cheers -- Sebastian Ramacher
Bug#1017677: autofdo: Please upgrade to llvm-toolchain-14
Source: autofdo Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017676: bpftrace: Please upgrade to llvm-toolchain-14
Source: bpftrace Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017675: oclgrind: Please upgrade to llvm-toolchain-14
Source: oclgrind Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017674: bpftrace: Please upgrade to llvm-toolchain-14
Source: bpftrace Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017673: pocl: Please upgrade to llvm-toolchain-14
Source: pocl Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017672: ghdl: Please upgrade to llvm-toolchain-14
Source: ghdl Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017671: rustc: Please upgrade to llvm-toolchain-14
Source: rustc Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017670: spirv-llvm-translator: Please upgrade to llvm-toolchain-14
Source: spirv-llvm-translator Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017669: aiscm: Please upgrade to llvm-toolchain-14
Source: aiscm Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017668: castxml: Please upgrade to llvm-toolchain-14
Source: castxml Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017667: aflplusplus: Please upgrade to llvm-toolchain-14
Source: aflplusplus Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017666: amdgcn-tools: Please upgrade to llvm-toolchain-14
Source: amdgcn-tools Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017665: doxygen: Please upgrade to llvm-toolchain-14
Source: doxygen Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017664: intel-opencl-clang: Please upgrade to llvm-toolchain-14
Source: intel-opencl-clang Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017663: ghc: Please upgrade to llvm-toolchain-14
Source: ghc Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017662: crystal: Please upgrade to llvm-toolchain-14
Source: crystal Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017661: wasi-libc: Please upgrade to llvm-toolchain-14
Source: wasi-libc Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017660: pocl: Please upgrade to llvm-toolchain-14
Source: pocl Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017659: spirv-llvm-translator: Please upgrade to llvm-toolchain-14
Source: spirv-llvm-translator Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017658: vboot-utils: Please upgrade to llvm-toolchain-14
Source: vboot-utils Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017657: oclgrind: Please upgrade to llvm-toolchain-14
Source: oclgrind Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017656: rustc: Please upgrade to llvm-toolchain-14
Source: rustc Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017655: aflplusplus: Please upgrade to llvm-toolchain-14
Source: aflplusplus Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017654: oclgrind: Please upgrade to llvm-toolchain-14
Source: oclgrind Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017653: intel-opencl-clang: Please upgrade to llvm-toolchain-14
Source: intel-opencl-clang Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. Thanks, Sylvestre
Bug#1017652: golang-github-pelletier-go-toml: FTBFS on mips64el
Source: golang-github-pelletier-go-toml
Version: 1.9.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=golang-github-pelletier-go-toml=mips64el=1.9.4-1%2Bb2=1660745357=0
# internal/testlog
unexpected fault address 0x0
fatal error: fault
[signal SIGBUS: bus error code=0x80 addr=0x0 pc=0x40c094]
goroutine 7 [running]:
runtime.throw({0xbadaf0, 0x5})
/usr/lib/go-1.19/src/runtime/panic.go:1047 +0x58 fp=0xc000596a80
sp=0xc000596a58 pc=0x58610
runtime.sigpanic()
/usr/lib/go-1.19/src/runtime/signal_unix.go:832 +0x1e8 fp=0xc000596ab0
sp=0xc000596a80 pc=0x77a20
cmd/compile/internal/ssa.(*Cache).Reset.func1(0x3e8)
/usr/lib/go-1.19/src/cmd/compile/internal/ssa/cache.go:45 +0x34
fp=0xc000596ad0 sp=0xc000596ab8 pc=0x40c094
sort.Search(0x7d0, 0xc000596b20)
/usr/lib/go-1.19/src/sort/search.go:65 +0x6c fp=0xc000596b00
sp=0xc000596ad0 pc=0xdd52c
cmd/compile/internal/ssa.(*Cache).Reset(0xc00069afc0)
/usr/lib/go-1.19/src/cmd/compile/internal/ssa/cache.go:45 +0x68
fp=0xc000596b30 sp=0xc000596b00 pc=0x40bb28
cmd/compile/internal/ssagen.buildssa(0xc00043d400, 0x2)
/usr/lib/go-1.19/src/cmd/compile/internal/ssagen/ssa.go:358 +0xa1c
fp=0xc000596ea8 sp=0xc000596b30 pc=0x87030c
cmd/compile/internal/ssagen.Compile(0xc00043d400, 0x2)
/usr/lib/go-1.19/src/cmd/compile/internal/ssagen/pgen.go:183 +0x54
fp=0xc000596f68 sp=0xc000596ea8 pc=0x865cfc
cmd/compile/internal/gc.compileFunctions.func4.1(0x2)
/usr/lib/go-1.19/src/cmd/compile/internal/gc/compile.go:153 +0x5c
fp=0xc000596fa0 sp=0xc000596f68 pc=0xab5c8c
cmd/compile/internal/gc.compileFunctions.func3.1()
/usr/lib/go-1.19/src/cmd/compile/internal/gc/compile.go:140 +0x74
fp=0xc000596fd8 sp=0xc000596fa0 pc=0xab5e2c
runtime.goexit()
/usr/lib/go-1.19/src/runtime/asm_mips64x.s:617 +0x4 fp=0xc000596fd8
sp=0xc000596fd8 pc=0x9a23c
created by cmd/compile/internal/gc.compileFunctions.func3
/usr/lib/go-1.19/src/cmd/compile/internal/gc/compile.go:138 +0xbc
goroutine 1 [runnable]:
runtime.newobject(0xb70080)
/usr/lib/go-1.19/src/runtime/malloc.go:1191 +0x1c fp=0xc000499a00
sp=0xc000499a00 pc=0x1f1fc
cmd/compile/internal/gc.compileFunctions.func4({0xc00047ee80, 0x8, 0x8})
/usr/lib/go-1.19/src/cmd/compile/internal/gc/compile.go:152 +0xbc
fp=0xc000499a58 sp=0xc000499a00 pc=0xab5b74
cmd/compile/internal/gc.compileFunctions()
/usr/lib/go-1.19/src/cmd/compile/internal/gc/compile.go:163 +0x270
fp=0xc000499ab8 sp=0xc000499a58 pc=0xab5980
cmd/compile/internal/gc.Main(0xbe43a0)
/usr/lib/go-1.19/src/cmd/compile/internal/gc/main.go:306 +0x1958
fp=0xc000499f10 sp=0xc000499ab8 pc=0xab8068
main.main()
/usr/lib/go-1.19/src/cmd/compile/main.go:57 +0x1a4 fp=0xc000499f80
sp=0xc000499f10 pc=0xaed204
runtime.main()
/usr/lib/go-1.19/src/runtime/proc.go:250 +0x30c fp=0xc000499fd8
sp=0xc000499f80 pc=0x5bbe4
runtime.goexit()
/usr/lib/go-1.19/src/runtime/asm_mips64x.s:617 +0x4 fp=0xc000499fd8
sp=0xc000499fd8 pc=0x9a23c
goroutine 2 [force gc (idle)]:
runtime.gopark(0xbe5478, 0x1262040, 0x11, 0x14, 0x1)
/usr/lib/go-1.19/src/runtime/proc.go:363 +0x13c fp=0xc50fb0
sp=0xc50f98 pc=0x5c1a4
runtime.goparkunlock(...)
/usr/lib/go-1.19/src/runtime/proc.go:369
runtime.forcegchelper()
/usr/lib/go-1.19/src/runtime/proc.go:302 +0x128 fp=0xc50fd8
sp=0xc50fb0 pc=0x5bfc0
runtime.goexit()
/usr/lib/go-1.19/src/runtime/asm_mips64x.s:617 +0x4 fp=0xc50fd8
sp=0xc50fd8 pc=0x9a23c
created by runtime.init.5
/usr/lib/go-1.19/src/runtime/proc.go:290 +0x48
goroutine 3 [GC sweep wait]:
runtime.gopark(0xbe5478, 0x1262440, 0xc, 0x14, 0x1)
/usr/lib/go-1.19/src/runtime/proc.go:363 +0x13c fp=0xc517a0
sp=0xc51788 pc=0x5c1a4
runtime.goparkunlock(...)
/usr/lib/go-1.19/src/runtime/proc.go:369
runtime.bgsweep(0xc32070)
/usr/lib/go-1.19/src/runtime/mgcsweep.go:297 +0x1b0 fp=0xc517c8
sp=0xc517a0 pc=0x3f138
runtime.gcenable.func1()
/usr/lib/go-1.19/src/runtime/mgc.go:178 +0x64 fp=0xc517d8
sp=0xc517c8 pc=0x2f27c
runtime.goexit()
/usr/lib/go-1.19/src/runtime/asm_mips64x.s:617 +0x4 fp=0xc517d8
sp=0xc517d8 pc=0x9a23c
created by runtime.gcenable
/usr/lib/go-1.19/src/runtime/mgc.go:178 +0xc4
goroutine 4 [GC scavenge wait]:
runtime.gopark(0xbe5478, 0x12629a0, 0xd, 0x14, 0x2)
/usr/lib/go-1.19/src/runtime/proc.go:363 +0x13c fp=0xc51f80
sp=0xc51f68 pc=0x5c1a4
runtime.goparkunlock(...)
/usr/lib/go-1.19/src/runtime/proc.go:369
runtime.(*scavengerState).park(0x12629a0)
/usr/lib/go-1.19/src/runtime/mgcscavenge.go:389 +0x98 fp=0xc51fa8
sp=0xc51f80 pc=0x3c4a8
runtime.bgscavenge(0xc32070)
/usr/lib/go-1.19/src/runtime/mgcscavenge.go:622 +0xc0 fp=0xc51fc8
Bug#1017651: golang-github-xenolf-lego: FTBFS on mips*el
Source: golang-github-xenolf-lego Version: 4.1.3-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) ok github.com/go-acme/lego/providers/http/webroot 0.026s === RUN TestRegistrar_ResolveAccountByKey 2022/08/17 14:29:29 [INFO] acme: Trying to resolve account by key --- PASS: TestRegistrar_ResolveAccountByKey (0.05s) PASS ok github.com/go-acme/lego/registration0.060s FAIL dh_auto_test: error: cd _build && go test -vet=off -v -p 4 github.com/go-acme/lego/acme github.com/go-acme/lego/acme/api github.com/go-acme/lego/acme/api/internal/nonces github.com/go-acme/lego/acme/api/internal/secure github.com/go-acme/lego/acme/api/internal/sender github.com/go-acme/lego/certcrypto github.com/go-acme/lego/certificate github.com/go-acme/lego/challenge github.com/go-acme/lego/challenge/dns01 github.com/go-acme/lego/challenge/http01 github.com/go-acme/lego/challenge/resolver github.com/go-acme/lego/challenge/tlsalpn01 github.com/go-acme/lego/cmd github.com/go-acme/lego/cmd/lego github.com/go-acme/lego/internal github.com/go-acme/lego/lego github.com/go-acme/lego/log github.com/go-acme/lego/platform/config/env github.com/go-acme/lego/platform/tester github.com/go-acme/lego/platform/wait github.com/go-acme/lego/providers/dns github.com/go-acme/lego/providers/dns/arvancloud github.com/go-acme/lego/providers/dns/arvancloud/internal github.com/go-acme/lego/providers/dns/autodns github.com/go-acme/lego/providers/dns/bluecat github.com/go-acme/lego/providers/dns/checkdomain github.com/go-acme/lego/providers/dns/clouddns github.com/go-acme/lego/providers/dns/clouddns/internal github.com/go-acme/lego/providers/dns/cloudns github.com/go-acme/lego/providers/dns/cloudns/internal github.com/go-acme/lego/providers/dns/cloudxns github.com/go-acme/lego/providers/dns/cloudxns/internal github.com/go-acme/lego/providers/dns/conoha github.com/go-acme/lego/providers/dns/conoha/internal github.com/go-acme/lego/providers/dns/constellix github.com/go-acme/lego/providers/dns/constellix/internal github.com/go-acme/lego/providers/dns/desec github.com/go-acme/lego/providers/dns/digitalocean github.com/go-acme/lego/providers/dns/dnsmadeeasy github.com/go-acme/lego/providers/dns/dnsmadeeasy/internal github.com/go-acme/lego/providers/dns/dode github.com/go-acme/lego/providers/dns/dreamhost github.com/go-acme/lego/providers/dns/duckdns github.com/go-acme/lego/providers/dns/dyn github.com/go-acme/lego/providers/dns/dynu github.com/go-acme/lego/providers/dns/dynu/internal github.com/go-acme/lego/providers/dns/easydns github.com/go-acme/lego/providers/dns/edgedns github.com/go-acme/lego/providers/dns/exec github.com/go-acme/lego/providers/dns/gandi github.com/go-acme/lego/providers/dns/gandiv5 github.com/go-acme/lego/providers/dns/gcloud github.com/go-acme/lego/providers/dns/glesys github.com/go-acme/lego/providers/dns/godaddy github.com/go-acme/lego/providers/dns/hetzner github.com/go-acme/lego/providers/dns/hetzner/internal github.com/go-acme/lego/providers/dns/hostingde github.com/go-acme/lego/providers/dns/httpreq github.com/go-acme/lego/providers/dns/hyperone github.com/go-acme/lego/providers/dns/hyperone/internal github.com/go-acme/lego/providers/dns/infomaniak github.com/go-acme/lego/providers/dns/infomaniak/internal github.com/go-acme/lego/providers/dns/internal/rimuhosting github.com/go-acme/lego/providers/dns/internal/selectel github.com/go-acme/lego/providers/dns/inwx github.com/go-acme/lego/providers/dns/joker github.com/go-acme/lego/providers/dns/joker/internal/dmapi github.com/go-acme/lego/providers/dns/joker/internal/svc github.com/go-acme/lego/providers/dns/lightsail github.com/go-acme/lego/providers/dns/luadns github.com/go-acme/lego/providers/dns/luadns/internal github.com/go-acme/lego/providers/dns/mydnsjp github.com/go-acme/lego/providers/dns/mythicbeasts github.com/go-acme/lego/providers/dns/namecheap github.com/go-acme/lego/providers/dns/netcup github.com/go-acme/lego/providers/dns/netcup/internal github.com/go-acme/lego/providers/dns/netlify github.com/go-acme/lego/providers/dns/netlify/internal github.com/go-acme/lego/providers/dns/nifcloud github.com/go-acme/lego/providers/dns/nifcloud/internal github.com/go-acme/lego/providers/dns/otc github.com/go-acme/lego/providers/dns/ovh github.com/go-acme/lego/providers/dns/pdns github.com/go-acme/lego/providers/dns/rackspace github.com/go-acme/lego/providers/dns/regru github.com/go-acme/lego/providers/dns/regru/internal github.com/go-acme/lego/providers/dns/rfc2136 github.com/go-acme/lego/providers/dns/rimuhosting github.com/go-acme/lego/providers/dns/route53 github.com/go-acme/lego/providers/dns/scaleway github.com/go-acme/lego/providers/dns/scaleway/internal github.com/go-acme/lego/providers/dns/selectel github.com/go-acme/lego/providers/dns/servercow github.com/go-acme/lego/providers/dns/servercow/internal
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
On Thu, 2022-08-18 at 23:11 +0300, Martin-Éric Racine wrote: > On Thu, Aug 18, 2022 at 10:59 PM Ben Hutchings wrote: > > > > Control: retitle -1 [i386] Unconditional LFENCE instructions in > > FILL_RETURN_BUFFER > > Control: tag -1 confirmed upstream > > Control: found -1 5.18.14-1 > > > > On Wed, 2022-08-17 at 11:42 +0200, Etienne Vogt wrote: > > > I can confirm that this bug also occurs on Athlon XP systems (Generic VIA > > > KT333 motherboard, CPU AMD Athlon(tm) XP 2600+) : kernel panic early on > > > boot. > > > > > > I suspect someone thought it would be a good idea to compile the kernel > > > for P4 only, as both PIII and Athlon XP processors lack the SSE2 > > > instruction set. > > > > > > > That was a good guess, though we don't change the configuration like > > that in stable updates. > > > > The RETbleed mitigations, which are not needed on these CPUs or even > > functional on 32-bit kernels, interact with the Spectre v2 mitigations, > > which *are* used on these CPUs. And unfortunately the RETbleed > > mitigations added some unconditional LFENCE instructions, which should > > be conditional since they are part of SSE2. > > > > As a temporary workaround, disabling the Spectre v2 mitigation with the > > kernel parameter "nospectre_v2" should allow this kernel version to run > > on older CPUs without SSE2. We'll fix this properly in a later update. > > That breakage affects Stable. > > Expecting people to go and use workarounds on what was meant to be a > stable update isn't acceptable. Martin, you know we're all volunteers here, so don't take that tone. I was trying to be helpful in offering an alternative to holding back the upgrade. > I really hope that the fix will be pushed within the next 24 hours > with high urgency. This is unlikely to happen. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Bug#1017650: rust-zram-generator: BD-Uninstallable
Source: rust-zram-generator Version: 0.3.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/package.php?p=rust-zram-generator=sid rust-zram-generator build-depends on missing: - librust-rust-ini-0.16+default-dev:amd64 Cheers -- Sebastian Ramacher
Bug#942882: moving things around with PYBUILD_EXT_DESTDIR_* doesn't seem to work
Hi Matthias (2019.10.22_20:54:04_+0200) > The handling of the changed extension names in 3.8 is a little bit tricky, > and you suggested to use PYBUILD_NAME and PYBUILD_EXT_DESTDIR_*. Here is a > try to do that The changed packaging has other bugs, but it show that the > extensions are not moved into the -lib packages. From what I can see, PYBUILD_NAME effectively overrides PYBUILD_EXT_DESTDIR. It should probably be the other way around. At the moment, this does work: export PYBUILD_DESTDIR_python3=debian/python3-tables export PYBUILD_EXT_DESTDIR_python3=debian/python3-tables-lib SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1017649: rust-rust-code-analysis-cli: BD-Uninstallable
Source: rust-rust-code-analysis-cli Version: 0.0.19-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/package.php?p=rust-rust-code-analysis-cli=sid rust-rust-code-analysis-cli build-depends on missing: - librust-crossbeam-0.7+default-dev:amd64 Cheers -- Sebastian Ramacher
Bug#1017648: tiger: Filesystem 'fuse.portal' used by 'portal' is not recognised as a valid filesystem
Package: tiger Version: 1:3.2.4~rc1-3 Severity: normal Dear Maintainer, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987512;msg=5 has a patch attached to it, where do I add it at? What file? Thanks! -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tiger depends on: ii binutils 2.38.90.20220713-2 ii bsdutils 1:2.38.1-1 ii debconf [debconf-2.0] 1.5.79 ii debianutils5.7-0.3 ii libc6 2.34-3 ii lsb-release11.2 ii net-tools 1.60+git20181103.0eebece-1 ii ucf3.0043 Versions of packages tiger recommends: ii chkrootkit 0.55-4+b2 ii exim4-daemon-light [mail-transport-agent] 4.96-3 ii john 1.8.0-4 ii tripwire 2.4.3.7-4+b2 Versions of packages tiger suggests: ii lsof 4.95.0-1 ii lynis 3.0.7-1 -- debconf information: tiger/mail_rcpt: root tiger/policy_adapt:
Bug#956506: Confirmed, regression since 5:102 in buster
Confirming I'm also seeing this bug after an upgrade of my desktop to bullseye. It worked fine in buster (kde-plasma-desktop 5:102), though I freely confess I have no idea which underlying KDE component or package is invovled. Looks like this is upstream bug #413104 - I confirmed the bug is only present when using "Desktop" layout, not "Folder View". -- Ivan Kohler
Bug#1017393: buster-pu: package debian-security-support/1:10+2022.08.23
On Mon, 2022-08-15 at 13:50 +0200, Holger Levsen wrote: > I'd like to introduce an epoch to debian-security-support in buster, > as used everywhere else since stretch-security (as demanded in > #988321) > > debian-security-support | 2020.06.21~deb9u1 | stretch | > source, all > debian-security-support | 1:9+2022.06.02 | stretch-security | > source, all > debian-security-support | 2020.06.21~deb10u1 | buster | > source, all > debian-security-support | 1:11+2021.03.19| bullseye | > source, all > debian-security-support | 1:12+2022.08.06| bookworm | > source, all > debian-security-support | 1:12+2022.08.12| sid | > source, all > > As such, I'd like to use 1:10+2022.08.23 as the version and *not* > 1:10+2022.08.23~deb10u2. So long as the resulting version strings sort correctly, that seems OK. Regards, Adam
Bug#1017647: Update ucarp to current upstream version
Package: ucarp Version:1.5.2-2.2 There's newer version available at https://github.com/jedisct1/UCarp/ sadly still listed as 1.5.2 Among changes are the addition of --debug and --mcastip options, as well as some fixes. Please, consider updating.
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
On Thu, 2022-08-18 at 21:59 +0200, Ben Hutchings wrote: > Control: retitle -1 [i386] Unconditional LFENCE instructions in > FILL_RETURN_BUFFER > Control: tag -1 confirmed upstream > Control: found -1 5.18.14-1 > > On Wed, 2022-08-17 at 11:42 +0200, Etienne Vogt wrote: > > I can confirm that this bug also occurs on Athlon XP systems (Generic VIA > > KT333 motherboard, CPU AMD Athlon(tm) XP 2600+) : kernel panic early on > > boot. > > > > I suspect someone thought it would be a good idea to compile the kernel > > for P4 only, as both PIII and Athlon XP processors lack the SSE2 > > instruction set. > > > > That was a good guess, though we don't change the configuration like > that in stable updates. > > The RETbleed mitigations, which are not needed on these CPUs or even I mean PBRSB, not RETbleed. There are so many different issues to keep track of... Ben. > functional on 32-bit kernels, interact with the Spectre v2 mitigations, > which *are* used on these CPUs. And unfortunately the RETbleed > mitigations added some unconditional LFENCE instructions, which should > be conditional since they are part of SSE2. > > As a temporary workaround, disabling the Spectre v2 mitigation with the > kernel parameter "nospectre_v2" should allow this kernel version to run > on older CPUs without SSE2. We'll fix this properly in a later update. > > Ben. > -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Bug#1017439: gr-satellites: Dependency missing tnc_nx
Re: tony mancill > > Unable to import tnc_nx > > gr-tnc_nx needs to be installed to use Mobitex > > Thank you for the bug report. For whoever works on this one, there > appear to be other missing dependencies. When trying to reproduce this > on sid after installing gr-satellites, I get this error: > > $ gr_satellites AMGU-1 --audio default --samp 48e3 > Traceback (most recent call last): > File "/usr/bin/gr_satellites", line 15, in > from gnuradio import gr, blocks, audio > ModuleNotFoundError: No module named 'gnuradio' It would also be interesting to know how many sats/submodules need some missing python module so we know if the package is totally/somewhat/slightly unusable without it. Christoph (who still hasn't found the time to get into LEOs)
Bug#1017645: RM: litecoin [i386] -- ROP; no longer builds on i386
Package: ftp.debian.org Severity: normal Control: block 1015819 by -1 See #1015819 for background, attempts to fix the package on i386 were not successful and it's unlikely to have many users there.
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
On Thu, Aug 18, 2022 at 10:59 PM Ben Hutchings wrote: > > Control: retitle -1 [i386] Unconditional LFENCE instructions in > FILL_RETURN_BUFFER > Control: tag -1 confirmed upstream > Control: found -1 5.18.14-1 > > On Wed, 2022-08-17 at 11:42 +0200, Etienne Vogt wrote: > > I can confirm that this bug also occurs on Athlon XP systems (Generic VIA > > KT333 motherboard, CPU AMD Athlon(tm) XP 2600+) : kernel panic early on > > boot. > > > > I suspect someone thought it would be a good idea to compile the kernel > > for P4 only, as both PIII and Athlon XP processors lack the SSE2 > > instruction set. > > > > That was a good guess, though we don't change the configuration like > that in stable updates. > > The RETbleed mitigations, which are not needed on these CPUs or even > functional on 32-bit kernels, interact with the Spectre v2 mitigations, > which *are* used on these CPUs. And unfortunately the RETbleed > mitigations added some unconditional LFENCE instructions, which should > be conditional since they are part of SSE2. > > As a temporary workaround, disabling the Spectre v2 mitigation with the > kernel parameter "nospectre_v2" should allow this kernel version to run > on older CPUs without SSE2. We'll fix this properly in a later update. That breakage affects Stable. Expecting people to go and use workarounds on what was meant to be a stable update isn't acceptable. I really hope that the fix will be pushed within the next 24 hours with high urgency. Martin-Éric
Bug#1017644: ITP: libtitanium-json-ld-java -- implementation of the JSON-LD 1.1 specification in Java
Package: wnpp Severity: wishlist Owner: Markus Koschany X-Debbugs-Cc: debian-de...@lists.debian.org, a...@debian.org,debian-j...@lists.debian.org * Package name: libtitanium-json-ld-java Version : 1.3.1 Upstream Author : Filip Kolarik and the original authors and contributors * URL : https://github.com/filip26/titanium-json-ld * License : Apache-2.0 Programming Lang: Java Description : implementation of the JSON-LD 1.1 specification in Java An implementation of the JSON-LD 1.1 (JSON-based Serialization for Linked Data) specification in Java utilizing Jakarta JSON Processing. The goals of Titanium are: * conformance to the specification * secure, stable, fast, A+ code * minimal external dependencies * only jakarta.json-api is required * simple to use This package is a new dependency of apache-jena and required to fix #1014982.
Bug#1010751: clone: handle -b optional branch specification in VCS-Git
Package: git-buildpackage
Followup-For: Bug #1010751
Hello.
The attached commit implements your suggestions.
>From 3f8debeeeffbf57e77234848317b38d12b2d3363 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez
Date: Sun, 8 May 2022 16:51:26 +0200
Subject: [PATCH] clone: handle -b optional branch specification in VCS-Git
---
gbp/scripts/clone.py | 35 ---
tests/29_test_gbp_clone.py | 18 --
2 files changed, 40 insertions(+), 13 deletions(-)
diff --git a/gbp/scripts/clone.py b/gbp/scripts/clone.py
index 7e02f0e2..4825c572 100755
--- a/gbp/scripts/clone.py
+++ b/gbp/scripts/clone.py
@@ -47,10 +47,15 @@ def apt_showsrc(pkg):
def vcs_git_url(pkg):
+"""
+(url, None) most of the time
+(url, branch) when the VCS-Git contains -b
+(None, None) when the VCS-Git field is missing
+"""
repos = {}
out = apt_showsrc(pkg)
-vcs_re = re.compile(r'(x-)?vcs-git:\s*(?P[^ ]+)$', re.I)
+vcs_re = re.compile(r'(?:x-)?vcs-git:\s*([^ ]+)(?:\s+-b\s+([^ ]+))?$', re.I)
version_re = re.compile(r'Version:\s*(?P.*)$', re.I)
end_re = re.compile(r'\s*$')
@@ -58,7 +63,7 @@ def vcs_git_url(pkg):
for line in out.split('\n'):
m = vcs_re.match(line)
if m:
-repo = m.group('repo')
+repo = m.groups()
continue
m = version_re.match(line)
if m:
@@ -72,7 +77,7 @@ def vcs_git_url(pkg):
if not repos:
gbp.log.err("Can't find any vcs-git URL for '%s'" % pkg)
-return None
+return None, None
s = sorted(repos, key=cmp_to_key(DpkgCompareVersions()))
return repos[s[-1]]
@@ -80,27 +85,31 @@ def vcs_git_url(pkg):
def repo_to_url(repo):
"""
+(url, None) most of the time
+(url, branch) when VCS-Git is required and contains a -b option
+(None, None) when VCS-Git is required but missing.
+
>>> repo_to_url("https://foo.example.com;)
-'https://foo.example.com'
+('https://foo.example.com', None)
>>> repo_to_url("salsa:agx/git-buildpackage")
-'https://salsa.debian.org/agx/git-buildpackage.git'
+('https://salsa.debian.org/agx/git-buildpackage.git', None)
>>> repo_to_url("github:agx/git-buildpackage")
-'https://github.com/agx/git-buildpackage.git'
+('https://github.com/agx/git-buildpackage.git', None)
"""
parts = repo.split(":", 1)
if len(parts) != 2:
-return repo
+return repo, None
else:
proto, path = parts
if proto == 'salsa':
-return 'https://salsa.debian.org/%s.git' % path
+return 'https://salsa.debian.org/%s.git' % path, None
if proto == 'github':
-return 'https://github.com/%s.git' % path
+return 'https://github.com/%s.git' % path, None
elif proto in ['vcsgit', 'vcs-git']:
return vcs_git_url(path)
else:
-return repo
+return repo, None
def add_upstream_vcs(repo):
@@ -189,7 +198,7 @@ def main(argv):
return 1
else:
remote_repo = args[1]
-source = repo_to_url(remote_repo) if options.aliases else remote_repo
+source, vcs_git_branch = repo_to_url(remote_repo) if options.aliases else remote_repo, None
if not source:
return 1
@@ -212,6 +221,10 @@ def main(argv):
postclone = options.postclone
(options, args) = parse_args(argv)
+if vcs_git_branch and vcs_git_branch != options.debian_branch:
+gbp.log.warn(f'VCS-Git: -b {vcs_git_branch} overrides --debian-branch={options.debian_branch}')
+options.debian_branch = vcs_git_branch
+
# Track all branches:
if options.all:
remotes = repo.get_remote_branches()
diff --git a/tests/29_test_gbp_clone.py b/tests/29_test_gbp_clone.py
index f1ac3925..b1930612 100644
--- a/tests/29_test_gbp_clone.py
+++ b/tests/29_test_gbp_clone.py
@@ -15,7 +15,7 @@ Vcs-Git: git://honk.sigxcpu.org/git/git-buildpackage.git
Version: 0.8.14
Standards-Version: 3.9.8
-Vcs-Git: https://git.sigxcpu.org/cgit/git-buildpackage/ -b foo
+Vcs-Git: https://git.sigxcpu.org/cgit/git-buildpackage/ unexpected_info
Version: 0.8.12.2
Standards-Version: 3.9.8
@@ -31,4 +31,18 @@ Vcs-Git: git://honk.sigxcpu.org/git/git-buildpackage.git
@patch('gbp.scripts.clone.apt_showsrc', return_value=show_src)
def test_vcs_git_url(self, patch):
self.assertEqual(vcs_git_url('git-buildpackage'),
- 'https://git.sigxcpu.org/cgit/git-buildpackage/')
+ ('https://git.sigxcpu.org/cgit/git-buildpackage/', None))
+
+@skip_without_cmd('dpkg')
+@patch('gbp.scripts.clone.apt_showsrc', return_value="""
+Version: 0.7.6-4
+Vcs-Git: https://git.codelabs.ch/git/pcscada.git -b debian
+""")
+def test_vcs_git_url_branch(self, patch):
+self.assertEqual(vcs_git_url('pcscada'),
+ ('https://git.codelabs.ch/git/pcscada.git', 'debian'))
Bug#1017642: ITP: libjsonp2-java -- Jakarta JSON Processing
Package: wnpp Severity: wishlist Owner: Markus Koschany X-Debbugs-Cc: debian-de...@lists.debian.org, a...@debian.org,debian-j...@lists.debian.org * Package name: libjsonp2-java Version : 2.1.1 Upstream Author : Oracle and/or its affiliates * URL : https://github.com/eclipse-ee4j/jsonp * License : EPL-2.0 and GPL-2 with classpath exception Programming Lang: Java Description : Jakarta JSON Processing Jakarta JSON Processing provides portable APIs to parse, generate, transform, and query JSON documents. This project contains Jakarta JSON Processing specification, API and TCK. This implementation provides a newer API and is not backwards compatible with libjsonp-java. This package is a new dependency of apache-jena and required to fix #1014982.
Bug#1017643: coreutils: uniq -i entirely non-functional?
Package: coreutils Version: 8.32-4+b1 Severity: normal Dear Maintainer, Consider: -- >8 -- $ printf '%s\n' a A ą Ą и И | uniq -ic 2 a 1 ą 1 Ą 1 и 1 И -- >8 -- Contrast uniq(1): -- >8 -- -i, --ignore-case ignore differences in case when comparing -- >8 -- наб -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-16-amd64 (SMP w/24 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages coreutils depends on: ii libacl1 2.2.53-10 ii libattr1 1:2.4.48-6 ii libc62.31-13+deb11u3 ii libgmp10 2:6.2.1+dfsg-1+deb11u1 ii libselinux1 3.1-3 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
Control: retitle -1 [i386] Unconditional LFENCE instructions in FILL_RETURN_BUFFER Control: tag -1 confirmed upstream Control: found -1 5.18.14-1 On Wed, 2022-08-17 at 11:42 +0200, Etienne Vogt wrote: > I can confirm that this bug also occurs on Athlon XP systems (Generic VIA > KT333 motherboard, CPU AMD Athlon(tm) XP 2600+) : kernel panic early on > boot. > > I suspect someone thought it would be a good idea to compile the kernel > for P4 only, as both PIII and Athlon XP processors lack the SSE2 > instruction set. > That was a good guess, though we don't change the configuration like that in stable updates. The RETbleed mitigations, which are not needed on these CPUs or even functional on 32-bit kernels, interact with the Spectre v2 mitigations, which *are* used on these CPUs. And unfortunately the RETbleed mitigations added some unconditional LFENCE instructions, which should be conditional since they are part of SSE2. As a temporary workaround, disabling the Spectre v2 mitigation with the kernel parameter "nospectre_v2" should allow this kernel version to run on older CPUs without SSE2. We'll fix this properly in a later update. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Bug#1012289: RFH: lintian -- Debian package checker
Hi Bastien, Bastien Roucariès wrote: > I have just reinstanced the sliding windows on master. Yay, thanks! > could you please check why autotest fail Will do, but probably not before the weekend. > BTW I am really supprised that test are not run at build time The test suite currently runs around 35-40 minutes on my 6 year old 4-core workstation and even longer on Salsa CI (1h30m to 1h45m). (At least those were the numbers when I last measured it. There are a few commits in there now which probably reduce that time a bit.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1017641: RFP: snappymail -- Simple, modern, lightweight & fast web-based email client
Package: wnpp Severity: wishlist X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org * Package name: snappymail Version : 2.17.2 Upstream Author : https://github.com/the-djmaze * URL : https://snappymail.eu/ * License : AGPL-3 Programming Lang: PHP, Javascript Description : Simple, modern, lightweight & fast web-based email client Simple, modern, lightweight & fast web-based email client. The drastically upgraded & secured fork of RainLoop Webmail Community edition. Rainloop was removed from Debian due to packaging issues (#1006060, #1001632), and it's unclear if the fork fixes that. The primary goal of the fork seems to have been to fix a security issue (#1004548), but also unblock maintenance of the project: https://github.com/RainLoop/rainloop-webmail/issues/2162 It seems like it would be nice to consider packaging this instead of rainloop...
Bug#1017640: RFS: libusbgx/0.2.0-2 [ITP] -- C library encapsulating the kernel USB gadget-configfs
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libusbgx": * Package name: libusbgx Version : 0.2.0-2 Upstream Author : Krzysztof Opasiak * URL : https://github.com/linux-usb-gadgets/libusbgx * License : GPL-2.0+, __AUTO_PERMISSIVE__, LGPL-2.1+ * Vcs : https://salsa.debian.org/debian/libusbgx Section : libs The source builds the following binary packages: libusbgx-dev - Development files for libusbgx libusbgx-doc - Documentation files for libusbgx libusbgx2 - C library encapsulating the kernel USB gadget-configfs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libusbgx/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libu/libusbgx/libusbgx_0.2.0-2.dsc Changes for the initial release: libusbgx (0.2.0-2) unstable; urgency=medium . * Initial release. (Closes: #1016019) Regards, -- Manuel Traut
Bug#1017577: sqlcipher: new upstream version available
Control: affects 1017577 + src:rust-libsqlite3-sys librust-libsqlite3-sys-dev The old version of sqlcipher in debian means that building from the packaged versions of the rust libsqlite3-dev crate with "buildtime_bindgen" and "sqlcipher" features active will fail. --dkg signature.asc Description: PGP signature
Bug#1017556: src:redis: fails to migrate to testing for too long: autopkgtest regressions
Hi Chris, On 18-08-2022 21:00, Chris Lamb wrote: Perhaps jobs just need to be resubmitted? I see that the version numbers on: https://qa.debian.org/excuses.php?package=redis ... refer to the unfixed versions; for example, python-fakeredis (version 1.6.1-1) was fixed in 1.7.1-1. I'll keep an eye on it and massage things if needed. Thanks for uploading my MR so promptly. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1017639: ITP: elpa-orderless -- Emacs completion style that matches multiple regexps in any order
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-orderless Version : 0.7 Upstream Author : Omar Antolín Camarena * URL or Web page : https://github.com/oantolin/orderless * License : GPL-3+ Programming Lang: Emacs Lisp Description : Emacs completion style that matches multiple regexps in any order This Emacs package offers a completion style, that is an completion matching engine, capable of matching multiple regexps, each following different regexp syntax, in any order. Aymeric Agon-Rambosson
Bug#1015254: transition: opencascade
Hi Sebastian, netgen has now been fixed. Can you schedule a binNMU for gmsh, so that gmsh will be installable again? (there is no sourceful upload needed to make that happen) Possibly, not sure if really needed, with a Dep-Wait on netgen >= 6.2.2006+really6.2.1905+dfsg-5.1, as some ports have not recompiled netgen yet. -- Thanks tobi On Tue, Aug 16, 2022 at 09:10:33PM +0200, Sebastian Ramacher wrote: > On 2022-07-18 14:26:26 +0200, Tobias Frost wrote: > > Hi Release team, > > > > opencascade has a new release with bumps so name to 7.6 The transition > > tracker [1] > > correctly picked it up already after the upload to experimental. > > > > [1] https://release.debian.org/transitions/html/auto-opencascade.html > > > > This bug is also to help me keeping track of the transistion as it will > > need at least > > one sourceful upload of netgen. > > > > building the reverse depenencies, results are: > > > > Dependency level 2 > > > > freecad (sid only)✔ (RC buggy due to other issues) > > kicad ✔ > > netgen✘ (fixed upstream, #1014964)) > > > > With a local built of netgen (patched to just make it compile, not > > preserving functionality), > > I could get also Dependency level 3 to be built: > > > > gmsh_4.5.6+ds1 ✔ (BDs on netgen) > > > > Dependency Level 4: > > deal.ii_9.1.1-9 ✔ (BDs on gmsh) > > > > > > I'm not sure if I can come up with a proper patch for netgen, but I will > > try. > > netgen and reverse depenencies have been removed. This transition is > done. > > Cheers > -- > Sebastian Ramacher
Bug#1015254: transition: opencascade
Apperantly it has been done alrasdy, sorry for the noise and disregard the previous mail… -- tobi Hi Sebastian, netgen has now been fixed. Can you schedule a binNMU for gmsh, so that gmsh will be installable again? (there is no sourceful upload needed to make that happen) Possibly, not sure if really needed, with a Dep-Wait on netgen >= 6.2.2006+really6.2.1905+dfsg-5.1, as some ports have not recompiled netgen yet. -- Thanks tobi On Tue, Aug 16, 2022 at 09:10:33PM +0200, Sebastian Ramacher wrote: > On 2022-07-18 14:26:26 +0200, Tobias Frost wrote: > > Hi Release team, > > > > opencascade has a new release with bumps so name to 7.6 The transition > > tracker [1] > > correctly picked it up already after the upload to experimental. > > > > [1] https://release.debian.org/transitions/html/auto-opencascade.html > > > > This bug is also to help me keeping track of the transistion as it will > > need at least > > one sourceful upload of netgen. > > > > building the reverse depenencies, results are: > > > > Dependency level 2 > > > > freecad (sid only)✔ (RC buggy due to other issues) > > kicad ✔ > > netgen✘ (fixed upstream, #1014964)) > > > > With a local built of netgen (patched to just make it compile, not > > preserving functionality), > > I could get also Dependency level 3 to be built: > > > > gmsh_4.5.6+ds1 ✔ (BDs on netgen) > > > > Dependency Level 4: > > deal.ii_9.1.1-9 ✔ (BDs on gmsh) > > > > > > I'm not sure if I can come up with a proper patch for netgen, but I will > > try. > > netgen and reverse depenencies have been removed. This transition is > done. > > Cheers > -- > Sebastian Ramacher
Bug#1017439: gr-satellites: Dependency missing tnc_nx
On Tue, Aug 16, 2022 at 12:58:26PM +0300, Apostolos Kefalas wrote: > Package: gr-satellites > Version: 3.5.1-2 > Severity: normal > > I have tried the following: > > $ gr_satellites AMGU-1 --audio default --samp 48e3 > > and I got an error message: > > Unable to import tnc_nx > gr-tnc_nx needs to be installed to use Mobitex Thank you for the bug report. For whoever works on this one, there appear to be other missing dependencies. When trying to reproduce this on sid after installing gr-satellites, I get this error: $ gr_satellites AMGU-1 --audio default --samp 48e3 Traceback (most recent call last): File "/usr/bin/gr_satellites", line 15, in from gnuradio import gr, blocks, audio ModuleNotFoundError: No module named 'gnuradio' signature.asc Description: PGP signature
Bug#939904: Temporary network disruption during upgrade
On Thu, 2022-08-18 at 18:07 +0200, Raphaël Halimi wrote: > Le 18/08/2022 à 16:59, Luca Boccassi a écrit : > > No, custom and unsupported setups are unsupported. Compatibility is > > provided for default environments, anything outside of it can and will > > break at any given time, and it's not really feasible to do otherwise > > given the uncountable amount of possible permutations. This time > > there's a clear and unambiguos NEWS entry with a notification, which > > doesn't even always happen. > > What I meant is that I thought systemd-networkd (which partly relies on > systemd-resolved) was considered supported since it was shipped with > systemd and thus installed by default (unlike, for example, netplan), > albeit not enabled. > > Should I understand that the only supported way to configure the network > in Debian is ifupdown with a plain /etc/resolv.conf file, and everything > outside of this scope is considered custom and thus, unsupported ? I'm > not being ironical here, it's a legitimate question. The default supported network configuration managers on Debian are NetworkManager for desktop environments (default brought in by Gnome, the default desktop env), and ifupdown (which is priority: important) for headless environments. > > > Wrong, I always receive e-mails with news as well as changelogs during > > > upgrades, with the more recent examples being on July 13, 22 and 25. I > > > don't know why it didn't work this time, but I can hardly believe that > > > it's apt-listchanges' fault. > > > > And yet it is, and it's been a known issue for quite some time: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422 > > OK, you're right on this point, I didn't know that. Apologies. But it > also means that other sysadmins will be in the same case too when the > upgrade will take place (when bookworm is released, or when systemd > 251.3-2 will be backported to bullseye) and will have their DNS > resolution temporarily broken after the upgrade. > > But I guess you'll probably argue that it's their fault for using > systemd-resolved. NEWS files' main purpose is to communicate breaking changes, so I hope the issue in apt-listchanges is fixed before the release. Feel free to go bump the severity if you wish. I cannot do much about it. > > > I think you don't understand my position: I don't care about resolvconf > > > or openresolv, I just want to use systemd-resolved (not the systemd > > > resolvconf interface, but the systemd-resolved service itself!) and > > > avoid breakage during upgrades for all users. > > > > > > Look, I'm just trying to help here. You made a change, it has serious > > > consequences for systemd-resolved users, and I hinted them to you, > > > that's all. I think this is a bad change, but that's another matter. > > > Being obtuse and condescending won't help. > > > > Name-calling won't help either. > > Right, but at least admit that you're being a bit harsh to me since the > beginning of this thread, rejecting all my arguments and refusing to see > the problem here, basically saying that the resulting breakage is not > your fault and systemd-resolved users brought it on themselves by using > it because it's "unsupported". > > Again, I don't care about resolvconf or openresolv, I care about > sysadmins who use systemd-networkd/resolved on their servers or > containers, and I'm just trying to avoid problems for them as well as > for myself in the future. > > systemd brought a lot of controversy when it was adopted in Debian, and > I myself was amongst the people who were quite unhappy when it happened > (I still think that Jessie was too soon, it was not mature enough, but > that's another story). > > Now that we started to familiarize with its different parts and all in > all find it very convenient that they're installed by default, you > slowly remove them one by one (systemd-machined, systemd-timesyncd, > systemd-boot, and now systemd-resolved... Which will be the next ?), > forcing us sysadmins to constantly update our automated installation > procedures (debian-installer hooks, ansible/puppet recipes, container > images, etc etc), and defeating the very purpose of systemd to be "a > suite of basic building blocks for a Linux system" that we finally embraced. > > It's almost as if you want to discourage us to use the non-init-related > parts of systemd. Staying with a distro's default means there's almost always a seamless upgrade path when breaking changes happen, though not always. Going for a custom setup means sometimes there is, sometimes there's not. It's always a tradeoff. This breaking change means there's now a supported way to run resolved, and it's the easiest possible way for all those that weren't using it before, which is the majority given there was no support and no integration before. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1017637: havp: Not working anymore since linux-image-* v5.15.
Source: havp Version: 0.93-2 Severity: grave While testing havp before uploading I noticed that starting havp ends quickly with: | Starting HAVP Version: 0.93 | Filesystem not supporting mandatory locks! | On Linux, you need to mount filesystem with "-o mand" The so called "mandatory locks" have been removed from the Linux kernel in v5.15 [0]. havp is compiled to use it and fails to continue if it is not working. We have to options now: - Remove havp from unstable. - Pass --disable-locking to configure and build it without it. This forces havp to download everything scan it first. I'm not a user of havp so I can't tell if disabling locking is an option. There is a script with loopback mount and everything just to use the locking without enabling it on the main partition. The first 5.15 kernel was uploaded by the end of 2021 and this went unnoticed until now. Probably even longer if it wasn't for #1016270. Given that and the dropping popcon numbers, I lean towards RM. Anyone? [0] https://git.kernel.org/torvalds/c/f7e33bdbd6d1bdf9c3df8bba5abcf3399f957ac3 Sebastian
Bug#1017556: src:redis: fails to migrate to testing for too long: autopkgtest regressions
Paul Gevers wrote: > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. I think I've fixed the two underlying issues have been fixed: * python-fakeredis was fixed in #1014101 * python-redis was fixed in #1014102 Perhaps jobs just need to be resubmitted? I see that the version numbers on: https://qa.debian.org/excuses.php?package=redis ... refer to the unfixed versions; for example, python-fakeredis (version 1.6.1-1) was fixed in 1.7.1-1. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1009112: python-eventlet: (autopkgtest) needs update for python3.10: tests.patcher_test.test_patcher_existing_locks_locked
Hi, On Thu, 7 Apr 2022 13:57:24 +0200 Thomas Goirand wrote: This issue was reported upstream: https://github.com/eventlet/eventlet/issues/730 https://github.com/eventlet/eventlet/issues/739 This looks kind of serious, and not just an issue with tests. So blacklisting the failed tests isn't an option. Ping, any progress on this? python-eventlet is a key package. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1017556: src:redis: fails to migrate to testing for too long: autopkgtest regressions
Hi Paul, > I have prepared a new version of python-fakeredis which builds and > passes its autopkgtest in unstable: > https://salsa.debian.org/python-team/packages/python-fakeredis/-/merge_requests/1 > https://salsa.debian.org/python-team/packages/python-fakeredis/-/merge_requests/2 > https://salsa.debian.org/python-team/packages/python-fakeredis/-/merge_requests/3 Uploading now. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1017620: kicad: Minor kicad upgrade forces install of tons of dev packages and tcl+tk?
Source: opencascade Followup-For: Bug #1017620 Thanks for the report. I can see that libocct-draw-7.x depends on a bunch of -dev packages [1], but that has been since ages… (at least this bits have not been changed for the 7.6.3 update) I'll need to investigate if those dependencies are really needed or have been misplaced and should be in libocct-draw7.x-dev instead. [1] https://salsa.debian.org/science-team/opencascade/-/blob/master/debian/control#L328 -- tobi
Bug#1017636: lists.debian.org: List-Archive field used instead of Archived-At
Package: lists.debian.org Messages from Debian lists include a field like the following: List-Archive: https://lists.debian.org/msgid-search/87h73gyaiw@janja.pimeys.fr This is not correct: [1] shows List-Archive should point to the archive for the entire list, so probably to https://lists.debian.org/debian-devel-announce/ or similar. The Archived-At field[2] should be used for links to individual messages. Ansgar [1]: https://www.rfc-editor.org/rfc/rfc2369.html#section-3.6 [2]: https://www.rfc-editor.org/rfc/rfc5064.html
Bug#1017635: ITP: lsip6 -- Find link-local IPv6 address of remote end in point-to-point USB connections
Package: wnpp Severity: wishlist Owner: Evangelos Ribeiro Tzaras X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: lsip6 Version : 0.1.0 Upstream Author : Martijn Braam * URL : https://git.sr.ht/~martijnbraam/lsip6 * License : MIT Programming Lang: Python Description : Finds remote link-local IPv6 address in point-to-point IPv6 network `lsip6` is a `ls` for link-local IPv6 addresses This is very handy in finding e.g. USB connected mobile phone even without DHCP set up. . It sends a ICMPv6 (ping) to ff02::1 (all devices on link) causing devices on the link to start Neighbor Solicitation (part of the IPv6 Neighbour Discovery Protocol NDP) in order to figure out how to talk to each other. I intend to package this as part of the Python Application or Debian on Mobile teams.
Bug#1016754: po4a: Incorrect bold handling for manpages bug 2
Hello, could you please be more specific on what's going wrong? You say that the "english is in roman, while the translated text is in German". Well. The translation being in German does not sound like a bug to me :) I tried to check on the rendered manpages, but I don't see any difference between the english and german text here. They are both rendered as regular text. I'm using `man -l ` to render the page, so maybe that's why I don't see any difference. Please tell me how to render if I'm not doing it right. Thanks for the info, Mt - Le 6 Aoû 22, à 17:56, Helge Kreutzmann deb...@helgefjell.de a écrit : > Package: po4a > Version: 0.67-2 > Severity: normal > X-Debbugs-Cc: Mario Blättermann > > I'm the Debian maintainer of manpages-l10n and support upstream > (Mario) in maintaing the po based translations of manpages. > > I noticed the following incorrect bold formatting after some tables. > Search for "the innermost subdirectories are removed" in the english > original and for "werden die innersten Unterverzeichnisse" in the > german translations (all attached, including the intermediary po > file). > > The english original is in roman font, while the translated text is in > German. This specific paragraph looks like the following in the po > file: > > #. type: Plain text > #: archlinux debian-bullseye debian-unstable fedora-36 fedora-rawhide > #: mageia-cauldron opensuse-leap-15-4 opensuse-tumbleweed > msgid "" > "In case of I the innermost subdirectories are removed " > "when the unit is stopped\\&. It is possible to preserve the specified " > "directories in this case if I is configured to " > "B or B (see below)\\&. The directories specified with " > "I, I, I, " > "I are not removed when the unit is stopped\\&." > msgstr "" > "Im Falle von I werden die innersten Unterverzeichnisse " > "entfernt, wenn die Unit gestoppt wird\\&. Es ist möglich, in diesem Fall die > " > "festgelegten Verzeichnisse zu erhalten, falls I " > "auf B oder B konfiguriert ist (siehe unten)\\&. Die mit " > "I, I, I, " > "I festgelegten Verzeichnisse werden nicht entfernt, > " > "wenn die Unit gestoppt wird\\&." > > I could not detect anything wrong here, so I suspect that something > got wrong in the table above (table 2). I noticed that the original > includes the strings in the table in \fI$XDG_CONFIG_HOME\fR, while the > translation uses \fI$XDG_CONFIG_HOME\fP. > > I tried changing the last \fP (and all) to an \fR, but this did not > change this issue. > > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel taint flags: TAINT_UNSIGNED_MODULE > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL > set to de_DE.UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages po4a depends on: > ii gettext 0.21-6 > ii libpod-parser-perl 1.65-1 > ii libsgmls-perl 1.03ii-37 > ii libsyntax-keyword-try-perl 0.27-1 > ii libyaml-tiny-perl 1.73-1 > ii opensp 1.5.2-13+b2 > ii perl5.34.0-5 > > Versions of packages po4a recommends: > ii liblocale-gettext-perl 1.07-4+b2 > ii libterm-readkey-perl 2.38-1+b3 > ii libtext-wrapi18n-perl 0.06-9 > ii libunicode-linebreak-perl 0.0.20190101-1+b4 > > po4a suggests no packages. > > -- no debconf information > > -- > Dr. Helge Kreutzmann deb...@helgefjell.de > Dipl.-Phys. http://www.helgefjell.de/debian.php >64bit GNU powered gpg signed mail preferred >Help keep free software "libre": http://www.ffii.de/
Bug#1017556: src:redis: fails to migrate to testing for too long: autopkgtest regressions
Control: tags -1 pending patch Hi, On Wed, 17 Aug 2022 21:20:06 +0200 Paul Gevers wrote: Your package src:redis has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package is a key package and so is python-fakeredis. Hence, the autopkgtest regression won't be fixed by autoremoval. I have prepared a new version of python-fakeredis which builds and passes its autopkgtest in unstable: https://salsa.debian.org/python-team/packages/python-fakeredis/-/merge_requests/1 https://salsa.debian.org/python-team/packages/python-fakeredis/-/merge_requests/2 https://salsa.debian.org/python-team/packages/python-fakeredis/-/merge_requests/3 Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1017634: ITP: vdt -- mathematical library
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: vdt Version : 0.4.4 Upstream Authors: Danilo Piparo URL : https://github.com/dpiparo/vdt * License : LGPL-3-or-later Description : mathematical library This is vectorised math library - a collection of fast and inline implementations of mathematical functions - the functions can be used in autovectorised loops - double and single precision implementations are available - no overhead present, no intrinsics used . A scalar (T(T)) and array signature (void(const unsigned int,T*,T*)) are provided. Born and developed at CERN, it is used, among the others, by LHC experiments and the Geant4 simulation toolkit. . Much of the VDT code is inspired by the well known Cephes mathematical library.
Bug#1017633: ITP: unuran -- Universal Non-Uniform RAndom Number generator
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: unuran Version : 1.9.0 Upstream Authors: Josef Leydold URL : https://statmath.wu.ac.at/unuran/ * License : Description : Universal Non-Uniform RAndom Number generator This is a collection of algorithms for generating non-uniform pseudorandom variates as a library of C functions designed and implemented by the ARVAG (Automatic Random VAriate Generation) project group in Vienna.
Bug#1012289: RFH: lintian -- Debian package checker
Le mardi 16 août 2022, 13:37:39 UTC Axel Beckert a écrit : Hi, I have just reinstanced the sliding windows on master. could you please check why autotest fail BTW I am really supprised that test are not run at build time Bastien > Hi Bastien, > > Bastien Roucariès wrote: > > I will restep to be a lintian maint. > > Yay, thanks! Much appreciated. > > You're still in the "lintian" group of Salsa, so you should be still > able to commit to the repo. > > > Could you please prepare a list of urgent action ? > > Usually, if I consider a lintian bug to be urgent-ish, I bumped its > severity to important. (And you bumped one to serious already, too. > > :-) So anything RC or "important" on > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=lintian;dist=unstable > is what we should focus on first, if possible. Those marked confirmed > are those I already looked at closer: > > * #993613 > * #1014083 > * #1014162 > > Then there are two other topics I have a focus on, because I think, > they're important for all of us, because they're annoying: > > * False Positives: > > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=lintian-maint%40debian > .org=false-positive > > * Automatically migrating non-bracketed lintian overrides to bracketed > ones. I started here, but it's mostly lacking migration regexp > mappings for the hundreds of tags being affected: > > https://salsa.debian.org/lintian/lintian/-/blob/migrate-overrides/bin/linti > an-migrate-overrides-to-pointed-hints > > Note that this is currently only inside a feature branch which is > not yet merged as it is far from helpful yet. > > This is actually my fix for https://bugs.debian.org/1007002 > > Oh, and one more thing: I want to adhere to Semantic Versioning — the > real one (https://semver.org/), not the one which Felix called > "Semantic Versioning" despite it wasn't Semantic Versioning. > > So the versioning from now on will be BREAK.FEATURE.BUGFIX: > > * Changing configuration semantic or syntax or exit codes will be a BREAK. > * Adding new tags will be a FEATURE. > * No functional changes except bug fixes will be a BUGFIX. > * Pure documentation or build-system changes will be a BUGFIX, too. > > And probably also: > > * Renaming tags will be a BREAK. (Feel free to discuss if you > disagree. :-)) > > Not yet sure about: > > * Will be removing a tag a BREAK, too? > > P.S.: Yeah, there was a bit of silence (despite not complete silence) > from me on lintian, but that was mostly due to holidays (in which was > way less online that I expected), some pre-holiday and some > post-holidays stress. And also because of RC bugs in some of my other > similarily important packages. Expect some more activity on Lintian > towards to next weekend. :-) > > Regards, Axel signature.asc Description: This is a digitally signed message part.
Bug#1015487: libfiu: ftbfs with LTO (link time optimization) enabled
Hey Alberto, Just briefly reaching out to you just in case this slipped your mind during your time away from the internet. Hopefully, it's quite an easy fix. Best wishes, Chris > On 20 July 2022 00:18:29 GMT-06:00, Chris Lamb wrote: >>Hi Alberto, >> >>Any ideas why libfiu fails to build with -flto=auto -ffat-lto-objects >>(etc.) enabled? > > Just FYI I have extremely limited connectivity until the end of the > month, so I'm afraid I won't have a chance to look before then :( > > >>> cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE >>> -fPIC -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=. >>> -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat >>> -Werror=format-security -std=c99 -pedantic -Wall -std=c99 -pedantic >>> -Wall tests/strdup.c -lfiu -o tests/strdup.bin >>> LD_LIBRARY_PATH=../libfiu/ >>> LD_PRELOAD=./libs/fiu_run_preload.so:./libs/fiu_posix_preload.so >>> ./test-enable_stack >>> test-enable_stack: test-enable_stack.c:39: main: Assertion `func2() == >>> 1' failed. > > From this it seems the issue is with the stack trace collection. If LTO > is doing some inlining for example (which wouldn't surprise me) then it > could cause the test to fail. > > I'll look in more detail at the beginning of August.
Bug#1017632: lintian: False positive on partial match for bin-sbin-mismatch
Package: lintian
Version: 2.115.2
Severity: normal
Hi!
The bin-sbin-mismatch triggers false positives on partial matches such
as /usr/bin/dpkg-www and /usr/sbin/dpkg-www-installer, or
/usr/bin/dpkg and /usr/sbin/dpkg-fsys-usrunmess.
This is due to the check in lib/Lintian/Check/Files/Contents.pm, where
it essentially does the following:
perl -E '$str = "/bin/dpkg-www-installer"; \
say "wrong-match" if $str =~ m{\B/\Qbin/dpkg-www\E\b}x'
I've got false-positives in dpkg and dpkg-www.
Thanks,
Guillem
Bug#1003928: gnome-todo: Gnome-ToDo does not longer work when change date of an entry
Control: forwarded -1 https://gitlab.gnome.org/World/Endeavour/-/issues/429 I had to upload gnome-todo 41 to Unstable today because I was unable to get the older version to build. That means gnome-todo would have been removed from Testing soon otherwise. Thank you, Jeremy Bicha
Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles
Hi, On 8/17/22 21:56, Michael Biebl wrote: Looking at the package in question $ cat debian/passwd.tmpfiles # If a password operation is in progress and we lose power, stale lockfiles # can be left behind. Clear them on boot. r! /etc/gshadow.lock r! /etc/shadow.lock r! /etc/passwd.lock r! /etc/group.lock r! /etc/subuid.lock r! /etc/subgid.lock It appears this particular tmpfile is meant to be run only during boot and not during the runtime of the system. I've been thinking about this a bit more and there are basically two use cases for tmpfiles: 1. Creating files in non-persistent locations (/run) and cleanup (at boot and via cron job): One example is the case above. The dependency on "systemd | systemd-tmpfiles" does not cause tmpfiles to be processed during boot or normal system operation with sysvinit-core as the systemd-standalone-tmpfiles package ships no init script or cron job taking over the function of systemd-tmpfiles-setup.service and systemd-tmpfiles-clean.timer. I expect that such tmpfiles could mostly be ignored in init-less environments such as containers as these usually don't expect cleanup actions for boot and service startup is handled differently. With one exception this could be covered by mandating that init systems must run tmpfiles during boot and packages do not need an explicit dependency for this to happen. (Why mandate the init system to do so? Because I do not think we want to require passwd and other packages to ship an init script just to call systemd-tmpfiles or reimplement the equivalent behavior in a different way.) However there is also the issue that tmpfiles should probably be called on package installation to create the requested files below /run before the next system reboot; they might be relevant for the service to start. It might be sufficient to only call systemd-tmpfiles if some init system is used (i.e., not in the init-less container case) and so also be covered by the requirement above (it would have to include some systemd-tmpfiles binary to be available). Some tmpfiles also include only exception rules for cleanup, for example gvfsd-fuse-tmpfiles.conf: x /run/user/*/gvfs This case does not need an explicit dependency either. 2. Creating files in persistent locations (e.g., /var/cache, /var/lib, ...): Here it would be enough to create the files once (e.g., during the call in the maintainer script), but it is nice if there is an easy way to recreate directories with the right permissions. This is the case where it might be relevant to call systemd-tmpfiles even in init-less environments. Therefore an explicit dependency might be warranted. I'm not sure how relevant this is in Debian, but expect this to not be widely used so far. In conclusion, the unconditional dependency on "systemd | systemd-tmpfiles" is probably not the best way to proceed. Ansgar
Bug#1016753: po4a: Incorrect bold handling for manpages bug 1
tag 1016753 fixed-upstream thanks Hello, I believe that this bug is fixed upstream by commit https://github.com/mquinson/po4a/commit/6b5139e7c5a7d789f51f8912cd2a6a835194c84b Thanks for reporting, Mt - Le 6 Aoû 22, à 17:55, Helge Kreutzmann deb...@helgefjell.de a écrit : > Package: po4a > Version: 0.67-2 > Severity: normal > X-Debbugs-Cc: Mario Blättermann > > I'm the Debian maintainer of manpages-l10n and support upstream > (Mario) in maintaing the po based translations of manpages. > > I noticed the following incorrect bold formatting in table headings, > when the translation is spanning more than one line in the po file. > Exactly at the line break in the po file, the bold formatting is > stopped. > > The english orginal file does not line wrap these lines, so maybe a > ,nowrap is missing here? > > This is an example, the full files are attached. > > .br > .B Table\ \&1.\ \ limit directives, their equivalent ulimit shell > commands and the unit used > .TS > > This becomes the following in the po file: > #. type: Plain text > #: archlinux debian-bullseye debian-unstable fedora-36 fedora-rawhide > #: mageia-cauldron opensuse-leap-15-4 opensuse-tumbleweed > msgid "" > "B "shell commands and the unit used>" > msgstr "" > "B "Ulimit-Shell-Befehle und die verwandte Einheit>" > > and thus the following in the German man page: > > .br > \fBTabelle\ \&1.\ \, ihre äquivalenten > Ulimit\-Shell\-Befehle und die verwandte Einheit\fP > .TS > > In the rendered man pages, bold font stops after "äquivalenten". If I > remove the line break manually in the generated man page, then the > entire line is bold. > > This happens consistently for all table headings in this man page. > > > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel taint flags: TAINT_UNSIGNED_MODULE > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL > set to de_DE.UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages po4a depends on: > ii gettext 0.21-6 > ii libpod-parser-perl 1.65-1 > ii libsgmls-perl 1.03ii-37 > ii libsyntax-keyword-try-perl 0.27-1 > ii libyaml-tiny-perl 1.73-1 > ii opensp 1.5.2-13+b2 > ii perl5.34.0-5 > > Versions of packages po4a recommends: > ii liblocale-gettext-perl 1.07-4+b2 > ii libterm-readkey-perl 2.38-1+b3 > ii libtext-wrapi18n-perl 0.06-9 > ii libunicode-linebreak-perl 0.0.20190101-1+b4 > > po4a suggests no packages. > > -- no debconf information > > -- > Dr. Helge Kreutzmann deb...@helgefjell.de > Dipl.-Phys. http://www.helgefjell.de/debian.php >64bit GNU powered gpg signed mail preferred >Help keep free software "libre": http://www.ffii.de/
Bug#1017631: r-cran-lmertest: autopkgtest regression on i386: times out
Source: r-cran-lmertest
Version: 3.1-3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: timeout
Dear maintainer(s),
I looked at the results of the autopkgtest of your package because it
was showing up on our page for long running tests on i386. I noticed
that your package regressed on i386 around Mid July 2022, as it started
to time out on the run-unit-test test after 2:47 hours while it passed
in several minutes before.
Don't hesitate to reach out if you need help and some more information
from our infrastructure.
Paul
https://ci.debian.net/packages/r/r-cran-lmertest/testing/i386/
https://ci.debian.net/data/autopkgtest/testing/i386/r/r-cran-lmertest/24674859/log.gz
Backward reduced fixed-effect table:
Degrees of freedom method: Satterthwaite
Eliminated Sum Sq Mean Sq NumDF DenDF F valuePr(>F)
sens2 0 58.685 58.685 1 102.02 54.8236 3.888e-11 ***
Homesize 0 5.979 5.979 1 100.95 5.5852 0.02003 *
---
Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
Model found:
Preference ~ sens2 + Homesize + (sens2 | Consumer)
> stopifnot(
+ nrow(ranova(model)) == 3L,
+ nrow(ranova(model, reduce.terms = FALSE)) == 2L
+ )
boundary (singular) fit: see help('isSingular')
>
> # Model of the form (f1 + f2 | gr):
> model <- lmer(Preference ~ sens2 + Homesize + Gender +
+ (Gender+Homesize|Consumer), data=carrots)
autopkgtest [08:57:51]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true; . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.4ujypq2i/downtmp/build.Ikx/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.4ujypq2i/downtmp/run-unit-test-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.4ujypq2i/downtmp/run-unit-test-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.4ujypq2i/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.4ujypq2i/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.4ujypq2i/downtmp/build.Ikx/src/debian/tests/run-unit-test;
touch /tmp/autopkgtest-lxc.4ujypq2i/downtmp/run-unit-test-stdout
/tmp/autopkgtest-lxc.4ujypq2i/downtmp/run-unit-test-stderr;
/tmp/autopkgtest-lxc.4ujypq2i/downtmp/build.Ikx/src/debian/tests/run-unit-test
2> >(tee -a /tmp/autopkgtest-lxc.4ujypq2i/downtmp/run-unit-test-stderr
>&2) > >(tee -a
/tmp/autopkgtest-lxc.4ujypq2i/downtmp/run-unit-test-stdout);" (kind: test)
autopkgtest [08:57:51]: test run-unit-test: ---]
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1017630: r-cran-insight: autopkgtest regression on i386: times out
Source: r-cran-insight
Version: 0.18.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: timeout
Dear maintainer(s),
I looked at the results of the autopkgtest of your package because it
was showing up on our page for long running tests on i386. I noticed
that your package regressed on i386 around Mid July 2022, as it started
to time out on the run-unit-test test after 2:47 hours while it passed
in several minutes before.
Don't hesitate to reach out if you need help and some more information
from our infrastructure.
Paul
https://ci.debian.net/packages/r/r-cran-insight/testing/i386/
https://ci.debian.net/data/autopkgtest/testing/i386/r/r-cran-insight/24933022/log.gz
autopkgtest [20:20:34]: test run-unit-test: [---
BEGIN TEST testthat.R
R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
Copyright (C) 2022 The R Foundation for Statistical Computing
Platform: i686-pc-linux-gnu (32-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> if (require("testthat")) {
+ library(insight)
+
+ is_dev_version <-
length(strsplit(packageDescription("insight")$Version, "\\.")[[1]]) > 3
+
+ if (is_dev_version) {
+ Sys.setenv("RunAllinsightTests" = "yes")
+ } else {
+ Sys.setenv("RunAllinsightTests" = "no")
+ }
+ si <- Sys.info()
+
+ osx <- tryCatch(
+ {
+ if (!is.null(si["sysname"])) {
+ si["sysname"] == "Darwin" || grepl("^darwin", R.version$os)
+ } else {
+ FALSE
+ }
+ },
+ error = function(e) {
+ FALSE
+ }
+ )
+
+ solaris <- tryCatch(
+ {
+ if (!is.null(si["sysname"])) {
+ grepl("SunOS", si["sysname"], ignore.case = TRUE)
+ } else {
+ FALSE
+ }
+ },
+ error = function(e) {
+ FALSE
+ }
+ )
+
+ # disable / enable if needed
+ if (.Platform$OS.type == "unix" && is_dev_version) {
+ Sys.setenv("RunAllinsightStanTests" = "yes")
+ } else {
+ Sys.setenv("RunAllinsightStanTests" = "no")
+ }
+
+ # if (!osx && !solaris) {
+ # test_check("insight")
+ # }
+
+ test_check("insight")
+ }
Loading required package: testthat
autopkgtest [23:07:14]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true; . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.25vi6u5m/downtmp/build.lM8/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.25vi6u5m/downtmp/run-unit-test-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.25vi6u5m/downtmp/run-unit-test-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.25vi6u5m/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.25vi6u5m/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.25vi6u5m/downtmp/build.lM8/src/debian/tests/run-unit-test;
touch /tmp/autopkgtest-lxc.25vi6u5m/downtmp/run-unit-test-stdout
/tmp/autopkgtest-lxc.25vi6u5m/downtmp/run-unit-test-stderr;
/tmp/autopkgtest-lxc.25vi6u5m/downtmp/build.lM8/src/debian/tests/run-unit-test
2> >(tee -a /tmp/autopkgtest-lxc.25vi6u5m/downtmp/run-unit-test-stderr
>&2) > >(tee -a
/tmp/autopkgtest-lxc.25vi6u5m/downtmp/run-unit-test-stdout);" (kind: test)
autopkgtest [23:07:14]: test run-unit-test: ---]
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1017093: nautilus-extension-gnome-console: Gets removed when upgrading gnome-console to 43~beta-1
Thanks for the response, Jeremy. I was not aware that this feature is built into Nautilus 43. I'll wait for it to become available in sid. -- Chandra Sekar On Thu, 18 Aug, 2022, 22:40 Jeremy Bicha, wrote: > On Sat, Aug 13, 2022 at 10:12 AM Chandra Sekar > wrote: > > apt attempts to remove nautilus-extension-gnome-console when > > upgrading gnome-console pakcage to 43~beta-1. Please update this > > package's dependency on gnome-console. > > The open in Console feature is now provided directly by Nautilus 43 > which is currently in Experimental. If that feature is important to > you, you can either use gnome-console 42 from Debian Testing or you > could try Nautilus 43 from Experimental. If you use other Nautilus > extensions, they probably won't work with Nautilus 43. > > Nautilus 43 will be uploaded to Debian Unstable in approximately a few > weeks. > > Thank you, > Jeremy Bicha >
