Bug#1071293: ddcci-dkms: Fails to build on linux-image-6.8.9-amd64

[Stephen Kitt]

Hi Ben,

On Fri, 17 May 2024 21:10:01 +0100, Ben Morris  wrote:
> Although upstream has not yet bumped the version number, I believe they have
> committed changes that fix this to their GitLab repo.

They’ve committed changes that allow the module to build, but it doesn’t work
— see the discussion in
https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux/-/merge_requests/15

Regards,

Stephen


pgpCBQOpbOrlA.pgp
Description: OpenPGP digital signature

Bug#1070791: solaar: Does not restore DPI after suspend

[Stephen Kitt]

Hi Bruno,

On Thu, 09 May 2024 11:02:11 +0200, Bruno Kleinert  wrote:
> when the computer wakes up from suspend the DPI setting of the mouse is not
> restored. This had worked in earlier versions of solaar.
> 
> I reproduce this with an MX Master 3S mouse, set to 2000 DPI via the solaar
> configuration window, and the GNOME desktop environment:
> 
> 1. Open solaar from the tray and set mouse to 2000 DPI
> 2. Put the computer into standby via GNOME's power menu
> 3. Wake up the computer
> 4. Moving the mouse cursor appears way slower than the previously configured
> 2000 DPI. My apologies, I didn't figure out how to read the actual DPI value
> from the mouse at this step.
> 
> To work around after wakeup, I open the solaar configuration, click into the
> DPI field, which displays still shows 2000 DPI, and just hit enter.

I think this is fixed upstream — would you mind applying
https://github.com/pwr-Solaar/Solaar/commit/6c11f4e4808063a9a454d4c034a7e40b8e56da5c
to /usr/share/solaar/lib/solaar/dbus.py to see if suspend is handled
correctly?

Regards,

Stephen


pgpJsK0_Qsdmq.pgp
Description: OpenPGP digital signature

Bug#1069480: bochs: FTBFS on armhf: build-dependency not installable: gcc-i686-linux-gnu

[Stephen Kitt]

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

[Stephen Kitt]

Package: ftp.debian.org
Severity: normal

Dear FTP team,

Please remove chipmunk from experimental.

Regards,

Stephen

Bug#1065924: ITP: lfanew -- tool to manipulate MZ stubs in NE/PE binaries

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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#985184: reminiscence not anymore licensed

[Stephen Kitt]

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#1054148: mingw-w64: please enable support for the mcf thread model

[Stephen Kitt]

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#1051753: dosbox-x: FTBFS on big-endian architectures

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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#1050056: libz-mingw-w64 build-depends on pev

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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#999977: qxw: depends on obsolete pcre3 library

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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#1031930: nmu: binutils-mingw-w64_10.3, gdb-mingw-w64_12

[Stephen Kitt]

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#1031387: supertuxkart: Fails to compile due to inescaped +, bug in shaderc

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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
):
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

[Stephen Kitt]

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

[Stephen Kitt]

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
? 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#1029093: solaar doesn't enable plugdev when plugdev requested

[Stephen Kitt]

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#1028050: ITP: pyqt6-charts -- Python 3 bindings for Qt6's Charts module

[Stephen Kitt]

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#1027668: mc: Copying with fish fails when the local temporary directory fills up

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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

[Stephen Kitt]

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?

[Stephen Kitt]

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?

[Stephen Kitt]

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

[Stephen Kitt]

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#1021349: RFA: wput -- tiny wget-like ftp-client for uploading files

[Stephen Kitt]

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

[Stephen Kitt]

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#1020738: RM: hubicfuse -- ROM; service is shutting down

[Stephen Kitt]

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

[Stephen Kitt]

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#1020218: vcmi: luajit got removed on ppc64el, please either drop vcmi on ppc64el or switch to lua

[Stephen Kitt]

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#1019139: ITP: zpaqfranz -- Swiss army knife for backup and disaster recovery

[Stephen Kitt]

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#967353: freeciv: depends on deprecated GTK 2

[Stephen Kitt]

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

[Stephen Kitt]

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#1018078: hdparm: new upstream release(s) available

[Stephen Kitt]

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

[Stephen Kitt]

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#1014392: mingw-w64: ftbfs on riscv64(error: #error Unknown CPU architecture!)

[Stephen Kitt]

On Sat, 16 Jul 2022 14:12:56 +0200, Stephen Kitt  wrote:

> On Wed, 06 Jul 2022 09:52:41 +0800, Paul Wise  wrote:
> > On Wed, 2022-07-06 at 09:27 +0800, Bo YU wrote:  
> > > To my surprise this definition doesn't seem to take effect,
> > > Either define or undef can build riscv64 package here.
> > 
> > Probably the code that uses the definition is not adequately tested
> > during the package build, if it was then there should be failure.  
> 
> That’s right.
> 
> widl is a targetted tool anyway; it shouldn’t actually care about the host
> CPU, the only thing that matters it the target CPU. I’ve been meaning to fix
> this for a while, I guess it’s time to do it...

Scratch that, it’s a little more complex; what matters in this particular
case is whether the endianness of the host CPU matches the endianness of the
target Windows ABI (which is always little-endian).

Regards,

Stephen


pgp1GYyzhUEOZ.pgp
Description: OpenPGP digital signature

Bug#1014392: mingw-w64: ftbfs on riscv64(error: #error Unknown CPU architecture!)

[Stephen Kitt]

On Wed, 06 Jul 2022 09:52:41 +0800, Paul Wise  wrote:
> On Wed, 2022-07-06 at 09:27 +0800, Bo YU wrote:
> > To my surprise this definition doesn't seem to take effect,
> > Either define or undef can build riscv64 package here.  
> 
> Probably the code that uses the definition is not adequately tested
> during the package build, if it was then there should be failure.

That’s right.

widl is a targetted tool anyway; it shouldn’t actually care about the host
CPU, the only thing that matters it the target CPU. I’ve been meaning to fix
this for a while, I guess it’s time to do it...

Regards,

Stephen


pgpCmlaMraYng.pgp
Description: OpenPGP digital signature

Bug#1010861: ready to salvage?

[Stephen Kitt]

Hi Matija,

On Tue, Jun 28, 2022 at 04:21:23PM +0200, Matija Nalis wrote:
> As there have now been more than the double of required 21 days
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> with no comment from maintainer, I propose that Stephen now continue with
> the salvaging process, if that is okay?

I’m working on merging your MR (which is a bit complicated since
there’s an upstream update which should go in its own branch).

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#1013268: chromium: Broken kerberos authentication

[Stephen Kitt]

Hi,

Le 20/06/2022 14:18, Santiago García Mantiñán a écrit :
starting with version 101.0.4951.41-1~deb11u1 I have found that 
kerberos

authentication is broken, I have tested that on version
100.0.4896.127-1~deb11u1 everything was working ok.

To reproduce it I get a working ticket with kinit myuser, I then run a 
klist

to make sure the ticket is ok and then I try to logon on places I have
authorized at /etc/chromium/policies/recommended/auth.json
{
"AuthServerWhitelist": "*.internal.domain"
}

The result is that up to version 100 or in firefox it just works, and
version 101 and later don't work.


