Bug#1075034: marked as pending in goocanvas-2.0

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #1075034 in goocanvas-2.0 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/goocanvas-2.0/-/commit/968bf29cfb95598ee58209f5418123c2fdadcc84


Add an explicit pointer cast to fix the build with GCC 14

Closes: #1075034.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1075034

Bug#1073643: marked as pending in nilfs-tools

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #1073643 in nilfs-tools reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/nilfs-tools/-/commit/b2ae6882518c39cd0ded64c5cf48350ba32ba923


Move binaries to /usr

Closes: #1073643.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1073643

Bug#1075275: marked as pending in mingw-w64

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #1075275 in mingw-w64 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/mingw-w64-team/mingw-w64/-/commit/4dbdc1773e5600bb16a34605de9c170577e52344


Cleanup winbase.h and winnt.h

Closes: #1075275.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1075275

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

[Stephen Kitt]

On Thu, 18 Jul 2024 11:17:06 +0500, Ar Worf  wrote:

> On Fri, 17 May 2024 23:08:30 +0200 Stephen Kitt  wrote:
> 
> > 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
> 
> But it DOES work. Tested in my 6.9.7-1~bpo12+1 kernel. And if the package
> maintainers, for a change, did actual testing instead of avoiding their
> responsibilies by marking any trivially fixable bug as "RC" based on some
> unproved rumor of a third-party noname - that would be great.

Your is the first confirmation that the patch works for at least one user
(albeit a third-party noname). It doesn’t work for me. While I’m at it, I
didn’t mark the bug RC, the initial reporter did.

At least you had the gumption to insult me in public. Since you will do a
much better job than me, I’ve orphaned the package and signaled your intent
to adopt it. See https://bugs.debian.org/1076575

Best of luck,

Stephen


pgpGexw_fp7B2.pgp
Description: OpenPGP digital signature

Bug#1005961: nq,fq: trying to overwrite '/usr/bin/fq', which is also in package nq 0.3.1-4

[Stephen Gelman]

 Great, that would be perfect if you’re willing to do so! Just let me know
when that’s done and I can work with the nq debian maintainer to get that
uploaded.

Thanks,

Stephen

On Jun 29, 2024 at 7:11:33 AM, Leah Neukirchen  wrote:

> Hi, nq maintainer here.
>
> I propose to make a new release 1.0, where fq is renamed to nqtail,
> and by default I will install a symlink fq -> nqtail.
>
> Debian (and other distros) are free to remove this symlink.
>
> Since fq is widely packaged now
> (https://repology.org/project/fq-inspect-binary-data/versions)
> I hope this will resolve the issue.
>
> Thanks,
> --
> Leah Neukirchenhttps://leahneukirchen.org/
>
>

Bug#1005961: nq,fq: trying to overwrite '/usr/bin/fq', which is also in package nq 0.3.1-4

[Stephen Gelman]

On May 29, 2024 at 4:04:13 PM, Bastian Germann  wrote:

> I suggest fq renames the binary because it was introduced over 4 years
> later and has only been in one release so far.
>

Both packages have very low usage acc to popcon, but for fq the fq binary
is the entire point of the package, whereas for nq, the fq binary seems to
only be a small part of the functionality of the package. Therefore, I
think that nq should rename the fq binary.

Stephen

Bug#1071825: linux-image-6.8.9-amd64: Fails to build some module(s) during install

[Stephen Kitt]

Control: notforwarded -1
Control: forcemerge 1071293 -1

On Sat, 25 May 2024 10:54:15 +0200, Diederik de Haas 
wrote:
> On Saturday, 25 May 2024 10:18:20 CEST Bastian Blank wrote:
> > Control: reassign -1 ddcci-dkms/0.4.4-1  
> 
> Upstream has a commit for compatibility with 6.8 and I've set that at
> the 'forwarded' URL. There's no release/tag with that commit though.

As mentioned in #1071293, the upstream commit results in a non-functional
module. I don’t think it’s an appropriate fix for Debian.

Regards,

Stephen


pgp5MUEFLsk3N.pgp
Description: OpenPGP digital signature

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


pgpWOb9Q1xZQL.pgp
Description: OpenPGP digital signature

Bug#1069528: marked as pending in mingw-w64

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #1069528 in mingw-w64 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/mingw-w64-team/mingw-w64/-/commit/90fb8e2afd9656aaf25dc5fa9974a7b273f37862


Disable 64-bit time_t flags in dpkg-buildflags when cross-compiling

Closes: #1069528.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1069528

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


pgpytC3Od5ois.pgp
Description: OpenPGP digital signature

Bug#1066939: marked as pending in xboxdrv

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #1066939 in xboxdrv reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/xboxdrv/-/commit/68d528c7a0db65335c174fd051ecf992a466eaa4


Adjust to the new 64-bit input_event API

Closes: #1066939.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1066939

Bug#1066661: marked as pending in heroes

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #101 in heroes reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/heroes/-/commit/dc5f633293579980404efb983faa6cfaa02160a1


Avoid forward declarations in the configure run test program

Closes: #101.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/101

Bug#1061317: marked as pending in gemrb

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #1061317 in gemrb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/gemrb/-/commit/4948cd7d830c4d63f3df6a8b780c8702c3f0b44b


New upstream release

Supports Python 3.12; closes: #1061317.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1061317

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


pgpxVFjnDIF0f.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,&pcreerr,&pcreerroff,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,&pcreerr,&pcreerroff,0);
+if(sre == NULL) {
+  pcre2_get_error_message(pcreerr, pcreerrm

Bug#1042415: ruby-aws-partitions: Package missing partitions.json

[Stephen Gelman]

Package: ruby-aws-partitions
Version: 1.653.0-1
Severity: grave
Tags: patch
Justification: renders package unusable
X-Debbugs-Cc: ssg...@debian.org

In version 1.653.0-1, 
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/partitions.json 
is not present. It is there in version 1.354.0-2 in bullseye. Without that 
file, any actual use of this gem fails:

$ irb
irb(main):001:0> require 'aws-partitions'
=> true
irb(main):002:1* Aws::Partitions.each do |partition|
irb(main):003:1*   puts partition.name
irb(main):004:0> end
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:225:in
 `read': No such file or directory @ rb_sysopen - 
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/partitions.json 
(Errno::ENOENT)
from 
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:225:in
 `defaults'
from 
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:214:in
 `default_partition_list'
from 
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:137:in
 `each'
from (irb):2:in `'
from /usr/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `'
from /usr/bin/irb:25:in `load'
from /usr/bin/irb:25:in `'

Patch to fix is attached


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby-aws-partitions depends on:
ii  ruby  1:3.1

ruby-aws-partitions recommends no packages.

ruby-aws-partitions suggests no packages.

-- no debconf information
diff -Nru ruby-aws-partitions-1.653.0/debian/changelog 
ruby-aws-partitions-1.653.0/debian/changelog
--- ruby-aws-partitions-1.653.0/debian/changelog2022-10-30 
08:49:35.0 -0500
+++ ruby-aws-partitions-1.653.0/debian/changelog2023-07-27 
17:39:10.0 -0500
@@ -1,3 +1,11 @@
+ruby-aws-partitions (1.653.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Change DH_RUBY_GEM_INSTALL_WHITELIST_APPEND to DH_RUBY_GEM_INSTALL_INCLUDE
+in debian/rules to work with newer gem2deb
+
+ -- Stephen Gelman   Thu, 27 Jul 2023 17:39:10 -0500
+
 ruby-aws-partitions (1.653.0-1) unstable; urgency=medium
 
   * Team Upload
diff -Nru ruby-aws-partitions-1.653.0/debian/rules 
ruby-aws-partitions-1.653.0/debian/rules
--- ruby-aws-partitions-1.653.0/debian/rules2022-10-30 08:49:35.0 
-0500
+++ ruby-aws-partitions-1.653.0/debian/rules2023-07-27 17:36:38.0 
-0500
@@ -2,7 +2,7 @@
 
 export GEM2DEB_TEST_RUNNER = --check-dependencies
 export DH_RUBY = --gem-install
-export DH_RUBY_GEM_INSTALL_WHITELIST_APPEND := partitions.json
+export DH_RUBY_GEM_INSTALL_INCLUDE := partitions.json
 
 %:
dh $@ --buildsystem=ruby --with ruby

Bug#999977: qxw: depends on obsolete pcre3 library

[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


pgpJ5rnX7z89K.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


pgpdvmAJgP37_.pgp
Description: OpenPGP digital signature

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


pgprVyzst0n5p.pgp
Description: OpenPGP digital signature

Bug#1027130: Bug may still be open

[Stephen Lyons]

Dear Maintainer;

This "grave" bug has been marked as closed in 1.0.0-dfsg-1 however it is
still open in 0.103.7-dfsg-0+deb11u1 and there is no indication that it
has been resolved in 0.103.8+dfsg-0+deb11u1 which is promulgated to
solve the "serious" CVEs handled in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031509 for "Buster".

As such trying to upgrade my system is warning me that this grave bug is
present. It is not clear whether this is indeed the case or not.

I must note that I am running Devuan Stable "Chimaera" but it seems that
this issue will also arise for Debian Stable "Bulleye".

Regards

Stephen Lyons

Bug#1031387: supertuxkart: Fails to compile due to inescaped +, bug in shaderc

[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


pgpDYg4JyVrwP.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


pgpiVTQxbKULW.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


pgpEUZjToHaug.pgp
Description: OpenPGP digital signature

Bug#1030701: marked as pending in intelrdfpmath

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #1030701 in intelrdfpmath reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/intelrdfpmath/-/commit/55fe834e7528943d0307f5473fa9b205f24644cf


Fix architecture support on non-x86

Closes: #1030701


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1030701

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
<https://github.com/mongodb/libmongocrypt/blob/master/cmake/IntelDFP.cmake>):
armel/armhf are assumed to behave like i386 (I haven’t checked whether that
makes sense), arm64/ppc64el/riscv64 are assumed to behave like amd64, and
s390x is supported explicitly.

If you want to track the unsupported architectures, please open a new bug. As
far as I can tell, even if libmongocrypt were built in Debian using its
embedded copy of intelrdfpmath, it would fail on the same architectures.

Regards,

Stephen


pgpgzApOVtQZ1.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]

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


pgpwU4NmoIwN8.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


pgpAyQZyWANAs.pgp
Description: OpenPGP digital signature

Bug#1022051: /boot/vmlinuz-5.10.0-19-amd64: Same Here

[Boyd Stephen Smith Jr.]

Package: src:linux
Version: 5.10.149-1
Followup-For: Bug #1022051

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

   * What led up to the situation?

Normal kernal package upgrade and reboot.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

5.10.0-18 works fine.  5.10.0-19 always hangs with "flip_done timed out" before
I can get even a text console.

   * What was the outcome of this action?

Using older kernel for now.

   * What outcome did you expect instead?

5.10.0-19 bootable.

- -- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: To Be Filled By O.E.M.
product_name: To Be Filled By O.E.M.
product_version: To Be Filled By O.E.M.
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: P2.00
board_vendor: ASRock
board_name: X399 Taichi
board_version: 

** Network interface configuration:
*** /etc/network/interfaces:

auto lo
iface lo inet loopback

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-0fh) Root Complex [1022:1450]
Subsystem: ASRock Incorporation Family 17h (Models 00h-0fh) Root 
Complex [1849:1450]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-0fh) PCIe GPP Bridge [1022:1453] (prog-if 00 [Normal decode])
Subsystem: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 
00h-0fh) PCIe GPP Bridge [1022:1453]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b] (rev 59)
Subsystem: ASRock Incorporation FCH SMBus Controller [1849:]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] X399 Series 
Chipset SATA Controller [1022:43b6] (rev 02) (prog-if 01 [AHCI 1.0])
Subsystem: ASMedia Technology Inc. X399 Series Chipset SATA Controller 
[1b21:1062]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] X399 Series 
Chipset PCIe Bridge [1022:43b1] (rev 02) (prog-if 00 [Normal decode])
Subsystem: ASMedia Technology Inc. X399 Series Chipset PCIe Bridge 
[1b21:0201]
Control: I/

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#1016600: siconos: vtk[6,7] removal

