Bug#1040452: libc6: upgrading libc6 to version 2.37-3 break almost every program (especially in a shell)
Hey Aurelien, Aurelien Jarno wrote on 06.07.23 21:43: Hi, On 2023-07-06 08:14, Kai Wasserbäch wrote: OK, downgrading from the broken system state didn't work either and left me with a lot of segfaulting programs. In the end it seems that 2.73-3 isn't really broken, but the update process is somehow. After I went to a rescue system and redid the update from there, everything worked out. Now 2.73-3 is working here as well. In the rescue system environment the post-install scripts ran successfully. This looks very strange that downgrading and re-upgrading fixes the issue. Did the initial upgrade finished properly? You might want to look for issues in /var/log/dpkg.log or /var/log/apt/term.log. the logs I can only check on Monday, but as I've written in my first e-mail: the post-install scripts failed with segmentation faults. And the re-upgrade only succeeded from a rescue environment (with its own, working libc). Cheers, Kai OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1040452: libc6: upgrading libc6 to version 2.37-3 break almost every program (especially in a shell)
Hi,
same here. I have the full log of apt upgrade:
... skipping the initial part without errors ...
Running mktexlsr. This may take some time... done.
/usr/sbin/update-fmtutil: line 213: 93596 Segmentation fault find
"$SNIPPET_BASE/$tree" -maxdepth 1 -type f -name '*'$EXT -exec cat '{}'
\; >> "$tempfile"
dpkg: error processing package tex-common (--configure):
installed tex-common package post-installation script subprocess
returned error exit status 139
Processing triggers for dbus (1.14.8-1) ...
Processing triggers for shared-mime-info (2.2-1) ...
Processing triggers for ca-certificates-java (20230620) ...
done.
Processing triggers for install-info (6.8-6+b1) ...
Processing triggers for mailcap (3.70+nmu1) ...
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.3.0-2-amd64
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
awk: cmd. line:3: fatal error: internal error: segfault
awk: cmd. line:3: fatal error: internal error: segfault
Segmentation fault
Segmentation fault
E: /usr/share/initramfs-tools/hooks/udev failed with return 139.
update-initramfs: failed for /boot/initrd.img-6.3.0-2-amd64 with 139.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess
returned error exit status 139
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for gnome-menus (3.36.0-1.1) ...
Processing triggers for libglib2.0-0:amd64 (2.74.6-2) ...
Setting up openjdk-17-jre:amd64 (17.0.8~6-3) ...
Processing triggers for libc-bin (2.37-3) ...
Processing triggers for ccache (4.8+really4.7.5-1) ...
Updating symlinks in /usr/lib/ccache ...
Setting up openjdk-11-jre:amd64 (11.0.20~7-1) ...
Setting up openjdk-17-jdk-headless:amd64 (17.0.8~6-3) ...
Setting up libedataserver-1.2-27:amd64 (3.48.4-1) ...
Setting up libecal-2.0-2:amd64 (3.48.4-1) ...
Setting up libedataserverui4-1.0-0:amd64 (3.48.4-1) ...
Setting up libebook-contacts-1.2-4:amd64 (3.48.4-1) ...
Setting up openjdk-17-jdk:amd64 (17.0.8~6-3) ...
Setting up gir1.2-edataserver-1.2:amd64 (3.48.4-1) ...
Setting up libedataserverui-1.2-4:amd64 (3.48.4-1) ...
Setting up libebackend-1.2-11:amd64 (3.48.4-1) ...
Setting up libedata-cal-2.0-2:amd64 (3.48.4-1) ...
Setting up gir1.2-ecal-2.0:amd64 (3.48.4-1) ...
Setting up libedata-book-1.2-27:amd64 (3.48.4-1) ...
Setting up libebook-1.2-21:amd64 (3.48.4-1) ...
Setting up libevolution (3.48.4-1) ...
Setting up evolution-data-server (3.48.4-1) ...
Setting up evolution (3.48.4-1) ...
Setting up evolution-plugins (3.48.4-1) ...
Setting up evolution-plugin-bogofilter (3.48.4-1) ...
Setting up evolution-plugin-pstimport (3.48.4-1) ...
Processing triggers for libvlc-bin:amd64 (3.0.18-3) ...
Segmentation fault
dpkg: error processing package libvlc-bin:amd64 (--configure):
installed libvlc-bin:amd64 package post-installation script subprocess
returned error exit status 139
Processing triggers for libc-bin (2.37-3) ...
Errors were encountered while processing:
tex-common
initramfs-tools
libvlc-bin:amd64
Log ended: 2023-07-06 15:22:25
In my case I cannot use apt or apt-get anymore. This is the journalctl
log when using apt:
Jul 07 06:59:22 debian kernel: apt[111774]: segfault at 7fe480492006 ip
7fe47fd2af36 sp 7ffdd53c6398 error 4 in
libc.so.6[7fe47fc44000+155000] likely on CPU 0 (core 0, socket 0)
Cheers
Matteo
On Thu, 6 Jul 2023 21:43:32 +0200 Aurelien Jarno
wrote:
Hi,
On 2023-07-06 08:14, Kai Wasserbäch wrote:
> OK, downgrading from the broken system state didn't work either and left me
> with a lot of segfaulting programs. In the end it seems that 2.73-3 isn't
> really broken, but the update process is somehow. After I went to a rescue
> system and redid the update from there, everything worked out. Now 2.73-3 is
> working here as well. In the rescue system environment the post-install
> scripts ran successfully.
This looks very strange that downgrading and re-upgrading fixes the
issue. Did the initial upgrade finished properly? You might want to look
for issues in /var/log/dpkg.log or /var/log/apt/term.log.
> In case it matters: I made the initial update with aptitude in my graphical
> session (KDE on X11).
It should not matter how the upgrade is performed, and in any case
doesn't explain why your tests on tty2 and tty3 are also affected.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
Bug#1040514: rust-markdown: panicks when no arguments provided
Package: rust-markdown Version: 0.3.0-1+b5 Severity: normal Dear Maintainer, $ rust-markdown ["rust-markdown"] thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', src/main.rs:9:27 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace also no manual so idk why -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rust-markdown depends on: ii libc6 2.36-9 ii libgcc-s1 12.2.0-14 rust-markdown recommends no packages. rust-markdown suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1040513: wireplumber: non-installable due to hardcoded Depends: dbus-user-session
Package: wireplumber Version: 0.4.14-3 Severity: grave Hi! In version 0.4.14-3, you added a hard dependency on a specific session model of dbus, rather than the virtual package defined by the Policy (dbus-session-bus). This makes it non-installable on any box where a dependency of that package is non-functional or unwanted. As of policy 4.3.0, the expected dependency is: default-dbus-session-bus | dbus-session-bus We have two implementations of in Debian: * dbus-user-session: + works with wayland - no multiseat support - requires systemd * dbus-x11 - requires x11 + allows multiple sessions + portable even to non-linux I confirm that, as of 0.4.14-2 wireplumber works well with dbus-x11, and earlier versions did so for quite a while too. Meow! -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.2-00035-g5920c330f094 (SMP w/64 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages wireplumber depends on: ii init-system-helpers 1.65.2 ii libc6 2.37-4 ii libglib2.0-0 2.74.6-2 ii libpipewire-0.3-0 0.3.73-1 ii libwireplumber-0.4-0 0.4.14-2 ii pipewire 0.3.73-1 Versions of packages wireplumber recommends: ii pipewire-pulse 0.3.73-1 Versions of packages wireplumber suggests: pn libspa-0.2-bluetooth pn wireplumber-doc -- no debconf information
Bug#1036712: Replaces without Breaks or Conflicts harmful?
Hi Thorsten,
On Thu, Jul 06, 2023 at 05:26:43PM +, Thorsten Glaser wrote:
> Helmut Grohne dixit:
>
> > openjdk-8 (U)
>
> Should be convered by the Depends lines in the respective
> binary packages, e.g:
>
> Depends: openjdk-8-jre (>= ${source:Version}),
> openjdk-8-jdk (>= ${binary:Version}),
> ${misc:Depends}
> Replaces: openjdk-8-jdk (<< 8u20~b26-1~)
Yes, this is the kind of fpos I was mentioning as expected.
> > rng-tools-debian
>
> Also false positive:
>
> Replaces: intel-rng-tools, rng-tools
> Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate)
> Conflicts: intel-rng-tools
This is *not* a false positive, but a real issue. It replaces any
rng-tools, but breaks only a subset. This would have to be fixed to
either drop the version constraint from Breaks (probably wrong) or add
it to Replaces. Can you handle that?
Helmut
Bug#1040501: mrtg: [INTL:nl] Dutch translation of debconf templates
Em qui., 6 de jul. de 2023 às 17:24, Frans Spiesschaert escreveu: > > > > Package: mrtg > Severity: wishlist > Tags: l10n patch > > > > Dear Maintainer, > > > Please find attached the updated Dutch translation of mrtg debconf > messages. A draft has been posted to the debian-l10n-dutch mailing list > allowing for review. > Please add it to your next package revision. > It should be put as debian/po/nl.po in your package build tree. > > > -- > Kind regards, > Frans Spiesschaert Thanks Frans. I just sent it to Salsa. Regards, Eriberto
Bug#455854: evince: bad text selection behaviour - characters clipped and text overwritten
Control: fixed -1 43.1-3 On Thu, 2023-07-06 at 11:20 +0200, Sune Stolborg Vuorela wrote: > Fixed long ago upstream Confirmed, marking as fixed in the current version. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1040510: mrtg: [INTL:fr] French templates translation
Em qui., 6 de jul. de 2023 às 19:57, Jean-Pierre Giraud escreveu: > > Package: mrtg > Severity: wishlist > Tags: patch l10n > > Hi! > > Please find attached the french templates translation updated, > proofread by the debian-l10n-french mailing list contributors. > > This file should be put as debian/po/fr.po in your package build tree. > > Kind Regards > > Jean-Pierre Giraud Thanks Jean-Pierre. I just sent this translation to Salsa. Regards, Eriberto
Bug#1040512: javatools: Please support Java 21
Package: javatools
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
X-Debbugs-Cc: vladimir.pe...@canonical.com
Dear Maintainer,
Java 21 retires release level 7 and requires release level 8. This patch allows
to set release level to 8 if Java is 21 or later.
Changes:
* jh_build: check Java version to set the minimum release level.
* d/control: javahelper now depends on jarwrapper to check Java version.
* d/rules: use release level 8.
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers lunar-updates
APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'),
(100, 'lunar-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.2.0-24-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru javatools-0.78/debian/control javatools-0.78ubuntu1/debian/control
--- javatools-0.78/debian/control 2021-02-05 00:05:53.0 +1300
+++ javatools-0.78ubuntu1/debian/control2023-05-04 19:27:54.0
+1200
@@ -36,6 +36,7 @@
Package: javahelper
Architecture: all
Depends:
+ jarwrapper,
bsdextrautils | bsdmainutils,
dctrl-tools,
debhelper-compat (= 13),
diff -Nru javatools-0.78/debian/rules javatools-0.78ubuntu1/debian/rules
--- javatools-0.78/debian/rules 2021-02-05 00:05:53.0 +1300
+++ javatools-0.78ubuntu1/debian/rules 2023-05-04 19:27:54.0 +1200
@@ -14,7 +14,7 @@
override_dh_auto_build: jh_lib.sh
mkdir -p target/classes
- javac -d target/classes -source 7 -target 7
src/main/java/org/debian/javatools/CheckProperty.java
+ javac -d target/classes -source 8 -target 8
src/main/java/org/debian/javatools/*.java
jar -cvf target/javatools.jar -C target/classes/ .
mkdir tmp tmp.jarwrapper
diff -Nru javatools-0.78/jh_build javatools-0.78ubuntu1/jh_build
--- javatools-0.78/jh_build 2021-02-05 00:07:26.0 +1300
+++ javatools-0.78ubuntu1/jh_build 2023-05-04 19:27:54.0 +1200
@@ -10,9 +10,7 @@
use warnings;
use Cwd qw(realpath);
use List::Util qw(any);
-
-# Value to pass to -source/-target by default
-use constant DEFAULT_JAVA_RELEASE => '1.7';
+use File::Temp qw(tempfile);
use Debian::Debhelper::Dh_Lib;
use Debian::Javahelper::Java qw(write_manifest_fd);
@@ -115,7 +113,7 @@
my @JH_JAR_EXTRA;
my $build_javadoc = 1;
my (@javac_opts, @javadoc_opts, $main_class, $do_clean);
-my (@JAVAC, @JAVADOC, @JAR, @builds);
+my (@JAVAC, @JAVA, @JAVADOC, @JAR, @builds);
$CLASSPATH =~ tr/:/ /;
@JH_JAR_EXTRA = split(' ', $ENV{'JH_JAR_EXTRA'}) if defined
$ENV{'JH_JAR_EXTRA'};
@@ -150,6 +148,17 @@
exit(0);
}
+# Value to pass to -source/-target by default
+sub get_min_release {
+ if (doit_noerror(@JAVA, "-cp", "/usr/share/java/javatools.jar",
"org.debian.javatools.CheckIntProperty", "java.specification.version", "gte",
"21")) {
+ warning('Java machine does not support --release 7, using
--release 8');
+ return "8";
+ }
+ # when the specification version is less than 21 or an error occured
+ # default to 7
+ return "7";
+}
+
sub _has_java_option {
my ($opt_ref, $option_name) = @_;
for my $arg (@{$opt_ref}) {
@@ -171,27 +180,6 @@
return;
}
-# Use ISO8859-1 as the default encoding to avoid unmappable character errors
-_default_java_option(\@javac_opts, '-encoding', 'ISO8859-1');
-_default_java_option(\@javadoc_opts, '-encoding', 'ISO8859-1');
-
-if (not _has_java_option(\@javac_opts, '--release') and not
_has_java_option(\@javac_opts, '-source')) {
- # If neither --release nor -source is set, then set -source (and
-target if also absent)
- if (not _has_java_option(\@javac_opts, '-target')) {
- push(@javac_opts, '-source', DEFAULT_JAVA_RELEASE, '-target',
DEFAULT_JAVA_RELEASE);
- } else {
- push(@javac_opts, '-source', DEFAULT_JAVA_RELEASE);
- }
-}
-
-if (not _has_java_option(\@javadoc_opts, '--release')) {
- _default_java_option(\@javadoc_opts, '-source', DEFAULT_JAVA_RELEASE);
-}
-
-_default_java_option(\@javadoc_opts, '-notimestamp');
-_default_java_option(\@javadoc_opts, '-Xdoclint:none');
-
-
sub do_build {
my ($jarfile, @sources) = @_;
my (@srcdirs, @srcfiles);
@@ -275,8 +263,33 @@
error('Cannot find any JAVA_HOME: aborting');
}
@JAVAC = ("${JAVA_HOME}/bin/javac");
+ @JAVA = ("${JAVA_HOME}/bin/java");
+
@JAVADOC = ("${JAVA_HOME}/bin/javadoc", '-locale', 'en_US');
@JAR = ("${JAVA_HOME}/bin/jar");
+
+ my $default_java_release = get_min_release();
+
+ # Use ISO8859-1 as
Bug#1040329: postfix set-permissions is broken in bookworm and up
On Wed, 05 Jul 2023 17:55:23 -0400 Scott Kitterman wrote: > > Proposed stable update for bookworm in progress. You can follow its status in > bug #1040435. > > Scott K I tested your debdiff from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040435 bookworm2.debdiff upon the pending stable-update and it fixes "postfix set-permissions" fine on stable arm64. Cheers, Alban
Bug#1018212: libspnav: diff for NMU version 1.0-1.1
Control: tags 1018212 + patch Control: tags 1018212 + pending X-Debbugs-CC: moel...@debian.org rodol...@damsy.net Dear maintainer, I've prepared an NMU for libspnav (versioned as 1.0-1.1) and uploaded it to DELAYED/14. Please feel free to tell me if I should delay it longer. Regards. diff -Nru libspnav-1.0/debian/changelog libspnav-1.0/debian/changelog --- libspnav-1.0/debian/changelog 2022-08-21 12:31:36.0 -0400 +++ libspnav-1.0/debian/changelog 2023-07-06 20:42:15.0 -0400 @@ -1,3 +1,17 @@ +libspnav (1.0-1.1) unstable; urgency=medium + + * Non-maintainer upload. + + [ Steffen Moeller ] + * Added team as maintainer. + * Added myself as an uploader. + + [ Boyuan Yang ] + * debian/patches/0003-Makefile.in-Also-link-math-library-lm.patch: +Add missing link to libm library. (Closes: #1018212) + + -- Boyuan Yang Thu, 06 Jul 2023 20:42:15 -0400 + libspnav (1.0-1) unstable; urgency=medium * Introduced Team upload next to FreeCAD with the Science-Team. diff -Nru libspnav-1.0/debian/control libspnav-1.0/debian/control --- libspnav-1.0/debian/control 2022-08-21 12:31:36.0 -0400 +++ libspnav-1.0/debian/control 2023-07-06 20:36:39.0 -0400 @@ -1,7 +1,8 @@ Source: libspnav Section: libs Priority: optional -Maintainer: Rodolphe PELLOUX-PRAYER +Maintainer: Debian Science Team +Uploaders: Steffen Moeller , Rodolphe PELLOUX-PRAYER Build-Depends: debhelper-compat (= 13), libx11-dev Standards-Version: 4.6.1 Homepage: http://spacenav.sourceforge.net diff -Nru libspnav-1.0/debian/patches/0003-Makefile.in-Also-link-math-library- lm.patch libspnav-1.0/debian/patches/0003-Makefile.in-Also-link-math-library- lm.patch --- libspnav-1.0/debian/patches/0003-Makefile.in-Also-link-math-library- lm.patch1969-12-31 19:00:00.0 -0500 +++ libspnav-1.0/debian/patches/0003-Makefile.in-Also-link-math-library- lm.patch2023-07-06 20:41:02.0 -0400 @@ -0,0 +1,22 @@ +From: Boyuan Yang +Date: Thu, 6 Jul 2023 20:40:13 -0400 +Subject: Makefile.in: Also link math library -lm + +Bug-Debian: https://bugs.debian.org/1018212 +--- + Makefile.in | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/Makefile.in b/Makefile.in +index f86a50c..2bfaec6 100644 +--- a/Makefile.in b/Makefile.in +@@ -11,7 +11,7 @@ libpaths = -L/usr/local/lib -L/usr/X11R6/lib + CC ?= gcc + AR ?= ar + CFLAGS = $(opt) $(dbg) -std=c89 $(pic) -pedantic -Wall -fno-strict-aliasing $(incpaths) $(user_cflags) `dpkg-buildflags --get CFLAGS` `dpkg-buildflags -- get CPPFLAGS` +-LDFLAGS = $(libpaths) $(user_ldflags) $(xlib) `dpkg-buildflags --get LDFLAGS` ++LDFLAGS = $(libpaths) $(user_ldflags) $(xlib) -lm `dpkg-buildflags --get LDFLAGS` + + ifeq ($(shell uname -s), Darwin) + lib_so = libspnav.dylib diff -Nru libspnav-1.0/debian/patches/series libspnav- 1.0/debian/patches/series --- libspnav-1.0/debian/patches/series 2022-08-21 12:27:04.0 -0400 +++ libspnav-1.0/debian/patches/series 2023-07-06 20:41:02.0 -0400 @@ -1,2 +1,3 @@ ldconfig-symlink-referencing-wrong-file.patch add-buildflags-to-makefile.patch +0003-Makefile.in-Also-link-math-library-lm.patch signature.asc Description: This is a digitally signed message part
Bug#1040309: Packaged but no reason to upload
Control: unblock 861615 by -1 Hello, This RFP was created so I could package this library for use in prismlauncher, but prismlauncher uses its own incompatible fork. To find this out, though, I did package this library [1], so anyone else who has a use for it can upload and maintain the package. -- Ben Westover [1] https://salsa.debian.org/BenTheTechGuy/libnbtplusplus2 OpenPGP_signature Description: PGP signature
Bug#1022747: RFS: prismlauncher/5.0+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts
Control: tags -1 - moreinfo Hello, On 7/6/23 5:59 AM, Bastian Germann wrote: > I did not recognize that prismlauncher uses a fork. If you cannot make > up for that by including some of the fork's patches, please keep the > library copy in prismlauncher. I will do the latter. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1040511: packagekit: DBUS policy is installed in /etc instead of /usr
Package: packagekit Version: 1.2.6-5 Tags: patch Dear packagekit maintainers, packagekit installs the `org.freedesktop.PackageKit.conf` policy in `/etc/dbus-1`. Since Debian 9 the standard directory for package-installed dbus policies is `/usr/share/dbus-1`. See: https://bugs.debian.org/1006631 Lintian complains with `dbus-policy-in-etc`. A patch to fix this issue is available at https://salsa.debian.org/pkgutopia-team/packagekit/-/merge_requests/6 Regards, -- Gioele Barabucci
Bug#1035881: linux-image-6.3.0-0-amd64: 6.3.0 freezes shrtly after boot
Package: src:linux Version: 6.3.7-1 Followup-For: Bug #1035881 Dear Maintainer, I can second this. My machine's an old Thinkpad T410. I use root encryption. System boots from a (not encrypted) /boot partition and hangs after loading the initramfs. In my case, my screen turns black before entering the passphrase to unlock my ssd. I use Intel-graphics, too. Could this be the point? ** Model information sys_vendor: LENOVO product_name: 2537DN3 product_version: ThinkPad T410 chassis_vendor: LENOVO chassis_version: Not Available bios_vendor: LENOVO bios_version: 6IET76WW (1.36 ) board_vendor: LENOVO board_name: 2537DN3 board_version: Not Available ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 02) Subsystem: Lenovo Core Processor DRAM Controller [17aa:2193] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Capabilities: 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Lenovo Core Processor Integrated Graphics Controller [17aa:215a] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Interrupt: pin A routed to IRQ 26 Region 0: Memory at f200 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at d000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 1800 [size=8] Expansion ROM at 000c [virtual] [disabled] [size=128K] Capabilities: Kernel driver in use: i915 Kernel modules: i915 00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series Chipset HECI Controller [8086:3b64] (rev 06) Subsystem: Lenovo 5 Series/3400 Series Chipset HECI Controller [17aa:215f] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Interrupt: pin A routed to IRQ 27 Region 0: Memory at f2827800 (64-bit, non-prefetchable) [size=16] Capabilities: Kernel driver in use: mei_me Kernel modules: mei_me 00:16.3 Serial controller [0700]: Intel Corporation 5 Series/3400 Series Chipset KT Controller [8086:3b67] (rev 06) (prog-if 02 [16550]) Subsystem: Lenovo 5 Series/3400 Series Chipset KT Controller [17aa:2162] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Interrupt: pin B routed to IRQ 17 Region 0: I/O ports at 1808 [size=8] Region 1: Memory at f2624000 (32-bit, non-prefetchable) [size=4K] Capabilities: Kernel driver in use: serial 00:19.0 Ethernet controller [0200]: Intel Corporation 82577LM Gigabit Network Connection [8086:10ea] (rev 06) Subsystem: Lenovo 82577LM Gigabit Network Connection [17aa:2153] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Interrupt: pin A routed to IRQ 24 Region 0: Memory at f260 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at f2625000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 1820 [size=32] Capabilities: Kernel driver in use: e1000e Kernel modules: e1000e 00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 06) (prog-if 20 [EHCI]) Subsystem: Lenovo 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [17aa:2163] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0 Interrupt: pin D routed to IRQ 23 Region 0: Memory at f2828000 (32-bit, non-prefetchable) [size=1K] Capabilities: Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] (rev 06) Subsystem: Lenovo 5 Series/3400 Series Chipset High Definition Audio [17aa:215e] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 29 Region 0: Memory at f262 (64-bit, non-prefetchable) [size=16K] Capabilities: Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 [8086:3b42] (rev 06) (prog-if 00 [Normal decode]) Subsystem: Lenovo 5 Series/3400 Series Chipset PCI Express Root Port 1 [17aa:2164] Control: I/O+ Mem+ BusMaster+
Bug#1040510: mrtg: [INTL:fr] French templates translation
Package: mrtg Severity: wishlist Tags: patch l10n Hi! Please find attached the french templates translation updated, proofread by the debian-l10n-french mailing list contributors. This file should be put as debian/po/fr.po in your package build tree. Kind Regards Jean-Pierre Giraud fr.po.xz Description: application/xz signature.asc Description: This is a digitally signed message part
Bug#1003865: GPG error: http://deb.debian.org/debian sid InRelease: The following signatures were invalid: BADSIG 648ACFD622F3D138 Debian Archive Automatic Signing Key (10/buster)
Adding more data... I have been seeing this on bookworm (both the machine running "apt update" and the machine running apt-cacher-ng): W: GPG error: http://deb.debian.org/debian bookworm-updates InRelease: The following signatures were invalid: BADSIG 0E98404D386FA1D9 Debian Archive Automatic Signing Key (11/bullseye) E: The repository 'http://deb.debian.org/debian bookworm-updates InRelease' is not signed. On Fri, 28 Jan 2022 20:45:00 +0530 Pirate Praveen wrote: > I have seen this on another sid chroot. So I had to remove > /var/lib/apt/* inside the chroot and debrepo/dists directory in > apt-cacher-ng's cache directory. I'm not sure if it can be fixed in > apt-cacher-ng. The above workaround has fixed it for me... for now. peace & happiness, martin
Bug#1040509: realmd: DBUS policy is installed in /etc instead of /usr
Package: realmd Version: 0.17.1-1 Tags: patch Dear realmd maintainers, realmd installs the `org.freedesktop.realmd.conf` policy in `/etc/dbus-1`. Since Debian 9 the standard directory for package-installed dbus policies is `/usr/share/dbus-1`. See: https://bugs.debian.org/1006631 Lintian complains with `dbus-policy-in-etc`. A patch to fix this issue is available at https://salsa.debian.org/utopia-team/realmd/-/merge_requests/3 Regards, -- Gioele Barabucci
Bug#1039721: r-base: 4.3 causes many autopkgtests to fail
Thanks for closing it. I think in due course as you will see there a) new tag does not help today (we already took care of the six packages needing a rebuild because of the graphics engine constant changing) and b) what is likely being the exact same sets of packages having issue with each other as week ago, and the r-base 4.3.1-2 change does not affect them as these are internal issue to the respective packages c) hence there never a mass bug cause to be had. So it was always a nothingburger, and I suspect the ongoing round two of the transition will boil down to what I said at the outset: the packages with woes (beside what the graphics engine change that we covered the standard way) will be dealt with by their maintainer. We'll see how it goes. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1018206: luatex loses or changes text when discretionaries with priorities are used
On 06.07.2023 20:44, Preuße...@buxtehude.debian.org, Hilmar wrote: Hi, Oh my gosh. Losing formatting would indeed be not severe. Distorting contents is IS severe, especially if this goes unnoticed. Heaven knows how much text has already been and will be silently changed in all the years of Debian 12. Therefore, a kind request: please push it into the next update of Debian (12.1) or at least one of the next updates. I guess this is [1] according to [2]. I'll try to do something, but it won't be for 12.1, which will be released soon. I used that one [1], but it does not solve the issue. ;-( H. [1 https://github.com/TeX-Live/luatex/commit/ad3b0d706c71bb6f3309a236e98e8fb644121bc6.patch OpenPGP_signature Description: OpenPGP digital signature
Bug#1040508: ratbagd: DBUS policy is installed in /etc instead of /usr
Package: ratbagd Version: 0.17-2 Tags: patch Dear ratbagd maintainers, ratbagd installs the `org.freedesktop.ratbag1.conf` policy in `/etc/dbus-1`. Since Debian 9 the standard directory for package-installed dbus policies is `/usr/share/dbus-1`. See: https://bugs.debian.org/1006631 Lintian complains with `dbus-policy-in-etc`. A patch to fix this issue is available at https://salsa.debian.org/debian/libratbag/-/merge_requests/3 Regards, -- Gioele Barabucci
Bug#1036424: sylpheed: replying to an email you sent doesn't set account accordingly
On Wed, 14 Jun 2023 16:00:12 +0900 Hideki Yamane wrote: [...] > As I wrote in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036388, > please describe your environment and reproducible way step by step. Hello, I am another user of Sylpheed (in Debian). Personally, I can reproduce the reported issue, but with a difference. In order to reproduce, configure at least two e-mail accounts in Sylpheed. Let's call them: * Albert AtWork * Bert BeachBum Let's say that "Albert AtWork" is the default account. Send an e-mail message from "Bert BeachBum" to your friend "Frank Friend". Now reply to your own e-mail message, with the intent to write again from "Bert BeachBum" to "Frank Friend". The original bug reporter claims that the reply is prepared from the default account "Albert AtWork", instead of from the previously used account "Bert BeachBum". What I experience personally, is that the reply is prepared from the currently selected account (not necessarily from the default account). If you select "Bert BeachBum" (menu entry 'Configuration' → 'Change current account'), and then use the 'Reply' command, the reply will be prepared from "Bert BeachBum", as intended. On the other hand, if you select "Albert AtWork" as current account, the reply will be prepared from "Albert AtWork". Well, this may make sense, after all. If I have selected an account as current, I mean that I want to send e-mail messages from that account. On the other hand, when I reply to an e-mail message sent to one of my accounts (for instance from "Frank Friend" to "Bert BeachBum"), that account is automatically selected, when I use the 'Reply' command, even if it was not the current account. Hence, what the original bug reporter is asking may be considered as useful feature. But I would not consider it as a bug of severity "grave". Maybe the severity should be set to "important" or "normal", or even "wishlist"... I hope this helps. Bye! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp6IrIKT23_e.pgp Description: PGP signature
Bug#1040507: golang-1.21-go: downloads and runs binaries from the Internet without permission
Package: golang-1.21-go Version: 1.21~rc2-2 Severity: grave Tags: security Go 1.21 provides the `GOTOOLCHAIN` environment variable and associated functionality[0]. As part of this code, if go.mod indicates that a newer version of Go is required than the current toolchain supports, it proceeds by default to attempt to download a toolchain from the Internet and runs it without prompting the user. It is unclear what, if any cryptographic verification it performs, especially if the user has disabled GOPROXY and GOSUMDB for privacy reasons. As far as I know, the Go core team does not sign Linux binaries cryptographically, so at best the data would be verified by a hash, which is not sufficient. Debian itself uses a strong cryptographic signature for APT archives. In addition, it's possible that a newer version of the toolchain might contain some vulnerability which is not present in the current toolchain, and therefore might expose the user to new vulnerabilities that are not patched. This is not at all far-fetched, since Go is known to have regressions all the time, so security-based regressions are not at all out of the question. I don't believe this is an appropriate way for software distributed in Debian to behave, especially by default, and I'd like to request that it be patched out for security reasons. Steps to reproduce: 1. Clone a Go project (e.g., Git LFS). 2. Update go.mod to state "go 1.22". 3. Run /usr/lib/go-1.21/bin/go build 4. Notice the following output: go: downloading go1.22 (linux/amd64) go: download go1.22 for linux/amd64: toolchain not available [0] https://tip.golang.org/doc/toolchain -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages golang-1.21-go depends on: ii golang-1.21-src 1.21~rc2-2 Versions of packages golang-1.21-go recommends: ii g++ 4:12.3.0-1 ii gcc 4:12.3.0-1 ii libc6-dev 2.37-3 ii pkg-config1.8.1-1 ii pkgconf [pkg-config] 1.8.1-1 Versions of packages golang-1.21-go suggests: pn bzr | brz ii ca-certificates 20230311 ii git 1:2.40.1+next.20230427-1 pn mercurial pn subversion -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1040506: RM: bigint -- ROM; Useless; Upstream Dead
Package: ftp.debian.org Control: affects -1 + src:bigint X-Debbugs-Cc: big...@packages.debian.org User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: by...@debian.org Severity: normal Dear Debian FTP Masters, Please remove package bigint https://tracker.debian.org/pkg/bigint from debian archive. It was initially packaged as a library dependency, but ended up not being used. Besides, it has a dead upstream and has no reverse dependencies and reverse build-dependencies. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Nicholas, >That's ok, you don't need to find the original version. Remember >that >it's a fork and child relationship, Yes, I'm terribly sorry, I'm familiar with the fork-child relationship but I still found your analogy very helpful and concise, I might present it to my interns (if that's O.K), thanks a lot for the reminder. I was extremely tired when I wrote the last e-mail. In short, considering debian-legal's input, should I mention the NCSA copyright notice in debian/copyright for Files: htpasswd.c, adding a separate License: NCSA field to clarify the provenance of said source ? I will fix the /patches issues we discussed in a later commit and would also like to propose a mechanism for integrating PAM (Pluggable Authentication Modules) into mini-httpd. I am currently in the negotiation phase with my employer to grant an exception for this particular patch in order for it to be upstreamed into debian/patches (since, remember, we're the de-facto upstream here) and for my code to become GPL licensed). PAM support (which would be toggled via a Makefile parameter) could provide tangible improvements for the users of mini-httpd and might even increase the server's popularity. The AUTH mechanism in mini-httpd is arguably heavily antiquated and prone to DDos attacks, MitM, scalability issues, etc. PAM would also enable AAA solutions to interoperate with mini-httpd almost seamlessly (such as Radius, TACACS+) which is becoming increasingly relevant in today's SSO/IoT central trust-based use cases. >P.S. Please acknowledge: Have you read the DFSG yet, and do you >understand why it's important? Yes I have and yes I do, it is one of the main reasons I decided to start contributing to DebianWiki (and now mini-httpd) to begin with. :) >I confirm receipt of your mail, and I see an attached signature. >Where >can I download your public key? I'd like to ask you the same question, since I'd like to add your address to my keyring. I've read a bit of documentation which suggests using Ubuntu's HKP which seems a bit off-axis. I understand that the Debian Public Key Server is for DDs and DMs only (I am not yet a DM). I could perhaps use my DebianWiki personal page to link to my public key, but I do not know if that solution would be accepted or would sound absurd. I should find a better solution after some research. Stay safe and thanks for your time, Alexandru Mihail On Wed, 2023-07-05 at 21:01 -0400, Nicholas D Steeves wrote: > Hi Alexandru, > > Alexandru Mihail writes: > > > After yet some more software archaeology, I've uncovered some more > > rusty HTML 1.0 documents which are of interest to our dilemma. > > Apparently, NCSA HTTPd Acknowledgements as of 7-14-95 state: > > "Thanks to: > > Robert McCool > > For developing NCSA HTTPd till version 1.3 and this > > documentation." > > > > https://web.archive.org/web/20090416132804/http://hoohoo.ncsa.uiuc.edu/docs/acknowledgement.html > > > > This is the time Robert left the project and the date (and license > > release - 1.3) probably aligns best with the code we have in mini- > > httpd. After extensive googling, it seems to me that the original > > mini- > > httpd-1.0.0.tar.gz source is lost to time, or at least is buried > > beyond > > my reach. > > That's ok, you don't need to find the original version. Remember > that > it's a fork and child relationship, so anyone, today, can fork httpd > (1.1-1.3, 1.4-1.14, 1.15, etc.) under the license terms specific to a > particular release. So, for a hypothetical case where the file[s] in > question are identical for the following versions ..: > > 1.1-1.3: "Do what you want but only on continental landmasses" > license > || \\ > || \=Possible fork point. If discriminating against islanders > || is important, then fork from this point. > \/ > 1.4-1.14: "Non-commercial use only, except for fishermen" license > || \\ > || \=Possible fork point. If privileging fishermen and > || discriminate against everyone else is important, then > fork > || from this point. > \/ > 1.15: GPL3+ > \\ > \=Possible fork point. Only discriminates against those who > wish to keep their source private while also distributing > their > fork. Fork from this point if that's important. > > ...then if httpd 1.15 is older then mini-httpd 1.30, you must choose > 1.15. Meanwhile, Robert McCool's copyright still exists in 1.15 even > if > he hasn't made a contribution since 1.3. > > P.S. Please acknowledge: Have you read the DFSG yet, and do you > understand why it's important? > https://wiki.debian.org/DebianFreeSoftwareGuidelines > > > I transitioned all debian mail-related services to Google, and am > > using > > a good MUA now (PGP signing properly). (BTW, does everything look > > all > > right on your end?) > > I confirm receipt of your mail, and I see an attached signature. > Where > can I download your public key? > > >
Bug#1040505: bookworm-pu: package rime-cantonese/0.0~git20230209.e0295fa-2~deb12u1
Package: release.debian.org Control: affects -1 + src:rime-cantonese X-Debbugs-Cc: rime-canton...@packages.debian.org f...@debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bookworm X-Debbugs-Cc: by...@debian.org Severity: normal [ Reason ] This upload adds a missing file (word frequency file) to the installation of binary package rime-data-jyut6ping3 to fix https://bugs.debian.org/1037022 . [ Impact ] If the update is not approved, the rime-cantonese input method will not show word candidates according to the frequency, which makes it very difficult to use. [ Tests ] Manually tested by myself and the original bug submitter. [ Risks ] Minimal. Only a new file appears in the new binary package. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Full debdiff pasted below. diff -Nru rime-cantonese-0.0~git20230209.e0295fa/debian/changelog rime-cantonese-0.0~git20230209.e0295fa/debian/changelog --- rime-cantonese-0.0~git20230209.e0295fa/debian/changelog 2023-02-09 12:49:08.0 -0500 +++ rime-cantonese-0.0~git20230209.e0295fa/debian/changelog 2023-07-06 16:35:12.0 -0400 @@ -1,3 +1,18 @@ +rime-cantonese (0.0~git20230209.e0295fa-2~deb12u1) bookworm; urgency=medium + + * Upload fix to Debian Bookworm. + + -- Boyuan Yang Thu, 06 Jul 2023 16:35:12 -0400 + +rime-cantonese (0.0~git20230209.e0295fa-2) unstable; urgency=medium + + * Team upload. + * Install new /usr/share/rime-data/essay-cantonese.txt vocabulary file +so that the words and characters are sorted by their frequency +for a smooth Cantonese typing experience like before. (Closes: #1037022) + + -- Anthony Fok Thu, 01 Jun 2023 14:32:16 -0600 + rime-cantonese (0.0~git20230209.e0295fa-1) unstable; urgency=medium * New upstream snapshot. diff -Nru rime-cantonese-0.0~git20230209.e0295fa/debian/rime-data-jyut6ping3.install rime-cantonese-0.0~git20230209.e0295fa/debian/rime-data-jyut6ping3.install --- rime-cantonese-0.0~git20230209.e0295fa/debian/rime-data-jyut6ping3.install 2022-11-05 15:57:28.0 -0400 +++ rime-cantonese-0.0~git20230209.e0295fa/debian/rime-data-jyut6ping3.install 2023-07-06 16:34:31.0 -0400 @@ -2,3 +2,4 @@ jyut6ping3*.yaml usr/share/rime-data/ opencc usr/share/rime-data/ symbols_cantonese.yaml /usr/share/rime-data/ +essay-cantonese.txt /usr/share/rime-data/ -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1040504: dh-puredata: armhf externals use wrong extension
Package: dh-puredata Version: 3.1.0 Severity: normal Dear Maintainer, double-precision externals built on armhf use .linux-armhf-64.so as extenion. I think they should use .linux-armv7-64.so instead. while fixing this, also check other CPUs (e.g. PowerPC)
Bug#1040503: gamim: Drop unused gir1.2-gupnpigd-1.0 from Recommends
Source: gajim Version: 1.7.3+git20230504.fc692871-1 Severity: important Please drop gir1.2-gupnpigd-1.0 from Recommends. In upstream "version" 1.7.3+git20230504.fc692871, the code using it in gajim/common/app.py was commented out because gajim uses libsoup2.4 but the new gupnp libraries use libsoup3 I'm filing as important because that gir package will no longer be built from source soon. See https://dev.gajim.org/gajim/gajim/-/issues/11578 Thank you, Jeremy Bícha
Bug#1035194: nanovna-saver: please add autopkgtests (to add coverage for python3-numpy)
Source: nanovna-saver Followup-For: Bug #1035194 Hello. Nanovna-saver requires a specific hardware to do anything useful. Also, testing a graphical tool is far from trivial. Post-build tests check some purely algorithmic parts, but do not make much sense as integration tests. Unless someone comes with a specific suggestion, this bug should probably be closed.
Bug#1040502: bookworm-pu: package rime-luna-pinyin/0.0~git20230204.79aeae2-3~deb12u1
Package: release.debian.org Control: affects -1 + src:rime-luna-pinyin X-Debbugs-Cc: rime-luna-pin...@packages.debian.org eni...@petalmail.com User: release.debian@packages.debian.org Usertags: pu Tags: bookworm X-Debbugs-Cc: by...@debian.org Severity: normal [ Reason ] Fix input method deployment error and bug in customizing input method as reported in https://bugs.debian.org/1040403 . It is caused by missing installation of pinyin.yaml from upstream source code to binary package according to the upstream bug report at https://github.com/rime/home/issues/1326 . [ Impact ] If the update is not approved, the user will not be able to customize rime-luna-pinyin input method, and error message will occur every time on startup. [ Tests ] Manual testing by myself and the original bug submitter. [ Risks ] Minimal risk. Difference between fixed package and problematic package is only the missing pinyin.yaml file. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Full debdiff pasted here. diff -Nru rime-luna-pinyin-0.0~git20230204.79aeae2/debian/changelog rime-luna-pinyin-0.0~git20230204.79aeae2/debian/changelog --- rime-luna-pinyin-0.0~git20230204.79aeae2/debian/changelog 2023-02-20 20:39:19.0 -0500 +++ rime-luna-pinyin-0.0~git20230204.79aeae2/debian/changelog 2023-07-06 16:21:47.0 -0400 @@ -1,3 +1,16 @@ +rime-luna-pinyin (0.0~git20230204.79aeae2-3~deb12u1) bookworm; urgency=medium + + * Upload to Debian Bookworm. + + -- Boyuan Yang Thu, 06 Jul 2023 16:21:47 -0400 + +rime-luna-pinyin (0.0~git20230204.79aeae2-3) unstable; urgency=medium + + * debian/rime-data-luna-pinyin.install: Also install missing +pinyin schema data. (Closes: #1040403) + + -- Boyuan Yang Thu, 06 Jul 2023 11:46:15 -0400 + rime-luna-pinyin (0.0~git20230204.79aeae2-2) unstable; urgency=medium * debian/rime-data-luna-pinyin.install: Also install missing diff -Nru rime-luna-pinyin-0.0~git20230204.79aeae2/debian/rime-data-luna-pinyin.install rime-luna-pinyin-0.0~git20230204.79aeae2/debian/rime-data-luna-pinyin.install --- rime-luna-pinyin-0.0~git20230204.79aeae2/debian/rime-data-luna-pinyin.install 2023-02-20 20:39:12.0 -0500 +++ rime-luna-pinyin-0.0~git20230204.79aeae2/debian/rime-data-luna-pinyin.install 2023-07-06 11:51:03.0 -0400 @@ -1,2 +1,3 @@ build/luna* usr/share/rime-data/build/ *luna*.yaml usr/share/rime-data +pinyin.yaml usr/share/rime-data -- Best Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1040501: mrtg: [INTL:nl] Dutch translation of debconf templates
Package: mrtg Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of mrtg debconf messages. A draft has been posted to the debian-l10n-dutch mailing list allowing for review. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Kind regards, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#1040439: sudo: /etc/sudoers.d/README contains nonsensical text
Package: sudo Version: 1.9.13p3-1 Followup-For: Bug #1040439 Dear Maintainer, Now that you explained it I understand the intended meaning behind the sentence. My suggestion is this: "Sudo versions older than the one in Debian 11 (bullseye) support only the old syntax #includedir, current sudo supports both @includedir and #includedir"
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Am Fri, Jul 07, 2023 at 12:52:49AM +0530 schrieb Nilesh Patra: > > Andreas, if you remember, the code pointed out by Sébastien is > the exact same reason we had to t-p-u r-cran-shiny during freeze, See > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035428#15 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035428#40 > > https://tracker.debian.org/news/1431956/accepted-r-cran-shiny-174dfsg-2deb12u1-source-into-testing-proposed-updates/ Nilesh, you somehow work like my "external memory". I just answered the issue and IMHO Sébastian is correct but this line has a long history ... Kind regards Andreas. -- http://fam-tille.de
Bug#1040001: To strict version restrictions injected by dh-r (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi Sébastien,
Am Thu, Jul 06, 2023 at 09:13:46PM +0200 schrieb Sébastien Villemot:
> > I'm not sure so please explain in more detail. dh-r was designed to put
> > the lowest restriction regarding the versions. I remember some
> > discussion some time ago that Dirk thought we should put stronger
> > restrictions (and he is sometimes adding version restrictions manually
> > that are not helpful for backporting). If I will be sure I understand
> > your point exactly I can check the code and the relevant discussion.
> > (Feel free to file a bug report about this and we can discuss it there
> > if you think this makes more sense.)
>
> It comes from this line:
> https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L272
>
> More precisely the “r-base-core (>= $rbase_version)” part, which
> imposes an unnecessarily tight restriction on the r-base-core version.
Got it, thanks for the explanation. This restriction existed since the
early stage of dh-r development
https://salsa.debian.org/r-pkg-team/dh-r/-/commit/22fd80b9#L174
by Gordon Ball (in CC but not really active in R pkg team any more) at
2016-09-04 12:28:57 +0200 . I'm guessing this restriction was obtained
from the cdbs helper that existed before the dh support was created by
Gordon and he simply took over what existed there. The according line
in the initial commit of dh-r is
say $svs "R:Depends=r-base-core (>= $rversion), $rapiversion";
which supports my thesis. So I went back in history and found the
discussion of bug #704805 where several people were finally able to
convince Dirk that r-api is a good idea.
In r-base changelog we find:
r-base (3.2.0-3) unstable; urgency=low
* debian/control: The r-base-core package now 'Provides: r-api-3' which
can be used to have r-cran-* depend on a particular API vintage.
(Closes: #704805)
* debiab/r-cran.mk: Have the build-time API vintage encoded as a Depends
(with thanks to Julian Gilbey, Charles Plessy, and others for the patch)
* debian/control: Set Standards-Version: to current version
-- Dirk Eddelbuettel Mon, 11 May 2015 06:08:12 -0500
which contains the change in /usr/share/R/debian/r-cran.mk
@@ -96,7 +98,7 @@
dh_installdirs $(debRdir)
##
## support ${R:Depends} via debian/${package}.substvars
- echo "R:Depends=r-base-core (>= ${rversion})" >>
debian/$(package).substvars
+ echo "R:Depends=r-base-core (>= ${rversion}), ${rapiversion}"
>> debian/$(package).substvars
##
## call R to install the sources we're looking at
## use this inside xvfb-run if this wrapper is installed
between this file from r-base (3.2.0-2)
So this seems a historic leftover to me probably since Dirk has the
opinion that this version restriction is needed.
I'd consider it sensible if you open a bug against dh-r where we can
document the change you are suggesting.
Kind regards
Andreas.
--
http://fam-tille.de
Bug#1040500: routine-update: Don't create d/salsa-ci.yml file
Package: routine-update Version: 0.1.1 Severity: normal Dear Maintainer, routine-update adds a file under the path "debian/salsa-ci.yml". According to the salsa-ci-team[1], the default recommendation is to set the pipeline URL in the project settings rather than to use a standaline debian/salsa-ci.yml file. Therefore, please remove the addition of this file and instead please print a warning if this file exists for manual intervention to change the pipeline to the recommended suggestion by the Salsa CI team. [1]: https://salsa.debian.org/salsa-ci-team/pipeline/#basic-use Cheers! Chris -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages routine-update depends on: ii cme1.038-1 ii devscripts 2.23.5 ii dpkg-dev 1.21.22 ii fakeroot 1.31-1.2 ii git1:2.40.1-1 ii git-buildpackage 0.9.30 ii gobject-introspection 1.74.0-3 ii libconfig-model-dpkg-perl 2.165 ii lintian-brush 0.149 ii pristine-tar 1.50 ii quilt 0.67+really0.66-1 routine-update recommends no packages. routine-update suggests no packages. -- no debconf information
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
On Thu, Jul 06, 2023 at 02:24:57PM -0500, Dirk Eddelbuettel wrote: > [...] I understood some of it (not completely, possibly because of lack of background with R extensions), but thanks a lot for taking the time to explain it to me! > So if tibble does this now, it should only affect tibble itself -- unless of > course a dependent package calls directly into the native code of tibble > (possible, but rare). I found some code in vctrs which do some tibble specific stuff, like https://sources.debian.org/src/r-cran-vctrs/0.6.3-1/src/type-tibble.c/ But I don't think there are calls for native code anywhere. No idea where this comes from, then. > | Since you are building with R from unstable and tibble from testing > | (built with an older R), it chokes and works when both are new. > > Not sure I agree. That should still work. Quick check in Docker (using the > r-base image I maintain) shows it does: > > root@f39da83dba5a:/# dpkg -l r-base-core r-cran-tibble | tail -2 Very weird. That means you're unable to repro the failure in https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-rsample/35451568/log.gz Right? Would you have an idea on the github dplyr issue then? The log seems to be the same as we see in the CI https://github.com/tidyverse/dplyr/issues/6793 > It's simpy that testing has an older one and (esp in the tidyverse) things > change quickly and packages want to be in consistent cohort. But AFAICS, in both the scenarios (with and without failure) it is essentially running with the same version of tidyverse, so ideally pulling tibble from unstable and mixing it with an older tidyverse should break, right? (It's the opposite here and I'm quite confused). > | This attribute has got something to do with R extensions' entry > | points / dll compatibilty, but I simply do not have enough background > | with r-core to comment beyond this point, I'm afraid. > > Hope the above helped a little. Yes, thanks again. Best, Nilesh signature.asc Description: PGP signature
Bug#1040499: mail uses short hostname for return address, instead of fqdn
Package: mailutils Version: 1:3.16-1 After a recent upgrade, the mail command switched from using @ to using @ for the default return address. I don't see anything in the changelog, so I'm guessing that wasn't an intentional change? I do see "Remove leftover uses of gethostby* functions." in the changelog which might be related though? Here are some debug logs in case it helps. On another host with mailutils 1:3.15-4, the "mu_mailer_send_message(): using From" line shows the fqdn instead of the short hostname. dseomn@solaria:~$ hostname solaria dseomn@solaria:~$ hostname --fqdn solaria.mandelberg.org dseomn@solaria:~$ echo test | mail.mailutils --debug-level='acl;config;mailbox;mailer;auth' --no-config --config-verbose root mail.mailutils: sendmail binary: /usr/sbin/sendmail mail.mailutils: Getting auth info for UID 1000 mail.mailutils: Trying system... mail.mailutils: system yields 0=Success mail.mailutils: source=system, name=dseomn, passwd=x, uid=1000, gid=1000, gecos=David Mandelberg dir=/home/dseomn, shell=/bin/bash, mailbox=/var/mail/dseomn, quota=0, change_uid=1 mail.mailutils: Getting auth info for UID 1000 mail.mailutils: Trying system... mail.mailutils: system yields 0=Success mail.mailutils: source=system, name=dseomn, passwd=x, uid=1000, gid=1000, gecos=David Mandelberg dir=/home/dseomn, shell=/bin/bash, mailbox=/var/mail/dseomn, quota=0, change_uid=1 mail.mailutils: mu_mailer_send_message(): using From: dseomn@solaria mail.mailutils: exec /usr/sbin/sendmail argv: /usr/sbin/sendmail -oi -f dseomn@solaria -t mail.mailutils: Sending headers... mail.mailutils: Header: To: root mail.mailutils: Header: User-Agent: mail (GNU Mailutils 3.16) mail.mailutils: Header: Date: Thu, 6 Jul 2023 15:48:20 -0400 mail.mailutils: Header: mail.mailutils: Sending body... mail.mailutils: /usr/sbin/sendmail exited with: 0
Bug#1040452: libc6: upgrading libc6 to version 2.37-3 break almost every program (especially in a shell)
Hi, On 2023-07-06 08:14, Kai Wasserbäch wrote: > OK, downgrading from the broken system state didn't work either and left me > with a lot of segfaulting programs. In the end it seems that 2.73-3 isn't > really broken, but the update process is somehow. After I went to a rescue > system and redid the update from there, everything worked out. Now 2.73-3 is > working here as well. In the rescue system environment the post-install > scripts ran successfully. This looks very strange that downgrading and re-upgrading fixes the issue. Did the initial upgrade finished properly? You might want to look for issues in /var/log/dpkg.log or /var/log/apt/term.log. > In case it matters: I made the initial update with aptitude in my graphical > session (KDE on X11). It should not matter how the upgrade is performed, and in any case doesn't explain why your tests on tty2 and tty3 are also affected. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1039746: Support phpunit 10
A fix proposal was submitted to the upstream project at https://gitlab.com/davical-project/davical/-/merge_requests/115 AFAIU, this package is maintained within the upstream project, hence, I am not forwarding a debdiff here. -- Athos Ribeiro
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
On 7 July 2023 at 00:33, Nilesh Patra wrote:
| I think we are hitting this issue here:
https://github.com/tidyverse/dplyr/issues/6793
| The comment says "Looks like some package in the stack sets
R_forceSymbols(dll, TRUE)" and that package is tibble
|
| | $ grep -rnw R_forceSymbols
| | src/init.c:19: R_forceSymbols(dll, TRUE);
That mechanism should not spill from one package to the next.
What we have here is that (R) packages with compiled code can (optionally)
declare in NAMESPACE whether or not 'symbols' (ie the entrypoints for the
compiled code) should be a registered symbol (to R), or (as they used to be)
strings. That is then used in the first argument to .Call() as in eg
.Call(myfunc) as opposed to .Call("myfunc"). It has small efficiency
gains. Most packages do that now.
Now, another (less frequently-used) option is in the intialization file run
at package to also say R_forceSymbols in which case the second ("string")
form is no longer allowed. Few packages do that.
So if tibble does this now, it should only affect tibble itself -- unless of
course a dependent package calls directly into the native code of tibble
(possible, but rare).
So I sum in should not spill. I could be wrong but if there were general
spillage it would affect all R use of compiled packages and it very clearly
does not. So in short, this force symbol resolution should only affect the
symbols from the one shared (per-package) library it is set for.
| Since you are building with R from unstable and tibble from testing
| (built with an older R), it chokes and works when both are new.
Not sure I agree. That should still work. Quick check in Docker (using the
r-base image I maintain) shows it does:
root@f39da83dba5a:/# dpkg -l r-base-core r-cran-tibble | tail -2
ii r-base-core4.3.1-2 amd64GNU R core of statistical
computation and graphics system
ii r-cran-tibble 3.1.8+dfsg-1 amd64GNU R Simple Data Frames
root@f39da83dba5a:/# Rscript -e 'library(tibble); print(as_tibble(mtcars))'
# A tibble: 32 × 11
mpg cyl disphp dratwt qsecvsam gear carb
1 21 6 160110 3.9 2.62 16.5 0 1 4 4
2 21 6 160110 3.9 2.88 17.0 0 1 4 4
3 22.8 4 108 93 3.85 2.32 18.6 1 1 4 1
4 21.4 6 258110 3.08 3.22 19.4 1 0 3 1
5 18.7 8 360175 3.15 3.44 17.0 0 0 3 2
6 18.1 6 225105 2.76 3.46 20.2 1 0 3 1
7 14.3 8 360245 3.21 3.57 15.8 0 0 3 4
8 24.4 4 147.62 3.69 3.19 20 1 0 4 2
9 22.8 4 141.95 3.92 3.15 22.9 1 0 4 2
10 19.2 6 168. 123 3.92 3.44 18.3 1 0 4 4
# … with 22 more rows
root@f39da83dba5a:/#
It's simpy that testing has an older one and (esp in the tidyverse) things
change quickly and packages want to be in consistent cohort.
| This attribute has got something to do with R extensions' entry
| points / dll compatibilty, but I simply do not have enough background
| with r-core to comment beyond this point, I'm afraid.
Hope the above helped a little.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
On Thu, Jul 06, 2023 at 09:13:46PM +0200, Sébastien Villemot wrote: > > I'm not sure so please explain in more detail. dh-r was designed to put > > the lowest restriction regarding the versions. I remember some > > discussion some time ago that Dirk thought we should put stronger > > restrictions (and he is sometimes adding version restrictions manually > > that are not helpful for backporting). If I will be sure I understand > > your point exactly I can check the code and the relevant discussion. > > (Feel free to file a bug report about this and we can discuss it there > > if you think this makes more sense.) > > It comes from this line: > https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L272 > > More precisely the “r-base-core (>= $rbase_version)” part, which > imposes an unnecessarily tight restriction on the r-base-core version. Andreas, if you remember, the code pointed out by Sébastien is the exact same reason we had to t-p-u r-cran-shiny during freeze, See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035428#15 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035428#40 https://tracker.debian.org/news/1431956/accepted-r-cran-shiny-174dfsg-2deb12u1-source-into-testing-proposed-updates/ Best, Nilesh signature.asc Description: PGP signature
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi,
Am Thu, Jul 06, 2023 at 08:28:45PM +0200 schrieb Paul Gevers:
> On 06-07-2023 19:08, Paul Gevers wrote:
> > Yes, we'll take care of that where it looks sane to do so (examples of
> > that are r-cran-epi); I'll manually schedule the "combined" tests, such
> > that they disappear from the excuses if they then pass.
>
> I'm seeing in several tests where things seem to work when r-cran-tibble
> from unstable is involved and fail if the version from unstable is used;
Are you sure there is no typo in your sentence? At least I fail to
understand. I assume the latter "unstable" should be "testing", right?
> e.g. here: https://ci.debian.net/packages/r/r-cran-rsample/testing/amd64/
I can only say that tibble is used by a lot of packages directly as
dependency (69 in my locally stored repositories - may be some more).
In addition there are further dependencies of higher order.
> Is there something special about r-cran-tibble? It didn't grow a dependency
> on r-graphics-engine according to
> https://buildd.debian.org/status/fetch.php?pkg=r-cran-tibble=amd64=3.2.1%2Bdfsg-2=1688629916=0
> so it doesn't seem to be involved in that part of the discussion.
I confirm it shouldn't be involved into the r-graphics-engine issue.
May be there is some other "hidden" transition needed which is connected
to some interface of tibble? Dirk, can you shed some light into this?
Kind regards
Andreas.
--
http://fam-tille.de
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Le jeudi 06 juillet 2023 à 21:02 +0200, Andreas Tille a écrit : > Am Thu, Jul 06, 2023 at 07:08:04PM +0200 schrieb Paul Gevers: > > PS: in a private discussion I had today, we noticed that r-* packages often > > (always?) have a dependency on r-base-core with a lower limited version > > equal to the r-base-core that was used during the build. With the > > appropriate API in Provides of r-base-core, this should no longer be > > necessary and ease migrations in the future. > > Could you please give some example to make sure I understand correctly? > > > We should probably file a bug > > against dh-r (I guess) to fix that dependency. Or did we conclude that > > wrong? > > I'm not sure so please explain in more detail. dh-r was designed to put > the lowest restriction regarding the versions. I remember some > discussion some time ago that Dirk thought we should put stronger > restrictions (and he is sometimes adding version restrictions manually > that are not helpful for backporting). If I will be sure I understand > your point exactly I can check the code and the relevant discussion. > (Feel free to file a bug report about this and we can discuss it there > if you think this makes more sense.) It comes from this line: https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L272 More precisely the “r-base-core (>= $rbase_version)” part, which imposes an unnecessarily tight restriction on the r-base-core version. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Hi Paul, On Thu, Jul 06, 2023 at 08:28:45PM +0200, Paul Gevers wrote: > On 06-07-2023 19:08, Paul Gevers wrote: > > Yes, we'll take care of that where it looks sane to do so (examples of > > that are r-cran-epi); I'll manually schedule the "combined" tests, such > > that they disappear from the excuses if they then pass. > > I'm seeing in several tests where things seem to work when r-cran-tibble > from unstable is involved and fail if the version from unstable is used; > e.g. here: https://ci.debian.net/packages/r/r-cran-rsample/testing/amd64/ > > Is there something special about r-cran-tibble? It didn't grow a dependency > on r-graphics-engine according to > https://buildd.debian.org/status/fetch.php?pkg=r-cran-tibble=amd64=3.2.1%2Bdfsg-2=1688629916=0 > so it doesn't seem to be involved in that part of the discussion. I think we are hitting this issue here: https://github.com/tidyverse/dplyr/issues/6793 The comment says "Looks like some package in the stack sets R_forceSymbols(dll, TRUE)" and that package is tibble | $ grep -rnw R_forceSymbols | src/init.c:19: R_forceSymbols(dll, TRUE); Since you are building with R from unstable and tibble from testing (built with an older R), it chokes and works when both are new. This attribute has got something to do with R extensions' entry points / dll compatibilty, but I simply do not have enough background with r-core to comment beyond this point, I'm afraid. Best, Nilesh signature.asc Description: PGP signature
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Hi Paul, Am Thu, Jul 06, 2023 at 07:08:04PM +0200 schrieb Paul Gevers: > Yes, we'll take care of that where it looks sane to do so (examples of that > are r-cran-epi); I'll manually schedule the "combined" tests, such that they > disappear from the excuses if they then pass. OK. Thanks a lot for this service. Do you think the remaining serious tests are blockers? Should these be closed manually? > > Alternatively it would probably OK to remove all > > RC buggy r-bioc-* packages from testing since we need to upload new > > versions of these packages anyway in the pending BioC transition (I'll > > file an according bug report soon). > > If you're OK to temporarily remove r-bioc-*, than I think it's the fastest > and easiest way out, albeit not the prettiest. For sure it is not pretty, but since once week I'm fighting to non-pretty things and I'm really happy about fast and easy solutions. ;-) I have just filed a transition bug for r-bioc-* where we can discuss issues belonging to this transition. > Please all involved, hold any uploads in the r-* world until we get r-base > migrated unless it's needed (and we acked it). OK, I'll refrain from any upload of r-* packages (I'll answer your other mail about r-cran-tibble separately). > Paul > > PS: in a private discussion I had today, we noticed that r-* packages often > (always?) have a dependency on r-base-core with a lower limited version > equal to the r-base-core that was used during the build. With the > appropriate API in Provides of r-base-core, this should no longer be > necessary and ease migrations in the future. Could you please give some example to make sure I understand correctly? > We should probably file a bug > against dh-r (I guess) to fix that dependency. Or did we conclude that > wrong? I'm not sure so please explain in more detail. dh-r was designed to put the lowest restriction regarding the versions. I remember some discussion some time ago that Dirk thought we should put stronger restrictions (and he is sometimes adding version restrictions manually that are not helpful for backporting). If I will be sure I understand your point exactly I can check the code and the relevant discussion. (Feel free to file a bug report about this and we can discuss it there if you think this makes more sense.) Kind regards Andreas. -- http://fam-tille.de
Bug#1040498: transition: r-bioc-biocgenerics
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: r-bioc-biocgener...@packages.debian.org, debia...@bugs.debian.org Control: affects -1 + src:r-bioc-biocgenerics Hi, BioConductor has released version 3.17 when we were in Freeze. Once we have settled the r-base graphics API transition I would like to start the BioConductor transition bumping r-api-bioc-3.16 to r-api-bioc-3.17. As we discussed in bug #1040001 it is fine in principle to remove all r-bioc-* packages from testing to smoothen the r-base migration. These will be soonish replaced by the new set of packages belonging to BioConductor 3.17. Kind regards and thanks a lot for your work as release team Andreas. Ben file: title = "r-bioc-biocgenerics"; is_affected = .depends ~ "r-bioc-biocgenerics" | .depends ~ "r-bioc-biocgenerics"; is_good = .depends ~ "r-bioc-biocgenerics"; is_bad = .depends ~ "r-bioc-biocgenerics";
Bug#1019236: Why does mere inclusion of pstricks change A4 to letter?
On 06.07.2023 12:24, Peter Mueller wrote: Hi, Don't know about unstable (I cannot risk an upgrade now), but as for the texlive-pstricks 2022.20230122-4 containing pst-node.sty 2012/09/18 v1.01, the bug still exists. Do you have the time to discuss this with the upstream author. I don't have. Sorry! Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1018206: luatex loses or changes text when discretionaries with priorities are used
Control: severity -1 important On 06.07.2023 12:15, Peter Mueller wrote: Hi, Oh my gosh. Losing formatting would indeed be not severe. Distorting contents is IS severe, especially if this goes unnoticed. Heaven knows how much text has already been and will be silently changed in all the years of Debian 12. Therefore, a kind request: please push it into the next update of Debian (12.1) or at least one of the next updates. I guess this is [1] according to [2]. I'll try to do something, but it won't be for 12.1, which will be released soon. H. [1] https://github.com/TeX-Live/luatex/commit/77e10504fec9a0d131af670eadcfe9a0db4e3bf0#diff-06ca41d7c22a6c478aa499841874506676b8f9183cd37c3b928c386d87ffcb4c [2] https://mailman.ntg.nl/archives/list/dev-lua...@ntg.nl/thread/XVFUXHHDWNVYMVMYYICWMP4CJTQGFLH4/ -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1040479: 104079: devices from extern FC-Raid only map if the have no partitions
Package: multipath-tools Version: 0.9.4-3+deb12u1 Severity: critical Tags: upstream Justification: breaks unrelated software X-Debbugs-Cc:t...@security.debian.org Hallo Chris, if the device has _one_ partition Version: 0.9.4-3+deb12u1 solve the problem, but if it has multiple partitions the problem stay. with regards On Thu, 6 Jul 2023 15:18:52 +0200 Chris Hofstaedtler wrote: > Version: 0.9.4-3+deb12u1 > > Should be the same as #1037539, already fixed in deb12u1. > > > > -- Dipl.-Phys. Andreas Matthus Netzwerkadministrator Technische Universität Dresden Fakultät Architektur 01062 Dresden Tel.: +49 (351) 463-33909 Fax: +49 (351) 463-36120 E-Mail:andreas.matt...@tu-dresden.de smime.p7s Description: S/MIME Cryptographic Signature
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Hi, On 06-07-2023 19:08, Paul Gevers wrote: Yes, we'll take care of that where it looks sane to do so (examples of that are r-cran-epi); I'll manually schedule the "combined" tests, such that they disappear from the excuses if they then pass. I'm seeing in several tests where things seem to work when r-cran-tibble from unstable is involved and fail if the version from unstable is used; e.g. here: https://ci.debian.net/packages/r/r-cran-rsample/testing/amd64/ Is there something special about r-cran-tibble? It didn't grow a dependency on r-graphics-engine according to https://buildd.debian.org/status/fetch.php?pkg=r-cran-tibble=amd64=3.2.1%2Bdfsg-2=1688629916=0 so it doesn't seem to be involved in that part of the discussion. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1039860: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.199.02-1~deb11u1
Control: tags -1 + confirmed On Thu, 2023-06-29 at 00:29 +0200, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > Control: clone -1 -2 > Control: retitle -2 bookworm-pu: package nvidia-graphics-drivers- > tesla-470/470.199.02-1~deb12u1 > Control: tag -2 = bookworm > Control: usertag -2 pu > fwiw, setting usertags via Control: doesn't work; fixed separately. > [ Reason ] > Let's update nvidia-graphics-drivers-tesla-470 in bookworm/bullseye > to a new upstream release fixing some CVEs. > Please go ahead. Regards, Adam
Bug#1040142: bookworm-pu: package aide/0.18.3-1+deb12u2
Control: tags -1 + confirmed On Sat, 2023-07-01 at 16:03 +0200, Marc Haber wrote: > This update augments 0.18.3-1+deb12u1 which has already been accepted > for bookworm-pu last week. It fixes #1039936, an important bug that > is a > regression from bullseye and affects directory processing when using > equals rules. > > [ Impact ] > Without this bug fixes, equals rules concerning directories are > incorrectly processed, which differs from the way that bullseye's > aide > handled this case and also differs from the way operation is > documented. > Debian's default configuration doesn't use equals rules and is > therefore > not affected, but local configurations might be. > Please go ahead. Regards, Adam
Bug#1040490: librust-cipher-dev: please provide feature block-padding
Control: block -1 by 1040492 Quoting Jeremy Bícha (2023-07-06 19:26:14) > On Thu, Jul 6, 2023 at 12:48 PM Jonas Smedegaard wrote: > > Quoting Jeremy Bícha (2023-07-06 18:30:42) > > > Would you like to share why you need that feature? > > > > Would you like to share why the feature was patched out? > > > > My reason for needing the feature is not a secret. I am however > > reluctant to write elaborate bugreport for packages that seem to not > > be elaborately packaged. > > > > Concretely, and as also mentioned in this bugreport, lack of DEP-3 > > patch headers that would help hint at the reason for the existence of a > > patch. > > > > DEP-3 patch headers are documented here: > > https://dep-team.pages.debian.net/deps/dep3/ > > > > So let's trade: Please first share why it was patched out. ;-) > > Well, this is also not a secret. It's in debian/changelog: > https://tracker.debian.org/news/1441750/accepted-rust-cipher-044-2-source-into-unstable/ Thanks. Added blocking hint accordingly. I am working on packaging Safenet (bug#1008016) which transitively requires cbc, which in turn requires cipher with feature block-padding. - 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#1040139: bookworm-pu: package exim4/4.96-15
Control: tags -1 + confirmed
On Sun, 2023-07-02 at 15:11 +0200, Andreas Metzler wrote:
> I would like to get most of the changes from 4.96-16
> (unstable/testing)
> into bookworm:
>* 75_42-Fix-run-arg-parsing.patch (From upstream GIT master,
> backported by
> Bryce Harrington for Ubuntu): Fix argument parsing for ${run }
> expansion.
> Previously, when an argument included a close-brace character
> (eg. it
> itself used an expansion) an error occurred. Closes: #1025420
>* 75_68-Fix-srs_encode-.-for-mod-1024-day-zero.patch from upstream
> GIT
> master: Fix ${srs_encode ..}. Previously it would give a bad
> result for
> one day every 1024 days.
>
> The former is something has already popped up a couple of times on
> the
> upstream user support mailing list.
>
Please go ahead.
Regards,
Adam
Bug#1040497: On ASPEED and NVIDIA, gnome runs Xorg instead of Wayland
Tiny correction: I wanted to reference the whole http://gitlab.gnome.org/GNOME/gdm/-/merge_requests/171 and not a single comment therein.
Bug#1040432: ical2html: man pages for ical2html binaries contain "./binary: unrecognized option '--help'"
Hi Carles, Quoting Carles Pina i Estany (2023-07-05 22:41:32) > Each of the manual pages (man ical2html, icalfilter and icalmerge) > contain a line: ./ical2html: unrecognized option '--help' Oh, indeed. Thanks for noticing and reporting! - 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#1036712: Replaces without Breaks or Conflicts harmful?
Helmut Grohne dixit:
> openjdk-8 (U)
Should be convered by the Depends lines in the respective
binary packages, e.g:
Depends: openjdk-8-jre (>= ${source:Version}),
openjdk-8-jdk (>= ${binary:Version}),
${misc:Depends}
Replaces: openjdk-8-jdk (<< 8u20~b26-1~)
> rng-tools-debian
Also false positive:
Replaces: intel-rng-tools, rng-tools
Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate)
Conflicts: intel-rng-tools
bye,
//mirabilos
--
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Bug#1014405: bash.bashrc snippet to give sudo hint
Control: tags -1 thanks On Thu, Jun 02, 2022 at 07:39:39PM +0200, Vincent Blut wrote: > What makes this option interesting in Ubuntu is this code snippet in > /etc/bash.bashrc: > > if [ ! -e "$HOME/.sudo_as_admin_successful" ] && [ ! -e "$HOME/.hushlogin" ] > ; then > case " $(groups) " in *\ admin\ *|*\ sudo\ *) > if [ -x /usr/bin/sudo ]; then > cat <<-EOF > To run a command as administrator (user "root"), use "sudo > ". > See "man sudo_root" for details. > > EOF > fi > esac > fi What does the bash maintainer in Debian think about this change? Greetings Marc
Bug#1040439: sudo: /etc/sudoers.d/README contains nonsensical text
Control: tags -1 confirmed thanks On Wed, Jul 05, 2023 at 10:28:37PM +, patri...@gmail.com wrote: > Notice the last sentence: > "Sudo versions older than the one in Debian 11 (bullseye) require the > directive will only support the old syntax #includedir, and the current sudo > will happily accept both @includedir and #includedir" The words "require the directive" are wrong here, and after they have been removed the sentence makes sense to me, as a non-native speaker. Please suggest a different wording if you want it differently. > has very broken english. Please fix and release the fix into bookworm > because documentation should be clear. I apologize, but this will not be going into a point release. I might pursue that if an update is in order for technical reasons, but strictly speaking that is not eligible for a stable point release. Greetings Marc
Bug#1040497: gnome runs Xorg on ASPEED + NVIDIA
Package: gnome Version: 1:43+1 Control: affects -1 gdm3/43.0-3 After upgrading from a mixture of Debian 11 and 12 to Debian 12, Gnome started to run Xorg on login instead of Wayland, whereas previously, Wayland had been used. In uxterm, we see $ echo $XDG_SESSION_TYPE x11 $ grep -i Wayland /etc/gdm3/daemon.conf #WaylandEnable=false In the journal we find, among other stuff, this: … 2023-07-06T09:50:41.334837+02:00 AnonymizedMachineName systemd[1957]: Started app-gnome-gnome\x2dkeyring\x2dssh-2263.scope - Application launched by gnome-session-binary. 2023-07-06T09:50:41.337128+02:00 AnonymizedMachineName gnome-keyring-d[1993]: The Secret Service was already initialized 2023-07-06T09:50:41.339085+02:00 AnonymizedMachineName gnome-keyring-secrets.desktop[2267]: discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring 2023-07-06T09:50:41.353383+02:00 AnonymizedMachineName gnome-keyring-d[1993]: The PKCS#11 component was already initialized 2023-07-06T09:50:41.354308+02:00 AnonymizedMachineName dbus-daemon[1995]: [session uid=1000 pid=1995] Activating via systemd: service name='org.gtk.vfs.MTPVolumeMonitor' unit='gvfs-mtp-volume-monitor.service' requested by ':1.13' (uid=1000 pid=2124 comm="/usr/libexec/tracker-miner-fs-3") 2023-07-06T09:50:41.355212+02:00 AnonymizedMachineName gnome-keyring-pkcs11.desktop[2268]: discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring 2023-07-06T09:50:41.355373+02:00 AnonymizedMachineName gnome-keyring-pkcs11.desktop[2268]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh 2023-07-06T09:50:41.356700+02:00 AnonymizedMachineName gnome-keyring-ssh.desktop[2266]: discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring 2023-07-06T09:50:41.356916+02:00 AnonymizedMachineName gnome-keyring-ssh.desktop[2266]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh 2023-07-06T09:50:41.358183+02:00 AnonymizedMachineName systemd[1957]: Starting gvfs-mtp-volume-monitor.service - Virtual filesystem service - Media Transfer Protocol monitor... 2023-07-06T09:50:41.365168+02:00 AnonymizedMachineName systemd[1957]: Started gnome-session-manager@gnome.service - GNOME Session Manager (session: gnome). 2023-07-06T09:50:41.365674+02:00 AnonymizedMachineName systemd[1957]: Reached target gnome-session-manager.target - GNOME Session Manager is ready. 2023-07-06T09:50:41.367890+02:00 AnonymizedMachineName systemd[1957]: Starting org.gnome.Shell@wayland.service - GNOME Shell on Wayland... 2023-07-06T09:50:41.377067+02:00 AnonymizedMachineName systemd[1957]: Starting org.gnome.Shell@x11.service - GNOME Shell on X11... 2023-07-06T09:50:41.387252+02:00 AnonymizedMachineName systemd[1957]: org.gnome.Shell@wayland.service: Skipped due to 'exec-condition'. 2023-07-06T09:50:41.387680+02:00 AnonymizedMachineName systemd[1957]: Condition check resulted in org.gnome.Shell@wayland.service - GNOME Shell on Wayland being skipped. 2023-07-06T09:50:41.404997+02:00 AnonymizedMachineName systemd[1957]: Started app-gnome-at\x2dspi\x2ddbus\x2dbus-2270.scope - Application launched by gnome-session-binary. Further, $ sudo cat /run/gdm3/custom.conf [daemon] WaylandEnable=false $ ls -a /etc/udev/rules.d/ . .. $ ls -a /run/udev/ . .. control data gdm-machine-has-hardware-gpu gdm-machine-has-hybrid-graphics links static_node-tags tags watch The machine is stationary (i.e., not a laptop) with two graphic chips, namely, ASPEED AST2500 64MB and NVIDIA® GeForce® GTX1660 Ti 6GB: $ sudo lspci -vv| grep -A15 Graphics 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 41) (prog-if 00 [VGA controller]) Subsystem: ASPEED Technology, Inc. ASPEED Graphics Family Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Interrupt: pin A routed to IRQ 17 NUMA node: 0 IOMMU group: 32 Region 0: Memory at 8c00 (32-bit, non-prefetchable) [size=64M] Region 1: Memory at 9000 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at 4000 [size=128] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/2 Maskable- 64bit+ Address: Data: Kernel driver in use: ast Kernel modules: ast $ sudo lspci -vv| grep -A81 -i GeForce 65:00.0 VGA compatible controller: NVIDIA Corporation TU116 [GeForce GTX 1660 Ti] (rev a1) (prog-if 00 [VGA controller]) Subsystem: PNY TU116 [GeForce GTX 1660 Ti] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
Bug#1040346: linux-image-6.3.0-2-amd64: AMDGPU only with unusable high resolution available
Hi Salvatore, Am Do den 6. Jul 2023 um 11:36 schrieb Salvatore Bonaccorso: > Can you check if it is the following known regression: > https://lore.kernel.org/stable/mn0pr12mb6101c52c4b7fb00702a996ebe2...@mn0pr12mb6101.namprd12.prod.outlook.com/ It pretty much look like that it is this one. Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C signature.asc Description: PGP signature
Bug#1037591: Why was the severity of this bug increased?
Hello, On 5 July the severity of this bug was changed from 'normal' to 'important'. Yet this bug is already fixed. It was marked as: Fixed in version bibledit-cloud/5.1.002-1 This version, bibledit-cloud/5.1.002-1, is already available in the testing and unstable archives. Question: Why was the severity of this bug raised? Note that although the bug was fixed, it was left open as per request in the bug report. Met vriendelijke groeten, With kind regards, Teus Benschop https://freesoftwareconsultants.nl https://bibledit.org
Bug#1040490: [Pkg-rust-maintainers] Bug#1040490: librust-cipher-dev: please provide feature block-padding
Package contains a patch to remove feature block-padding, with no DEP-3 patch headers indicating why I did it to get the new rust-aes into testing quicker while we wait for either rust-block-buffer-0.9 and it's rdeps to get autoremoved from testing, or some other resoloution that allows rust-block-padding to migrate. Once I get aes into testing, i'm happy to re-enable the feature.
Bug#1040490: librust-cipher-dev: please provide feature block-padding
On Thu, Jul 6, 2023 at 12:48 PM Jonas Smedegaard wrote: > Quoting Jeremy Bícha (2023-07-06 18:30:42) > > Would you like to share why you need that feature? > > Would you like to share why the feature was patched out? > > My reason for needing the feature is not a secret. I am however > reluctant to write elaborate bugreport for packages that seem to not > be elaborately packaged. > > Concretely, and as also mentioned in this bugreport, lack of DEP-3 > patch headers that would help hint at the reason for the existence of a > patch. > > DEP-3 patch headers are documented here: > https://dep-team.pages.debian.net/deps/dep3/ > > So let's trade: Please first share why it was patched out. ;-) Well, this is also not a secret. It's in debian/changelog: https://tracker.debian.org/news/1441750/accepted-rust-cipher-044-2-source-into-unstable/ Thank you, Jeremy Bícha
Bug#1037589: Why was the severity of this bug increased?
Hello, On 5 July the severity of this bug was changed from 'normal' to 'important'. Yet this bug is already fixed. It was marked as: Fixed in version bibledit/5.1.002-1 This version, bibledit/5.1.002-1, is already available in the testing and unstable archives. Question: Why was the severity of this bug raised? Note that although the bug was fixed, it was left open as per request in the bug report. Met vriendelijke groeten, With kind regards, Teus Benschop https://freesoftwareconsultants.nl https://bibledit.org
Bug#1040496: qt6-virtualkeyboard FTBFS with parallel=1: qmlcachegen segfaults
Source: qt6-virtualkeyboard Version: 6.4.2+dfsg-2 Severity: serious Tags: ftbfs qt6-virtualkeyboard fails to build from source in unstable when passing DEB_BUILD_OPTIONS=parallel=1. A build ends as follows: | [110/301] cd /<>/obj-x86_64-linux-gnu/src/components && /usr/bin/cmake -E make_directory /<>/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache && /usr/lib/qt6/libexec/qmlcachegen --bare --resource-path /qt-project.org/imports/QtQuick/VirtualKeyboard/Components/Keyboard.qml -I /<>/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml -I /usr/lib/x86_64-linux-gnu/qt6/qml -i /<>/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml/QtQuick/VirtualKeyboard/Components/qmldir --resource /<>/obj-x86_64-linux-gnu/src/components/.rcc/qmake_QtQuick_VirtualKeyboard_Components.qrc --resource /<>/obj-x86_64-linux-gnu/src/components/.rcc/qtvkbcomponentsplugin_raw_qml_0.qrc -o /<>/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp /<>/src/components/Keyboard.qml | FAILED: src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp /<>/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp | cd /<>/obj-x86_64-linux-gnu/src/components && /usr/bin/cmake -E make_directory /<>/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache && /usr/lib/qt6/libexec/qmlcachegen --bare --resource-path /qt-project.org/imports/QtQuick/VirtualKeyboard/Components/Keyboard.qml -I /<>/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml -I /usr/lib/x86_64-linux-gnu/qt6/qml -i /<>/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml/QtQuick/VirtualKeyboard/Components/qmldir --resource /<>/obj-x86_64-linux-gnu/src/components/.rcc/qmake_QtQuick_VirtualKeyboard_Components.qrc --resource /<>/obj-x86_64-linux-gnu/src/components/.rcc/qtvkbcomponentsplugin_raw_qml_0.qrc -o /<>/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp /<>/src/components/Keyboard.qml | Segmentation fault (core dumped) | ninja: build stopped: subcommand failed. | dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v returned exit code 1 | make: *** [debian/rules:12: binary] Error 25 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 This originally was a cross build failure, but it also reproduces natively. Therefore, I know that it also fails on an arm64 machine. In all of my testing, all parallel=1 builds reliably failed while all builds that weren't parallel=1 succeeded (cross or native). This is not necessarily a bug in qt6-virtualkeyboard itself. I'll leave it up to you to reassign as necessary. Helmut
Bug#1040495: RFS: grimripper/3.0.2-1 -- Graphical audio CD ripper and encoder
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "grimripper": https://tracker.debian.org/pkg/grimripper (Andreas who sponsored initial upload is having to set up a new gpg key which will likely take a while) As a DM, I would be happy to upload grimripper myself if given the upload rights. * Package name : grimripper Version : 3.0.2-1 Upstream contact : Salamandar * URL : https://gitlab.gnome.org/Salamandar/GrimRipper * License : GPL-2+, CC0-1.0, GPL-2 * Vcs : https://salsa.debian.org/PeterB/grimripper Section : sound The source builds the following binary packages: grimripper - Graphical audio CD ripper and encoder To access further information about this package, please visit the following URL: https://mentors.debian.net/package/grimripper/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/grimripper/grimripper_3.0.2-1.dsc Also on Salsa https://salsa.debian.org/PeterB/grimripper Changes since the last upload: grimripper (3.0.2-1) unstable; urgency=medium . * New Upstream release (completes rename to grimripper) Regards, -- Peter Blackman
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Hi Andreas, On 06-07-2023 16:44, Andreas Tille wrote: Am Thu, Jul 06, 2023 at 09:56:31AM +0200 schrieb Andreas Tille: Is there any chance to fix this via hinting by release team or should I rather add some "artificial" versioned Depends just to enable the whole set of r-cran-* packages to testing. Yes, we'll take care of that where it looks sane to do so (examples of that are r-cran-epi); I'll manually schedule the "combined" tests, such that they disappear from the excuses if they then pass. Alternatively it would probably OK to remove all RC buggy r-bioc-* packages from testing since we need to upload new versions of these packages anyway in the pending BioC transition (I'll file an according bug report soon). If you're OK to temporarily remove r-bioc-*, than I think it's the fastest and easiest way out, albeit not the prettiest. Please all involved, hold any uploads in the r-* world until we get r-base migrated unless it's needed (and we acked it). Paul PS: in a private discussion I had today, we noticed that r-* packages often (always?) have a dependency on r-base-core with a lower limited version equal to the r-base-core that was used during the build. With the appropriate API in Provides of r-base-core, this should no longer be necessary and ease migrations in the future. We should probably file a bug against dh-r (I guess) to fix that dependency. Or did we conclude that wrong? OpenPGP_signature Description: OpenPGP digital signature
Bug#1032071: ARM firmware packages included in amd64 installation images
> >Speaking for myself: I installed from a live image on the release day of > >Debian > >12. > > OK, that explains it. Let's try to get this fixed before 12.1... > > I can see that there is already #1035382 open on the live side, let's> bump > the severity on that. > Aha, yes. Bug #1035382 seems to be the _actual_ bug for this. Sorry if I mailed in the wrong bug report!
Bug#1040494: RFS: cevomapgen/26-1 [ITP] -- External Map Generator for C-Evo
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "cevomapgen": * Package name : cevomapgen Version : 26-1 Upstream contact : Peter Blackman * URL : https://sourceforge.net/projects/cevomapgen/ * License : CC-BY-3.0, GPL-2+ * Vcs : https://salsa.debian.org/PeterB/cevomapgen Section : games The source builds the following binary packages: cevomapgen - External Map Generator for C-Evo To access further information about this package, please visit the following URL: https://mentors.debian.net/package/cevomapgen/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/cevomapgen/cevomapgen_26-1.dsc Changes for the initial release: cevomapgen (26-1) unstable; urgency=medium . * Initial release (Closes: #1035747) Regards, -- Peter Blackman
Bug#961595: ruby-gollum-lib: please package new upstream release 5.x
Control: block 1040461 by -1 On Tue, 26 May 2020 14:55:28 +0200 Jonas Smedegaard wrote: > gollum-lib 5.x has been out for a few months, with several exciting new > features. > > Please consider upgrading to that new release. ruby-gollum-lib was originally packaged as a dependency of gitaly and gitaly no longer needs it (so I'm not interested in maintaining it any longer). It is also blocking testing migration of ruby-rouge (#1040405). So I have filed an rm request #1040461 for it. If you are interested in maintaining it, you can close the rm bug and fix the rc bug.
Bug#1040490: librust-cipher-dev: please provide feature block-padding
Quoting Jeremy Bícha (2023-07-06 18:30:42) > Would you like to share why you need that feature? Would you like to share why the feature was patched out? My reason for needing the feature is not a secret. I am however reluctant to write elaborate bugreport for packages that seem to not be elaborately packaged. Concretely, and as also mentioned in this bugreport, lack of DEP-3 patch headers that would help hint at the reason for the existence of a patch. DEP-3 patch headers are documented here: https://dep-team.pages.debian.net/deps/dep3/ So let's trade: Please first share why it was patched out. ;-) - 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#1040493: ITP: obs-ashmanix-blur-filter -- plugin for OBS Studio to set a blur filter on a source
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho X-Debbugs-Cc: debian-de...@lists.debian.org, Ashmanix * Package name: obs-ashmanix-blur-filter Version : 0.0.2 Upstream Contact: Ashmanix * URL : https://obsproject.com/forum/resources/ashmanix-blur-filter.1742/ * License : GPL-2+ Programming Lang: C++ Description : plugin for OBS Studio to set a blur filter on a source This plugin lets to set a simple blur filter on any OBS source, such images, videos, texts, scenes, webcam, etc. To use it, just right click on an image or video source and select Filters.
Bug#1032071: ARM firmware packages included in amd64 installation images
Control: severity 1035382 grave On Thu, Jul 06, 2023 at 06:29:49PM +0200, Magnus Wallin wrote: > >Hi Magnus, and thanks for the heads-up > >[ . . . ] > >Just because the raspi-firmware package is included on the d-i >installation media, it shouldn't necessarily be installed on an amd64 >host. Or is this coming from live images? > >Hi Steve! > >Speaking for myself: I installed from a live image on the release day of Debian >12. OK, that explains it. Let's try to get this fixed before 12.1... I can see that there is already #1035382 open on the live side, let's bump the severity on that. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Bug#1036428: libapache2-mod-apreq2: the package is missing from testing release and from i386 architecture
There are a lot of bugs in the libapreq 2.17 release, the maintainer recommends building from trunk: Forwarded Message Subject:Re: libapreq 2.17 POST upload with empty filename parameter Date: Tue, 4 Jul 2023 21:01:32 + From: Joe Schaefer Reply-To: d...@httpd.apache.org To: d...@httpd.apache.org , Raymond Field 2.17 was a dud security release. Use trunk Joe Schaefer, Ph.D +1 (954) 253-3732 SunStar Systems, Inc. /Orion - The Enterprise Jamstack Wiki/ / / On Tue, 13 Jun 2023 08:17:01 +0200 Sebastiaan Couwenberg wrote: > On Sat, 20 May 2023 19:25:41 +0200 Rafal Pietrak wrote: > > I've experieced problem after upgrading old (i386) machine to Debian-12 > > I've upgraded it from Debian-10, through Debian-11 (without testing this > The package got removed from bookworm due to #1027355. > > libapreq2 (2.17-3) should migrate to testing in a few days. > > Once it's back in testing, it will be rebuilt for bookworm-backports. > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > >
Bug#1040491: libhtml-mason-perl: FTBFS with Perl 5.38: t/13-errors.t failure
Source: libhtml-mason-perl Version: 1:1.59-2 Severity: important Tags: ftbfs sid trixie fixed-upstream Forwarded: https://github.com/houseabsolute/HTML-Mason/issues/33 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build with Perl 5.38 (currently in experimental). # Running top_level_compilation_error (#20): Make sure top-level compiler errors work in output mode # Got ... # - # Error during compilation of /<>/mason_tests/3797995/comps/errors/top_level_compilation_error: # syntax error at /<>/mason_tests/3797995/comps/errors/top_level_compilation_error line 2, near ";" # Execution of /<>/mason_tests/3797995/comps/errors/top_level_compilation_error aborted due to compilation errors. # # Stack: # [/<>/mason_tests/3797995/comps/errors/top_level_compilation_error:2] # [/<>/blib/lib/HTML/Mason/Interp.pm:817] # [/<>/blib/lib/HTML/Mason/Interp.pm:445] # [/<>/blib/lib/HTML/Mason/Request.pm:250] # [/<>/blib/lib/HTML/Mason/Request.pm:212] # [/usr/share/perl5/Class/Container.pm:275] # [/usr/share/perl5/Class/Container.pm:353] # [/<>/blib/lib/HTML/Mason/Interp.pm:348] # [/<>/blib/lib/HTML/Mason/Interp.pm:342] # [/<>/blib/lib/HTML/Mason/Tests.pm:528] # [/<>/blib/lib/HTML/Mason/Tests.pm:515] # [/<>/blib/lib/HTML/Mason/Tests.pm:456] # [/<>/blib/lib/HTML/Mason/Tests.pm:263] # [t/13-errors.t:12] # # # Stack: # [/<>/blib/lib/HTML/Mason/Interp.pm:450] # [/<>/blib/lib/HTML/Mason/Request.pm:250] # [/<>/blib/lib/HTML/Mason/Request.pm:212] # [/usr/share/perl5/Class/Container.pm:275] # [/usr/share/perl5/Class/Container.pm:353] # [/<>/blib/lib/HTML/Mason/Interp.pm:348] # [/<>/blib/lib/HTML/Mason/Interp.pm:342] # [/<>/blib/lib/HTML/Mason/Tests.pm:528] # [/<>/blib/lib/HTML/Mason/Tests.pm:515] # [/<>/blib/lib/HTML/Mason/Tests.pm:456] # [/<>/blib/lib/HTML/Mason/Tests.pm:263] # [t/13-errors.t:12] # # - #... but expected ... # - # (?^s:Error during compilation((?!Stack:).)*Stack:((?!Stack:).)*$) # - # Failed test 'top_level_compilation_error' # at /<>/blib/lib/HTML/Mason/Tests.pm line 593. # Running component_error_handler_false (#21): Test error-handling with component_error_handler set to false # Running component_error_Handler_no_upgrade (#22): Test that errors do not become object with component_error_handler set to false # Running component_error_handler_false_fatal_mode (#23): Test error-handling with component_error_handler set to false and error_mode set to fatal # Running component_error_handler_uc_message (#24): Test error-handling with component_error_handler set to a subroutine that upper-cases all text # Running use_bad_module (#25): Use a module with an error # Running require_bad_module_in_once (#26): Require a module with an error in a once block # Looks like you failed 1 test of 26. t/13-errors.t . [...] Test Summary Report --- t/13-errors.t (Wstat: 256 (exited 1) Tests: 26 Failed: 1) Failed test: 20 Non-zero exit status: 1 Files=36, Tests=543, 36 wallclock secs ( 0.13 usr 0.08 sys + 5.50 cusr 1.04 csys = 6.75 CPU) Result: FAIL Failed 1/36 test programs. 1/543 subtests failed. make[1]: *** [Makefile:1017: test_dynamic] Error 255 Looks like it's fixed upstream in 1.60: 1.60 2023-02-11 - Fixed a test failure with Perl blead (5.37.x). Reported by Jim Keenan and diagnosed by Yves Orton. GH #33. -- Niko Tyni nt...@debian.org
Bug#1040492: librust-inout-dev: please provide feature block-padding
Package: librust-inout-dev Version: 0.1.3-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package contains a patch to remove feature block-padding, with no DEP-3 patch headers indicating why. I need that feature. Please have the package provide feature block-padding. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmSm7XQACgkQLHwxRsGg ASHKjQ/9GliAXg0uS4Dqv/750OR8zII6Kz/WWdadfwtwDslv0gwhK5WYVR70myEW 0LEJuczHyMFn4TnVxqQ4sPLGAvrKXiohV/ctiFfszNqrjQpO/4mNbtyuh4AicEQu 5DnYmNdAonVSs9BsyGh0Cn4hkBLrMEsG/biEMvHowy86I40IN+BU6uqi9wGrCpLO ur8Td+fPPAuCK+D2SvJ7EmaYtsVGooqUEhuJld5SzfhIxnKfWTLH068S1rs3Z8cD EXDYZN6G7/P91W6FrjoL/EA0eNLlNX/U2sZPv9kYD9PDcRkJBntKW9xsjsDtKzVO Fi5LUDbo+fIu1FxvxlOAvd/1o/FsiwyNwO28tC/XZMElX1MyNj8q9VPOgTLLQhPs wntdGMqUukb89RsKZWMBxmANuoOwVZOuKDcA6rzeOeU1WVhI6Rd2C+IHTR2vO/67 FaYuCmYlh3yrPU7t+lumRM35THjXcolL8LfWH2vmmOsxBBWY+h+GSuKN1jAZeG1H nTM+44A7ub/fdGEuq5+3CXaAsWLsRYLeWYUXJLmESSIx/QaC397q7zTMtDTOHkj+ afjlx6MZi2SCAT0Dt+/azqw4Kbw7miyCdIVDUDLZcz5z/GfDaghGcYQid/129QYU qJuAqsw8DUzjyS1WGGBdy+eWcT+LbAgG23ORyD/d06yjs8Xpq98= =ILyb -END PGP SIGNATURE-
Bug#1032071: ARM firmware packages included in amd64 installation images
> Hi Magnus, and thanks for the heads-up > > [ . . . ] > > Just because the raspi-firmware package is included on the d-i > installation media, it shouldn't necessarily be installed on an amd64 > host. Or is this coming from live images? > Hi Steve! Speaking for myself: I installed from a live image on the release day of Debian 12.
Bug#1040490: librust-cipher-dev: please provide feature block-padding
Would you like to share why you need that feature? Thank you, Jeremy Bícha
Bug#1032071: ARM firmware packages included in amd64 installation images
Hi Magnus, and thanks for the heads-up On Thu, Jul 06, 2023 at 06:13:28PM +0200, Magnus Wallin wrote: >> Just a head's up that this is starting to affect numerous people. >> If at all possible to prioritize it would be great. >> > >Sorry: I somehow managed to not include links in my previous message. > >Here below are examples of affected individuals and workarounds: >https://forums.debian.net/viewtopic.php?t=155195 >https://forums.debian.net/viewtopic.php?t=154857 Just because the raspi-firmware package is included on the d-i installation media, it shouldn't necessarily be installed on an amd64 host. Or is this coming from live images? -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183
Bug#1040490: librust-cipher-dev: please provide feature block-padding
Package: librust-cipher-dev Version: 0.4.4-2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package contains a patch to remove feature block-padding, with no DEP-3 patch headers indicating why. I need that feature. Please have the package provide feature block-padding. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmSm6oYACgkQLHwxRsGg ASGFtQ//aB2iB7AviOyN384MQxlBKCcIxWOaWia1/uPGoXuA+PWkTAPS2d9+qpMb mfdn0CFugSxstGki6wW8onwdEd+YlinyZlu0pldj8ChTwx7QEmRzbPS9i4v57wzy zK/K4xXdVvVsPFPE7x1Z+PniSap7l3ANcCTFBzpGJYvzPOewRCxuFTT0XY5PnrBO hc3G0IeAW9a0YnqHZpA2OflaiIjx9K73i1M2IsmbCD2rJyfnZYYnicnQzgm+iueW nJYmE87W+h5tFTZUQAR3Ig8zTDjFmRwI/nah1sFlBAAzzurloKY42zTlcgRCkS8S k34tVPcyikty8DXPcFk07u7UEFy0tqPebwfQg4NlnCUdbY8mZjCNdMSiM/or7gFE 54yT4dxicemDu3DtlP5xn7OCIHIPfKHFinJrx+3BOV7PZ+WpaSdc65/ApBi/1FEX 0pI52T5vrKgeKVNwGCV0IAF78OJdfNm/u9kGpbhh6Jz0Z2YBw2m1iclXjRC6ziDd lwAZF6R3l1PQZAvRjS+x8R5s2MsOJ3NP5Oo06DiZGPVRsrAmVULHY6jU0tgdbiJz BkNChU8hRt6QvLcZDzsIA+aWpBwwggfnJcY6ELCQ8250l3wpCgGVVaqpfAgbevl0 UZuL1pEiwW8MDmATGwtsb4e43xn6DmErN2OQGe4duyVLYQZzjhQ= =sd5W -END PGP SIGNATURE-
Bug#1032071: ARM firmware packages included in amd64 installation images
> Just a head's up that this is starting to affect numerous people. > If at all possible to prioritize it would be great. > Sorry: I somehow managed to not include links in my previous message. Here below are examples of affected individuals and workarounds: https://forums.debian.net/viewtopic.php?t=155195 https://forums.debian.net/viewtopic.php?t=154857 -- Sent with Tutanota, enjoy secure & ad-free emails.
Bug#1040489: gsd-media-keys[…]: Failed to grab accelerator for keybinding settings: …
Package: gnome-settings-daemon Version: 43.0-4 In my log I discovered the following 4 failures: … Jul 06 17:21:29 AnonymizedMachineName gsd-sharing[1240]: Failed to StopUnit service: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1 Jul 06 17:21:29 AnonymizedMachineName avahi-daemon[783]: Joining mDNS multicast group on interface wlp179s0.IPv4 with address 192.168.1.49. Jul 06 17:21:29 AnonymizedMachineName avahi-daemon[783]: New relevant interface wlp179s0.IPv4 for mDNS. Jul 06 17:21:29 AnonymizedMachineName avahi-daemon[783]: Registering new address record for 192.168.1.49 on wlp179s0.IPv4. Jul 06 17:21:29 AnonymizedMachineName NetworkManager[833]: [1688656889.3584] device (wlp179s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed') Jul 06 17:21:29 AnonymizedMachineName NetworkManager[833]: [1688656889.3618] device (wlp179s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed') Jul 06 17:21:29 AnonymizedMachineName NetworkManager[833]: [1688656889.3622] device (wlp179s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed') Jul 06 17:21:29 AnonymizedMachineName NetworkManager[833]: [1688656889.3629] manager: NetworkManager state is now CONNECTED_SITE Jul 06 17:21:29 AnonymizedMachineName NetworkManager[833]: [1688656889.3679] device (wlp179s0): Activation: successful, device activated. Jul 06 17:21:29 AnonymizedMachineName NetworkManager[833]: [1688656889.3688] manager: NetworkManager state is now CONNECTED_GLOBAL Jul 06 17:21:29 AnonymizedMachineName systemd[1]: systemd-rfkill.service: Deactivated successfully. Jul 06 17:21:29 AnonymizedMachineName gnome-shell[1133]: Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation Jul 06 17:21:29 AnonymizedMachineName /usr/libexec/gdm-x-session[1077]: dbus-daemon[1077]: [session uid=119 pid=1077] Activating service name='org.gnome.ScreenSaver' requested by ':1.23' (uid=119 pid=1277 comm="/usr/libexec/gsd-power") Jul 06 17:21:29 AnonymizedMachineName gsd-media-keys[1259]: Failed to grab accelerator for keybinding settings:rotate-video-lock Jul 06 17:21:29 AnonymizedMachineName gsd-media-keys[1259]: Failed to grab accelerator for keybinding settings:playback-random Jul 06 17:21:29 AnonymizedMachineName gsd-media-keys[1259]: Failed to grab accelerator for keybinding settings:playback-repeat Jul 06 17:21:29 AnonymizedMachineName gsd-media-keys[1259]: Failed to grab accelerator for keybinding settings:hibernate The last four lines are yellow and refer to a failure to grab some accelerators. According to line 583 of https://github.com/GNOME/gnome-settings-daemon/blob/master/plugins/media-keys/gsd-media-keys-manager.c (which might be the printing these lines), these might be warnings. In plain English, what goes wrong, or what are we warned about? Any remedy?
Bug#1040477: [Pkg-rust-maintainers] Bug#1040477: librust-syn-1-dev fails to coinstall
I'd be very interested in knowing what this self-conflict is supposed to achieve. It is common upstream for there to be multiple semver-incompatible versions of each rust crate in use at a given time. Incompatibilities can range from minor corner cases that are easily patched away to complete redesigns We try to only package one version of each crate at a time, but sometimes that isn't practical. When it becomes impractical we crate semver-suffix packages. The convention in the rust team is that the un-suffixed packages are used for the latest version and suffixed versions are used for any older versions. When packaged crates are installed on a Debian system. They are installed in a path that depends on the upstream version of a crate. This creates a problem though, if the same version is packaged as both a non-suffixed and suffixed version. Something that happens fairly frequently when a new version is introduced e.g. Before: librust-foo-dev version 1.23-1 After: librust-foo-1-dev version 1.23-2 librust-foo-dev version 2.34-1 This doesn't always happen, indeed it didn't happen in the case of syn, because a new upstream release of syn 1.x at the same time at the same time the semver suffix was introduced. However debcargo works on one crate at a time. so it doesn't know if this has happened or not. When this happens, it leads to a file conflict. In an attempt to fix this breaks+replaces were added. Unfortunately these proved to be insufficient because while breaks against virtual packages work, replaces apparently don't. We are in the process of considering several options to fix this, but overall switching to conflicts+replaces seems the least likely to be problematic. Do you encounter the same problem if you replace the breaks with conflicts? if so we would need to do something about it. I think the easiest would probablly be to put a version constraint on the conflicts/replaces. It would mean we would have to take care that semver-suffixed packages had a higher Debian revision than their un-suffixed counterparts, but I think that is managable.
Bug#1032071: ARM firmware packages included in amd64 installation images
On Wed, 5 Jul 2023 17:03:18 +0100 Steve McIntyre wrote: > On Mon, Feb 27, 2023 at 12:36:22PM +0100, Pascal Hambourg wrote: > >Package: debian-cd > >Version: 3.2.0 > >Severity: minor > > > >debian-bookworm-DI-alpha2-amd64-netinst.iso includes firmware packages for > >ARM platforms: > > > > firmware-qcom-soc > > firmware-samsung > > firmware-ti-connectivity > > raspi-firmware > > Now all filtered in debian-cd unless we have an arm* architecture for > the build. > > >These packages add 34 MB to the ISO image, which is not negligible. > > > >Additionally, IIUC the installer only needs firmware for storage, > >network/wireless and sound devices. It uses generic graphic drivers for > >display so it does not need GPU firmware. The netinst image includes firmware > >packages which do not seem to be needed by the installer: > > > > bluez-firmware (Bluetooth) > > dahdi-firmware-nonfree (VoIP) > > firmware-amd-graphics (GPU) > > firmware-ast (GPU) > > firmware-ivtv (MPEG codec) > > firmware-realtek-rtl8723cs-bt (Bluetooth) > > firmware-siano (TV receiver) > > hdmi2usb-fx2-firmware (?) > > > >Among them, firmware-amd-graphics takes 12 MB. > >Is it useful to include these packages in the netinst image ? > >Couldn't they be downloaded from a mirror like other ordinary packages when > >needed ? > > I'm not currently filtering by build type, so I'm leaving these in. > > >Note: it also includes firmware-linux-nonfree which is a meta-package not > >containing any firmware file. > > That's been fixed separately by other changes - we now check the > contents of the firmware .debs too. > > -- > Steve McIntyre, Cambridge, UK.st...@einval.com > "Managing a volunteer open source project is a lot like herding > kittens, except the kittens randomly appear and disappear because they > have day jobs." -- Matt Mackall > > > Just a head's up that this is starting to affect numerous people. If at all possible to prioritize it would be great. -- Sent with Tutanota, enjoy secure & ad-free emails.
Bug#1040488: CVE-2023-31606: REDOS
Source: ruby-redcloth Severity: important Tags: patch Dear Maintainer, Find the following patch in order to fix a REDOS Thanks BastienFrom: Kornelius Kalnbach Date: Wed, 28 Jun 2023 17:24:55 +0200 Subject: CVE-2023-31606 make regex faster with Atomic Grouping MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit origin: https://patch-diff.githubusercontent.com/raw/jgarber/redcloth/pull/75 bug-debian-security: https://security-tracker.debian.org/tracker/CVE-2023-31606 Signed-off-by: Bastien Roucari??s --- lib/redcloth/formatters/html.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/redcloth/formatters/html.rb b/lib/redcloth/formatters/html.rb index b241c99..396c2d0 100644 --- a/lib/redcloth/formatters/html.rb +++ b/lib/redcloth/formatters/html.rb @@ -324,7 +324,7 @@ private # Clean unauthorized tags. def clean_html( text, allowed_tags = BASIC_TAGS ) text.gsub!( /]*?)(\s?\/?)>/ ) do |m| +text.gsub!( /<(\/*)([A-Za-z]\w*+)([^>]*?)(\s?\/?)>/ ) do |m| raw = $~ tag = raw[2].downcase if allowed_tags.has_key? tag signature.asc Description: This is a digitally signed message part.
Bug#1040403: ibus-rime: menu/page_size settings not fully take effect
figured it out. there is one file missing in package rime-data-luna-pinyin cause this problem: pinyin.yaml thanks.
Bug#1040375: reply
[Petter Reinholdtsen] It is unclear to me why you believe this should work. Can you tell me where you got the idea to run the shared library like this? 1. /usr/bin/ssr-glinject from simplescreenrecorder package sets LD_PRELOAD=/usr/$LIB/simplescreenrecorder/libssr-glinject.so which also segmentation faults 2. LD_PRELOAD=/path/to/libssr-glinject.so works if simplescreenrecorder is compiled from source from https://github.com/MaartenBaert/ssr [Petter Reinholdtsen] I only use the package by starting simplescreenrecorder, so I have never seen the problem you are reporting before, and do not understand when it would occur in normal use. How do you "Record OpenGL" glxgears? When I try to launch anything using "OpenGL settings..." silent segmentation fault happens. I know it's segmentation fault (launched "ls") because "sudo dmesg -c" outputs: [ 261.486120] ls[3859]: segfault at ffe8 ip 7f315ab2fd9a sp 7ffc03c91e50 error 5 in libstdc++.so.6.0.30[7f315aa99000+101000] likely on CPU 2 (core 2, socket 0) [ 261.486134] Code: ff eb b4 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 55 48 89 fd 53 48 89 f3 48 83 ec 08 48 8b 06 48 89 77 08 c6 07 00 <48> 8b 78 e8 48 01 f7 48 8b 87 d8 00 00 00 8b 77 20 48 85 c0 74 2a
Bug#116879: ssh-keygen -d undocumented switch
It looks like this bug is obsolete as the switch was removed. Closing this bug as such.
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Hi again, Am Thu, Jul 06, 2023 at 09:56:31AM +0200 schrieb Andreas Tille: > > I've now re-uploaded all 6 packages that are known to be affected by the > graphics ABI change (and verified that it is set properly). I'll > continue now closing the open bugs. After rebuilding quite some packages with autopkgtest failure with r-base (4.3.1-1) it came to my mind (probably to late) that since we do not have any real transition those uploads will probably not help very much since these are not generated with dependencies that are conflicting with the versions in testing and thus the autopkgtests running against packages in testing will keep on failing. Is there any chance to fix this via hinting by release team or should I rather add some "artificial" versioned Depends just to enable the whole set of r-cran-* packages to testing. I'm also wondering whether I should upload the old r-bioc-* packages to finally get the full R stack fit for testing before I'll start the next BioC transition. Alternatively it would probably OK to remove all RC buggy r-bioc-* packages from testing since we need to upload new versions of these packages anyway in the pending BioC transition (I'll file an according bug report soon). Kind regards Andreas. -- http://fam-tille.de
Bug#1040487: libnanopb-dev: please include FindNanopb.cmake
Package: libnanopb-dev Version: 0.4.7-2 Severity: wishlist Dear maintainer, the upstream source of nanopb contains the file extra/FindNanopb.cmake, but it is not installed in the -dev package. The file contains some useful functions to use nanopb via cmake, and is needed by something I'm trying to package. Can you please include it? Thanks and kind regards, Reiner
Bug#1038868: [Pkg-pascal-devel] Bug#1038868: fpc: armhf binaries should have the hard-float ELF flag set
Hello Abou,
On 2023-07-06 01:59, Abou Al Montacir wrote:
> Can you please give the output of fpc -i and fpc -vi?
> This was requested by upstream to investigate the issue.
Of course.
(sid-armhf)root@ariel:/var/tmp# fpc -vi hello.pas
Free Pascal Compiler version 3.2.2+dfsg-21 [2023/06/17] for arm
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Linux for ARMHF
Compiling hello.pas
Linking hello
4 lines compiled, 0.3 sec
(sid-armhf)root@ariel:/var/tmp# fpc -i
Free Pascal Compiler version 3.2.2
Compiler date : 2023/06/17
Compiler CPU target: arm
Supported targets (targets marked with '{*}' are under development):
Linux: Linux for ARMHF
WinCE: WinCE for ARM
gba: GameBoy Advance
PalmOS: PalmOS
nds: Nintendo DS
embedded: Embedded
Symbian: Symbian OS for ARM
iOS: iOS for ARM
Android: Android for ARMEL
AROS: AROS for ARM
NetBSD: NetBSD for ARMHF {*}
Supported CPU instruction sets:
ARMV3,ARMV4,ARMV4T,ARMV5,ARMV5T,ARMV5TE,ARMV5TEJ,ARMV6,ARMV6K,ARMV6T2
ARMV6Z,ARMV6M,ARMV7,ARMV7A,ARMV7R,ARMV7M,ARMV7EM
Supported FPU instruction sets:
SOFT,LIBGCC,FPA,FPA10,FPA11,VFPV2,VFPV3,VFPV3_D16,FPV4_S16,VFPV4
Supported inline assembler modes:
STANDARD
DIVIDED
UNIFIED
Recognized compiler and RTL features:
HEAP,INITFINAL,RTTI,CLASSES,EXCEPTIONS,EXITCODE,ANSISTRINGS,WIDESTRINGS
TEXTIO,CONSOLEIO,FILEIO,RANDOM,VARIANTS,OBJECTS,DYNARRAYS,THREADING
COMMANDARGS,PROCESSES,STACKCHECK,DYNLIBS,SOFTFPU,OBJECTIVEC1,RESOURCES
UNICODESTRINGS
Supported ABI targets:
DEFAULT
EABIHF
Supported Optimizations:
REGVAR
STACKFRAME
PEEPHOLE
LOOPUNROLL
TAILREC
CSE
DFA
ORDERFIELDS
FASTMATH
REMOVEEMPTYPROCS
CONSTPROP
FORCENOSTACKFRAME
Supported Whole Program Optimizations:
All
DEVIRTCALLS
OPTVMTS
SYMBOLLIVENESS
Supported Microcontroller types:
LPC810M021FN8,LPC811M001FDH16,LPC812M101FDH16,LPC812M101FD20
LPC812M101FDH20,LPC1110FD20,LPCFDH20_002,LPCFHN33_101
LPCFHN33_102,LPCFHN33_103,LPCFHN33_201,LPCFHN33_202
LPCFHN33_203,LPC1112FD20_102,LPC1112FDH20_102,LPC1112FDH28_102
LPC1112FHN33_101,LPC1112FHN33_102,LPC1112FHN33_103,LPC1112FHN33_201
LPC1112FHN24_202,LPC1112FHN33_202,LPC1112FHN33_203,LPC1112FHI33_202
LPC1112FHI33_203,LPC1113FHN33_201,LPC1113FHN33_202,LPC1113FHN33_203
LPC1113FHN33_301,LPC1113FHN33_302,LPC1113FHN33_303,LPC1113FBD48_301
LPC1113FBD48_302,LPC1113FBD48_303,LPC1114FDH28_102,LPC1114FN28_102
LPC1114FHN33_201,LPC1114FHN33_202,LPC1114FHN33_203,LPC1114FHN33_301
LPC1114FHN33_302,LPC1114FHN33_303,LPC1114FHN33_333,LPC1114FHI33_302
LPC1114FHI33_303,LPC1114FBD48_301,LPC1114FBD48_302,LPC1114FBD48_303
LPC1114FBD48_323,LPC1114FBD48_333,LPC1115FBD48_303,LPC11C12FBD48_301
LPC11C14FBD48_301,LPC11C22FBD48_301,LPC11C24FBD48_301
LPC11D14FBD100_302,LPC1224FBD48_101,LPC1224FBD48_121,LPC1224FBD64_101
LPC1224FBD64_121,LPC1225FBD48_301,LPC1225FBD48_321,LPC1225FBD64_301
LPC1225FBD64_321,LPC1226FBD48_301,LPC1226FBD64_301,LPC1227FBD48_301
LPC1227FBD64_301,LPC12D27FBD100_301,LPC1311FHN33,LPC1311FHN33_01
LPC1313FHN33,LPC1313FHN33_01,LPC1313FBD48,LPC1313FBD48_01,LPC1315FHN33
LPC1315FBD48,LPC1316FHN33,LPC1316FBD48,LPC1317FHN33,LPC1317FBD48
LPC1317FBD64,LPC1342FHN33,LPC1342FBD48,LPC1343FHN33,LPC1343FBD48
LPC1345FHN33,LPC1345FBD48,LPC1346FHN33,LPC1346FBD48,LPC1347FHN33
LPC1347FBD48,LPC1347FBD64,LPC2114,LPC2124,LPC2194,LPC1754,LPC1756
LPC1758,LPC1764,LPC1766,LPC1768,AT91SAM7S256,AT91SAM7SE256,AT91SAM7X256
AT91SAM7XC256,STM32F030C6,STM32F030C8,STM32F030F4,STM32F030K6
STM32F030R8,STM32F050C4,STM32F050C6,STM32F050F4,STM32F050F6,STM32F050G4
STM32F050G6,STM32F050K4,STM32F050K6,STM32F051C4,STM32F051C6,STM32F051C8
STM32F051K4,STM32F051K6,STM32F051K8,STM32F051R4,STM32F051R6,STM32F051R8
STM32F091CC,STM32F091CB,STM32F091RC,STM32F091RB,STM32F091VC,STM32F091VB
STM32F100X4,STM32F100X6,STM32F100X8,STM32F100XB,STM32F100XC,STM32F100XD
STM32F100XE,STM32F101X4,STM32F101X6,STM32F101X8,STM32F101XB,STM32F101XC
STM32F101XD,STM32F101XE,STM32F101XF,STM32F101XG,STM32F102X4,STM32F102X6
STM32F102X8,STM32F102XB,STM32F103X4,STM32F103X6,STM32F103X8,STM32F103XB
STM32F103XC,STM32F103XD,STM32F103XE,STM32F103XF,STM32F103XG,STM32F107X8
STM32F107XB,STM32F107XC,STM32F105R8,STM32F105RB,STM32F105RC,STM32F105V8
STM32F105VB,STM32F105VC,STM32F107RB,STM32F107RC,STM32F107VB,STM32F107VC
STM32F401CB,STM32F401RB,STM32F401VB,STM32F401CC,STM32F401RC,STM32F401VC
DISCOVERYF401VC,STM32F401CD,STM32F401RD,STM32F401VD,STM32F401CE
STM32F401RE,NUCLEOF401RE,STM32F401VE,STM32F407VG,DISCOVERYF407VG
STM32F407IG,STM32F407ZG,STM32F407VE,STM32F407ZE,STM32F407IE,STM32F411CC
STM32F411RC,STM32F411VC,STM32F411CE,STM32F411RE,NUCLEOF411RE
STM32F411VE,DISCOVERYF411VE,STM32F429VG,STM32F429ZG,STM32F429IG
STM32F429VI,STM32F429ZI,DISCOVERYF429ZI,STM32F429II,STM32F429VE
STM32F429ZE,STM32F429IE,STM32F429BG,STM32F429BI,STM32F429BE,STM32F429NG
STM32F429NI,STM32F429NE,STM32F446MC,STM32F446RC,STM32F446VC,STM32F446ZC
Bug#1020494: openjdk-11: add server JVM variant support for risc-v platform
Control: tags -1 + wontfix not backporting, because it will become difficult to maintain that ourself for security updates. If it's backported upstream, ok. see openjdk-17 for a backported hotspot for riscv64.
Bug#1035736: neovim: Turning off the banner causes the cursor to flicker permanently and CPU usage goes up
On Sun, Jun 18, 2023 at 11:38:58AM +0200, Bastian Venthur wrote: > I think it is related to wl-copy, which is installed and used on all my > machines where this error occurs. More specifically, when browsing /tmp and > turning off the banner, I can actually see folders like > `wl-copy-buffer-X` appearing and disappearing in very quick succession. > I suspect this is related to that buggy behavior. Ah, that makes sense. Netrw fiddles with the clipboard, which is probably causing wl-copy to update files in /tmp, and therefore netrw tries to refresh its display. I thought neovim had patched out most/all of netrw's clipboard stuff, but maybe some got missed. As a workaround, it may be worth trying to setup autocommands to update 'clipboard' such that you don't have unnamedplus in use when you're in a netrw buffer. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1040477: librust-syn-1-dev fails to coinstall
Hi, Quoting Helmut Grohne (2023-07-06 13:27:19) > librust-syn-1-dev has (among other things) the following metadata: > > Provides: librust-syn-1.0.109-dev > Breaks: librust-syn-1.0.109-dev > Multi-Arch: same this looks very bad. > If apt and dose were refusing this situation this were a normal bug at > best. But since dpkg fails badly and leaves the system in an > inconsistent state, I am raising this to rc-severity. Even if we deem > this to be an apt bug or dpkg bug in the end, librust-syn-1-dev must > still be changed since we cannot depend on fixed versions of package > managers being used to install packages. I'd be very interested in knowing what this self-conflict is supposed to achieve. Depending on the answer it might be worth adding a Lintian check so that this doesn't happen again in the future. Thanks! cheers, josch signature.asc Description: signature
Bug#1039952: alacritty: broken rendering with Source Code Pro
On Thu, Jun 29, 2023 at 09:47:26PM +, brian m. carlson wrote: > If the user has configured Source Code Pro as the terminal font, then > text is rendered very tiny and squashed at the top of the window. > > [...] > > I believe this is fixed in 0.12.0 and was tracked upstream at > https://github.com/alacritty/alacritty/issues/6048. This will probably > be fixed simply by updating Alacritty to the latest version, so it would > be great if that could happen. That discussion also suggests updating the version of Source Code Pro will fix the issue. Updating alacritty is going to require packaging/updating more crates, so updating the font may be a quicker solution for this particular problem. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#977830: /usr/libexec/gdm-x-session[…]: dbus-daemon[…]: [session uid=… pid=…] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
found 977830 gdm3/43.0-3 thanks Similar DBus.Error messages still exist after an upgrade to Debian 12: Jul 06 09:48:45 AnonymizedMachineName /usr/libexec/gdm-x-session[1076]: dbus-daemon[1076]: [session uid=119 pid=1076] Successfully activated service 'org.gnome.Shell.Notifications' Jul 06 09:48:45 AnonymizedMachineName kernel: rfkill: input handler disabled Jul 06 09:48:45 AnonymizedMachineName wpa_supplicant[819]: wlp179s0: SME: Trying to authenticate with AnonymizedMAC (SSID='AnonymizedWiFiName' freq=5180 MHz) Jul 06 09:48:45 AnonymizedMachineName kernel: wlp179s0: authenticate with AnonymizedMAC Jul 06 09:48:45 AnonymizedMachineName kernel: wlp179s0: send auth to AnonymizedMAC (try 1/3) Jul 06 09:48:45 AnonymizedMachineName NetworkManager[814]: [1688629725.5309] device (wlp179s0): supplicant interface state: scanning -> authenticating Jul 06 09:48:45 AnonymizedMachineName NetworkManager[814]: [1688629725.5310] device (p2p-dev-wlp179s0): supplicant management interface state: scanning -> authenticating Jul 06 09:48:45 AnonymizedMachineName /usr/libexec/gdm-x-session[1076]: dbus-daemon[1076]: [session uid=119 pid=1076] Activating service name='org.freedesktop.systemd1' requested by ':1.10' (uid=119 pid=1220 comm="/usr/libexec/gsd-sharing") Jul 06 09:48:45 AnonymizedMachineName /usr/libexec/gdm-x-session[1076]: dbus-daemon[1076]: [session uid=119 pid=1076] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1 Jul 06 09:48:45 AnonymizedMachineName gsd-sharing[1220]: Failed to StopUnit service: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1 Jul 06 09:48:45 AnonymizedMachineName gsd-sharing[1220]: Failed to StopUnit service: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
Bug#1034348: at: autopkgtest regression on arm64
On 2023-07-05 18:58:13 +0200, Johannes Christ wrote:
> Is there another way to reproduce this issue?
I'm wondering whether there is a race condition in the test:
# use at command to schedule a job.
echo "echo `date` > ${WORKDIR}/${TMPFILE}" | at now + 1 minute
So the file is expected to be created 1 minute later.
Then in the script:
sleep 2
[...]
sleep 58
if grep -Fq "UTC" $WORKDIR/$TMPFILE
[...]
So the script waits for 1 minute (and some other fast commands)
before checking the existence of the file, which is the wait time
given to "at".
I can see 2 possible issues:
1. The system is a bit slow, and the job execution will take a bit
more time.
2. Time inaccuracies. What are the guaranties given by the system?
--
Vincent Lefèvre - Web:
Bug#1036232: a mutter bug
reassign 1036232 libmutter-11-0 43.4-2 thanks This bug is reassigned to mutter upstream: https://gitlab.gnome.org/GNOME/mutter/-/issues/2891
Bug#1040486: Error while loading 50a2ps: Symbol’s value as variable is void: menu-bar-files-menu
Package: emacs Version: 1:28.2+1-15 Start emacs (it doesn't matter whether you have ~/.emacs or not). The buffer *Messages* begins as follows: Loading /etc/emacs/site-start.d/00debian.el (source)...done Loading /etc/emacs/site-start.d/50a2ps.el (source)... Error while loading 50a2ps: Symbol’s value as variable is void: menu-bar-files-menu This error shouldn't happen. If it matters: the package a2ps 1:4.14-8 is installed.