You need to replace "Whitelist" with "Allowlist", the names were changed 
in Chromium 101.


Regards,

Stephen

Bug#1013122: gcc-10: internal compiler error: in move_insn

[Stephen Kitt]

Package: gcc-10
Version: 10.2.1-6
Severity: important
Tags: upstream, fixed-upstream

Dear Maintainer,

gcc-10 crashes when buiding dosemu2:

gcc -c -imacros config.hh -MD -DCFLAGS_STR=" -fplan9-extensions -Wall 
-Wstrict-prototypes -Wmissing-declarations -Wnested-externs -fms-extensions 
-pthread -Wno-unused-result -Wcast-qual -Wwrite-strings -Wstrict-aliasing=2 
-Wno-address-of-packed-member -ggdb3 -fpie   -g -O2 
-ffile-prefix-map=/home/steve/tmpdir/dosemu2=. -fstack-protector-strong 
-Wformat -Werror=format-security" -I../../../src/include 
-I../../../src/plugin/include -I../../../src/base/bios/x86 
-I/home/steve/tmpdir/dosemu2/build/../src/include 
-I/home/steve/tmpdir/dosemu2/build/../src/base/lib -Wdate-time 
-D_FORTIFY_SOURCE=2 -fplan9-extensions -Wall -Wstrict-prototypes 
-Wmissing-declarations -Wnested-externs -fms-extensions -pthread 
-Wno-unused-result -Wcast-qual -Wwrite-strings -Wstrict-aliasing=2 
-Wno-address-of-packed-member -ggdb3 -fpie   -g -O2 
-ffile-prefix-map=/home/steve/tmpdir/dosemu2=. -fstack-protector-strong 
-Wformat -Werror=format-security -o int.o 
/home/steve/tmpdir/dosemu2/build/../src/base/core/int.c
during RTL pass: sched2
.../dosemu2/build/../src/base/core/int.c: In function ‘int33_unrevect_fixup’:
.../dosemu2/build/../src/base/core/int.c:1748:1: internal compiler error: in 
move_insn, at haifa-sched.c:5471
 1748 | }
  | ^
0x7f14e033cd09 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


The bug as been reported upstream, and a fix has been backported to
the gcc-10 branch; see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105936 and
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=f2851a7cff4d74edca26d39c7bfa1264355a22ed

Would it be possible to update the gcc-10 package with this fix?
Ideally, in stable too...

Regards,

Stephen


-- System Information:
Debian Release: 11.3
  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-12-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 gcc-10 depends on:
ii  binutils   2.35.2-2
ii  cpp-10 10.2.1-6
ii  gcc-10-base10.2.1-6
ii  libc6  2.31-13+deb11u3
ii  libcc1-0   10.2.1-6
ii  libgcc-10-dev  10.2.1-6
ii  libgcc-s1  10.2.1-6
ii  libgmp10   2:6.2.1+dfsg-1+deb11u1
ii  libisl23   0.23-1
ii  libmpc31.2.0-1
ii  libmpfr6   4.1.0-3
ii  libstdc++6 10.2.1-6
ii  libzstd1   1.4.8+dfsg-2.1
ii  zlib1g 1:1.2.11.dfsg-2+deb11u1

Versions of packages gcc-10 recommends:
ii  libc6-dev  2.31-13+deb11u3

Versions of packages gcc-10 suggests:
pn  gcc-10-doc   
pn  gcc-10-locales   
ii  gcc-10-multilib  10.2.1-6

-- no debconf information

Bug#969390: ddcci-dkms: ddcci detection fails with "invalid identification response"

[Stephen Kitt]

On Sat, 5 Sep 2020 14:31:55 +0200, Stephen Kitt  wrote:
> Hi quintus,
> On Fri, 04 Sep 2020 12:54:20 +0200, Marvin ‘quintus’ Gülker
>  wrote:
> > By chance I have come today over these two pieces of information:
> > 
> > * https://www.ddcutil.com/faq/
> > * which links to:
> > https://lists.freedesktop.org/archives/intel-gfx/2017-May/127426.html
> > 
> > I don't use ddcutil, but I do have the i915 kernel module, which appears
> > to be at fault.  
> 
> I think there might be a regression in the kernel too; the module used to
> work for me (via DP, but not a dock), but it doesn’t with the current kernel
> — the i2c layer always gives me an I/O error.
> 
> I’ll investigate but it might take me a little while...

The driver works fine for me now on the current 5.10 kernel in Debian 11; do
you still have this issue?

Regards,

Stephen


pgpl9VWTPrh8X.pgp
Description: OpenPGP digital signature

Bug#1010861: ITS: uqm, uqm-content

[Stephen Kitt]

Package: uqm
Severity: important
X-Debbugs-Cc: Dmitry E. Oboukhov , Matija Nalis 


Dear Maintainer,

uqm has been updated through NMUs (seven) since 2015, and hasn’t seen
a maintainer upload since 2009. It has had a couple of upstream
releases since then, with a bug open since 2011 requesting an update
(#640881).

Accordingly, I intend to help Matija Nalis salvage this package along
with related packages (at least uqm-content), within the Debian Games
team (which is where the package VCSs are already hosted). Merge
requests updating the package are already available on
https://salsa.debian.org/games-team/uqm-content/-/merge_requests and
https://salsa.debian.org/games-team/uqm/-/merge_requests

The packages would then list the Games team as their maintainer, with
yourself (if you wish), Matija and me as uploaders.

Regards,

Stephen

Bug#1008780: dpkg: protection shouldn't apply to foreign-arch packages

[Stephen Kitt]

Hi Guillem,

On Sat, 2 Apr 2022 15:09:26 +0200, Guillem Jover  wrote:
> On Fri, 2022-04-01 at 14:41:51 +0200, Stephen Kitt wrote:
> > Package: dpkg
> > Version: 1.20.9
> > Severity: normal  
> 
> > Protection is applied to foreign-arch packages (e.g. libgcc-s1:i386 on
> > amd64) even though they aren't relevant to the scenarios that
> > protection is designed to prevent (as I understand it):  
> 
> Right, AFAIR this was a workaround used to try to help apt with an
> upgrade scenario where otherwise it was unable to cope well with the
> libgcc1 to libgcc-s1 transition.

Ah right, that’s good to know, thanks! It seems libcrypt1 is protected for
upgrade reasons too.

> > > Protected packages contain mostly important system boot
> > > infrastructure. Removing them might cause the whole system to be
> > > unable to boot, so use with caution.  
> > 
> > Would it be possible for removal of such packages not to require
> > --force-remove-protected, at least if the corresponding native arch
> > package is installed? The latter check isn't useful with libraries
> > (where, if nothing depends on them, we can be certain that they are
> > not needed for the system to boot), but would catch situations where
> > e.g. the system's init is not the native package. (I imagine there's a
> > better approach to this.)  
> 
> In principle shared libraries should never be marked Essential:yes nor
> Protected:yes, I think this was a special case, that will go away once
> the shared library gets the Protected filed dropped after the
> transition is over.
> 
> I think at least the description for the field in dpkg(1), deb-control(5)
> and probably «/usr/share/doc/dpkg/protected-field.txt» should be made more
> clear. I'll try to prepare a patch for this today.