[Stephen Sinclair]

On Thu, Sep 1, 2022 at 10:56 PM Adrian Bunk  wrote:
>
> On Wed, Aug 03, 2022 at 10:42:08PM +0200, Sebastian Ramacher wrote:
> > Source: siconos
> > Version: 4.3.1+dfsg-2
> > Severity: serious
> > X-Debbugs-Cc: sramac...@debian.org
> > Tags: sid bookworm
> > Control: block 1016597 by -1
> > User: gl...@debian.org
> > Usertags: vtk6_vtk7_removal
> >
> > Based on #1013156 and similar bugs:
> >
> > Dear maintainer,
> >
> > Debian archive has now three major versions of the VTK (The
> > Visualization Toolkit) package: vtk6, vtk7 and vtk9. Old vesions
> > (vtk6 and vtk7) are not supported by upstream and the package itself
> > is not easy for the mainance.
> >
> > We aim to drop old and deprecated version vtk6 and vtk7 packages before
> > the freeze of the Debian 12 Bookworm. Your package depends on vtk6 or
> > vtk7. Thus we ask you to migrate it to the latest vtk9 package.
>
> Two observations regarding the usage of VTK in siconos:
>
> There is WITH_VTK in siconos that does not seem to build with VTK 9,
> but it's anyway not enabled.
>
> The only current usage of VTK is python3-vtk7 in siconos-mechanics-tools.
> This might need upstrream fixes like
>   https://github.com/siconos/siconos/pull/437
>
> > Cheers


Thank you Adrian.  I have an update to the package for a newer
upstream version that has been under construction for a while, but I
haven't been available until recently to work on it more.  I'll try to
get this done soon.

Steve

Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1

[Stephen Gelman]

On Aug 29, 2022 at 6:52:06 AM, Luca Falavigna  wrote:

> Il giorno lun 29 ago 2022 alle ore 07:34 Stephen Gelman
>  ha scritto:
>
> Would you be interested in creating a MR for your changes to salsa? If not
> that’s fine, just let me know and I will pull in the changes myself.
>
>
> Sure, here it is:
> https://salsa.debian.org/ssgelm/opentracing-cpp/-/merge_requests/1
>
> --
> Cheers,
> Luca
>

This looks awesome; I merged it. Would you like to cancel your NMU and I
can release 1.6.0-3 now, or would you prefer to wait for your NMU? I don’t
have particularly strong feelings in either direction.

Stephen

Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1

[Stephen Gelman]

On Aug 28, 2022 at 4:29:03 AM, Luca Falavigna  wrote:

> Control: tags 1017132 + patch
> Control: tags 1017132 + pending
>
>
> Dear maintainer,
>
> I've prepared an NMU for opentracing-cpp (versioned as 1.6.0-2.1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.
>
> Regards,
> Luca
>

This is awesome, thanks so much! It was on my todo list to fix but I hadn’t
gotten around to it yet… Would you be interested in creating a MR for your
changes to salsa? If not that’s fine, just let me know and I will pull in
the changes myself.

Stephen

Bug#945748: marked as pending in xboxdrv

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #945748 in xboxdrv reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/xboxdrv/-/commit/a704bb3c837c25fed2fa2cc6fcf19a37d75aa260


Apply upstream patch to port xboxdrv to Python 3

Closes: #945748


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/945748

Bug#1010538: gdu: FTBFS on ppc64el

[Stephen Gelman]

 It seems rebuilding the package fixed this…
https://buildd.debian.org/status/logs.php?pkg=gdu&ver=5.13.2-1%2Bb1&arch=ppc64el

On May 3, 2022 at 4:07:00 PM, Sebastian Ramacher 
wrote:

> Source: gdu
> Version: 5.13.2-1
> Severity: serious
> Tags: ftbfs sid bookworm
> Justification: fails to build from source (but built successfully in the
> past)
> X-Debbugs-Cc: sramac...@debian.org
>
>
> https://buildd.debian.org/status/fetch.php?pkg=gdu&arch=ppc64el&ver=5.13.2-1%2Bb1&stamp=1651439537&raw=0
>
> === RUN   TestMin
> --- PASS: TestMin (0.00s)
> PASS
> ok   github.com/dundee/gdu/v5/tui 0.229s
> FAIL
> dh_auto_test: error: cd _build && go test -vet=off -v -p 8
> github.com/dundee/gdu/v5/build github.com/dundee/gdu/v5/cmd/gdu
> github.com/dundee/gdu/v5/cmd/gdu/app
> github.com/dundee/gdu/v5/internal/common
> github.com/dundee/gdu/v5/internal/testanalyze
> github.com/dundee/gdu/v5/internal/testapp
> github.com/dundee/gdu/v5/internal/testdev
> github.com/dundee/gdu/v5/internal/testdir
> github.com/dundee/gdu/v5/pkg/analyze github.com/dundee/gdu/v5/pkg/device
> github.com/dundee/gdu/v5/pkg/fs github.com/dundee/gdu/v5/report
> github.com/dundee/gdu/v5/stdout github.com/dundee/gdu/v5/tui returned
> exit code 1
> make: *** [debian/rules:14: binary-arch] Error 25
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
> exit status 2
>
> Cheers
> --
> Sebastian Ramacher
>
>

Bug#1010236: marked as pending in xye

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #1010236 in xye reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/xye/-/commit/88b977a58135b709bb7c7a5177aed6e0d3e56f91


Force signed chars on all architectures

Closes: #1010236


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1010236

Bug#1006815: marked as pending in xmoto

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #1006815 in xmoto reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/xmoto/-/commit/c04a481703150f31012558b4655ac0b8c5390e8c


Rework the autopkgtest to make it more reliable

Closes: #1006815


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1006815

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#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#965846: 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


pgpjqbqVKwhVK.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#998563: marked as pending in golang-github-jbenet-go-context

[Stephen Gelman]

Control: tag -1 pending

Hello,

Bug #998563 in golang-github-jbenet-go-context reported by you has been fixed 
in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-jbenet-go-context/-/commit/ee0918d089d9c67d67b66c7d5604055faeab9023


