Bug#1069480: bochs: FTBFS on armhf: build-dependency not installable: gcc-i686-linux-gnu
Hi Lucas, On Sat, 20 Apr 2024 14:46:39 +0200, Lucas Nussbaum wrote: > Source: bochs > Version: 2.8+dfsg-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on armhf. > > > Relevant part (hopefully): > > +--+ > > | Install package build dependencies > > | > > +--+ > > > > > > Setup apt archive > > - > > > > Merged Build-Depends: bison, debhelper-compat (= 13), flex, libaa1-dev, > > libasound2-dev, libgtk-3-dev, libice-dev, libltdl-dev, libncurses-dev, > > libreadline-dev, libsdl2-dev, libsm-dev, libtool, libwxgtk3.2-dev, > > libx11-dev, libxpm-dev, libz-dev, build-essential, fakeroot, > > acpica-tools, bcc, bin86, docbook-dsssl, gcc-i686-linux-gnu Filtered > > Build-Depends: bison, debhelper-compat (= 13), flex, libaa1-dev, > > libasound2-dev, libgtk-3-dev, libice-dev, libltdl-dev, libncurses-dev, > > libreadline-dev, libsdl2-dev, libsm-dev, libtool, libwxgtk3.2-dev, > > libx11-dev, libxpm-dev, libz-dev, build-essential, fakeroot, > > acpica-tools, bcc, bin86, docbook-dsssl, gcc-i686-linux-gnu dpkg-deb: > > building package 'sbuild-build-depends-main-dummy' in > > '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. Ign:1 > > copy:/<>/apt_archive ./ InRelease Get:2 > > copy:/<>/apt_archive ./ Release [609 B] Ign:3 > > copy:/<>/apt_archive ./ Release.gpg Get:4 > > copy:/<>/apt_archive ./ Sources [915 B] Get:5 > > copy:/<>/apt_archive ./ Packages [908 B] Fetched 2432 B in > > 0s (0 B/s) Reading package lists... Reading package lists... > > > > Install main build dependencies (apt-based resolver) > > > > > > Installing build dependencies > > Reading package lists... > > Building dependency tree... > > Reading state information... > > Some packages could not be installed. This may mean that you have > > requested an impossible situation or if you are using the unstable > > distribution that some required packages have not yet been created > > or been moved out of Incoming. > > The following information may help to resolve the situation: > > > > The following packages have unmet dependencies: > > sbuild-build-depends-main-dummy : Depends: gcc-i686-linux-gnu but it is > > not installable E: Unable to correct problems, you have held broken > > packages. apt-get failed. gcc-i686-linux-gnu is in Build-Depends-Indep, it’s only used to build Arch: all packages. Is there a requirement that these build on armhf? Given that armhf doesn’t have gcc-i686-linux-gnu, I’m not sure how I would go about fixing this, short of asking for the cross-compiler to be added to armhf (which doesn’t seem all that useful). Regards, Stephen pgpOdtyiQY5dR.pgp Description: OpenPGP digital signature
Bug#1068218: RM: chipmunk/experimental -- ROM; cruft from the 64-bit time_t transition
Package: ftp.debian.org Severity: normal Dear FTP team, Please remove chipmunk from experimental. Regards, Stephen
Bug#1067529: libonvif: Please package new upstream version
Hi Petter, Hope you are having a nice day. I am researching my options for making a Debian package for a python program, hope to have something soon. Best Regards, Stephen On Sat, Mar 23, 2024 at 1:51 AM Petter Reinholdtsen wrote: > > Package: onvif-tools > Version: 1.4.4-1 > Severity: wishlist > > According to https://github.com/sr99622/libonvif/tags >, the > latest upstream version of libonvif is 2.0.1, while the latest Debian > package is 1.4.4. > > Please update to the latest upstream version in Debian to make recording > and multistream support available. > > -- > Happy hacking > Petter Reinholdtsen >
Bug#1065924: ITP: lfanew -- tool to manipulate MZ stubs in NE/PE binaries
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: lfanew Version : 0~20230825 Upstream Author : TK Chia * URL : https://codeberg.org/tkchia/lfanew * License : MPL-2.0 Programming Lang: C Description : tool to manipulate MZ stubs in NE/PE binaries lfanew is a tool manipulating the e_lfanew header field in MZ (DOS) binaries. It can - add a .e_lfanew field to an MZ binary, allowing it to be used as a DOS loader stub for a NE or PE binary; - stubify a NE/PE binary by combining it with an MZ stub; - extract a NE/PE binary from a stubified MZ/NE/PE binary pair. This is required to build dosemu2.
Bug#1065664: ITP: smallerc -- single-pass C compiler for 16- and 32-bit platforms
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: smallerc Version : 1.0.1 Upstream Author : Alexey Frunze * URL : https://github.com/alexfru/SmallerC * License : BSD Programming Lang: C Description : single-pass C compiler for 16- and 32-bit x86/MIPS platforms Smaller C is a simple single-pass C compiler with support for most of C89 and C99. It targets 16- and 32-bit x86, and MIPS, on DOS, Windows, Linux, and older versions of macOS. . Smaller C is primarily useful for building DOS and UEFI binaries. This is a prerequisite for dosemu2.
Bug#1065378: ITP: libiir -- DSP IIR realtime filter library
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libiir Version : 1.9.4 Upstream Author : Bernd Porr * URL : https://github.com/berndporr/iir1 * License : MIT Programming Lang: C++ Description : DSP IIR realtime filter library libiir is an infinite impulse response library implementing Butterworth, RBJ, and Chebychev filters. The filter processes data sample by sample for realtime processing. This is a dependency of dosbox-staging. The GH repository is named iir1 but internally the library refers to itself as iir (e.g. for pkg-config). The current soname is libiir.so.1 so the library binary package will end up being called libiir1.
Bug#1062343: htmlcxx: NMU diff for 64-bit time_t transition
On Wed, 14 Feb 2024 09:48:05 +0100, Adrien Nader wrote: > On Wed, Feb 14, 2024, Stephen Kitt wrote: > > Would it be possible to re-run the analysis on htmlcxx with 0.87-4? > > I ran the analysis again but since the new package wasn't being picked > up yet, I added the change as a quirk to the analysis script. The ABI > isn't impacted by time_t nor LFS and I'm therefore also closing this > issue. Thanks for also fixing the issue in the package! > > Like I said in the other issue, consolidated results will not be > available immediately but only in a couple days. Fantastic, thanks for the quick turnaround on both issues! Regards, Stephen pgpmCA4FJJySm.pgp Description: OpenPGP digital signature
Bug#1062343: htmlcxx: NMU diff for 64-bit time_t transition
Hi, On Thu, Feb 01, 2024 at 05:57:37AM +, Graham Inggs wrote: > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > htmlcxx as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). In htmlcxx's case, the analysis failed because of a missing include in one of the headers. I've fixed that in 0.87-4 which is on its way to unstable. > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. Would it be possible to re-run the analysis on htmlcxx with 0.87-4? Thanks, Stephen signature.asc Description: PGP signature
Bug#1062057: chipmunk: NMU diff for 64-bit time_t transition
Hi, On Wed, 31 Jan 2024 08:50:37 +, Steve Langasek wrote: > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > chipmunk as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). […] > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if > information becomes available that your package should not be included in > the transition, there is time for us to amend the planned uploads. I’ve fixed the header problems preventing analysis in 7.0.3-6 (just uploaded to unstable), would it be possible to re-run the ABI analysis? Regards, Stephen pgpqEUBqjjZQk.pgp Description: OpenPGP digital signature
Bug#1063146: fai-setup-storage: New dependency on /usr/lib/fai/subroutines
Actually it's worse than that. Even with the fai-client package installed I cannot run fai-disk-info With version 6.0 I get: /usr/lib/fai/fai-disk-info sda with version 6.2 I get: /usr/lib/fai/fai-disk-info bash: set_bootstick: command not found bash: once_only: command not found bash: all_disks_and_size: command not found bash: checkdisk: command not found which in turn breaks the setup-storage utility. Regards, Stephen Quinney On Mon, 5 Feb 2024 at 11:45, Stephen Quinney wrote: > > Package: fai-setup-storage > Version: 6.2 > Severity: important > X-Debbugs-Cc: step...@jadevine.org.uk > > We use the fai-setup-storage utility in a standalone way (i.e. not > with the rest of FAI) as part of our local installation and > configuration scripts. This has always worked perfectly up to version > 6.0. > > With the recent changes in 6.2 the fai-disk-info script now requires > /usr/lib/fai/subroutines which is in the fai-client package but there > is no dependency declared. If the fai-client package is not installed > setup-storage will now completely fail to run. > > Regards, > > Stephen Quinney > > -- System Information: > Debian Release: 12.4 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 fai-setup-storage depends on: > ii e2fsprogs 1.47.0-2 > pn liblinux-lvm-perl > ii libparse-recdescent-perl 1.967015+dfsg-4 > ii parted3.5-3 > ii perl 5.36.0-7+deb12u1 > > Versions of packages fai-setup-storage recommends: > ii lvm2 2.03.16-2 > pn mdadm > > Versions of packages fai-setup-storage suggests: > ii cryptsetup 2:2.6.1-4~deb12u1 > ii dmsetup2:1.02.185-2 > ii dosfstools 4.2-1 > pn jfsutils > ii ntfs-3g1:2022.10.3-1+b1 > pn reiserfsprogs > pn xfsprogs
Bug#1063146: fai-setup-storage: New dependency on /usr/lib/fai/subroutines
Package: fai-setup-storage Version: 6.2 Severity: important X-Debbugs-Cc: step...@jadevine.org.uk We use the fai-setup-storage utility in a standalone way (i.e. not with the rest of FAI) as part of our local installation and configuration scripts. This has always worked perfectly up to version 6.0. With the recent changes in 6.2 the fai-disk-info script now requires /usr/lib/fai/subroutines which is in the fai-client package but there is no dependency declared. If the fai-client package is not installed setup-storage will now completely fail to run. Regards, Stephen Quinney -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 fai-setup-storage depends on: ii e2fsprogs 1.47.0-2 pn liblinux-lvm-perl ii libparse-recdescent-perl 1.967015+dfsg-4 ii parted3.5-3 ii perl 5.36.0-7+deb12u1 Versions of packages fai-setup-storage recommends: ii lvm2 2.03.16-2 pn mdadm Versions of packages fai-setup-storage suggests: ii cryptsetup 2:2.6.1-4~deb12u1 ii dmsetup2:1.02.185-2 ii dosfstools 4.2-1 pn jfsutils ii ntfs-3g1:2022.10.3-1+b1 pn reiserfsprogs pn xfsprogs
Bug#985184: reminiscence not anymore licensed
On Mon, 18 Dec 2023 00:38:26 +0100, Alexandre Detiste wrote: > I think until the licensing problem is not resolved, > this old version of the game should not be included in a release. Why not? The license of the old version is still valid... Regards, Stephen pgpyLcOab2FeX.pgp Description: OpenPGP digital signature
Bug#1058491: add a "Date" control field (for reproducibility)
Package: equivs
Version: 2.3.1
Tags: patch
Please accept this enhancement to add a "Date" field to the
equivs-build control file.
If supplied, the Date value will be used instead of the current time
to set the date/time in the generated debian/changelog file.
Sometimes the caller does not need to supply an entire changelog file
but just needs to set the package date. Setting the date to a
specific time lets equivs-build be part of a reproducible build chain.
--- equivs-2.3.1/usr/bin/equivs-build
+++ equivs/usr/bin/equivs-build
@@ -339,9 +339,14 @@ sub make_changelog {
my ($version, $suite, $date);
$version = $control->{'Version'} || "1.0";
$suite = $control->{'Suite'} || "unstable";
- chomp ($date = qx(date -R));
+ my $date_to_use_arg = "";
+ if (my $control_dateq = $control->{'Date'}) {
+ $control_dateq =~ s/'/'\\\''/g;
+ $date_to_use_arg = "--date='$control_dateq'";
+ }
+ chomp ($date = qx(date -R $date_to_use_arg));
open OUT, '>', "$builddir/debian/changelog" or
die "Couldn't write changelog: $!\n";
print OUT <. If not specified, B
+will generate one. Some parts of the generated F can be
+controlled; see the Version and Date fields.
=item Version:
If you don't use a local changelog, equivs will create a
dummy one. As the version of the package is defined in the
changelog, equivs will assume the version 1.0. With this
field, you can set an explicit version.
+=item Date:
+
+If B generates a F file, it will use this
+time as the package release date. The date defaults to the current time.
+The Date string can be anything C> will accept.
+
Bug#1058049: [mk-build-deps] "arch all" packages are architecture-specific
Package: devscripts
Version: 2.23.6
Tags: patch
The packages mk-build-deps builds work on only one architecture, even if the
built package architecture is "all". This is because the generated package
always includes a dependency on "build-essential:", where is a
specific architecture.
Because of this limitation, when I need a build-depends package for a second
architecture, I must re-run mk-build-deps. This gives me a new package with
the same name and same architecture, but a different Depends line.
The problem is fixed with this 2-line patch, which removes the architecture
specification from "build-essential" when building an "all" package.
--- devscripts-2.23.6/scripts/mk-build-deps.pl
+++ devscripts/scripts/mk-build-deps.pl
@@ -566,7 +566,8 @@ sub build_equiv {
deps_iterate($negative, $handle_native_archqual);
my $pkgname;
-my $buildess = "build-essential:$buildarch";
+my $buildess = "build-essential";
+$buildess .= ":$buildarch" if $packagearch ne "all";
if ($buildarch eq $hostarch) {
$pkgname = "$opts->{name}-$opts->{type}";
} else {
Bug#717778: checkinstall: mkdir -p fails (fstrans broken again?)
Sorry for the delay, I uploaded checkinstall 1.6.2+git20170426.d24a630-4 which has this fix. Stephen On Oct 23, 2023 at 9:58:53 AM, Stephen Gelman wrote: > It’s maintained, however the upstream no longer exists so I need to vet > any patches myself. I will take a look at the provided patch and get it > uploaded! > > Stephen > > On Oct 20, 2023 at 8:56:31 AM, Siddh Raman Pant wrote: > >> Is the package no longer maintained? If it is, it should be removed from >> the repo. >> >> It is 2023, and checkinstall is still broken. >> >> Thanks, >> Siddh >> >> On Sat, 02 Jul 2022 02:18:35 + Geoffrey Hausheer < >> debianbug...@pblue.org> wrote: >> >> Package: checkinstall >> >> Version: 1.6.2+git20170426.d24a630-2 >> >> Followup-For: Bug #717778 >> >> X-Debbugs-Cc: debianbug...@pblue.org >> >> >> It appears that the root of this issue may be in instw_setpathrel >> >> Specifically, the 'stat' command that is used to get the length of a >> symlink should >> >> be 'lstat' instead. >> >> >> Here is a 1 line-patch that addressed the issue for me: >> >> >> --- a/installwatch/installwatch.c >> >> +++ b/installwatch/installwatch.c >> >> @@ -1691,7 +1691,7 @@ >> >> if ( dirfd == AT_FDCWD ) return instw_setpath(instw, relpath); >> >> >> >> snprintf(proc_path, PROC_PATH_LEN, "/proc/self/fd/%d", dirfd); >> >> - if(true_stat(proc_path, ) == -1) >> >> + if(true_lstat(proc_path, ) == -1) >> >> goto out; >> >> if(!(newpath = malloc(s.st_size+strlen(relpath)+2))) >> >> goto out; >> >> >> >> >> -- System Information: >> >> Debian Release: 11.3 >> >> APT prefers stable-updates >> >> APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, >> 'stable') >> >> Architecture: amd64 (x86_64) >> >> >> Kernel: Linux 5.10.67-zfs (SMP w/4 CPU threads) >> >> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, >> TAINT_UNSIGNED_MODULE >> >> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set >> >> Shell: /bin/sh linked to /bin/dash >> >> Init: unable to detect >> >> >> Versions of packages checkinstall depends on: >> >> ii dpkg-dev1.20.10 >> >> ii file1:5.39-3 >> >> ii libc6 2.31-13+deb11u3 >> >> ii sensible-utils 0.0.14 >> >> >> Versions of packages checkinstall recommends: >> >> ii make 4.3-4.1 >> >> >> Versions of packages checkinstall suggests: >> >> ii gettext 0.21-4 >> >> >> -- Configuration Files: >> >> /etc/checkinstallrc changed [not included] >> >> >> -- no debconf information >> >> >> >>
Bug#1031063: wormhole-william: FTBFS randomly (failing tests)
Ah sorry, I meant to get to this and haven't had a chance. I'd really appreciate it if you did a team upload! Stephen On Tue, Oct 24, 2023 at 3:03 AM Santiago Vila wrote: > > reopen 1031063 > fixed 1031063 1.0.6-3 > owner 1031063 ! > thanks > > Hi. I'm going to do a "Team upload" to fix this in stable. > > Thanks.
Bug#717778: checkinstall: mkdir -p fails (fstrans broken again?)
It’s maintained, however the upstream no longer exists so I need to vet any patches myself. I will take a look at the provided patch and get it uploaded! Stephen On Oct 20, 2023 at 8:56:31 AM, Siddh Raman Pant wrote: > Is the package no longer maintained? If it is, it should be removed from > the repo. > > It is 2023, and checkinstall is still broken. > > Thanks, > Siddh > > On Sat, 02 Jul 2022 02:18:35 + Geoffrey Hausheer < > debianbug...@pblue.org> wrote: > > Package: checkinstall > > Version: 1.6.2+git20170426.d24a630-2 > > Followup-For: Bug #717778 > > X-Debbugs-Cc: debianbug...@pblue.org > > > It appears that the root of this issue may be in instw_setpathrel > > Specifically, the 'stat' command that is used to get the length of a > symlink should > > be 'lstat' instead. > > > Here is a 1 line-patch that addressed the issue for me: > > > --- a/installwatch/installwatch.c > > +++ b/installwatch/installwatch.c > > @@ -1691,7 +1691,7 @@ > > if ( dirfd == AT_FDCWD ) return instw_setpath(instw, relpath); > > > > snprintf(proc_path, PROC_PATH_LEN, "/proc/self/fd/%d", dirfd); > > - if(true_stat(proc_path, ) == -1) > > + if(true_lstat(proc_path, ) == -1) > > goto out; > > if(!(newpath = malloc(s.st_size+strlen(relpath)+2))) > > goto out; > > > > > -- System Information: > > Debian Release: 11.3 > > APT prefers stable-updates > > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > > Architecture: amd64 (x86_64) > > > Kernel: Linux 5.10.67-zfs (SMP w/4 CPU threads) > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > > Shell: /bin/sh linked to /bin/dash > > Init: unable to detect > > > Versions of packages checkinstall depends on: > > ii dpkg-dev1.20.10 > > ii file1:5.39-3 > > ii libc6 2.31-13+deb11u3 > > ii sensible-utils 0.0.14 > > > Versions of packages checkinstall recommends: > > ii make 4.3-4.1 > > > Versions of packages checkinstall suggests: > > ii gettext 0.21-4 > > > -- Configuration Files: > > /etc/checkinstallrc changed [not included] > > > -- no debconf information > > > >
Bug#1054183: RFP: pdfbox -- PDF utilities (based on Apache PDFBox)
Package: wnpp Severity: wishlist X-Debbugs-Cc: bhs2...@gmail.com * Package name: pdfbox Version : 3.0.0 Upstream Contact: PDFBox Users Mailing List * URL : https://pdfbox.apache.org/ * License : Apache License 2.0 Programming Lang: Java Description : PDF utilities (based on Apache PDFBox) The Apache PDFBox® library is an open source Java tool for working with PDF documents. This project allows creation of new PDF documents, manipulation of existing documents and the ability to extract content from documents. This package would provide the PDFBox command-line utility (https://pdfbox.apache.org/3.0/commandline.html), including a desktop launcher for the 'debug' subcommand which invokes the graphical PDF Debugger application. Debian already packages the PDFBox library (as libpdfbox-java and libpdfbox2-java), but does not yet package these utilities or the included PDF Debugger. This project shares similarities with Poppler, but contains some valuable features which Poppler alone does not.
Bug#1054148: mingw-w64: please enable support for the mcf thread model
Package: mingw-w64 Version: 8.0.0-1 Severity: wishlist X-Debbugs-Cc: LIU Hao Dear Maintainer, On Wed, 4 Oct 2023 21:29:07 +0800, LIU Hao wrote: > I have submitted a new thread model for mingw-w64 targets, namely the `mcf` > thread model [1], which can be enabled by passing `--enable-threads=mcf` > when configuring GCC. The mcfgthread library [2] is required to have been > built and installed after the mingw-w64 CRT; it doesn't depend on the CRT > though, only depends on some import libraries for system DLLs. > > AFAICT Debian provides GCC with the `posix` and `win32` thread model. Would > you please consider providing an `mcf` one as well? So far I have made > similar proposals to winlibs [3] and mingw-builds [4], hopefully we can > have it on Debian as well. > > > [1] > https://github.com/gcc-mirror/gcc/commit/f036d759ecee538555fa8c6b11963e4033732463 > [2] https://github.com/lhmouse/mcfgthread [3] > https://github.com/brechtsanders/winlibs_mingw/releases/tag/13.2.0mcf-16.0.6-11.0.0-ucrt-r1 > [4] > https://github.com/niXman/mingw-builds/commit/b876df909372d7fb0ab21aa58ce1b7c0df813dbe
Bug#1052646: xrdp: New release with security fixes
Source: xrdp Version: 0.9.21.1-1 Severity: important X-Debbugs-Cc: step...@jadevine.org.uk Dear Maintainer, A new version of xrdp - 0.9.23 - was released on 2023/08/31 which contains an important security fix for CVE-2023-40184: "Improper handling of session establishment errors allows bypassing OS-level session restrictions". I just wanted to check, will this be available in unstable soon and backported to stable? Thanks for your work on maintaining the xrdp package, it's much appreciated! Regards, Stephen Quinney -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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
Bug#1051753: dosbox-x: FTBFS on big-endian architectures
Package: src:dosbox-x Version: 2023.09.01+dfsg-1 Tags: upstream ftbfs Forwarded: https://github.com/joncampbell123/dosbox-x/issues/3751 Dear Maintainer, dosbox-x fails to build on big-endian platforms: g++ -DHAVE_CONFIG_H -I. -I../../../src/cpu -I../.. -I../../../include -I../../../src -Wno-int-to-void-pointer-cast -Wno-address-of-packed-member -Wno-format-zero-length -Wno-missing-field-initializers -Wno-strict-aliasing -Wno-implicit-fallthrough -Wno-deprecated-declarations -Wconversion-null -Wsign-promo -Wlogical-op -Wno-error=format-security -pedantic -Wunused -Wextra -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/SDL2 -D_REENTRANT -I/<> -I/<>/vs/sdlnet/linux-host/include -I/<>/vs/sdlnet/linux-host/include/SDL -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/slirp -I/usr/include/glib-2.0 -I/usr/lib/s390x-linux-gnu/glib-2.0/include -g -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu++14 -O2 -Wall -Wextra -Wunused -pedantic -Wno-error=format-security -Wlogical-op -Wsign-promo -Wconversion-null -Wno-deprecated-declarations -Wno-implicit-fallthrough -Wno-strict-aliasing -Wno-missing-field-initializers -Wno-format-zero-length -Wno-address-of-packed-member -Wno-int-to-void-pointer-cast -I/<> -I/<>/vs/sdlnet/linux-host/include -I/<>/vs/sdlnet/linux-host/include/SDL -D_XOPEN_SOURCE=700 -D_POSIX_C_SOURCE=200809L -c -o core_normal_8086.o ../../../src/cpu/core_normal_8086.cpp In file included from ../../../src/cpu/core_normal/prefix_0f.h:2180, from ../../../src/cpu/core_normal.cpp:181: ../../../src/cpu/core_normal/prefix_0f_mmx.h: In function ‘Bits CPU_Core_Normal_Run()’: ../../../src/cpu/core_normal/prefix_0f_mmx.h:1080:35: error: ‘union MMX_reg’ has no member named ‘uwa’; did you mean ‘uw’? 1080 | dest->uw.w0 = src.uwa[ imm8 &3u]; /* uwa[0] is uw.w0, see MMX_reg union */ | ^~~ | uw ../../../src/cpu/core_normal/prefix_0f_mmx.h:1081:35: error: ‘union MMX_reg’ has no member named ‘uwa’; did you mean ‘uw’? 1081 | dest->uw.w1 = src.uwa[(imm8>>2u)&3u]; | ^~~ | uw ../../../src/cpu/core_normal/prefix_0f_mmx.h:1082:35: error: ‘union MMX_reg’ has no member named ‘uwa’; did you mean ‘uw’? 1082 | dest->uw.w2 = src.uwa[(imm8>>4u)&3u]; | ^~~ | uw ../../../src/cpu/core_normal/prefix_0f_mmx.h:1083:35: error: ‘union MMX_reg’ has no member named ‘uwa’; did you mean ‘uw’? 1083 | dest->uw.w3 = src.uwa[(imm8>>6u)&3u]; | ^~~ | uw In file included from ../../../src/cpu/core_normal/prefix_66_0f.h:541, from ../../../src/cpu/core_normal.cpp:183: ../../../src/cpu/core_normal/prefix_0f_mmx.h:1080:35: error: ‘union MMX_reg’ has no member named ‘uwa’; did you mean ‘uw’? 1080 | dest->uw.w0 = src.uwa[ imm8 &3u]; /* uwa[0] is uw.w0, see MMX_reg union */ | ^~~ | uw ../../../src/cpu/core_normal/prefix_0f_mmx.h:1081:35: error: ‘union MMX_reg’ has no member named ‘uwa’; did you mean ‘uw’? 1081 | dest->uw.w1 = src.uwa[(imm8>>2u)&3u]; | ^~~ | uw ../../../src/cpu/core_normal/prefix_0f_mmx.h:1082:35: error: ‘union MMX_reg’ has no member named ‘uwa’; did you mean ‘uw’? 1082 | dest->uw.w2 = src.uwa[(imm8>>4u)&3u]; | ^~~ | uw ../../../src/cpu/core_normal/prefix_0f_mmx.h:1083:35: error: ‘union MMX_reg’ has no member named ‘uwa’; did you mean ‘uw’? 1083 | dest->uw.w3 = src.uwa[(imm8>>6u)&3u]; | ^~~ | uw Regards, Stephen
Bug#1038023: angband: Depends on SDL 1.2
Hi Chris, On Thu, 7 Sep 2023 22:47:05 +0100, Chris Carr wrote: > I would also like to build a nonfree package (to replace angband-audio, > which can safely be removed) – Angband ships with non-free graphical tiles > as well as non-free sounds. I can create a DFSG-free orig.tar.gz, and a > non-free one with the tiles and sounds. I can then configure debhelper to > detect the presence or absence of the non-free tarball and build either two > packages (angband and angband-data) or three (including the non-free one). > > But I don’t know how if that will render the *source* package non-free. I > and many others spent much of the late 2000s tracking down all the original > contributors and persuading them to re-licence their code under the GPL > (which wasn’t known when they wrote it), so it was a big achievement to get > Angband into main from 3.0. So I would like to keep the source package free > if possible, even if this means having to maintain two source packages > (which I don’t know how to do). In this scenario, you need two completely separate source packages: one with a tarball containing only DFSG-free content, the other containing anything non-free (and potentially DFSG-free stuff as well, if it makes sense). This means separate packaging as well; at least that way you don’t have to worry about trying to detect whether you’re building the free or non-free package. Maintaining two source packages isn’t any harder than maintaining one, you just need to do it twice. And yes, that means two separate Salsa repos too (you could technically combine everything using branches, but that’s a recipe for mix-ups). Basically, the same situation as you have today with the separate angband and angband-audio source packages. > I have a number of questions about the packaging process (sbuild can’t > install imagemagick; dh_autoconf rewrites install-sh; version deps of libc > and sdl-mixer-dev have increased unnecessarily; many more) – would anyone > be willing to mentor me to get these things fixed? Feel free to ping me, or ask on debian-mentors. Regards, Stephen pgpIY4EvARCjx.pgp Description: OpenPGP digital signature
Bug#999977: qxw: depends on obsolete pcre3 library
Hi,
On Mon, 31 Jul 2023 04:44:14 +0100, Nick Morrott
wrote:
> On 2023/07/22 at 08:43, Stephen Kitt wrote:
> >aOn Sat, 22 Jul 2023 16:14:06 +0200, Bastian Germann
> >wrote:
> > > I suggest to remove the package. I do not think upstream will deal with
> > > this.
> >
> > qxw’s usage of pcre seems simple enough, I’ll try to come up with a patch.
>
> In the meantime, I will look to spend some time understanding the
> pcre3->pcre2 migration and patching qxw in the short term, if Stephen does
> not have time to do so.
It took me longer to get round to this than I hoped, but here is a patch for
qxw. I’ve already forwarded it upstream.
Regards,
Stephen
Description: Port to pcre2
Author: Stephen Kitt
Forwarded: q...@quinapalus.com
--- a/Makefile
+++ b/Makefile
@@ -27,7 +27,7 @@
PKG_CONFIG ?= pkg-config
CFLAGS := -Wall -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wno-deprecated-declarations `$(PKG_CONFIG) --cflags glib-2.0` `$(PKG_CONFIG) --cflags gtk+-2.0` -I/opt/local/include `dpkg-buildflags --get CFLAGS` `dpkg-buildflags --get CPPFLAGS` -Wpedantic -Wextra -Wno-unused-parameter
# CFLAGS := -Wall -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security `$(PKG_CONFIG) --cflags glib-2.0` `$(PKG_CONFIG) --cflags gtk+-2.0` -I/opt/local/include
-LFLAGS := -Wl,-Bsymbolic-functions -Wl,-z,relro -L/opt/local/lib `$(PKG_CONFIG) --libs glib-2.0` `$(PKG_CONFIG) --libs gtk+-2.0` -lm -ldl -lpcre -pthread -lgthread-2.0 `dpkg-buildflags --get LDFLAGS`
+LFLAGS := -Wl,-Bsymbolic-functions -Wl,-z,relro -L/opt/local/lib `$(PKG_CONFIG) --libs glib-2.0` `$(PKG_CONFIG) --libs gtk+-2.0` -lm -ldl `pcre2-config --libs8` -pthread -lgthread-2.0 `dpkg-buildflags --get LDFLAGS`
# -lrt as well?
ifneq ($(filter deb,$(MAKECMDGOALS)),)
CFLAGS:= $(CFLAGS) -g
--- a/dicts.c
+++ b/dicts.c
@@ -23,7 +23,8 @@
*/
-#include
+#define PCRE2_CODE_UNIT_WIDTH 8
+#include
#include// required for string conversion functions
#include
@@ -447,13 +448,13 @@
// Add a new dictionary word with UTF-8 citation form s0
// dictionary number dn, score f. Return 1 if added, 0 if not, -2 for out of memory
-static int adddictword(char*s0,int dn,pcre*sre,pcre*are,float f) {
+static int adddictword(char*s0,int dn,pcre2_code*sre,pcre2_code*are,float f) {
int c,c0,i,l0,l1,l2;
uchar t[MXLE+1],u;
char s1[MXLE*16+1];
char s2[MXLE+1];
struct memblk*q;
- int pcreov[120];
+ pcre2_match_data * pcremd;
l0=strlen(s0);
utf8touchars(t,s0,MXLE+1);
@@ -507,24 +508,28 @@
// s2 contains canonicalised form in internal character code, length l2 1<=l2<=MXLE
dst_lines[dn]++;
+ pcremd = pcre2_match_data_create(120, NULL);
if(sre) {
-i=pcre_exec(sre,0,s0,l0,0,0,pcreov,120);
+i=pcre2_match(sre,(PCRE2_SPTR)s0,l0,0,0,pcremd,NULL);
DEB_DI if(i<-1) printf("PCRE error %d\n",i);
if(i<0) {
DEB_DV printf(" failed file filter\n");
+ pcre2_match_data_free(pcremd);
return 0; // failed match
}
}
dst_lines_f[dn]++;
if(are) {
-i=pcre_exec(are,0,s1,l1,0,0,pcreov,120);
+i=pcre2_match(are,(PCRE2_SPTR)s1,l1,0,0,pcremd,NULL);
DEB_DI if(i<-1) printf("PCRE error %d\n",i);
if(i<0) {
DEB_DV printf(" failed answer filter\n");
+ pcre2_match_data_free(pcremd);
return 0; // failed match
}
}
dst_lines_fa[dn]++;
+ pcre2_match_data_free(pcremd);
if(memblkp==NULL||memblkl+2+l0+1+l2+1>MEMBLK) { // allocate more memory if needed (this always happens on first pass round loop)
q=(struct memblk*)malloc(sizeof(struct memblk));
@@ -574,7 +579,7 @@
}
// Attempt to load a .TSD file. Return number of words >=0 on success, <0 on error.
-static int loadtsd(FILE*fp,int format,int dn,pcre*sre,pcre*are) {
+static int loadtsd(FILE*fp,int format,int dn,pcre2_code*sre,pcre2_code*are) {
int c,i,j,l,m,ml,n,u,nw;
int hoff[MXLE+1]; // file offsets into Huffman coded block
int dcount[MXLE+1]; // number of words of each length
@@ -683,9 +688,10 @@
float f;
int mode,owd,rc;
- pcre*sre,*are;
- const char*pcreerr;
- int pcreerroff;
+ pcre2_code*sre,*are;
+ int pcreerr;
+ PCRE2_SIZE pcreerroff;
+ PCRE2_UCHAR pcreerrmsg[256];
char sfilter[SLEN+1];
char afilter[SLEN+1];
GError *error = NULL;
@@ -709,18 +715,20 @@
strcpy(sfilter,dsfilters[dn]);
if(!strcmp(sfilter,"")) sre=0;
else {
-sre=pcre_compile(sfilter,PCRE_CASELESS|PCRE_UTF8|PCRE_UCP,,,0);
-if(pcreerr) {
- sprintf(t,"Dictionary %d\nBad file filter syntax: %.100s",dn+1,pcreerr);
+sre=pcre2_compile((PCRE2_SPTR)sfilter,PCRE2_ZERO_TERMINATED,PCRE2_CASELESS|PCRE2_UTF|PCRE2_UCP,,,0);
+if(sre == NULL) {
+ pcre2_get_error_message(pcreerr, pcreerrmsg, sizeof pcreerrmsg);
+ sprintf(t,"Diction
Bug#1050316: apt-setup: Unable to use local repo when installing older release
Source: apt-setup Version: 1:0.183 Severity: normal Tags: d-i X-Debbugs-Cc: ssg...@debian.org I sometimes use the current stable d-i to install the n-1 release when I need to install on hardware that requires a newer kernel, then I install the backport kernel in the preseed so the system boots. With the bookworm debian-installer, my local apt repo does not get successfully added to the system. After some debugging, I determined the issue is here: https://salsa.debian.org/installer-team/apt-setup/-/blob/master/generators/60local#L46 The /etc/apt/keyrings directory wasn't added to the apt package until apt 2.4.0, but bullseye only ships with 2.2.4. The fix here is simple and I believe it to be low risk: the generator just needs to run "mkdir -p /etc/apt/keyrings" at the beginning of 60local. Since newer versions of apt already create that empty directory it will be a no-op for them. In case anyone else runs into this issue and stumbles onto this bug, I was able to work around it by adding the following to my preseed: d-i partman/early_command string printf "#!/bin/sh\nmkdir -p \$ROOT/etc/apt/keyrings\n" > /usr/lib/apt-setup/generators/02fixbug && chmod +x /usr/lib/apt-setup/generators/02fixbug I understand that the current release is the main priority of d-i but given the fix seems to be low risk it would be appreciated if it could be fixed in stable! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1050056: libz-mingw-w64 build-depends on pev
Hi David, On Fri, 18 Aug 2023 23:05:29 -0300, David da Silva Polverari wrote: > Your package build-depends on pev, but it has been renamed to readpe due > to upstream changes. > > readpe is still in experimental. I will wait 15 days before uploading it > to unstable. Please let me know if you need more time, or if you had any > problems with it. Any feedback/testing is appreciated. Since there’s a transitional pev package depending on readpe, there shouldn’t be any adverse effect: libz-mingw-w64 will still be buildable, since its build-dependency on pev will pull in readpe. Once readpe is in unstable I’ll upload an updated libz-mingw-w64 package build-depending only on readpe. Regards, Stephen pgpGqz_nqR30z.pgp Description: OpenPGP digital signature
Bug#967356: fyre: depends on deprecated GTK 2
Hi Bastian, On Sat, 12 Aug 2023 15:12:06 +0200, Bastian Germann wrote: > Is it worth to keep such an ancient program as fyre in Debian? > It might be time to drop it. You’re right, it isn’t worth it, I’ll file a removal request. Regards, Stephen pgpzjFhby3m96.pgp Description: OpenPGP digital signature
Bug#1049941: RM: fyre -- ROM; abandoned upstream, low popcon
Package: ftp.debian.org Severity: normal Dear FTP team, Please remove fyre, it’s abandoned upstream, depends on obsolete libraries and has a very low popcon. Regards, Stephen
Bug#1043539: project: Forwarding of @debian.org mails to gmail broken
Greetings, * Cord Beermann (c...@debian.org) wrote: > As listmaster i can confirm that it is a big problem to deliver Mails to > gmail/outlook/yahoo. Yahoo Subscribers are mostly gone by now because they > bounced a lot, for gmail it is so much that we just ignore bounces because of > those rules. As a maintainer or some pretty big lists ... we don't have *that* much trouble delivering to gmail, or others for that matter. > | helgefjell.de descriptive text "v=spf1 ip4:142.132.201.35 mx ~all" > > so you flagged your mail has to come from that IP (or the MX) and from other > sources it should be considered suspicious. ... but if it's DKIM signed, then it'll generally get delivered properly. > SRS/ARC and so on are just dirty patches that try to fix things that were > broken before, but they will break even more things like Mail signing. ARC doesn't break DKIM signatures (unless someone's got a very broken DKIM setup which over-signs ARC headers ... but if so, then that's on them). Thanks, Stephen signature.asc Description: PGP signature
Bug#1043539: project: Forwarding of @debian.org mails to gmail broken
Greetings, * Mattia Rizzolo (mat...@debian.org) wrote: > Alternatively, I wonder if ARC nowadays is respected enough (and if > Google cares about it)... I personally don't have any system with ARC > under my care. Sadly, no, they don't seem to care one bit about ARC, except possibly if it's their own ARC sigs. If someone has some idea how to get them to care about ARC, I'd love to hear about it, as I have folks on the one hand who view DKIM/DMARC as too painful to set up but then they end up with bounces from gmail due to my forwarding of messages through my server (which are being ARC-signed by it and pass on that the SPF check was successful when they arrived to my server)... I'd encourage everyone running their own email servers to please get DKIM/DMARC/ARC/SPF set up. Yeah, it's annoying, but it's not actually all *that* bad to do. Thanks, Stephen signature.asc Description: PGP signature
Bug#1042415: ruby-aws-partitions: Package missing partitions.json
Package: ruby-aws-partitions Version: 1.653.0-1 Severity: grave Tags: patch Justification: renders package unusable X-Debbugs-Cc: ssg...@debian.org In version 1.653.0-1, /usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/partitions.json is not present. It is there in version 1.354.0-2 in bullseye. Without that file, any actual use of this gem fails: $ irb irb(main):001:0> require 'aws-partitions' => true irb(main):002:1* Aws::Partitions.each do |partition| irb(main):003:1* puts partition.name irb(main):004:0> end /usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:225:in `read': No such file or directory @ rb_sysopen - /usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/partitions.json (Errno::ENOENT) from /usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:225:in `defaults' from /usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:214:in `default_partition_list' from /usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:137:in `each' from (irb):2:in `' from /usr/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `' from /usr/bin/irb:25:in `load' from /usr/bin/irb:25:in `' Patch to fix is attached -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ruby-aws-partitions depends on: ii ruby 1:3.1 ruby-aws-partitions recommends no packages. ruby-aws-partitions suggests no packages. -- no debconf information diff -Nru ruby-aws-partitions-1.653.0/debian/changelog ruby-aws-partitions-1.653.0/debian/changelog --- ruby-aws-partitions-1.653.0/debian/changelog2022-10-30 08:49:35.0 -0500 +++ ruby-aws-partitions-1.653.0/debian/changelog2023-07-27 17:39:10.0 -0500 @@ -1,3 +1,11 @@ +ruby-aws-partitions (1.653.0-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Change DH_RUBY_GEM_INSTALL_WHITELIST_APPEND to DH_RUBY_GEM_INSTALL_INCLUDE +in debian/rules to work with newer gem2deb + + -- Stephen Gelman Thu, 27 Jul 2023 17:39:10 -0500 + ruby-aws-partitions (1.653.0-1) unstable; urgency=medium * Team Upload diff -Nru ruby-aws-partitions-1.653.0/debian/rules ruby-aws-partitions-1.653.0/debian/rules --- ruby-aws-partitions-1.653.0/debian/rules2022-10-30 08:49:35.0 -0500 +++ ruby-aws-partitions-1.653.0/debian/rules2023-07-27 17:36:38.0 -0500 @@ -2,7 +2,7 @@ export GEM2DEB_TEST_RUNNER = --check-dependencies export DH_RUBY = --gem-install -export DH_RUBY_GEM_INSTALL_WHITELIST_APPEND := partitions.json +export DH_RUBY_GEM_INSTALL_INCLUDE := partitions.json %: dh $@ --buildsystem=ruby --with ruby
Bug#999977: qxw: depends on obsolete pcre3 library
On Sat, 22 Jul 2023 16:14:06 +0200, Bastian Germann wrote: > I suggest to remove the package. I do not think upstream will deal with > this. qxw’s usage of pcre seems simple enough, I’ll try to come up with a patch. Regards, Stephen pgpj3AFhwSrrc.pgp Description: OpenPGP digital signature
Bug#1041151: libxmp-dev: invalid cmake configuration
Package: libxmp-dev Version: 4.6.0-1 Severity: important Dear Maintainer, The new cmake configuration files shipped with libxmp-dev don’t take multiarch paths into account; this produces an invalid path for includes (/usr/lib/include). Regards, Stephen -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-debug'), (500, 'oldstable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 5.10.0-23-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libxmp-dev depends on: ii libxmp4 4.4.1-3 libxmp-dev recommends no packages. libxmp-dev suggests no packages. -- no debconf information
Bug#837108: gcc-mingw-w64-i686's libgcc dll is not found by wine
Control: tag -1 + wontfix
Hi Niels,
On Thu, 08 Sep 2016 21:56:38 +0200, ni...@lysator.liu.se (Niels Möller) wrote:
> The default dll search path used by wine32 does not include the location
> of the libgcc_s_sjlj-1.dll library supplied with gcc-mingw-w64-i686.
>
> I can't say if it's wine, mingw, or both, which are wrong here. Wine's
> dll directory, /usr/lib/i386-linux-gnu/wine/, seems reasonable, so I'm
> filing it on mingw. But maybe it's no good idea to have
> gcc-mingw-w64-i686 install files in the same directory. So we might need
> to extend wine's dll path to add some suitable directory for other
> packages to install dlls in.
gcc-mingw-w64 ships different variants of libgcc, so it can’t just drop one
in a directory on the default Wine DLL path — Windows programs built with
gcc-mingw-w64 have to ensure that the appropriate DLLs are available
alongside them.
> My expectation is that if I compile a program using i686-w64-mingw32-gcc
> or i686-w64-mingw32-g++, I should be able to run that executable using
> wine. I've used to be able to do that, not sure at which package upgrade
> it stopped working. Here's an example where this fails:
I don’t think it was ever possible to do that; even when gcc-mingw-w64 (or
gcc-mingw32) shipped a single version of libgcc, it wasn’t provided in a
directory Wine would use on its own. What *is* possible is that previous
versions of the compiler didn’t produce binaries needing libgcc in as many
cases, so you might end up with a binary which just works whereas now you
don’t.
> #include
> #include
>
> int
> main(int argc, char **argv)
> {
> printf("foo\n");
> return 0;
> }
>
> To reproduce, save into a file "hello.cxx", compile using
>
>i686-w64-mingw32-g++ hello.cxx
>
> and run it using
>
>WINEDEBUG=err+all wine ./a.exe
>
> Expected result is a line "foo" written to stdout. Instead, I get
> the error
>
> err:module:import_dll Library libgcc_s_sjlj-1.dll (which is needed by
> L"Z:\\home\\nisse\\hack\\test\\a.exe") not found
> err:module:LdrInitializeThunk Main exe initialization for
> L"Z:\\home\\nisse\\hack\\test\\a.exe" failed, status c135
>
> By strace (strace -f -e open wine a.exe), I see that wine attempts to open
>
> [pid 31177]
> open("/usr/lib/wine/../i386-linux-gnu/wine/./libgcc_s_sjlj-1.dll.so",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 31177]
> open("/usr/lib/wine/../i386-linux-gnu/wine/./libgcc_s_sjlj-1.dll.so",
> O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) which seems
> ok, /usr/lib/i386-linux-gnu/wine/ exists and there are a lot of dll files
> there. But not libgcc.
>
> $ apt-file search libgcc_s_sjlj
> gcc-mingw-w64-i686:
> /usr/lib/gcc/i686-w64-mingw32/4.9-posix/libgcc_s_sjlj-1.dll
> gcc-mingw-w64-i686:
> /usr/lib/gcc/i686-w64-mingw32/4.9-win32/libgcc_s_sjlj-1.dll
>
> I have this package installed, and the files exist on my system, they
> just aren't found by wine. Besides the different location, also note the
> different file name, ".dll" vs ".dll.so".
Yes, .dll.so files are Wine-specific. The goal of the mingw-w64 packages is
to produce binaries which work on Windows (and incidentally, Wine).
> The debian wine* packages I have installed are wine, wine32 and wine64,
> all version 1.8.4-1.
>
> The debian gcc-mingw* packages installed are gcc-mingw-w64,
> gcc-mingw-w64-base, gcc-mingw-w64-i686, gcc-mingw-w64-x86-64, all
> version 4.9.1-19+14.3.
>
> I'm running this on an x86_64 machine running mostly debian stable,
> but certain packages, including wine, installed from testing (apt-get
> install -t testing wine).
>
> Some curiosities:
>
> * Switching the order of the two includes, or deleting the include of
> , makes this example work. It then prints out the message
> "foo", as expected. (The executable then no longer depends on the
> libgcc dll, I guess).
>
> * The strace output also shows that wine attempts to open
> "/usr/lib/wine/../i386-linux-gnu/wine/./%1.dll.so"
Regards,
Stephen
pgpwV2cZqpSjk.pgp
Description: OpenPGP digital signature
Bug#1038023: angband: Depends on SDL 1.2
Hi Alexandre, I see you’re already taken care of importing the last upload and preparing a new release. If you’re interested in the history of the Alioth VCS repository, it was archived at https://alioth-archive.debian.org/git/collab-maint/ (there are three tarballs, angband-audio.git.tar.xz, angband-debian.git.tar.xz, and angband.git.tar.xz; I haven’t checked their contents). Regards, Stephen On Fri, 23 Jun 2023 22:32:32 +0200, Alexandre Detiste wrote: > tag 1038023 +fixed-upstream > thanks > > The new upstream releases 4.x provide SDL2 and a lot of other niceties > > The VCS Url still point to Alioth. > > Can the last upload be imported on Salsa ? > > Greetings > > https://angband.readthedocs.io/en/latest/customize.html#interface-details > >Interface details > > > >Below are brief descriptions for what you can configure with the standard > >Windows, X11, SDL, SDL2 and Mac front ends. > > pgpCHTgS0Ksxf.pgp Description: OpenPGP digital signature
Bug#1038210: please provide a way to use UCRT instead of MSVCRT
On Fri, 16 Jun 2023 17:00:19 +0200, Sébastien Villemot wrote: > Le vendredi 16 juin 2023 à 16:42 +0200, Sébastien Villemot a écrit : > > 2. at runtime, by passing a modified specs file to the cross-compiler > > (more specifically, replacing -lmsvcrt by -lucrt in the libgcc section) > > Actually I realize that this solution probably does not work very > reliably, in particular for C++ programs (because libstdc++ would still > be built against MSVCRT). Right, that wouldn’t work — or rather, it would work in some cases but not in others... > So the only reliable solution may be to provide different binary > packages with cross-compilers for UCRT. I’m leaning towards taking the same approach as Fedora, using a new triplet, ...-w64-mingw32ucrt (see https://fedoraproject.org/wiki/Changes/F37MingwUCRT for details and https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CAMxuvax0nSO5%2BMRNQG%3DkBiN%3DPPAFbXrzAR-OVgS0kiKoVPeWSw%40mail.gmail.com/ for a very brief discussion with upstream). Regards, Stephen pgp6iwNzeM5RL.pgp Description: OpenPGP digital signature
Bug#1037974: ddcci-dkms: code fails to build and package fails to install with Linux 6.3 headers
Hi Paul, On Thu, 15 Jun 2023 10:32:56 +0800, Paul Wise wrote: > When I try to install ddcci-dkms with the Linux 6.3 headers installed, > the build of the code fails and then the install of the package fails. > > I think there are two problems here: > > * The code needs to be adapted to the latest Linux kernel version. I’ve applied candidate patches from the upstream repo to handle up to 6.4. > * The package should not fail to install when the module build fails. > This might be a problem in dkms itself, or in ddcci's integration. This is the more interesting issue, but see #1029063. Admittedly the absence of a ddcci module is unlikely to ever prevent a system from booting, so perhaps we could have a way of telling dkms that build failures in a given module shouldn’t be treated as errors. Andreas, what do you think? Regards, Stephen pgpNUPqVo_amU.pgp Description: OpenPGP digital signature
Bug#1037228: ITP: pycrc -- CRC C source code generator
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pycrc Version : 0.10.0 Upstream Author : Thomas Pircher * URL : https://pycrc.org * License : MIT Programming Lang: Python Description : CRC C source code generator pycrc is a Cyclic Redundancy Check (CRC) C source code generator. . It supports different implementations, with various speed-space compromises. The CRC parameters can be freely chosen, and pycrc includes a number of well-known CRC models (CRC-16, CRC-32 etc.). This is a build-dependency for dosbox-x. It will be maintained in the Python packaging team.
Bug#1036033: upgrade-reports: bullseye -> bookworm kernel package upgrade fails when ddcci-dkms package installed
Control: severity -1 normal Control: tag -1 +moreinfo Hi Tim, On Sun, 14 May 2023 22:44:41 +0200, Andreas Beckmann wrote: > On 14/05/2023 19.43, Paul Gevers wrote: > >> /etc/kernel/postinst.d/dkms: > >> dkms: running auto installation service for kernel 6.1.0-7-amd64. > >> Error! Could not locate dkms.conf file. > >> File: /var/lib/dkms/ddcci/0.3.3/source/dkms.conf does not exist. > >> dkms: autoinstall for kernel: 6.1.0-7-amd64 failed! > > How has ddcci-dkms been installed? > How did the dkms.conf go missing? > Please show the current layout of the source tree: >ls -laR /usr/src/ddcci-* > Why hasn't ddcci been upgraded to the bookworm version (0.4.2)? Would it be possible for you to provide an update with the information requested above? It would also be useful if you could provide the information requested in the upgrade-reports template (the output of COLUMNS=200 dpkg -l). I’m downgrading the bug’s severity pending this, since yours is the only report so far with an upgrade error related to ddcci-dkms. I’ve been trying to reproduce this, but have so far been unable to, regardless of the upgrade order or combination (upgrading dkms but not ddcci-dkms, upgrading the kernel, etc.). In particular, I would very much like to understand why dkms is complaining about /var/lib/dkms/ddcci/0.3.3/source/dkms.conf even though the ddcci-dkms package has seemingly been upgraded. > PS: I don't see any errors during piuparts upgrade tests of ddcci-dkms + > linux-headers-amd64 > > PPS: Of course the bullseye version (0.3.3) will fail to build for a 6.1 > kernel (if it gets that far), but that's nothing unexpected > > PPPS: if you install the bookworm version of ddcci-dkms, it should a) > restore the missing file and b) be compatible with current kernels Regards, Stephen Kitt pgpQXk30MAMaD.pgp Description: OpenPGP digital signature
Bug#1036708: ITS: dosbox is dead, move to active, high quality dosbox-staging successor
Hi, On Wed, 24 May 2023 16:43:56 +0200, David Heidelberg wrote: > DOSBox upstream is dead for a long time. Since upstream is dead, > multiple good or worse quality forks emerged over the time. > > One of serious ones is DOSBox-staging, which implemented testing, using > recent SDL 2, modern programming language and tries hard to solve issues > previously carried patch by patch from downstream forks. > > I (and probably few others listed in [1]) would love to see working > DOSBox. > > Current DOSBox due to usage of SDL 1.2 is hardly usable on Wayland based > environments, so my main motivation is use DOSBox on Wayland and > Mobian/PureOS (Debian adapted to mobile phones). DOSBox-X is in NEW: https://ftp-master.debian.org/new/dosbox-x_2023.05.01%2Bdfsg-1.html You have an existing ITP for dosbox-staging, https://bugs.debian.org/973822. Are you still working on that? It’s not clear to me why you want to salvage the dosbox package, could you clarify? Regards, Stephen pgpxGGh8zP9ce.pgp Description: OpenPGP digital signature
Bug#1035539: unblock: binutils-mingw-w64/10.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team, Please unblock package binutils-mingw-w64. [ Reason ] Version 10.4 includes a two-line upstream fix for a crash when handling certain import libraries. [ Impact ] Users with affected libraries can’t use Bookworm’s binutils-mingw-w64 at all; this is a regression from Bullseye. [ Tests ] The reporter of https://bugs.debian.org/1029841 provided a test case; see also https://sourceware.org/bugzilla/show_bug.cgi?id=30079 [ Risks ] The fix is tiny: diff --git a/ld/ldlang.c b/ld/ldlang.c index 84a2914fc26..b5e0d026ae4 100644 --- a/upstream/ld/ldlang.c +++ b/upstream/ld/ldlang.c @@ -649,7 +649,8 @@ wild_sort (lang_wild_statement_type *wild, looking at the sections for this file. */ /* Find the correct node to append this section. */ - if (compare_section (sec->spec.sorted, section, (*tree)->section) < 0) + if (sec && sec->spec.sorted != none && sec->spec.sorted != by_none + && compare_section (sec->spec.sorted, section, (*tree)->section) < 0) tree = &((*tree)->left); else tree = &((*tree)->right); The risk is minute. [ 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 testing unblock binutils-mingw-w64/10.4 Regards, Stephen diff -Nru binutils-mingw-w64-10.3/debian/changelog binutils-mingw-w64-10.4/debian/changelog --- binutils-mingw-w64-10.3/debian/changelog2023-01-11 13:02:20.0 +0100 +++ binutils-mingw-w64-10.4/debian/changelog2023-05-03 08:49:22.0 +0200 @@ -1,3 +1,9 @@ +binutils-mingw-w64 (10.4) unstable; urgency=medium + + * Apply upstream patch to fix an internal error. Closes: #1029841. + + -- Stephen Kitt Wed, 03 May 2023 08:49:22 +0200 + binutils-mingw-w64 (10.3) unstable; urgency=medium * Drop another failing codeview test. diff -Nru binutils-mingw-w64-10.3/debian/patches/pr30079.patch binutils-mingw-w64-10.4/debian/patches/pr30079.patch --- binutils-mingw-w64-10.3/debian/patches/pr30079.patch1970-01-01 01:00:00.0 +0100 +++ binutils-mingw-w64-10.4/debian/patches/pr30079.patch2023-05-03 08:49:22.0 +0200 @@ -0,0 +1,26 @@ +commit b7eab2a9d4f4e92692daf14b09fc95ca11b72e30 +Author: Michael Matz +Date: Thu Feb 9 15:29:00 2023 +0100 + +Fix PR30079: abort on mingw + +the early-out in wild_sort is not enough, it might still be +that filenames are equal _and_ the wildcard list doesn't specify +a sort order either. Don't call compare_section then. + +Tested on all targets. + +diff --git a/ld/ldlang.c b/ld/ldlang.c +index 84a2914fc26..b5e0d026ae4 100644 +--- a/upstream/ld/ldlang.c b/upstream/ld/ldlang.c +@@ -649,7 +649,8 @@ wild_sort (lang_wild_statement_type *wild, +looking at the sections for this file. */ + + /* Find the correct node to append this section. */ +- if (compare_section (sec->spec.sorted, section, (*tree)->section) < 0) ++ if (sec && sec->spec.sorted != none && sec->spec.sorted != by_none ++&& compare_section (sec->spec.sorted, section, (*tree)->section) < 0) + tree = &((*tree)->left); + else + tree = &((*tree)->right); diff -Nru binutils-mingw-w64-10.3/debian/patches/series binutils-mingw-w64-10.4/debian/patches/series --- binutils-mingw-w64-10.3/debian/patches/series 2021-10-25 10:49:54.0 +0200 +++ binutils-mingw-w64-10.4/debian/patches/series 2023-05-03 08:46:34.0 +0200 @@ -3,3 +3,4 @@ dont-run-objcopy.patch disable-flags.patch reproducible-import-libraries.patch +pr30079.patch
Bug#1029841: binutils-mingw-w64-x86-64: x86_64-w64-mingw32-ld internal error in ldlang.c
Hi Dennis, On Tue, 2 May 2023 14:10:46 -0700, Dennis Kempin wrote: > would you be able to build a new release that includes the upstream patch? > > We currently have the version of binutils-mingw-w64-x86-64 pinned to an > older version to avoid the issue. This had slipped my mind, thanks for the reminder. I’ve pushed a new package, I’ll ask for an unblock so it can get into Debian 12. Regards, Stephen pgpbPIg2LdcQA.pgp Description: OpenPGP digital signature
Bug#1034308: RM: lcab -- RoQA; orphaned, abandoned upstream, has alternative
Package: ftp.debian.org Severity: normal Dear FTP team, Please remove lcab; it was last released upstream in 2007, has been orphaned since 2019, has had no significant upload since 2013, and everything it does can be done with gcab. Regards, Stephen
Bug#1034252: colord: please consider splitting out colord-sane
Package: colord
Version: 1.4.5-3
Severity: wishlist
Tags: patch
Dear Maintainer,
colord-sane scans for SANE devices every time colord scans for
devices, e.g. on my system whenever a USB device is connected (or
wakes up). This wakes my multi-function printer up, which is noisy and
wasteful (it's a laser printer, so it heats up every time this
happens). See https://github.com/hughsie/colord/issues/118 and the
links there for more on this.
Would it be possible to split colord-sane out to a separate package?
The attached patch implements this. This has the side-benefit that the
main colord package no longer depends on libsane1.
Regards,
Stephen
-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable'), (100, 'unstable-debug'), (100,
'testing-debug'), (100, 'unstable'), (100, 'testing'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages colord depends on:
ii acl 2.2.53-10
ii adduser 3.118
ii colord-data 1.4.5-3
ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2
ii libc62.31-13+deb11u5
ii libcolord2 1.4.5-3
ii libcolorhug2 1.4.5-3
ii libdbus-1-3 1.12.24-0+deb11u1
ii libglib2.0-0 2.66.8-1
ii libgudev-1.0-0 234-1
ii libgusb2 0.3.5-1
ii liblcms2-2 2.12~rc1-2
ii libpolkit-gobject-1-00.105-31+deb11u1
ii libsane1 1.0.31-4.1
ii libsqlite3-0 3.34.1-3
ii libsystemd0 247.3-7+deb11u1
ii policykit-1 0.105-31+deb11u1
colord recommends no packages.
colord suggests no packages.
-- no debconf information
-- debsums errors found:
debsums: missing file /usr/libexec/colord-sane (from colord package)
diff --git a/debian/changelog b/debian/changelog
index 462aaf30..2b9039f5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+colord (1.4.6-2.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Split SANE support out to a separate package, to allow installation of
+colord without triggering SANE devices (this wakes up network
+multi-function printers supported by SANE whenever colord scans for
+supported devices).
+
+ -- Stephen Kitt Tue, 11 Apr 2023 17:23:30 +0200
+
colord (1.4.6-2.2) unstable; urgency=medium
* Non-maintainer upload
diff --git a/debian/colord-plugin-sane.install
b/debian/colord-plugin-sane.install
new file mode 100644
index ..5ef0687f
--- /dev/null
+++ b/debian/colord-plugin-sane.install
@@ -0,0 +1,2 @@
+usr/lib/*/colord-plugins/libcolord_sensor_sane.so
+usr/libexec/colord-sane
diff --git a/debian/colord.install b/debian/colord.install
index 42cc99bc..6ad61798 100644
--- a/debian/colord.install
+++ b/debian/colord.install
@@ -1,7 +1,8 @@
lib/systemd/system/*.service
lib/udev/rules.d/
usr/bin/
-usr/lib/*/colord-plugins
+usr/lib/*/colord-plugins/libcolord_sensor_camera.so
+usr/lib/*/colord-plugins/libcolord_sensor_scanner.so
usr/lib/*/colord-sensors/libcolord_sensor_colorhug.so
usr/lib/*/colord-sensors/libcolord_sensor_dtp94.so
usr/lib/*/colord-sensors/libcolord_sensor_dummy.so
@@ -9,7 +10,6 @@ usr/lib/*/colord-sensors/libcolord_sensor_huey.so
usr/lib/systemd/user/
usr/lib/tmpfiles.d/
usr/libexec/colord
-usr/libexec/colord-sane
usr/libexec/colord-session
usr/share/bash-completion
usr/share/dbus-1
diff --git a/debian/control b/debian/control
index 9f190d09..6df76ed1 100644
--- a/debian/control
+++ b/debian/control
@@ -116,6 +116,27 @@ Description: system service to manage device colour
profiles -- argyll sensor pl
This package contains a sensor plugin that uses the Argyll tools, allowing
colord to support colourimeters that are supported by Argyll.
+Package: colord-plugin-sane
+Architecture: linux-any
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Replaces:
+ colord (<< 1.4.6-2.2~),
+Breaks:
+ colord (<< 1.4.6-2.2~),
+Enhances:
+ colord,
+Description: system service to manage device colour profiles -- SANE plugin
+ colord is a system service that makes it easy to manage, install and generate
+ colour profiles to accurately colour manage input and output devices.
+ .
+ It provides a D-Bus API for system frameworks to query, a persistent
Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash
On Mon, 3 Apr 2023 20:47:01 -0600 David Ahern wrote: > On 4/3/23 9:24 AM, Stephen Hemminger wrote: > > ted > >> > >> This happens because iproute2 just assumes the tunnel is ipv4, but the > >> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL > >> ioctl it writes back a struct ip6_tnl_parm2 into the struct > >> ip_tunnel_parm which is smaller, so the stack gets overwritten. Is > >> there any way to tell from userspace whether a gre is v4 or v6 before > >> doing an ioctl? The ioctls don't take/return a size parameter as far > >> as I can see... > > > > Ip uses and IPv4 UDP socket when it thinks it is talking to GRE. > > And a IPv6 UDP socket when it is talking to GRE6. > > > > So the kernel could check and error out? > > > > Does seem like a kernel bug and a well known design flaw in ioctl > interface (assuming buffer of a specific size). The best iproute2 can do > is have `old_p` be a larger size (e.g., ip6_tnl_parm2) to avoid the > overrun, but then the result is nonsense with no way for it no an ipv6 > struct was passed back. The crash at least indicates something is off. I started to look into redoing the whole 'ip tunnel XXX' as just a remapping of arguments and calling the equivalent 'ip link ... type YYY' and it is doable for the basic stuff. Then starting looking at the Potential Router List (PRL) stuff. Looks like this is only supported through ioctl(). Definitely a dusty dark corner of networking code with rarely used features. Plus things like, the code to get PRL will allow bigger get if called from root vs non-root user??
Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash
On Mon, 3 Apr 2023 20:47:01 -0600 David Ahern wrote: > On 4/3/23 9:24 AM, Stephen Hemminger wrote: > > ted > >> > >> This happens because iproute2 just assumes the tunnel is ipv4, but the > >> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL > >> ioctl it writes back a struct ip6_tnl_parm2 into the struct > >> ip_tunnel_parm which is smaller, so the stack gets overwritten. Is > >> there any way to tell from userspace whether a gre is v4 or v6 before > >> doing an ioctl? The ioctls don't take/return a size parameter as far > >> as I can see... > > > > Ip uses and IPv4 UDP socket when it thinks it is talking to GRE. > > And a IPv6 UDP socket when it is talking to GRE6. > > > > So the kernel could check and error out? > > > > Does seem like a kernel bug and a well known design flaw in ioctl > interface (assuming buffer of a specific size). The best iproute2 can do > is have `old_p` be a larger size (e.g., ip6_tnl_parm2) to avoid the > overrun, but then the result is nonsense with no way for it no an ipv6 > struct was passed back. The crash at least indicates something is off. Actually any change tunnel can have similar issues where the tunnel is of one type and the request wants to change parameters. The two structs (ip_param and ip6_tunnel_param) are different enough that getting the incorrect type will be complete garbage. There doesn't seem to be a good way to identify the tunnel type. The only way I can see is to look at the link type (ifi_type) but this is ARPHRD_XXX value and not the ip protocol. The other way would be to query link info (with netlink) and make sure that IFLA_INFO_KIND (in IFLA_LINKINFO) matches when changing. Or maybe get rid of the ip tunnel command and just use ip link which is all netlink based. The iptunnel stuff was introduced long ago when the only way to make tunnels was with ioctl. Now you can do same operations with ip link. to
Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash
ted > > This happens because iproute2 just assumes the tunnel is ipv4, but the > kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL > ioctl it writes back a struct ip6_tnl_parm2 into the struct > ip_tunnel_parm which is smaller, so the stack gets overwritten. Is > there any way to tell from userspace whether a gre is v4 or v6 before > doing an ioctl? The ioctls don't take/return a size parameter as far > as I can see... Ip uses and IPv4 UDP socket when it thinks it is talking to GRE. And a IPv6 UDP socket when it is talking to GRE6. So the kernel could check and error out?
Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash
On Sun, 2 Apr 2023 23:58:52 +0100
Luca Boccassi wrote:
> On Sat, 25 Mar 2023 at 00:39, Bernhard Übelacker
> wrote:
> >
> > Dear Maintainer,
> > I tried to find out where exactly the stack smashing takes place.
> > And found the ioctl SIOCCHGTUNNEL did write more than the 52 bytes
> > allocated in variable old_p, by that overwriting the stack canary.
> >
> > Kind regards,
> > Bernhard
> >
> >
> > (gdb)
> > 0x5557589f 62 {
> > 1: x/i $pc
> > => 0x5557589f : mov%fs:0x28,%rax
> > (gdb)
> > 0x555758a8 62 {
> > 1: x/i $pc
> > => 0x555758a8 : mov%rax,0x68(%rsp)
> > (gdb) print/x $rax
> > $1 = 0xbf9b77d893accd00
> > (gdb) print/x $rsp + 0x68
> > $2 = 0x7fffea28
> >
> >
> > (gdb)
> > 0x77e575f5 120 in ../sysdeps/unix/syscall-template.S
> > 1: x/i $pc
> > => 0x77e575f5 :syscall
> > 2: /x *(uint64_t*)0x7fffea28 = 0xbf9b77d893accd00
> > (gdb) bt
> > #0 0x77e575f5 in ioctl () at ../sysdeps/unix/syscall-template.S:120
> > #1 0x55578230 in tnl_get_ioctl (basedev=0x7fffee8f "gre1",
> > p=) at tunnel.c:77
> > #2 0x55576243 in parse_args (argc=9, argv=0x7fffec50,
> > cmd=35315, p=0x7fffea70) at iptunnel.c:181
> > #3 0x555762fb in do_add (cmd=35315, argc=,
> > argv=) at iptunnel.c:260
> > #4 0x5556258b in do_cmd (argv0=0x7fffee81 "tunnel", argc=11,
> > argv=0x7fffec40) at ip.c:133
> > #5 0x55561fc2 in main (argc=12, argv=0x7fffec38) at ip.c:344
> > (gdb) stepi
> > 0x77e575f7 120 in ../sysdeps/unix/syscall-template.S
> > 1: x/i $pc
> > => 0x77e575f7 :cmp$0xf001,%rax
> > 2: /x *(uint64_t*)0x7fffea28 = 0x200
> >
> > (gdb) print _p
> > $7 = (struct ip_tunnel_parm *) 0x7fffe9f0
> > (gdb) print sizeof(old_p)
> > $8 = 52
> > (gdb) print/x 0x7fffe9f0 + 52
> > $9 = 0x7fffea24
> >
> > (gdb) list iptunnel.c:181
> > 178 if (cmd == SIOCCHGTUNNEL && count == 0) {
> > 179 struct ip_tunnel_parm old_p = {};
> > 180
> > 181 if (tnl_get_ioctl(*argv, _p))
> > 182 return -1;
>
> Hi David and Stephen,
>
> To reproduce, build iproute2 with -fstack-protector-strong in CFLAGS, and run:
>
> ip tunnel add gre1 mode ip6gre local 2001:db8::1 remote 2001:db8::2 ttl 255
> ip tunnel change gre1 mode gre local 192.168.0.0 remote 192.168.0.1 ttl 255
>
> You'll get:
>
> *** stack smashing detected ***: terminated
> Aborted
>
> This happens because iproute2 just assumes the tunnel is ipv4, but the
> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL
> ioctl it writes back a struct ip6_tnl_parm2 into the struct
> ip_tunnel_parm which is smaller, so the stack gets overwritten. Is
> there any way to tell from userspace whether a gre is v4 or v6 before
> doing an ioctl? The ioctls don't take/return a size parameter as far
> as I can see...
Is setting IPv4 addresses on an IPv6 tunnel even a valid operation?
Assuming the ioctl to get is fixed, is there a reason to allow it?
One more reason netlink is better than ioctl.
Bug#1031930: nmu: binutils-mingw-w64_10.3, gdb-mingw-w64_12
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: Matthias Klose Dear release team, Please binNMU binutils-mingw-w64 and gdb-mingw-w64: nmu binutils-mingw-w64_10.3 . ANY . unstable . -m "Rebuild for outdated Built-Using" nmu gdb-mingw-w64_12 . ANY . unstable . -m "Rebuild for outdated Built-Using" Thanks, Stephen
Bug#1027130: Bug may still be open
Dear Maintainer; This "grave" bug has been marked as closed in 1.0.0-dfsg-1 however it is still open in 0.103.7-dfsg-0+deb11u1 and there is no indication that it has been resolved in 0.103.8+dfsg-0+deb11u1 which is promulgated to solve the "serious" CVEs handled in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031509 for "Buster". As such trying to upgrade my system is warning me that this grave bug is present. It is not clear whether this is indeed the case or not. I must note that I am running Devuan Stable "Chimaera" but it seems that this issue will also arise for Debian Stable "Bulleye". Regards Stephen Lyons
Bug#1031387: supertuxkart: Fails to compile due to inescaped +, bug in shaderc
Control: severity normal Hi Rishi, On Thu, 16 Feb 2023 00:29:33 -0800, Rishi Cutchin wrote: >* What led up to the situation? > Attempting to backport supertuxkart, necessary to backport glslang > aswell. > >* What exactly did you do (or not do) that was effective (or > ineffective)? > Compiled with fakeroot debian/rules binary > >* What was the outcome of this action? > Failed to build due to > > cd > /home/rishi/build/supertuxkart/supertuxkart-1.4+dfsg/obj-x86_64-linux-gnu/lib/shaderc/libshaderc > && /usr/bin/ar -M < shaderc_combined.ar +Syntax error in archive script, > line 1 > > Appears to be an issue with cmake and shadercc not properly escaping '+' > character: > https://github.com/google/shaderc/issues/473 > > >* What outcome did you expect instead? > Successful (test) compile The package builds correctly in unstable, including from a directory containing a +. This *might* mean that other packages need to be backported too, I haven’t checked. Regards, Stephen pgp9gV7aKxheY.pgp Description: OpenPGP digital signature
Bug#1031386: supertuxkart: Depends on newer version of glslang
Control: severity wishlist Hi Rishi, On Thu, 16 Feb 2023 00:25:54 -0800, Rishi Cutchin wrote: >* What led up to the situation? > Attempted to backport package to stable. Installed build-dependencies > with mk-build-deps --install --remove > >* What exactly did you do (or not do) that was effective (or > ineffective)? > Attempted to build with fakeroot debian/rules binary. > >* What was the outcome of this action? > Recieved error relating to glslang::EShTargetSpv_1_6, and compilation > failed. Was able to continue compilation after backporting glslang and > it's dependencies > >* What outcome did you expect instead? > Build-dependency should require newer version so that mk-build-deps > errors to force new version. Package dependencies are supposed to make sense within a given release. supertuxkart builds fine in unstable, so this isn’t a serious issue. When you backport, it’s part of the backporting work to determine when the stable dependencies aren’t sufficient, as you did; but insufficient dependencies for a backport to stable don’t constitute a bug. It *is* useful to have versioned dependencies where appropriate, so I’m leaving this open, but as a wishlist bug. Regards, Stephen pgpN4py2qYZZm.pgp Description: OpenPGP digital signature
Bug#1030726: marked as pending in intelrdfpmath
On Tue, 7 Feb 2023 15:17:05 -0500, Roberto C. Sánchez wrote: > On Tue, Feb 07, 2023 at 08:44:50PM +0100, Stephen Kitt wrote: > > Yes, it seems like we’d really need a mips_macros.h implementation on > > MIPS. > That was my suspicion as well. > > > I enabled the test suite, and the result is basically that the library > > only works fully on amd64, i386 (nearly, with two test failures out of > > ~120,000 test cases), and ia64, which matches the architectures which the > > library claims to support. On other architectures, the number of failures > > varies, up to 12.5% of test cases on s390x. > > > > So really I should change the library to [amd64 i386 ia64]... > > > That's unfortunate. > > > Do you have a good way of validating whether the library is good enough > > for libmongocrypt’s purposes on non-Intel architectures? > > > libmonogocrypt has a test suite, which we don't execute as part of the > package build because of upstream's robust CI. However, we could > definitely enable it and it would be sufficient to let us know that the > library is adequate for what libmongocrypt needs. > > That said, upstream is quite close validating that libmongocrypt works > with libdfp, so that might provide a near-term alternative if you decide > that the best thing to do from a quality perspective is to restrict the > architecture list of intelrdfpmath. Given how late we are in the Bookworm release process, I’ve updated the package description to mention that the library is only fully functional on x86 architectures and ia64, but may be sufficient on others (for free42, it is, at least on ARM), and haven’t restricted the architectures. That doesn’t help on MIPS of course... Does libdfp work on MIPS? I got the impression it’s mainly supported on IBM platforms (POWER and S/390) but perhaps that’s outdated! Regards, Stephen pgphXQ5ZbYEOl.pgp Description: OpenPGP digital signature
Bug#1030726: marked as pending in intelrdfpmath
On Mon, 6 Feb 2023 16:37:57 -0500, Roberto C. Sánchez wrote: > And even with the build continuing on mips64el I see this: > > float128/dpml_ux_trig.c: In function '__dpml_bid_ux_degree_reduce__': > float128/dpml_ux_trig.c:254:9: warning: implicit declaration of function > 'UMULH' [-Wimplicit-f unction-declaration] > 254 | UMULH((UX_FRACTION_DIGIT_TYPE) exponent, RECIP_TWELVE, k); > | ^ > > > When I build libmongocrypt against the resulting libintelrdfp-math, the > libmongocrypt will then fail at link time: > > /usr/bin/ld: > /home/roberto/mips64el/intelrdfpmath-2.0u2/debian/libintelrdfpmath-dev/usr/lib/mips64el-linux-gnuabi64/libbidgcc000.a(dpml_ux_ops_64.o): > in function `__eval_pos_poly': (.text+0xe4): undefined reference to `UMULH' > /usr/bin/ld: (.text+0xfc): undefined reference to `UMULH' /usr/bin/ld: > (.text+0x144): undefined reference to `UMULH' /usr/bin/ld: (.text+0x160): > undefined reference to `UMULH' /usr/bin/ld: (.text+0x168): undefined > reference to `UMULH' /usr/bin/ld: > /home/roberto/mips64el/intelrdfpmath-2.0u2/debian/libintelrdfpmath-dev/usr/lib/mips64el-linux-gnuabi64/libbidgcc000.a(dpml_ux_ops_64.o):(.text+0x17c): > more undefined references to `UMULH' follow > > It might be better to simply declare intelrdfpmath '[!mipsel > !mips64el]'. Sadly, my experience with Intel libraries (I maintained > TBB in Debian for several years) is that they only put effort into the > architectures that are important to them and that you can't assume that > their code will work on other architectures. That could well be the > case here. Yes, it seems like we’d really need a mips_macros.h implementation on MIPS. I enabled the test suite, and the result is basically that the library only works fully on amd64, i386 (nearly, with two test failures out of ~120,000 test cases), and ia64, which matches the architectures which the library claims to support. On other architectures, the number of failures varies, up to 12.5% of test cases on s390x. So really I should change the library to [amd64 i386 ia64]... Do you have a good way of validating whether the library is good enough for libmongocrypt’s purposes on non-Intel architectures? Regards, Stephen pgpt5tua0m1VP.pgp Description: OpenPGP digital signature
Bug#1030701: intelrdfpmath: FTBFS on alpha/hppa/mips and likely misbuilt on several architectures
On Mon, 6 Feb 2023 21:21:46 +0200, Adrian Bunk wrote: > On Mon, Feb 06, 2023 at 08:04:13PM +0100, Stephen Kitt wrote: > > On Mon, 06 Feb 2023 17:53:31 +0200, Adrian Bunk wrote: > >... > > > The RC severity is based on looking at a related question: > > > How did intelrdfpmath compile on new platforms like powerpc/arm/s390x > > > that never had any explicit support in intelrdfpmath? > > > > > > intelrdfpmath (2.0u2-2) unstable; urgency=medium > > > * Assume unknown architectures are “EFI2”. > > > > > > LIBRARY/float128/architecture.h: > > > #if defined(ct) || defined(efi2) > > > # undef _M_AMD64 > > > # define _M_AMD64 > > > #endif > > > > > > This builds, but the (used) definition > > > # define ENDIANESS little_endian > > > isn't correct on s390x, and neither is > > > # define BITS_PER_LONG 64 > > > on 32bit arm. > > > > Ah, I knew that would bite me some day... > > > > I’m updating intelrdfpmath to apply the architecture definitions used in > > libmongocrypt (see > > <https://github.com/mongodb/libmongocrypt/blob/master/cmake/IntelDFP.cmake>): > > armel/armhf are assumed to behave like i386 (I haven’t checked whether > > that makes sense), arm64/ppc64el/riscv64 are assumed to behave like > > amd64, and s390x is supported explicitly. > > > > If you want to track the unsupported architectures, please open a new > > bug. As far as I can tell, even if libmongocrypt were built in Debian > > using its embedded copy of intelrdfpmath, it would fail on the same > > architectures. > > If arm64/ppc64el/riscv64 are assumed to behave like amd64 (little endian > 64bit), and armel/armhf are assumed to behave like i386 (little endian > 32bit), and s390x is big endian so clearly different, could you add > mips64el and mipsel as little endian 64/32bit architectures there? > > This feels like the easiest way for getting the new version of > libmongocrypt into bookworm. Another way would be to remove the MIPS packages in Bookworm ;-). (I haven’t checked the impact of that I’ll wait for the results of Roberto’s tests and add the MIPS patch if it’s appropriate. (intelrdfpmath has a built-in test suite but it hits an endless loop even on x86...) Regards, Stephen pgp7WJKaQr9Jr.pgp Description: OpenPGP digital signature
Bug#1030701: intelrdfpmath: FTBFS on alpha/hppa/mips and likely misbuilt on several architectures
On Mon, 06 Feb 2023 17:53:31 +0200, Adrian Bunk wrote: > intelrdfpmath FTBFS on the older platforms alpha/hppa/mips where > it seems to used to have support for, but that support is now so > broken that even the headers necessary for compilation are missing: > > float128/dpml_exception.h:315:17: fatal error: alpha_linux_exception.h: No > such file or directory 315 | # include "alpha_linux_exception.h" > > float128/dpml_private.h:215:14: fatal error: mips_macros.h: No such file or > directory 215 | #include "mips_macros.h" > > (The hppa FTBFS looks different, I haven't checked whether that's also > related to the stale hp_pa code.) > > > This is a problem for libmongocrypt, which started to use intelrdfpmath > but whose new version is currently blocked from testing migration due > to libintelrdfpmath-dev not being available on mipsel/mips64el. I’m afraid there isn’t much I can do about that, other than ask upstream to add MIPS support. Given the RC severity of this bug, I’ll consider the main point of the bug to be the latter part: > The RC severity is based on looking at a related question: > How did intelrdfpmath compile on new platforms like powerpc/arm/s390x > that never had any explicit support in intelrdfpmath? > > intelrdfpmath (2.0u2-2) unstable; urgency=medium > * Assume unknown architectures are “EFI2”. > > LIBRARY/float128/architecture.h: > #if defined(ct) || defined(efi2) > # undef _M_AMD64 > # define _M_AMD64 > #endif > > This builds, but the (used) definition > # define ENDIANESS little_endian > isn't correct on s390x, and neither is > # define BITS_PER_LONG 64 > on 32bit arm. Ah, I knew that would bite me some day... I’m updating intelrdfpmath to apply the architecture definitions used in libmongocrypt (see <https://github.com/mongodb/libmongocrypt/blob/master/cmake/IntelDFP.cmake>): armel/armhf are assumed to behave like i386 (I haven’t checked whether that makes sense), arm64/ppc64el/riscv64 are assumed to behave like amd64, and s390x is supported explicitly. If you want to track the unsupported architectures, please open a new bug. As far as I can tell, even if libmongocrypt were built in Debian using its embedded copy of intelrdfpmath, it would fail on the same architectures. Regards, Stephen pgpYCIWa6fBgX.pgp Description: OpenPGP digital signature
Bug#1029841: binutils-mingw-w64-x86-64: x86_64-w64-mingw32-ld internal error in ldlang.c
Hi Didier, On Sat, 4 Feb 2023 16:27:17 +0100, Didier Smets wrote: > Thank you, I did some more testing in order to isolate it better, and have > now uploaded a bug report upstream. I'll report depending on the outcome. > > (https://sourceware.org/bugzilla/show_bug.cgi?id=30079) Fantastic, thank you very much! I’ve linked the Debian bug to the upstream bug. Regards, Stephen pgpM7hZjTQmcG.pgp Description: OpenPGP digital signature
Bug#1029841: binutils-mingw-w64-x86-64: x86_64-w64-mingw32-ld internal error in ldlang.c
Hi Didier, On Sat, 28 Jan 2023 18:07:12 +0100, Didier Smets wrote: > I have a C project that I cross-compile for Win64 from Linux using > mingw-w64. > > One of the targets is a dll which fails to build with the following : > >[ 96%] Linking C shared library libXPSV.dll >/usr/bin/x86_64-w64-mingw32-ld: internal error: aborting at > ./upstream/ld/ldlang.c:527 in compare_section > /usr/bin/x86_64-w64-mingw32-ld: please report this bug collect2: error: ld > returned 1 exit status > > The same project builds fine in bullseye. This appears to be an upstream bug; would you mind reporting it to <https://sourceware.org/bugzilla/>? You’ll probably have to provide more details. The CMake setup isn’t necessarily relevant; if at all possible, it would be useful to see the full commands used at each step, notably the ld invocation. The failure occurs at an abort() line, so it would also be useful to know what’s calling it; to see that, run the linker command using gdb, and note the output of "bt" when the linker aborts. Regards, Stephen pgpp5UNbgHTxQ.pgp Description: OpenPGP digital signature
Bug#1029752: tests fail with nmh 1.8~RC-2, blocking nmh from entering testing
Thank you for this bug report! I had noticed that the xlbiff test fails in some chroots, but I had not yet identified that nmh 1.8 was the difference. I will upload a fix in the next few days. < Stephen
Bug#1029464: gnucash: Missing Dependency or Suggestion
Package: gnucash
Version: 1:4.4-1
Severity: minor
X-Debbugs-Cc: none, step...@marenka.net
Dear Maintainer,
gnucash throws the following error on launch from cli, although I'm not
aware of anything that doesn't work.
| Traceback (most recent call last):
| File "/usr/share/gnucash/python/init.py", line 6, in
| from gi import require_version
| ModuleNotFoundError: No module named 'gi'
Installing python3-gi yields the following.
| Traceback (most recent call last):
| File "/usr/share/gnucash/python/init.py", line 7, in
|require_version('Gtk', '3.0')
| File "/usr/lib/python3/dist-packages/gi/__init__.py", line 126, in
require_version
|raise ValueError('Namespace %s not available' % namespace)
| ValueError: Namespace Gtk not available
Installing gobject-introspection gir1.2-gtk-3.0 remediates that but
brings quite a few dependencies (FWIW). At least now we get no errors.
Maybe add a Suggests: python3-gi gobject-introspection gir1.2-gtk-3.0?
Thanks,
Stephen
-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.153-20432-gaa06ea936644 (SMP w/4 CPU threads;
PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gnucash depends on:
ii gnucash-common 1:4.4-1
ii guile-3.0 3.0.5-4
ii guile-3.0-libs 3.0.5-4
ii libaqbanking44 6.2.10-1
ii libboost-filesystem1.74.0 1.74.0-9
ii libboost-locale1.74.0 1.74.0-9
ii libboost-program-options1.74.0 1.74.0-9
ii libboost-regex1.74.0 [libboost-regex1.74.0-icu67] 1.74.0-9
ii libc6 2.31-13+deb11u5
ii libcairo2 1.16.0-5
ii libcrypt-ssleay-perl 0.73.06-1+b3
ii libdate-manip-perl 6.83-1
ii libdbi10.9.0-6
ii libfinance-quote-perl 1.50~rc2-2
ii libgcc-s1 10.2.1-6
ii libgdk-pixbuf-2.0-0
2.42.2+dfsg-1+deb11u1
ii libglib2.0-0 2.66.8-1
ii libgtk-3-0 3.24.24-4+deb11u2
ii libgwengui-gtk3-79 5.6.0-2
ii libgwenhywfar795.6.0-2
ii libhtml-tableextract-perl 2.15-1.1
ii libhtml-tree-perl 5.07-2
ii libicu67 67.1-7
ii libofx71:0.9.15-3
ii libpango-1.0-0 1.46.2-3
ii libpangocairo-1.0-01.46.2-3
ii libpython3.9 3.9.2-1
ii libsecret-1-0 0.20.4-2
ii libstdc++6 10.2.1-6
ii libwebkit2gtk-4.0-37 2.38.3-1~deb11u1
ii libwww-perl6.52-1
ii libxml2
2.9.10+dfsg-6.7+deb11u3
ii perl 5.32.1-4+deb11u2
ii zlib1g
1:1.2.11.dfsg-2+deb11u2
Versions of packages gnucash recommends:
ii gnucash-docs 4.4-1
ii python3-gnucash 1:4.4-1
ii yelp 3.38.3-1
Versions of packages gnucash suggests:
pn libdbd-mysql
pn libdbd-pgsql
pn libdbd-sqlite3
--
Stephen R. Marenka If life's not fun, you're not doing it right!
Bug#1029093: solaar doesn't enable plugdev when plugdev requested
Control: forcemerge 1028922 -1 Control: severity 1028922 important Hi Mason, On Tue, 17 Jan 2023 11:05:46 -0500, Mason Loring Bliss wrote: > My previous bug, BZ#1028922, was closed inappropriately, given that the > bug is not fixed in Bookworm, and will impact Bullseye users until Bullseye > leaves support. The Debian bug tracker (which isn’t Bugzilla ;-) takes version information into account; if you look at the diagram on the right-hand side of https://bugs.debian.org/1028922 you’ll see that the only fixed version is the version currently in unstable, and that the versions currently in stable (Bullseye) and testing (Bookworm) are marked as unfixed. Likewise, if you compare https://bugs.debian.org/solaar;dist=stable and https://bugs.debian.org/solaar;dist=unstable you’ll see that the former still lists 1028922 as outstanding, i.e. unresolved. I’m merging this bug with 1028922 and upgrading the importance of the latter, so that it can be fixed in an upcoming Bullseye point release (if the stable release managers approve). Regards, Stephen pgpYWWwnXEZiU.pgp Description: OpenPGP digital signature
Bug#1028073: libonvif: Fix build problem on hurd
The header has been removed from source code, as well as other unneeded headers in that section. Only and are needed. On Fri, Jan 6, 2023 at 9:33 AM Petter Reinholdtsen wrote: > > Package: libonvif > Version: 1.4.4-1 > Tags: patch > > The code enumerating all network interfaces using getifaddrs() include a > linux specific header file. As far as I can tell from getifaddrs(3), > there is no need for the include, only the > one is needed. The latter is available on Hurd, while the former is > not. > > This patch get the code building on Debian Hurd. > > diff --git a/onvif-gui/src/settingspanel.cpp > b/onvif-gui/src/settingspanel.cpp > index b0c6e72..ff0cc52 100644 > --- a/onvif-gui/src/settingspanel.cpp > +++ b/onvif-gui/src/settingspanel.cpp > @@ -31,7 +31,6 @@ > #include > #include > #include > -#include > #endif > > #include > > -- > Happy hacking > Petter Reinholdtsen >
Bug#1028050: ITP: pyqt6-charts -- Python 3 bindings for Qt6's Charts module
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pyqt6-charts Version : 6.4.0 Upstream Author : Riverbank Computing * URL : https://riverbankcomputing.com/software/pyqtchart/ * License : GPL-3 Programming Lang: C++ Description : Python 3 bindings for Qt6's Charts module The Charts module of PyQt6 provides widgets and utility classes for chart rendering in a PyQt6 application. This will be maintained in the Debian Python team.
Bug#1027941: O: keras-preprocessing -- data preprocessing module for the Keras deep learning framework
Package: wnpp Severity: normal X-Debbugs-Cc: keras-preprocess...@packages.debian.org Control: affects -1 + src:keras-preprocessing I intend to orphan the keras-preprocessing package, as it is no longer maintained upstream as an independent software from tensorflow, and the base package keras is now giving errors with the latest version of numpy that I cannot resolve. The package description is: Keras is a Python library for machine learning based on deep (multi- layered) artificial neural networks (DNN), which follows a minimalistic and modular design with a focus on fast experimentation. . Features of DNNs like neural layers, cost functions, optimizers, initialization schemes, activation functions and regularization schemes are available in Keras a standalone modules which can be plugged together as wanted to create sequence models or more complex architectures. Keras supports convolutions neural networks (CNN, used for image recognition resp. classification) and recurrent neural networks (RNN, suitable for sequence analysis like in natural language processing). . It runs as an abstraction layer on the top of Theano (math expression compiler) by default, which makes it possible to accelerate the computations by using (GP)GPU devices. Alternatively, Keras could run on Google's TensorFlow (not yet available in Debian). . Keras Preprocessing is the data preprocessing and data augmentation module of the Keras deep learning library. It provides utilities for working with image data, text data, and sequence data.
Bug#1027940: O: keras-applications -- popular models and pre-trained weights for the Keras deep learning framework
Package: wnpp Severity: normal X-Debbugs-Cc: keras-applicati...@packages.debian.org Control: affects -1 + src:keras-applications I intend to orphan the keras-applications package, as the upstream package is no longer maintained as an independent software from tensorflow, and its base package keras now has errors with the latest version of numpy that I cannot resolve. The package description is: Keras is a Python library for machine learning based on deep (multi- layered) artificial neural networks (DNN), which follows a minimalistic and modular design with a focus on fast experimentation. . Features of DNNs like neural layers, cost functions, optimizers, initialization schemes, activation functions and regularization schemes are available in Keras a standalone modules which can be plugged together as wanted to create sequence models or more complex architectures. Keras supports convolutions neural networks (CNN, used for image recognition resp. classification) and recurrent neural networks (RNN, suitable for sequence analysis like in natural language processing). . It runs as an abstraction layer on the top of Theano (math expression compiler) by default, which makes it possible to accelerate the computations by using (GP)GPU devices. Alternatively, Keras could run on Google's TensorFlow (not yet available in Debian). . Keras Applications is the applications module of the Keras deep learning library. It provides model definitions and pre-trained weights for a number of popular architectures, such as VGG16, ResNet50, Xception, MobileNet, and more.
Bug#1027938: O: keras -- deep learning framework running on Theano or TensorFlow
Package: wnpp Severity: normal X-Debbugs-Cc: ke...@packages.debian.org Control: affects -1 + src:keras I intend to orphan the keras package, as it is no longer updated as an independent package outside of tensorflow, and the last independent problem now has difficult to resolve errors with the latest version of numpy. The package description is: Keras is a Python library for machine learning based on deep (multi- layered) artificial neural networks (DNN), which follows a minimalistic and modular design with a focus on fast experimentation. . Features of DNNs like neural layers, cost functions, optimizers, initialization schemes, activation functions and regularization schemes are available in Keras a standalone modules which can be plugged together as wanted to create sequence models or more complex architectures. Keras supports convolutions neural networks (CNN, used for image recognition resp. classification) and recurrent neural networks (RNN, suitable for sequence analysis like in natural language processing). . It runs as an abstraction layer on the top of Theano (math expression compiler) by default, which makes it possible to accelerate the computations by using (GP)GPU devices. Alternatively, Keras could run on Google's TensorFlow (not yet available in Debian).
Bug#1027668: mc: Copying with fish fails when the local temporary directory fills up
Package: mc Version: 3:4.8.26-1.1 Severity: normal Dear Maintainer, When copying files remotely using fish, if the local temporary directory fills up, the copy fails saying that there is no disk space to copy the file. This is somewhat confusing since the target may well have plenty of space. This isn’t helped by the fact that fish keeps its local copies even when they have been transferred to the remote. Thus copying a set of files larger than the available disk space on the local temporary file system is guaranteed to fail, even if the files are individually small enough to fit in the local temporary directory. (The failure isn’t drastic: only the last copied file is affected, and another copy can be started to continue copying.) Regards, Stephen -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 5.10.0-20-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mc depends on: ii libc6 2.31-13+deb11u5 ii libext2fs21.46.2-2 ii libglib2.0-0 2.66.8-1 ii libgpm2 1.20.7-8 ii libslang2 2.3.2-5 ii libssh2-1 1.9.0-2 ii mc-data 3:4.8.26-1.1 Versions of packages mc recommends: ii mime-support3.66 ii perl5.32.1-4+deb11u2 ii sensible-utils 0.0.14 ii unzip 6.0-26+deb11u1 Versions of packages mc suggests: ii arj 3.10.22-24 ii bzip2 1.0.8-4 ii catdvi0.14-12.1+b1 ii dbview1.0.4-4 ii djvulibre-bin 3.5.28-2 pn epub-utils ii evince [pdf-viewer] 3.38.2-1 ii file 1:5.39-3 ii genisoimage 9:1.1.11-3.2 ii gv [pdf-viewer] 1:3.7.4-2+b1 ii imagemagick 8:6.9.11.60+dfsg-1.3 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3 pn libaspell-dev ii lynx 2.9.0dev.6-3~deb11u1 ii odt2txt 0.5-7 ii okular [pdf-viewer] 4:20.12.3-2 ii poppler-utils 20.09.0-3.1+deb11u1 pn python pn python-boto pn python-tz ii texlive-binaries 2020.20200327.54578-7 ii unar 1.10.1-2+b6 ii w3m 0.5.3+git20210102-6 pn wimtools ii xpdf [pdf-viewer] 3.04+git20210103-3 ii zathura-pdf-poppler [pdf-viewer] 0.3.0-1 ii zip 3.0-12 -- no debconf information
Bug#1025137: bullseye-pu: package g810-led/0.4.2-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
g810-led has a security issue in stable; it leaves /dev/input/eventXX
device nodes world-readable and writable (CVE-2022-46338). The issue
is marked no-dsa, but I would like to provide a fix in the next
point-release. The fix is already in unstable (0.4.2-3).
The attached debdiff fixes the issue by patching the udev rules file:
the affected device nodes have their mode set to 660 instead of 666,
and uaccess is used to provide access to the user at the console. I
own relevant hardware and have verified the fix myself on a multi-user
system.
[ 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
Regards,
Stephen
diff -Nru g810-led-0.4.2/debian/changelog g810-led-0.4.2/debian/changelog
--- g810-led-0.4.2/debian/changelog 2020-05-23 20:33:29.0 +0200
+++ g810-led-0.4.2/debian/changelog 2022-11-30 08:24:25.0 +0100
@@ -1,3 +1,11 @@
+g810-led (0.4.2-1+deb11u1) bullseye; urgency=medium
+
+ * Control device access with uaccess instead of making everything
+world-writable. Thanks to Xavi Drudis Ferran for the report!
+Closes:#1024998. (CVE-2022-46338.)
+
+ -- Stephen Kitt Wed, 30 Nov 2022 08:24:25 +0100
+
g810-led (0.4.2-1) unstable; urgency=medium
* New upstream release.
diff -Nru g810-led-0.4.2/debian/patches/device-permissions.patch
g810-led-0.4.2/debian/patches/device-permissions.patch
--- g810-led-0.4.2/debian/patches/device-permissions.patch 1970-01-01
01:00:00.0 +0100
+++ g810-led-0.4.2/debian/patches/device-permissions.patch 2022-11-30
08:23:44.0 +0100
@@ -0,0 +1,74 @@
+commit e2b486fd1bc21e0b784e1b4c959770772dfced24
+Author: Stephen Kitt
+Date: Mon Nov 28 21:05:05 2022 +0100
+
+Rely on uaccess to control device access
+
+The udev rules currently make supported device nodes world-readable
+and writable, which means that any process on the system can read
+traffic from keyboards including passwords etc. To avoid this, while
+still allowing the "controlling" user to run g810-led without being
+root, this patch adds a uaccess tag; this ensures that the user at the
+console has write access to the devices. The mode is also changed to
+660 to ensure that existing device nodes are fixed on upgrade.
+
+Thanks to Xavi Drudis Ferran for bringing this to my attention.
+
+Fixes: #293
+Signed-off-by: Stephen Kitt
+
+diff --git a/udev/g810-led.rules b/udev/g810-led.rules
+index 90b743b..ea05726 100644
+--- a/udev/g810-led.rules
b/udev/g810-led.rules
+@@ -1,25 +1,25 @@
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d",
ATTRS{idProduct}=="c336", MODE="666" RUN+="/usr/bin/g213-led -p
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d",
ATTRS{idProduct}=="c330", MODE="666" RUN+="/usr/bin/g410-led -p
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d",
ATTRS{idProduct}=="c33a", MODE="666" RUN+="/usr/bin/g413-led -p
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d",
ATTRS{idProduct}=="c342", MODE="666" RUN+="/usr/bin/g512-led -p
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d",
ATTRS{idProduct}=="c33c", MODE="666" RUN+="/usr/bin/g513-led -p
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d",
ATTRS{idProduct}=="c333", MODE="666" RUN+="/usr/bin/g610-led -p
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d",
ATTRS{idProduct}=="c338", MODE="666" RUN+="/usr/bin/g610-led -p
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d",
ATTRS{idProduct}=="c331", MODE="666" RUN+="/usr/bin/g810-led -p
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d",
ATTRS{idProduct}=="c337", MODE="666" RUN+="/usr/bin/g810-led -p
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d",
ATTRS{idProduct}=="c33f", MODE="666" RUN+="/usr/bin/g815-led -p
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="u
Bug#1024998: g810-led: Security risk: Leaves /dev/input/event* with read and write permissions for all users
On Wed, 30 Nov 2022 06:59:41 +0100, Salvatore Bonaccorso wrote: > The issue got CVE-2022-46338 assigned by MITRE. > > Stephen, the issue is marked no-dsa for bullseye, but a fix might go > still trough the upcoming point release (scheduled for 17th december). Thanks, I’ll submit a stable update. Regards, Stephen pgpsjkR9gwwEH.pgp Description: OpenPGP digital signature
Bug#1024998: g810-led: Security risk: Leaves /dev/input/event* with read and write permissions for all users
Hi, On Mon, 28 Nov 2022 15:45:16 +0100, Xavi Drudis Ferran wrote: > I hesitate to file as critical, but I came across a bug report in > upstream that looked serious enough since it would allow all local > processes to eavesdrop on keyboard input, including passwords, etc. I > haven't tried an exploit, but it seemed better to just restrict > /dev/input/event* permissions to those of other event dev files. > > Without this patch, I can read /dev/input/event2 and /dev/input/event3 as a > normal user. I see bytes in /dev/input/event2 when typing as a normal > user and also typing in another terminal (Konsole) typing as > root. event3 only shows the characters typed by the normal user. > > With the patch I can't read /dev/input/event* as a normal user. Thanks for bringing this up! I’d rather use uaccess, see https://github.com/MatMoul/g810-led/pull/297 I’ll upload a fixed package shortly and see about a security update for stable. Regards, Stephen pgpNel_TR6FzR.pgp Description: OpenPGP digital signature
Bug#1024434: osslsigncode: Fails to sign code with pkcs12
On Sat, 19 Nov 2022 14:59:57 +0100, Stefan Weil wrote: > Am 19.11.22 um 14:03 schrieb Stephen Kitt: > > Since you have a working build, could you run ldd on it and reply with the > > result? > [...] > > That differs from the non-working one which does not use > libcrypto.so.1.1 (that's the only difference). > > It looks like libcrypto.so.1.1 is essential: after libssl1.1 (which > provides libcrypto.so.1.1) was uninstalled, a fresh build also produces > a failing osslsigncode. > > So it works with libssl1, but not with libssl3. Thanks! This is an upstream bug: https://github.com/mtrojnar/osslsigncode/issues/178 libssl1.1 is no longer available for packages to build against, so we’ll have to wait for an upstream fix. Regards, Stephen pgp5ieSH2z7XQ.pgp Description: OpenPGP digital signature
Bug#1024434: osslsigncode: Fails to sign code with pkcs12
Hi Stefan, On Sat, 19 Nov 2022 12:59:07 +0100, Stefan Weil wrote: > Code signing no longer works with the package from Debian bookworm, > while Debian bullseye and a local build based on > https://github.com/mtrojnar/osslsigncode works fine. Thanks for taking the time to report this! Since you have a working build, could you run ldd on it and reply with the result? Regards, Stephen pgpReeJAUS5bX.pgp Description: OpenPGP digital signature
Bug#1022921: wine: broken packages after running dist-upgrade
Hi Tobias, On Thu, 27 Oct 2022 17:53:29 +0200, Tobias Koeck wrote: > unfortunately the system installed or wanted to install the newer > version after running. > > apt-get dist-upgrade -t bullseye-backports This is generally a bad idea, backports repositories shouldn’t be enabled globally for upgrades. However that’s not the problem here... > libwine : Depends: libz-mingw-w64 (>= 1.2.11+dfsg-4) but 1.2.11+dfsg-2 is > to be installed Phil, wine’s debian/control hard-codes the above version as a minimum requirement on libz-mingw-w64, but there is no satisfactory version available in stable or backports. Presumably Wine needs a version of the libz DLL with no GCC dependencies, so we’d have to backport libz-mingw-w64 too. I can take care of that this weekend. Regards, Stephen pgp1Ju1e4vs6h.pgp Description: OpenPGP digital signature
Bug#1022779: dosbox: could dosbox-x be a future to dosbox?
I’ve heard of DOSBox Staging, but AFAICT all its features are in DOSBox-X. Someone else is working on packaging that, see https://bugs.debian.org/973822 Regards, Stephen On Wed, 26 Oct 2022 19:53:22 +0200, Patrice wrote: > So nice! > > Do you know this one https://github.com/dosbox-staging/dosbox-staging ? > I found some packagings on Salsa like: > https://salsa.debian.org/okias/dosbox-staging > but it remained at the version 0.76.0 and now the upstream is 0.79.1. > I haven't tried it yet. > > Best, > Patrice > > On Wed, 26 Oct 2022 11:59:29 +0200 Stephen Kitt wrote: > > Hi Patrice, > > > > Le 25/10/2022 19:55, Patrice Duroux a écrit : > > > The dosbox-x project (https://dosbox-x.com/) is currently version > > > 0.84.3 > > > (2022.09.0) > > > and seems to be SDL 2 compatible. > > > Have you tried it? > > > > I have, and I’m actually working on packaging it. I’ve just filed an ITP > > to trace that fact, https://bugs.debian.org/1022800 > > > > Regards, > > > > Stephen > > > > pgpl6nL3AvU2B.pgp Description: OpenPGP digital signature
Bug#1022779: dosbox: could dosbox-x be a future to dosbox?
Hi Patrice, Le 25/10/2022 19:55, Patrice Duroux a écrit : The dosbox-x project (https://dosbox-x.com/) is currently version 0.84.3 (2022.09.0) and seems to be SDL 2 compatible. Have you tried it? I have, and I’m actually working on packaging it. I’ve just filed an ITP to trace that fact, https://bugs.debian.org/1022800 Regards, Stephen
Bug#1022800: ITP: dosbox-x -- DOS emulator with complete, accurate hardware emulation
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: dosbox-x Version : 0.84.3 Upstream Author : Jonathan Campbell * URL : https://dosbox-x.com/ * License : GPL-2+ Programming Lang: C, C++ Description : DOS emulator with complete, accurate hardware emulation DOSBox-X is a comprehensive DOS emulator, supporting DOS applications including Windows 3.x and Windows 9x, and striving to provide accurate hardware emulation. It is based on the original DOSBox and includes features from a number of forks including SVN Daum, ECE, DOSBox Staging, DOSVAX, and vDosPlus. Its features include: * a built-in drop-down menu * a graphical configuration tool * support for save-states * NEC PC-98, AX, and J-3100 emulations * DOS/V support for Chinese, Japanese, and Korean language support * support for CONFIG.SYS commands * printing support * long filename support * DOS SHARE emulation * wheel mouse support (including the CuteMouse wheel mouse API) * 3Dfx Voodoo chip and Glide emulation * NE2000 emulation * MT-32 emulation DOSBox-X isn't a direct upgrade from DOSBox, but DOSBox users should be able to use DOSBox-X without difficulty.
Bug#1022051: /boot/vmlinuz-5.10.0-19-amd64: Same Here
Package: src:linux Version: 5.10.149-1 Followup-For: Bug #1022051 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Maintainer, * What led up to the situation? Normal kernal package upgrade and reboot. * What exactly did you do (or not do) that was effective (or ineffective)? 5.10.0-18 works fine. 5.10.0-19 always hangs with "flip_done timed out" before I can get even a text console. * What was the outcome of this action? Using older kernel for now. * What outcome did you expect instead? 5.10.0-19 bootable. - -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: To Be Filled By O.E.M. product_name: To Be Filled By O.E.M. product_version: To Be Filled By O.E.M. chassis_vendor: Default string chassis_version: Default string bios_vendor: American Megatrends Inc. bios_version: P2.00 board_vendor: ASRock board_name: X399 Taichi board_version: ** Network interface configuration: *** /etc/network/interfaces: auto lo iface lo inet loopback ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Root Complex [1022:1450] Subsystem: ASRock Incorporation Family 17h (Models 00h-0fh) Root Complex [1849:1450] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge [1022:1453] (prog-if 00 [Normal decode]) Subsystem: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge [1022:1453] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 59) Subsystem: ASRock Incorporation FCH SMBus Controller [1849:] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset SATA Controller [1022:43b6] (rev 02) (prog-if 01 [AHCI 1.0]) Subsystem: ASMedia Technology Inc. X399 Series Chipset SATA Controller [1b21:1062] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: ahci Kernel modules: ahci 01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset PCIe Bridge [1022:43b1] (rev 02) (prog-if 00 [Normal decode]) Subsystem: ASMedia Technology Inc. X399 Series Chipset PCIe Bridge [1b21:0201] Control:
Bug#1020935: Old Version of go used to build git-lfs
On Sep 28, 2022 at 4:49:29 PM, "Bower, Jesse (LNG-HBE)" < jesse.bo...@lexisnexis.com> wrote: > Package: git-lfs > > Version: 2.13.2-1+b5 > > After I install git-lfs the docker image is seen as having the following > cve’s: > > CVE-2022-23806 > CVE-2021-38297 > CVE-2022-27664 > CVE-2022-30631 > CVE-2022-32189 > CVE-2022-30632 > CVE-2022-30635 > CVE-2022-28131 > CVE-2022-30630 > CVE-2022-30633 > CVE-2022-23773 > CVE-2022-24921 > CVE-2022-24675 > CVE-2022-28327 > CVE-2022-30580 > CVE-2021-41772 > CVE-2021-41771 > CVE-2021-44716 > CVE-2021-39293 > CVE-2022-23772 > CVE-2021-33194 > CVE-2021-33195 > CVE-2021-33196 > CVE-2021-33198 > CVE-2021-29923 > > Seen from the version of go used to build git-lfs, > > "name": "go", > "version": "1.15.9", > "path": "/usr/bin/git-lfs", > "layerTime": 0, > "knownVulnerabilities": 72 > > Example Dockerfile used for testing > > FROM debian:stable-slim > > RUN apt-get update && apt-get upgrade -y && apt-get install -y git-lfs > > > > I suggest that the version of go used to build git-lfs is updated to a > current version. > > > > Thank you, > > Jesse Bower > Jesse, The way that go packages are built in Debian is that they are required to use the version of the go compiler in the current release. Therefore, any CVEs that are patched there are also patched in this version of git-lfs. If there are unpatched vulnerabilities with the debian go compiler, you will instead need to file a bug against the golang-go package. Stephen
Bug#1021349: RFA: wput -- tiny wget-like ftp-client for uploading files
Package: wnpp Severity: normal Control: affects -1 src:wput I request an adopter for the wput package. I no longer use the package, everything I used it for can be done with curl; wput hasn't been maintained upstream for a long time, whereas curl is very actively maintained. (All this means that it may be better to drop wput entirely.) The package description is: Wput is a tiny ftp-client, that uploads files or directories to a remote ftp-server. . Main features are: resuming, time-stamping, wget-like interface, proxy-support and speed-limit.
Bug#1021346: RM: osslsigncode [s390x] -- ROM; no longer builds on s390x
Package: ftp.debian.org Severity: normal Dear FTP team, Please remove osslsigncode on s390x; its test suite fails there, which means the package doesn't work correctly on that architecture. Regards, Stephen
Bug#1020544: siconos: FTBFS on s390x: Cholesky solve kNM_test failed
On Fri, Sep 23, 2022 at 5:33 AM Aron Xu wrote: > Package: siconos > Version: 4.4.0+dfsg-1 > Severity: important > > The new version FTBFS on s390x in test suite 23, relevant log entry: > > > Cholesky solve preserving matrix > > Cholesky solve kNM_test: ./numerics/src/tools/NumericsMatrix.c:3023: > NM_csc: > Assertion `A->matrix2->csc->m == A->size0 && "inconsistent size > > Full build log is > > https://buildd.debian.org/status/fetch.php?pkg=siconos=s390x=4.4.0%2Bdfsg-1=1663797112=0 > > Regards, > Aron > > Thanks for this bug report. I was able to reproduce the problem under qemu, and it is unclear to me whether the problem is actually a missing step in dense-to-sparse conversion, or simply a problematic assert after. It seems to be an issue showing up only on this architecture, because the numerical results of the test are slightly different, but this is possibly revealing a logical error in how dense to sparse is working or how the results are checked. Therefore, I have reported it upstream [0] and will try to include a patch in a package update if/when we are able to determine what is going on here. [0] https://github.com/siconos/siconos/issues/467 regards, Steve
Bug#1020738: RM: hubicfuse -- ROM; service is shutting down
Package: ftp.debian.org Severity: normal Dear FTP team, hubicfuse is only useful with the hubiC service, and that is shutting down on September 30. The replacement is Nextcloud-based so hubicfuse won't be any use with it. Regards, Stephen
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
Hi Aurelien, On Tue, Sep 20, 2022 at 11:20:26PM +0200, Aurelien Jarno wrote: > Have you been able to progress on that? Do you need some help for a > specific step? For what it’s worth, I’ve upgraded libc6 on my Haswell system (Xeon E3-1245v3) and everything seems to be working fine. Regards, Stephen signature.asc Description: PGP signature
Bug#1020398: ITP: jqp -- A TUI playground to experiment with jq
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: jqp Version : 0.1.0-1 Upstream Author : Noah Gorstein * URL : https://github.com/noahgorstein/jqp * License : Expat Programming Lang: Go Description : A TUI playground to experiment with jq A TUI tool that allows for experimentation with jq with fast iteration. This application utilizes itchny's (https://github.com/itchyny) implementation of jq written in Go, gojq (https://github.com/itchyny/gojq). This package will be team maintained by the go team.
Bug#1020218: vcmi: luajit got removed on ppc64el, please either drop vcmi on ppc64el or switch to lua
Hi josch, Le 19/09/2022 11:00, Johannes Schauer Marin Rodrigues a écrit : Quoting Paul Gevers (2022-09-18 11:44:07) vcmi build depends on libluajit-5.1-dev but that got removed on ppc64el because it doesn't work correcty on that architecture and noone volunteers to fix *and maintain* it on that architecture. See bug #1014853. Please investigate if you can just use liblua or if your package needs to be removed on ppc64el. I thought according to the recent threat on d-devel [1] packages that FTBFS on some arches should rather just let it FTBFS instead of maintaining a list of architectures the package can be built on? [1] https://lists.debian.org/20220911150857.xedt2an2vye3qrc7@begin I don’t think Paul was necessarily asking to remove ppc64el from the list of architectures in debian/control, but rather asking to remove the ppc64el binary package if we can’t get it working with liblua. The best course of action IMO is to file a RM bug for vcmi on ppc64el so that the package can migrate to testing, and then if someone fixes the Lua situation (either on pcc64el globally, or by switching vcmi to liblua) the package will become available on ppc64el again. Regards, Stephen
Bug#1020272: ITP: wormhole-william -- End-to-end encrypted file transfer. A magic wormhole CLI and API in Go (golang).
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: wormhole-william Version : 1.0.6-1 Upstream Author : Peter Sanford * URL : https://github.com/psanford/wormhole-william * License : Expat Programming Lang: Go Description : End-to-end encrypted file transfer. A magic wormhole CLI and API in Go (golang). wormhole-william wormhole-william is a Go (golang) implementation of magic wormhole (https://magic-wormhole.readthedocs.io/en/latest/). It provides secure end-to-end encrypted file transfers between computers. The endpoints are connected using the same "wormhole code". wormhole-william is compatible with the official python magic wormhole cli tool (https://github.com/warner/magic-wormhole). Currently, wormhole-william supports: * sending and receiving text over the wormhole protocol * sending and receiving files over the transit protocol * sending and receiving directories over the transit protocol This is a dependency of termshark 2.4.0. It will be team maintained by the go team.
Bug#1020271: ITP: golang-nhooyr-websocket -- Minimal and idiomatic WebSocket library for Go
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-nhooyr-websocket Version : 1.8.7-1 Upstream Author : Anmol Sethi * URL : https://github.com/nhooyr/websocket * License : Expat Programming Lang: Go Description : Minimal and idiomatic WebSocket library for Go websocket is a minimal and idiomatic WebSocket library for Go. Highlights * Minimal and idiomatic API * First class context.Context (https://blog.golang.org/context) support * Fully passes the WebSocket autobahn-testsuite (https://github.com/crossbario/autobahn-testsuite) * Single dependency (https://pkg.go.dev/nhooyr.io/websocket?tab=imports) * JSON and protobuf helpers in the wsjson (https://pkg.go.dev/nhooyr.io/websocket/wsjson) and wspb (https://pkg.go.dev/nhooyr.io/websocket/wspb) subpackages * Zero alloc reads and writes * Concurrent writes * Close handshake (https://pkg.go.dev/nhooyr.io/websocket#Conn.Close) * net.Conn (https://pkg.go.dev/nhooyr.io/websocket#NetConn) wrapper * Ping pong (https://pkg.go.dev/nhooyr.io/websocket#Conn.Ping) API * RFC 7692 (https://tools.ietf.org/html/rfc7692) permessage-deflate compression * Compile to Wasm (https://pkg.go.dev/nhooyr.io/websocket#hdr-Wasm) This is a dependency for wormhole-william, which is in turn a dependency for the new release of termshark. This package will be team maintaned by the go team.
Bug#1020270: ITP: golang-debian-vasudev-gospake2 -- Go SPAKE2 Implementation
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-debian-vasudev-gospake2 Version : 0.2.1+git20210510.d916299-1 Upstream Author : Vasudev Kamath * URL : https://salsa.debian.org/vasudev/gospake2 * License : Expat or GPL-3 Programming Lang: Go Description : Go SPAKE2 Implementation (library) Implementation of SPAKE2 key exchange protocol which interoperates with Rust Haskell and Python versions. This package defines the behavior of group and its element as package groups. It also implements 2 groups ed25519 and multiplicative group over integer as 2 packages. SPAKE2 calculation uses ed25519 as default group and allows user to switch to group of his choice. This is a dependency for wormhole-william, which is in turn a dependency for the new release of termshark. This package will be team maintaned by the go team.
Bug#1019139: ITP: zpaqfranz -- Swiss army knife for backup and disaster recovery
Hi, On Tue, 13 Sep 2022 22:09:10 +0200, Bastian Germann wrote: > X-Debbugs-Cc: sk...@debian.org > > On Sun, 04 Sep 2022 14:53:45 +0200 root wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Franco Corbelli > > > > * Package name: zpaqfranz > > Version : 55.14 > > Upstream Author : Franco Corbelli > > * URL : https://github.com/fcorbelli/zpaqfranz > > * License : MIT > > Programming Lang: C, C++ > > Description : Swiss army knife for backup and disaster recovery > > > > Like 7z or RAR on steroids,with deduplicated "snapshots" (versions) > > Conceptually similar to Mac time machine, but much more efficiently > > Keeps backup always-to-always, no need to ever prune (CryptoLocker) > > Easily handles millions of files and TBs of data, non-latin support > > Cloud backups with full encryption, minimal data transfer/bandwidth > > Data integrity check CRC32+XXHASH|SHA-1|SHA-2|SHA-3|MD5|XXH3|BLAKE3 > > Thorough data verification, multithread support (real world 1GB+/s) > > Specific zfs handling functions,full multiplatform interoperability > > Particularly suitable for minimal space storage of virtual machines > > > > Windows, FreeBSD, OpenBSD, Linux, MacOS, Solaris, OmniOS and others > > > > > > __ > > This is a fork of zpaq 7.15 (already in Debian) which was abandoned > > by the developer (Matt Mahoney) in 2016. > > As zpaqfranz is supposed to be a compatible replacement for zpaq, > I suggest to make it the new upstream of the existing zpaq package. > > Stephen, any opinions on this? I agree, this should replace zpaq. In fact Franco Corbelli asked me about this quite a while ago but I never looked into it in detail, sorry about that! Franco, if you need help getting this into Debian, feel free to ping me, I’d be happy to review and sponsor your package, or help you package zpaqfranz if appropriate. Regards, Stephen pgpV1cOha_4V7.pgp Description: OpenPGP digital signature
Bug#823061: Greetings from Mr. Stephen Melvin!!!
Hello Dear, I have called you several times but didn't get through the phone. Please contact me at my email address, I have an important thing to discuss with you: mmrstephe...@gmail.com
Bug#1019867: ITP: qrterminal -- Display QR Codes in terminal
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: qrterminal Version : 3.0.0-1 Upstream Author : Mark Percival * URL : https://github.com/mdp/qrterminal * License : Expat Programming Lang: Go Description : Display QR Codes in terminal A golang library for generating QR codes in the terminal. Originally this was a port of the NodeJS version. Recently it's been updated to allow for smaller code generation using ASCII 'half blocks' This package will be team maintained by the go team. This is a dependency of wormhole-william, which is in turn a dependency of termshark 4.2.0
Bug#1019859: ITP: golang-gitlab-jonas.jasas-condchan -- TODO
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-gitlab-jonas.jasas-condchan Version : 0.0~git20190210.36637ad-1 Upstream Author : Jonas Jasas * URL : https://gitlab.com/jonas.jasas/condchan * License : Expat Programming Lang: Go Description : Cancellable sync.Cond CondChan is a sync.Cond with the ability to wait in select statement. - Adds waiting in select statement feature - Implements all sync.Cond interface - Passes all sync.Cond tests - Implemented using channels - Just ~37% slower comparing to sync.Cond This package will be team-maintaned. This is a dependency of termshark
Bug#1019856: ITP: golang-github-flytam-filenamify -- Convert a string to a valid safe filename on Golang
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-github-flytam-filenamify Version : 1.1.1-1 Upstream Author : tanjiahui * URL : https://github.com/flytam/filenamify * License : Expat Programming Lang: Go Description : Convert a string to a valid safe filename Converts a string to a valid safe filename. Package will be team maintained by the go team. A new dependency of termshark 2.4.0
Bug#1016600: siconos: vtk[6,7] removal
On Thu, Sep 1, 2022 at 10:56 PM Adrian Bunk wrote: > > On Wed, Aug 03, 2022 at 10:42:08PM +0200, Sebastian Ramacher wrote: > > Source: siconos > > Version: 4.3.1+dfsg-2 > > Severity: serious > > X-Debbugs-Cc: sramac...@debian.org > > Tags: sid bookworm > > Control: block 1016597 by -1 > > User: gl...@debian.org > > Usertags: vtk6_vtk7_removal > > > > Based on #1013156 and similar bugs: > > > > Dear maintainer, > > > > Debian archive has now three major versions of the VTK (The > > Visualization Toolkit) package: vtk6, vtk7 and vtk9. Old vesions > > (vtk6 and vtk7) are not supported by upstream and the package itself > > is not easy for the mainance. > > > > We aim to drop old and deprecated version vtk6 and vtk7 packages before > > the freeze of the Debian 12 Bookworm. Your package depends on vtk6 or > > vtk7. Thus we ask you to migrate it to the latest vtk9 package. > > Two observations regarding the usage of VTK in siconos: > > There is WITH_VTK in siconos that does not seem to build with VTK 9, > but it's anyway not enabled. > > The only current usage of VTK is python3-vtk7 in siconos-mechanics-tools. > This might need upstrream fixes like > https://github.com/siconos/siconos/pull/437 > > > Cheers Thank you Adrian. I have an update to the package for a newer upstream version that has been under construction for a while, but I haven't been available until recently to work on it more. I'll try to get this done soon. Steve
Bug#967353: freeciv: depends on deprecated GTK 2
On Mon, 29 Aug 2022 20:43:01 +0200, Tobias Frost wrote: > On Mon, Aug 29, 2022 at 08:33:12PM +0200, Stephen Kitt wrote: > > On Mon, 29 Aug 2022 20:06:12 +0200, Tobias Frost wrote: > > > On Tue, 04 Aug 2020 11:38:27 +0100 s...@debian.org wrote: > > > > Source: freeciv > > > > Severity: normal > > > > User: pkg-gnome-maintain...@lists.alioth.debian.org > > > > Usertags: gtk2 oldlibs > > > > Control: block 947713 by -1 > > > > > > > > This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces > > > > binary packages with a Depends on GTK 2. > > > > > > (...) > > > > > > Upstream says in 3.0.3 (doc/README.packaging): > > > > * Gtk2-client is no longer considered maintained client > > > > > > So I guess the gtk2 client should not be released with bookworm… > > > > > > Any thoughts (question directed to the games team)? > > > > It’s gone entirely in 3.0.3, isn’t it? So if you’re upgrading to that > > release, it seems the freeciv-gtk package should be dropped (or rather, > > turned into a transitional package pulling freeciv-gtk3). > > The client is still there in 3.0.3 (but needs to be enabled manually, > at least it builds; not yet there to see if it works…) Ah yes, I started with the main branch and didn’t check 3.0.3 thoroughly enough. However given that GTK 2 is obsolete in general, and the existence of other (maintained) Freeciv clients, I don’t think it’s all useful to keep the GTK 2 client for Bookworm. Regards, Stephen pgpg5UpEajORr.pgp Description: OpenPGP digital signature
Bug#967353: freeciv: depends on deprecated GTK 2
Hi, On Mon, 29 Aug 2022 20:06:12 +0200, Tobias Frost wrote: > On Tue, 04 Aug 2020 11:38:27 +0100 s...@debian.org wrote: > > Source: freeciv > > Severity: normal > > User: pkg-gnome-maintain...@lists.alioth.debian.org > > Usertags: gtk2 oldlibs > > Control: block 947713 by -1 > > > > This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces > > binary packages with a Depends on GTK 2. > > (...) > > Upstream says in 3.0.3 (doc/README.packaging): > > * Gtk2-client is no longer considered maintained client > > So I guess the gtk2 client should not be released with bookworm… > > Any thoughts (question directed to the games team)? It’s gone entirely in 3.0.3, isn’t it? So if you’re upgrading to that release, it seems the freeciv-gtk package should be dropped (or rather, turned into a transitional package pulling freeciv-gtk3). Regards, Stephen pgpeaw_jMrz5W.pgp Description: OpenPGP digital signature
Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1
On Aug 29, 2022 at 6:52:06 AM, Luca Falavigna wrote: > Il giorno lun 29 ago 2022 alle ore 07:34 Stephen Gelman > ha scritto: > > Would you be interested in creating a MR for your changes to salsa? If not > that’s fine, just let me know and I will pull in the changes myself. > > > Sure, here it is: > https://salsa.debian.org/ssgelm/opentracing-cpp/-/merge_requests/1 > > -- > Cheers, > Luca > This looks awesome; I merged it. Would you like to cancel your NMU and I can release 1.6.0-3 now, or would you prefer to wait for your NMU? I don’t have particularly strong feelings in either direction. Stephen
Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1
On Aug 28, 2022 at 4:29:03 AM, Luca Falavigna wrote: > Control: tags 1017132 + patch > Control: tags 1017132 + pending > > > Dear maintainer, > > I've prepared an NMU for opentracing-cpp (versioned as 1.6.0-2.1) and > uploaded it to DELAYED/7. Please feel free to tell me if I > should delay it longer. > > Regards, > Luca > This is awesome, thanks so much! It was on my todo list to fix but I hadn’t gotten around to it yet… Would you be interested in creating a MR for your changes to salsa? If not that’s fine, just let me know and I will pull in the changes myself. Stephen
Bug#1018078: hdparm: new upstream release(s) available
Package: hdparm Version: 9.60+ds-1 Severity: wishlist Dear Maintainer, Multiple upstream releases have been made available since 9.60; the current release is 9.64. It would be great if hdparm could be updated before the next release of Debian. In particular, 9.61 fixes set-sector-size handling. Regards, Stephen -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hdparm depends on: ii libc6 2.31-13+deb11u3 ii lsb-base 11.1.0 Versions of packages hdparm recommends: ii powermgmt-base 1.36 hdparm suggests no packages. -- no debconf information
Bug#1017955: bugs.debian.org: 1017155 is innaccessible
Package: bugs.debian.org Severity: normal Dear Maintainer, Attempting to access https://bugs.debian.org/1017155 results in > An error occurred. Error was: Bad bug log for Bug 1017155. Unable to > read records: state kill-init at end at > /usr/local/lib/site_perl/Debbugs/Log.pm line 320. I'm afraid that's all I have. 1017154 and 1017156 are fine. Regards, Stephen
Bug#1016091: RFS: tinymux/2.12.0.10-1 [RC] -- text-based multi-user virtual world server
Reproduce this by adding 'sleep 100' into the libmux.so: part of the Makefile. It reproduces in the initial submission. It does not reproduce in the second. So, I am confident it has been fixed. On Tue, Jul 26, 2022 at 8:03 PM Adam Borowski wrote: > On Tue, Jul 26, 2022 at 03:29:03PM -0600, Stephen Dennis wrote: > > * Package name: tinymux > >Version : 2.12.0.10-1 > > > tinymux (2.12.0.10-1) unstable; urgency=medium > > . > >* New upstream release > > + fixes ftbfs with GCC-12. (Closes: #1013053) > >* Update Standards-Version in debian/control from 4.0.1 to 4.6.1. > > + Removed build date and number for reproducible build. > >(Closes: #866945) > > Alas, it fails to build: > g++ -std=c++14 -g -O2 -ffile-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -g -O > -DSTUB_SLAVE -o stubslave stubslave.o -L. -lm -lcrypt -lmux > /usr/bin/ld: cannot find -lmux: No such file or directory > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, > ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the > ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious... >