Excellent!

> And while I think in this specific case that you mention, the heuristic
> that you propose might make sense. I'm not sure that is generalizable
> or can be encoded in a neutral way in dpkg itself. As I don't think it
> would be appropriate for dpkg to assume that all Mulit-Arch:same packages
> are going to be shared libraries, or say encode specific package name
> patterns or even assumed semantics out of section names.

Right, I didn’t have the latter in mind; I was hoping that a heuristic like
“when removing foo:foreign, if foo:native is installed then ignore the
protected field” would work, without considering foo’s section etc.

Regards,

Stephen


pgpiVXL4Q496Q.pgp
Description: OpenPGP digital signature

Bug#1008780: dpkg: protection shouldn't apply to foreign-arch packages

[Stephen Kitt]

Package: dpkg
Version: 1.20.9
Severity: normal

Dear Maintainer,

Protection is applied to foreign-arch packages (e.g. libgcc-s1:i386 on
amd64) even though they aren't relevant to the scenarios that
protection is designed to prevent (as I understand it):

> Protected packages contain mostly important system boot
> infrastructure. Removing them might cause the whole system to be
> unable to boot, so use with caution.

Would it be possible for removal of such packages not to require
--force-remove-protected, at least if the corresponding native arch
package is installed? The latter check isn't useful with libraries
(where, if nothing depends on them, we can be certain that they are
not needed for the system to boot), but would catch situations where
e.g. the system's init is not the native package. (I imagine there's a
better approach to this.)

Regards,

Stephen


-- Package-specific info:

-- System Information:
Debian Release: 11.3
  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-12-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 dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13+deb11u3
ii  liblzma5 5.2.5-2
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.4
ii  debsig-verify  0.23+b2

-- no debconf information

Bug#1008097: libmodplug: Upstream has moved to https://github.com/Konstanty/libmodplug

[Stephen Kitt]

Source: libmodplug
Severity: normal

Dear Maintainer,

Upstream has moved to https://github.com/Konstanty/libmodplug. There
aren't any new releases yet, although 0.8.9.1 is seemingly in
preparation:
https://github.com/Konstanty/libmodplug/commit/d04fbc2eb2dddc9dd05fbcc29ab062f83a7a2a48

Regards,

The Maintainer


-- System Information:
Debian Release: 11.2
  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-12-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

Bug#993451: osslsigncode distribution does not have production-quality tests (yet)

[Stephen Kitt]

Hi Mike,

Le 09/03/2022 13:41, Michał Trojnara a écrit :
Didn't you notice that these tests are *not* part of the osslsigncode 
release tarball?  Just because some random code can be found is in the 
same GitHub repository doesn't meany it's suitable for production use.


Apologies, I did not notice this. Unfortunately the previous 
version-tracking setup downloaded the tag-based tarballs provided by 
GitHub rather than the separate release tarballs you prepared. I’ve 
fixed that, so going forward the release tarballs will be used (and 
their signature verified).


There is a very good reason why "make check" doesn't work in 
osslsigncode.  It will work when the tests are ready for production 
use.  Hopefully soon.  We're working on this.


Noted, thanks!

Regards,

Stephen

Bug#1006885: ITP: lumin -- pattern match highlighter

[Stephen Kitt]

Hi Jonas,

On Mon, 07 Mar 2022 18:01:47 +0100, Jonas Smedegaard  wrote:
> Quoting Stephen Kitt (2022-03-07 17:50:43)
> > Package: wnpp
> > Severity: wishlist
> > Owner: Stephen Kitt 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> > 
> > * Package name: lumin
> >   Version : 1.0.0
> >   Upstream Author : John Kerl
> > * URL : https://github.com/johnkerl/lumin
> > * License : BSD-2-clause
> >   Programming Lang: Go
> >   Description : pattern match highlighter
> > 
> > lumin highlights matches to a specified pattern (string or regular
> > expression) in files, using color. This is similar to grep with
> > colorized output, but it outputs all lines in the given files, not
> > only matching lines.  
> 
> Is this a command-line tool or only a Go library?
> 
> If the latter, then please use a source package name starting with 
> "golang-" to not needlessly occupy a short global name.

It’s both, a command-line tool and a Go library.

Regards,

Stephen


pgpFLWvDeFiqw.pgp
Description: OpenPGP digital signature

Bug#1006886: ITP: gocc -- Go lexer and parser generator

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: gocc
  Version : 0.0~git20211213.7ea6993
  Upstream Author : Marius Ackerman 
* URL : https://github.com/goccmack/gocc
* License : ASL-2.0
  Programming Lang: Go
  Description : Go lexer and parser generator

Gocc generates lexer-parser pairs or stand-alone DFAs or parsers from
a Backus-Naur form (BNF). The generated lexers are deterministic
finite automata (DFAs), recognising regular languages. The generated
parsers are pushdown automata (PDAs), recognising LR(1) languages.
Optional LR(1) conflict handling automatically resolves shift/reduce
and reduce/reduce conflicts.



This is a new dependency of Miller 6.1.0.

Bug#1006885: ITP: lumin -- pattern match highlighter

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: lumin
  Version : 1.0.0
  Upstream Author : John Kerl
* URL : https://github.com/johnkerl/lumin
* License : BSD-2-clause
  Programming Lang: Go
  Description : pattern match highlighter

lumin highlights matches to a specified pattern (string or regular
expression) in files, using color. This is similar to grep with
colorized output, but it outputs all lines in the given files, not
only matching lines.



This is a new dependency of Miller 6.1.0.

Bug#1006725: Missing libgcc_s_dw2-1.dll in programs using zlib1.dll

[Stephen Kitt]

Control: reassign -1 libz-mingw-w64
Control: affects -1 wine

Hi Miguel,

On Thu, 3 Mar 2022 16:14:30 +0100, "Miguel A. Vallejo" 
wrote:
> Since Wine 6.0.2~repack-3 arrived Debian Unstable some Win32 programs
> have stopped working because of a missing libgcc_s_dw2-1.dll file. For
> example:

This isn’t a bug in Wine, but in libz-mingw-w64 which provides zlib1.dll;
previously the DLL didn’t have any dependency on GCC libraries, but the
current version does.

I’m reassigning accordingly.

Regards,

Stephen


pgpKrs4PcHO00.pgp
Description: OpenPGP digital signature

Bug#1005326: no-code-sections triggered on non-ELF files

[Stephen Kitt]

On Fri, 11 Feb 2022 12:51:06 -0800 Felix Lechner 
wrote:
> On Fri, Feb 11, 2022 at 12:09 PM Marc Dequènes  wrote:
> >
> > Could you consider improving the check?
> 
> Yes, I'd like to.
> 
> > readelf fails with "readelf: Error: Not an ELF file - it has the wrong
> > magic bytes at the start"
> 
> I confirmed that Lintian's invocation produces that error for
> usr/lib/dxvk/wine64-development/d3d10.dll.a in dxvk, but how can we
> tell such archives apart from those that are legitimately broken?

They contain valid object files, just not in ELF format. file matches them
correctly. Would a signature check be good enough?