Add TRAVIS env flag to skip tests that use timeouts (Closes: #998563)

The comments note that timeouts don't work reliably in Travis CI.
Apparently, based on #998563 the same is true in Debian CI so adding the
flag will skip those tests.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/998563

Bug#972084: marked as pending in gweled

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #972084 in gweled reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/gweled/-/commit/f0c1431f88d789885e82411ec156ab667ce7232d


Apply upstream patch to fix SVGs

Closes: #972084


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/972084

Bug#997168: marked as pending in scottfree

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #997168 in scottfree reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/scottfree/-/commit/59221d2a1f4f401773e74bdc0610e41102c0aad4


Add constant format strings

Closes: #997168


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/997168

Bug#997398: marked as pending in xmoto

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #997398 in xmoto reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/xmoto/-/commit/4f93cb6df36b4bbba5b4015d5a7543128c3aa76d


Drop the dh_auto_configure override

Closes: #997398


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/997398

Bug#995597: marked as pending in bsdgames

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #995597 in bsdgames reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/bsdgames/-/commit/a1c5ab9de5f5336adf50a403fa478059213ff15e


Specify format string literals for all printw() calls

Closes: #995597


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/995597

Bug#984181: marked as pending in htmlcxx

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #984181 in htmlcxx reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/htmlcxx/-/commit/d39cae1c99029273e6149cc27d35030deea3b95c


Drop unnecessary exception declarations

Closes: #984181


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/984181

Bug#895037: Bug#895038: libappindicator: deprecated in Debian; AppIndicator based applications, please switch to Ayatana (App)Indicator(s)

[Stephen Kitt]

On Mon, 28 Dec 2020 16:41:12 +0100 Ivo De Decker  wrote:
> I added some hints to finish this, and now libindicator and libappindicator
> are no longer in testing.

I uploaded a fix for #956782 in unstable, which means libappindicator is no
longer needed there either:

skitt@coccia:~$ dak rm --no-action -R libappindicator
Will remove the following packages from unstable:

gir1.2-appindicator-0.1 |   0.4.92-8 | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x
gir1.2-appindicator3-0.1 |   0.4.92-8 | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x
libappindicator |   0.4.92-8 | source
libappindicator-dev |   0.4.92-8 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
libappindicator-doc |   0.4.92-8 | all
libappindicator1 |   0.4.92-8 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
libappindicator3-1 |   0.4.92-8 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
libappindicator3-dev |   0.4.92-8 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x

Maintainer: Debian QA Group 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


I’m guessing this should be converted to an RM, but I’ll leave that up to
Mike.

Regards,

Stephen


pgpgP9Ob8nrAb.pgp
Description: OpenPGP digital signature

Bug#986923: Salzburg BSP

[Stephen Kitt]

user debian-rele...@lists.debian.org
usertags -1 + bsp-2021-04-AT-Salzburg
owner !
thank you


pgpo9U557kYkO.pgp
Description: OpenPGP digital signature

Bug#986923: Salzburg BSP

[Stephen Kitt]

user debian-rele...@lists.debian.org
usertags -1 + bsp-2021-04-AT-Salzburg
owner !
thank you


pgpwwO2v1CVKD.pgp
Description: OpenPGP digital signature

Bug#986515: siconos: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j1 test "ARGS=-E 'COLLECTION|collection|python_test_lcp|dr_iso1|ContactTest'" ARGS\+=-j1 returned exit code 2

[Stephen Sinclair]

I was unable to reproduce this issue.  The build was successful for me
locally and on Debian Salsa server. The salsa build log can be found
here:
https://salsa.debian.org/science-team/siconos/-/jobs/1562650/raw

My local build log is attached from running dpkg-buildpackage.

regards,
Stephen Sinclair

On Wed, Apr 7, 2021 at 9:01 AM Lucas Nussbaum  wrote:
>
> Source: siconos
> Version: 4.3.1+dfsg-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210406 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in bullseye, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > make[2]: Entering directory '/<>/obj-x86_64-linux-gnu'
> > Running tests...
> > /usr/bin/ctest --force-new-ctest-process -E 
> > 'COLLECTION|collection|python_test_lcp|dr_iso1|ContactTest' -j1
> > Test project /<>/obj-x86_64-linux-gnu
> >   Start  1: DLSODES-test
> >  1/95 Test  #1: DLSODES-test    Passed
> > 0.01 sec
> >   Start  2: DLSODAR-test
> >  2/95 Test  #2: DLSODAR-test    Passed
> > 0.01 sec
> >   Start  3: DLSODI-test
> >  3/95 Test  #3: DLSODI-test .   Passed
> > 0.02 sec
> >   Start  4: DLSODPK-test
> >  4/95 Test  #4: DLSODPK-test    Passed
> > 0.12 sec
> >   Start  5: DLSODA-test
> >  5/95 Test  #5: DLSODA-test .   Passed
> > 0.01 sec
> >   Start  6: DLSODE-test
> >  6/95 Test  #6: DLSODE-test .   Passed
> > 0.01 sec
> >   Start  7: DLSODIS-test
> >  7/95 Test  #7: DLSODIS-test    Passed
> > 0.01 sec
> >   Start  8: DLSODKR-test
> >  8/95 Test  #8: DLSODKR-test    Passed
> > 0.03 sec
> >   Start  9: DLSOIBT-test
> >  9/95 Test  #9: DLSOIBT-test    Passed
> > 0.04 sec
> >   Start 10: odepacktest10
> > 10/95 Test #10: odepacktest10 ...   Passed
> > 0.00 sec
> >   Start 11: dr1_radau5
> > 11/95 Test #11: dr1_radau5 ..   Passed
> > 0.01 sec
> >   Start 12: dr2_radau5
> > 12/95 Test #12: dr2_radau5 ..   Passed
> > 0.01 sec
> >   Start 13: dr_radau
> > 13/95 Test #13: dr_radau    Passed
> > 0.00 sec
> >   Start 14: dr_radaup
> > 14/95 Test #14: dr_radaup ...   Passed
> > 0.01 sec
> >   Start 15: dr_rodas
> > 15/95 Test #15: dr_rodas    Passed
> > 0.00 sec
> >   Start 16: dr_seulex
> > 16/95 Test #16: dr_seulex ...   Passed
> > 0.00 sec
> >   Start 17: test_op3x3
> > 17/95 Test #17: test_op3x3 ..   Passed
> > 0.26 sec
> >   Start 18: test_timers_interf
> > 18/95 Test #18: test_timers_interf ..   Passed
> > 0.01 sec
> >   Start 19: test_blas_lapack
> > 19/95 Test #19: test_blas_lapack    Passed
> > 0.01 sec
> >   Start 20: test_pinv
> > 20/95 Test #20: test_pinv ...   Passed
> > 0.02 sec
> >   Start 21: tools_projection
> > 21/95 Test #21: tools_projection    Passed
> > 0.01 sec
> >   Start 22: NumericsArrays
> > 22/95 Test #22: NumericsArrays ..   Passed
> > 0.01 sec
> >   Start 23: NM_test
> > 23/95 Test #23: NM_test .   Passed
> > 0.17 sec
> >   Start 24: tools_test_JordanAlgebra
> > 24/95 Test #24: tools_test_JordanAlgebra    Passed
> > 0.01 sec
> >   Start 25: NM_MUMPS_test
> > 25/95 Test #25: NM_MUMPS_test ...   Passed
> > 0.01 sec
> >   Start 26: SBM_test
> > 26/95 Test #26: SBM_test    Passed
> > 0.02 sec
> >   Start 27: SBCM_to_SBM
> > 27/95 Test #27: SBCM_to_SBM .   Passed
> > 0.01 sec
> >   Start 28: SparseMatrix_test
> > 28/95 Test #28: SparseMatrix_test ...   Passed
> >

Bug#981146: loggedfs: fails: fusermount: unknown option 'nonempty'

[Stephen Kitt]

Control: severity -1 important

On Wed, 27 Jan 2021 21:21:36 +0800, Paul Wise  wrote:
> On Wed, 2021-01-27 at 13:10 +0100, Stephen Kitt wrote:
> > Unfortunately this would be rather difficult to fix in loggedfs itself.  
> 
> Ugh, sorry for the bugs then. I did strings on loggedfs, saw fusermount
> and nonempty in the output so presumed it was coming from loggedfs.
> I'll leave it up to you to close/downgrade/reassign the bugs I filed.

No worries, they’re still bugs affecting loggedfs! I’ll downgrade this one
and fix the other. (I’ll also suggest a fix for the nonempty handling in
fuse3...)

Regards,

Stephen


pgpMtsxfCEmPd.pgp
Description: OpenPGP digital signature

Bug#981146: loggedfs: fails: fusermount: unknown option 'nonempty'

[Stephen Kitt]

Hi pabs,

On Wed, 27 Jan 2021 07:19:13 +0800, Paul Wise  wrote:
> When I try to use loggedfs I get an error, presumably because loggedfs
> wants fuse rather than fuse3, but I can't install fuse because other
> things I have installed want fuse3 instead of fuse.

Unfortunately this would be rather difficult to fix in loggedfs itself.
loggedfs goes through libfuse2, which then uses fusermount. With fuse3,
fusermount no longer supports “-o nonempty”, because that’s now the default
(but it’s not treated as a no-op). There’s no nice way for loggedfs to
determine which version of fusermount will be used; it could run “fusermount
-V” and parse its output — but it can’t determine which binary libfuse2 will
actually use...

See also #918984, #939767, #927291.

Regards,

Stephen


pgpVjfTwgx1Tl.pgp
Description: OpenPGP digital signature

Bug#969597: libzstd: Please correct version in symbol file

[Stephen Kitt]

Control: severity -1 normal

Hi Sebastian,

On Sat, Sep 05, 2020 at 09:03:20PM +0200, Sebastian Andrzej Siewior wrote:
> The symbol file records for instance the following symbols:
>   ZSTD_minCLevel
>   ZSTD_compressStream2
> 
> as present in 1.3.8. This isn't entirely correct.  Both symbols were
> present in 1.3.8 but they were hidden behind ZSTD_STATIC_LINKING_ONLY
> and only available for static linking.
> They are available for dynamic linking since 1.4.0, please see commit
>d7d89513d6a21 ("Stabilize advance API")

That was no doubt the intention, however in practice the symbol
visibility wasn’t as expected: looking at the .so build in version
1.3.8, common/pool.c includes common/zstd_internal.h which defines
ZSTD_STATIC_LINKING_ONLY before including zstd.h, and as a result the
symbols are visible.

(It’s unfortunate that the build hides the exact commands used, so
they’re not visible in the build logs, but that’s another issue. Easy
enough to fix in a local build to see exactly what’s going on...)

So the cat is out of the bag, and the symbols are present and visible
in the .so. The symbols file is generated and only reflects the
reality of what is present in the file (apart from the version numbers
which are added manually).

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#967170: markupsafe: Unversioned Python removal in sid/bullseye

[Stephen Kitt]

Control: fixed -1 1.1.1-1
Control: close -1

On Sun, Jan 24, 2021 at 09:12:04AM +0100, Jann Haber wrote:
> fixed -1 1.1.1-1
> close -1
> thanks
> 
> Looking at the package, it seems like this bug has been fixed in version 
> 1.1.1-1 - I can find no more references to unversioned python in that 
> version. I marked the bug as fixed. Please re-open if I am mistaken.
> 
> Best,
> Jann
> 
> On Tue, 04 Aug 2020 09:28:33 + Matthias Klose  wrote:
> > Package: src:markupsafe
> > Version: 1.1.1-1
> > Severity: serious
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2unversioned
> > 
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
> > 
> > We will keep some Python2 package as discussed in
> > https://lists.debian.org/debian-python/2020/07/msg00039.html
> > but removing the unversioned python packages python-minimal, python,
> > python-dev, python-dbg, python-doc.
> > 
> > Your package either build-depends, depends on one of those packages.
> > Please either convert these packages to Python3, or if that is not
> > possible, replaces the dependencies on the unversioned Python
> > packages with one of the python2 dependencies (python2, python2-dev,
> > python2-dbg, python2-doc).
> > 
> > Please check for dependencies, build dependencies AND autopkg tests.
> > 
> > If there are questions, please refer to the wiki page for the removal:
> > https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> > #debian-python, or the debian-pyt...@lists.debian.org mailing list.
> > 
> > 


signature.asc
Description: PGP signature

Bug#975492: marked as pending in scummvm

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #975492 in scummvm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/scummvm/-/commit/5b455c4a8d589593f35d86cd54642345f8cc68b3


Disable Ultima on platforms where its tests fail

Closes: #975492


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/975492

Bug#976468: This package only builds Arch:all binary packages

[Stephen Kitt]

Control: severity -1 important

Hi,

On Sat, 5 Dec 2020 21:45:34 +0100 Lucas Nussbaum  wrote:
> This package only builds Arch:all binary packages. Unfortunately, I
> don't think that we have a way to indicate that such binary packages
> must be built on a specific architecture, and thus avoid a failure on
> arm64.
> 
> In those cases, building those packages on amd64 works fine, so the bug
> is limited to building arch:all packages on specific architectures.

In python-ptrace’s case, the package supports a limited set of architectures,
so perhaps it shouldn’t be arch:all in the first place. The current package
only supports amd64, i386, ppc and arm; version 0.9.6 adds ppc64, and the
forthcoming 0.9.8 will add arm64.

Downgrading however since it does build on amd64.

Regards,

Stephen


pgpRBYfVtnmDb.pgp
Description: OpenPGP digital signature

Bug#960454: chromium: Make Chromium ask before downloading and enabling DRM

[Stephen Kitt]

Hi,

On Fri, 25 Dec 2020 20:50:04 +0100 Michel Le Bihan  wrote:
> With
> https://salsa.debian.org/mimi8/chromium/-/commit/d21192e70824befdfeed5a5145275139cd6c4ffa
> the Widevine component won't be downloaded automatically. However,
> unlike when `enable_widevine=false` is set, Widevine CDM component will
> still be used when found in `~/.config/chromium/WidevineCdm/`. It is
> possibly to copy it there, but there is no nice UI to do that.
> 
> This resolves the policy issue, while still making it possible to use
> that component. This change will be available in the next upload.

Doesn’t this mean though that users who *do* have the CDM component installed
will no longer receive updates to it?

Regards,

Stephen


pgpDwIGuGsQnc.pgp
Description: OpenPGP digital signature

Bug#911587: infnoise: busy-waits, using too much CPU

[Stephen Kitt]

Hi Axel,

On Mon, 28 Dec 2020 09:29:04 +0100, Axel Beckert  wrote:
> Stephen Kitt wrote:
> > Dear Maintainer,  
> 
> You're writing to yourself as "Dear Maintainer"? :-)

I didn’t bother changing the reportbug template, and who knows the maintainer
might not always be me ;-).

> > Version 0.3 of infnoise busy-waits; 0.2.6 didn’t, so this is a
> > regression.  
> 
> Any news on this? I just dist-upgraded a box which has a Infinite
> Noise TRNG connected from Buster to Bullseye and noticed that infnoise
> is gone. That way I stumbled upon this bug report.

I have figured out what was wrong (cue brown paper bag for me), I’ll upload a
fix shortly.

> There seems a new upstream release (0.3.1) at
> https://github.com/13-37-org/infnoise/releases/tag/0.3.1 (but no
> changelog entry for it so far) and 57 more commits to master since
> then:
> 
> https://github.com/13-37-org/infnoise/compare/0.3.1...master
> 
> Not sure if any of these fix this issue.

