Bug#1099778: ITP: golang-github-gosimple-unidecode -- Unicode transliterator in Golang - Replaces non-ASCII characters with their ASCII approximations.
> (I took the liberty to clear-text reply to your e-mail, I assume you > want this to be public...) Exactly, as this is the first time I use the BTS system, I put the BTS in Cc. Was that the correct way to proceed? > Some nits: > > 1) Looks like you are using a old dh-make-golang, you would want > Build-Depends: dh-golang-sequence and not dh-golang. > > 2) Bump Standards-Version. That should be ok now. > 3) You have TODO's remaining in debian/copyright. > > 4) LICENSE file contains another copyright notice you want to look into. I updated debian/copyright for both packages. Can you tell me if that's ok now? > 5) You should fix lintian complaints, e.g., the Description: section in > debian/control is too long. > > Look at the 'lintian' (and other jobs) output in the pipeline: Ok, I just let warnings related to non-maintainer upload in d/changelog. > After you've fixed everything and it looks good, if you are a DD you > upload it to NEW or go find some DD to do sponsor the upload. As I'm not a DD can you sponsor me for this upload? Otherwise lola...@debian.org will probably take a look. Thank you very much for your review. It's really appreciated! -- Luca publickey - luca.soler@proton.me - 0xCFA702A4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Bug#1099217: bash: FTBFS: /usr/bin/ld: [...] multiple definition of `getenv'
control: reassign -1 src:glibc/2.41-1 control: affects -1 bash Hi, On 2025-03-01 21:00, Santiago Vila wrote: > Package: src:bash > Version: 5.2.37-1.1 > Severity: serious > Tags: ftbfs trixie sid > > Dear maintainer: > > During a rebuild of all packages in unstable, your package failed to build: > > [...] > gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde > -L./lib/sh -Wl,-z,relro -Wl,-z,now -rdynamic -g -O2 > -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. > -fstack-protector-strong -fstack-clash-protection -Wformat > -Werror=format-security -fcf-protection -Wall -static -o bash shell.o eval.o > y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o > variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o > hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o > version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o bashhist.o > bashline.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o > pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh -lreadline -lhistory > -ltinfo -ltilde > /usr/bin/ld: ./lib/sh/libsh.a(tmpfile.o): in function `sh_mktmpname': > ./build-static/lib/sh/../../.././lib/sh/tmpfile.c:160:(.text+0x172): warning: > the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp' > /usr/bin/ld: bashline.o: in function `bash_groupname_completion_function': > ./build-static/.././bashline.c:2665:(.text+0x8081): warning: Using 'getgrent' > in statically linked applications requires at runtime the shared libraries > from the glibc version used for linking > /usr/bin/ld: ./build-static/.././bashline.c:2662:(.text+0x806f): warning: > Using 'setgrent' in statically linked applications requires at runtime the > shared libraries from the glibc version used for linking > /usr/bin/ld: ./build-static/.././bashline.c:2673:(.text+0x80d9): warning: > Using 'endgrent' in statically linked applications requires at runtime the > shared libraries from the glibc version used for linking > /usr/bin/ld: ./lib/sh/libsh.a(netopen.o): in function `_netopen6': > ./build-static/lib/sh/../../.././lib/sh/netopen.c:229:(.text+0x93): warning: > Using 'getaddrinfo' in statically linked applications requires at runtime the > shared libraries from the glibc version used for linking > /usr/bin/ld: ./lib/readline/libreadline.a(complete.o): in function > `rl_username_completion_function': > ./build-static/lib/readline/../../.././lib/readline/complete.c:2307:(.text+0x48e1): > warning: Using 'getpwent' in statically linked applications requires at > runtime the shared libraries from the glibc version used for linking > /usr/bin/ld: > ./build-static/lib/readline/../../.././lib/readline/complete.c:2302:(.text+0x48d6): > warning: Using 'setpwent' in statically linked applications requires at > runtime the shared libraries from the glibc version used for linking > /usr/bin/ld: shell.o: in function `get_current_user_info': > ./build-static/.././shell.c:1920:(.text+0x642): warning: Using 'endpwent' in > statically linked applications requires at runtime the shared libraries from > the glibc version used for linking > /usr/bin/ld: ./lib/readline/libreadline.a(tilde.o): in function > `tilde_expand_word': > ./build-static/lib/readline/../../.././lib/readline/tilde.c:386:(.text+0x144): > warning: Using 'getpwnam' in statically linked applications requires at > runtime the shared libraries from the glibc version used for linking > /usr/bin/ld: shell.o: in function `get_current_user_info': > ./build-static/.././shell.c:1902:(.text+0x5ad): warning: Using 'getpwuid' in > statically linked applications requires at runtime the shared libraries from > the glibc version used for linking > /usr/bin/ld: bashline.o: in function `bash_servicename_completion_function': > ./build-static/.././bashline.c:2609:(.text+0x7f21): warning: Using > 'getservent' in statically linked applications requires at runtime the shared > libraries from the glibc version used for linking > /usr/bin/ld: ./build-static/.././bashline.c:2606:(.text+0x7f18): warning: > Using 'setservent' in statically linked applications requires at runtime the > shared libraries from the glibc version used for linking > /usr/bin/ld: ./build-static/.././bashline.c:2631:(.text+0x800b): warning: > Using 'endservent' in statically linked applications requires at runtime the > shared libraries from the glibc version used for linking > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libc.a(getenv.o): > in function `getenv': > (.text+0x0): multiple definition of `getenv'; > ./lib/sh/libsh.a(getenv.o):./build-static/lib/sh/../../.././lib/sh/getenv.c:52: > first defined here > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile:595: bash] Error 1 > make[2]: Leaving directory '/<>/build-static' > make[1]: ***
Bug#1099853: broot: fish completion doesn't work - zsh file shipped by mistake?
Awesome, thanks for the very quick response! On Sat, Mar 8, 2025, at 22:09, NoisyCoil wrote: > Control: tags -1 incoming > > On 08/03/25 21:19, Vincent van Leeuwen wrote: >> Examining the file it seems to be zsh syntax, not fish syntax. I can't find >> the file in the upstream git repo, so maybe something shipped by this >> package got switched around by mistake? > > Yep, after a recent change I switched the fish and zsh file paths by > mistake, so zsh gets the fish completions and vice-versa. Fix incoming. > > Thanks for reporting!
Bug#1099847: unblock: erlang/1:27.2.4+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: erl...@packages.debian.org Control: affects -1 + src:erlang Hi release team! I'd like to ask you to unblock the erlang package, which is stuck in unstable because of an autopkgtest failure for rebar3/3.19.0-1 (see [1] for detail). The problem is that rebar3/3.23.0-3 should migrate to testing simultaneously with erlang, it has this test fixed, but britney for some reason does not take into account this migration of rebar3. unblock erlang/1:25.2.3+dfsg-1 [1] https://ci.debian.net/packages/r/rebar3/testing/ppc64el/58520400/ Cheers! -- Sergei Golovan
Bug#1099855: RFS: xdg-desktop-portal-hyprland/1.3.8-3 [ITA] -- XDG Desktop Portal backend for Hyprland
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "xdg-desktop-portal-hyprland": * Package name : xdg-desktop-portal-hyprland Version : 1.3.8-3 Upstream contact : https://github.com/hyprwm/xdg-desktop-portal-hyprland/issues/new * URL : https://github.com/hyprwm/xdg-desktop-portal-hyprland * License : BSD-3-Clause, MIT, HPND-sell-variant * Vcs : https://salsa.debian.org/debian/xdg-desktop-portal-hyprland Section : x11 The source builds the following binary packages: xdg-desktop-portal-hyprland - XDG Desktop Portal backend for Hyprland To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xdg-desktop-portal-hyprland/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/x/xdg-desktop-portal-hyprland/xdg-desktop-portal-hyprland_1.3.8-3.dsc Changes since the last upload: xdg-desktop-portal-hyprland (1.3.8-3) unstable; urgency=medium . * New maintainer (Closes: #1093708) As the package is already in the debian namespace, I would kindly ask you to review my MR[1]. Following changes have been made: - - updated maintainer & changelog - - updated d/copyright - - updated standard version to 4.7.2 - - added recommends to d/control - - added upstream/metadata - - added salsa ci config Regards, Carl Keinath [1] https://salsa.debian.org/debian/xdg-desktop-portal-hyprland/-/merge_requests/2
Bug#1099743: Wayland shell stops repainting the screen until monitor layout (or input devices?) change
On Fri, 07 Mar 2025 at 13:00:07 +0100, Nicolas Dandrimont wrote: > Since [48~rc], I've had a baffling issue where the screen would stop > repainting, > until I unplug *or* replug my dock (which reconnects an external monitor, > keyboard and mouse). I'm assuming what puts gnome-shell back on track is the > change to the monitor layout, but I haven't really isolated the behavior yet On Sat, 08 Mar 2025 at 12:56:06 -0800, Josh Triplett wrote: > I don't know if this helps to debug it, but every time it freezes and I > close and reopen the lid to un-freeze it, I see this in the log: > > Mar 08 12:49:59 o gnome-shell[1126]: Cursor update failed: Timer disarmed > > If I close and reopen the lid when it *isn't* frozen, that message > doesn't appear. I have a similar issue intermittently, possibly correlated with I/O load (or maybe not, it's hard to tell), which can be worked around by switching to another virtual console, and back to the one I was previously on (in my case this is Ctrl+Alt+F6 Ctrl+Alt+F2). This might be https://gitlab.gnome.org/GNOME/mutter/-/issues/3955 upstream, for which there is a merge request proposed at https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4321 (or it might be something different). smcv
Bug#1073842: calypso: please patch-out usage of python3-lockfile
Control: tags -1 - patch On Sun, Nov 24, 2024 at 11:39:41PM +, Andrew Bower wrote: Control: tags -1 patch Withdrawing my patch that was an attempt to be helpful but would reduce functionality. It doesn't seem as if anyone cares and I couldn't work out if the bug that it blocked still had the same perceived importance.
Bug#1099753: gnome-photos: unmaintained upstream; upstream repository is archived and read-only
On Sat, 08 Mar 2025 at 14:27:24 -0500, Jeremy Bícha wrote: > On Fri, Mar 7, 2025 at 11:33 AM Simon McVittie wrote: > > On Fri, 07 Mar 2025 at 11:09:30 -0500, Jeremy Bícha wrote: > > > Currently, 'gnome' Depends on gnome-photos and > > > cinnamon-desktop-environment Recommends it. > > > > If we know that gnome-photos is going to be removed from forky, then I > > think the gnome and cinnamon-desktop-environment metapackages should > > probably be updated before trixie to stop including gnome-photos in new > > installations (it could be a Suggests, or it could be removed completely). > > Actually, > gnome has Depends: shotwell | gnome-photos (>= 3.36) > cinnamon-desktop-environment has Depends: shotwell | gnome-photos > > Do you think it's fine to leave it like that for trixie? I think that should be OK (apt and therefore tasksel will prefer to install shotwell if I understand correctly). I thought for a moment that the alternative might be there because something about shotwell is non-portable, but it seems shotwell is available on all release architectures anyway. It might be more predictable if we drop the alternative, though. smcv
Bug#1099801: libkmod2: missing dependencies on compression libraries
On Mar 08, Sven Joachim wrote: > After the switch to dlopen() the lzma and zstd compression libraries, > libkmod2 does no longer depend on the liblzma5 and libzstd1 packages. > This is bad because kmod is not going to be automatically rebuilt should > one of these libraries change SONAME. Policy §8.6 recommends to I think that this would be a very rare event, hence it could be easily handled manually. Do you believe that there are any other reasons to declare such dependencies? -- ciao, Marco signature.asc Description: PGP signature
Bug#1099670: rust-rebuildctl: git repository does not work (?)
Package: src:rust-rebuildctl Version: 0.22.1-1 Dear maintainer: The following command does not work: $ debcheckout rust-rebuildctl declared git repository at https://salsa.debian.org/rust-team/debcargo-conf.git [src/rebuildctl] git clone https://salsa.debian.org/rust-team/debcargo-conf.git [src/rebuildctl] rust-rebuildctl ... Cloning into 'rust-rebuildctl'... fatal: unable to access 'https://salsa.debian.org/rust-team/debcargo-conf.git [src/rebuildctl]/': URL rejected: Malformed input to a URL function checkout failed (the command above returned a non-zero exit code) Looks like the Vcs-Git control field is not using a correct syntax. Thanks.
Bug#1099853: broot: fish completion doesn't work - zsh file shipped by mistake?
Package: broot Version: 1.44.7-2 Severity: normal Dear Maintainer, The broot package gives an error if you're trying to use it from the fish shell. As soon as you type 'broot ' in the shell you get the following error: /usr/share/fish/vendor_completions.d/broot.fish (line 91): Missing end to balance this if statement if [ "$funcstack[1]" = "_broot" ]; then ^^ from sourcing file /usr/share/fish/vendor_completions.d/broot.fish source: Error while reading file '/usr/share/fish/vendor_completions.d/broot.fish' Examining the file it seems to be zsh syntax, not fish syntax. I can't find the file in the upstream git repo, so maybe something shipped by this package got switched around by mistake? I'm having some trouble reliably reproducing it, seems like completions are cached or something. On the second try I needed to type something like 'broot -s ' to get the same error. If you ignore the error broot mostly works fine after that, except that you can't install the 'br' shell integration without getting the same error. Kind regards, Vincent van Leeuwen -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing'), (400, 'unstable'), (400, 'stable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.12.12-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER 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 broot depends on: ii libc62.40-7 ii libgcc-s114.2.0-17 ii libgit2-1.8 1.8.4+ds-3 broot recommends no packages. broot suggests no packages. -- no debconf information
Bug#1099753: gnome-photos: unmaintained upstream; upstream repository is archived and read-only
On Sat, Mar 8, 2025 at 4:12 PM Simon McVittie wrote: > I think that should be OK (apt and therefore tasksel will prefer to > install shotwell if I understand correctly). I thought for a moment > that the alternative might be there because something about shotwell > is non-portable, but it seems shotwell is available on all release > architectures anyway. > > It might be more predictable if we drop the alternative, though. gnome-photos was in GNOME Core previously but it was one of the early GNOME 3 apps dependent on tracker instead of an open dialog, etc., and it wasn't universally liked. So we used an alternative dependency. I guess we might drop Shotwell from 'gnome' for Forky as Loupe gains more features. Loupe doesn't do all of what Shotwell does but it may do enough for casual use. For 'gnome' now, let's demote shotwell to Recommends and remove the alternate dependency gnome-photos. Thank you, Jeremy Bícha
Bug#1099836: gnome-shell should recommend rtkit since it uses org.freedesktop.RealtimeKit1
Package: gnome-shell Version: 48~rc-2 Severity: normal X-Debbugs-Cc: j...@joshtriplett.org Mar 08 09:56:19 o gnome-shell[1126]: Failed to make thread 'KMS thread' high priority scheduled: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.RealtimeKit1" does not exist Since gnome-shell wants to use rtkit, it should recommend the rtkit package. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 6.12.17-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-5 ii gir1.2-accountsservice-1.0 23.13.9-7 ii gir1.2-adw-1 1.7~beta-2 ii gir1.2-atk-1.0 2.55.2-1 ii gir1.2-atspi-2.0 2.55.2-1 ii gir1.2-freedesktop 1.83.2-2 ii gir1.2-gcr-4 4.3.91-1 ii gir1.2-gdesktopenums-3.0 48~beta-1 ii gir1.2-gdkpixbuf-2.0 2.42.12+dfsg-2 ii gir1.2-gdm-1.0 48~beta-1 ii gir1.2-geoclue-2.0 2.7.2-2 ii gir1.2-glib-2.0 2.83.5-1 ii gir1.2-gnomebg-4.0 44.1-2 ii gir1.2-gnomebluetooth-3.047.1-1 ii gir1.2-gnomedesktop-4.0 44.1-2 ii gir1.2-graphene-1.0 1.10.8-5 ii gir1.2-gstreamer-1.0 1.24.12-1 ii gir1.2-gtk-4.0 4.17.5+ds-3 ii gir1.2-gweather-4.0 4.4.4-1 ii gir1.2-ibus-1.0 1.5.32~rc1-1 ii gir1.2-mutter-16 48~rc-2 ii gir1.2-nm-1.01.52.0-2 ii gir1.2-nma4-1.0 1.10.6-5 ii gir1.2-pango-1.0 1.56.1-1 ii gir1.2-polkit-1.0126-2 ii gir1.2-rsvg-2.0 2.59.90+dfsg-2 ii gir1.2-soup-3.0 3.6.4-2 ii gir1.2-upowerglib-1.01.90.7-1 ii gjs 1.82.1-1 ii gnome-control-center 1:48~beta-2 ii gnome-settings-daemon48~rc-1 ii gnome-shell-common 48~rc-2 ii gsettings-desktop-schemas48~beta-1 ii gstreamer1.0-pipewire1.4.0-1 ii libatk-bridge2.0-0t642.55.2-1 ii libatk1.0-0t64 2.55.2-1 ii libc62.41-3 ii libcairo21.18.2-2 ii libecal-2.0-33.55.3-1 ii libedataserver-1.2-27t64 3.55.3-1 ii libgcr-4-4 4.3.91-1 ii libgdk-pixbuf-2.0-0 2.42.12+dfsg-2 ii libgirepository-1.0-11.83.2-2 ii libgjs0g 1.82.1-1 ii libgles2 1.7.0-1+b2 ii libglib2.0-0t64 2.83.5-1 ii libglib2.0-bin 2.83.5-1 ii libgnome-autoar-0-0 0.4.5-2 ii libgnome-desktop-4-2t64 44.1-2 ii libgraphene-1.0-01.10.8-5 ii libgtk-4-1 4.17.5+ds-3 ii libical3t64 3.0.19-4 ii libjson-glib-1.0-0 1.10.6+ds-1 ii libmutter-16-0 48~rc-2 ii libnm0 1.52.0-2 ii libpango-1.0-0 1.56.1-1 ii libpipewire-0.3-0t64 1.4.0-1 ii libpolkit-agent-1-0 126-2 ii libpolkit-gobject-1-0126-2 ii libpulse-mainloop-glib0 17.0+dfsg1-2 ii libpulse017.0+dfsg1-2 ii libsecret-1-00.21.6-3 ii libsystemd0 257.4-1 ii libx11-6 2:1.8.10-2 ii libxext6 2:1.3.4-1+b3 ii libxfixes3 1:6.0.0-2+b4 ii python3 3.13.2-2 ii tecla48~rc-1 Versions of packages gnome-shell recommends: ii bolt 0.9.8-1 ii evolution-data-server 3.55.3-1 ii gdm3 48~beta-1 pn gn
Bug#1099854: amberol: Should not set inode/directory mimetype
Package: amberol Severity: wishlist Tags: upstream X-Debbugs-Cc: werdah...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, amberol sets the inode/directory file in its desktop file. This is wrong as it causes amberol to handle as app for opening files. Should probably fixed / discussed upstream. best, werdahias - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.12.17-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: OpenRC (via /run/openrc), PID 1: init LSM: AppArmor: enabled Versions of packages amberol depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-5 ii gstreamer1.0-plugins-good1.25.90-2 ii libadwaita-1-0 1.7~rc-1 ii libc62.41-3 ii libcairo21.18.2-2 ii libgcc-s114.2.0-17 ii libgdk-pixbuf-2.0-0 2.42.12+dfsg-2 ii libglib2.0-0t64 2.83.5-1 ii libgraphene-1.0-01.10.8-5 ii libgstreamer-plugins-bad1.0-01.24.12-3+b1 ii libgstreamer-plugins-base1.0-0 1.25.90-2 ii libgstreamer1.0-01.25.90-2 ii libgtk-4-1 4.17.5+ds-3 ii libpango-1.0-0 1.56.1-1 amberol recommends no packages. amberol suggests no packages. -BEGIN PGP SIGNATURE- iIsEARYIADMWIQQUWTv/Sl6/b+DpcW7svtu2B7myvgUCZ8y53BUcd2VyZGFoaWFz QGRlYmlhbi5vcmcACgkQ7L7btge5sr5IQgD/c8c4Ev2FClVOq8Bbc034xmWxRiUD hZDK88lLQSZJzy8BAKE+qGNzM3VnjQQxYNkDpJZH2I/z6sHc7LTrlpIdEZgH =IQMW -END PGP SIGNATURE-
Bug#1099533: nmu: rust-mimalloc_0.1.29-1
On 2025-03-08 22:57:04 +0100, Paul Gevers wrote: > Hi Jochen, > > On 04-03-2025 16:32, Jochen Sprickerhof wrote: > > This is on an Intel Xeon X5690 without AVX. Rebuilding against the > > current unstable toolchain fixes the build so I assume it is some build > > dependency that was fixed in the meantime. > > How have you tested this, I guess building (not rebuilding) on the same > hardware? > > I'm wondering, would it be worth while to try and find out which build > dependency this is? Maybe it's not fixed, but just depending on which buildd > it gets build to exhibit the issue? I guess that was #1094881 and #1094269 which was fixed in mimalloc 3.0.1+ds-2.1. Cheers -- Sebastian Ramacher
Bug#1099834: tech-ctte: Call for votes on TC membership of Paul Tagliamonte
* Matthew Vernon [2025-03-08 17:48]: ===BEGIN The Technical Committee recommends that Paul Tagliamonte (paultag) be appointed by the Debian Project Leader to the Technical Committee. H: Recommend to Appoint Paul Tagliamonte (paultag) F: Further Discussion ===END I vote H > F Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1098397: bookworm-pu: package curl/7.88.1-10+deb12u10
On Wed, 2025-02-19 at 21:57 -0300, Matheus Polkorny wrote: > The reason is to fix CVE-2024-11053 [1], when both a `.netrc` file > for credentials and HTTP redirects are used, curl could leak the > password from the first host to the redirect target in certain cases. I'm not sure if either of the sets of changes for these bugs caused the issue, but the new curl upload FTBFS for both the arch:all and amd64 builds, with test failures: TESTFAIL: These test cases failed: 320 324 This is quite reproducible - so far 3 times on "all" and 2 on amd64. Regards, Adam
Bug#1099857: ITP: qtpyvcp -- Framework for LinuxCNC virtual control panels
Package: wnpp Severity: wishlist Owner: Steffen Moeller X-Debbugs-Cc: debian-de...@lists.debian.org, moel...@debian.org * Package name: qtpyvcp Version : 5.0.2 * URL : https://www.qtpyvcp.com/ * License : GPL-2 Programming Lang: Python Description : Framework for LinuxCNC virtual control panels QtPyVCP is a Qt and Python based framework for building virtual control panels (VCPs) for the LinuxCNC machine controller. A set of readily usable VCPs for lathes and mills up to 5 axes are available and in routine use through the globe. . The QtPyVCP projects strives towards a no-code, drag-and-drop system for making simple VCPs, as well as a straightforward, flexible and extensible framework to aid in building complex VCPs. QtPyVCP provides graphical infrastructures for lathes and mills. It is optically very appealing. The package LinuxCNC, which is used underneath, is already shipping with Debian and would miss out without this addition. The package will be uploaded to the electronics-team. Had though about the science-team, but the direct contact for QtPyVCP is the electronics which drives and controls the motors, so it seems like the better fit. No sponsoring required.
Bug#1099325: Emacs 30.1 byte-compilation failures
Hello, On Sat 08 Mar 2025 at 08:20pm +01, Micha Lenk wrote: > Both tiny changes target a situation that in practice[1] would not surface > without using bookworm-backports. Hence I'd consider both changes even > acceptable if uploaded to bookworm-backports directly (e.g. as a ~bpo12+2 > upload to urgently fix something). Obviously, fixing such issues via unstable > is always the preferred and more sustainable method of fixing a backport. > [...] > As the only diff of your uploads are meant to have an effect in > bookworm-backports, Actually, the changes are primarily targeted at fixing bookworm->trixie partial upgrades. But they also fix the bookworm-backports situation. > feel free to immediately upload emacs and dh-elpa as suggested. Thanks for reviewing! Done, with dh-elpa now in backports-NEW. -- Sean Whitton signature.asc Description: PGP signature
Bug#1099859: ITP: python-local-agent-rs -- Proton VPN local agent for managing connections
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-local-agent-rs Version : 1.4.3 Upstream Contact: Proton Technologies * URL : https://github.com/ProtonVPN/local-agent-rs * License : GPL-3+ Programming Lang: Python and Rust Description : Proton VPN local agent for managing connections Local-agent-rs is a ProtonVPN project that provides a Rust library for communicating with ProtonVPN's LocalAgent. Its purpose is to promote efficiency and security in the integration of ProtonVPN features across different clients. . It is responsible for: - Communication with ProtonVPN: - Manages the connection between the ProtonVPN client and ProtonVPN servers. - Handles authentication, key and certificate exchange, and other operations required to establish a secure connection. - Python Bindings: - Includes Python bindings for the Rust library, allowing Rust code to be used in Python applications. - Integrate LocalAgent functionality into ProtonVPN clients written in Python.
Bug#1099666: Upstream bug report
upstream bug report: https://github.com/zmanda/amanda/issues/275
Bug#1099858: im-config: Fctix5 environment variable is not set correctly in KDE Plasma 6 Wayland
Package: im-config Version: 0.57-2 Severity: normal X-Debbugs-Cc: noga...@gmail.com Dear Maintainer, In the KDE Plasma 6 desktop environment on Wayland, the following message appears when using fcitx5 for the input method front end. > Detect GTK_IM_MODULE and QT_IM_MODULE being set and Wayland Input method > frontend is working. It is recommended to unset GTK_IM_MODULE and > QT_IM_MODULE and use Wayland input method frontend instead. For more details > see https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland#KDE_Plasma > GTK_IM_MODULE と QT_IM_MODULE が設定され、Wayland > 入力メソッドフロントエンドが動作していることを検出しました。GTK_IM_MODULE と QT_IM_MODULE の設定を解除し、代わりに > Wayland 入力メソッドフロントエンドを使用することをお勧めします。詳しくは > https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland#KDE_Plasma をご覧ください。 According to the settings on the Fcitx5 Wiki, it appears that the GTK_IM_MODULE, QT_IM_MODULE and SDL_IM_MODULE settings need to be removed. https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland#KDE_Plasma -- KDE Plasma 6 Desktop info: Operating System: Debian GNU/Linux 12 KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.12.15-amd64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics Memory: 30.7 GiB of RAM Graphics Processor: AMD Radeon Graphics Product Name: B550 Phantom Gaming 4 オペレーティングシステム: Debian GNU/Linux 12 KDE Plasma バージョン: 6.3.2 KDE Frameworks バージョン: 6.11.0 Qt バージョン: 6.8.2 カーネルバージョン: 6.12.15-amd64 (64 ビット) グラフィックプラットフォーム: Wayland プロセッサ: 12 × AMD Ryzen 5 5600G with Radeon Graphics メモリ: 30.7 GiB の RAM グラフィックプロセッサ: AMD Radeon Graphics 製品名: B550 Phantom Gaming 4 -- Package-specific info: === command path == im-config is /usr/bin/im-config === im-config API -l: available IM === im-config -l => fcitx5 xim === im-config API -m: selected IM === im-config -m => 'system' 'user' 'automatic' 'override' 'autobase' 'default' 'missing' 'fcitx5' '' 'fcitx5' === /etc/default/im-config == # Default im-config mode (see im-config(8)) # This im-config helps to start best available input method (IM) # Always start highest priority IM IM_CONFIG_DEFAULT_MODE=auto # Start or not to start IM dynamically under CJKV/desktop environment #IM_CONFIG_DEFAULT_MODE=cjkv # Never start IM by im-config (Leave it to desktop system) #IM_CONFIG_DEFAULT_MODE=none # cjkv mode behavior: # case 1: #* desktop is listed in CJKV_DEFAULT_DESKTOP #* locale is under so-called CJKV environments #--> auto mode # case 2: #* desktop is listed in CJKV_DEFAULT_DESKTOP #* locale is *not* under so-called CJKV environments #--> none mode # case 3: #* desktop is *not* listed in CJKV_DEFAULT_DESKTOP #* locale is under any environments #--> auto mode # CJKV_DEFAULT_DESKTOP="*" #CJKV_DEFAULT_DESKTOP="KDE:LXQt:XFCE" # List of locales for so-called CJKV environments CJKV_LOCALES="zh_TW:zh_HK:zh_SG:zh_CN:ja_JP:ko_KR:vi_VN" # Set locale dependent preferred IM over standard auto mode if not GNOME IM_CONFIG_PREFERRED_RULE="zh_CN,fcitx5:zh_TW,fcitx5:zh_HK,fcitx5:zh_SG,fcitx5" # User and system wide configuration is normally done via im-config program. # The above IM_CONFIG_PREFERRED_RULE sets locale dependent preferred IM # override rule. If you wish to use uim over ibus just for ja_JP, # add :ja_JP,uim at the end of the above list. (Marked by "!" in GUI) # List of desktop systems which starts ibus if available # Applicable desktops are excluded for applying IM_CONFIG_PREFERRED_RULE DESKTOP_SETUP_IBUS="GNOME" # Trace commands for debug # (This may cause problem configuration file generated under console mode) #IM_CONFIG_SETMODE="-x" # Verbose output for debug (uncomment following) #IM_CONFIG_VERBOSE="true" === localectl status === System Locale: LANG=ja_JP.UTF-8 VC Keymap: (unset) X11 Layout: kr X11 Model: pc105 === environment vars == DISPLAY=:1 WAYLAND_DISPLAY=wayland-0 XDG_CONFIG_DIRS=/home/jun/.config/kdedefaults:/etc/xdg:/usr/share/desktop-base/kf5-settings XDG_CURRENT_DESKTOP=KDE XDG_DATA_DIRS=/home/jun/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share XDG_MENU_PREFIX=plasma- XDG_RUNTIME_DIR=/run/user/1000 XDG_SEAT=seat0 XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 XDG_SESSION_CLASS=user XDG_SESSION_DESKTOP=KDE XDG_SESSION_ID=8 XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session3 XDG_SESSION_TYPE=wayland XDG_VTNR=1 CLUTTER_IM_MODULE=xim GTK_IM_MODULE=fcitx QT_IM_MODULE=fcitx SDL_IM_MODULE=fcitx XMODIFIERS=@im=fcitx -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.12.15-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages im-confi
Bug#1099861: gapplication.1: Some remarks and a patch with editorial changes for this man page
Package: libglib2.0-bin
Version: 2.83.4-1
Severity: minor
Tags: patch
* What led up to the situation?
Checking for defects with a new version
test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z < "man
page"
[Use "groff -e ' $' -e '\\~$' " to find obvious trailing spaces.]
["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).
[The fate of "test-nroff" was decided in groff bug #55941.]
* What was the outcome of this action?
Output from "test-groff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z
":
troff::30: warning: start (0) and end (0) index of substring out of range
an.tmac::30: warning: TH: second argument is not a numeric expression:
an.tmac::30: style: .TH missing third argument; consider document
modification date in ISO 8601 format (-MM-DD)
an.tmac::30: style: .TH missing fourth argument; consider
package/project name and version (e.g., "groff 1.23.0")
troff::30: warning: name 'an-extra3' not defined
an.tmac::30: style: .TH missing fifth argument and second argument ''
not a recognized manual section; specify its title
an.tmac::260: style: 1 leading space(s) on input line
an.tmac::261: style: 1 leading space(s) on input line
an.tmac::262: style: 1 leading space(s) on input line
troff::262: warning: trailing space in the line
* What outcome did you expect instead?
No output (no warnings).
-.-
General remarks and further material, if a diff-file exist, are in the
attachments.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libglib2.0-bin depends on:
ii libc62.40-7
ii libelf1t64 0.192-4
ii libglib2.0-0t64 2.83.4-1
ii libglib2.0-data 2.83.4-1
libglib2.0-bin recommends no packages.
libglib2.0-bin suggests no packages.
-- no debconf information
Input file is gapplication.1
Output from "mandoc -T lint gapplication.1": (shortened list)
1 input text line longer than 80 bytes: Desktop Entry Specif...
1 input text line longer than 80 bytes: List the actions dec...
1 input text line longer than 80 bytes: The first parameter ...
1 input text line longer than 80 bytes: activation. This li...
1 input text line longer than 80 bytes: arguments such as \f...
1 input text line longer than 80 bytes: set to \fBtrue\fP in...
1 missing date, using "": TH
3 skipping paragraph macro: sp after SH
3 skipping paragraph macro: sp after SS
1 whitespace at end of input line
Remove trailing space with: sed -e 's/ *$//'
-.-.
Output from "test-nroff -mandoc -t -ww -z gapplication.1": (shortened list)
1 name 'an-extra3' not defined
1 start (0) and end (0) index of substring out of range
1 trailing space in the line
Remove trailing space with: sed -e 's/ *$//'
-.-.
Show if generated from reStructuredText.
Who is actually generating this man page? Debian or upstream?
Is the generating software out of date?
1:.\" Man page generated from reStructuredText.
-.-.
Remove space characters (whitespace) at the end of lines.
Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".
Number of lines affected is
1
-.-.
Remove space in the first column, if not indented.
Use ".in +n" and ".in" to end it; ".nf" and ".fi" to end
it, for an extra indention.
gapplication.1:260: ,
gapplication.1:261: ,
gapplication.1:262:
-.-.
Add a "\&" (or a comma (Oxford comma)) after "e.g." and "i.e.",
or use English words
(man-pages(7)).
Abbreviation points should be marked as such and protected against being
interpreted as an end of sentence, if they are not, and that independent
of the current place on the line.
95:(e.g. \fBorg.gnome.app\fP) without the \fB\&.desktop\fP suffix.
-.-.
Wrong distance (not two spaces) between sentences in the input file.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.
Remember coding: Only one command ("sentence") on each (logical) line.
E-mail: Easier to quote exactly the relevant lines.
Generally: Easier to edit the sentence.
Patches: Less unaffected text.
Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.
The amount of space between sentences in the output can then be
controlled with the ".ss" request.
Mark a final abbreviation point as such by suffixing it with "\&".
Some sentences (etc
Bug#1091995: TC decision on ownership of top-level filesystem aliases - #1091995
Hello, On Thu 06 Mar 2025 at 11:25am +01, Helmut Grohne wrote: > Can you clarify how you understand policy here? > > I read it as systemd is not performing an installation here and > therefore does not violate the present policy. If your reading is > different, we should likely clarify policy on this aspect. I read it that way too. -- Sean Whitton signature.asc Description: PGP signature
Bug#1099627: Bug#1099786: Bug#1099627: RFS: calcurse/4.8.1-1.2 [NMU] [RC] -- text-based calendar and todo manager
My previous copy of this email was truncated due to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057758 This copy removes a bunch of the quoted text to make it go through. ;( On Saturday, March 8, 2025 8:21:32 AM MST Peter B wrote: > I'm not at all sure about this. > It seems to me that the Policy wording is ambiguous, > as I would interpret "copyright information" to imply both the copyright > notice/statement and the license itself. Policy 22.8 is not ambiguous, which is the release that added the option to not include all copyright information in debian/copyright (previously all copyright information was required). When this change was made, they specifically said: “Note that there is no change to the requirement to copy *all licensing information* into / usr/share/doc/PACKAGE/copyright.” I do agree that without this statement in 22.8 it would be ambiguous. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1099829: maildir-utils: 1.12.9 is available upstream
Package: maildir-utils Severity: wishlist Hi, It would be great to have 1.12.9 packaged for trixie. Thanks! - John
Bug#1095470: amd64-microcode: CVE-2024-56161
retitle 1095470 amd64-microcode: CVE-2024-56161 updated AMD-SEV FW needed to pass attestation severity 1095470 important clone 1095470 -1 tag 1095470 + fixed-upstream retitle -1 amd64-microcode: CVE-2024-36347 weak microcode update validation tag -1 = upstream security wontfix severity -1 important thanks Please let me clarify some details. If this is incorrect, please provide pointers to the relevant documentation/artifacts: There is NO *operating-system-loadable* microcode update available from AMD to address the root issue (weak microcode validation) at this time. And public documentation states the root-cause fix must be done through a system firmware (UEFI) update. https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html Maybe this will change, and if it doesn't, maybe lesser mitigations (such as blocking further microcode updates) will become available: I understand running a minimal kernel-monitor secure hypervisor should be able to block the MSR writes that trigger a microcode update, for example. So, AMD-SB-7033 / CVE-2024-36347 is unactionable by package amd64-microcode at this time. I will clone the bug to split the two CVEs into their own bugs, and tag the one for CVE-2024-36347 "wontfix" accordingly. I will also downgrade its severity to "important", since unactionable grave bugs can block actionable fixes from propagating to testing, etc. Should the situation change (hopefully it will), we can revisit this. Now, for CVE-2024-56161, which is the AMD-SEV side of the issue. There is a pending AMD-SEV loadable firmware update from 2025/02/29, and I will package it soon (but I'd rather hear back from AMD about a few details, first). However, I understand from AMD SB-3019 that the SEV firmware update will just ensure that SEV remote attestation can succeed on updated firmware. It is relevant for CVE-2024-56161, yes, but it is NOT FIXING the underlying issue at all. https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html Note that CVE-2024-56161 is mitigated by ensuring no SEV payload attestation can succeed on outdated firmware (and you don't need to do anything for THAT: the SEV payload providers are already on it), and by allowing attestation to succeed on updated firmware. What is missing in Debian is a way for SEV payloads to pass attestation *on systems with updated firmware*, and THAT is what the pending SEV firmware update is about. I changed the bug title accordingly. Since AMD-SEV is *not* officially supported in Debian anyway, I will downgrade the SEV bug to severity to important as well. More information about AMD-SEV: https://www.amd.com/en/developer/sev.html -- Henrique de Moraes Holschuh
Bug#1080311: railway-gtk: should handle timezones in a better way
Control: tags -1 wontfix On Sun, 01 Sep 2024 22:51:30 + Martin wrote: Package: railway-gtk Version: 2.4.0-4 Dear maintainer, if users system has a different timezone then the train operator (common use case when planning a trip in a different country), it's not obvious, which time is used where. E.g. if users system runs in UTC, searching for a connection in Germany (CEST/UTC+2 atm.) at 16 hrs, this is interpreted as 16:00 UTC and it shows a train at 18:00 CEST. This is technically correct, but confusing. Web sites of train operators interprete search time always as local time of the train, no matter which is the time zone of the users system, which is better UX IMHO. Alternatively, times zones could be displayed with the times, but that would clutter the UI. Not so nice on mobile phone. The obvious workaround would be to run railway-gtk with the desired timezone, but it looks like railway-gtk ignores the TZ variable! Cheers Hi Martin, after reaching out to upstream they stated that tracking timezones is not planned nor being worked on as the providers like DB do not support this and timezones in general are hard to keep track of wrt departure/arrival times. The times displayed in railway-gtk are always the "local" operator times, i.e. CET for DB, oebb, etc. best, werdahias
Bug#1099828: diamond-aligner :FTBFS:build failed ( error: ‘memcpy’ was not declared in this scope)
Hello Gui-Yue, On Sat, 2025-03-08 at 23:54 +0800, Yue Gui wrote: > Dear diamond-aligner maintainer, > The package diamond-aligner build failed on riscv64.The crucial buildd log > below: > ``` > /build/reproducible-path/diamond-aligner-2.1.11/src/search/finger_print.h: In > constructor ‘Byte_finger_print_48::Byte_finger_print_48(const Letter*)’: > /build/reproducible-path/diamond-aligner-2.1.11/src/search/finger_print.h:138:17: > error: ‘memcpy’ was not declared in this scope > 138 | memcpy(r, q - 16, 48); > | ^~ > /build/reproducible-path/diamond-aligner-2.1.11/src/search/finger_print.h:26:1: > note: ‘memcpy’ is defined in header ‘’; this is probably fixable by > adding ‘#include ’ > 25 | #include "basic/value.h" > +++ |+#include > 26 | > At global scope: > cc1plus: note: unrecognized command-line option ‘-Wno-unknown-warning-option’ > may have been intended to silence earlier diagnostics > make[3]: *** [CMakeFiles/arch_generic.dir/build.make:96: > CMakeFiles/arch_generic.dir/src/search/stage1_2.cpp.o] Error 1 > make[3]: *** Waiting for unfinished jobs > In file included from /usr/include/c++/14/list:62, > from > /build/reproducible-path/diamond-aligner-2.1.11/src/dp/swipe/swipe_wrapper.cpp:22: > In function ‘typename __gnu_cxx::__enable_if::__value, > void>::__type std::__fill_a1(_ForwardIterator, _ForwardIterator, const _Tp&) > [with _ForwardIterator = int*; _Tp = int]’, > inlined from ‘void std::__fill_a(_FIte, _FIte, const _Tp&) [with _FIte = > int*; _Tp = int]’ at /usr/include/c++/14/bits/stl_algobase.h:998:21, > inlined from ‘void std::fill(_ForwardIterator, _ForwardIterator, const > _Tp&) [with _ForwardIterator = int*; _Tp = int]’ at > /usr/include/c++/14/bits/stl_algobase.h:1029:20, > inlined from ‘DP::Swipe::ARCH_GENERIC::Matrix::Matrix(int, int) [with > Sv = int]’ at > /build/reproducible-path/diamond-aligner-2.1.11/src/dp/swipe/full_matrix.h:66:12: > /usr/include/c++/14/bits/stl_algobase.h:952:18: warning: ‘void* > __builtin_memset(void*, int, long unsigned int)’ specified bound > 18446744073709551612 exceeds maximum object size 9223372036854775807 > [-Wstringop-overflow=] > 952 | *__first = __tmp; > | ~^~~ > At global scope: > cc1plus: note: unrecognized command-line option ‘-Wno-unknown-warning-option’ > may have been intended to silence earlier diagnostics > make[3]: Leaving directory > '/build/reproducible-path/diamond-aligner-2.1.11/obj-riscv64-linux-gnu' > make[2]: *** [CMakeFiles/Makefile2:93: CMakeFiles/arch_generic.dir/all] Error > 2 > make[2]: Leaving directory > '/build/reproducible-path/diamond-aligner-2.1.11/obj-riscv64-linux-gnu' > make[1]: *** [Makefile:149: all] Error 2 > make[1]: Leaving directory > '/build/reproducible-path/diamond-aligner-2.1.11/obj-riscv64-linux-gnu' > dh_auto_build: error: cd obj-riscv64-linux-gnu && make -j4 "INSTALL=install > --strip-program=true" VERBOSE=1 returned exit code 2 > make: *** [debian/rules:16: binary-arch] Error 25 > dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit > status 2 > ``` > The full buildd log is here: > https://buildd.debian.org/status/fetch.php?pkg=diamond-aligner&arch=riscv64&ver=2.1.11-1&stamp=1741409747&raw=0 > My solution to this issue: > This issue occurs because the memcpy function is defined in the > header file, but the code does not include this header. Therefore, it can be > resolved by adding #include .I have tested this locally,and it works > well.The debpatch is in the attachment.Please let me know whether this > solution can be accepted. This should probably be upstreamed and doesn't look like a riscv64-exclusive bug. See: https://github.com/bbuchfink/diamond Can you repor the issue upstream? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1099833: wiki.debian.org: Verbatim text containing "8k/com" triggers spam filter
Package: wiki.debian.org
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org
Hello,
I wanted to create a wiki page which contains the following verbatim text:
=== SunOS 4.1.1 ===
{{{
# dmesg | head -8
Feb 15 12:38
SunOS Release 4.1.1 (GENERIC) #1: Sat Oct 13 06:05:48 PDT 1990
Copyright (c) 1983-1990, Sun Microsystems, Inc.
mem = 24576K (0x1800)
avail mem = 23486464
Ethernet address = 8:0:20:0:0:3
si at vme24d16 0x20 vec 0x40
# uname -a
SunOS ferrari 4.1.1 1 sun3
# cat test.c
#include
#include
#define offsetof(type, member) ((size_t)(unsigned long)(&((type *)0)->member))
struct test { char x; int y; };
int main()
{
printf("struct test { char x; int y; };\n");
printf("sizeof(sturct test) = %d\n", sizeof(struct test));
printf("offsetof(struct test, y) = %d\n", offsetof(struct test, y));
}
# cc test.c
# file a.out
a.out: mc68020 demand paged dynamically linked executable not stripped
# ./a.out
struct test { char x; int y; };
sizeof(struct test) = 6
offsetof(struct test, y) = 2
#
}}}
This fails as the substring "8k/com" triggers a spam filter, the error message
is:
'Sorry, can not save page because "8k/com" is not allowed in this wiki.'
Can this be alleviated by fixing the blacklist of the spam filter? I'm not sure
why
"8k/com" is a blocked string, in particular being a substring.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1098802: sponsorship-requests: libjs-glibbox/3.3.1-1 [ITP] -- GLightbox is a pure javascript lightbox
Karsten, The 'd/install' file contains: dist/* usr/share/javascript/glightbox We are not removing the 'dist' directory and building the source? Not the most knowledgeable on JS packages, but this seems wrong to me. Could someone offer advice? -- Regards Phil Donate: https://buymeacoffee.com/kathenasorg -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Bug#1095854: dcmtk 3.6.7-9~deb12u3 flagged for acceptance
package release.debian.org tags 1095854 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: dcmtk Version: 3.6.7-9~deb12u3 Explanation: fix arbitrary code execution issue [CVE-2024-28130]; fix buffer overflow issues [CVE-2025-25472 CVE-2025-25474]; fix NULL pointer dereference issue [CVE-2025-25475]
Bug#1095437: spamassassin 4.0.1-1~deb12u1 flagged for acceptance
package release.debian.org tags 1095437 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: spamassassin Version: 4.0.1-1~deb12u1 Explanation: new upstream stable release
Bug#1098223: node-redis 4.5.1+~1.1.2-1+deb12u1 flagged for acceptance
package release.debian.org tags 1098223 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: node-redis Version: 4.5.1+~1.1.2-1+deb12u1 Explanation: fix build failure
Bug#1099832: fixnt.1: Some remarks and a patch with editorial changes for this man page
Package: a2ps Version: 1:4.15.6-1+b1 Severity: minor Tags: patch * What led up to the situation? Checking for defects with a new version test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z < "man page" [Use "groff -e ' $' -e '\\~$' " to find obvious trailing spaces.] ["test-groff" is a script in the repository for "groff"; is not shipped] (local copy and "troff" slightly changed by me). [The fate of "test-nroff" was decided in groff bug #55941.] * What was the outcome of this action? troff::6: warning: trailing space in the line troff::8: warning: trailing space in the line troff::12: warning: trailing space in the line troff::17: warning: trailing space in the line troff::19: warning: trailing space in the line * What outcome did you expect instead? No output (no warnings). -.- General remarks and further material, if a diff-file exist, are in the attachments. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.12.12-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages a2ps depends on: ii file 1:5.45-3+b1 ii libc6 2.40-7 ii libgc1 1:8.2.8-1 ii libpaper2 2.2.5-0.3+b1 ii psutils3.3.8-1 Versions of packages a2ps recommends: ii bzip2 1.0.8-6 pn lpr | rlpr | cups-client ii wdiff 1.2.2-7 Versions of packages a2ps suggests: ii emacsen-common 3.0.5 ii ghostscript 10.04.0~dfsg-2+b1 ii groff1.23.0-7 ii gv 1:3.7.4-2+b2 pn html2ps ii imagemagick 8:7.1.1.43+dfsg1-1 ii imagemagick-7.q16 [imagemagick] 8:7.1.1.43+dfsg1-1 pn t1-cyrillic ii texlive-binaries [texlive-base-bin] 2024.20240313.70630+ds-5+b1 -- no debconf information Input file is fixnt.1 Output from "mandoc -T lint fixnt.1": (shortened list) 8 whitespace at end of input line Remove trailing space with: sed -e 's/ *$//' -.-. Output from "test-nroff -mandoc -t -ww -z fixnt.1": (shortened list) 5 trailing space in the line Remove trailing space with: sed -e 's/ *$//' -.-. Remove space characters (whitespace) at the end of lines. Use "git apply ... --whitespace=fix" to fix extra space issues, or use global configuration "core.whitespace". Number of lines affected is 8 -.-. Put a subordinate sentence (after a comma) on a new line. fixnt.1:12:files, that are incompatible with psutils. fixnt.1:14:is a filter that fixes these problems, allowing the use of fixnt.1:28:does not check for NTPSOct94. For a workaround, use a fixnt.1:31:to replace 'NTPSOct94' with 'NTPSOct95', like so: fixnt.1:42:Report bugs to the Authors, but avoid sending large postscript files. -.-. Remove quotes when there is a printable but no space character between them and the quotes are not for emphasis (markup), for example as an argument to a macro. fixnt.1:1:.TH "fixnt" 1 "February 2003" "a2ps" "Debian" -.-. Space character after a macro call. 43:.P -.-. Trailing space in a macro call. Remove with "sed -i -e 's/ *$//'" 5:.B fixnt 7:.I BADFILE.ps -.-. Section headings (.SH and .SS) do not need quoting their arguments. 45:.SH "SEE ALSO" -.-. Output from "test-groff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z ": troff::6: warning: trailing space in the line troff::8: warning: trailing space in the line troff::12: warning: trailing space in the line troff::17: warning: trailing space in the line troff::19: warning: trailing space in the line -.-. Generally: Split (sometimes) lines after a punctuation mark; before a conjunction. --- fixnt.1 2025-03-08 15:57:23.131841621 + +++ fixnt.1.new 2025-03-08 16:11:45.151423256 + @@ -1,22 +1,24 @@ -.TH "fixnt" 1 "February 2003" "a2ps" "Debian" +.TH fixnt 1 "February 2003" a2ps Debian .SH NAME fixnt \- Filter for the Windows NT postscript printer driver. .SH SYNOPSIS -.B fixnt -< -.I BADFILE.ps -> +.B fixnt +< +.I BADFILE.ps +> .I GOODFILE.ps .SH DESCRIPTION The Windows NT postscript driver has a tendency to make broken postscript -files, that are incompatible with psutils. +files, +that are incompatible with psutils. .B fixnt -is a filter that fixes these problems, allowing the use of +is a filter that fixes these problems, +allowing the use of .BR psnup (1). .PP -The filter takes the broken postscript file on +The filter takes the broken postscript file on .BR stdin , -and outputs a fixed postscript file on +and outputs a fixed postscript file on .BR stdout . It has no other form for invocation and takes no options on the command-line. .SH OPTIONS @@ -25,10 +27,
Bug#1099539: debian-ports-archive-keyring 2025.02.01~deb12u1 flagged for acceptance
package release.debian.org tags 1099539 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: debian-ports-archive-keyring Version: 2025.02.01~deb12u1 Explanation: add 2026 key; move 2023 and 2024 keys to the removed keyring
Bug#1099444: incus-base: ineffective Replaces for incus due to /usr-move (DEP17 P1)
On Mon, 3 Mar 2025 14:43:30 +0100 Helmut Grohne wrote: > [Y]ou moved the systemd units formerly present in incus to the incus-base > package. The way this is done is normally correct and works for trixie > -> sid upgrades. Unfortunately, the earlier version has also been > backported to bookworm-backports and there the systemd units are > installed into the aliased location. Therefore and upgrade from > bookworm-backports to sid may presently loose the systemd units. This > bug serves as a migration blocker. For more information refer to > https://subdivi.de/~helmut/dep17.html section P1. > > The failing scenario is rare. People upgrading from trixie to sid will > be unaffected as there is no aliasing in trixie. People running > bookworm-backports will most likely upgrade to some eventual > 6.0.3-4~bpo12+1 which will also have working Replaces and from there > they may be upgrading to trixie at a later time. It is the rare > situation from the aliased + previous package organization to the > canonicalized + reorganized packages that is prone to loss. I would expect this scenario to be exceedingly rare, bordering on purely theoretical. I do intend to provide an updated backport with the packaging changes; to be affected a user would have to avoid updating their bookworm system before upgrading to trixie. As we have a few months before the trixie stable release, I think the odds of someone not running `apt update && apt upgrade` between the upload of an updated backport and the trixie upgrade to be very low. (I suppose someone could also upgrade to testing in the window between Incus migrating to testing and an updated backport being available, but again I think that's pretty unlikely.) > Given this rarity, I suggest going with a rather weak mitigation that > will only work reliably when upgrading with an apt-based package manager > (and can leave failing scenarios behind when doing upgrades with dpkg > directly). It is (DEP17 M7): > > -Replaces: incus (<< 6.0.3-3~) > -Breaks: incus (<< 6.0.3-3~) > +Conflicts: incus (<< 6.0.3-3~) > > Then apt will prefer to unpack the updated incus (releasing the systemd > units) before unpacking incus-base and thus avert the file loss > situation. In other cases, I've suggested stronger mitigations, but here > my expectation is that the scenario is mostly artificial (assuming that > you do another bookworm-backports upload and people upgrade to it). > > Do you agree with the reasoning? If yes, please move forward and include > "DEP17 P1 M7" in debian/changelog. I am inclined to lower the severity of this bug, so Incus can migrate to testing, then close it after a new backport has been uploaded. If Incus had been part of the bookworm release, I would be more concerned about possible breakage during an upgrade to trixie, but Incus has only ever been available via backports for bookworm. As such, it's more of an "opt-in" situation with users needing to explicitly install it from backports. I also intend to backport the 6.0.4 release later this month, which will be another incentive for people to do an update well in advance of the trixie release, further minimizing the likelihood of someone actually encountering this upgrade issue. Mathias signature.asc Description: This is a digitally signed message part
Bug#1099755:
What's the scenario where an AD DC server will not have the samba-ad-dc package installed? That package exists since stable.
Bug#1060057: returning to pending CUPS-PDF issue
la 8.3.2025 klo 19.28 наб (nabijaczlew...@nabijaczleweli.xyz) kirjoitti: > On Sat, Mar 08, 2025 at 07:10:40PM +0200, Martin-Éric Racine wrote: > > la 8.3.2025 klo 18.03 наб (nabijaczlew...@nabijaczleweli.xyz) kirjoitti: > > > I just explicitly updated cups-pdf cups ghostscript on sid and > > > lp -dPDF all.ps > > > still produced an empty file (attached). > > Can I get a copy of that PS file? > It's attached to the OP on this bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1060057;filename=all.ps.zst;msg=5 Noted. > > Also, can you try another thing for me? > > > > cat .bashrc | lp -dPDF > > > > Does that produce a readable PDF for you? (I don't need a copy - I'm > > just trying to see whether we might be having problems with converting > > PS specifically). > The vast majority of postscripts, and all text files, work, > and I use cups-pdf basically all the time in my workflow. > > Both of > cat .bashrc | lp -dPDF > curl > https://lfs.nabijaczleweli.xyz/0012-groff-mdoc-*q-spacing/2022-10-23-stty.1-preprint/a4.ps > | lp -dPDF > work, as expected, on bookworm and sid. That's already more encouraging. > It's just this > (and some other similarly(?)-broken(?)/-funnily-configured(?)) > document. So we're dealing with a handful of corner-case PS files that, for whatever odd reason, fail to convert. That's a lot harder to debug. Let's see if upstream (in CC) might have any idea. Martin-Éric
Bug#1099834: tech-ctte: Call for votes on TC membership of Paul Tagliamonte
Hi, On 08/03/2025 17:48, Matthew Vernon wrote: Package: tech-ctte X-Debbugs-cc: paul...@debian.org, lea...@debian.org I call for votes on the following ballot to fill the vacant seat on the Debian Technical Committee. The voting period starts immediately and lasts for up to one week, or until the outcome is no longer in doubt. ===BEGIN The Technical Committee recommends that Paul Tagliamonte (paultag) be appointed by the Debian Project Leader to the Technical Committee. H: Recommend to Appoint Paul Tagliamonte (paultag) F: Further Discussion ===END With apologies for not correcting Paul's initial in the ballot, I vote: H > F Regards, Matthew OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1092310: libvmime patch for icu-76.1
Control: tags -1 +patch
Hi,
There are two ways to have this fixed. There's the minimal patch or
two upstream commits backported. It's your choice which way to go when
the transition starts.
Regards,
Laszlo/GCS
Description: fix FTBFS with ICU 75.1+
Set correct C++ standard.
Author: Laszlo Boszormenyi (GCS)
Forwarded: no
Last-Update: 2024-11-17
---
--- a/cmake/cmake-cxx11/Modules/CheckCXX11Features.cmake
+++ b/cmake/cmake-cxx11/Modules/CheckCXX11Features.cmake
@@ -55,13 +55,13 @@ cmake_minimum_required(VERSION 2.8.3)
### Check for needed compiler flags
#
include(CheckCXXCompilerFlag)
-check_cxx_compiler_flag("-std=c++11" _HAS_CXX11_FLAG)
+check_cxx_compiler_flag("-std=c++17" _HAS_CXX11_FLAG)
if (NOT _HAS_CXX11_FLAG)
check_cxx_compiler_flag("-std=c++0x" _HAS_CXX0X_FLAG)
endif ()
if (_HAS_CXX11_FLAG)
-set(CXX11_COMPILER_FLAGS "-std=c++11")
+set(CXX11_COMPILER_FLAGS "-std=c++17")
elseif (_HAS_CXX0X_FLAG)
set(CXX11_COMPILER_FLAGS "-std=c++0x")
endif ()
From 022303bbc9c281f7c2c525acaba19f31e755b4e3 Mon Sep 17 00:00:00 2001
From: bmagistro
Date: Sun, 31 Dec 2023 09:54:48 -0500
Subject: [PATCH] Build: static lib dependency for ICU (#281)
* Fix missed path for generated files in #277
* Update cmake to include char conversion dependency on static library
---
CMakeLists.txt | 16
1 file changed, 16 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 247dc342..e71000eb 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -773,6 +773,14 @@ IF(VMIME_CHARSETCONV_LIB STREQUAL "iconv")
)
ENDIF()
+ IF(VMIME_BUILD_STATIC_LIBRARY)
+ TARGET_LINK_LIBRARIES(
+ ${VMIME_LIBRARY_NAME}-static
+ ${TARGET_LINK_LIBRARIES}
+ ${ICONV_LIBRARIES}
+ )
+ ENDIF()
+
SET(VMIME_PKGCONFIG_LIBS "${VMIME_PKGCONFIG_LIBS} ${ICONV_LIBRARIES}")
SET(VMIME_PKGCONFIG_CFLAGS "${VMIME_PKGCONFIG_CFLAGS} -I${ICONV_INCLUDE_DIR}")
@@ -795,6 +803,14 @@ ELSEIF(VMIME_CHARSETCONV_LIB STREQUAL "icu")
)
ENDIF()
+ IF(VMIME_BUILD_STATIC_LIBRARY)
+ TARGET_LINK_LIBRARIES(
+ ${VMIME_LIBRARY_NAME}-static
+ ${TARGET_LINK_LIBRARIES}
+ ${ICU_LIBRARIES}
+ )
+ ENDIF()
+
SET(VMIME_PKGCONFIG_LIBS "${VMIME_PKGCONFIG_LIBS} ${ICU_LIBRARIES}")
SET(VMIME_PKGCONFIG_CFLAGS "${VMIME_PKGCONFIG_CFLAGS} -I${ICU_INCLUDE_DIRS}")
From 0f7014ab579acd4a29e743fa570d5ed8e58e2a41 Mon Sep 17 00:00:00 2001
From: Jan Engelhardt
Date: Tue, 11 Jun 2024 20:46:59 +0200
Subject: [PATCH] build: upgrade to C++17 when ICU is used (#310)
ICU 75 requires the use of C++17.
`SET(CMAKE_CXX_STANDARD 17)` has no effect after the first target has been defined
or so, therefore the detection of the conversion library is split and partially
moved upwards.
---
CMakeLists.txt | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3e209b54..89fb980c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -67,6 +67,23 @@ SET(VMIME_API_VERSION ${VMIME_API_VERSIO
# Set base name
SET(VMIME_LIBRARY_NAME vmime)
+##
+# Charset conversion library (1/2)
+
+INCLUDE(cmake/FindIconv.cmake)
+INCLUDE(cmake/FindICU.cmake)
+
+FIND_PACKAGE(ICU QUIET)
+
+IF(ICU_LIBRARIES)
+ SET(VMIME_CHARSETCONV_LIB_DETECTED "icu")
+ SET(CMAKE_CXX_STANDARD 17)
+ELSEIF(ICONV_FOUND)
+ SET(VMIME_CHARSETCONV_LIB_DETECTED "iconv")
+ELSEIF(WIN32)
+ SET(VMIME_CHARSETCONV_LIB_DETECTED "win")
+ENDIF()
+
# Source files
FILE(
GLOB_RECURSE
@@ -729,20 +746,7 @@ ENDIF(VMIME_HAVE_TLS_SUPPORT)
##
-# Charset conversion library
-
-INCLUDE(cmake/FindIconv.cmake)
-INCLUDE(cmake/FindICU.cmake)
-
-FIND_PACKAGE(ICU QUIET)
-
-IF(ICU_LIBRARIES)
- SET(VMIME_CHARSETCONV_LIB_DETECTED "icu")
-ELSEIF(ICONV_FOUND)
- SET(VMIME_CHARSETCONV_LIB_DETECTED "iconv")
-ELSEIF(WIN32)
- SET(VMIME_CHARSETCONV_LIB_DETECTED "win")
-ENDIF()
+# Charset conversion library (2/2)
SET(
VMIME_CHARSETCONV_LIB
Bug#1092316: haskell-text-icu patch for icu-76.1
Control: tags -1 +patch Hi, I provide a working, tested patch to fix this issue. Regards, Laszlo/GCS --- a/text-icu.cabal +++ b/text-icu.cabal @@ -125,7 +125,7 @@ library Data.Text.ICU.Spoof.Pure Data.Text.ICU.Text c-sources: cbits/text_icu.c - cc-options: -Wall -Wextra -pedantic -Wno-deprecated + cc-options: -Wall -Wextra -pedantic -Wno-deprecated -Wno-deprecated-declarations include-dirs: include if os(darwin) && flag(homebrew) extra-lib-dirs: @@ -140,7 +140,7 @@ library else extra-libraries: icui18n icudata - ghc-options: -Wall + ghc-options: -Wall -Wno-deprecated if impl(ghc >= 8.0) ghc-options: -Wcompat --- a/tests/Properties.hs +++ b/tests/Properties.hs @@ -195,7 +195,7 @@ testCases = c <- cal "CET" 2000 00 01 02 03 00 return $ I.formatCalendar dfDe (Cal.add c [(Cal.Hour, 25), (Cal.Second, 65)]) `ioEq` -"2. Januar 2000 um 03:04:05 GMT+1" +"2. Januar 2000 um 03:04:05 MEZ" ,do dfAt <- I.standardDateFormatter I.LongFormatStyle I.LongFormatStyle
Bug#1099428: wget 1.21.3-1+deb12u1 flagged for acceptance
package release.debian.org tags 1099428 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: wget Version: 1.21.3-1+deb12u1 Explanation: fix mishandling of semicolons in userinfo in URLs [CVE-2024-38428]
Bug#1099829: maildir-utils: 1.12.9 is available upstream
Control: tags -1 pending On 2025-03-08, at 09:52:26 -0600, John Goerzen wrote: > Package: maildir-utils > Severity: wishlist > > Hi, > > It would be great to have 1.12.9 packaged for trixie. > > Thanks! No problem. J. signature.asc Description: PGP signature
Bug#1099828: diamond-aligner :FTBFS:build failed ( error: ‘memcpy’ was not declared in this scope)
Source: diamond-aligner Version: 2.1.11-1 Severity: serious Tags: FTBFS, patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Dear diamond-aligner maintainer, The package diamond-aligner build failed on riscv64.The crucial buildd log below: ``` /build/reproducible-path/diamond-aligner-2.1.11/src/search/finger_print.h: In constructor ‘Byte_finger_print_48::Byte_finger_print_48(const Letter*)’: /build/reproducible-path/diamond-aligner-2.1.11/src/search/finger_print.h:138:17: error: ‘memcpy’ was not declared in this scope 138 | memcpy(r, q - 16, 48); | ^~ /build/reproducible-path/diamond-aligner-2.1.11/src/search/finger_print.h:26:1: note: ‘memcpy’ is defined in header ‘’; this is probably fixable by adding ‘#include ’ 25 | #include "basic/value.h" +++ |+#include 26 | At global scope: cc1plus: note: unrecognized command-line option ‘-Wno-unknown-warning-option’ may have been intended to silence earlier diagnostics make[3]: *** [CMakeFiles/arch_generic.dir/build.make:96: CMakeFiles/arch_generic.dir/src/search/stage1_2.cpp.o] Error 1 make[3]: *** Waiting for unfinished jobs In file included from /usr/include/c++/14/list:62, from /build/reproducible-path/diamond-aligner-2.1.11/src/dp/swipe/swipe_wrapper.cpp:22: In function ‘typename __gnu_cxx::__enable_if::__value, void>::__type std::__fill_a1(_ForwardIterator, _ForwardIterator, const _Tp&) [with _ForwardIterator = int*; _Tp = int]’, inlined from ‘void std::__fill_a(_FIte, _FIte, const _Tp&) [with _FIte = int*; _Tp = int]’ at /usr/include/c++/14/bits/stl_algobase.h:998:21, inlined from ‘void std::fill(_ForwardIterator, _ForwardIterator, const _Tp&) [with _ForwardIterator = int*; _Tp = int]’ at /usr/include/c++/14/bits/stl_algobase.h:1029:20, inlined from ‘DP::Swipe::ARCH_GENERIC::Matrix::Matrix(int, int) [with Sv = int]’ at /build/reproducible-path/diamond-aligner-2.1.11/src/dp/swipe/full_matrix.h:66:12: /usr/include/c++/14/bits/stl_algobase.h:952:18: warning: ‘void* __builtin_memset(void*, int, long unsigned int)’ specified bound 18446744073709551612 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] 952 | *__first = __tmp; | ~^~~ At global scope: cc1plus: note: unrecognized command-line option ‘-Wno-unknown-warning-option’ may have been intended to silence earlier diagnostics make[3]: Leaving directory '/build/reproducible-path/diamond-aligner-2.1.11/obj-riscv64-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:93: CMakeFiles/arch_generic.dir/all] Error 2 make[2]: Leaving directory '/build/reproducible-path/diamond-aligner-2.1.11/obj-riscv64-linux-gnu' make[1]: *** [Makefile:149: all] Error 2 make[1]: Leaving directory '/build/reproducible-path/diamond-aligner-2.1.11/obj-riscv64-linux-gnu' dh_auto_build: error: cd obj-riscv64-linux-gnu && make -j4 "INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2 make: *** [debian/rules:16: binary-arch] Error 25 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 ``` The full buildd log is here: https://buildd.debian.org/status/fetch.php?pkg=diamond-aligner&arch=riscv64&ver=2.1.11-1&stamp=1741409747&raw=0 My solution to this issue: This issue occurs because the memcpy function is defined in the header file, but the code does not include this header. Therefore, it can be resolved by adding #include .I have tested this locally,and it works well.The debpatch is in the attachment.Please let me know whether this solution can be accepted. Gui-Yue Best Regards fix_diamond-aligner_missing_cstring.patch Description: Binary data
Bug#1060057: returning to pending CUPS-PDF issue
I just explicitly updated cups-pdf cups ghostscript on sid and
lp -dPDF all.ps
still produced an empty file (attached).
CUPS config attached, log below.
$ dpkg -l | grep -e cups -e pdf -e ghost
ii cups 2.4.10-2+b1amd64 Common UNIX Printing
System(tm) - PPD/driver support, web interface
ii cups-client2.4.10-2+b1amd64 Common UNIX Printing
System(tm) - client programs (SysV)
ii cups-common2.4.10-2 allCommon UNIX Printing
System(tm) - common files
ii cups-core-drivers 2.4.10-2+b1amd64 Common UNIX Printing
System(tm) - driverless printing
ii cups-daemon2.4.10-2+b1amd64 Common UNIX Printing
System(tm) - daemon
ii cups-filters 1.28.17-4.1amd64 OpenPrinting CUPS
Filters - Main Package
ii cups-filters-core-drivers 1.28.17-4.1amd64 OpenPrinting CUPS
Filters - Driverless printing
ii cups-ipp-utils 2.4.10-2+b1amd64 Common UNIX Printing
System(tm) - IPP developer/admin utilities
ii cups-ppdc 2.4.10-2+b1amd64 Common UNIX Printing
System(tm) - PPD manipulation utilities
ii cups-server-common 2.4.10-2 allCommon UNIX Printing
System(tm) - server common files
ii ghostscript10.04.0~dfsg-2+b1 amd64 interpreter for the
PostScript language and for PDF
ii libcups2t64:amd64 2.4.10-2+b1amd64 Common UNIX Printing
System(tm) - Core library
ii libcupsfilters1t64:amd64 1.28.17-4.1amd64 OpenPrinting CUPS
Filters - Shared library
ii libqpdf29t64:amd64 11.9.1-1 amd64 runtime library for
PDF transformation/inspection software
ii printer-driver-cups-pdf3.0.1-19 amd64 printer driver for PDF
writing via CUPS
Sat Mar 8 16:51:20 2025 [DEBUG] *** Final Configuration ***
Sat Mar 8 16:51:20 2025 [DEBUG] AnonDirName=
"/var/spool/cups-pdf/ANONYMOUS"
Sat Mar 8 16:51:20 2025 [DEBUG] AnonUser = "nobody"
Sat Mar 8 16:51:20 2025 [DEBUG] GhostScript= "/usr/bin/gs"
Sat Mar 8 16:51:20 2025 [DEBUG] GSCall = "%s -q
-dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite
-sOutputFile="%s" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false
-dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c -f %s"
Sat Mar 8 16:51:20 2025 [DEBUG] Grp= "lpadmin"
Sat Mar 8 16:51:20 2025 [DEBUG] GSTmp = "TMPDIR=/var/tmp"
Sat Mar 8 16:51:20 2025 [DEBUG] Log= "/var/log/cups"
Sat Mar 8 16:51:20 2025 [DEBUG] PDFVer = "1.2"
Sat Mar 8 16:51:20 2025 [DEBUG] PostProcessing = ""
Sat Mar 8 16:51:20 2025 [DEBUG] Out= "${HOME}/PDF"
Sat Mar 8 16:51:20 2025 [DEBUG] Spool =
"/var/spool/cups-pdf/SPOOL"
Sat Mar 8 16:51:20 2025 [DEBUG] UserPrefix = ""
Sat Mar 8 16:51:20 2025 [DEBUG] RemovePrefix = ""
Sat Mar 8 16:51:20 2025 [DEBUG] OutExtension = "pdf"
Sat Mar 8 16:51:20 2025 [DEBUG] Cut= 3
Sat Mar 8 16:51:20 2025 [DEBUG] Truncate = 64
Sat Mar 8 16:51:20 2025 [DEBUG] DirPrefix = 0
Sat Mar 8 16:51:20 2025 [DEBUG] Label = 1
Sat Mar 8 16:51:20 2025 [DEBUG] LogType= 7
Sat Mar 8 16:51:20 2025 [DEBUG] LowerCase = 1
Sat Mar 8 16:51:20 2025 [DEBUG] TitlePref = 0
Sat Mar 8 16:51:20 2025 [DEBUG] DecodeHexStrings = 1
Sat Mar 8 16:51:20 2025 [DEBUG] FixNewlines= 0
Sat Mar 8 16:51:20 2025 [DEBUG] AllowUnsafeOptions = 0
Sat Mar 8 16:51:20 2025 [DEBUG] AnonUMask =
Sat Mar 8 16:51:20 2025 [DEBUG] UserUMask = 0077
Sat Mar 8 16:51:20 2025 [DEBUG] *** End of Configuration ***
Sat Mar 8 16:51:20 2025 [DEBUG] set new gid: lpadmin
Sat Mar 8 16:51:20 2025 [STATUS] directory created: /var/spool/cups-pdf/SPOOL
Sat Mar 8 16:51:20 2025 [STATUS] spool directory created:
/var/spool/cups-pdf/SPOOL
Sat Mar 8 16:51:20 2025 [DEBUG] initialization finished: v3.0.1
Sat Mar 8 16:51:20 2025 [DEBUG] user identified: nabijaczleweli
Sat Mar 8 16:51:20 2025 [DEBUG] output directory name generated:
/home/nabijaczleweli/PDF
Sat Mar 8 16:51:20 2025 [DEBUG] user information prepared
Sat Mar 8 16:51:20 2025 [DEBUG] spoolfile name created:
/var/spool/cups-pdf/SPOOL/cups2pdf-3056
Sat Mar 8 16:51:20 2025 [DEBUG] source stream ready
Sat Mar 8 16:51:20 2025 [DEBUG] destination stream ready:
/var/spool/cups-pdf/SPOOL/cups2pdf-3056
Sat Mar 8 16:51:20 2025 [DEBUG] owner set for spoolfile:
/var/spool/cups-pdf/SPOOL/cups2pdf-3056
Sat Mar 8 16:51:20 2025 [DEBUG] using traditional fgets
Sat Mar 8 16:51:20 2025 [DEBUG] found beginning of postscript code:
%!PS-Adobe-3.0
Sat Mar 8 16:51:20 2025 [DEBUG] now extracting postscript code
Sat Mar 8 16:51:20 2025 [DEBUG] found title in ps code: stdin
nabijaczleweli/PDF
Sat Mar 8 16:51:20 2025 [DE
Bug#1098297: lttng-modules 2.13.9-1+deb12u1 flagged for acceptance
package release.debian.org tags 1098297 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: lttng-modules Version: 2.13.9-1+deb12u1 Explanation: fix build with newer bullseye kernels
Bug#1099749: iptables-netflow 2.6-4+deb12u1 flagged for acceptance
package release.debian.org tags 1099749 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: iptables-netflow Version: 2.6-4+deb12u1 Explanation: fix build with newer bullseye kernels
Bug#1098308: node-js-sdsl 4.1.4-2+deb12u1 flagged for acceptance
package release.debian.org tags 1098308 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: node-js-sdsl Version: 4.1.4-2+deb12u1 Explanation: fix build failure
Bug#1099792: chromium 134.0.6998.35-1~deb12u1 into stable-security has broken python3-selenium on bookworm
Thanks for the report. This is fixed in sid, but it will have to wait for the next security update to get fixed in bookworm. Given the pace of releases though, this is likely to be as soon as this Tuesday. As a workaround, 'apt install chromium' should fix it. On 3/8/25 04:07, Francesco Ballarin wrote: Source: chromium Severity: important X-Debbugs-Cc: c.schoen...@t-online.de, dilin...@debian.org, tpear...@raptorengineering.com Control: affects -1 python3-selenium Control: tags -1 bookworm Hi, there was a recent upload [2025-03-06] Accepted chromium 134.0.6998.35-1~deb12u1 (source amd64 all) into stable-security (Debian FTP Masters) (signed by: Andres Salomon) to stable-security which upgraded chromium from 133 to 134. Unfortunately, it seems that such an upgrade has broken python3-selenium, which hasn't been upgraded in stable since 4.8.3+dfsg-1, March 2023. Now when using python3-selenium I get Traceback (most recent call last): File "", line , in setUp self.selenium = webdriver.Chrome(options=chrome_options) File "/usr/lib/python3/dist-packages/selenium/webdriver/chrome/webdriver.py", line 80, in __init__ super().__init__( File "/usr/lib/python3/dist-packages/selenium/webdriver/chromium/webdriver.py", line 104, in __init__ super().__init__( File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", line 286, in __init__ self.start_session(capabilities, browser_profile) File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", line 378, in start_session response = self.execute(Command.NEW_SESSION, parameters) ^ File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", line 440, in execute self.error_handler.check_response(response) File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/errorhandler.py", line 245, in check_response raise exception_class(message, screen, stacktrace) selenium.common.exceptions.SessionNotCreatedException: Message: session not created from unknown error: cannot find Chrome binary = while, on the same set up, on March 3 I wasn't getting any error, which to me suggests that the issue is caused by the upgrade from 133 to 134. While the bug is due to an upload to stable-security, this isn't reporting a security issue per se, rather a usability one. How can a working python3-selenium be restored for bookworm users? Thanks, Francesco OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1098725: curl 7.88.1-10+deb12u11 flagged for acceptance
package release.debian.org tags 1098725 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: curl Version: 7.88.1-10+deb12u11 Explanation: fix possible credentials leakage issue [CVE-2025-0167]
Bug#1098890: RFS: clipboard/0.10.0-1 [ITP] -- Smart Clipboard Manager
Control: tags -1 +moreinfo Kirill, Fails to build with 'sbuild', information below. make[1]: Leaving directory '/build/reproducible-path/clipboard-0.10.0/obj- x86_64-linux-gnu' dh_auto_test create-stamp debian/debhelper-build-stamp dh_prep dh_auto_install cd obj-x86_64-linux-gnu && make -j10 install DESTDIR=/build/reproducible-path/clipboard-0.10.0/debian/tmp AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true" make[1]: Entering directory '/build/reproducible-path/clipboard-0.10.0/obj- x86_64-linux-gnu' /usr/bin/cmake -S/build/reproducible-path/clipboard-0.10.0 - B/build/reproducible-path/clipboard-0.10.0/obj-x86_64-linux-gnu --check-build- system CMakeFiles/Makefile.cmake 0 make -f CMakeFiles/Makefile2 preinstall make[2]: Entering directory '/build/reproducible-path/clipboard-0.10.0/obj- x86_64-linux-gnu' make[2]: Nothing to be done for 'preinstall'. make[2]: Leaving directory '/build/reproducible-path/clipboard-0.10.0/obj- x86_64-linux-gnu' Install the project... /usr/bin/cmake -P cmake_install.cmake -- Install configuration: "RelWithDebInfo" -- Installing: /build/reproducible-path/clipboard- 0.10.0/debian/tmp/usr/lib/x86_64-linux-gnu/libcbx11.so.1.0 -- Installing: /build/reproducible-path/clipboard- 0.10.0/debian/tmp/usr/lib/x86_64-linux-gnu/libcbx11.so.1 -- Installing: /build/reproducible-path/clipboard- 0.10.0/debian/tmp/usr/lib/x86_64-linux-gnu/libcbx11.so -- Installing: /build/reproducible-path/clipboard-0.10.0/debian/tmp/usr/bin/cb -- Installing: /build/reproducible-path/clipboard- 0.10.0/debian/tmp/usr/share/man/man1/cb.1 -- Installing: /build/reproducible-path/clipboard- 0.10.0/debian/tmp/usr/share/bash-completion/completions/cb make[1]: Leaving directory '/build/reproducible-path/clipboard-0.10.0/obj- x86_64-linux-gnu' dh_install dh_install: warning: Cannot find (any matches for) "usr/lib/x86_64-linux- gnu/libcbwayland.so.1" (tried in ., debian/tmp) dh_install: warning: libcbwayland1 missing files: usr/lib/x86_64-linux- gnu/libcbwayland.so.1 dh_install: warning: Cannot find (any matches for) "usr/lib/x86_64-linux- gnu/libcbwayland.so.1.0" (tried in ., debian/tmp) dh_install: warning: libcbwayland1 missing files: usr/lib/x86_64-linux- gnu/libcbwayland.so.1.0 dh_install: warning: Cannot find (any matches for) "usr/lib/x86_64-linux- gnu/libcbwayland.so" (tried in ., debian/tmp) dh_install: warning: libcbwayland1-dev missing files: usr/lib/x86_64-linux- gnu/libcbwayland.so dh_install: error: missing files, aborting make: *** [debian/rules:12: binary] Error 255 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 --- - Build finished at 2025-03-08T18:47:38Z Finished +-- + | Cleanup Sat, 08 Mar 2025 18:47:38 + | +-- + Purging /build/reproducible-path Not cleaning session: cloned chroot in use E: Build failure (dpkg-buildpackage died with exit 2) -- Regards Phil Donate: https://buymeacoffee.com/kathenasorg -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Bug#1099841: gamescope: Noticeable performance regression in AMD Polaris
Package: gamescope Version: 3.16.1-1 Severity: normal X-Debbugs-Cc: daltroaugu...@tutanota.com The situation is occuring when I'm playing the game Red Dead Redemption 1, but it may happen in other games as well. I notice that when I'm playing the game (3D elements, mostly) everything is fine. However, if any HUD/UI element is overlayed, e.g. when I need to select other weapon while playing, I see huge FPS drops (90-ish to 50-ish), and the game stutters. When I play the same game without gamescope, things run fine. This issue didn't happen with the previous version of the package. This 3.16 release of Gamescope introduced a major change for AMD polaris GPUs (like my Sapphire RX 570) that may be the reason of the issue. Before that version, we AMD users were obligated to use the "sdl" backend to run programs with gamescope, as the program gave us a "types/wlr_linux_dmabuf_v1.c:532: feedback_compile: Assertion `table_len > 0' failed." exception. Now, we seem to be obligated to use the default (wayland) backend, as if I try to run the game with the older sdl backend, I got the exact same exception that was outputted when I tried to use wayland backend, in the previous versions. So, I would expect to: be still able to run the older backend; or to at least not have noticeable performance issues due to this new backend/due to the latest updates. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.13.6-1-liquorix-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gamescope depends on: ii libavif16 1.1.1-1 ii libc6 2.40-7 ii libcap2 1:2.66-5+b1 ii libdecor-0-0 0.2.2-2 ii libdisplay-info2 0.2.0-2 ii libdrm2 2.4.124-1 ii libeis1 1.3.901-1 ii libgcc-s1 14.2.0-17 ii libliftoff0 0.5.0-1.1 ii libluajit-5.1-2 2.1.0+openresty20250117-2 ii libpipewire-0.3-0t64 1.2.7-1+b2 ii libpixman-1-0 0.44.0-3 ii libsdl2-2.0-0 2.32.2+dfsg-1 ii libstdc++614.2.0-17 ii libwayland-client01.23.1-3 ii libwayland-server01.23.1-3 ii libwlroots-0.18 0.18.2-3 ii libx11-6 2:1.8.10-2 ii libx11-xcb1 2:1.8.10-2 ii libxcb1 1.17.0-2+b1 ii libxcomposite11:0.4.6-1 ii libxcursor1 1:1.2.3-1 ii libxdamage1 1:1.1.6-1+b2 ii libxext6 2:1.3.4-1+b3 ii libxfixes31:6.0.0-2+b4 ii libxi62:1.8.2-1 ii libxkbcommon0 1.7.0-2 ii libxmu6 2:1.1.3-3+b4 ii libxrender1 1:0.9.10-1.1+b4 ii libxres1 2:1.2.1-1+b2 ii libxtst6 2:1.2.5-1 ii libxxf86vm1 1:1.1.4-1+b4 ii xwayland 2:24.1.6-1 Versions of packages gamescope recommends: ii seatd 0.9.1-1 Versions of packages gamescope suggests: ii libcap2-bin 1:2.66-5+b1 pn pipewire-audio -- no debconf information
Bug#1099842: lintian: maintainer-script-lacks-home-in-adduser recommends options that are no longer needed
Package: lintian Version: 2.121.1+nmu1 Severity: normal X-Debbugs-Cc: addu...@packages.debian.org Since adduser 3.122, `adduser --system` automatically defaults to `--home /nonexistent` if no home directory is specified, so as requested by the adduser maintainer in #1099086, I tried changing dbus-system-bus-common to stop explicitly saying `--home /nonexistent`. I was also asked to stop using --no-create-home, because in adduser 3.130 or later, there is a special case to never create /nonexistent. However, this results in a lintian tag at error level: > E: dbus-system-bus-common: maintainer-script-lacks-home-in-adduser "adduser > --system --quiet --group "$MESSAGEUSER"" [postinst:22] and the description of that tag gives advice that contradicts what the adduser maintainer requested: > Please use adduser --no-create-home --home /nonexistent instead. I think this tag should probably not be emitted for adduser calls with --system and no --home, at least not in packages that have a versioned dependency on adduser (>= 3.130) (but adduser in Debian 12 'bookworm' is newer than that, and we officially don't support skipping a release, so the versioned dependency is not strictly necessary for packages targeting trixie or later). This means that in Lintian's test suite, adduser calls like this: > t/recipes/checks/build-systems/debhelper/maintainer-script/token/scripts-maintainer-general/build-spec/debian/postinst:adduser > --system foo are actually fine and should not emit this tag: > t/recipes/checks/scripts/scripts-maintainer-general/eval/hints:scripts-maintainer-general > (binary): maintainer-script-lacks-home-in-adduser "adduser --system foo" > [postinst:148] adduser maintainer cc'd to give the opportunity to confirm or deny my interpretation being correct. smcv
Bug#1073665: fixed in libreswan 4.14-1.1
Am 08.03.25 um 20:10 schrieb Michael Biebl: Hi unfortunately the latest upload from experimental to unstable missed to incorporate the changes from this NMU. Thus reopening this RC bug and marking as found accordingly. Regards, Michael On Wed, 25 Sep 2024 22:25:33 + Debian FTP Masters master.debian.org> wrote: libreswan (4.14-1.1) unstable; urgency=medium . * Non-maintainer upload. * Move aliased files from / to /usr (DEP17). (Closes: #1073665) Actually, the package in unstable looks to be broken in a different way. It contains the following files /ipsec.service /libreswan.conf (yes, that's the root directory) It seems you are missing a Build-Depends on systemd-dev, which ships systemd.pc. It appears your package needs both: a Build-Depends on systemd and systemd-dev. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1099533: nmu: rust-mimalloc_0.1.29-1
Hi Jochen, On 04-03-2025 16:32, Jochen Sprickerhof wrote: This is on an Intel Xeon X5690 without AVX. Rebuilding against the current unstable toolchain fixes the build so I assume it is some build dependency that was fixed in the meantime. How have you tested this, I guess building (not rebuilding) on the same hardware? I'm wondering, would it be worth while to try and find out which build dependency this is? Maybe it's not fixed, but just depending on which buildd it gets build to exhibit the issue? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1095392: smart-open FTBFS: tests hang
Control: tags -1 patch In addition to the hangs, several tests fail. It looks like the trigger is botocore enabling checksums by default: https://sources.debian.org/src/python-boto3/1.36.0%2Bdfsg-1/CHANGELOG.rst/#L12 Turning them off with AWS_REQUEST_CHECKSUM_CALCULATION=when_required makes the tests pass: https://salsa.debian.org/python-team/packages/smart-open/-/tree/experiments1095392?ref_type=heads However, I haven't looked closely enough to say whether this is actually a full solution. It isn't obviously known to upstream.
Bug#973654: TLS: start_SSL fails to set SSL_verifycn_name
Control: fixed -1 1:2.13.0-1 On 06/11/20 10:23 AM, Sven Bartscher wrote: Hi, > Control: forwarded -1 https://gitlab.com/amavis/amavis/-/issues/72 According to the metadata in Gitlab the fix has been released in 2.13.0 Bernhard
Bug#1098983: crm114,crmsh: both install crm
Well, crm114 is long time abandonware upstream and according to the popularity contest not much popular in Debian. So I think it’s better to leave crmsh untouched and solve the problem on the crm114 side. Either by making it conflicting with crmsh or by renaming the binary to crm114. The latter could upset users because their copied example scripts with the original shebangs would stop working; maybe the conflict would be better then, I guess there is a good chance that nobody uses both crmsh and crm114 on the same system. Regards, Milan
Bug#1099853: broot: fish completion doesn't work - zsh file shipped by mistake?
Control: tags -1 incoming On 08/03/25 21:19, Vincent van Leeuwen wrote: Examining the file it seems to be zsh syntax, not fish syntax. I can't find the file in the upstream git repo, so maybe something shipped by this package got switched around by mistake? Yep, after a recent change I switched the fish and zsh file paths by mistake, so zsh gets the fish completions and vice-versa. Fix incoming. Thanks for reporting!
Bug#1099068: RFH: ostree -- content-addressed filesystem for operating system binaries
Hi Simon, On Thu, 27 Feb 2025 20:38:13 + Simon McVittie wrote: I request assistance with maintaining the ostree package. (Other Uploaders cc'd.) I'm willing to help maintaining this package. src:ostree currently has one RC bug, #1098951, a test failure involving its interaction with GPG signature verification: updates to GPG have caused it to report a missing key (GPGME_SIGSUM_KEY_MISSING, OSTREE_GPG_ERROR_MISSING_KEY, "Can't check signature: public key not found") instead of an expected failure mode like "key expired". I have been unable to identify whether this is a GPG bug or an ostree bug, and would particularly welcome help with this. Things seem to be progressing on the upstream side of gnupg. I'm going to closely follow the status of this regression to ensure fixes land as soon as possible in Debian. I first uploaded this package in 2016 as a dependency of Flatpak. It is team-maintained by the Utopia team (approximately a "freedesktop.org stuff" team) and has other Uploaders, but in practice I have effectively been maintaining it alone, which was not really my intention. I'm already a member of the Utopia team for pipewire/wireplumber. Some Debian-derived operating systems like Endless OS (and non-Debian-derived OSs like Fedora Silverblue) make use of ostree for their OS binaries, but I don't use it in that mode myself and have no particular expertise in how that works, so it would be helpful if someone who *is* using it in that mode could assist. As you know, we use ostree for Apertis image, this seems to be the expertise you're looking for. Best regards, Dylan
Bug#1099232: gauche-c-wrapper: FTBFS: ERROR: process 22782 exitted abnormally with exit code 512
Hi, On 2025-03-06 16:54, NIIBE Yutaka wrote: > Hello, > > Aurelien Jarno wrote: > > Currently it's not an issue for Sid (unstable), but glibc 2.41 should > > migrate to Trixie (testing) in the next days. > > Thank you. Now, I understand the situation. > > I uploaded the fix for #1099232. Thanks a lot for the prompt fix. In the meantime I have been able to find a way to get rid of that extra semicolon, it went upstream [1] and will be part of the glibc 2.41-4 upload. Regards Aurelien [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=443cb0b5f25129dd0f1e9f9101299d31c4700b7f -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1099854: amberol: Should not set inode/directory mimetype
On Sat, Mar 8, 2025 at 4:45 PM Matthias Geiger wrote:
> amberol sets the inode/directory file in its desktop file.
> This is wrong as it causes amberol to handle as app for opening files.
> Should probably fixed / discussed upstream.
I don't think this is necessarily a bug that needs to be fixed.
Similarly, I think your recent patch for baobab isn't needed and
interferes with someone who wants to use baobab to scan a particular
directory by right clicking on the directory in their file manager and
choosing Open with… Disk Usage Analyzer.
Debian's gnome-session-common package provides
/usr/share/applications/gnome-mimeapps.list which is currently
provided by
https://salsa.debian.org/gnome-team/gnome-session/-/blob/debian/latest/debian/gnome-mimeapps.list
although there was a draft merge request upstream to have GNOME
provide that file itself).
For desktops that set their XDG_CURRENT_DESKTOP to include GNOME, that
file is used to provide default apps for different mimetypes. (The
Ubuntu default desktop sets XDG_CURRENT_DESKTOP=ubuntu:GNOME so
gnome-mimeapps.list is currently used although I guess I should
provide a ubuntu-mimeapps.list to more clearly show where Ubuntu
diverges from the Debian GNOME set.)
What desktop/window manager do you use? I think you don't use GNOME
which is why the behavior isn't working for you. I think you should
consider updating the Debian package for your desktop to include a
reasonable ${desktop}-mimeapps.list . Notably, you can include
alternatives separated by semicolons in case there isn't necessarily a
single best app for a particular mimetype.
Thank you,
Jeremy Bícha
Bug#1099856: fakeroot: [INTL:pt] Update Portuguese translation of MANPAGE
Package: fakeroot Version: 1.37-1 Tags: l10n, patch- Severity: wishlist Updated Portuguese translation for fakeroot's manpage Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro fakeroot_1.37-1_pt.po.gz Description: application/gzip
Bug#1099828: [Debian-med-packaging] Bug#1099828: diamond-aligner :FTBFS:build failed ( error: ‘memcpy’ was not declared in this scope)
Hi Yue Gui, Yue Gui, on 2025-03-08: > The package diamond-aligner build failed on riscv64. […] > My solution to this issue: > This issue occurs because the memcpy function is defined in the > header file, but the code does not include this header. Therefore, it can > be resolved by adding #include .I have tested this locally,and it > works well.The debpatch is in the attachment.Please let me know whether > this solution can be accepted. > Gui-Yue > Best Regards The patch looks good to me, besides it is also going to fix further issues on other 64-bit release architectures also affected by the bug (I noticed at least ppc64el and s390x). I included your patch in the Salsa repository of the package. Let us know if you have the opportunity to send the patch upstream, the package can be uploaded shortly after. Thank you for your contribution! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from my alarm clock `- signature.asc Description: PGP signature
Bug#1099743: Wayland shell stops repainting the screen until monitor layout (or input devices?) change
On Fri, Mar 7, 2025 at 7:03 AM Nicolas Dandrimont wrote: > This morning, I've upgraded the gnome-related packages from the 48 beta series > to the 48 RC series and rebooted my laptop. > > Since then, I've had a baffling issue where the screen would stop repainting, > until I unplug *or* replug my dock (which reconnects an external monitor, > keyboard and mouse). I'm assuming what puts gnome-shell back on track is the > change to the monitor layout, but I haven't really isolated the behavior yet > (and I've now downgraded packages back to the ~beta versions to be able to > work > ;-)). I was experiencing similar behavior with 48 Beta. Notably, it is much more easily triggered during the hour-long Night Light transition. I see that you emailed early in the morning so maybe you were experiencing that. I recommend disabling Night Light until this issue is fixed. I also agree with Simon that sometimes the screen freezing seems to be triggered by high CPU load. I would like to downgrade the severity of this bug since this bug is preventing 48 RC from reaching Testing. I believe it is probably that 48 RC is at least a bit better than 48 Beta in other areas. That isn't saying that this bug isn't important and even Release Critical, but just that it may not be new with 48 RC and staying on 48 Beta isn't necessarily better for people using Testing. Also, I believe we will want to reassign this bug to mutter. (Technically marking the bug as found in 48 Beta would be equivalent to downgrading so I think that's what I would do instead.) Thank you, Jeremy Bícha
Bug#1098245: amavisd-new load package problem
Control: tags -1 patch On 18/02/25 10:54 AM, Grzegorz Malinka wrote: > Package: amavisd-new > Version: 1:2.13.0-3+deb12u1 > > Maillog: > : host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error > in processing, id=04086-18, quar+notif FAILED: temporarily unable to > quarantine: 451 4.5.0 Local delivery(1) to > /var/lib/amavis/virusmails/spam-Zxby_LTTGl9R.gz failed: Can't locate > object > method "new" via package "Amavis::IO::Zlib" (perhaps you forgot to load > "Amavis::IO::Zlib"?) at /usr/share/perl5/Amavis/Out/Local.pm line 199., > id=04086-18 at /usr/share/perl5/Amavis.pm line 5578. (in reply to end of > DATA command) > > Conclusion: > /usr/share/perl5/Amavis/Out/Local.pm doesn't include: > new Amavis::IO::Zlib There is a patch commited (but not yet released) upstream https://gitlab.com/amavis/amavis/-/commit/9bcb6fecedbe606a9cf988fa93a11e9754106a9c Bernhard
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On Tue, 5 Mar 2024 09:50:27 +0100 Helmut Grohne wrote: > Hi Bastian, > > On Mon, Mar 04, 2024 at 11:04:22PM +0100, Bastian Blank wrote: > > > Arguably, a cross toolchain build should probably search > > > /usr/include/. I went back and forth a bit with Matthias > > > about whether we could add this and did not fully understand his > > > reasons, but there is one technical reason we want to avoid it for now. > > > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed > > > and these packages can have differing versions. When that happens and we > > > search both /usr//include and /usr/include/, we'd > > > mix two glibc versions with usually bad results (been there). > > > > But this is a search path. If a file exists in one, the second one is > > not found. So nothing can happen even from version skew. > > The problem arises in the reverse sense. If a file does not exist in > one, it is searched in the second and erroneously may be found. That may > make tests pass that should not pass and typically causes a link failure > later. While I do not have a concrete example at hand, I have seen this > pattern repeatedly and generally favour moving stuff out of /usr/include > to avoid this kind of confusion that causes difficult to debug problems. > This also motivates #798955 (in addition to the problem with file > conflicts). > > > > The other aspect here is that it is not sufficient to add > > > /usr/include/ to the search path as you also need > > > /usr/include to get a complete linux kernel headers experience. We > > > definitely do not want to add /usr/include, because that is known to > > > misguide configure tests performed for the target architecture. > > > > We are talking about the toolchain itself. What configure tests could > > that be? Or is that premature optimization of the gcc build? > > The one case I really do remember quite well is sanitizers. These should > not be enabled in the earlier toolchain stages and failing to disable > them tends to cause linker failures. I don't think it matches the > concrete situation exactly though. You also make a good case in your > followup reporting that gcc-13-cross actually builds. > > > You just said that the search path used during the build of the > > toolchain and the one for everything else are unrelated. So you are > > free to create $BUILD/tmp-include with symlinks for asm, asm-generic, > > linux. > > > > The toolchain as installed already finds all headers. So I still don't > > see why we need this in the final system. > > I find this argument fairly convincing and hope Matthias also does. > > Thank you > > Helmut > > > +880 1406-311377number contact details
Bug#1099814: intel-microcode 3.20250211.1~deb12u1 flagged for acceptance
package release.debian.org tags 1099814 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: intel-microcode Version: 3.20250211.1~deb12u1 Explanation: new upstream security release [CVE-2023-34440 CVE-2023-43758 CVE-2024-24582 CVE-2024-28047 CVE-2024-28127 CVE-2024-29214 CVE-2024-31068 CVE-2024-31157 CVE-2024-36293 CVE-2024-37020 CVE-2024-39279 CVE-2024-39355]
Bug#1099519: /usr/bin/dgit: dgit-nmu-simple should be less pessimistic about rebasing
control: tag -1 + patch Hello, On Tue 04 Mar 2025 at 11:58am GMT, Ian Jackson wrote: > Package: dgit > Version: 12.6 > Severity: normal > File: /usr/bin/dgit > > I was asked in pers.comm about rebasing a branch from dgit clone, as > part of the dgit-nmu-simple workflow. > > Our current comments about rebasing are a bit elliptical; dealing > simultaneously with detailed situtations, but also doing so vaguely. > > I think we ought to state more directly the basic principles. > Something like this: > > You can treat the dgit/sid branch you end up on as a normal local > git branch tracking an upstream branch. So you can rebase your local > changes that you haven't pushed anywhere, as normal. > > The one thing that's weird is the quilt fixup commits (that turn up > if you do eg dgit sbuild), and the thing you need to know is that if > it's OK for you to be rebasing them at all, you can and should just > dreop them. > > All of this follows from an underlying fact, which is that dgit > doesn't have any magic state somewhere. So if you rebase away the > quilt fixup, and rework your branch, the result must be fine because > it looks *just like* it would do if you'd just made those commits > straight off. (NB git-debrebase *does* have weird off-branch state.) LGTM. -- Sean Whitton signature.asc Description: PGP signature
Bug#1099862: ITP: passim -- A local caching server
Package: wnpp Severity: wishlist Owner: Mario Limonciello X-Debbugs-Cc: debian-de...@lists.debian.org, supe...@gmail.com * Package name: passim Version : 0.1.9 * URL : https://github.com/hughsie/passim * License : LGPL2.1 Programming Lang: C Description : A local caching server Passim is used to cache small files (such as those from a CDN) to be able to share with other clients on the local network that would otherwise be downloading the same files. I'm planning to maintain it in the debian-efi team as it is an optional dependency for fwupd. Fwupd can use it to fetch files from the CDN and then share them with other clients on the same local network.
Bug#1099863: gawk.1: Some remarks and a patch with editorial changes for this man page
The version is 5.3.1.
Bug#1099864: RM: libsmbios -- ROM; Dead upstream, no remaining consumers in Debian
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: supe...@gmail.com User: ftp.debian@packages.debian.org Usertags: remove The libsmbios package previously had consumers in the fwupd package for Dell systems. This has been changed in fwupd and it directly talks to the kernel instead of using the libsmbios library. There have been bug reports forwarded upstream that are totally ignored. There hasn't been any changes upstream in 5 years. The project is effectively dead upstream and tech debt to maintain in Debian without much utility or need.
Bug#1099860: vifm: vim (or neovim) incorrectly listed as dependencies in package
Package: vifm Version: 0.13-1 Severity: normal X-Debbugs-Cc: farrislu...@gmail.com Dear Maintainer, When doing a routine system update, I noticed that the `vim` and `vim-runtime` packages were about to be installed for some reason. I found this rather confusing, but then I noticed that the `vifm` package is being updated alongside. I checked the dependencies for that package on the package index page vifm for sid, and indeed, it appears `vim` (or `neovim`) and also oddly `perl` were added as dependencies. I downloaded the deb for the `vifm` package, and modified it with those new dependencies removed, and then installed that. The version of the `vifm` package listed below is that modified package. It appears that vifm still runs fine. So my belief is that `vim` was added as a "dependency" to vifm, since it's likely that a vifm user would also be a Vim user. I strongly disagree with this change; it doesn't make sense to me for a package like `vifm` to be dictating what editor I should have installed on my system. Just because one may have vifm installed doesn't automatically mean they use either Vim or Neovim as their editor, or vice versa. For my case, I don't use either the `vim` nor `neovim` package in Debian's repos, and instead build an up-to-date version of Neovim from source, so using the `vifm` package as it currently stands would force me to have an extra version of Vim installed that I will never use for any reason, since I'd be using my Neovim. Since `vifm` can work just fine without Vim or Neovim installed, I think having `vim` | `neovim` as a recommends instead of a dependency would make more sense. This is my first bug report, so apologies if I did anything wrong in this report! :3 Thank you. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.12.17-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.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 vifm depends on: ii libc6 2.41-3 ii libmagic1t64 1:5.45-3+b1 ii libncursesw6 6.5+20250216-2 ii libtinfo6 6.5+20250216-2 Versions of packages vifm recommends: ii libx11-6 2:1.8.10-2 vifm suggests no packages. -- no debconf information
Bug#1099866: Undefined subroutine &Dpkg::OpenPGP::Backend::Sequoia::g_
Package: libdpkg-perl Version: 1.22.17 Severity: normal Tags: patch X-Debbugs-Cc: ykonoto...@gnome.org Hello! While building apt-mirror2 I recently got `Undefined subroutine &Dpkg::OpenPGP::Backend::Sequoia::g_` error. It looks like Dpkg::Gettext is missing from the Sequoia.pm. Below is the patch that fixes this issue: >From 5085a80c6298f1b924140ee10cfce7f4c641242e Mon Sep 17 00:00:00 2001 From: Yuri Konotopov Date: Sun, 9 Mar 2025 10:41:10 +0400 Subject: [PATCH] Dpkg::OpenPGP::Backend::Sequoia: add missing `Dpkg::Gettext` dependency Signed-off-by: Yuri Konotopov --- scripts/Dpkg/OpenPGP/Backend/Sequoia.pm | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/Dpkg/OpenPGP/Backend/Sequoia.pm b/scripts/Dpkg/OpenPGP/Backend/Sequoia.pm index 55cde3e2d..666bbe37c 100644 --- a/scripts/Dpkg/OpenPGP/Backend/Sequoia.pm +++ b/scripts/Dpkg/OpenPGP/Backend/Sequoia.pm @@ -36,6 +36,7 @@ use warnings; use POSIX qw(:sys_wait_h); use Dpkg::ErrorHandling; +use Dpkg::Gettext; use Dpkg::IPC; use Dpkg::OpenPGP::ErrorCodes; -- 2.45.3 -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.12.16 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages libdpkg-perl depends on: ii dpkg 1.22.17 ii perl 5.40.1-2 Versions of packages libdpkg-perl recommends: ii bzip2 1.0.8-6 ii libfile-fcntllock-perl 0.22-4+b4 ii liblocale-gettext-perl 1.07-7+b1 ii xz-utils5.6.4-1 Versions of packages libdpkg-perl suggests: ii binutils 2.44-3 pn bzr pn debian-keyring ii gcc [c-compiler] 4:14.2.0-1 ii gcc-14 [c-compiler] 14.2.0-17 pn git ii patch2.7.6-7 ii sensible-utils 0.0.24 ii sq 1.2.0-1+b1 -- no debconf information
Bug#1099867: Lintian: should source the current Standard from Masters
Package: lintian Version: 2.121.1+nmu1 Severity: normal X-Debbugs-Cc: martin-eric.rac...@iki.fi The newer-standards-version tends to be printed by mistake, usually because someone upgraded their packaging according to the latest debian-policy before a new Lintian got uploaded to the repository. What Lintian should instead do is source the current Standards live from Masters, and only issue the warning if the declared version is newer than that. src:routine-update already has the code to perform this. Martin-Éric -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 6.1.0-31-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii appstream 1.0.4-1 ii binutils2.44-3 ii bzip2 1.0.8-6 ii diffstat1.67-1 ii dpkg1.22.17 ii dpkg-dev1.22.17 ii file1:5.45-3+b1 ii gettext 0.23.1-1 ii gpg 2.2.46-4 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.17.0-1 ii libapt-pkg-perl 0.1.41 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.66-1 ii libcapture-tiny-perl0.50-1 ii libclass-xsaccessor-perl1.19-4+b5 ii libclone-perl 0.47-1+b1 ii libconfig-tiny-perl 2.30-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.39-1 ii libdata-dpath-perl 0.60-1 ii libdata-validate-domain-perl0.15-1 ii libdata-validate-uri-perl 0.07-3 ii libdevel-size-perl 0.84-1+b1 pn libdigest-sha-perl ii libdpkg-perl1.22.17 ii libemail-address-xs-perl1.05-1+b4 pn libencode-perl ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.026-1 ii libipc-run3-perl0.049-1 ii libjson-maybexs-perl1.004008-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.146-1 ii libperlio-gzip-perl 0.20-1+b4 ii libperlio-utf8-strict-perl 0.010-1+b3 ii libproc-processtable-perl 0.636-1+b3 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.004+ds-1+b3 ii libsereal-encoder-perl 5.004+ds-1+b3 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.30-1+b1 ii libterm-readkey-perl2.38-2+b4 ii libtext-levenshteinxs-perl 0.03-5+b4 ii libtext-markdown-discount-perl 0.18-1 ii libtext-xslate-perl 3.5.9-2+b1 ii libtime-duration-perl 1.21-2 ii libtime-moment-perl 0.44-2+b4 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-2+b3 ii liburi-perl 5.30-1 ii libwww-mechanize-perl 2.19-1 ii libwww-perl 6.78-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-5+b2 ii libyaml-libyaml-perl0.903.0+ds-1 ii lzip [lzip-decompressor]1.25-2 ii lzop1.04-2 ii man-db 2.13.0-1 ii patchutils 0.4.2-1 ii perl [libversion-perl] 5.40.1-2 ii t1utils 1.41-4 ii unzip 6.0-28 ii xz-utils5.6.4-1 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.61-1 -- no debconf information
Bug#1099865: gcc-13.1: Some remarks about this man page
Package: gcc-13-doc
Version: 13.3.0-1
Severity: minor
Tags: upstream
* What led up to the situation?
Checking for defects with a new version
test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z < "man
page"
[Use "groff -e ' $' -e '\\~$' " to find obvious trailing spaces.]
["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).
[The fate of "test-nroff" was decided in groff bug #55941.]
* What was the outcome of this action?
Output from "test-groff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z
":
an.tmac::68: style: 4 leading space(s) on input line
[...]
troff::99: warning: trailing space in the line
an.tmac::1441: style: use of deprecated macro: .PD
[...]
* What outcome did you expect instead?
No output (no warnings).
-.-
General remarks and further material, if a diff-file exist, are in the
attachments.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages gcc-13-doc depends on:
ii gcc-doc-base 14.2.0-1
gcc-13-doc recommends no packages.
Versions of packages gcc-13-doc suggests:
ii doc-base 0.11.2
-- no debconf information
Input file is gcc-13.1
Output from "mandoc -T lint gcc-13.1": (shortened list)
75 empty block: RS
2 input text line longer than 80 bytes: "Classic" devices wi...
[...]
167 whitespace at end of input line
Remove trailing space with: sed -e 's/ *$//'
-.-.
Output from "test-nroff -mandoc -t -ww -z gcc-13.1": (shortened list)
3 cannot break line
209 trailing space in the line
Remove trailing space with: sed -e 's/ *$//'
-.-.
Show if Pod::Man generated this.
Who is actually creating this man page? Debian or upstream?
Is the generating software out of date?
2:.\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43)
-.-.
Remove space characters (whitespace) at the end of lines.
Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".
Number of lines affected is
209
-.-.
Reduce space between words.
Examples:
gcc-13.1:141:\&\fB\-c \-S \-E \-o\fR \fIfile\fR
gcc-13.1:287:\&\-Wno\-c++11\-extensions \-Wno\-c++14\-extensions
\-Wno\-c++17\-extensions
gcc-13.1:615:\&\fB\-pie \-pthread \-r \-rdynamic
gcc-13.1:1028:\&\-mloongson\-mmi \-mno\-loongson\-mmi
gcc-13.1:9984:the analyzer detects an attempt to use a
\f(CW\*(C`va_list\*(C'\fR after
gcc-13.1:33575:\& A GNU Manual
gcc-13.1:33581:\& You have freedom to copy and modify this GNU Manual, like
GNU
gcc-13.1:33582:\& software. Copies published by the Free Software
Foundation raise
gcc-13.1:33583:\& funds for GNU development.
-.-.
Use the word (in)valid instead of (il)legal,
if not related to legal matters.
See "www.gnu.org/prep/standards".
Think about translations into other languages!
gcc-13.1:14046:Allow the store merging pass to introduce unaligned stores if it
is legal to
-.-.
Find a repeated word
! 6606 --> from
! 10342 --> be
! 14059 --> to
-.-.
Strings longer than 3/4 of a standard line length (80)
Use "\:" to split the string at the end of an output line, for example a
long URL (web address)
[List of affected lines removed.]
-.-.
Add a "\&" (or a comma (Oxford comma)) after "e.g." and "i.e.",
or use English words
(man-pages(7)).
Abbreviation points should be marked as such and protected against being
interpreted as an end of sentence, if they are not, and that independent
of the current place on the line.
[List of affected lines removed.]
-.-.
Wrong distance (not two spaces) between sentences in the input file.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.
Remember coding: Only one command ("sentence") on each (logical) line.
E-mail: Easier to quote exactly the relevant lines.
Generally: Easier to edit the sentence.
Patches: Less unaffected text.
Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.
The amount of space between sentences in the output can then be
controlled with the ".ss" request.
Mark a final abbreviation point as such by suffixing it with "\&".
Some sentences (etc.) do not begin on a new line.
Split (sometimes) lines after a punctuation mark; before a conjunction.
Lines with only one (or two) space(s) between sentences could be split,
so latter sentences begin on a new line.
Use
#!/usr/bin/sh
sed -e '/^\./n' \
-e 's/\([[
Bug#1095470: amd64-microcode: CVE-2024-56161
Hi Nenrique, On Sat, Mar 08, 2025 at 12:56:25PM -0300, Henrique de Moraes Holschuh wrote: > retitle 1095470 amd64-microcode: CVE-2024-56161 updated AMD-SEV FW needed to > pass attestation > severity 1095470 important > clone 1095470 -1 > tag 1095470 + fixed-upstream > retitle -1 amd64-microcode: CVE-2024-36347 weak microcode update validation > tag -1 = upstream security wontfix > severity -1 important > thanks > > Please let me clarify some details. If this is incorrect, please provide > pointers to the relevant documentation/artifacts: > > There is NO *operating-system-loadable* microcode update available from AMD > to address the root issue (weak microcode validation) at this time. And > public documentation states the root-cause fix must be done through a system > firmware (UEFI) update. > > https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html > > Maybe this will change, and if it doesn't, maybe lesser mitigations (such as > blocking further microcode updates) will become available: I understand > running a minimal kernel-monitor secure hypervisor should be able to block > the MSR writes that trigger a microcode update, for example. > > So, AMD-SB-7033 / CVE-2024-36347 is unactionable by package amd64-microcode > at this time. > > I will clone the bug to split the two CVEs into their own bugs, and tag the > one for CVE-2024-36347 "wontfix" accordingly. I will also downgrade its > severity to "important", since unactionable grave bugs can block actionable > fixes from propagating to testing, etc. Should the situation change > (hopefully it will), we can revisit this. > > > Now, for CVE-2024-56161, which is the AMD-SEV side of the issue. > > There is a pending AMD-SEV loadable firmware update from 2025/02/29, and I > will package it soon (but I'd rather hear back from AMD about a few details, > first). However, I understand from AMD SB-3019 that the SEV firmware update > will just ensure that SEV remote attestation can succeed on updated firmware. > It is relevant for CVE-2024-56161, yes, but it is NOT FIXING the underlying > issue at all. > > https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html > > Note that CVE-2024-56161 is mitigated by ensuring no SEV payload attestation > can succeed on outdated firmware (and you don't need to do anything for THAT: > the SEV payload providers are already on it), and by allowing attestation to > succeed on updated firmware. > > What is missing in Debian is a way for SEV payloads to pass attestation *on > systems with updated firmware*, and THAT is what the pending SEV firmware > update is about. I changed the bug title accordingly. > > Since AMD-SEV is *not* officially supported in Debian anyway, I will > downgrade the SEV bug to severity to important as well. > > More information about AMD-SEV: > https://www.amd.com/en/developer/sev.html Thanks for your analysis, I have tried to reflect the status in the security-tracker for both CVEs now. AFAIU, there are "stop-gap" mitigations in Kernel and Xen as well which are implemnted (and for the kernel they did already land in 6.12.18 and 6.13.6): https://www.openwall.com/lists/oss-security/2025/03/06/3 Regards, Salvatore
Bug#1099755:
08.03.2025 20:15, Andreas Hasenack wrote: What's the scenario where an AD DC server will not have the samba-ad-dc package installed? That package exists since stable. No. In stable, samba-ad-dc was completely optional, - it was just a meta-package depending on all components which are essential for an AD-DC to function (incl. samba-dsdb-modules, winbind, ...). It was a preparation for the actual split which I didn't want to do that late in the release process (bookworm freeze). It was entirely okay to have the same components installed manually without installing samba-ad-dc, and have a working DC, the way it has always been before. Actual move happened in 4.20.1+dfsg-2: samba (2:4.20.1+dfsg-2) unstable; urgency=medium * move many files from samba package to samba-ad-dc package. From now on, samba-ad-dc isn't just a meta-package, it is actually needed for AD-DC functionality. If you run AD-DC, please ensure that samba-ad-dc package is installed (it is not recommended by samba) Closes: #1051770 at which point samba-ad-dc has become mandatory for a DC to function. See d/samba.NEWS file for the details, - it has an entry for this very version. A similar info will be included in trixie release notes. We'll have to live with this for one release, - I'll plan to demote this Recommends to Suggests after the trixie release. Thanks, /mjt
Bug#1099867: Lintian: should source the current Standard from Masters
Control: tags -1 + wontfix On Sun, 2025-03-09 at 09:08 +0200, Martin-Éric Racine wrote: > The newer-standards-version tends to be printed by mistake, usually because > someone upgraded their packaging according to the latest debian-policy before > a new Lintian got uploaded to the repository. What Lintian should instead do > is source the current Standards live from Masters, and only issue the warning > if the declared version is newer than that. src:routine-update already has > the code to perform this. lintian must retain the ability to operate offline, so it has to include debian-policy data. routine-update is different in that it's designed to connect to the internet and fetch a new upstream version, so it might as well also grab the latest policy data while it's at it. The issue here isn't bringing lintian up-to-date (that's easy), it's maintenance. I've requested access to the Salsa repo for lintian so I can work on maintaining it since ~6 weeks ago, and still haven't been given access nor a definitive response. -- Maytham signature.asc Description: This is a digitally signed message part
Bug#1099869: debian-startup.el:1:1: Warning: file has no ‘lexical-binding’ directive on its first line
Package: emacsen-common Version: 3.0.5 Severity: minor File: /usr/share/emacsen-common/debian-startup.el Seen on upgrade: Install emacsen-common for emacs emacsen-common: Handling install of emacsen flavor emacs In toplevel form: usr/share/emacs/site-lisp/debian-startup.el:1:1: Warning: file has no ‘lexical-binding’ directive on its first line
Bug#1099871: chkrootkit: some issues with ifpromisc
Package: chkrootkit
Version: 0.58b-3+b2
Severity: normal
Hi,
when running chkrootkit using `chkrootkit-daily` in diff mode, ifpromisc
sometimes raised an alert because of its output appears in a different order.
To avoid those false alerts, it would be good if the output of `ifpromisc`
would be sorted - at least for the non-EXPERT case.
If I saw it correctly in Debian's git repo, this should be a simple change in
'debian/patches/chkrootkit-sniffer.patch':
--- a/debian/patches/chkrootkit-sniffer.patch
+++ b/debian/patches/chkrootkit-sniffer.patch
@@ -48,10 +48,10 @@ index d1d84e4..9f2d0b4 100755
- [ "${QUIET}" != "t" ] && ./ifpromisc -v || ./ifpromisc -q
+ status=0
+ if [ "${QUIET}" != "t" ]; then
-+ outmsg=$(./ifpromisc -v 2>&1)
++ outmsg=$(./ifpromisc 2>&1 | sort)
+ status=$?
+ else
-+ outmsg=$(./ifpromisc -q 2>&1)
++ outmsg=$(./ifpromisc -q 2>&1 | sort)
+ status=$?
+ fi
+ if [ "$status" = 0 ]; then
In addition I found that the ifpromisc included in chkrootkit supports exactly
oner commandline argument: "-q".
I.e. the calls of ifpromisc with "-v" as commandline argument should be adapted
too.
I stumbled across it when trying to patch the above issue directly in reportbug
where I found the following call in export mode
expertmode_output "./ifpromisc" -v
But `expertmode_output` only takes the first of its parameters into account.
Luckily this does not matter (because of "-v" not being supported by ifpromisc),
but it is very confusing.
The above patch includes thos fix already for the non-EXPERT case.
Thanks for maintaining chkrootkit in Debian!
Peter
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-security'), (500, 'unstable'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages chkrootkit depends on:
ii libc6 2.40-7
Versions of packages chkrootkit recommends:
ii anacron 2.3-42
ii binutils2.44-3
ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1
ii cron [cron-daemon] 3.0pl1-194
ii iproute26.13.0-1
ii net-tools 2.10-1.1
ii postfix [mail-transport-agent] 3.10.1-1
ii procps 2:4.0.4-7
ii systemd-sysv257.3-1
chkrootkit suggests no packages.
-- Configuration Files:
/etc/chkrootkit/chkrootkit.conf changed [not included]
-- no debconf information
Bug#1099119: Confirming the workaround
I encountered the same issue. The workaround describes by Serge works for me.
Bug#1060057: returning to pending CUPS-PDF issue
Hey, As we're approaching the freeze, I'm reviewing pending bugs. I still cannot reproduce this. Btw, the previous bug you referenced was due to CUPS-PDF's outdated Ghostscript recipe. That has been fixed with a patch. The above bug seems to be an entirely different issue. Martin-Éric
Bug#1082544: [Pkg-rust-maintainers] Bug#1082544: rust-tree-sitter: please upgrade to v0.22
Quoting James McCoy (2025-03-08 03:40:45) > On Fri, Jan 24, 2025 at 11:55:58PM +0100, Jonas Smedegaard wrote: > >Quoting Jonas Smedegaard (2025-01-14 22:18:30) > >> Quoting James McCoy (2025-01-14 21:51:13) > >> > On Tue, Jan 14, 2025 at 09:39:45PM +0100, Jonas Smedegaard wrote: > >> > > a) librust-tree-sitter-cli-dev v0.22 does *not* exist > >> > > >> > That was an oversight when collapsing everything into src:tree-sitter. I > >> > didn't realize tree-sitter-cli was also exposed as a library. > >> > > >> > > b) I now bogusly files a bugreport against tree-sitter-cli > >> > > >> > Reassigned to src:tree-sitter. > >> > > >> > > turtlefmt requires crate tree-sitter-generate which I have patched to > >> > > instead require crate tree-sitter-cli, but neither is available with > >> > > crate tree-sitter v0.22 in experimental: t-s-generate is missing and > >> > > t-s-cli depends on older t-s v0.20. > >> > > >> > t-s-generate doesn't exist as a standalone crate until 0.24.3. > >> > >> I suspected that from the version number beginning at 0.24. > >> > >> > I'll fix src:tree-sitter to have a libtree-sitter-cli-dev binary > >> > package. > >> > >> Excellent! > > > >turtlefmt now released for experimental. > > > >None of the packages that I maintain now stops the tree-sitter v0.22 > >crates from entering unstable. > > I'll be uploading tree-sitter to unstable this weekend. Wohoo! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1099325: Emacs 30.1 byte-compilation failures
Hi Sean, Am 6. März 2025 12:49:12 MEZ schrieb Sean Whitton : >I think I have the fix for these problems. >Updating the backport of Emacs to 1:30.1+1-4, and uploading an >NEW, unmodified backport of dh-elpa 2.1.8, should be jointly sufficient. And who is taking action now? Or has this already been taken care of? Kind regards, Micha
Bug#1099798: clisp-module-fastcgi: Consider dropping to get libfcgi out of trixie
Package: clisp-module-fastcgi Severity: important Version: 1:2.49.20241123.git9ff8aed-1 clisp-module-fastcgi makes libfcgi a key package. That has a RC (security) issue that has not been addressed for two months. Please consider dropping clisp-module-fastcgi and its Build-Depends so that libfcgi can move out of testing and not be released with trixie.
Bug#1099781: RFS: runit/2.2.0-1 [RC] -- system-wide service supervision
Hi Phil, thanks for your review! On Sat, 08 Mar 2025 09:35:23 + Phil Wyett wrote: > > Test 3 (build twice): Information only > > debian/rules clean > dh clean --sourcedirectory=runit-2.1.2/src \ shouldn't it be --sourcedirectory=runit-2.2.0/src ? > ./runit_2.1.2.orig.tar.gz dpkg-source: info: using patch list from > debian/patches/series dpkg-source: error: cannot represent change to > runit- 2.1.2/src/t/timestamp/supervise/status: binary file contents > changed dpkg-source: error: add > runit-2.1.2/src/t/timestamp/supervise/status in anyway, there is a race with the test that creates src/t that makes the build fail on alpha, https://buildd.debian.org/status/package.php?p=runit#problem-1 I'll try to fix it in the next upload, maybe is related to your build twice test failure > > autopkgtest: > > The following packages have unmet dependencies: > E: Error, pkgProblemResolver::Resolve generated breaks, this may be > caused by held packages. > runit-init : Conflicts: systemd-sysv but 257.4-1 is to be installed > systemd-sysv : Conflicts: initscripts but 3.14-3 is to be installed > Conflicts: insserv but 1.26.0-1 is to be installed > Recommends: libnss-systemd but it is not installable > autopkgtest [09:17:41]: test init-switch: ---] > autopkgtest [09:17:42]: test init-switch: - - - - - - - - - - > results - - - - > - - - - - - > init-switch FAIL non-zero exit status 100 this one actually passed in the CI for migration https://ci.debian.net/packages/r/runit/testing/amd64/58563396/ I've marked as flaky, I'm not sure what else can be done here Lorenzo
Bug#1099467: Emacs 30.1 byte-compilation failures
On Sat 08 Mar 2025 at 11:47am +01, Micha Lenk wrote: > Hi Sean, > > Am 6. März 2025 12:49:12 MEZ schrieb Sean Whitton : >>I think I have the fix for these problems. >>Updating the backport of Emacs to 1:30.1+1-4, and uploading an >>NEW, unmodified backport of dh-elpa 2.1.8, should be jointly sufficient. > > And who is taking action now? Or has this already been taken care of? I'm waiting for dh-elpa and Emacs to migrate, unless you would allow an exception, so that I can upload immediately? Diffs between testing and sid are tiny: dh-elpa: --8<---cut here---start->8--- diff --git a/debian/control b/debian/control index 9d9d0db..a00bd89 100644 --- a/debian/control +++ b/debian/control @@ -7,7 +7,7 @@ Uploaders: Sean Whitton , Build-Depends: debhelper-compat (= 12), - emacs-nox (>= 47) | emacs (>= 47.0) + emacs-nox (>= 1:30.1) | emacs (>= 1:30.1) Standards-Version: 4.4.1 Vcs-Git: https://salsa.debian.org/emacsen-team/dh-elpa.git Vcs-Browser: https://salsa.debian.org/emacsen-team/dh-elpa --8<---cut here---end--->8--- Emacs: --8<---cut here---start->8--- diff --git a/debian/control b/debian/control index b6e9c094ce6..86cd8976b46 100644 --- a/debian/control +++ b/debian/control @@ -76,7 +76,7 @@ Recommends: fonts-noto-color-emoji Suggests: emacs-common-non-dfsg, emacs-editing-major-modes Conflicts: emacs-gtk, emacs-pgtk, emacs-nox Replaces: emacs-gtk, emacs-pgtk, emacs-nox, emacs-bin-common (<< 1:29.2) -Breaks: emacs-bin-common (<< 1:29.2) +Breaks: emacs-bin-common (<< 1:29.2), dh-elpa-helper (<< 2.1.7) Description: GNU Emacs editor (with Lucid GUI support) GNU Emacs is the extensible self-documenting text editor. This package contains a version of Emacs with support for a graphical user @@ -99,7 +99,7 @@ Provides: editor, emacs, emacsen, info-browser, mail-reader, news-reader Suggests: emacs-common-non-dfsg, emacs-editing-major-modes Conflicts: emacs-gtk, emacs-pgtk, emacs-lucid Replaces: emacs-gtk, emacs-pgtk, emacs-lucid, emacs-bin-common (<< 1:29.2) -Breaks: emacs-bin-common (<< 1:29.2) +Breaks: emacs-bin-common (<< 1:29.2), dh-elpa-helper (<< 2.1.7) Description: GNU Emacs editor (without GUI support) GNU Emacs is the extensible self-documenting text editor. This package contains a version of Emacs compiled without support for X, @@ -117,7 +117,7 @@ Recommends: fonts-noto-color-emoji Suggests: emacs-common-non-dfsg, emacs-editing-major-modes Conflicts: emacs-pgtk, emacs-lucid, emacs-nox Replaces: emacs-pgtk, emacs-lucid, emacs-nox, emacs-bin-common (<< 1:29.2) -Breaks: emacs-bin-common (<< 1:29.2) +Breaks: emacs-bin-common (<< 1:29.2), dh-elpa-helper (<< 2.1.7) Description: GNU Emacs editor (with GTK+ GUI support) GNU Emacs is the extensible self-documenting text editor. This package contains a version of Emacs with a graphical user interface @@ -146,6 +146,7 @@ Replaces: Breaks: emacs-bin-common (<< 1:29.2), emacs-common (<< 1:29.3+1-3~), + dh-elpa-helper (<< 2.1.7) Description: GNU Emacs editor (with GTK+ Wayland GUI support) GNU Emacs is the extensible self-documenting text editor. This package contains a version of Emacs with a graphical user interface --8<---cut here---end--->8--- -- Sean Whitton
Bug#1099804: mdadm: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: mdadm Tags: l10n patch Severity: wishlist Hello, Could you please update the Brazilian Portuguese translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and tested with msgfmt and podebconf-display-po. Kind regards. pt_BR.po.gz Description: application/gzip signature.asc Description: PGP signature
Bug#1099807: tmpreaper: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: tmpreaper Tags: l10n patch Severity: wishlist Hello, Could you please update the Brazilian Portuguese translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and tested with msgfmt and podebconf-display-po. Kind regards. pt_BR.po.gz Description: application/gzip signature.asc Description: PGP signature
Bug#1099808: ITP: golang-github-jesseduffield-gocui -- minimalist console user interfaces Go library
Package: wnpp Severity: wishlist Owner: Jongmin Kim X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-jesseduffield-gocui Version : 0.4+git20250220.b376cb0 Upstream Contact: Jesse Duffield * URL : https://github.com/jesseduffield/gocui * License : BSD-3-clause Programming Lang: Go Description : minimalist console user interfaces Go library This package provides the minimalist Go package aimed at creating the Console User Interfaces. . Following features are available: * Minimalist API * Views (the "windows" in the GUI) implement the interface io.ReadWriter * Support for overlapping views * The GUI can be modified at runtime (concurrent-safe) * Global and view-level keybindings. * Mouse support * Colored text * Customizable edition mode * Easy to build reusable widgets, complex layouts This package was REMOVED[1], but it need to be packaged again for lazygit/0.48.0[2,3]. [1] https://bugs.debian.org/1081322 [2] https://bugs.debian.org/908894 [3] https://lists.debian.org/debian-go/2025/03/msg00041.html This package is a fork of golang-github-jroimartin-gocui. However, due to significant differences[4], the original can no longer be used for lazygit. This fork is actively maintained[5], so I will reintroduce it into Debian. [4] https://github.com/jroimartin/gocui/compare/master...jesseduffield:gocui:master [5] https://github.com/jesseduffield/gocui/commits/master
Bug#1099806: mysql-8.0: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: mysql-8.0 Tags: l10n patch Severity: wishlist Hello, Could you please update the Brazilian Portuguese translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and tested with msgfmt and podebconf-display-po. Kind regards. pt_BR.po.gz Description: application/gzip signature.asc Description: PGP signature
Bug#1095470: amd64-microcode: CVE-2024-56161
On Thu, Mar 6, 2025, at 07:59, Christian Kastner wrote: > Control: severity -1 grave I will keep this open for a little while, and try to ask AMD about it directly, but expect either bad news, or extremely bad news for anyone that is not in a position to get a new firmware from their vendor or from a third-party (or build a new one themselves by replacing the AMD PI / AGESA with updated ones). -- Henrique de Moraes Holschuh
Bug#1099822: gnome-system-tools: please migrate away from /usr/share/cdbs/1/class/gnome.mk
Source: gnome-system-tools Version: 3.0.0-11 Severity: important Dear Maintainer, CDBS is a deprecated, unmaitained, build-systemd. There are only 3 users left of the /usr/share/cdbs/1/class/gnome.mk. We would like this module pruned from CDBS. Please consider switching to DebHelper sequencer. Greetings Alexandre Detiste
Bug#1099823: libglade2: please migrate away from /usr/share/cdbs/1/class/gnome.mk
Source: libglade2 Version: 1:2.6.4-2.4 Severity: serious Dear Maintainer, CDBS is a deprecated, unmaitained, build-systemd. There are only 3 users left of the /usr/share/cdbs/1/class/gnome.mk. We would like this module pruned from CDBS. Please consider switching to DebHelper sequencer. It looks like LibGlade2 is there to stay a little longuer. Greetings Alexandr
Bug#1099814: bookworm-pu: package intel-microcode/3.20250211.1~deb12u1
Control: tags -1 + confirmed On Sat, 2025-03-08 at 09:57 -0300, Henrique de Moraes Holschuh wrote: > As requested by the security team, I would like to bring the > microcode update level for Intel processors in Bookworm to match what > we have in Sid and Trixie. Please go ahead, bearing in mind that the window for getting updates into 12.10 closes this weekend. Regards, Adam
Bug#1099827: gnuplot: command line options -rv and -geometry are unrecognized
Package: gnuplot Version: 6.0.2+dfsg1-1 Severity: important Dear Maintainer, This is possibly introduced with version 6, but I can find no change in the documentation indicating these options are no longer supported. They work as documented as of 5.4.4+dfsg1-2 at least. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-18-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages gnuplot depends on: ii gnuplot-x11 [gnuplot-nox] 6.0.2+dfsg1-1 gnuplot recommends no packages. Versions of packages gnuplot suggests: pn gnuplot-doc -- no debconf information
Bug#1099826: FTBFS: error: ‘void QCheckBox::stateChanged(int)’ is deprecated
Source: obs-ashmanix-countdown Version: 1.2.0-2 Severity: serious Tags: ftbfs upstream Justification: FTBFS X-Debbugs-Cc: theashma...@gmail.com, em...@ashmanix.com The package FTBFS (fails to build from source). See below. [ 90%] Building CXX object CMakeFiles/ashmanix-countdown.dir/src/utils/obs-utils.cpp.o /usr/bin/c++ -DHAVE_OBSCONFIG_H -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DSIMDE_ENABLE_OPENMP -Dashmanix_countdown_EXPORTS -I/PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/obj-x86_64-linux-gnu -I/PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown -I/PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/obj-x86_64-linux-gnu/ashmanix-countdown_autogen/include -I/PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/lib -I/PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/src -isystem /usr/include/obs -isystem /usr/include/x86_64-linux-gnu/qt6/QtCore -isystem /usr/include/x86_64-linux-gnu/qt6 -isystem /usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ -isystem /usr/include/x86_64-linux-gnu/qt6/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt6/QtGui -g -O2 -ffile-prefix-map=/PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fdiagnostics-color=always -fopenmp-simd -fno-strict-aliasing -Wdeprecated-declarations -Wempty-body -Wenum-conversion -Werror=return-type -Wextra -Wformat -Wformat-security -Wno-conversion -Wno-float-conversion -Wno-implicit-fallthrough -Wno-missing-braces -Wno-missing-field-initializers -Wno-shadow -Wno-sign-conversion -Wno-trigraphs -Wno-unknown-pragmas -Wno-unused-function -Wno-unused-label -Wparentheses -Wshadow -Wuninitialized -Wunreachable-code -Wunused-parameter -Wunused-value -Wunused-variable -Wvla -Wconversion -Wfloat-conversion -Winvalid-offsetof -Wno-overloaded-virtual -Wno-error=maybe-uninitialized -Winfinite-recursion -mmmx -msse -msse2 -Werror -MD -MT CMakeFiles/ashmanix-countdown.dir/src/utils/obs-utils.cpp.o -MF CMakeFiles/ashmanix-countdown.dir/src/utils/obs-utils.cpp.o.d -o CMakeFiles/ashmanix-countdown.dir/src/utils/obs-utils.cpp.o -c /PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/src/utils/obs-utils.cpp /PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/src/widgets/settings-dialog.cpp: In member function ‘void SettingsDialog::ConnectUISignalHandlers()’: /PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/src/widgets/settings-dialog.cpp:135:70: error: ‘void QCheckBox::stateChanged(int)’ is deprecated: Use checkStateChanged() instead [-Werror=deprecated-declarations] 135 | QObject::connect(ui->startOnStreamStartCheckBox, &QCheckBox::stateChanged, this, | ^~~~ In file included from /usr/include/x86_64-linux-gnu/qt6/QtWidgets/QCheckBox:1, from /PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/obj-x86_64-linux-gnu/ashmanix-countdown_autogen/include/../ui/ui_SettingsDialog.h:15, from /PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/src/widgets/settings-dialog.hpp:14, from /PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/src/widgets/settings-dialog.cpp:1: /usr/include/x86_64-linux-gnu/qt6/QtWidgets/qcheckbox.h:41:10: note: declared here 41 | void stateChanged(int); | ^~~~ /PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/src/widgets/settings-dialog.cpp:138:63: error: ‘void QCheckBox::stateChanged(int)’ is deprecated: Use checkStateChanged() instead [-Werror=deprecated-declarations] 138 | QObject::connect(ui->switchSceneCheckBox, &QCheckBox::stateChanged, this, | ^~~~ /usr/include/x86_64-linux-gnu/qt6/QtWidgets/qcheckbox.h:41:10: note: declared here 41 | void stateChanged(int); | ^~~~ /PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/src/widgets/settings-dialog.cpp:144:62: error: ‘void QCheckBox::stateChanged(int)’ is deprecated: Use checkStateChanged() instead [-Werror=deprecated-declarations] 144 | QObject::connect(ui->endMessageCheckBox, &QCheckBox::stateChanged, this, | ^~~~ /usr/include/x86_64-linux-gnu/qt6/QtWidgets/qcheckbox.h:41:10: note: declared here 41 | void stateChanged(int); | ^~~~ /PKGS/obs-ashmanix-countdown/obs-ashmanix-countdown/src/widgets/settings-dialog.cpp:147:64: error: ‘void QCheckBox::stateChanged(int)’ is deprecated: Use checkStateChanged() instead [-Werror=deprecated-declarations] 147 | QObject::connect(ui->formatOutputCheckBox, &QCheckBox::stateChanged, this, | ^~~~ /usr/include/
Bug#1099814: bookworm-pu: package intel-microcode/3.20250211.1~deb12u1
The upload got into the proposed-updates queue a few moments ago. Thank you! -- Henrique de Moraes Holschuh