Regards,

Stephen


pgpJQeThF6WGD.pgp
Description: OpenPGP digital signature

Bug#1006483: ITP: python3-mergedeep -- A deep merge function for Python

[Stephen Kitt]

Hi,

On Sat, 26 Feb 2022 08:12:27 +, Edward Betts  wrote:
> * Package name: python3-mergedeep
>   Version : 1.3.4
>   Upstream Author : Travis Clarke
> * URL : https://github.com/clarketm/mergedeep
> * License : MIT
>   Programming Lang: Python
>   Description : A deep merge function for Python

This appears to be the same upstream as Carsten Schoenert’s ITP, 1006479
(filed just an hour before yours!).

Regards,

Stephen


pgpRxerDrkXJT.pgp
Description: OpenPGP digital signature

Bug#1005994: RM: key-mapper -- ROM; replaced by input-remapper

[Stephen Kitt]

Package: ftp.debian.org
Severity: normal

Dear FTP team,

Please remove the key-mapper source package; it’s been replaced by
input-remapper.

Regards,

Stephen

Bug#1003708: Fw: Bug#1003708: units: Segmentation fault on certain conversions in verbose mode

[Stephen Kitt]

Control: tag -1 forwarded

Hi Adrian,

I had a quick look into this, it seems related to the fact that brwiregauge,
plategauge etc. are units with discrete values, and the user is asking for
the inverse; but I’m not sure what the best way to fix this is.
fun->inverse.param ends up with nonsensical values:

(gdb) run
Starting program: /home/steve/Debian/units/units -v
Currency exchange rates from FloatRates (USD base) on 2020-11-15 
3679 units, 109 prefixes, 114 nonlinear units

You have: cm
You want: brwiregauge

Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65  ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x77c8cf76 in __vfprintf_internal (s=0x77de06a0 
<_IO_2_1_stdout_>, 
format=format@entry=0x55568f6d "\t%s = %s(", 
ap=ap@entry=0x7fffd540, mode_flags=mode_flags@entry=2)
at vfprintf-internal.c:1688
#2  0x77d2ce88 in ___vfprintf_chk (fp=, 
flag=flag@entry=1, format=format@entry=0x55568f6d "\t%s = %s(", 
ap=ap@entry=0x7fffd540) at vfprintf_chk.c:29
#3  0x84a5 in vprintf (__ap=0x7fffd540, __fmt=0x55568f6d 
"\t%s = %s(")
at /usr/include/x86_64-linux-gnu/bits/stdio2.h:120
#4  logprintf (format=format@entry=0x55568f6d "\t%s = %s(") at units.c:415
#5  0xe605 in showfunc (havestr=0x555dd900 "cm", 
have=have@entry=0x555703a0 , fun=0x556005c0)
at units.c:2976
#6  0x7e25 in main (argc=, argv=) at 
units.c:6267
(gdb) up
#1  0x77c8cf76 in __vfprintf_internal (s=0x77de06a0 
<_IO_2_1_stdout_>, 
format=format@entry=0x55568f6d "\t%s = %s(", 
ap=ap@entry=0x7fffd540, mode_flags=mode_flags@entry=2)
at vfprintf-internal.c:1688
1688vfprintf-internal.c: No such file or directory.
(gdb) up
#2  0x77d2ce88 in ___vfprintf_chk (fp=, 
flag=flag@entry=1, format=format@entry=0x55568f6d "\t%s = %s(", 
ap=ap@entry=0x7fffd540) at vfprintf_chk.c:29
29  vfprintf_chk.c: No such file or directory.
(gdb) up
#3  0x84a5 in vprintf (__ap=0x7fffd540, __fmt=0x55568f6d 
"\t%s = %s(")
at /usr/include/x86_64-linux-gnu/bits/stdio2.h:120
120   return __vfprintf_chk (stdout, __USE_FORTIFY_LEVEL - 1, __fmt, __ap);
(gdb) up
#4  logprintf (format=format@entry=0x55568f6d "\t%s = %s(") at units.c:415
415   vprintf(format, args);
(gdb) up
#5  0xe605 in showfunc (havestr=0x555dd900 "cm", 
have=have@entry=0x555703a0 , fun=0x556005c0)
at units.c:2976
2976 logprintf("\t%s = %s(", havestr, fun->inverse.param);
(gdb) print *fun
$1 = {name = 0x556005a0 "brwiregauge", forward = {param = 0x690077 
, 
def = 0x650072 , 
dimen = 0x610067 , 
domain_min = 0x670075, 
domain_max = 0x5b0065, domain_min_open = 105, domain_max_open = 110}, 
inverse = {
param = 0x20005d , 
def = 0x200020 , 
dimen = 0x200020 , 
domain_min = 0x200020, 
domain_max = 0x200020, domain_min_open = 45, domain_max_open = 54}, 
table = 0x555bc500, tablelen = 16, 
  tableunit = 0x55600660 "in", next = 0x555d44f0, skip_error_check = 0, 
linenumber = 5857, 
  file = 0x55589a40 "/usr/share/units/definitions.units"}


Regards,

Stephen


Begin forwarded message:

Date: Thu, 13 Jan 2022 19:20:31 -0600
From: "Owen T. Heisler" 
To: Debian Bug Tracking System 
Subject: Bug#1003708: units: Segmentation fault on certain conversions in
verbose mode


Package: units
Version: 2.21-1
Severity: normal
X-Debbugs-Cc: wri...@owenh.net

Hi, the following commands result in a segmentation fault:

$ echo -e "cm\nbrwiregauge" | units -v
$ echo -e "cm\nplategauge" | units -v

This was discovered while attempting to use the script example in the
"SCRIPTING WITH UNITS" section of the units(1) man page.

Thank you for maintaining this useful tool.

Owen T. Heisler

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable'), (1, 'testing') Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages units depends on:
ii  libc6 2.31-13+deb11u2
ii  libreadline8  8.1-1

Versions of packages units recommends:
ii  python3   3.9.2-3
ii  python3-requests  2.25.1+dfsg-2

units suggests no packages.

-- debconf-show failed


pgpFbs11_850W.pgp
Description: OpenPGP digital signature

Bug#1002859: ITP: golang-github-lestrrat-go-envload -- environment variable manipulation library

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: golang-github-lestrrat-go-envload
  Version : 0.0~20180221
  Upstream Author : Daisuke Maki 
* URL : https://github.com/lestrrat-go/envload
* License : MIT
  Programming Lang: Go
  Description : environment variable manipulation library

This library provides functions to store, modify, and restore
environment variables. This is useful for example to temporarily
change values of environment variables for tests, as doable for
example with Perl 5’s local variables.


This is required for lestrrat-go-strftime. I’m planning on maintaining
this within the Go packaging team.

Bug#1002858: ITP: golang-github-lestrrat-go-strftime -- fast strftime implementation for Go

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: golang-github-lestrrat-go-strftime
  Version : 1.0.5
  Upstream Author : Daisuke Maki 
* URL : https://github.com/lestrrat-go/strftime
* License : MIT
  Programming Lang: Go
  Description : fast strftime implementation for Go