0.3.1 was already in unstable, but the error came from incomplete build
flags...

> > I’m designating this as serious to prevent 0.3 from migrating to
> > testing.  
> 
> That's nice, but any chance to get infnoise back into testing?

Yup!

Regards,

Stephen


pgpqnVJI1cYEP.pgp
Description: OpenPGP digital signature

Bug#978391: gdb-source no longer ships the gdb source

[Stephen Kitt]

Package: gdb-source
Version: 10.1-1.5
Severity: grave
Justification: renders package unusable

Dear Maintainer,

gdb-source now only contains the following:

/usr/share/doc/gdb-source/NEWS.Debian.gz
/usr/share/doc/gdb-source/changelog.Debian.gz
/usr/share/doc/gdb-source/changelog.gz
/usr/share/doc/gdb-source/copyright

In particular it's missing /usr/src/gdb.tar.*, making it useless.

Regards,

Stephen


-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (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 4.19.0-12-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, 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)

-- no debconf information

Bug#977901: chromium: Inconsistent SEGV

[Boyd Stephen Smith Jr.]

On Wednesday, December 23, 2020 4:30:48 AM CST Boyd Stephen Smith Jr. wrote:
> On Wednesday, December 23, 2020 4:19:43 AM CST Michel Le Bihan wrote:
> > The Debian patch for #963548
> > https://salsa.debian.org/mimi8/chromium/-/blob/ece23b4ca107cd968ac9a40
> > 9f
> > 40eb11edf8a0266/debian/patches/fixes/serviceworker-double-destruction.pat
> > ch is clearly in upstream 87.0.4280.88:
> > https://source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88
> > :c
> > ontent/browser/service_worker/service_worker_container_host.cc;l=671-679
>
> Different destructor.  The old patch is for ServiceWorkerObjectHost, but we
> need a new patch for ServiceWorker*Registration*ObjectHost.

In particular, just above where you linked to, at line 629 (https://
source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88:content/
browser/service_worker/service_worker_container_host.cc;l=629) is the crashing 
line.

The fix for the back trace I finally got is to change that line like so: 
https://source.chromium.org/chromium/chromium/src/+/
f27ad210062f61d06eb782214ee4fc8c19a1725b:content/browser/service_worker/
service_worker_container_host.cc;l=623-647

The f27ed21 commit does contain the fix for #963548, but lower down at line 
689: https://source.chromium.org/chromium/chromium/src/+/
f27ad210062f61d06eb782214ee4fc8c19a1725b:content/browser/service_worker/
service_worker_container_host.cc;l=689-697

-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
Twitter: @DaTwinkDaddy   `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Bug#977901: chromium: Inconsistent SEGV

[Boyd Stephen Smith Jr.]

On Wednesday, December 23, 2020 4:19:43 AM CST Michel Le Bihan wrote:
> The Debian patch for #963548
> https://salsa.debian.org/mimi8/chromium/-/blob/ece23b4ca107cd968ac9a409f
> 40eb11edf8a0266/debian/patches/fixes/serviceworker-double-destruction.patch
> is clearly in upstream 87.0.4280.88:
> https://source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88:c
> ontent/browser/service_worker/service_worker_container_host.cc;l=671-679

Different destructor.  The old patch is for ServiceWorkerObjectHost, but we 
need a new patch for ServiceWorker*Registration*ObjectHost.

> I also think that it might be an upstream bug, but can't confirm unless
> tested and reproducible in Google Chrome.

https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 is originally 
reported against *Chrome* 87.0.4278.0
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
Twitter: @DaTwinkDaddy   `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Bug#977901: Similarities to 963548

[Boyd Stephen Smith Jr.]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963548 also has a fix 
(https://salsa.debian.org/chromium-team/chromium/-/commit/
b904fa41d40b967dcc8f6984db52f7a2f6a2c83d) related to the cyclic 
SerivceWorker.*ObjectHost objects and their deletion.

The chromium team noticed the same thing: https://bugs.chromium.org/p/
chromium/issues/detail?id=1135070#c15 (in the other direction)

It's been an Chromium issue for a while with no clear fix on how to handle 
cyclic service dependencies in general: https://bugs.chromium.org/p/chromium/
issues/detail?id=1135070#c18
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
Twitter: @DaTwinkDaddy   `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Bug#977901: chromium: Inconsistent SEGV

[Boyd Stephen Smith Jr.]

On Wednesday, December 23, 2020 3:49:06 AM CST Boyd Stephen Smith Jr. wrote:
> On Wednesday, December 23, 2020 2:38:32 AM CST Boyd Stephen Smith Jr. wrote:
> > I got a crash (attached)
> 
> Looks like https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 to
> me, which has a fix, but I haven't yet figured out what release(s) the fix
> made it into.

Doesn't look to me like it has made it into a release at all, but I'm just 
using the Git tools to navigate the repository, not all the depot tools.

---8<---
bss@monster % git tag -l --contains f27ad210062f61d06eb782214ee4fc8c19a1725b
bss@monster % git branch -r --contains 
f27ad210062f61d06eb782214ee4fc8c19a1725b --list
  origin/HEAD -> origin/master
  origin/lkgr
  origin/lkgr-android-internal
  origin/lkgr-ios-internal
  origin/master
--->8---

So, I guess it's an "upstream" bug?
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
Twitter: @DaTwinkDaddy   `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Bug#977901: chromium: Inconsistent SEGV

[Boyd Stephen Smith Jr.]

On Wednesday, December 23, 2020 2:38:32 AM CST Boyd Stephen Smith Jr. wrote:
> I got a crash (attached)

Looks like https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 to 
me, which has a fix, but I haven't yet figured out what release(s) the fix 
made it into.

-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
Twitter: @DaTwinkDaddy   `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Bug#977901: chromium: Inconsistent SEGV

[Boyd Stephen Smith Jr.]

On Tuesday, December 22, 2020 11:22:21 PM CST Boyd Stephen Smith Jr. wrote:
> I'll have to play around with disabling extensions to see which one(s) cause
> a crash within 30 minutes.  Super annoying since I do use every one of them
> literally every day. :(

Looks like maybe Proxy SwitchyOmega (which is thankfully open source).  Things 
had been going fine under the debugger for hours with no extensions, and then 
I got a crash (attached) within minutes of enabling it.

Unfortunately, I need this extension enabled in order to access client network 
websites behind a proxy server behind a VPN.  So, I'm not sure what I can do 
(or if I can even reproduce the error).

-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
Twitter: @DaTwinkDaddy   `-'(. .)`-'
http://iguanasuicide.net/\_/
Thread 1 "chromium" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x73857537 in __GI_abort () at abort.c:79
#2  0x5a982805 in base::debug::BreakDebugger() ()
#3  0x5a909ed6 in logging::LogMessage::~LogMessage() ()
#4  0x5a90a24e in logging::LogMessage::~LogMessage() ()
#5  0x5a90bc4a in base::subtle::RefCountedBase::ReleaseImpl() const ()
#6  0x5930078b in 
content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost()
 ()
#7  0x593007ce in 
content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost()
 ()
#8  0x58821ca7 in std::_Rb_tree > >, 
std::_Select1st > > >, std::less, std::allocator > > > 
>::_M_erase(std::_Rb_tree_node > > >*) ()
#9  0x592a97c3 in 
content::ServiceWorkerContainerHost::~ServiceWorkerContainerHost() ()
#10 0x592dfd99 in content::ServiceWorkerHost::~ServiceWorkerHost() ()
#11 0x5932f921 in 
content::ServiceWorkerVersion::~ServiceWorkerVersion() ()
#12 0x5932fbde in 
content::ServiceWorkerVersion::~ServiceWorkerVersion() ()
#13 0x592fc847 in 
content::ServiceWorkerRegistration::~ServiceWorkerRegistration() ()
#14 0x592fc89e in 
content::ServiceWorkerRegistration::~ServiceWorkerRegistration() ()
#15 0x593007a0 in 
content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost()
 ()
#16 0x593007ce in 
content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost()
 ()
#17 0x58821ca7 in std::_Rb_tree > >, 
std::_Select1st > > >, std::less, std::allocator > > > 
>::_M_erase(std::_Rb_tree_node > > >*) ()
#18 0x58b98403 in std::_Rb_tree > >, 
std::_Select1st > > >, std::less, std::allocator > > > 
>::_M_erase_aux(std::_Rb_tree_const_iterator > > >, 
std::_Rb_tree_const_iterator > > >) ()
#19 0x58f36e3c in 
mojo::ReceiverSetBase >, 
void>::OnDisconnect(unsigned long, unsigned int, 
std::__cxx11::basic_string, std::allocator > 
const&) ()
#20 0x5af13f9f in 
mojo::InterfaceEndpointClient::NotifyError(base::Optional
 const&) ()
#21 0x5af1a5a7 in 
mojo::internal::MultiplexRouter::ProcessNotifyErrorTask(mojo::internal::MultiplexRouter::Task*,
 mojo::internal::MultiplexRouter::ClientCallBehavior, 
base::SequencedTaskRunner*) ()
#22 0x5af188b9 in 
mojo::internal::MultiplexRouter::ProcessTasks(mojo::internal::MultiplexRouter::ClientCallBehavior,
 base::SequencedTaskRunner*) ()
#23 0x5af1770e in 
mojo::internal::MultiplexRouter::OnPipeConnectionError(bool) ()
#24 0x5af11128 in mojo::Connector::HandleError(bool, bool) ()
#25 0x5af2aebe in mojo::SimpleWatcher::OnHandleReady(int, unsigned int, 
mojo::HandleSignalsState const&) ()
#26 0x5af2b336 in 
base::internal::Invoker, int, unsigned int, 
mojo::HandleSignalsState>, void ()>::RunOnce(base::internal::BindStateBase*) ()
#27 0x5a9497d4 in base::TaskAnnotator::RunTask(char const*, 
base::PendingTask*) ()
#28 0x5a959aa9 in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*)
 ()
#29 0x5a9597ac in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() 
()
#30 0x5a90d8da in 
base::MessagePumpGlib::Run(base::MessagePump::Delegate*) ()
#31 0x5a95a10d in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool,
 base::TimeDelta) ()
#32 0x5a9301a0 in base::RunLoop::Run() ()
#33 0x5aae564c in ChromeBrowserMainParts::MainMessageLoopRun(int*) ()
#34 0x58ecb8a2 in content::BrowserMainLoop::RunMainMessageLoopParts() ()
#35 0

Bug#977901: chromium: Inconsistent SEGV

[Boyd Stephen Smith Jr.]

On Tuesday, December 22, 2020 10:47:31 PM CST Boyd Stephen Smith Jr. wrote:
> All my extensions were pulled down during the Google Sync and ran fine on 87
> for roughly an hour -- that's twice as long as my longest browser session
> for version 87 on the old profile.
> 
> I still convinced this is a bug -- nothing in my profile should cause a
> SEGV, ref_count violation, or corrupted double-linked list.  But, there's
> at least a workaround, that I'm going to take advantage of, to create a
> new, blank profile and either sync or manually import (or likely a
> combination of both) all your settings into the new profile.

So, it seems one of the _settings_ of one of my extensions is causing the 
problem.  Restored my _settings_ (same list of extensions), and got a crash in 
10 minutes.