This is a Go implementation of strftime, optimised for pattern re-use,
and with support for as many conversion specifications as possible. It
aims for POSIX compliance while still including widely-used non-POSIX
format specifications such as "%f" or "%L" for milliseconds.


This is required for the new Go version of Miller. I’ll be asking to
join the Go packaging team to maintain this there.

Bug#727021: Bug#965846: ufiformat: diff for NMU version 0.9.9-1.1

[Stephen Kitt]

You’re very welcome! I hope the changes aren’t too invasive; since short 
dh “just worked”, including cross-compilation, I went with that.


Regards,

Stephen


Le 20/12/2021 17:44, David Given a écrit :

Thank you for fixing these; I completely missed both of these bugs when 
they got filed.


On Mon, 20 Dec 2021 at 15:33, Stephen Kitt  wrote:


Package: ufiformat
Version: 0.9.9-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for ufiformat (versioned as 0.9.9-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,

Stephen

Bug#727021: ufiformat: diff for NMU version 0.9.9-1.1

[Stephen Kitt]

Package: ufiformat
Version: 0.9.9-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for ufiformat (versioned as 0.9.9-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,

Stephen
diff -u ufiformat-0.9.9/debian/changelog ufiformat-0.9.9/debian/changelog
--- ufiformat-0.9.9/debian/changelog
+++ ufiformat-0.9.9/debian/changelog
@@ -1,3 +1,14 @@
+ufiformat (0.9.9-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to debhelper compatibility level 13 and short dh rules.
+Closes: #965846, #727021.
+  * Switch to libext2fs-dev.
+  * Watch https://github.com/tedigh/ufiformat instead of the dead
+GeoCities page.
+
+ -- Stephen Kitt   Mon, 20 Dec 2021 15:23:36 +0100
+
 ufiformat (0.9.9-1) unstable; urgency=low
 
   * New upstream release
reverted:
--- ufiformat-0.9.9/debian/compat
+++ ufiformat-0.9.9.orig/debian/compat
@@ -1 +0,0 @@
-5
diff -u ufiformat-0.9.9/debian/control ufiformat-0.9.9/debian/control
--- ufiformat-0.9.9/debian/control
+++ ufiformat-0.9.9/debian/control
@@ -2,8 +2,8 @@
 Section: utils
 Priority: optional
 Maintainer: David Given 
-Build-Depends: debhelper (>= 5), autotools-dev, automake, e2fslibs-dev
-Homepage: http://www.geocities.jp/tedi_world/format_usbfdd_e.html
+Build-Depends: debhelper-compat (= 13), libext2fs-dev
+Homepage: https://github.com/tedigh/ufiformat
 Standards-Version: 3.9.4
 
 Package: ufiformat
reverted:
--- ufiformat-0.9.9/debian/dirs
+++ ufiformat-0.9.9.orig/debian/dirs
@@ -1 +0,0 @@
-usr/bin
diff -u ufiformat-0.9.9/debian/rules ufiformat-0.9.9/debian/rules
--- ufiformat-0.9.9/debian/rules
+++ ufiformat-0.9.9/debian/rules
@@ -1,79 +1,7 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
-# debian/rules file for ufiformat.
-# This file was originally written by Joey Hess and Craig Small.
-# As a special exception, when this file is copied by dh-make into a
-# dh-make output file, you may use that output file without restriction.
-# This special exception was added by Craig Small in version 0.37 of dh-make.
 
-# Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
-
-# These are used for cross-compiling and for saving the configure script
-# from having to guess our platform (since we know it already)
-DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
-export CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
-export CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
-export CXXFLAGS = $(shell dpkg-buildflags --get CXXFLAGS)
-export LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)
-
-configure:
-	dh_testdir
-	autoreconf -i
-	
-config.status: configure
-	dh_testdir
-	./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
-
-
-build: build-arch build-indep
-build-arch: build-stamp
-build-indep: build-stamp
-
-build-stamp:  config.status
-	dh_testdir
-	$(MAKE)
-	touch $@
-
-clean:
-	dh_testdir
-	dh_testroot
-	
-	rm -f build-stamp
-	[ ! -f Makefile ] || $(MAKE) distclean
-	rm -f aclocal.m4 Makefile.in
-	rm -f config.sub config.guess config.status config.status.lineno
-	rm -f config.log configure config.h.in
-
-	dh_clean 
-
-install: build
-	dh_testdir
-	dh_testroot
-	dh_clean -k 
-	dh_installdirs
-	$(MAKE) DESTDIR=$(CURDIR)/debian/ufiformat install
-
-binary-indep: build install
-	# none
-
-binary-arch: build install
-	dh_testdir
-	dh_testroot
-	dh_installchangelogs ChangeLog
-	dh_installdocs
-	dh_installman ufiformat.man
-	dh_strip
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_shlibdeps
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
-
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install 
+%:
+	dh $@
diff -u ufiformat-0.9.9/debian/watch ufiformat-0.9.9/debian/watch
--- ufiformat-0.9.9/debian/watch
+++ ufiformat-0.9.9/debian/watch
@@ -1,6 +1,4 @@
-# Check upstream for a new version
-
-# Compulsory line, this is a version 3 file
-version=3
-
-http://www.geocities.jp/tedi_world/format_usbfdd_e.html  ufiformat-(.*)\.tar\.gz
+version=4
+opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%" \
+https://github.com/tedigh/ufiformat/releases \
+(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate


signature.asc
Description: PGP signature

Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]

[Stephen Kitt]

Hi Jeff,

On Tue, 14 Dec 2021 09:13:42 +, Jeff Blake  wrote:
[...]
> Inspector and convertutf are the worst offenders in terms of being
> unnecessary and complex. The disable/catapult.patch could also be dropped,
> since profiling might be desirable to some users.

convertutf at least is required for licensing reasons — it replaces code
which is stripped from the upstream tarball because it’s not DFSG-free. See
https://lintian.debian.org/tags/license-problem-convert-utf-code for details.

Regards,

Stephen


pgpQAy5HovuN7.pgp
Description: OpenPGP digital signature

Bug#999022: binstats: diff for NMU version 1.08-9.1

[Stephen Kitt]

Control: tags 999022 + patch
Control: tags 999022 + pending

Dear maintainer,

I've prepared an NMU for binstats (versioned as 1.08-9.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer; you can of course also replace this with your
own upload.

Regards,

Stephen
diff -u binstats-1.08/debian/changelog binstats-1.08/debian/changelog
--- binstats-1.08/debian/changelog
+++ binstats-1.08/debian/changelog
@@ -1,3 +1,10 @@
+binstats (1.08-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to short dh rules. Closes: #999022.
+
+ -- Stephen Kitt   Tue, 14 Dec 2021 08:56:38 +0100
+
 binstats (1.08-9) unstable; urgency=low
 
   * Acknowledge NMU
diff -u binstats-1.08/debian/rules binstats-1.08/debian/rules
--- binstats-1.08/debian/rules
+++ binstats-1.08/debian/rules
@@ -1,53 +1,10 @@
 #! /usr/bin/make -f
 
-export CFLAGS="-O2 -g -Wall"
-export LDFLAGS=""
+%:
+	dh $@
 
-clean:
-	dh_testdir
-	dh_testroot
-	dh_clean
-	make clean
+# We only ship the shell script, there's nothing to build
+override_dh_auto_build:
 
-build:
-	make 
-
-binary:  binary-indep
-
-binary-indep: 
-	dh_testdir 
-	dh_testroot
-	dh_clean 
-	dh_installdirs  usr/bin 
-	cp -p binstats debian/binstats/usr/bin
-	dh_installdocs README
-	dh_installman binstats.1
-	dh_installchangelogs
-	dh_strip
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
-
-binary-arch: build
-	dh_testdir 
-	dh_testroot
-	dh_clean 
-	dh_installdirs  usr/bin usr/share/man/man1
-	make install DESTBIN=`pwd`/debian/binstats/usr/bin \
-	   	 DESTMAN=`pwd`/debian/binstats/usr/share/man/man1
-	cp -p binstats debian/binstats/usr/bin
-	dh_installdocs README
-	dh_installman binstats.1
-	dh_installchangelogs
-	dh_strip
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
-
-.PHONY: clean build binary binary-arch binary-indep
+# Everything is installed through debhelper
+override_dh_auto_install:
reverted:
--- binstats-1.08/debian/rules.tiny
+++ binstats-1.08.orig/debian/rules.tiny
@@ -1,3 +0,0 @@
-#!/usr/bin/make -f
-%:
-	dh $@
only in patch2:
unchanged:
--- binstats-1.08.orig/debian/docs
+++ binstats-1.08/debian/docs
@@ -0,0 +1 @@
+README
only in patch2:
unchanged:
--- binstats-1.08.orig/debian/install
+++ binstats-1.08/debian/install
@@ -0,0 +1 @@
+binstats /usr/bin
only in patch2:
unchanged:
--- binstats-1.08.orig/debian/manpages
+++ binstats-1.08/debian/manpages
@@ -0,0 +1 @@
+binstats.1


signature.asc
Description: PGP signature

Bug#950271: netperfmeter: can't start netperfmeter (passive) without DCCP

[Stephen Kitt]

Hi Thomas,

On Tue, 9 Nov 2021 17:03:51 +0100, Thomas Dreibholz
 wrote:
> I just uploaded a buster-backports package with the fix for review on
> the mentors server: https://mentors.debian.net/package/netperfmeter/ .

Thanks for preparing this, however there are a few issues.

Backports are supposed to be no-change uploads of the original package, other
than the backports changelog entry and in some cases a maintainer change in
the control file (so that bug reports go to the backporter). I see a number
of changes here which aren’t appropriate for a backport, in particular
changes to the upstream source; a backport should use the exact same .orig
archive as the upload being backported.

Here is the recipe for a buster backport, starting from scratch:

apt source netperfmeter/stable
cd netperfmeter-1.8.6~rc2

(You might want to use a branch in your repo instead, in which case you
should start from the commit which served as the 1.8.6~rc2-1 upload.)

dch --bpo

The latter will open an editor with the changelog set for a bullseye
backport; you’ll have to change the top line so that it reads

netperfmeter (1.8.6~rc2-1~bpo10+1) buster-backports; urgency=medium

Note that it’s the package version which changes, not the upstream version,
and the backport version is bpo10+1 (first backport to Debian 10).

Those are all the changes that should be necessary in this instance.

Regards,

Stephen


pgp1CdktKuhDa.pgp
Description: OpenPGP digital signature

Bug#998513: rott: Fails at startup when doing XFree86-VidModeExtension/XF86VidModeGetAllModeLines X request

[Stephen Kitt]

Le 08/11/2021 11:29, Fabian Greffrath a écrit :

Am 08.11.2021 09:59, schrieb Konstantin Khomoutov:
Oh, indeed: I have rebooted the laptop to apply the latest Bullseye 
updates,

and the issue has gone away; sorry for the noise.
I'm going to close this bug.


Alright, thank you. Anyway, we should keep in mind to upgrade this
game to use SDL2 sooner or later...


Or make it use sdl12-compat ;-)

Regards,

Stephen

Bug#950271: netperfmeter: can't start netperfmeter (passive) without DCCP

[Stephen Kitt]

Hi Thomas,

On Sun, 7 Nov 2021 19:50:34 +0100, Thomas Dreibholz
 wrote:
> I created an updated package for "unstable" on the mentors server:
> https://mentors.debian.net/package/netperfmeter/ .
> 
> How is the procedure for submitting a backport package for buster? The
> backport is probably quite easy to create, I assume it will just need an
> older version of debhelper. That is, specifying the version in
> debian/control and recreating the debian/compat file is probably sufficient?

You won’t be able to upload the new version to buster-backports; the only
version that could go there is a backport of 1.8.6~rc2-1 (the version
currently in bullseye). 1.9.2-1 could only be backported to
buster-backports-sloppy, but that shouldn’t be necessary – 1.8.6~rc2-1 should
be good enough for buster.

You shouldn’t need any change for that version. Debhelper compatibility level
13 is available in buster-backports too (although that’s not a concern  for
1.8.6~rc2-1). BTW debhelper compatibility levels should be specified using
debhelper-compat now, not debian/compat; see "man debhelper" for details.

See https://backports.debian.org/Contribute/ for detailed backporting
instructions, including how to prepare the changelog.

As mentioned previously, if you need further help don’t hesitate to ask! I
can also check your package for unstable if you don’t already have a mentor.

Regards,

Stephen


pgpJ73bh9QIcc.pgp
Description: OpenPGP digital signature

Bug#998195: libsdl2-gfx-dev: Please ship SDL2_gfxPrimitives_font.h

[Stephen Kitt]

Package: libsdl2-gfx-dev
Version: 1.0.4+dfsg-3.1
Severity: wishlist

Dear Maintainer,

Upstream’s Makefile.am doesn’t specify that SDL2_gfxPrimitives_font.h,
but there are other projects which rely on it; it would be great if it
could be installed alongside the other header files in the packge.

Regards,

Stephen


-- System Information:
Debian Release: 11.1
  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-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
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 libsdl2-gfx-dev:amd64 depends on:
ii  libsdl2-dev2.0.14+dfsg2-3
ii  libsdl2-gfx-1.0-0  1.0.4+dfsg-3.1

libsdl2-gfx-dev:amd64 recommends no packages.

Versions of packages libsdl2-gfx-dev:amd64 suggests:
pn  libsdl2-gfx-doc  

-- no debconf information

Bug#932969: gprbuild: i686-w64-mingw32 compiler not found by gprconfig

[Stephen Kitt]

Control: reassign -1 gcc-mingw-w64

Hi,

On Sat, 16 Oct 2021 19:13:45 +0200, Nicolas Boulenguez 
wrote:
> The easyest solution would be for gnat-mingw-w64-i686 to install a
> symbolic link like the gnat-$arch for official architectures.
> 
> Stephen, is it possible to add a line like
>   usr/bin/gnat-mingw-w64-i686-gnatgccusr/bin/gnat-mingw-w64-i686-gcc
> to
>   debian/gnat-mingw-w64-i686.links ?

Yes, I can take care of that! I’m reassigning the bug to gcc-mingw-w64.

Regards,

Stephen


pgpSK8Lty2QTK.pgp
Description: OpenPGP digital signature

Bug#974186: /usr/bin/gnome-software: gnome-software uses way too much memory

[Stephen Kitt]

On Wed, Nov 11, 2020 at 04:12:30PM +1100, Timothy Allen wrote:
> I have a low-end laptop with 2GB of RAM, and I usually run GNOME 3 because 
> it's
> highly polished and light-weight enough that I can still run a browser and a
> few terminals to get work done. The one exception is gnome-software, which
> frequently claims 15% or more of my RAM whenever it checks for updates. Right
> now, it's sitting at ~18%, or 335MB resident — that may not be much on other
> computers, but for my little laptop it's often enough to get my browser OOM-
> killed while I'm in the middle of something.

This might be related to
https://sourceware.org/bugzilla/show_bug.cgi?id=14827 — connecting gdb
to an offending gnome-software process and calling malloc_trim(0)
releases a lot of memory; I went from

steve2801906  0.1  3.4 2924988 1136840 ? Sl   Oct02   6:32 
/usr/bin/gnome-software --gapplication-service

to

steve2801906  0.1  0.6 2908452 219416 ?  Sl   Oct02   6:32 
/usr/bin/gnome-software --gapplication-service

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#994700: python3-glad: please update to 0.1.34

[Stephen Kitt]

Package: python3-glad
Version: 0.1.30-1.1
Severity: wishlist

Dear Maintainer,

The generator has had several releases since 0.1.30, please consider
updating it.

Thanks,

Stephen


-- System Information:
Debian Release: 11.0
  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-8-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 python3-glad depends on:
ii  python3  3.9.2-3

python3-glad recommends no packages.

python3-glad suggests no packages.

-- no debconf information

Bug#994619: xpra: recommends gir1.2-appindicator3-0.1 which is no longer available

[Stephen Kitt]

Package: xpra
Version: 3.0.13+dfsg1-1
Severity: normal

Dear Maintainer,

xpra recommends gir1.2-appindicator3-0.1 but the latter is no longer available.

Regards,

Stephen


-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (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-8-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 xpra depends on:
ii  adduser   3.118
ii  gir1.2-gtk-3.03.24.24-4
ii  init-system-helpers   1.60
ii  libavcodec58  7:4.3.2-0+deb11u2
ii  libavformat58 7:4.3.2-0+deb11u2
ii  libavutil56   7:4.3.2-0+deb11u2
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4
ii  libpam0g  1.4.0-9
ii  libswscale5   7:4.3.2-0+deb11u2
ii  libsystemd0   247.3-6
ii  libturbojpeg0 1:2.0.6-4
ii  libvpx6   1.9.0-1
ii  libwebp6  0.6.1-2.1
ii  libx11-6  2:1.7.2-1
ii  libx264-160   2:0.160.3011+gitcde9a93-2.1
ii  libx265-192   3.4-2
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1.1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.10-1
ii  libxkbfile1   1:1.1.0-1
ii  libxrandr22:1.5.1-1
ii  libxtst6  2:1.2.3-1
ii  python3   3.9.2-3
ii  python3-cairo 1.16.2-4+b2
ii  python3-gi3.38.0-2
ii  python3-rencode   1.0.6-1+b3
ii  x11-xserver-utils 7.7+8
ii  xserver-xorg-video-dummy  1:0.3.8-1+b1
ii  xvfb  2:1.20.11-1

Versions of packages xpra recommends:
pn  gir1.2-appindicator3-0.1  
ii  keyboard-configuration1.205
ii  openssh-client1:8.4p1-5
ii  python3-brotli1.0.9-2+b2
ii  python3-cpuinfo   5.0.0-2
ii  python3-dbus  1.2.16-5
ii  python3-dns   3.2.1-1
ii  python3-gssapi1.6.1-1+b3
ii  python3-kerberos  1.1.14-3.1+b3
ii  python3-lz4   3.1.3+dfsg-1
ii  python3-lzo   1.12-3+b4
ii  python3-numpy 1:1.19.5-1
ii  python3-opengl3.1.5+dfsg-1
ii  python3-paramiko  2.7.2-1
ii  python3-pil   8.1.2+dfsg-0.3
ii  python3-setproctitle  1.2.1-1+b1
ii  python3-uritools  3.0.0-2
ii  python3-xdg   0.27-2
ii  python3-zeroconf  0.26.1-1
ii  ssh-askpass   1:1.2.4.1-10+b1

Versions of packages xpra suggests:
ii  cups-client2.3.3op2-3+deb11u1
ii  cups-common2.3.3op2-3+deb11u1
ii  cups-filters   1.28.7-1
pn  cups-pdf   
ii  gstreamer1.0-plugins-bad   1.18.4-3
ii  gstreamer1.0-plugins-base  1.18.4-2
ii  gstreamer1.0-plugins-good  1.18.4-2
ii  gstreamer1.0-plugins-ugly  1.18.4-2
ii  openssh-server 1:8.4p1-5
ii  pulseaudio 14.2-2
ii  pulseaudio-utils   14.2-2
pn  python3-avahi  
ii  python3-cryptography   3.3.2-1
ii  python3-cups   2.0.1-4+b1
ii  python3-gst-1.01.18.3-1
ii  python3-netifaces  0.10.9-0.2+b3
pn  python3-opencv 
ii  python3-pyinotify  0.9.6-1.3
pn  python3-pyopencl   
pn  python3-uinput 
ii  python3-yaml   5.3.1-5
pn  v4l2loopback-dkms  

-- no debconf information

Bug#988709: RM: ooo-thumbnailer -- RoQA; orphaned, abandoned upstream

[Stephen Kitt]

Control: retitle -1 "ooo-thumbnailer: please set the maintainer to Debian QA"
Control: reassign -1 ooo-thumbnailer
Control: tag -1 - moreinfo

Hi Sean,

On Tue, 14 Sep 2021 12:21:40 -0700, Sean Whitton 
wrote:
> On Tue 18 May 2021 at 04:00PM +02, Stephen Kitt wrote:
> > Please remove ooo-thumbnailer from unstable. It’s abandoned upstream
> > (see https://launchpad.net/ooo-thumbnailer), is orphaned in Debian,
> > and even though its last upstream release was made ten years ago, it
> > never even made it into Debian.  
> 
> It has a high popcon -- is there any evidence it doesn't work?

I was going by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597296#37
but looking at my own system shows that ooo-thumbnailer is indeed working.

I’ll change this to a request to remove David D Lowe from the maintainer
field, and upload a package doing so.

Regards,

Stephen


pgpFmjOJymknd.pgp
Description: OpenPGP digital signature

Bug#993944: make: noguile profile is incomplete

[Stephen Kitt]

Package: make
Version: 4.3-1
Severity: normal
Tags: patch

Dear Maintainer,

The patch in #892566 wasn't applied completely; the

Build-Profiles: 

was left out in the make-guile package stanza. The result is that a
noguile profile build doesn't build-depend on guile, which is fine,
but it still builds a make-guile package which doesn't actually
support guile.

Please add the missing line.

Regards,

Stephen

-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (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 4.19.0-17-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages make depends on:
ii  libc6  2.28-10

make recommends no packages.

Versions of packages make suggests:
pn  make-doc  

-- no debconf information

Bug#993452: osslsigncode: MSI tests fail on big-endian architectures

[Stephen Kitt]

Package: osslsigncode
Version: 2.2-1
Severity: normal
Tags: upstream

Dear Maintainer,

The MSI tests enabled in 2.2-1 fail on big-endian architectures. This
could be related to the MSI rewrite in 2.2.

012. Sign a MSI file with a certificate and a private key in the PEM format 
failed
022. Sign a MSI file with an encrypted private key in the PEM format
failed
032. Sign a MSI file with an encrypted private key in the DER format
failed
042. Sign a MSI file with a SPC certificate and a PVK private key   
failed
052. Sign a MSI file with a certificate and a key stored in a PKCS#12 container 
failed
072. Sign a MSI file with Authenticode timestamping 
failed
082. Sign a MSI file with RFC 3161 timestamping 
failed
102. Sign a MSI file with addUnauthenticatedBlob
failed
112. Sign a MSI file with the nest flag 
failed
122. Sign a MSI file with a PEM key and a password read from password.txt file  
failed
132. Sign a MSI file with a PKCS#12 container and the file with a password  
failed
142. Sign a MSI file with a descryption 
failed
152. Sign a MSI file with specified URL 
failed
162. Sign a MSI file with the common purpose set
failed
172. Add an additional certificate to the signature block of a MSI file 
failed
212. Sign a MSI file with MD5 set of cryptographic hash functions   
failed
222. Sign a MSI file with SHA1 set of cryptographic hash functions  
failed
232. Sign a MSI file with SHA2 set of cryptographic hash functions  
failed
242. Sign a MSI file with SHA384 set of cryptographic hash functions
failed
252. Sign a MSI file with SHA512 set of cryptographic hash functions
failed
262. Extract the PEM signature from the MSI file
failed
272. Extract the DER signature from the MSI file
failed
312. Attach the DER signature to the MSI file   
failed
322. Attach the PEM signature to the MSI file   
failed
332. Attach the PEM signature to the signed MSI file
failed
342. Attach the PEM signature to the signed MSI file with the nest flag 
failed
352. Remove the signature from the MSI file 
failed
372. Add an authenticode timestamp to the MSI signed file   
failed
382. Add a RFC 3161 timestamp to the MSI signed file
failed
392. Add an unauthenticated blob to the MSI signed file 
failed
402. Compare the leaf hash against SHA256 message digest for the MSI file   
failed
412. Sign a MSI file with the add-msi-dse option
failed
512. Verify MSI file signed after the cert has been expired 
failed
522. Verify a MSI file signed with Authenticode after the cert has been expired 
failed
532. Verify a MSI file signed with RFC3161 after the cert has been expired  
failed
542. Verify a MSI file signed with the expired cert 
failed
552. Verify a MSI file signed with the revoked cert 
failed
562. Verify a MSI file signed with the multiple signature   
failed

See
https://buildd.debian.org/status/fetch.php?pkg=osslsigncode=s390x=2.2-1=1630508632=0
for the complete logs.

Regards,

Stephen

-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (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 4.19.0-17-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages osslsigncode 

Bug#993451: osslsigncode: timestamp-based tests fail on amd64 (sometimes)

[Stephen Kitt]

Package: osslsigncode
Version: 2.2-1
Severity: normal
Tags: upstream

Dear Maintainer,

The tests enabled in 2.2-1 failed on amd64 on the buildd:

071. Sign a CAT file with Authenticode timestamping 
failed
072. Sign a MSI file with Authenticode timestamping 
failed
073. Sign a CAB file with Authenticode timestamping 
failed
074. Sign a PE file with Authenticode timestamping  
failed
081. Sign a CAT file with RFC 3161 timestamping 
failed
082. Sign a MSI file with RFC 3161 timestamping 
failed
083. Sign a CAB file with RFC 3161 timestamping 
failed
084. Sign a PE file with RFC 3161 timestamping  
failed
371. Add an authenticode timestamp to the CAT signed file   
failed
372. Add an authenticode timestamp to the MSI signed file   
failed
373. Add an authenticode timestamp to the CAB signed file   
failed
374. Add an authenticode timestamp to the PE signed file
failed
381. Add a RFC 3161 timestamp to the CAT signed file
failed
382. Add a RFC 3161 timestamp to the MSI signed file
failed
383. Add a RFC 3161 timestamp to the CAB signed file
failed
384. Add a RFC 3161 timestamp to the PE signed file 
failed
464. Verify changed PE file after signing with Authenticode timestamping
failed
474. Verify changed PE file after signing with RFC 3161 timestamping
failed
521. Verify a CAT file signed with Authenticode after the cert has been expired 
failed
522. Verify a MSI file signed with Authenticode after the cert has been expired 
failed
523. Verify a CAB file signed with Authenticode after the cert has been expired 
failed
524. Verify a PE file signed with Authenticode after the cert has been expired  
failed
531. Verify a CAT file signed with RFC3161 after the cert has been expired  
failed
532. Verify a MSI file signed with RFC3161 after the cert has been expired  
failed
533. Verify a CAB file signed with RFC3161 after the cert has been expired  
failed
534. Verify a PE file signed with RFC3161 after the cert has been expired   
failed
541. Verify a CAT file signed with the expired cert 
failed
542. Verify a MSI file signed with the expired cert 
failed
543. Verify a CAB file signed with the expired cert 
failed
544. Verify a PE file signed with the expired cert  
failed
551. Verify a CAT file signed with the revoked cert 
failed
552. Verify a MSI file signed with the revoked cert 
failed
553. Verify a CAB file signed with the revoked cert 
failed
554. Verify a PE file signed with the revoked cert  
failed
562. Verify a MSI file signed with the multiple signature   
failed
563. Verify a CAB file signed with the multiple signature   
failed
564. Verify a PE file signed with the multiple signature
failed

See
https://buildd.debian.org/status/fetch.php?pkg=osslsigncode=amd64=2.2-1=1630508600=0
for the complete logs.

Regards,

Stephen


-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (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 4.19.0-17-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages osslsigncode depends on:
ii  libc62.28-10
ii  libcurl3-gnutls  7.64.0-4+deb10u2
ii  libglib2.0-0 2.58.3-2+deb10u3
ii  libgsf-1-114 1.14.45-1
ii  

Bug#992066: libvkd3d-headers: Package doesn't contain header files

[Stephen Kitt]

On Fri, 20 Aug 2021 17:03:28 +0200 (CEST), Francois Gouget 
wrote:
> I can confirm this. None of the 1.2-5 vkd3d packages contain the 
> headers: particularly not libvkd3d-headers and not libvkd3d-dev.
> 
> The workaround is to go back to vkd3d 1.2-3 (if you can find the 
> corresponding packages that is).

They’re available from snapshots:
https://snapshot.debian.org/package/vkd3d/1.2-3/

Regards,

Stephen


pgpbrgJP0kTJP.pgp
Description: OpenPGP digital signature