*That* is annoying, but not a chromium bug.  Feel free to close this at your 
leisure.

I'll have to play around with disabling extensions to see which one(s) cause a 
crash within 30 minutes.  Super annoying since I do use every one of them 
literally every day. :(
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
Twitter: @DaTwinkDaddy   `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Bug#977901: chromium: Inconsistent SEGV

[Boyd Stephen Smith Jr.]

On Tuesday, December 22, 2020 5:26:04 PM CST Boyd Stephen Smith Jr. wrote:
> On Tue, 22 Dec 2020 23:43:23 +0100 Michel Le Bihan  
wrote:
> > I was not able to reproduce those crashes.
> 
> That's unfortunate.  I'm up to 50 just today.  I'm probably going to have to
> downgrade to 83 at least until there's another update.

Downgrading was a mixed bag (browser was stable, but audio/video stopped 
working (!)) .  So, I tried again with 87.

Rather than just disabling my extensions, I tried from a brand-new profile and 
an empty cache.  So far, I'm not able to reproduce the crashing on the new 
profile.

Unfortunately, I have about a half-dozen extensions that have at least some 
configuration that isn't synchronized anywhere else, so I need to go back to 
83 and the old profile, dump/export/backup all their settings to a file (or 
take notes), then go back to 87 and the new profile and restore/import/apply 
all those settings in the new profile.

All my extensions were pulled down during the Google Sync and ran fine on 87 
for roughly an hour -- that's twice as long as my longest browser session for 
version 87 on the old profile.

I still convinced this is a bug -- nothing in my profile should cause a SEGV, 
ref_count violation, or corrupted double-linked list.  But, there's at least a 
workaround, that I'm going to take advantage of, to create a new, blank 
profile and either sync or manually import (or likely a combination of both) 
all your settings into the new profile.

It's not going to be a kind experience for people upgrading from buster to 
bullseye, especially since the crashes make it hard to export settings from 
your old profile.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
Twitter: @DaTwinkDaddy   `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Bug#977901: chromium: Inconsistent SEGV

[Boyd Stephen Smith Jr.]

On Tue, 22 Dec 2020 23:43:23 +0100 Michel Le Bihan  wrote:
> Installing `chromium-dbgsym` should be enough. Please run Chromium with
> the `--debug` flag like: `chromium --debug`.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963711#10

Chromium crashes on startup if I use the "-g" or "--debug" options.  After I 
issue a "run" at the "(gdb)" prompt, there's some time (a few seconds), but I 
never get a GUI window and then it crashes.  I do get a usable back trace for 
the crash on startup, which I added to that bug.

> I was not able to reproduce those crashes.

That's unfortunate.  I'm up to 50 just today.  I'm probably going to have to 
downgrade to 83 at least until there's another update.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
Twitter: @DaTwinkDaddy   `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Bug#976492: marked as pending in bochs

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #976492 in bochs reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/bochs/-/commit/acaf70cc296a979fb08dfa105f46e93db052cb15


Use cross-binutils tools when building rombios32

Closes: #976492


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/976492

Bug#975492: scummvm: FTBFS on big-endian platforms

[Stephen Kitt]

Package: scummvm
Version: 2.2.0+dfsg1-1
Severity: serious
Tags: upstream
Justification: ftbfs

Dear Maintainer,

On big-endian platforms, test/engines/ultima/ultima8/misc/memset_n.h
fails because the memset_n functions assume they're running on a
little-endian platform. On a big-endian platform, the value written to
memory will depend on the alignment: if the value is aligned, it will
be written as expected (MSB first), but if it's not aligned, it will
be written in a mixture of little- and big-endian. The tests always
use the host memory order.

Regards,

Stephen


-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (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 4.19.0-12-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)

Versions of packages scummvm depends on:
ii  libasound2   1.1.8-1
ii  libc62.28-10
ii  libfaad2 2.8.8-3
ii  libflac8 1.3.2-3
ii  libfluidsynth1   1.1.11-1
ii  libfreetype6 2.9.1-3+deb10u2
ii  libgcc1  1:8.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libmad0  0.15.1b-10
ii  libmpeg2-4   0.5.1-8
ii  libogg0  1.3.2-1+b1
ii  libpng16-16  1.6.36-6
ii  libsdl2-2.0-02.0.9+dfsg1-1
ii  libsndio7.0  1.5.0-3
ii  libstdc++6   8.3.0-6
ii  libtheora0   1.1.1+dfsg.1-15
ii  libvorbis0a  1.3.6-2
ii  libvorbisfile3   1.3.6-2
ii  scummvm-data 2.0.0+dfsg-2
ii  zlib1g   1:1.2.11.dfsg-1

scummvm recommends no packages.

Versions of packages scummvm suggests:
ii  beneath-a-steel-sky 0.0372-7
ii  drascula1.0+ds3-1
ii  flight-of-the-amazon-queen  1.0.0-8
ii  fluidsynth  1.1.11-1
ii  lure-of-the-temptress   1.1+ds2-3
ii  timidity2.14.0-8

-- no debconf information

Bug#972394: likely cause: Python.h not found because of version mismatch 3.8 vs 3.9

[Stephen Sinclair]

On Wed, Oct 21, 2020 at 10:39 AM Adrian Bunk  wrote:
>
> Control: retitle -1 siconos FTBFS with more than one supported python3 version
>
> On Mon, Oct 19, 2020 at 11:38:42PM +0200, Markus Koschany wrote:
> >
> > I built siconos in a clean chroot environment. The recent rebuild of
> > siconos also shows build failures
> >
> > https://buildd.debian.org/status/package.php?p=siconos
> >
> > I don't think it's specific to my environment.
>
> You need something like python3-dev -> python3-all-dev in the build
> dependencies.

I can confirm that making this change allows the package to build.
However, some Python-related tests in autopkgtest fail when trying to
import the Siconos python modules, so something still needs to be
fixed.  I will investigate.
As for this change, however, is it the correct one to make?  Or should
I wait for more information in #972551?

> The next problem is what it builds - it then builds for the highest
> version only, not for the default version.

Can I ask how you determined this?  It is not surprising that
something could be wrong, as the CMake configuration is very
complicated in this package.
However, the configure step includes the line,

-DPYTHON_EXECUTABLE=$(shell which python3)"

which should specify the path to the default Python interpreter.  Is
there a better way to determine this path?

> This bug could be solved by either adjusting the build dependencies
> and the build to build for all supported python3 versions, or by fixing
> whatever in the build system does not use the default version.

I would prefer the latter as the package is already quite complicated
and does not play well with multiple pythons.

regards,
Steve

Bug#970820: marked as pending in intelrdfpmath

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #970820 in intelrdfpmath reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/intelrdfpmath/-/commit/f86e86a1611e559b78729710026f4c31f094697e


Install bid_functions.h

Closes: #970820


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/970820

Bug#971161: marked as pending in evemu

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #971161 in evemu reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/evemu/-/commit/6d2c7d8f3ba19cef2570fd2d4e2df06cacd87d5c


Apply upstream fix for the tests

Closes: #971161


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/971161

Bug#969260: closed by Debian FTP Masters (reply to Stephen Kitt ) (Bug#969260: fixed in openjfx 11.0.7+0-5~exp1)

[Stephen Kitt]

Hi Tony,

Le 21/09/2020 15:53, tony mancill a écrit :
On Mon, Sep 21, 2020 at 08:39:07AM +, Debian Bug Tracking System 
wrote:

This is an automatic notification regarding your Bug report
which was filed against the src:openjfx package:

#969260: openfjx: FTBFS (gstreamer)

It has been closed by Debian FTP Masters 
 (reply to Stephen Kitt 
).


Thank you for resolving the build issue with openjfx.

I didn't notice that GSTREAMER_LITE was defined for the autobuilders 
but

not being defined when I built the package locally (which never failed,
which made this more difficult to diagnose).

Do you know why the defines would be different in two different clean
sid chroots?  Maybe something with how gstreamer (transitive) 
dependencies are

provided?  I'd like local sbuild chroots to be as representative of the
autobuilder environments as possible.


It’s something to do with arch-specific builds; I reproduced the issue 
with


pdebuild -- --binary-arch

I didn’t spend much time trying to figure out what the difference was...


P.S.  I pushed another commit to undo the change I made to
NUM_COMPILE_THREADS in -4.  This was one of the few differences I could
see between my build environment and the autobuilders, but was a
red-herring.


I wondered about that, I didn’t try reverting it.

Regards,

Stephen

Bug#967157: libglade2: diff for NMU version 1:2.6.4-2.1

[Stephen Kitt]

On Tue, 4 Aug 2020 20:24:40 +0200, Stephen Kitt  wrote:
> I've prepared an NMU for libglade2 (versioned as 1:2.6.4-2.1) and
> uploaded it to the archive. It fixes #967157, #936867, and #880437.

Except not, because I forgot to update my key in the keyring and it’s
expired. Ho hum...

Regards,

Stephen


pgp3zKOEmtpcY.pgp
Description: OpenPGP digital signature

Bug#967157: libglade2: diff for NMU version 1:2.6.4-2.1

[Stephen Kitt]

Package: libglade2
Version: 1:2.6.4-2
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for libglade2 (versioned as 1:2.6.4-2.1) and
uploaded it to the archive. It fixes #967157, #936867, and #880437.

Regards,

Stephen
diff -Nru libglade2-2.6.4/debian/changelog libglade2-2.6.4/debian/changelog
--- libglade2-2.6.4/debian/changelog	2013-12-26 15:07:02.0 +0100
+++ libglade2-2.6.4/debian/changelog	2020-08-04 12:09:22.0 +0200
@@ -1,3 +1,13 @@
+libglade2 (1:2.6.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove Andreas Rottmann from the uploaders; thanks for your work on
+this package! Closes: #880437.
+  * Stop shipping libglade-convert, which is obsolete and the only
+reason libglade2 involves Python. Closes: #936867, #967157.
+
+ -- Stephen Kitt   Tue, 04 Aug 2020 12:09:22 +0200
+
 libglade2 (1:2.6.4-2) unstable; urgency=low
 
   [ Emilio Pozuelo Monfort ]
diff -Nru libglade2-2.6.4/debian/control libglade2-2.6.4/debian/control
--- libglade2-2.6.4/debian/control	2013-12-26 15:29:58.0 +0100
+++ libglade2-2.6.4/debian/control	2020-08-04 12:09:22.0 +0200
@@ -1,20 +1,18 @@
 # This file is autogenerated. DO NOT EDIT!
-# 
+#
 # Modifications should be made to debian/control.in instead.
 # This file is regenerated automatically in the clean target.
-
 Source: libglade2
 Section: devel
 Priority: optional
-Maintainer: Andreas Rottmann 
-Uploaders: Debian GNOME Maintainers , Josselin Mouette , Loic Minier , Sebastian Dröge 
+Maintainer: Debian GNOME Maintainers 
+Uploaders: Josselin Mouette , Sebastian Dröge 
 Standards-Version: 3.9.4
 Build-Depends: cdbs (>= 0.4.93~),
debhelper (>= 9),
dh-autoreconf,
libgtk2.0-dev (>= 2.6.0),
libglib2.0-dev (>= 2.10.0),
-   python (>= 2.0),
libxml2-dev (>= 2.4.10),
libatk1.0-dev (>= 1.9.0),
zlib1g-dev,
@@ -45,8 +43,7 @@
 Depends: ${misc:Depends},
  libglade2-0 (= ${binary:Version}),
  libgtk2.0-dev (>= 2.0.6),
- libxml2-dev,
- python:any (>= 2.0)
+ libxml2-dev
 Replaces: libglade2-0 (<< 2.0.1-10)
 Suggests: glade | glade-gnome
 Description: development files for libglade
diff -Nru libglade2-2.6.4/debian/control.in libglade2-2.6.4/debian/control.in
--- libglade2-2.6.4/debian/control.in	2013-12-26 15:07:02.0 +0100
+++ libglade2-2.6.4/debian/control.in	2020-08-04 12:09:22.0 +0200
@@ -1,7 +1,7 @@
 Source: libglade2
 Section: devel
 Priority: optional
-Maintainer: Andreas Rottmann 
+Maintainer: Debian GNOME Maintainers 
 Uploaders: @GNOME_TEAM@
 Standards-Version: 3.9.4
 Build-Depends: cdbs (>= 0.4.93~),
@@ -9,7 +9,6 @@
dh-autoreconf,
libgtk2.0-dev (>= 2.6.0),
libglib2.0-dev (>= 2.10.0),
-   python (>= 2.0),
libxml2-dev (>= 2.4.10),
libatk1.0-dev (>= 1.9.0),
zlib1g-dev,
@@ -40,8 +39,7 @@
 Depends: ${misc:Depends},
  libglade2-0 (= ${binary:Version}),
  libgtk2.0-dev (>= 2.0.6),
- libxml2-dev,
- python:any (>= 2.0)
+ libxml2-dev
 Replaces: libglade2-0 (<< 2.0.1-10)
 Suggests: glade | glade-gnome
 Description: development files for libglade
diff -Nru libglade2-2.6.4/debian/libglade2-dev.install libglade2-2.6.4/debian/libglade2-dev.install
--- libglade2-2.6.4/debian/libglade2-dev.install	2013-12-26 15:07:02.0 +0100
+++ libglade2-2.6.4/debian/libglade2-dev.install	2020-08-04 12:09:22.0 +0200
@@ -1,5 +1,4 @@
 usr/include
 usr/lib/*/libglade-2.0.{a,so}
 usr/lib/*/pkgconfig
-usr/bin
 usr/share/gtk-doc
diff -Nru libglade2-2.6.4/debian/libglade2-dev.manpages libglade2-2.6.4/debian/libglade2-dev.manpages
--- libglade2-2.6.4/debian/libglade2-dev.manpages	2005-04-10 17:28:57.0 +0200
+++ libglade2-2.6.4/debian/libglade2-dev.manpages	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-debian/libglade-convert.1
diff -Nru libglade2-2.6.4/debian/libglade-convert.1 libglade2-2.6.4/debian/libglade-convert.1
--- libglade2-2.6.4/debian/libglade-convert.1	2005-04-10 17:28:57.0 +0200
+++ libglade2-2.6.4/debian/libglade-convert.1	1970-01-01 01:00:00.0 +0100
@@ -1,44 +0,0 @@
-.TH "libglade-convert" "1" "February 8, 2005" "Margarita Manterola" ""
-.SH "NAME"
-libglade-convert - Utility to convert old .glade files into new ones.
-
-.SH "SYNOPSIS"
-.B libglade-convert 
-.RB "[ " --no-upgrade " ] "
-.RB "[ " --verbose " ] "
-.I oldfile.glade
-
-.SH "DESCRIPTION"
-.B libglade-convert
-is a small Python script used to convert old .glade to the new format.
-The converted file is written to standard output.
-
-Usage example:
-.br
-.B libglade-convert gnu.glade > gnu2.glade
-
-.S

Bug#966188: d2x-rebirth: diff for NMU version 0.58.1-1.3

[Stephen Kitt]

Control: tags 966188 + patch
Control: tags 966188 + pending

Dear maintainer,

I've prepared an NMU for d2x-rebirth (versioned as 0.58.1-1.3) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

Stephen
diff -Nru d2x-rebirth-0.58.1/debian/changelog d2x-rebirth-0.58.1/debian/changelog
--- d2x-rebirth-0.58.1/debian/changelog	2020-02-02 18:18:43.0 +0100
+++ d2x-rebirth-0.58.1/debian/changelog	2020-08-02 11:43:10.0 +0200
@@ -1,3 +1,11 @@
+d2x-rebirth (0.58.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Avoid defining objects twice; this allows building with GCC 10.
+Closes: #966188.
+
+ -- Stephen Kitt   Sun, 02 Aug 2020 11:43:10 +0200
+
 d2x-rebirth (0.58.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru d2x-rebirth-0.58.1/debian/patches/common-objects.patch d2x-rebirth-0.58.1/debian/patches/common-objects.patch
--- d2x-rebirth-0.58.1/debian/patches/common-objects.patch	1970-01-01 01:00:00.0 +0100
+++ d2x-rebirth-0.58.1/debian/patches/common-objects.patch	2020-08-02 11:42:09.0 +0200
@@ -0,0 +1,16 @@
+Description: Avoid defining objects twice
+Author: Stephen Kitt 
+
+This allows building with -fno-common (the GCC 10 default).
+
+--- a/texmap/ntmap.c
 b/texmap/ntmap.c
+@@ -55,7 +55,7 @@
+ int Lighting_on=1;  // initialize to no lighting
+ int	Tmap_flat_flag = 0;		//	1 = render texture maps as flat shaded polygons.
+ int	Current_seg_depth;		// HACK INTERFACE: how far away the current segment (& thus texture) is
+-int	Max_perspective_depth;
++extern int	Max_perspective_depth;
+ int	Max_flat_depth;
+ 
+ // These variables are the interface to assembler.  They get set for each texture map, which is a real waste of time.
diff -Nru d2x-rebirth-0.58.1/debian/patches/series d2x-rebirth-0.58.1/debian/patches/series
--- d2x-rebirth-0.58.1/debian/patches/series	2020-02-02 18:17:06.0 +0100
+++ d2x-rebirth-0.58.1/debian/patches/series	2020-08-02 11:43:10.0 +0200
@@ -3,3 +3,4 @@
 spelling.patch
 libphysfs-3.0.1.patch
 python3.patch
+common-objects.patch


signature.asc
Description: PGP signature

Bug#966187: d1x-rebirth: diff for NMU version 0.58.1-1.2

[Stephen Kitt]

Control: tags 966187 + patch
Control: tags 966187 + pending

Dear maintainer,

I've prepared an NMU for d1x-rebirth (versioned as 0.58.1-1.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

Stephen
diff -Nru d1x-rebirth-0.58.1/debian/changelog d1x-rebirth-0.58.1/debian/changelog
--- d1x-rebirth-0.58.1/debian/changelog	2020-02-01 16:24:25.0 +0100
+++ d1x-rebirth-0.58.1/debian/changelog	2020-08-02 11:16:13.0 +0200
@@ -1,3 +1,11 @@
+d1x-rebirth (0.58.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Avoid defining objects twice; this allows building with GCC 10.
+Closes: #966187.
+
+ -- Stephen Kitt   Sun, 02 Aug 2020 11:16:13 +0200
+
 d1x-rebirth (0.58.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru d1x-rebirth-0.58.1/debian/patches/common-objects.patch d1x-rebirth-0.58.1/debian/patches/common-objects.patch
--- d1x-rebirth-0.58.1/debian/patches/common-objects.patch	1970-01-01 01:00:00.0 +0100
+++ d1x-rebirth-0.58.1/debian/patches/common-objects.patch	2020-08-02 11:16:04.0 +0200
@@ -0,0 +1,27 @@
+Description: Avoid defining objects twice
+Author: Stephen Kitt 
+
+This allows building with -fno-common (the GCC 10 default).
+
+--- a/main/multi.h
 b/main/multi.h
+@@ -181,7 +181,7 @@
+ #define MULTI_GAME_TYPE_COUNT	8
+ #define MULTI_GAME_NAME_LENGTH	13
+ #define MULTI_ALLOW_POWERUP_MAX 12
+-int multi_allow_powerup_mask[MAX_POWERUP_TYPES];
++extern int multi_allow_powerup_mask[MAX_POWERUP_TYPES];
+ extern char *multi_allow_powerup_text[MULTI_ALLOW_POWERUP_MAX];
+ extern const char GMNames[MULTI_GAME_TYPE_COUNT][MULTI_GAME_NAME_LENGTH];
+ extern const char GMNamesShrt[MULTI_GAME_TYPE_COUNT][8];
+--- a/texmap/ntmap.c
 b/texmap/ntmap.c
+@@ -55,7 +55,7 @@
+ int Lighting_on=1;  // initialize to no lighting
+ int	Tmap_flat_flag = 0;		//	1 = render texture maps as flat shaded polygons.
+ int	Current_seg_depth;		// HACK INTERFACE: how far away the current segment (& thus texture) is
+-int	Max_perspective_depth;
++extern int	Max_perspective_depth;
+ int	Max_flat_depth;
+ 
+ // These variables are the interface to assembler.  They get set for each texture map, which is a real waste of time.
diff -Nru d1x-rebirth-0.58.1/debian/patches/series d1x-rebirth-0.58.1/debian/patches/series
--- d1x-rebirth-0.58.1/debian/patches/series	2020-02-01 15:03:06.0 +0100
+++ d1x-rebirth-0.58.1/debian/patches/series	2020-08-02 11:13:04.0 +0200
@@ -1,3 +1,4 @@
 debian.patch
 spelling.patch
 python3.patch
+common-objects.patch


signature.asc
Description: PGP signature

Bug#966063: marked as pending in rocksndiamonds

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #966063 in rocksndiamonds reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/rocksndiamonds/-/commit/6362b584c00f59eda064b13cb28bdbb9194f98dd


Avoid multiple definitions, to allow building with -fno-common

Closes: #966063


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/966063

Bug#964742: src:binutils-mingw-w64: FTBFS on s390x: FAIL: objcopy executable (pr25662)

[Stephen Kitt]

Package: src:binutils-mingw-w64
Version: 8.10
Severity: serious
Justification: ftbfs

Dear Maintainer,

binutils-mingw-w64 FTBFS on s390x and other big-endian architectures;
the test suite fails with

FAIL: objcopy executable (pr25662)

Regards,

The Maintainer

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (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

Kernel: Linux 4.19.0-9-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)

Bug#964293: hubicfuse: error while loading libssl.so.1.0.0

[Stephen Kitt]

Control: tag -1 + stretch
Control: fixed -1 3.0.1-1

On Sun, 5 Jul 2020 11:51:43 +0200, Stephen Kitt  wrote:
> On Sun, 05 Jul 2020 11:42:08 +0200, rpnpif  wrote:
> > The command hubicfuse /mnt/hubic -o noauto_cache,sync_read
> > get the result :
> > hubicfuse: error while loading shared libraries: libssl.so.1.0.0: cannot
> > open shared object file: No such file or directory
> > 
> > but libssl1.1 was needed.  
> 
> What does
> 
>   command -v hubicfuse
> 
> show?

Also, do you have libssl1.0.2 installed? libcurl3 depends on it in Stretch so
it should be available if you have hubicfuse installed...

Regards,

Stephen


pgpOl8PDXk0ws.pgp
Description: OpenPGP digital signature

Bug#964293: hubicfuse: error while loading libssl.so.1.0.0

[Stephen Kitt]

Hi,

On Sun, 05 Jul 2020 11:42:08 +0200, rpnpif  wrote:
> The command hubicfuse /mnt/hubic -o noauto_cache,sync_read
> get the result :
> hubicfuse: error while loading shared libraries: libssl.so.1.0.0: cannot
> open shared object file: No such file or directory
> 
> but libssl1.1 was needed.

What does

command -v hubicfuse

show?

Regards,

Stephen


pgpMaNyzVoDm6.pgp
Description: OpenPGP digital signature

Bug#962518: cegui-mk2 FTBFS on mipsel/mips64el: symbol differences

[Stephen Kitt]

On Wed, 10 Jun 2020 13:53:58 +0200, Stephen Kitt  wrote:
> On Tue, 9 Jun 2020 21:08:25 +0100, Simon McVittie  wrote:
> > On Tue, 09 Jun 2020 at 15:21:37 -0400, Olek Wojnar wrote:  
> > > On Tue, Jun 9, 2020 at 6:12 AM Adrian Bunk <[1]b...@debian.org>
> > > wrote:
> > > > I wonder if the real fix shouldn't be for cegui-mk2 to stop
> > > > exporting a
> > > pile
> > > > of Boost symbols...
> > > 
> > > 
> > > I would love that. Any advice on a reasonably easy/straightforward way
> > > of doing that?
> > 
> > *If* your upstream is on board with this, my understanding is that
> > the main way to do this is to build with -fvisibility=hidden,
> > and decorate each intentionally-public class/function/thing
> > with a macro that (when building with gcc or clang) expands to
> > __attribute__((__visibility__("hidden"))).
> > 
> > Some upstreams will be doing something similar already, because they are
> > portable to Windows and need to decorate public symbols with
> > __declspec(dllexport) on Windows.  
> 
> See
> https://salsa.debian.org/debian/fcml/-/blob/master/debian/patches/visibility.patch
> for a quick-and-dirty example of both of these approaches (and
> https://salsa.debian.org/debian/fcml/-/commit/22d753b1c820ea339b6b52cbc1cdf6e05229fbf9#34a4bacbb5ecf973fa5f481819228c77da389f43
> for the resulting symbols file simplification).

I’ve looked into the cegui-mk2 situation a bit more. It turns out that the
project itself does define its exported symbols, and that can be used to
built a library with no extraneous symbols:

* add -fvisibility=hidden to the CXXFLAGS (or use the CMake hidden symbol
  support, which I think is available);
* patch the headers define the various export macros, e.g. CEGUIEXPORT in
  cegui/include/CEGUI/Base.h (taking care to match the EXPORTS handling, same
  as the Windows code).

This greatly reduces the number of exported symbols:

 debian/libcegui-mk2-0.8.7.symbols | 7477
 
+++--
 1 file changed, 577 insertions(+), 6900 deletions(-)

However it also breaks dh_dwz.

This still leaves all the bitness variation (armel/armhf/i386 etc. v.
amd64/arm64 etc., which could be better handled with arch-bits), and the
changes from GCC 9 to 10. Those are annoying enough that I suspect it’s
simply not worth dealing with a symbols file, as others have said.

However I do think that controlling the symbols’ visibility would be a good
thing, but that should be dealt with upstream.

Regards,

Stephen


pgp88v71CcYus.pgp
Description: OpenPGP digital signature

Bug#962518: cegui-mk2 FTBFS on mipsel/mips64el: symbol differences

[Stephen Kitt]

On Tue, 9 Jun 2020 21:08:25 +0100, Simon McVittie  wrote:
> On Tue, 09 Jun 2020 at 15:21:37 -0400, Olek Wojnar wrote:
> > On Tue, Jun 9, 2020 at 6:12 AM Adrian Bunk <[1]b...@debian.org> wrote:  
> > > I wonder if the real fix shouldn't be for cegui-mk2 to stop
> > > exporting a  
> > pile  
> > > of Boost symbols...  
> > 
> > 
> > I would love that. Any advice on a reasonably easy/straightforward way of
> > doing that?  
> 
> *If* your upstream is on board with this, my understanding is that
> the main way to do this is to build with -fvisibility=hidden,
> and decorate each intentionally-public class/function/thing
> with a macro that (when building with gcc or clang) expands to
> __attribute__((__visibility__("hidden"))).
> 
> Some upstreams will be doing something similar already, because they are
> portable to Windows and need to decorate public symbols with
> __declspec(dllexport) on Windows.

See
https://salsa.debian.org/debian/fcml/-/blob/master/debian/patches/visibility.patch
for a quick-and-dirty example of both of these approaches (and
https://salsa.debian.org/debian/fcml/-/commit/22d753b1c820ea339b6b52cbc1cdf6e05229fbf9#34a4bacbb5ecf973fa5f481819228c77da389f43
for the resulting symbols file simplification).

Regards,

Stephen


pgpk2c5j6uPEd.pgp
Description: OpenPGP digital signature

Bug#962518: cegui-mk2 FTBFS on mipsel/mips64el: symbol differences

[Stephen Kitt]

Le 09/06/2020 09:59, Adrian Bunk a écrit :

https://buildd.debian.org/status/package.php?p=cegui-mk2

...
dpkg-gensymbols: warning: some new symbols appeared in the symbols
file: see diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libcegui-mk2-0.8.7/DEBIAN/symbols
doesn't match completely debian/libcegui-mk2-0.8.7.symbols


[...]


Fix:


I wonder if the real fix shouldn't be for cegui-mk2 to stop exporting a 
pile of Boost symbols...


Regards,

Stephen

Bug#961120: nulib2 ftbfs on s390x (failing tests), built before

[Stephen Kitt]

Le 20/05/2020 13:02, Matthias Klose a écrit :

nulib2 ftbfs on s390x (failing tests), built before:


Thanks, the tests fail on all 64-bit big-endian platforms:

ERROR: kNuAttrNumRecords 12884901888 vs 3

12884901888 is 0x3 ;-).

I’ll look into it...

Regards,

Stephen

Bug#959647: lasagne: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

[Stephen Sinclair]

I am confused.  This bug is filed against
0.1+git20200419.5d3c63c+ds-1, which contains a patch for this exact
problem, but the build logs indicate that the previous version,
0.1+git20181019.a61b76f-2, is being built.

Steve

Bug#959137: lasagne: (autopkgtest) needs update for new version of numpy: 'numpy.float64' object cannot be interpreted as an integer

[Stephen Sinclair]

The package has been updated in salsa and is awaiting sponsorship.

regards,
Steve

On Wed, Apr 29, 2020 at 9:48 PM Paul Gevers  wrote:
>
> Source: lasagne
> Version: 0.1+git20181019.a61b76f-2
> Severity: serious
> X-Debbugs-CC: debian...@lists.debian.org, nu...@packages.debian.org
> Tags: sid bullseye
> User: debian...@lists.debian.org
> Usertags: needs-update
> Control: affects -1 src:numpy
>
> Dear maintainer(s),
>
> With a recent upload of numpy the autopkgtest of lasagne fails in
> testing when that autopkgtest is run with the binary packages of numpy
> from unstable. It passes when run with only packages from testing. In
> tabular form:
>
>passfail
> numpy  from testing1:1.18.3-1
> lasagnefrom testing0.1+git20181019.a61b76f-2
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report.
>
> Currently this regression is blocking the migration of numpy to testing
> [1]. Of course, numpy shouldn't just break your autopkgtest (or even
> worse, your package), but it seems to me that the change in numpy was
> intended and your package needs to update to the new situation.
>
> If this is a real problem in your package (and not only in your
> autopkgtest), the right binary package(s) from numpy should really add a
> versioned Breaks on the unfixed version of (one of your) package(s).
> Note: the Breaks is nice even if the issue is only in the autopkgtest as
> it helps the migration software to figure out the right versions to
> combine in the tests.
>
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [1] https://qa.debian.org/excuses.php?package=numpy
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/l/lasagne/5197094/log.gz
>
> === FAILURES
> ===
> 
> TestTPSTransformLayer.test_transform_thin_plate_spline_variable_input _
>
> start = -1, stop = 1, num = 4.0, endpoint = True, retstep = False, dtype
> = None
> axis = 0
>
> @array_function_dispatch(_linspace_dispatcher)
> def linspace(start, stop, num=50, endpoint=True, retstep=False,
> dtype=None,
>  axis=0):
> """
> Return evenly spaced numbers over a specified interval.
>
> Returns `num` evenly spaced samples, calculated over the
> interval [`start`, `stop`].
>
> The endpoint of the interval can optionally be excluded.
>
> .. versionchanged:: 1.16.0
> Non-scalar `start` and `stop` are now supported.
>
> Parameters
> --
> start : array_like
> The starting value of the sequence.
> stop : array_like
> The end value of the sequence, unless `endpoint` is set to
> False.
> In that case, the sequence consists of all but the last of
> ``num + 1``
> evenly spaced samples, so that `stop` is excluded.  Note
> that the step
> size changes when `endpoint` is False.
> num : int, optional
> Number of samples to generate. Default is 50. Must be
> non-negative.
> endpoint : bool, optional
> If True, `stop` is the last sample. Otherwise, it is not
> included.
> Default is True.
> retstep : bool, optional
> If True, return (`samples`, `step`), where `step` is the spacing
> between samples.
> dtype : dtype, optional
> The type of the output array.  If `dtype` is not given,
> infer the data
> type from the other input arguments.
>
> .. versionadded:: 1.9.0
>
> axis : int, optional
> The axis in the result to store the samples.  Relevant only
> if start
> or stop are array-like.  By default (0), the samples will be
> along a
> new axis inserted at the beginning. Use -1 to get an axis at
> the end.
>
> .. versionadded:: 1.16.0
>
> Returns
> ---
> samples : ndarray
> There are `num` equally spaced samples in the closed interval
> ``[start, stop]`` or the half-open interval ``[start, stop)``
> (depending on whether `endpoint` is True or False).
> step : float, optional
> Only returned if `retstep` is True
>
> Size of spacing between samples.
>
>
> See Also
> 
> arange : Similar to `linspace`, but uses a step size (instead of the
>  number of samples).
> geomspace : Similar to `linspace`, but with numbers spaced
> evenly on a log
> scale (a geometric progression).
> logspace : Similar to `geomspace`, but with the end points
> specified as
>logarithms.
>
> Examples
> 
> >>> n

Bug#958536: marked as pending in chipmunk

[Stephen Kitt]

Control: tag -1 pending

Hello,

Bug #958536 in chipmunk reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/chipmunk/-/commit/30ff0ce6520e23b7e7b422e1a82cdc8670a4d367


Only tweak examples on arch builds

Closes: #958536


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/958536

Bug#956276: runescape: downloads unverified binary and runs it

[Stephen Kitt]

On Thu, 9 Apr 2020 20:06:33 +0200, Markus Koschany  wrote:
> So when the quint essential message is, it is a matter of opinion and a
> special form of verification is not mandated by Policy, then why don't
> you work closer with the member of this team and help him to implement
> the standard envisioned by you? That would be productive and helpful for
> a change.

For obvious reasons I don’t think there’s any point in continuing this
discussion.

Stephen


pgpF2eM7dDBqu.pgp
Description: OpenPGP digital signature

Bug#956276: runescape: downloads unverified binary and runs it

[Stephen Kitt]

Le 09/04/2020 14:47, Markus Koschany a écrit :

Am 09.04.20 um 13:58 schrieb Stephen Kitt:

Le 09/04/2020 13:44, Markus Koschany a écrit :

Am 09.04.20 um 13:24 schrieb Stephen Kitt:

On Thu, 9 Apr 2020 12:37:03 +0200, Markus Koschany 
wrote:

Am 09.04.20 um 11:36 schrieb Ivo De Decker:

[...]

Installing a Debian package doesn’t involve downloading a tarball from
github.com or anywhere else. A packager downloads the tarball, vets it
in some way or other (hopefully), and then uploads it to Debian
infrastructure, where it is used to build the binary packages which
users eventually download. After the initial upload, the contents 
don’t

change, unless a new version is uploaded.


In general we offer users the opportunity to rebuild a package from
scratch. That sometimes includes precise instructions in README.source
and a get-orig-source target in debian/rules but we often just assume
that running uscan will download the same original tarball that is
shipped in Debian's archive. In many cases this assumption is not true
and users will get a different tarball. Nowhere do we enforce that the
data is identical.


We’re not talking about rebuilding the package (at least, I wasn’t).

When a user installs a package in Debian, there’s a reasonable 
expectation that the user will get when the maintainer intended. Even if 
they choose to rebuild the package, the typical "apt source" invocation 
will retrieve the source last used to build the Debian package, *not* 
the upstream source.


Incidentally, there is one place where we do enforce that the orig 
tarball doesn’t change: when uploading to the archive... So there is 
that expectation somewhere. All the effort that went into pristine-tar 
also suggests that at least some people care about it in other 
circumstances too.



Put another way, when you install a Debian package, you get the exact
same contents as any other user installing the same version of the
package, and thus a certain amount of collective trust can be built.
This isn’t necessarily the case with the runescape package.


Right, because the runescape package does neither qualify for main nor
contrib hence why it was put in non-free and for its purpose the level
of trust is sufficient.


The fact that a package is in non-free isn’t a blank cheque for it to do 
anything it wants; Policy 2.2.3 still requires packages in non-free to 
“meet all policy requirements presented in this manual that it is 
possible for them to meet”. I disagree with the level of trust involved 
but that’s a matter of opinion.


Now to answer your initial question, as far as I can tell there is no 
Policy requirement that packages which download third-party files verify 
the contents.



Oh I know, we can’t do anything about trusting the publisher. The main
issue is that if for whatever reason a compromised JAR is put in place
on the upstream site, the runescape package will download it and run 
it

without any warning. Even the TLS protection doesn’t do much since the
download script doesn’t check the upstream certificate (so the site
could be hijacked and it would still work).


As Simon has already pointed out, the binary hash/signature will
probably change due to updates or other minor changes. That makes
runescape prone to other RC bugs and any implementation to validate the
launcher should take that into consideration.


Not necessarily: note that I said “without any warning”. The package 
could check the downloaded JAR against a signature, and if there’s a 
mismatch, warn the user before running it. That wouldn’t make the 
package prone to RC bugs.



Consider it this way: the packager will presumably check the package
before upload, and we can consider the JAR at that point to be
trustworthy (for some value of trustworthy). But there is absolutely 
no
guarantee that the JAR which users will receive bears any resemblance 
to

the JAR checked by the packager.


If someone wants to implement some form of verification, hash or
something else, please do. I still don't see why this issue is a Policy
violation and why everyone seems to require the same standards as in
main or contrib when the package is in non-free and does not have to
comply with each and every part of the DFSG. In my opinion the package
is very simple and sufficient for its purpose. A warning message may
help here too. Construing a Policy violation seems wrong to me.


I agree that as things currently stand, this is a matter of opinion. I 
do however tend to think that we can hold the distribution to a higher 
standard than that strictly mandated by Policy, in particular because 
most of Policy is written within a certain framework (packages which are 
fully contained within the archive) and ignores issues such as this one.


And of course no one is asking *you* to do anything ;-).

Regards,

Stephen

Bug#956276: runescape: downloads unverified binary and runs it

[Stephen Kitt]

Le 09/04/2020 15:18, Stephen Kitt a écrit :
[...]

When a user installs a package in Debian, there’s a reasonable
expectation that the user will get when the maintainer intended. Even


Sorry, *what* the maintainer intended.

[...]

Bug#956276: runescape: downloads unverified binary and runs it

[Stephen Kitt]

Le 09/04/2020 13:44, Markus Koschany a écrit :

Am 09.04.20 um 13:24 schrieb Stephen Kitt:
On Thu, 9 Apr 2020 12:37:03 +0200, Markus Koschany  
wrote:

Am 09.04.20 um 11:36 schrieb Ivo De Decker:
It seems runescape downloads a binary and runs it, without verifying 
its

integrity. At least the download happens using https, but no other
verification is done.


Could you quote the relevant part of Debian Policy, that requires
verification (and what kind of verification) of downloaded files. Is
downloading of verified orig tarballs now a requirement or is it 
still
just sufficient to download the tarball and verify its integrity by 
hand?


This is a bit different: runescape downloads a binary the first time 
it’s
run by any given user, so each user can potentially get a different 
binary.
Checking orig tarballs (whether using a signing key or manually) 
produces a

result which remains the same for all users...


How is this any different? It is possible that tarballs from github.com
differ each time a user is downloading them, but we don't require
verification. Where is this documented in Debian Policy as a "must"
requirement?


Installing a Debian package doesn’t involve downloading a tarball from 
github.com or anywhere else. A packager downloads the tarball, vets it 
in some way or other (hopefully), and then uploads it to Debian 
infrastructure, where it is used to build the binary packages which 
users eventually download. After the initial upload, the contents don’t 
change, unless a new version is uploaded.


Put another way, when you install a Debian package, you get the exact 
same contents as any other user installing the same version of the 
package, and thus a certain amount of collective trust can be built. 
This isn’t necessarily the case with the runescape package.



Note that we are talking about a non-free game here. The user has to
trust the publisher and there is nothing Debian can do about it. We 
only

provide a simple helper script to download the binary, which is done
about a secure transport channel. This is just a little more convenient
than to download it directly with your favorite web browser.


Oh I know, we can’t do anything about trusting the publisher. The main 
issue is that if for whatever reason a compromised JAR is put in place 
on the upstream site, the runescape package will download it and run it 
without any warning. Even the TLS protection doesn’t do much since the 
download script doesn’t check the upstream certificate (so the site 
could be hijacked and it would still work).


Consider it this way: the packager will presumably check the package 
before upload, and we can consider the JAR at that point to be 
trustworthy (for some value of trustworthy). But there is absolutely no 
guarantee that the JAR which users will receive bears any resemblance to 
the JAR checked by the packager.


Regards,

Stephen

Bug#956276: runescape: downloads unverified binary and runs it

[Stephen Kitt]

On Thu, 9 Apr 2020 12:37:03 +0200, Markus Koschany  wrote:
> Am 09.04.20 um 11:36 schrieb Ivo De Decker:
> > It seems runescape downloads a binary and runs it, without verifying its
> > integrity. At least the download happens using https, but no other
> > verification is done.  
> 
> Could you quote the relevant part of Debian Policy, that requires
> verification (and what kind of verification) of downloaded files. Is
> downloading of verified orig tarballs now a requirement or is it still
> just sufficient to download the tarball and verify its integrity by hand?

This is a bit different: runescape downloads a binary the first time it’s
run by any given user, so each user can potentially get a different binary.
Checking orig tarballs (whether using a signing key or manually) produces a
result which remains the same for all users...

Regards,

Stephen


pgp5TtfEIzrTV.pgp
Description: OpenPGP digital signature

Bug#955690: wine-development: FTBFS: configure: error: MinGW compiler not found, cross-compiling PE files won't be supported.

[Stephen Kitt]

On Fri, 3 Apr 2020 23:42:10 +0200, Gianfranco Costamagna
 wrote:
> Can you please also add this patch to fix arm64 build failures with default
> clang-10?

The arm64 build no longer uses clang, so I don’t think this is necessary (and
it should be handled differently anyway AFAICT, see the extra build flags in
debian/rules).

Regards,

Stephen


pgp5DPGSogNPs.pgp
Description: OpenPGP digital signature

Bug#955690: wine-development: FTBFS: configure: error: MinGW compiler not found, cross-compiling PE files won't be supported.

[Stephen Kitt]

On Sat, 4 Apr 2020 12:08:35 -0400, Michael Gilbert 
wrote:
> On Fri, Apr 3, 2020 at 5:28 PM Stephen Kitt wrote:
> > Thanks for the report, the package is missing a build-dependency on
> > gcc-mingw-w64-x86-64.  
> 
> There is more to it than this.  I am working on it now.

Yes, so far I’ve run into the 16-bit PE binaries (only on i386), and the
wine64-development.1 manpage. I’ll leave you to it!

> > Michael, I can take care of fixing this, doing a rebuild to make sure and
> > uploading, if you could push your git repo ;-).  
> 
> Done.

Thanks!

Regards,

Stephen


pgpq2Df033NGD.pgp
Description: OpenPGP digital signature

Bug#955690: wine-development: FTBFS: configure: error: MinGW compiler not found, cross-compiling PE files won't be supported.

[Stephen Kitt]

On Fri, 3 Apr 2020 21:45:28 +0200, Lucas Nussbaum  wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > checking for amd64-w64-mingw32-gcc... no
> > checking for x86_64-mingw32msvc-gcc... no
> > checking for amd64-mingw32msvc-gcc... no
> > checking for x86_64-w64-mingw32-clang... no
> > checking for amd64-w64-mingw32-clang... no
> > configure: error: MinGW compiler not found, cross-compiling PE files
> > won't be supported. This is an error since --with-mingw was requested.
> > make[1]: *** [debian/rules:150: override_dh_auto_configure] Error 1
> > make[1]: Leaving directory '/<>'  

Thanks for the report, the package is missing a build-dependency on
gcc-mingw-w64-x86-64.

Michael, I can take care of fixing this, doing a rebuild to make sure and
uploading, if you could push your git repo ;-).

Regards,

Stephen


pgpAghY7tlvW1.pgp
Description: OpenPGP digital signature

Bug#947558: d1x-rebirth: diff for NMU version 0.58.1-1.1

[Stephen Kitt]

On Sun, 02 Feb 2020 02:44:51 +1100, Dmitry Smirnov  wrote:
> On Sunday, 2 February 2020 2:28:04 AM AEDT Stephen Kitt wrote:
> > I've prepared an NMU for d1x-rebirth (versioned as 0.58.1-1.1) and
> > uploaded it to DELAYED/5.  
> 
> Thank you very much for doing this, Stephen. Much appreciated.

You’re very welcome! I’ve just done the same for d2x-rebirth (with a very
similar patch). The srcdir handling at the end of SConstruct is dealt with in
a rather ham-fisted manner in my patches, but I couldn’t figure out the
proper fix in a reasonable amount of time...

Regards,

Stephen


pgpBea6gGdABy.pgp
Description: OpenPGP digital signature