Bug#1016821: libspf2: FTBFS with glibc 2.34

2022-08-09 Thread Aurelien Jarno
control: tag -1 + patch

Hi,

On 2022-08-08 01:34, Sebastian Ramacher wrote:
> Source: libspf2
> Version: 1.2.10-7.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=libspf2=arm64=1.2.10-7.1%2Bb2=1659915050=0
> 
> /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wall  -Wl,-z,relro 
> -Wl,--version-script=/<>/debian/libspf2.ver -o spfquery 
> spfquery.o ../../src/libspf2/libspf2.la -lpthread -lnsl -lresolv 
> libtool: link: gcc -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wl,-z 
> -Wl,relro -Wl,--version-script=/<>/debian/libspf2.ver -o 
> .libs/spfquery spfquery.o  ../../src/libspf2/.libs/libspf2.so -lpthread -lnsl 
> -lresolv
> /usr/bin/ld: ../../src/libspf2/.libs/libspf2.so: undefined reference to 
> `__dn_expand'
> /usr/bin/ld: ../../src/libspf2/.libs/libspf2.so: undefined reference to 
> `__dn_skipname'

It appears that these two symbols have been renamed in glibc 2.34 when
moved from libresolv to libc. Quoting the glibc NEWS file:

| * Various symbols previously defined in libresolv have been moved to libc
|   in order to prepare for libresolv moving entirely into libc (see earlier
|   entry for merging libraries into libc).  The symbols __dn_comp,
|   __dn_expand, __dn_skipname, __res_dnok, __res_hnok, __res_mailok,
|   __res_mkquery, __res_nmkquery, __res_nquery, __res_nquerydomain,
|   __res_nsearch, __res_nsend, __res_ownok, __res_query, __res_querydomain,
|   __res_search, __res_send formerly in libresolv have been renamed and no
|   longer have a __ prefix.  They are now available in libc.

libspf2 is using libreplace internally to provide "replacements in case
the OS does not have native libraries that contain (working) copies.".
In that case it takes care to rename dn_expand into __dn_expand and
dn_skipname into __dn_skipname. It appears that with the changes done in
glibc 2.34, libspf2 does not need to use libreplace anymore. Therefore
the following patch from Ubuntu fixes the issue:

https://patches.ubuntu.com/libs/libspf2/libspf2_1.2.10-7.1ubuntu1.patch

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1016898: dolfin needs a rebuild against glibc 2.34

2022-08-09 Thread Aurelien Jarno
On 2022-08-09 13:21, Aurelien Jarno wrote:
> Source: dolfin
> Version: 2019.2.0~git20220407.d29e24d-5
> Severity: serious

FYI, I filled this bug with severity serious as it currently makes this
package uninstallable in sid, given breaks have been added to libc6-dev
against the affected version of libdolfin-dev-common.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1016898: dolfin needs a rebuild against glibc 2.34

2022-08-09 Thread Aurelien Jarno
Source: dolfin
Version: 2019.2.0~git20220407.d29e24d-5
Severity: serious

Dear maintainer,

glibc 2.34 has merged a few libraries (libpthread, libdl, libutil,
libanl) into libc. While this is handled transparently at runtime, there
are a few corner cases at build time. In the case of dolfin, the file
usr/share/dolfin/cmake/DOLFINTargets.cmake files embed the path to
libdl.so which doesn't exist anymore.

dolfin has been binNMUed as part of the transition [1], however we later
realised that the above file is actually in the libdolfin-dev-common
package which is binary all. Therefore a source upload is necessary.

Could you please schedule one? There should be no change needed besides
adding a build-depends on libc-dev (>= 2.34) to ensure it is built
against glibc 2.34 (not all chroots have been upgraded yet).

Thanks,
Aurelien

[1] https://buildd.debian.org/status/package.php?p=dolfin



Bug#1016540: wmanager: FTBFS / autopkgtest regression with glibc 2.34

2022-08-09 Thread Aurelien Jarno
control: severity 1016540 serious

On 2022-08-02 18:46, Aurelien Jarno wrote:
> Source: wmanager
> Version: 0.3.0-2
> Severity: important
> Tags: upstream patch
> Forwarded: https://gitlab.com/wmanager/wmanager/-/merge_requests/1
> 
> wmanager fails to build when built against glibc 2.34, and the
> autopkgtest fails when run against glibc 2.34 due to a timeout:
> 
> https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wmanager/24248015/log.gz
> 
> The problem has already been reported upstream with a patch available:
> https://gitlab.com/wmanager/wmanager/-/merge_requests/1
> 
> Could you please do an upload with this fix?

glibc 2.34 is now in unstable, upgrading the severity.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1016560: glibc 2.34 breaks scalpel autopkgtest on amd64: bash: line 1: 1961 Segmentation fault

2022-08-09 Thread Aurelien Jarno
control: severity 1016560 serious

On 2022-08-03 00:01, Aurelien Jarno wrote:
> Source: scalpel
> Version: 1.60-9
> Severity: important
> Tags: upstream patch
> User: debian-gl...@lists.debian.org
> Usertags: glibc2.34
> 
> Dear maintainer,
> 
> The autopkgtest of scalpel fails in sid on amd64 when that autopkgtest is
> run with the binary packages of glibc from experimental. It passes when
> run with only packages from sid. In tabular form:
> 
>  passfail
> glibcfrom sid2.34-0experimental5
> scalpel  from sid1.60-9
> all others   from sidfrom sid
> 
> Here is the relevant part of the test log:
> 
> autopkgtest [10:36:40]: test command1: scalpel -c debian/tests/scalpel.conf 
> debian/tests/lua.img
> autopkgtest [10:36:40]: test command1: [---
> 
> Opening target 
> "/tmp/autopkgtest-lxc.93yq46zi/downtmp/build.fXk/src/debian/tests/lua.img"
> 
> bash: line 1:  1961 Segmentation fault  bash -ec 'scalpel -c 
> debian/tests/scalpel.conf debian/tests/lua.img' 2> >(tee -a 
> /tmp/autopkgtest-lxc.93yq46zi/downtmp/command1-stderr >&2) > >(tee -a 
> /tmp/autopkgtest-lxc.93yq46zi/downtmp/command1-stdout)
> 
> The full test log is available there:
> https://ci.debian.net/data/autopkgtest/unstable/amd64/s/scalpel/24235565/log.gz
> 
> After some debugging, I have found the issue to be a duplicate use of a
> va_list without using va_copy. Please find attached a patch to fix that.
> 
> Regards
> Aurelien

> --- scalpel-1.60.orig/helpers.c
> +++ scalpel-1.60/helpers.c
> @@ -70,12 +70,14 @@ void setProgramName(char *s) {
>  // write entry to both the screen and the audit file 
>  void scalpelLog(struct scalpelState *state, char *format, ...) {
>  
> -  va_list argp;
> +  va_list argp, argp2;
>  
>va_start(argp,format);
> +  va_copy(argp2, argp);
>vfprintf (stderr,format,argp);
> -  vfprintf (state->auditFile,format,argp);
>va_end(argp);
> +  vfprintf (state->auditFile,format,argp2);
> +  va_end(argp2);
>  }
>  
>  // determine if two characters match, with optional case 

glibc 2.34 is now in unstable, upgrading the severity.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1012097: NIS broken in sid

2022-08-07 Thread Aurelien Jarno
control: reassign 1012097 libc6
control: forcemerge 1003342 1012097
control: affects 1012097 libnss-nis

On 2022-05-30 09:38, Francesco Paolo Lovergine wrote:
> Package: libnssswitch-nis
> Version: 3.1-4
> Severity: grave
> 
> It seems that currently unstable has a totally not working NIS binding for 
> users. I
> performed my trials using an existing setup (bullseye-based NIS master+slaves 
> and
> clients network in the real life).
> 
> I recently upgraded a bullseye NIS client box to sid for testing and 
> discovered that while
> ypbind-mt is regularly working, the usual mapping of NIS users has gone.
> To be sure of the issue I prepared a vagrant bullseye VM and bound that to 
> the regular bullseye NIS master as usual: perfectly working. 
> 
> Then I full-upgraded to sid with the same broken result:
> 
> vagrant@debian:/etc$ ypcat passwd
> [...]
> lovergine:x:2003:2000:Francesco Lovergine (trial),,,:/home/lovergine:/bin/bash
> [...]
> {sorry, I stripped the full output for privacy)
> 
> vagrant@debian:/etc$ id lovergine
> id: ‘lovergine’: no such user
> 
> vagrant@debian:/etc$ cat /etc/nsswitch.conf 
> # /etc/nsswitch.conf
> #
> # Example configuration of GNU Name Service Switch functionality.
> # If you have the `glibc-doc-reference' and `info' packages installed, try:
> # `info libc "Name Service Switch"' for information about this file.
> 
> passwd: compat systemd
> group:  compat systemd
> shadow: compat
> gshadow:compat
> 
> hosts:  files dns
> networks:   files
> 
> protocols:  db files
> services:   db files
> ethers: db files
> rpc:db files
> 
> netgroup:   nis
> 
> vagrant@debian:/etc$ cat /etc/passwd
> root:x:0:0:root:/root:/bin/bash
> daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
> bin:x:2:2:bin:/bin:/usr/sbin/nologin
> sys:x:3:3:sys:/dev:/usr/sbin/nologin
> sync:x:4:65534:sync:/bin:/bin/sync
> games:x:5:60:games:/usr/games:/usr/sbin/nologin
> man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
> lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
> mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
> news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
> uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
> proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
> www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
> backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
> list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
> irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
> gnats:x:41:41:Gnats Bug-Reporting System 
> (admin):/var/lib/gnats:/usr/sbin/nologin
> nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
> _apt:x:100:65534::/nonexistent:/usr/sbin/nologin
> systemd-timesync:x:101:101:systemd Time 
> Synchronization,,,:/run/systemd:/usr/sbin/nologin
> systemd-network:x:102:103:systemd Network 
> Management,,,:/run/systemd:/usr/sbin/nologin
> systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
> messagebus:x:104:105::/nonexistent:/usr/sbin/nologin
> _chrony:x:105:112:Chrony daemon,,,:/var/lib/chrony:/usr/sbin/nologin
> sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
> vagrant:x:1000:1000::/home/vagrant:/bin/bash
> systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
> _rpc:x:107:65534::/run/rpcbind:/usr/sbin/nologin
> +::
> 
> 
> My next step will be running a full-sid setup for a test network, but I don't
> see any reason why the working NIS maps could be broken, my guess is that
> the problem is connected to some inner libnss/libc issue. 

This was actually a bug in libc6, which affected the compat module,
while explicitly using the nis module worked. This has been introduced
in glibc 2.33 and fixed in glibc 2.34 that just landed in sid.

Merging this bug with the existing one on the libc6 side.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1016576: transition: glibc 2.34

2022-08-07 Thread Aurelien Jarno
On 2022-08-07 21:40, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/glibc-2.34.html
> 
> On 2022-08-03 11:49:20 +0200, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: debian-gl...@lists.debian.org
> > 
> > Dear release team,
> > 
> > I would like to get a transition slot for glibc 2.34. It has been
> > available in experimental for a few months, and does not have any known
> > major issue. It has been built successfully on all release architectures
> > and many ports architectures.
> 
> Please go ahead.

Thanks, I have just uploaded it.

Cheers
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1016804: ksh93u+m_1.0.1-1_all-buildd.changes REJECTED

2022-08-07 Thread Aurelien Jarno
Source: ksh93u+m
Version: 1.0.1-1
Severity: serious

On 2022-08-07 16:04, Debian FTP Masters wrote:
> Version check failed:
> Your upload included the binary package ksh, version 20211217, for all,
> however unstable already has version 20211217.
> Uploads to unstable must have a higher version than present in unstable.
> 
> Mapping sid to unstable.
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 



Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

2022-08-04 Thread Aurelien Jarno
On 2022-08-04 00:33, Vincent Lefevre wrote:
> On 2014-05-19 00:33:00 +0200, Aurelien Jarno wrote:
> > Until the C.UTF-8 locale is integrated directly into glibc instead of
> > being provide like a standard locale, it's not going to be something
> > easy to do.
> 
> Well, on the upstream side, the C.UTF-8 locale is now provided,
> but the bug still occurs.

It is provided like a standard locale, but has not been integrated
directly into glibc (like the built-in C locale), so it's expected that
the bug stills occurs.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1016576: transition: glibc 2.34

2022-08-03 Thread Aurelien Jarno
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-gl...@lists.debian.org

Dear release team,

I would like to get a transition slot for glibc 2.34. It has been
available in experimental for a few months, and does not have any known
major issue. It has been built successfully on all release architectures
and many ports architectures.

This transition is a bit more complex than the previous ones, as this
version merges a few libraries (libpthread, libdl, libutil, libanl) into
libc. This handled transparently at runtime.

This is also supposed to be handled transparently at link time by
providing empty static archives for libpthread.a, libdl.a, libutil.a,
libanl.a. That said it appears that the path to libpthread.so and
libdl.so is encoded in a few cmake files). Breaks against the affected
-dev packages have been added, and they will need to be binNMUed. Here
is the list:

assimp
deal.ii
dolfin
eckit
fclib
fltk1.3
insighttoolkit4
insighttoolkit5
ismrmrd
libminc
log4cplus
mathgl
mimalloc
mongo-c-driver
mrpt
netcdf
netcdf-parallel
ns3
openms
trilinos
visp
votca
vtk6
vtk7

In addition some symbols from libresolv symbols also got moved to libc,
and their __ prefix dropped at the same time. While there compatibility
symbols for dynamic linking, it it not the case for static linking.
Static libraries with reference to those symbols needs to be binNMUed.
Breaks against the affected -dev packages have been added, and they will
need to be binNMUed. Here is the list:

boinc
cups
dante
glib2.0
gloox
haskell-resolv
heimdal
hesiod
libasyncns
libaws
libdkim
libinfinity
libpg-query
libre
libspf2
libstrophe
linux-atm
loudmouth
mongo-c-driver
mysql-8.0
ncbi-igblast
nfs-utils
ola
openafs
opendkim
opendmarc
openldap
open-vm-tools
openzwave
pidgin-librvp
proftpd-dfsg
shishi
slurm-wlm
taningia

A few issues found through the autopkgtest pseudo excuses for
experimental have been fixed. Most of the remaining are either due to
the added breaks (see above), britney bugs or packages parts of the
transition. There are a few remaining though, but at this stage it's
probably better to move forward and get them fixed later, otherwise new
ones keep appearing. Here is the list:

castle-game-engine: #1016556
dash: #1016554
fpc: #1016556
scalpel: #1016560
securefs: #993515
wmanager: #1016540 
wcc: #1014729 (A binNMU fixes the issue, but not sure why)

A tracker is already setup at:
https://release.debian.org/transitions/html/glibc-2.34.html

Thanks for considering.

Regards
Aurelien



Bug#1016560: glibc 2.34 breaks scalpel autopkgtest on amd64: bash: line 1: 1961 Segmentation fault

2022-08-02 Thread Aurelien Jarno
Source: scalpel
Version: 1.60-9
Severity: important
Tags: upstream patch
User: debian-gl...@lists.debian.org
Usertags: glibc2.34

Dear maintainer,

The autopkgtest of scalpel fails in sid on amd64 when that autopkgtest is
run with the binary packages of glibc from experimental. It passes when
run with only packages from sid. In tabular form:

 passfail
glibcfrom sid2.34-0experimental5
scalpel  from sid1.60-9
all others   from sidfrom sid

Here is the relevant part of the test log:

autopkgtest [10:36:40]: test command1: scalpel -c debian/tests/scalpel.conf 
debian/tests/lua.img
autopkgtest [10:36:40]: test command1: [---

Opening target 
"/tmp/autopkgtest-lxc.93yq46zi/downtmp/build.fXk/src/debian/tests/lua.img"

bash: line 1:  1961 Segmentation fault  bash -ec 'scalpel -c 
debian/tests/scalpel.conf debian/tests/lua.img' 2> >(tee -a 
/tmp/autopkgtest-lxc.93yq46zi/downtmp/command1-stderr >&2) > >(tee -a 
/tmp/autopkgtest-lxc.93yq46zi/downtmp/command1-stdout)

The full test log is available there:
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/scalpel/24235565/log.gz

After some debugging, I have found the issue to be a duplicate use of a
va_list without using va_copy. Please find attached a patch to fix that.

Regards
Aurelien
--- scalpel-1.60.orig/helpers.c
+++ scalpel-1.60/helpers.c
@@ -70,12 +70,14 @@ void setProgramName(char *s) {
 // write entry to both the screen and the audit file 
 void scalpelLog(struct scalpelState *state, char *format, ...) {
 
-  va_list argp;
+  va_list argp, argp2;
 
   va_start(argp,format);
+  va_copy(argp2, argp);
   vfprintf (stderr,format,argp);
-  vfprintf (state->auditFile,format,argp);
   va_end(argp);
+  vfprintf (state->auditFile,format,argp2);
+  va_end(argp2);
 }
 
 // determine if two characters match, with optional case 


Bug#1016556: fpc: glibc 2.34 breaks fpc autopkgtest on arm64: undefined reference to `__libc_csu_init'

2022-08-02 Thread Aurelien Jarno
Source: fpc
Version: 3.2.2+dfsg-10
Severity: important
Tags: patch
User: debian-gl...@lists.debian.org
Usertags: glibc2.34

Dear maintainer,

The autopkgtest of fpc fails in sid on amd64 when that autopkgtest is
run with the binary packages of glibc from experimental. It passes when
run with only packages from sid. In tabular form:

 passfail
glibcfrom sid2.34-0experimental5
fpc  from sid3.2.2+dfsg-10
all others   from sidfrom sid

Here is the relevant part of the test log:

/usr/bin/ppca64 fpmake.pp -n -Fu../../rtl/units/aarch64-linux 
-Fu../../packages/paszlib -Fu../../packages/fcl-process -Fu../../packages/hash 
-Fu../../packages/libtar -Fu../../packages/fpmkunit/units_bs/aarch64-linux  
@/tmp/autopkgtest-lxc.pdlnszmr/downtmp/build.u8l/src/debian/deb-build-fpc.cfg
/usr/bin/ld.bfd: 
/tmp/autopkgtest-lxc.pdlnszmr/downtmp/build.u8l/src/fpcsrc/rtl/units/aarch64-linux/cprt0.o:
 in function `_start':
(.text+0x54): undefined reference to `__libc_csu_init'
/usr/bin/ld.bfd: (.text+0x58): undefined reference to `__libc_csu_init'
/usr/bin/ld.bfd: (.text+0x5c): undefined reference to `__libc_csu_fini'
/usr/bin/ld.bfd: (.text+0x60): undefined reference to `__libc_csu_fini'
fpmake.pp(258) Error: Error while linking
fpmake.pp(258) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted

The full test log is available there:
https://ci.debian.net/data/autopkgtest/unstable/arm64/f/fpc/24224856/log.gz

It seems that the startup code has to be adjusted for glibc 2.34, Ubuntu
has a patch available there:
https://patches.ubuntu.com/f/fpc/fpc_3.2.2+dfsg-11ubuntu1.patch

Regards
Aurelien



Bug#1016554: dash: glibc 2.34 breaks dash autopkgtest on amd64: symbol lookup error

2022-08-02 Thread Aurelien Jarno
Package: dash
Version: 0.5.11+git20210903+057cd650a4ed-8
Severity: important
User: debian-gl...@lists.debian.org
Usertags: glibc2.34

Dear maintainer,

The autopkgtest of dash fails in sid on amd64 when that autopkgtest is
run with the binary packages of glibc from experimental. It passes when
run with only packages from sid. In tabular form:

 passfail
glibcfrom sid2.34-0experimental5
dash from sid0.5.11+git20210903+057cd650a4ed-8
all others   from sidfrom sid

The relevant part of the test log is the following

  env: symbol lookup error: 
/tmp/mmdebstrap.zcyyAwHdpW//lib/x86_64-linux-gnu/libc.so.6: undefined symbol: 
_dl_catch_error_ptr, version GLIBC_PRIVATE

The full test log is available there:
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dash/24221304/log.gz

It seems that fakechroot is mixing glibc from inside and outside of the
chroot, which have different GLIBC_PRIVATE symbols.

Regards
Aurelien



Bug#1016540: wmanager: FTBFS / autopkgtest regression with glibc 2.34

2022-08-02 Thread Aurelien Jarno
Source: wmanager
Version: 0.3.0-2
Severity: important
Tags: upstream patch
Forwarded: https://gitlab.com/wmanager/wmanager/-/merge_requests/1

wmanager fails to build when built against glibc 2.34, and the
autopkgtest fails when run against glibc 2.34 due to a timeout:

https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wmanager/24248015/log.gz

The problem has already been reported upstream with a patch available:
https://gitlab.com/wmanager/wmanager/-/merge_requests/1

Could you please do an upload with this fix?

Thanks
Aurelien



Bug#1009691: libusb-1.0-0: Some USB microphone takes sounds as very low volume

2022-07-29 Thread Aurelien Jarno
Hi,

On 2022-04-14 22:41, Aurelien Jarno wrote:
> Hi,
> 
> On 2022-04-14 19:41, Hideki Yamane wrote:
> > Package: libusb-1.0-0
> > Version: 2:1.0.26-1
> > Severity: normal
> > X-Debbugs-Cc: henr...@debian.org
> > 
> > Dear Maintainer,
> > 
> >  With upgrading libusb-1.0-0 package from 2:1.0.25-1 to 2:1.0.26-1,
> >  my USB microphone (marantz PROFESSIONAL pod pack1, "C-Media Electronics, 
> > Inc.
> >  Blue Snowball" with lsusb) just takes sounds as very low volume. However,
> >  Other USB mic (logicool webcam) just works fine with both versions.
> 
> Could you please point me to which software you use with this
> microphone? Very few softwares use libusb to grab the audio.
> 
> >  Downgrading to 2:1.0.25-1 solves this problem.
> >  
> >  USB microphone's info via lsusb is attached.
> >  Please let me know if you need more information to investigate this issue.
> >  Thanks.
> 
> Could you please run your application with the LIBUSB_DEBUG environment
> variable set to 99 for both versions 2:1.0.25-1 and 2:1.0.26-1, and send
> me the output?
> 

Any news about that?

Thanks
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

2022-07-25 Thread Aurelien Jarno
On 2022-07-25 14:51, Alejandro Colomar wrote:
> Hi Florian!
> 
> On 7/25/22 12:38, Florian Weimer wrote:
> > * Alejandro Colomar via Libc-alpha:
> > 
> > > Is there an easy way to regenerate that header to get the tatest
> > > syscalls?  Maybe a command could be supplied so that users (or at
> > > least distributors) have it easy to regenerate them?  Maybe it already
> > > exists but it's not widely known?
> > 
> > I have recently backported the syscall-names.list updates to glibc 2.34,
> > but not glibc 2.33.  It's a simple backport.
> > 
> > We could perhaps enhance the glibc build process that it uses the union
> > of the known system call names and what's found in the kernel headers.
> 
> I guess it's a simple backport, since it's just adding the macros (I guess 0
> side effects).

In addition the goal is to switch to glibc 2.34 in the next weeks, not
that most problems related with the libpthread.so removal are
identified.

> But maybe providing a script, e.g., update-libc-syscalls(1), that
> distributions and users can call when updating a kernel to immediately
> backport syscalls to their system, would make it even simpler.
> 
> E.g., when one runs `apt-get upgrade`, if the kernel is upgraded,
> update-libc-syscalls(1) would be called by apt-get as a post install script,
> and libc macros would have the new syscall numbers provided by the new
> kernel.  No need to wait glibc programmers to provide the backport.
> 
> Makes sense?

I don't think so. You do not want to modify files provided by a package.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

2022-07-24 Thread Aurelien Jarno
Hi,

On 2022-07-24 12:39, Alejandro Colomar (man-pages) wrote:
> Hi Aurelien,
> 
> On 7/23/22 11:43, Aurelien Jarno wrote:
> > Hi,
> > 
> > On 2022-07-19 21:55, Alejandro Colomar wrote:
> > > Package: libc6-dev
> > > Version: 2.33-8
> > > Severity: normal
> > > X-Debbugs-Cc: alx.manpa...@gmail.com
> > > 
> > > 
> > > Hi,
> > > 
> > > We had a discussion in NGINX Unit about if we should use __NR_xxx
> > > or SYS_xxx syscall numbers.  As maintainer of the Linux man-pages,
> > > I suggested that we should use the libc macros (SYS_xxx), since
> > > they are compatible with other non-Linux systems, and also because
> > > they are the documented way for user space.  However, there was
> > > some concern that someone might be running a new kernel with an
> > > old glibc, and that __NR_xxx symbols might be available but not
> > > SYS_xxx in that case.
> > 
> > Yes that sounds good.
> > 
> > > Since the  (included through )
> > > header is generated automatically from the kernel headers at glibc
> > > build time, Debian should make sure that the latest available
> > > kernel headers are used, so building the latest Sid glibc package
> > > should be done on a system with also the latest kernel available
> > > in Sid, to have a complete SYS_xxx list.
> > 
> > This is basically what is done, the buildd chroots are updated twice a
> > week, so in the worst case glibc is build against a kernel headers
> > package that is 4 days old.
> 
> Is it?  I have kernel 5.18, but my bits/syscalls.h still says it was
> generated from kernel 5.10 (that's a long time ago).  I have the latest Sid
> packages for both the kernel and glibc.

Yes, this is definitely the case, glibc 2.33-8 has been built against
linux-libc-dev 5.18.5-1. What is wrong is "header is generated
automatically from the kernel headers at glibc build time". They are
generated by upstream at release time, not at build time.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

2022-07-23 Thread Aurelien Jarno
Hi,

On 2022-07-19 21:55, Alejandro Colomar wrote:
> Package: libc6-dev
> Version: 2.33-8
> Severity: normal
> X-Debbugs-Cc: alx.manpa...@gmail.com
> 
> 
> Hi,
> 
> We had a discussion in NGINX Unit about if we should use __NR_xxx
> or SYS_xxx syscall numbers.  As maintainer of the Linux man-pages,
> I suggested that we should use the libc macros (SYS_xxx), since
> they are compatible with other non-Linux systems, and also because
> they are the documented way for user space.  However, there was
> some concern that someone might be running a new kernel with an
> old glibc, and that __NR_xxx symbols might be available but not
> SYS_xxx in that case.

Yes that sounds good.

> Since the  (included through )
> header is generated automatically from the kernel headers at glibc
> build time, Debian should make sure that the latest available
> kernel headers are used, so building the latest Sid glibc package
> should be done on a system with also the latest kernel available
> in Sid, to have a complete SYS_xxx list.

This is basically what is done, the buildd chroots are updated twice a
week, so in the worst case glibc is build against a kernel headers
package that is 4 days old. 

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1015146: rust-cbindgen_0.23.0-1~deb10u1_s390x-buildd.changes REJECTED

2022-07-16 Thread Aurelien Jarno
Source: rust-cbindgen
Version: 0.23.0-1~deb10u1
Severity: serious
X-Debbugs-Cc: po...@debian.org

On 2022-07-16 15:34, Debian FTP Masters wrote:
> 
> 
> cbindgen_0.23.0-1~deb10u1_s390x.deb: has 1 file(s) with a timestamp too far 
> in the past:
>   usr/share/doc/cbindgen/changelog.gz (Thu Nov 29 21:33:09 1973)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 


signature.asc
Description: PGP signature


Bug#1014735: rpcsvc-proto: The /usr/include/rpc/* files is not included

2022-07-11 Thread Aurelien Jarno
Hi,

On 2022-07-11 22:18, Magnus Danielson wrote:
> Hi,
> 
> On 7/11/22 18:30, Aurelien Jarno wrote:
> > control: tag -1 + moreinfo
> > 
> > Hi,
> > 
> > On 2022-07-11 02:46, Magnus Danielson wrote:
> > > Package: rpcsvc-proto
> > > Version: 1.4.2-4
> > > Severity: grave
> > > Justification: renders package unusable
> > rpcsvc-proto is used to build many packages in Debian, so I doubt it is
> > completely unusable.
> Fair enough, but for my purpose it failed completely. Of the options given
> by text in recommended tool reportbug this was closest to my experienced
> situation.
> > 
> > > Dear Maintainer,
> > > 
> > > Template answers first, for your convenience.
> > > 
> > >     * What led up to the situation?
> > > 
> > > Rebuilding an application using rpcgen.
> > > 
> > >     * What exactly did you do (or not do) that was effective (or
> > >   ineffective)?
> > > 
> > > Run rpcgen, then tried to compile the produced files.
> > > 
> > >     * What was the outcome of this action?
> > > 
> > > Any of the /usr/include/rpc/* header-files referenced such as
> > > #include 
> > > etc. fail to include, all the related definitions missing causes large
> > > amount
> > > of compile errors.
> > Could you please give me more details about the issue? Ideally copy and
> > paste the error message.
> make
> rpcgen core.x
> gcc -DHAVE_CONFIG_H -I. -I. -I.    -Wall -g -O2 -c core_svc.c
> In file included from core_svc.c:6:
> core.h:9:10: fatal error: rpc/rpc.h: No such file or directory
>     9 | #include 
>   |  ^~~
> compilation terminated.
> make: *** [Makefile:514: core_svc.o] Error 1
> 
> So, here rpcgen process the core.x, outputting core_clnt.c, core_svc.c,
> core_xdr.c and core.h.

Ok, so that's definitely the issue of the SunRPC removal from glibc.

> The next step is to compile these, and for the case of core_svc.c this fails
> because
> 
> #include 
> 
> which is generated by rpcgen (there is no such reference in core.x) and thus
> needed by users for rpcgen.
> 
> I think it is fair to assume that when using rpcgen, the associated
> headerfiles needed to compile is either directly or indirectly in the
> package (or dependencies of the package).
 
> > My guess is that your problem is not related to rpcsvc-proto itself
> > which just provides rpcgen and related header files, but with the
> > removal of the SunRPC implementation for glibc. You need to switch to
> > the TI RPC implementation instead (using the libtirpc-dev package).
> 
> Which does not work out, since rpcgen does generate the dependence to
> /usr/include/rpc/* and the installed libtirpc-dev delivers the files in
> /usr/include/tirpc/rpc/* so despite being installed, gcc does not find it,
> and the rpcgen produces files that does not compile.

Given the SunRPC library has been removed from glibc, you definitely
need to use pkg-config to get the correct link time flags to link
your code against libtirpc. Therefore changes are needed to your
project, whether you want it or not. You can therefore do the same
changes for the includes.

There are multiple compatible RPC libraries (which actually predates the
SunRPC removal), and users are able to select the one they prefer by
using the correct include and link flags.

Note that most open source projects have already been updated to
automatically switch to an alternative RPC implementation since the
first distribution removed the SunRPC support more than 4 years ago (at
this time this was still an opt-in on the glibc side).

> > >     * What outcome did you expect instead?
> > > 
> > > Nice compile as headerfiles is found.
> > > 
> > > This is most likely a consequence of repackaging the rpc-part. Looking 
> > > back
> > > at
> > > the stable version of libc6 the header files is there in libc6-dev, but 
> > > for
> > > testing and unstable they are not. I expect that using these this would
> > > work.
> > > If the headerfiles is in another package, dependence on that should be in
> > > place.
> > The files that are removed from libc6-dev are the ones related to the
> > removed SunRPC implementation. libc6-dev (indirectly) depends on
> > libtirpc3-dev so the replacement header files should be available on
> > your system. That said it is not a one to one replacement, so you need
> > to use pkgconfig to get the compile and link flags.
> 
> Which is documented where for this change?

The changes is documented on the Debian side in chang

Bug#1014729: glibc 2.34 breaks wcc autopkgtest on amd64: open: Invalid argument

2022-07-11 Thread Aurelien Jarno
On 2022-07-11 10:06, Michael Hudson-Doyle wrote:
> It looks like a no-change rebuild fixed this in Ubuntu fwiw.

Thanks, I confirm that in Debian too. Do you have an idea why? It could
be a missing or too loose dependency.

> On Mon, 11 Jul 2022 at 09:54, Aurelien Jarno  wrote:
> 
> > Source: glibc, wcc
> > Control: found -1 glibc/2.34-0experimental4
> > Control: found -1 wcc/0.0.2+dfsg-4.1
> > Severity: important
> > Tags: experimental
> >
> > Dear maintainers,
> >
> > The autopkgtest of wcc fails in sid on amd64 when that autopkgtest is
> > run with the binary packages of glibc from experimental. It passes when
> > run with only packages from sid. In tabular form:
> >
> >passfail
> > glibc  from sid2.34-0experimental4
> > wccfrom sid0.0.2+dfsg-4.1
> > all others from sidfrom sid
> >
> > I copied some of the output at the bottom of this report.
> >
> > Currently this regression is blocking the transition to glibc 2.34. Due
> > to the nature of this issue, I filed this bug report against both
> > packages. Can you please investigate the situation and reassign the bug
> > to the right package?
> >
> > More information about this bug and the reason for filing it can be found
> > on
> > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> >
> > Regards
> > Aurelien
> >
> > https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wcc/23455379/log.gz
> >
> >
> > autopkgtest [14:35:47]: test wsh-libs.wsh: [---
> > open: Invalid argument
> >
> > [1;32m[SIGSEGV] Read00700101[1;34m(address not mapped to
> > object)
> > [0mbash: line 1:  2061 Segmentation fault
> > /tmp/autopkgtest-lxc.yfun0_rb/downtmp/build.xHo/src/debian/tests/wsh-libs.wsh
> > 2> >(tee -a /tmp/autopkgtest-lxc.yfun0_rb/downtmp/wsh-libs.wsh-stderr >&2)
> > > >(tee -a /tmp/autopkgtest-lxc.yfun0_rb/downtmp/wsh-libs.wsh-stdout)
> > autopkgtest [14:35:47]: test wsh-libs.wsh: ---]
> > autopkgtest [14:35:47]: test wsh-libs.wsh:  - - - - - - - - - - results -
> > - - - - - - - - -
> > wsh-libs.wsh FAIL non-zero exit status 139
> >

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1014735: rpcsvc-proto: The /usr/include/rpc/* files is not included

2022-07-11 Thread Aurelien Jarno
control: tag -1 + moreinfo

Hi,

On 2022-07-11 02:46, Magnus Danielson wrote:
> Package: rpcsvc-proto
> Version: 1.4.2-4
> Severity: grave
> Justification: renders package unusable

rpcsvc-proto is used to build many packages in Debian, so I doubt it is
completely unusable.

> Dear Maintainer,
> 
> Template answers first, for your convenience.
> 
>    * What led up to the situation?
> 
> Rebuilding an application using rpcgen.
> 
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Run rpcgen, then tried to compile the produced files.
> 
>    * What was the outcome of this action?
> 
> Any of the /usr/include/rpc/* header-files referenced such as
> #include 
> etc. fail to include, all the related definitions missing causes large
> amount
> of compile errors.

Could you please give me more details about the issue? Ideally copy and
paste the error message.

My guess is that your problem is not related to rpcsvc-proto itself
which just provides rpcgen and related header files, but with the
removal of the SunRPC implementation for glibc. You need to switch to
the TI RPC implementation instead (using the libtirpc-dev package).

>    * What outcome did you expect instead?
> 
> Nice compile as headerfiles is found.
> 
> This is most likely a consequence of repackaging the rpc-part. Looking back
> at
> the stable version of libc6 the header files is there in libc6-dev, but for
> testing and unstable they are not. I expect that using these this would
> work.
> If the headerfiles is in another package, dependence on that should be in
> place.

The files that are removed from libc6-dev are the ones related to the
removed SunRPC implementation. libc6-dev (indirectly) depends on
libtirpc3-dev so the replacement header files should be available on
your system. That said it is not a one to one replacement, so you need
to use pkgconfig to get the compile and link flags.

> Package-testing should actually include a dummy-application that generates
> through rpcgen and then compiles it successfully. Then this error would be
> caught. Another approach would be to check that the same header files gets
> installed from previous packaging and new packaging. Both methods would be
> recommended to create fail-safes and quick turn-around for package
> maintainers.

Don't hesitate to provide a patch doing that.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1014729: glibc 2.34 breaks wcc autopkgtest on amd64: open: Invalid argument

2022-07-10 Thread Aurelien Jarno
Source: glibc, wcc
Control: found -1 glibc/2.34-0experimental4
Control: found -1 wcc/0.0.2+dfsg-4.1
Severity: important
Tags: experimental

Dear maintainers,

The autopkgtest of wcc fails in sid on amd64 when that autopkgtest is
run with the binary packages of glibc from experimental. It passes when
run with only packages from sid. In tabular form:

   passfail
glibc  from sid2.34-0experimental4
wccfrom sid0.0.2+dfsg-4.1
all others from sidfrom sid

I copied some of the output at the bottom of this report.

Currently this regression is blocking the transition to glibc 2.34. Due
to the nature of this issue, I filed this bug report against both
packages. Can you please investigate the situation and reassign the bug
to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Regards
Aurelien

https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wcc/23455379/log.gz


autopkgtest [14:35:47]: test wsh-libs.wsh: [---
open: Invalid argument

[1;32m[SIGSEGV] Read00700101[1;34m(address not mapped to object)
[0mbash: line 1:  2061 Segmentation fault  
/tmp/autopkgtest-lxc.yfun0_rb/downtmp/build.xHo/src/debian/tests/wsh-libs.wsh 
2> >(tee -a /tmp/autopkgtest-lxc.yfun0_rb/downtmp/wsh-libs.wsh-stderr >&2) > 
>(tee -a /tmp/autopkgtest-lxc.yfun0_rb/downtmp/wsh-libs.wsh-stdout)
autopkgtest [14:35:47]: test wsh-libs.wsh: ---]
autopkgtest [14:35:47]: test wsh-libs.wsh:  - - - - - - - - - - results - - - - 
- - - - - -
wsh-libs.wsh FAIL non-zero exit status 139


signature.asc
Description: PGP signature


Bug#1012867: bad line in usb.ids

2022-07-02 Thread Aurelien Jarno
control: found -1 2022.02.15-1
control: close -1 2022.04.02-1

Hi,

On 2022-06-15 16:50, Daniel Carlson wrote:
> Package: usb.ids
> Version: 2022.02.15-0+deb11u1
> 
> Line 23299 in usb.ids, containing "8087 07da  Centrino Advanced-N
> 6235", causes an error to be printed in the terminal when I run the
> command "sudo usbip list -l". The error text is "usbip: error:
> Protocol spec without prior Class and Subclass spec at line 23299".
> 
> When I checked the upstream version 2022.05.20 I found that this
> line has been removed. I've removed the line on my machine and
> the error is gone. The issue is mentioned here
> https://usb-ids.gowdy.us/read/UD/8087/07da.

Indeed, I confirm the issue. It seems that some parsers are able to cope
with that, some other not. It appears the problem has been introduced in
2022.02.15 and fixed in 2022.04.02. This mail should update the BTS to
mark it as such.

> The error first occurred for me on my computer running an armbian
> image. I've also reproduced it on my desktop running bullseye with
> kernel 5.10.0-14-amd64 and usbip version 2.0+5.10.120-1.

I can only speak for Debian. The problem is fixed in testing/sid and
should be fixed in stable soon.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1014077: haskell-bimap_0.4.0-2_mips64el-buildd.changes REJECTED

2022-06-29 Thread Aurelien Jarno
Source: haskell-bimap_
Version: 0.4.0-2
Severity: serious

On 2022-06-29 21:25, Debian FTP Masters wrote:
> libghc-bimap-dev_0.4.0-2_mips64el.deb: has 1 file(s) with a timestamp too far 
> in the past:
>   usr/share/doc/libghc-bimap-dev/changelog.gz (Thu Jan  1 00:00:00 1970)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 



Bug#1014014: bullseye-pu: package usb.ids/2022.05.20-0+deb11u1

2022-06-28 Thread Aurelien Jarno
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
This new upstream version of the USB ID database adds a few USB devices.

[ Impact ]
New USB devices will not be displayed with a human readable name for
package using this database.

[ Tests ]
There is no test associated with this database. This package only
contains data, no code.

[ Risks ]
Risks are very low, such update are routinely done in stable.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
I would like to do an update of the usb.ids package to add/update around
~35 USB devices to the usb.ids database. Those changes are already in
testing/sid. I have figured out that it's easier to just upload the
package from testing/sid with a new changelog entry, the only useless
change is the update of the Standards-Version field.

[ Other info ]
Given the changes are minimal, I have already uploaded the package to
the archive. Thanks for considering.
diff -Nru usb.ids-2022.02.15/debian/changelog 
usb.ids-2022.05.20/debian/changelog
--- usb.ids-2022.02.15/debian/changelog 2022-02-25 21:32:21.0 +
+++ usb.ids-2022.05.20/debian/changelog 2022-06-27 21:21:43.0 +
@@ -1,8 +1,27 @@
-usb.ids (2022.02.15-0+deb11u1) bullseye; urgency=medium
+usb.ids (2022.05.20-0+deb11u1) bullseye; urgency=medium
 
-  * Upload to bullseye.
+  * Upload to bullseye. 
 
- -- Aurelien Jarno   Fri, 25 Feb 2022 22:32:21 +0100
+ -- Aurelien Jarno   Mon, 27 Jun 2022 23:21:43 +0200
+
+usb.ids (2022.05.20-1) unstable; urgency=medium
+
+  * New upstream version.
+
+ -- Aurelien Jarno   Fri, 10 Jun 2022 22:20:35 +0200
+
+usb.ids (2022.05.09-1) unstable; urgency=medium
+
+  * New upstream version.
+  * Bump Standards-Version to 4.6.1 (no changes).
+
+ -- Aurelien Jarno   Mon, 16 May 2022 22:01:20 +0200
+
+usb.ids (2022.04.02-1) unstable; urgency=medium
+
+  * New upstream version.
+
+ -- Aurelien Jarno   Sat, 02 Apr 2022 23:49:24 +0200
 
 usb.ids (2022.02.15-1) unstable; urgency=medium
 
diff -Nru usb.ids-2022.02.15/debian/control usb.ids-2022.05.20/debian/control
--- usb.ids-2022.02.15/debian/control   2021-12-25 15:42:43.0 +
+++ usb.ids-2022.05.20/debian/control   2022-05-16 20:01:20.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Aurelien Jarno 
 Build-Depends: debhelper-compat (= 12)
-Standards-Version: 4.6.0
+Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: http://www.linux-usb.org/usb-ids.html
 
diff -Nru usb.ids-2022.02.15/usb.ids usb.ids-2022.05.20/usb.ids
--- usb.ids-2022.02.15/usb.ids  2022-02-15 20:34:10.0 +
+++ usb.ids-2022.05.20/usb.ids  2022-05-20 19:34:10.0 +
@@ -9,8 +9,8 @@
 #  The latest version can be obtained from
 #  http://www.linux-usb.org/usb.ids
 #
-# Version: 2022.02.15
-# Date:2022-02-15 20:34:10
+# Version: 2022.05.20
+# Date:2022-05-20 20:34:10
 #
 
 # Vendors, devices and interfaces. Please keep sorted.
@@ -3412,6 +3412,12 @@
069b  ECOSYS M2635dn
06b4  ECOSYS M5526cdw
 0483  STMicroelectronics
+   0102  Remote NDIS Network device with Android debug (ADB)
+   0103  Remote NDIS Network device
+   0104  MTP device with Android debug (ADB)
+   0105  MTP device
+   0106  PTP device with Android debug (ADB)
+   0107  PTP device
0137  BeWAN ADSL USB ST (blue or green)
0138  Unicorn II (ST70138B + MTC-20174TQ chipset)
0adb  Android Debug Bridge (ADB) device
@@ -14964,6 +14970,10 @@
 0e23  Liou Yuane Enterprise Co., Ltd
 0e25  VinChip Systems, Inc.
 0e26  J-Phone East Co., Ltd
+0e2e  Brady Worldwide, Inc.
+   000b  BMP 51
+   000c  BMP 61
+   000d  BMP 41
 0e30  HeartMath LLC
 0e34  Micro Computer Control Corp.
 0e35  3Pea Technologies, Inc.
@@ -17291,7 +17301,7 @@
a001  Bandit Action Camera Batt-Stick
 1391  IdealTEK, Inc.
1000  URTC-1000
-1395  Sennheiser Communications
+1395  DSEA A/S
0025  Headset [PC 8]
0026  SC230
0027  SC260
@@ -17333,7 +17343,7 @@
0065  MB 660
0066  SP 20 D UC
0067  SP 20 D MS
-   006b  SC5x5 MS
+   006b  SC6x5
0072  Headset
3556  USB Headset
 1397  BEHRINGER International GmbH
@@ -21548,6 +21558,12 @@
061d  PCTV Deluxe (NTSC) Device
061e  PCTV Deluxe (PAL) Device
2304  1689
+2309  TimeLink Technology Co., Ltd
+   1001  Touch Device(hid)
+   1005  Touch Device
+   1006  Touch Device(2)
+   1007  MulTouch Device(hid)
+   1009  Touch Device(hid)
 230d  Teracom
0103  Huwaii 3g wireless modem
 2314  INQ Mobile
@@ -22323,13 +22339,15 @@
5440  TimVideos' HDMI2USB Opsis (FX2) - Unconfigured device
5441  TimVideos' HDMI2USB Opsis (FX2) - Firmware load/upgrade

Bug#1013674: haskell-wl-pprint-text_1.2.0.1-1+b2_mips64el-buildd.changes REJECTED

2022-06-24 Thread Aurelien Jarno
Source: haskell-wl-pprint-text
Version: 1.2.0.1-1
Severity: serious

On 2022-06-22 16:08, Debian FTP Masters wrote:
> libghc-wl-pprint-text-dev_1.2.0.1-1+b2_mips64el.deb: has 1 file(s) with a 
> timestamp too far in the past:
>   usr/share/doc/libghc-wl-pprint-text-dev/changelog.gz (Thu Jan  1 00:00:00 
> 1970)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 



Bug#932927: (no subject)

2022-06-18 Thread Aurelien Jarno
cont...@bugs.debian.org
Bcc: 
Subject: Re: Bug#932927 closed by xiao sheng wen(肖盛文)
  (fixed in 4.1.1-5)
Reply-To: 
In-Reply-To: <0e8fef28-132d-da7b-3047-82648381d...@sina.com>

user debian-ri...@lists.debian.org
usertag 932927 - riscv64
thanks


On 2022-06-18 15:53, xiao sheng wen(肖盛文) wrote:
> Hi Aurelien,
> 
> 
> 在 2022/6/18 12:39, Aurelien Jarno 写道:
> > control: reopen 932927
> > control: found 932927 4.1.1-5
> > 
> > On 2022-06-17 08:33, Debian Bug Tracking System wrote:
> > 
> > #932927: libotr: buggy unit test: test_auth.c: test_auth_clear()
> > 
> > It has been closed by xiao sheng wen(肖盛文) .
> > 
> > -- 
> > 932927: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932927
> > 
> > > From: "xiao sheng wen(肖盛文)" 
> > > To: 932...@bugs.debian.org, 932927-d...@bugs.debian.org
> > > 
> > > control: fixed -1 4.1.1-5
> > > 
> > > 
> > > tests/unit$ ./test_auth is run OK now:
> > > 
> > > 
> > > ./run.sh test_list
> > > unit/test_auth . ok
> > > 
> > > 
> > > atzlinux@Debian-StarFive:~/libotr/tests/unit$ ./test_auth
> > > 1..5
> > > ok 1 - OTR auth info init is valid
> > > ok 2 - OTR auth info clear is valid
> > > ok 3 - OTR auth start v23 is valid
> > > ok 4 - Copy not done
> > > ok 5 - Copy OK
> > > 
> > I confirm that the problem is not visible anymore on riscv64, probably
> > due to the switch from gcc 8 to 10.
> > 
> > However the underlying bug is still there and might appear again with a
> > toolchain change, on riscv64 or another architecture. I am therefore
> > reopening the bug.
> > 
> > Regards
> > Aurelien
> 
> There is a possible is that the underlying bug perhaps had already fixed in 
> the some new version of one package.
> 
> Do this bug need to riscv porter team pay close attention to it?

No this bug can be ignored from the riscv point of view (unless it
reappears at some point ;-)

> I'm reviewing the bug list that has riscv64 tag:
> 
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-riscv%40lists.debian.org=riscv64

In that case the best is to keep the bug open, but remove it from that
user bug list. That should be done with that mail.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Bug#932927: closed by xiao sheng wen(肖盛文) (fixed in 4.1.1-5)

2022-06-17 Thread Aurelien Jarno
control: reopen 932927
control: found 932927 4.1.1-5

On 2022-06-17 08:33, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:libotr package:
> 
> #932927: libotr: buggy unit test: test_auth.c: test_auth_clear()
> 
> It has been closed by xiao sheng wen(肖盛文) .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact xiao sheng wen(肖盛文) 
>  by
> replying to this email.
> 
> 
> -- 
> 932927: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932927
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> From: "xiao sheng wen(肖盛文)" 
> To: 932...@bugs.debian.org, 932927-d...@bugs.debian.org
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
>  Thunderbird/91.10.0
> X-Spam-Status: No, score=-16.3 required=4.0 tests=BAYES_00,FREEMAIL_FROM,
>  PGPSIGNATURE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE
>  autolearn=ham autolearn_force=no version=3.4.2-bugs.debian.org_2005_01_02
> Date: Fri, 17 Jun 2022 16:24:31 +0800
> Subject: fixed in 4.1.1-5
> Message-ID: <235a1238-54d4-a34f-0060-6119cafad...@sina.com>
> 
> control: fixed -1 4.1.1-5
> 
> 
> tests/unit$ ./test_auth is run OK now:
> 
> 
> ./run.sh test_list
> unit/test_auth . ok
> 
> 
> atzlinux@Debian-StarFive:~/libotr/tests/unit$ ./test_auth
> 1..5
> ok 1 - OTR auth info init is valid
> ok 2 - OTR auth info clear is valid
> ok 3 - OTR auth start v23 is valid
> ok 4 - Copy not done
> ok 5 - Copy OK
> 

I confirm that the problem is not visible anymore on riscv64, probably
due to the switch from gcc 8 to 10.

However the underlying bug is still there and might appear again with a
toolchain change, on riscv64 or another architecture. I am therefore
reopening the bug.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Bug#1012311: libc6: invalid debug symbol for optind

2022-06-10 Thread Aurelien Jarno
control: reassign -1 gdb
control: found -1 gdb/10.1-1.7
control: found -1 gdb/11.2-1
control: affects -1 gdb

Hi,

On 2022-06-03 18:34, Mathis MARION wrote:
> Package: libc6
> Version: 2.31-13+deb11u3
> Severity: normal
> 
> Dear Maintainer,
> 
> Here is a simple example program:
> 
> 
> #include 
> 
> int main()
> {
> optind = 2;
> }
> 
> 
> I compiled it with 'gcc -g -O0' and ran it through gdb:
> 
> 
> (gdb) b main
> Breakpoint 1 at 0x1129: file main.c, line 5.
> (gdb) r
> Starting program: /home/marionm/test/optind/a.out 
> 
> Breakpoint 1, main () at main.c:5
> 5 optind = 2;
> (gdb) n
> 6 }
> (gdb) p optind
> $1 = 1
> (gdb) p 
> $2 = (int *) 0x77fa1344 
> (gdb) disassemble 
> Dump of assembler code for function main:
>0x5125 <+0>:   push   %rbp
>0x5126 <+1>:   mov%rsp,%rbp
>0x5129 <+4>:   movl   $0x2,0x2ef5(%rip)# 
> 0x8028 
>0x5133 <+14>:  mov$0x0,%eax
> => 0x5138 <+19>:  pop%rbp
>0x5139 <+20>:  ret
> End of assembler dump.
> (gdb) 
> 
> 
> We can see that the address used by GDB when accessing 'optind' is not the 
> same
> as the one present in the assembly code (0x77fa1344 vs 0x8028).

I confirm the issue.

> When running this experiment on Debian with the packaged gdb version 10 and 
> 11,
> we get the unexpected behavior described above. The same test run on Fedora 
> with
> gdb version 12 results in the expected behavior of seeing the same address on
> both sides.

The problem is reproducible on Debian and Fedora with both version 10
and 11, but not with GDB version 12, so it seems that the problem has
been fixed in that version.

> This issue might also be caused by gdb instead of libc but I don't have
> a deep enough understanding of the problem to ensure one or the other.

This definitely seems a problem with GDB, which appears to be fixed with
GDB 12. Reassigning the bug.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1012191: tzdata: /usr/share/zoneinfo/leap-seconds.list will expire on 2022-06-28 in Debian Stable 11.x/Bullseye

2022-06-09 Thread Aurelien Jarno
control: tag -1 + confirmed

On 2022-06-08 16:08, Paul Slootman wrote:
> severity 1012191 important
> thanks
> 
> The time is ticking, and the leap second data is now due to expire in 20
> days.

An update is planned before the deadline.

> There is a 2022a-1 version in testing. Could this be included in
> bullseye-updates and perhaps buster-updates? I've downloaded it manually
> and it seems fine in bullseye.

No you do not want to do that. 2022a-1 includes changes we might not
want in a stable update.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1012148: haskell-hslua-module-text_0.2.1-2.1_mips64el-buildd.changes REJECTED

2022-05-30 Thread Aurelien Jarno
Source: haskell-hslua-module-text
Severity: serious
Version: 0.2.1-2.1

On 2022-05-30 15:34, Debian FTP Masters wrote:
> libghc-hslua-module-text-dev_0.2.1-2.1_mips64el.deb: has 1 file(s) with a 
> timestamp too far in the past:
>   usr/share/doc/libghc-hslua-module-text-dev/changelog.gz (Thu Jan  1 
> 00:00:00 1970)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 



Bug#1012146: haskell-hslua-module-system_0.2.1-2.1_mips64el-buildd.changes REJECTED

2022-05-30 Thread Aurelien Jarno
Source: haskell-hslua-module-system
Severity: serious
Version: 0.2.1-2.1

On 2022-05-28 15:18, Debian FTP Masters wrote:
> libghc-hslua-module-system-dev_0.2.1-2.1_mips64el.deb: has 1 file(s) with a 
> timestamp too far in the past:
>   usr/share/doc/libghc-hslua-module-system-dev/changelog.gz (Thu Jan  1 
> 00:00:00 1970)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 



Bug#917602: python-fitsio 0.9.11+dfsg-4: FTBFS, alignment problem

2022-05-26 Thread Aurelien Jarno
On 2018-12-29 01:40, Steve McIntyre wrote:
> Source: python-fitsio
> Version: 0.9.11+dfsg-4
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: alignment
> 
> Hi!
> 
> I've been doing a full rebuild of the Debian archive, building all
> source packages targeting armel and armhf using arm64 hardware. We are
> planning in future to move all of our 32-bit armel/armhf builds to
> using arm64 machines, so this rebuild is to identify packages that
> might have problems with this configuration.
> 
> A feature of the arm64 kernel is that it does *not* support fixing up
> code with broken alignment, so code that might have built and run OK
> on our older armel/armhf build machines due to kernel fixups will now
> fail.
> 
> When building your package, I've found a bus error (aka alignment
> fault). The full log is online at
> 
>   
> https://www.einval.com/debian/arm/rebuild-logs/armel/FAIL/python-fitsio_0.9.11+dfsg-4_armel.log
> 
> for reference
> 
> I've done a quick bit of debugging to find the source of the
> bug. Here's a gdb stacktrace to demonstrate the problem. I'm not sure
> if the likely culprit is the test code here, or the underlying
> library.
> 
> (sid-armel)steve@maul:~/debian/build/python-fitsio/python-fitsio-0.9.11+dfsg$ 
> gdb /usr/bin/python2.7 ./.pybuild/cpython2_2.7_fitsio/build/core
> ...
> warning: Could not load shared library symbols for fitsio/_fitsio_wrap.so.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
> Core was generated by `python2.7 -m unittest discover -v'.
> Program terminated with signal SIGBUS, Bus error.
> #0  ffi8fi8 (input=input@entry=0x7, ntodo=ntodo@entry=1, scale= out>, zero=0, output=output@entry=0xff861368, status=status@entry=0xff868554) 
> at putcolj.c:1900
> 1900putcolj.c: No such file or directory.
> (gdb) bt
> #0  ffi8fi8 (input=input@entry=0x7, ntodo=ntodo@entry=1, scale= out>, zero=0, output=output@entry=0xff861368, status=status@entry=0xff868554) 
> at putcolj.c:1900
> #1  0xf5074ae4 in ffpcljj (fptr=0x1, colnum=-149821080, firstrow= out>, firstelem=, nelem=1, array=0x2303cef, status=0xff868554) 
> at putcolj.c:1442
> #2  0xf5074ce4 in ffpcljj (fptr=, colnum=, 
> firstrow=, firstelem=1, nelem=1, array=0x2303cef, 
> array@entry=0x1, status=status@entry=0xff868554)
> at putcolj.c:1371
> #3  0xf50669c4 in ffpcl (status=0xff868554, array=0x1, nelem=1, firstelem=1, 
> firstrow=-768257499031892296, colnum=, datatype= out>, fptr=)
> at putcol.c:739
> #4  ffpcl (fptr=, datatype=, colnum= out>, firstrow=1, firstelem=1, nelem=1, array=0x2303cef, status=0xff868554) 
> at putcol.c:668
> #5  0xf55699e0 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The problem comes from the following code in PyFITSObject_write_columns():

| for (irow=0; irowhttp://www.aurel32.net



Bug#1011178: python-fitsio: testsuite fails with cfitsio 4.1.0

2022-05-18 Thread Aurelien Jarno
control: tag -1 + fixed-upstream
control: forwarded -1 
https://github.com/esheldon/fitsio/commit/06e1e85e6d021c0cd60d0d990e07c5a2fb57f419

On 2022-05-17 23:25, Aurelien Jarno wrote:
> Source: python-fitsio
> Version: 1.1.7+dfsg-1
> Severity: normal
> Tags: upstream patch
> Forwarded: https://github.com/esheldon/fitsio/pull/349
> 
> The python-fitsio testsuite fails when ran against cfitsio 4.1.0:
> 
> | testCompressPreserveZeros (fitsio.test.TestReadWrite)
> | Test writing and reading gzip compressed image ... Warning: CFITSIO does 
> not allow subtractive_dither_2 when using Hcompress algorithm.
> | Will use subtractive_dither_1 instead.
> | FAIL
> 
> ...
> 
> | ==
> | FAIL: testCompressPreserveZeros (fitsio.test.TestReadWrite)
> | Test writing and reading gzip compressed image
> | --
> | Traceback (most recent call last):
> |   File "/usr/lib/python3/dist-packages/fitsio/test.py", line 1375, in 
> testCompressPreserveZeros
> | assert rdata[zind[0], zind[1]] == 0.0
> | AssertionError
> | 
> | --
> | Ran 60 tests in 1.072s
> 
> A full test log is available:
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-fitsio/21835539/log.gz
> 
> The problem is that cfitsio 4.1.0 removed support for
> SUBTRACTIVE_DITHER_2 when using the HCOMPRESS algorithm, which is
> exactly (one of) the configuration tested in testCompressPreserveZeros.
> 
> The fix is to stop testing the HCOMPRESS algorithm, a fix is available
> there:
> https://github.com/esheldon/fitsio/pull/349

This has now been merged upstream:
https://github.com/esheldon/fitsio/commit/06e1e85e6d021c0cd60d0d990e07c5a2fb57f419

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1011178: python-fitsio: testsuite fails with cfitsio 4.1.0

2022-05-17 Thread Aurelien Jarno
Source: python-fitsio
Version: 1.1.7+dfsg-1
Severity: normal
Tags: upstream patch
Forwarded: https://github.com/esheldon/fitsio/pull/349

The python-fitsio testsuite fails when ran against cfitsio 4.1.0:

| testCompressPreserveZeros (fitsio.test.TestReadWrite)
| Test writing and reading gzip compressed image ... Warning: CFITSIO does not 
allow subtractive_dither_2 when using Hcompress algorithm.
| Will use subtractive_dither_1 instead.
| FAIL

...

| ==
| FAIL: testCompressPreserveZeros (fitsio.test.TestReadWrite)
| Test writing and reading gzip compressed image
| --
| Traceback (most recent call last):
|   File "/usr/lib/python3/dist-packages/fitsio/test.py", line 1375, in 
testCompressPreserveZeros
| assert rdata[zind[0], zind[1]] == 0.0
| AssertionError
| 
| --
| Ran 60 tests in 1.072s

A full test log is available:
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-fitsio/21835539/log.gz

The problem is that cfitsio 4.1.0 removed support for
SUBTRACTIVE_DITHER_2 when using the HCOMPRESS algorithm, which is
exactly (one of) the configuration tested in testCompressPreserveZeros.

The fix is to stop testing the HCOMPRESS algorithm, a fix is available
there:
https://github.com/esheldon/fitsio/pull/349



Bug#1011069: decode-dimms does not detect SPD for kingston memory strips

2022-05-17 Thread Aurelien Jarno
control: reassign -1 src:linux
control: forcemerge 1001286 -1

On 2022-05-16 17:47, Сергей Фёдоров wrote:
> Package: i2c-tools
> Version: 4.3-2
> Severity: normal
> X-Debbugs-Cc: serfyo...@yandex.ru
> 
> Dear Maintainer,
> 
> 
> Problems:
> 
> 1. I want to see the contents of the SPD for each memory strip, but 
> decode-dimms
> (the i2c-tools 4.3-2 package) does not give this for this motherboard. But I 
> see
> it in the BIOS on computers boot and can change it.

decode-dimms uses the kernel spd or ee1004 drivers to access the content
of the EEPROM, and only parses the content. If your SPD EEPROM are not
recognized by the kernel, nothing can be done on the i2c-tools side. I
am therefore reassigning the bug to the kernel and merging it with the
one you already opened there.

> 2. Systems with more than 4 memory slots not supported yet, not instantiating 
> SPD.
> I solved this problem, which I described below.

Just increasing the limit from 4 to 8 won't make things work. The reason
for the limit is that above 4 DIMMs, the EEPROM are usually placed
behind a I2C mux (probably the chip at address 0x44 on your system).
Support for that needs to be added to the kernel.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1010509: [Pkg-javascript-devel] Bug#1010509: nodejs: add more info about build fail on riscv64

2022-05-05 Thread Aurelien Jarno
On 2022-05-05 11:36, Jérémy Lal wrote:
> Hi,
> 
> Le jeu. 5 mai 2022 à 11:12, Bo YU  a écrit :
> >
> >  ```
> >
> > Error: Unrecognized type: 'string\[]'.
> > Please, edit the type or update
> 'file:///<>/debian/doc-generator/type-parser.mjs'.
> > at file:///<>/debian/doc-generator/type-parser.mjs:297:15
> > ```
> 
> That's the documentation generator, non-fatal, just ignore it.
> 
> 
> > But it should no harm to build riscv64 packages from result at last.
> >
> > So maybe the rv-osuosl-02[0] machines has different with the real
> hardware?
> 
> Yes, maybe. CC-ing riscv64 porters about that.

rv-rr44-01 and rv-mullvad-0x are Unleashed boards
rv-osuosl-0x are Unmatched boards
Other are QEMU VMs.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1009814: android-platform-tools_29.0.6-8_s390x-buildd.changes REJECTED

2022-04-18 Thread Aurelien Jarno
Source: android-platform-tools
Version: 29.0.6-8
Severity: serious

On 2022-04-18 14:49, Debian FTP Masters wrote:
> 
> 
> Version check failed:
> Your upload included the binary package android-sdk-libsparse-utils, version 
> 29.0.6-8, for s390x,
> however testing already has version 1:10.0.0+r36-10.
> Uploads to unstable must have a higher version than present in testing.
> 
> Mapping sid to unstable.
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 



Bug#996262: libticables: Patch to add riscv64 support

2022-04-15 Thread Aurelien Jarno
On 2022-04-15 12:55, Ileana Dumitrescu wrote:
> Hi Aurelien,
> 
> > Yes, I can upload a package. Just prepare it on salsa and tell me when it's 
> > ready. I can fetch it from there, build it and upload it.
> 
> The package is ready on salsa now. I appreciate you taking care of the 
> upload. I am getting more involved in debian packaging and porting work, so 
> please feel free to reach out if you have any tasks or bugs that you need 
> help with.

I just get got a quick look, and it appears that while the package looks
ready, the changelog still says "UNRELEASED".

Could you please change it to unstable, and create the corresponding
tag? That's basically running "dch -r", "git commit" and "git tag", but
that might be done in a single step with other tools depending on the
workflow you use (for instance debcommit or gbp).

I'll just doing the building and signing part, that way you will
correctly appear as the one who have done the job.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Bug#1009691: libusb-1.0-0: Some USB microphone takes sounds as very low volume

2022-04-14 Thread Aurelien Jarno
Hi,

On 2022-04-14 19:41, Hideki Yamane wrote:
> Package: libusb-1.0-0
> Version: 2:1.0.26-1
> Severity: normal
> X-Debbugs-Cc: henr...@debian.org
> 
> Dear Maintainer,
> 
>  With upgrading libusb-1.0-0 package from 2:1.0.25-1 to 2:1.0.26-1,
>  my USB microphone (marantz PROFESSIONAL pod pack1, "C-Media Electronics, Inc.
>  Blue Snowball" with lsusb) just takes sounds as very low volume. However,
>  Other USB mic (logicool webcam) just works fine with both versions.

Could you please point me to which software you use with this
microphone? Very few softwares use libusb to grab the audio.

>  Downgrading to 2:1.0.25-1 solves this problem.
>  
>  USB microphone's info via lsusb is attached.
>  Please let me know if you need more information to investigate this issue.
>  Thanks.

Could you please run your application with the LIBUSB_DEBUG environment
variable set to 99 for both versions 2:1.0.25-1 and 2:1.0.26-1, and send
me the output?

Thanks
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#996262: libticables: Patch to add riscv64 support

2022-04-13 Thread Aurelien Jarno
Hi 

On 2022-04-11 15:56, Ileana Dumitrescu wrote:
> Hi Lionel and Aurelien,
> 
> > ... you should indeed include Aurelien's patch in the Debian package :)
> 
> I just uploaded Aurelien's patch and some other debian package updates to the 
> libticables salsa repo at https://salsa.debian.org/science-team/libticables/. 
> When the next upstream release is ready, I will remove the patch from the 
> debian folder.

Thanks!

> Aurelien, thank you for submitting the patch! Are you able to upload these 
> updates into debian? I do not have debian developer privileges (but am hoping 
> to in the near future!). 

Yes, I can upload a package. Just prepare it on salsa and tell me when
it's ready. I can fetch it from there, build it and upload it.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Bug#983457: libc6-i386: /lib32/libpthread-2.31.so with debug symbols is installed instead of a stripped version

2022-04-06 Thread Aurelien Jarno
control: notfound -1 2.31-13+deb11u3
control: notfound -1 2.33-7
control: close -1

On 2022-04-06 11:18, Mathieu Malaterre wrote:
> Control: found -1 2.33-7
> 
> Here is what I see from my sid schroot (amd64) today:
> 
> % file /lib32/libpthread-2.33.so /lib/x86_64-linux-gnu/libpthread-2.33.so
> /lib32/libpthread-2.33.so:ELF 32-bit LSB shared
> object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter
> /lib/ld-linux.so.2,
> BuildID[sha1]=219fd74148d97cff079eb2f985248736a99b97e4, for GNU/Linux
> 3.2.0, not stripped
> /lib/x86_64-linux-gnu/libpthread-2.33.so: ELF 64-bit LSB shared
> object, x86-64, version 1 (SYSV), dynamically linked, interpreter
> /lib64/ld-linux-x86-64.so.2,
> BuildID[sha1]=18adf73bf752fe671bdf5c046f15dda9c293834d, for GNU/Linux
> 3.2.0, not stripped

Nope the bug has really been fixed. What happens there is that we don't
remove the non-dynamic symbol table so that GDB can still work on
multithreaded programs, but the debug symbols are not present. You can
check that yourself by running strip --strip-debug on (a copy of) those
files and check that they are unchanged.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1008507:

2022-04-05 Thread Aurelien Jarno
Hi,

On 2022-03-29 17:53, Joshua Hudson wrote:
> diff -ur glibc.orig/glibc/sysdeps/unix/sysv/linux/pathconf.c
> glibc/glibc/sysdeps/unix/sysv/linux/pathconf.c
> --- glibc.orig/glibc/sysdeps/unix/sysv/linux/pathconf.c2022-03-29
> 17:50:12.558027042 -0700
> +++ glibc/glibc/sysdeps/unix/sysv/linux/pathconf.c2022-03-29
> 17:52:33.262157543 -0700
> @@ -183,6 +183,11 @@
>  case XFS_SUPER_MAGIC:
>return XFS_LINK_MAX;
> 
> +case MSDOS_SUPER_MAGIC:
> +#ifdef EXFAT_SUPER_MAGIC // For when it gets added in about 30 years
> +case EXFAT_SUPER_MAGIC:
> +#endif
> +  return 1;
>  case LUSTRE_SUPER_MAGIC:
>return LUSTRE_LINK_MAX;

If you ended with a patch, the best is probably to submit it upstream to
libc-al...@sourceware.org .

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1008807: ksystemstats: Please switch Build-Depends to libsensors-dev (from libsensors4-dev)

2022-04-01 Thread Aurelien Jarno
Package: ksystemstats
Version: 5.24.4-1
Severity: normal
User: aure...@debian.org
Usertags: libsensors-dev-transition

Dear maintainer,

ksystemstats build-depends on libsensors4-dev, the development package
from lm-sensors. For historical reasons the development package is
versioned. Following the transition of the library to libsensors5 a few
years ago, it made sense to rename the development package to
libsensors-dev.

In that regard a libsensors4-dev is a transitional package depending o
libsensors-dev that is going to be removed soon. Your package therefore
needs an update. The change should just be a matter of running:

  sed -i -e 's/libsensors4-dev/libsensors-dev/g' debian/control

Thanks,
Aurelien



Bug#1008174: libc6: poll() spuriously returns EINTR

2022-03-26 Thread Aurelien Jarno
Hi,

On 2022-03-23 18:07, Rémi Denis-Courmont wrote:
> Package: libc6
> Version: 2.34-0experimental3
> Severity: important
> 
> Dear Maintainer,
> 
> In the example below, glibc 2.34 from experimental causes a spurious
> EINTR error in the poll() call from the child thread. It seems that
> thread cancellation causes the poll() to be spuriously interrupted,
> even though the cancellation is explicitly disabled at that time.

Thanks for the example, it's very useful to reproduce and understand the
issue.

> As far as I understand, POSIX allows (or even requires) thread
> cancellation to be essentially like a signal interruption, save for
> ending the thread. But that is *only* from the moment that cancellation
> is effected. Cancellation cannot be effected while it is disabled by
> definition, so the behaviour from glibc seems wrong here.

poll() is a cancellation point. It appears to me that POSIX actually
allows this behaviour for cancellation points:

"The side effects of acting upon a cancellation request while suspended
during a call of a function are the same as the side effects that may be
seen in a single-threaded program when a call to a function is
interrupted by a signal and the given function returns [EINTR]. Any such
side effects occur before any cancellation cleanup handlers are called."

https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html

> This regression is known to break the test suite from the VLC package.
> Rolling back to 2.33 from unstable solves the problem.

The regression has been introduced by this commit:
https://sourceware.org/git/?p=glibc.git;a=commit;h=26cfbb7162ad364d53d69f6d482f2d87b5950524

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1007746: buster-pu: package glibc/2.28-10+deb10u1

2022-03-17 Thread Aurelien Jarno
On 2022-03-17 17:51, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
> 
> On Wed, 2022-03-16 at 00:50 +0100, Aurelien Jarno wrote:
> > A big part of the changes have been in the buster git branch for many
> > months, but I failed to submit the package for a point release up to
> > now. What triggered me to look at it again is breakage in the preinst
> > script when running on kernel x.y.z with z > 255.
> > 
> > In other changes are just an (old) pull from the stable branch,
> > fixing
> > a few important bugs.
> 
> Please go ahead, thanks.
> 
> As glibc produces a udeb, I'm tagging the bug and CCing accordingly.
> 

Thanks for the review despite the close deadline. I have just uploaded
it.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1005949: bullseye-pu: package glibc/2.31-13+deb11u3

2022-03-17 Thread Aurelien Jarno
On 2022-03-17 17:49, Adam D. Barratt wrote:
> On Tue, 2022-03-15 at 20:33 +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed d-i
> > 
> > On Thu, 2022-02-17 at 23:15 +0100, Aurelien Jarno wrote:
> > > There are multiple fixes in this upload:
> > > - 4 security bugs
> > > - a fix to avoid preinst script failure when running on kernel
> > > x.y.z
> > >   with z > 255. 
> > > - a fix to avoid changes to /etc/nsswitch.conf to be reverted on
> > > upgrade
> > > 
> > > [ Impact ]
> > > Installation will be left vulnerable to security issues and upgrade
> > > from buster will fail when running recent upstream stable kernels.
> > > 
> > 
> > This looks OK to me, thanks.
> > 
> > As glibc produces a udeb, this will want a KiBi-ack; CCing and
> > tagging
> > accordingly.
> 
> As we're getting very close to the window for 11.3 closing, please feel
> free to upload.

Thanks, I have just uploaded it.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1007750: libnfsidmap_0.25-6+b1_mips64el-buildd.changes REJECTED

2022-03-16 Thread Aurelien Jarno
Source: libnfsidmap
Version: 0.25-6
Severity: serious

On 2022-03-13 15:58, Debian FTP Masters wrote:
> Version check failed:
> Your upload included the binary package libnfsidmap-dev, version 0.25-6+b1, 
> for mips64el,
> however testing already has version 1:2.6.1-1.
> Uploads to unstable must have a higher version than present in testing.
> 
> Mapping sid to unstable.
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 



Bug#1007746: buster-pu: package glibc/2.28-10+deb10u1

2022-03-15 Thread Aurelien Jarno
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
A big part of the changes have been in the buster git branch for many
months, but I failed to submit the package for a point release up to
now. What triggered me to look at it again is breakage in the preinst
script when running on kernel x.y.z with z > 255.

In other changes are just an (old) pull from the stable branch, fixing
a few important bugs.

[ Impact ]
The preinst script fixes are important in order for the security team to
provide kernels with minor version greater than 255. Given that the
current stable kernel from the 4.19 branch is 4.19.234, it is likely to
happen in a few months.

[ Tests ]
The preinst changes have been in testing for more than 6 months and have
been submitted to stable (see bug#1005949).

The other changes have been in stable and in testing/sid for more than 2
years. They come with additional tests, which actually represent a
significant part of the diff.

[ Risks ]
The risk can probably be considered low, as the changes have been tested
in testing/sid and upstream or on other distributions.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

Let me comment the changelog:

  * debian/patches/git-updates.diff: update from upstream stable branch
(Closes: #930697):

This is an (old) pull from the upstream stable branch, here are the
details:

- Add more integrity check to malloc() function.

This adds a few more early checks to the malloc() function, to detect
memory corruption early to reduce the attack surface.

- Fix crash in _IO_wfile_sync.

This fixes a stack smashing in fgetwc() with some locales. See
https://sourceware.org/bugzilla/show_bug.cgi?id=20568 for more details.

- Fix bad free() in libdl if dlerror() is not used.  Closes: #953257.

This fixes a wrong call to free() that might causes a crash when running
under valgrind.

- Fix overflow in glibc.malloc.tcache_count tunable.

This limit the user provided value of the glibc.malloc.tcache_count
tunable (from the GLIBC_TUNABLES environment variable) to avoid a later
assertion in malloc. See
https://sourceware.org/bugzilla/show_bug.cgi?id=24531 for more details.

- Fix old x86 applications crash on exit() under valgrind.

See https://sourceware.org/bugzilla/show_bug.cgi?id=24228 for more
details.

- Remove copy_file_range emulation. The kernel interface has at evolved
  and the glibc emulation doesn't match it anymore, so it's better for
  it to return -ENOSYS. This only impacts Linux kernels << 4.8.

Note that even old-old-stable runs kernel 4.9, so this is mostly useful
for users which run older kernels for various reasons, and which might
experience data corruption in the worst case.

See https://sourceware.org/bugzilla/show_bug.cgi?id=24744 for more
details.

- Avoid lazy binding of symbols that may follow a variant PCS on arm64, to
  support binaries using AdvSIMD and SVE vector calls.

This is need to run binaries using ISA extension. ARM SVE is starting to
become a bit more common nowadays.

- Fix large mmap64 offset for the N32 ABI on mips/mipsel/mips64el.

This change fixes a bug introduced in glibc 2.26 on the mips N32 ABI.
Note that it is not the ABI used by any of the official ports, but is
solely shipped as multilib. See
https://sourceware.org/bugzilla/show_bug.cgi?id=20568 for more details.

- Improve string functions performances on arm64.

This is obviously not fully stable material, but upstream considered it
is important enough for stable. Note that the corresponding code is
unchanged since this optimization, in other words the code in glibc 2.35
is still the same. In addition it comes with a fix for a corner
case: https://sourceware.org/bugzilla/show_bug.cgi?id=23637

  * debian/patches/any/git-libio-stdout-putc.diff: refresh.

This is just a rebase as there were minor conflict with the above patch.

  * debian/debhelper.in/libc.preinst: simplify the version comparison by only
comparing the two first parts, now that kernel 2.X are not supported
anymore.  Closes: #1004861.
  * debian/debhelper.in/libc.preinst: drop the check for kernel release > 255
now that glibc and preinstall script are fixed.  Closes: #987266.

These two changes just drop the comparison for the z part in kernel
version x.y.z, as z is not relevant anymore since kernel 3.0, and the
minimum supported kernel version since buster is 3.2. This fixes cases
where z > 255 as with recent upstream stable kernels.
diff --git a/debian/changelog b/debian/changelog
index 0cbb4f9a..cb7fa65c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,29 @@
+glibc (2.28-10+deb10u1) buster; urgency=medium
+
+  [ Aurelien Jarno ]
+  * debian/patches/git-updat

Bug#1006813: reportbug: lm-sensors.service executes sensors twice

2022-03-06 Thread Aurelien Jarno
Hi,

On 2022-03-05 18:21, Armin Wolf wrote:
> Package: lm-sensors
> Version: 1:3.6.0-7
> Severity: normal
> 
> In lm-sensors.service, the sensors program is executed twice.
> The second execution happens without the -s flag, causing
> sensors to read all sensors and print the results to the
> system log.

Yes, the second call is actually done on purpose due to the way the
alarms work. The "sensors -s" sets the minimum and maximum limits,
however the ALARM flags are still latched until the next time the
sensors values are read. This is the purpose of the "sensors" call just
after, in other words it makes sure to clear the ALARM flags that might
have been triggered by different limits.

See /usr/share/doc/lm-sensors/README.Debian.gz to see how the ALARM
flags work.

> On a Dell Inspiron 3505 however, this results in a freeze for
> ~4 seconds during boot, caused by the second (and pointless)
> execution of sensors coupled with very slow sensor reads.

As said above the second call to sensors is not pointless. The bug is
actually on the kernel module side. You should get it fixed instead, and
in the meantime you can probably blacklist the module.

> In order to fix this issue, the second (and pointless) execution
> of sensors should be omited.

Not it shouldn't as it is not pointless. The kernel should be fixed
instead.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#987266: preinst check for kernel release > 255 may no longer be needed

2022-03-04 Thread Aurelien Jarno
On 2022-03-04 10:22, Emilio Pozuelo Monfort wrote:
> On 04/03/2022 09:50, Aurelien Jarno wrote:
> > On 2022-03-04 09:19, Emilio Pozuelo Monfort wrote:
> > > Hi,
> > > 
> > > On Sun, 26 Sep 2021 09:57:02 +0200 Salvatore Bonaccorso 
> > >  wrote:
> > > > Hi Aurelien,
> > > > 
> > > > On Tue, Apr 20, 2021 at 06:36:33PM +0200, Andras Korn wrote:
> > > > > Package: libc6
> > > > > Version: 2.31-11
> > > > > Severity: normal
> > > > > > Hi,
> > > > > > due to
> > > > > https://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f
> > > > > (a commit from 2004) the preinst script for glibc checks whether the
> > > > > "z" in the "x.y.z" of the kernel version is less than 255. If yes,
> > > > > the package refuses to install.
> > > > > > I hit this problem on a box with a custom 4.9.266 kernel.
> > > > > > Based on this lkml thread:
> > > > > https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/,
> > > > > the check is no longer needed because the kernel caps the version
> > > > > code it reports to 255, even if uname prints a higher number.
> > > > > > Of course, you could conceivably still hit the problem with earlier
> > > > > kernels, so I suppose the logic of the check should be modified, not
> > > > > removed entirely, to be technically correct.
> > > > > > If forced at gunpoint to make a guess, I would guess, though, that
> > > > > removing the check would have very little actual impact; it also
> > > > > doesn't protect the user from installing a kernel with an
> > > > > unsupported version number after having installed glibc.
> > > > 
> > > > Prompted by
> > > > https://lore.kernel.org/stable/yvaholtsb0nk0...@kroah.com/T/#t and
> > > > given this was addressed with
> > > > https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900
> > > > is this something we should do consider as well for the older releases
> > > > where it is not acutally needed for people compiling their own custom
> > > > kernels?
> > > 
> > > Another stretch user brought this up [1]. I suppose there are and as time
> > > passes (with current stable kernel versions getting higher) there will be
> > > more users affected by this in buster and bullseye. Have you further
> > > considered including this fix in a proposed-update?
> > 
> > Yep I have submitted #1005906 for bullseye, and I have committed the fix
> > to the buster branch, but not yet submitted the bug.
> 
> I was wondering what docker had to do with all this, until I realized you
> meant #1005949 :)

Oops, sorry about that.

> > Stretch is going to be more complicated as we still support 2.6.32
> > kernels, which means the third version level actually still makes sense.
> 
> I'm surprised we support that. However in any case we wouldn't need to

We disabled it at some point but we got strong pressure to re-enable it
as it is the last version supported by OpenVZ.

> backport [1], we could just backport [2] and support both 2.6.32 as well as
> e.g. 4.14.264. Wouldn't that work?

If we backport only [2], it means [1] doesn't work correctly as it
assumes that the third version level is < 255, just like glibc
internals.

Aurelien

> [1] 
> https://salsa.debian.org/glibc-team/glibc/-/commit/5452b62ded81132ebedf3db82577de5277479b27
> [2] 
> https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#987266: preinst check for kernel release > 255 may no longer be needed

2022-03-04 Thread Aurelien Jarno
On 2022-03-04 09:19, Emilio Pozuelo Monfort wrote:
> Hi,
> 
> On Sun, 26 Sep 2021 09:57:02 +0200 Salvatore Bonaccorso  
> wrote:
> > Hi Aurelien,
> > 
> > On Tue, Apr 20, 2021 at 06:36:33PM +0200, Andras Korn wrote:
> > > Package: libc6
> > > Version: 2.31-11
> > > Severity: normal
> > > > Hi,
> > > > due to
> > > https://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f
> > > (a commit from 2004) the preinst script for glibc checks whether the
> > > "z" in the "x.y.z" of the kernel version is less than 255. If yes,
> > > the package refuses to install.
> > > > I hit this problem on a box with a custom 4.9.266 kernel.
> > > > Based on this lkml thread:
> > > https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/,
> > > the check is no longer needed because the kernel caps the version
> > > code it reports to 255, even if uname prints a higher number.
> > > > Of course, you could conceivably still hit the problem with earlier
> > > kernels, so I suppose the logic of the check should be modified, not
> > > removed entirely, to be technically correct.
> > > > If forced at gunpoint to make a guess, I would guess, though, that
> > > removing the check would have very little actual impact; it also
> > > doesn't protect the user from installing a kernel with an
> > > unsupported version number after having installed glibc.
> > 
> > Prompted by
> > https://lore.kernel.org/stable/yvaholtsb0nk0...@kroah.com/T/#t and
> > given this was addressed with
> > https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900
> > is this something we should do consider as well for the older releases
> > where it is not acutally needed for people compiling their own custom
> > kernels?
> 
> Another stretch user brought this up [1]. I suppose there are and as time
> passes (with current stable kernel versions getting higher) there will be
> more users affected by this in buster and bullseye. Have you further
> considered including this fix in a proposed-update?

Yep I have submitted #1005906 for bullseye, and I have committed the fix
to the buster branch, but not yet submitted the bug.

Stretch is going to be more complicated as we still support 2.6.32
kernels, which means the third version level actually still makes sense.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#972525: fixed in gnupg2 2.2.27-1

2022-02-28 Thread Aurelien Jarno
control: reopen 972525
control: found 972525 gnupg2/2.2.27-2

On 2021-02-08 23:18, Debian FTP Masters wrote:
>* debian/patches/gpg-change-agent-spawn-2019-07-24-v2.patch: New patch to
>  fix a race condition, backported from master (Closes: #868550, #972525).

Although it *seems* to happen less often, we still observe the failure
from time to time on the buildds. For instance:

Signature with key '37B76E354F4D3F4EB64D699B374AD85D2226CD3D' requested:
 signfile buildinfo /home/buildd/build/linux_5.10.92-2_amd64-buildd.buildinfo 
37B76E354F4D3F4EB64D699B374AD85D2226CD3D
gpg: can't connect to the agent: IPC connect call failed
gpg: keydb_search failed: No agent running
gpg: skipped "37B76E354F4D3F4EB64D699B374AD85D2226CD3D": No agent running
gpg: /tmp/debsign.12nNJjLy/linux_5.10.92-2_amd64-buildd.buildinfo: clear-sign 
failed: No agent running
debsign: gpg error occurred!  Aborting


signature.asc
Description: PGP signature


Bug#1006342: bullseye-pu: package usb.ids/2022.02.15-0+deb11u1

2022-02-25 Thread Aurelien Jarno
control: retitle -1 bullseye-pu: package usb.ids/2022.02.15-0+deb11u1

On 2022-02-23 23:31, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> [ Reason ]
> This new upstream version of the USB ID database adds a few USB devices.
> 
> [ Impact ]
> New USB devices won't be displayed with a human readable name for
> package using this database.
> 
> [ Tests ]
> There is no test associated with this database. This package only
> contains data, no code.
> 
> [ Risks ]
> Risks are very low, such update are routinely done in stable.
> 
> [ Checklist ]
>   [x] *all* changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in (old)stable
>   [x] the issue is verified as fixed in unstable
> 
> [ Changes ]
> I would like to do an update of the usb.ids package to add/update around
> ~150 USB devices to the usb.ids database. Those changes are already in
> testing/sid. I have figured out that it's easier to just upload the
> package from testing/sid with a new changelog entry, the only useless
> change is the update of the Standards-Version field.
> 
> [ Other info ]
> Given the changes are minimal, I have already uploaded the package to
> the archive. Thanks for considering.

Adam pointed me on IRC that I got the version wrong, using deb10u1
instead of deb11u1. I have therefore uploaded a fixed version. Please
find attached the new debdiff.

Regards
Aurelien
diff -Nru usb.ids-2021.06.06/debian/changelog 
usb.ids-2022.02.15/debian/changelog
--- usb.ids-2021.06.06/debian/changelog 2021-06-06 22:58:30.0 +0200
+++ usb.ids-2022.02.15/debian/changelog 2022-02-25 22:32:21.0 +0100
@@ -1,3 +1,34 @@
+usb.ids (2022.02.15-0+deb11u1) bullseye; urgency=medium
+
+  * Upload to bullseye.
+
+ -- Aurelien Jarno   Fri, 25 Feb 2022 22:32:21 +0100
+
+usb.ids (2022.02.15-1) unstable; urgency=medium
+
+  * New upstream version.
+
+ -- Aurelien Jarno   Tue, 15 Feb 2022 23:51:27 +0100
+
+usb.ids (2021.12.24-1) unstable; urgency=medium
+
+  * New upstream version.
+  * Bump Standards-Version to 4.6.0 (no changes).
+
+ -- Aurelien Jarno   Sat, 25 Dec 2021 16:44:16 +0100
+
+usb.ids (2021.07.19-1) unstable; urgency=medium
+
+  * New upstream version.
+
+ -- Aurelien Jarno   Wed, 21 Jul 2021 19:14:18 +0200
+
+usb.ids (2021.07.01-1) unstable; urgency=medium
+
+  * New upstream version.
+
+ -- Aurelien Jarno   Sat, 10 Jul 2021 14:33:27 +0200
+
 usb.ids (2021.06.06-1) unstable; urgency=medium
 
   * New upstream version.
@@ -18,19 +49,19 @@
 
 usb.ids (2021.01.29-1) unstable; urgency=medium
 
-  * New upstream version. 
+  * New upstream version.
 
  -- Aurelien Jarno   Mon, 01 Feb 2021 06:39:29 +0100
 
 usb.ids (2021.01.26-1) unstable; urgency=medium
 
-  * New upstream version. 
+  * New upstream version.
 
  -- Aurelien Jarno   Tue, 26 Jan 2021 22:26:58 +0100
 
 usb.ids (2021.01.22-1) unstable; urgency=medium
 
-  * New upstream version. 
+  * New upstream version.
   * Bump Standards-Version to 4.5.1 (no changes).
 
  -- Aurelien Jarno   Sat, 23 Jan 2021 09:03:12 +0100
diff -Nru usb.ids-2021.06.06/debian/control usb.ids-2022.02.15/debian/control
--- usb.ids-2021.06.06/debian/control   2021-01-23 09:02:59.0 +0100
+++ usb.ids-2022.02.15/debian/control   2021-12-25 16:42:43.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Aurelien Jarno 
 Build-Depends: debhelper-compat (= 12)
-Standards-Version: 4.5.1
+Standards-Version: 4.6.0
 Rules-Requires-Root: no
 Homepage: http://www.linux-usb.org/usb-ids.html
 
diff -Nru usb.ids-2021.06.06/usb.ids usb.ids-2022.02.15/usb.ids
--- usb.ids-2021.06.06/usb.ids  2021-06-06 21:34:10.0 +0200
+++ usb.ids-2022.02.15/usb.ids  2022-02-15 21:34:10.0 +0100
@@ -9,8 +9,8 @@
 #  The latest version can be obtained from
 #  http://www.linux-usb.org/usb.ids
 #
-# Version: 2021.06.06
-# Date:2021-06-06 20:34:10
+# Version: 2022.02.15
+# Date:2022-02-15 20:34:10
 #
 
 # Vendors, devices and interfaces. Please keep sorted.
@@ -70,6 +70,8 @@
ac02  ATV Turbo / Rally2 Dual Channel USB 2.0 Flash Drive
 0386  LTS
0001  PSX for USB Converter
+03c3  ZWO
+   120e  ASI120MC-S Planetary Camera
 03d9  Shenzhen Sinote Tech-Electron Co., Ltd
0499  SE340D PC Remote Control
 03da  Bernd Walter Computer Technology
@@ -118,6 +120,7 @@
2064  Interfaceless Control-Only LUFA Devices
2065  LUFA Test and Measurement Demo Application
2066  LUFA Multiple Report HID Demo
+   2067  LUFA HID Class Bootloader
2068  LUFA Virtual Serial/Mass Storage Demo
2069  LUFA Webserver Project
2103  JTAG ICE mkII
@@ -348,6 +351,7 @@
1617  LaserJet 3015
161d  Wireless Rechargeable Optical Mouse (HID)
1624 

Bug#1006402: bullseye-pu: package debian-ports-archive-keyring/2022.02.15~deb11u1

2022-02-24 Thread Aurelien Jarno
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
The debian-ports-archive-keyring in bullseye does not include the 2023
key that has been created recently. Although it will start being used in
~10 months, it's a good idea to include it in a point release before we
forget doing so.

[ Impact ]
Users of the debian-ports archive won't be able to validate the archive
signature after January 1st, 2023.

[ Tests ]
There is no test associated with this package. This package only
contains "data", no code. 

[ Risks ]
Risks are very low, key addition is done regularly every year.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
The change consist in the addition of the 2023 key, the move of the 2021
key to the removed keyring, and update of the Standards-Version field.
The later is not relevant for an update to stable, but I have figured
out that it's easier and less error prone to just upload the package
from testing/sid with a new changelog entry.

[ Other info ]
Given the changes are minimal, I have already uploaded the package to
the archive. Thanks for considering.



Bug#1006342: bullseye-pu: package usb.ids/2022.02.15-0+deb10u1

2022-02-23 Thread Aurelien Jarno
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
This new upstream version of the USB ID database adds a few USB devices.

[ Impact ]
New USB devices won't be displayed with a human readable name for
package using this database.

[ Tests ]
There is no test associated with this database. This package only
contains data, no code.

[ Risks ]
Risks are very low, such update are routinely done in stable.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
I would like to do an update of the usb.ids package to add/update around
~150 USB devices to the usb.ids database. Those changes are already in
testing/sid. I have figured out that it's easier to just upload the
package from testing/sid with a new changelog entry, the only useless
change is the update of the Standards-Version field.

[ Other info ]
Given the changes are minimal, I have already uploaded the package to
the archive. Thanks for considering.
diff -Nru usb.ids-2021.06.06/debian/changelog 
usb.ids-2022.02.15/debian/changelog
--- usb.ids-2021.06.06/debian/changelog 2021-06-06 22:58:30.0 +0200
+++ usb.ids-2022.02.15/debian/changelog 2022-02-23 23:22:16.0 +0100
@@ -1,3 +1,34 @@
+usb.ids (2022.02.15-0+deb10u1) bullseye; urgency=medium
+
+  * Upload to bullseye.
+
+ -- Aurelien Jarno   Wed, 23 Feb 2022 23:22:16 +0100
+
+usb.ids (2022.02.15-1) unstable; urgency=medium
+
+  * New upstream version.
+
+ -- Aurelien Jarno   Tue, 15 Feb 2022 23:51:27 +0100
+
+usb.ids (2021.12.24-1) unstable; urgency=medium
+
+  * New upstream version.
+  * Bump Standards-Version to 4.6.0 (no changes).
+
+ -- Aurelien Jarno   Sat, 25 Dec 2021 16:44:16 +0100
+
+usb.ids (2021.07.19-1) unstable; urgency=medium
+
+  * New upstream version.
+
+ -- Aurelien Jarno   Wed, 21 Jul 2021 19:14:18 +0200
+
+usb.ids (2021.07.01-1) unstable; urgency=medium
+
+  * New upstream version.
+
+ -- Aurelien Jarno   Sat, 10 Jul 2021 14:33:27 +0200
+
 usb.ids (2021.06.06-1) unstable; urgency=medium
 
   * New upstream version.
@@ -18,19 +49,19 @@
 
 usb.ids (2021.01.29-1) unstable; urgency=medium
 
-  * New upstream version. 
+  * New upstream version.
 
  -- Aurelien Jarno   Mon, 01 Feb 2021 06:39:29 +0100
 
 usb.ids (2021.01.26-1) unstable; urgency=medium
 
-  * New upstream version. 
+  * New upstream version.
 
  -- Aurelien Jarno   Tue, 26 Jan 2021 22:26:58 +0100
 
 usb.ids (2021.01.22-1) unstable; urgency=medium
 
-  * New upstream version. 
+  * New upstream version.
   * Bump Standards-Version to 4.5.1 (no changes).
 
  -- Aurelien Jarno   Sat, 23 Jan 2021 09:03:12 +0100
diff -Nru usb.ids-2021.06.06/debian/control usb.ids-2022.02.15/debian/control
--- usb.ids-2021.06.06/debian/control   2021-01-23 09:02:59.0 +0100
+++ usb.ids-2022.02.15/debian/control   2021-12-25 16:42:43.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Aurelien Jarno 
 Build-Depends: debhelper-compat (= 12)
-Standards-Version: 4.5.1
+Standards-Version: 4.6.0
 Rules-Requires-Root: no
 Homepage: http://www.linux-usb.org/usb-ids.html
 
diff -Nru usb.ids-2021.06.06/usb.ids usb.ids-2022.02.15/usb.ids
--- usb.ids-2021.06.06/usb.ids  2021-06-06 21:34:10.0 +0200
+++ usb.ids-2022.02.15/usb.ids  2022-02-15 21:34:10.0 +0100
@@ -9,8 +9,8 @@
 #  The latest version can be obtained from
 #  http://www.linux-usb.org/usb.ids
 #
-# Version: 2021.06.06
-# Date:2021-06-06 20:34:10
+# Version: 2022.02.15
+# Date:2022-02-15 20:34:10
 #
 
 # Vendors, devices and interfaces. Please keep sorted.
@@ -70,6 +70,8 @@
ac02  ATV Turbo / Rally2 Dual Channel USB 2.0 Flash Drive
 0386  LTS
0001  PSX for USB Converter
+03c3  ZWO
+   120e  ASI120MC-S Planetary Camera
 03d9  Shenzhen Sinote Tech-Electron Co., Ltd
0499  SE340D PC Remote Control
 03da  Bernd Walter Computer Technology
@@ -118,6 +120,7 @@
2064  Interfaceless Control-Only LUFA Devices
2065  LUFA Test and Measurement Demo Application
2066  LUFA Multiple Report HID Demo
+   2067  LUFA HID Class Bootloader
2068  LUFA Virtual Serial/Mass Storage Demo
2069  LUFA Webserver Project
2103  JTAG ICE mkII
@@ -348,6 +351,7 @@
1617  LaserJet 3015
161d  Wireless Rechargeable Optical Mouse (HID)
1624  Smart Card Keyboard - JP
+   1647  Z27n G2 Monitor Hub
1702  PhotoSmart 380 series
1704  DeskJet 948C
1705  ScanJet 5590
@@ -437,6 +441,7 @@
2805  Scanjet G2710
2811  PSC-2100
2817  Color LaserJet 2840
+   2841  OMEN MINDFRAME [3XT27AA]
2902  PhotoSmart A820 series
2911  PSC 2200
2917  LaserJet 2420
@@ -705,6 +710,7 @@
ba02  PhotoSmart 8100 series
bb02  PhotoSmart 8400 series

Bug#1005906: Strace / Docker build output

2022-02-18 Thread Aurelien Jarno
reassign -1 docker.io
retitle -1 docker.io: docker seccomp filter does not allow faccessat2
affect -1 src:glibc

Hi,

On 2022-02-18 11:58, David Eccles (gringer) wrote:
> rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8)
> = 0
> rt_sigaction(SIGINT, {sa_handler=0x562a34911a20, sa_mask=~[RTMIN RT_1],
> sa_flags=SA_RESTORER, sa_restorer=0x7f0a2ff79910}, NULL, 8) = 0
> rt_sigaction(SIGQUIT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8)
> = 0
> rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
> sa_flags=SA_RESTORER, sa_restorer=0x7f0a2ff79910}, NULL, 8) = 0
> rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8)
> = 0
> rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
> sa_flags=SA_RESTORER, sa_restorer=0x7f0a2ff79910}, NULL, 8) = 0
> read(10, "#!/bin/sh\nif test -x /usr/bin/he"..., 8192) = 103
> syscall_0x(0xff9c, 0x562a3655e490, 0x1, 0x200,
> 0x562a3655e4b0, 0x7f0a300f9c00) = -1 EPERM (Operation not permitted)

The problem is there. The above syscall that is not recognized and
forbidden by docker is faccessat2, which is used since glibc 2.33.

I am therefore reassigning the bug to the docker.io package.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1005949: bullseye-pu: package glibc/2.31-13+deb11u3

2022-02-17 Thread Aurelien Jarno
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
There are multiple fixes in this upload:
- 4 security bugs
- a fix to avoid preinst script failure when running on kernel x.y.z
  with z > 255. 
- a fix to avoid changes to /etc/nsswitch.conf to be reverted on upgrade

[ Impact ]
Installation will be left vulnerable to security issues and upgrade
from buster will fail when running recent upstream stable kernels.

[ Tests ]
Those changes are all in testing for some time so have been tested by
many users already. In addition the security fixes come with additional
tests.

[ Risks ]
The risk can probably be considered low, as the changes have been tested
in testing/sid and upstream or on other distributions for the security
bugs.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

Let me comment the changelog:

 * debian/patches/git-updates.diff: update from upstream stable branch:
   - Fix bad conversion from ISO-2022-JP-3 with iconv (CVE-2021-43396).
 Closes: #998622.

This fixes a security issue.

   - Remove PIE check on amd64 to fix FTBFS with binutils 2.37.

This is actually not something that is strictly needed in bullseye, as it runs
binutils 2.35. As it comes from the upstream stable branch and it is just about
removing code for an outdated check in a configure script (the version test on
binutils already ensures that), it has not impact on the binaries shipped in
the package. Therefore I didn't judged necessary to revert that change, it
makes my life easier when the upstream stable branch can be used.

   - Fix a buffer overflow in sunrpc svcunix_create (CVE-2022-23218).
   - Fix a buffer overflow in sunrpc clnt_create (CVE-2022-23219).

This fixes two similar security issues.

 * debian/debhelper.in/libc-bin.postinst: stop replacing older versions from
   /etc/nsswitch.conf.  Closes: #998008.

This is a forgotten leftover from the move of that file from base-files in 
Wheezy.

 * debian/debhelper.in/libc.preinst: simplify the version comparison by only
   comparing the two first parts, now that kernel 2.X are not supported
   anymore.  Closes: #1004861.
 * debian/debhelper.in/libc.preinst: drop the check for kernel release > 255
   now that glibc and preinstall script are fixed.  Closes: #987266.

These two just drop the comparison for the z part in kernel version x.y.z, as z
is not relevant anymore since kernel 3.0, and the minimum supported kernel
version since buster is 3.2. This fixes cases where z > 255 as with recent
upstream stable kernels. Incidentally it also fixes the weird case where z is
not a numeric value.

 * debian/patches/local-CVE-2021-33574-mq_notify-use-after-free.diff:
   fix a possible use-after-free in mq_notify (CVE-2021-33574).  Closes:
   #989147.

This security fix does not come from the upstream stable branch, as a simple
backport would change the GLIBC_PRIVATE ABI and will cause issue with online
upgrades. Instead the corresponding code is included as a static function (see
the top of the patch for more details). Overall the code is the same as in
later glibc versions, just not ending up in the same library.
diff --git a/debian/changelog b/debian/changelog
index 7c23c790..36d87ef3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,25 @@
+glibc (2.31-13+deb11u3) UNRELEASED; urgency=medium
+
+  [ Aurelien Jarno ]
+  * debian/patches/git-updates.diff: update from upstream stable branch:
+- Fix bad conversion from ISO-2022-JP-3 with iconv (CVE-2021-43396).
+  Closes: #998622.
+- Remove PIE check on amd64 to fix FTBFS with binutils 2.37.
+- Fix a buffer overflow in sunrpc svcunix_create (CVE-2022-23218).
+- Fix a buffer overflow in sunrpc clnt_create (CVE-2022-23219).
+  * debian/debhelper.in/libc-bin.postinst: stop replacing older versions from
+/etc/nsswitch.conf.  Closes: #998008.
+  * debian/debhelper.in/libc.preinst: simplify the version comparison by only
+comparing the two first parts, now that kernel 2.X are not supported
+anymore.  Closes: #1004861.
+  * debian/debhelper.in/libc.preinst: drop the check for kernel release > 255
+now that glibc and preinstall script are fixed.  Closes: #987266.
+  * debian/patches/local-CVE-2021-33574-mq_notify-use-after-free.diff:
+fix a possible use-after-free in mq_notify (CVE-2021-33574).  Closes:
+#989147.
+
+ -- Aurelien Jarno   Tue, 07 Dec 2021 23:51:16 +0100
+
 glibc (2.31-13+deb11u2) bullseye; urgency=medium
 
   [ Aurelien Jarno ]
diff --git a/debian/debhelper.in/libc-bin.postinst 
b/debian/debhelper.in/libc-bin.postinst
index 802a3ad0..6309f194 100644
--- a/debian/debhelper.in/libc-bin.postinst
+++ b/debian/debhelper.in/libc-bin.postinst
@@ -12,21 +12,6 @@ update_to_current_default() {
 

Bug#1005906: libc6: 'test -x' ignores executable bit on files and directories

2022-02-17 Thread Aurelien Jarno
On 2022-02-17 06:14, David Eccles (gringer) wrote:
> Package: libc6
> Version: 2.33-6
> Severity: important
> X-Debbugs-Cc: b...@gringene.org
> 
> Dear Maintainer,
> 
> I'm not sure which package this bug is linked to; I'm fairly confident it's 
> one of the following:
> 
> fontconfig-config libbrotli-dev libbrotli1 libc-bin libc-dev-bin libc-l10n
>   libc6 libc6-dev libexpat1 libexpat1-dev libfontconfig-dev libfontconfig1
>   libfreetype-dev libfreetype6 libfreetype6-dev libuuid1 locales uuid-dev
> 
> I was trying to get R working on a Docker container with the following 
> Dockerfile:
> 
> --- BEGIN ---
> 
> FROM rocker/r-base:4.1.2
> 
> ## This works
> RUN R -e 'install.packages(c("rjson"))'
> 
> RUN apt-get update && apt-get install -y \
>   libfontconfig1-dev
> 
> ## This doesn't work
> RUN R -e 'install.packages(c("rjson"))'
> 
> --- END ---
> 
> Unfortunately, the R command stops working after the packages are updated. At 
> the time I ran this,
> the following packages were pulled in:
> 
> fontconfig-config libbrotli-dev libbrotli1 libc-bin libc-dev-bin libc-l10n
>   libc6 libc6-dev libexpat1 libexpat1-dev libfontconfig-dev libfontconfig1
>   libfreetype-dev libfreetype6 libfreetype6-dev libuuid1 locales uuid-dev
> 
> I get similar results [i.e. R not working] when I try to install 'nano' 
> instead of libfontconfig1-dev.
> 
> I opened up the docker container to try to work out what was happening, and 
> noticed the R command
> has the following logic:
> 
> if test -x "${R_HOME}"; then
>   :
> else
>   error "R_HOME ('${R_HOME}') not found"
> fi
> 
> When I changed this to a 'test -d', R started working again:
> 
> if test -d "${R_HOME}"; then
>   :
> else
>   error "R_HOME ('${R_HOME}') not found"
> fi
> 
> Unfortunately, this didn't fix all my problems, because there was another R 
> INSTALL script that
> was required for installing R packages, and this script also didn't work. The 
> script had a simiar
> '-x' command, but it was used to test to make sure a file was executable, 
> instead of a directory.
> 
> I created a short test shell commands to demonstrate the issue:
> 
> # export R_HOME=/usr/lib/R
> # ls -lh ${R_HOME}/bin/INSTALL
> -rwxr-xr-x 1 root root 825 Nov  1 11:00 /usr/lib/R/bin/INSTALL
> # if test -x "${R_HOME}/bin/INSTALL"; then echo "file is executable"; else 
> echo "dead beef"; fi
> dead beef
> 
> [note that this reports "dead beef", rather than stating that the file is 
> executable, even though
> 'ls' reports the file as executable]

Please run this command under strace and provide the output, so that we can 
find the culprit.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1005299: mutter: FBTFS: Program cvt found: NO

2022-02-10 Thread Aurelien Jarno
Source: mutter
Version: 41.3-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

mutter fails to build from source:
| Got pkgconfig variable girdir : /usr/share/gir-1.0
| Program msgfmt found: YES (/usr/bin/msgfmt)
| Configuring org.gnome.mutter.gschema.xml using configuration
| Configuring org.gnome.mutter.wayland.gschema.xml using configuration
| Program glib-mkenums found: YES (/usr/bin/glib-mkenums)
| Program glib-mkenums found: YES (/usr/bin/glib-mkenums)
| Program gdbus-codegen found: YES (/usr/bin/gdbus-codegen)
| Program gdbus-codegen found: YES (/usr/bin/gdbus-codegen)
| env[PKG_CONFIG_PATH]: 
| Called `/usr/bin/pkg-config --variable=datadir sysprof-capture-4` -> 0
| /usr/share
| Got pkgconfig variable datadir : /usr/share
| Program gdbus-codegen found: YES (/usr/bin/gdbus-codegen)
| Program cvt found: NO
| 
| ../src/meson.build:846:2: ERROR: Program 'cvt' not found or not executable
| dh_auto_configure: error: cd obj-riscv64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/riscv64-linux-gnu -Degl_device=true 
-Dremote_desktop=true -Dwayland_eglstream=true returned exit code 1
| make[1]: *** [debian/rules:46: override_dh_auto_configure] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:20: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

The full build log can be found there:
https://buildd.debian.org/fetch.php?pkg=mutter=riscv64=41.3-2%2Bb1=1644485628=0

Note that this is also reproducible on amd64. There is probably a
missing dependency on cvt.



Bug#1004861: libc6: dist-upgrade to stable fails kernel version checks on LXC guests

2022-02-02 Thread Aurelien Jarno
control: fixed -1 libc6/2.31-14

On 2022-02-02 15:33, Olivier Berger wrote:
> Package: libc6
> Version: 2.31-13
> Severity: normal
> 
> Dear Maintainer,
> 
> I tried to upgrade from old-stable to stable on an LXC guest running on
> an ASUS NAS (underlying "ADM" OS) and got blocked during preinst :
> 
> Preparing to unpack .../libc6_2.31-13+deb11u2_amd64.deb ...
> /var/lib/dpkg/tmp.ci/preinst: 105: [: Illegal number:
> /var/lib/dpkg/tmp.ci/preinst: 9: /var/lib/dpkg/tmp.ci/preinst:
> arithmetic expression: expecting primary: "5 * 1 + 4 * 100 + "
> dpkg: error processing archive
> /var/cache/apt/archives/libc6_2.31-13+deb11u2_amd64.deb (--unpack):
>   new libc6:amd64 package pre-installation script subprocess returned
> error exit status 2
> Errors were encountered while processing:
>   /var/cache/apt/archives/libc6_2.31-13+deb11u2_amd64.deb
> 
> It appears a workaround is to create a fake uname script in
> /usr/local/bin that will report 5.4.0 (for instance) instead of the
> 5.4.x which is returned by uname -r in this Debian guest (why the NAS
> maintainers have such numbering of kernels... who knows).
> 
> This was discussed in french on
> https://debian-facile.org/viewtopic.php?id=25401 but I though this might
> deserve a proper bug report.
> 
> I guess this wouldn't be too hard to fix in the preinst script, but
> haven't checked the code.

This bug has been accidentally fixed a few months ago in testing/sid
[1]. I will see if this change can be included in a stable release.

Aurelien

[1] 
https://salsa.debian.org/glibc-team/glibc/-/commit/5452b62ded81132ebedf3db82577de5277479b27

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)

2022-02-01 Thread Aurelien Jarno
On 2022-02-01 16:02, Tulio Magno Quites Machado Filho wrote:
> Aurelien Jarno  writes:
> 
> > On 2022-01-19 22:08, John Paul Adrian Glaubitz wrote:
> >> Hi Aurelien!
> >> 
> >> Unfortunately, glibc no longer builds with this change on powerpc and ppc64
> >> and kernel builds still fails on both targets:
> >> 
> >> > https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0
> >> > https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0
> >
> > The ppc64el fix is not the cause for those failures. Previous glibc
> > versions also do not build on powerpc and ppc64 following the binutils
> > snapshot upload to sid. It's just that more code got broken on powerpc
> > and ppc64 than on ppc64el. I have queued the backported fixes from
> > upstream for the next upload.
> 
> Are these issues happening when building glibc upstream too?

No, upstream built fine, and same now for the 2.33 and 2.34 branches
after I backported ee874f44fd55988808a4a162ef21bfa2cc8dc6f7.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1004577: ldconfig -p coredumps

2022-01-30 Thread Aurelien Jarno
control: severity -1 minor
control: retitle -1 libc-bin: ldconfig aborts when using linux 2.6 personality
control: found -1 glibc/2.26-1

On 2022-01-30 19:03, Christoph Berg wrote:
> Package: libc-bin
> Version: 2.33-3
> Severity: important
> 
> In 
> https://salsa.debian.org/python-team/packages/python-telethon/-/jobs/2413916
> there is a diff generated between the two builds because a core file
> from `ldconfig -p` appears as /usr/lib/python3.10/dist-packages/core.
> 
> Backtrace:
> 
> [0] 18:56 myon@sid-amd64.maxwell:~/de/py/debian/output/reprotest 1j $ gdb 
> /sbin/ldconfig core
> GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /sbin/ldconfig...
> Reading symbols from 
> /usr/lib/debug/.build-id/f3/4bf815c30c307353fa1703469d5f1f4b3c9356.debug...
> [New LWP 12315]
> Core was generated by `/sbin/ldconfig -p'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0x7f205bb9f621 in ?? ()
> (gdb) bt
> #0  0x7f205bb9f621 in ?? ()
> #1  0x in ?? ()

This just points to the code that exit with SIGABRT. This happens
because in that job ldconfig is run with the linux 2.6 personality
(using setarch --uname-2.6) while the minimum supported kernel version
is 3.2 since stretch. This is what happens in practice:

$ setarch --uname-2.6 /sbin/ldconfig
FATAL: kernel too old
Aborted

This only happens for static binaries like ldconfig which get the faked
kernel version through uname, while dynamically linked binaries are able
to get the real kernel version from the ELF auxiliary vectors.

> The build artifacts are available from the salsa page; I don't have
> any access to the system there.
> 
> There is another ldconfig segfault reported in #806911, I don't
> know if that is related.

It's related in the sense that they both try to use the linux 2.6
personality to test for reproductible builds. That said in the case of
#806911 ldconfig crashed with a segmentation fault, and that bug got
fixed in the meantime (I just realized that now and closed the bug),
while in your case it exits properly with an abort.

I do believe it's actually a minor issue, we ship > 3.x kernels since
Wheezy, so support for the 2.6 personality is now rather pointless.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1004505: nanoc_4.12.5-2_all-buildd.changes REJECTED

2022-01-29 Thread Aurelien Jarno
Source: nanoc
Version: 4.12.5-2
Severity: serious

On 2022-01-29 16:19, Debian FTP Masters wrote:
> 
> 
> Version check failed:
> Your upload included the binary package ruby-nanoc-deploying, version 
> 1.0.1-2, for all,
> however testing already has version 1.0.1-2.
> Uploads to unstable must have a higher version than present in testing.
> 
> Mapping sid to unstable.
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 



Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target

2022-01-25 Thread Aurelien Jarno
On 2022-01-25 19:04, Vagrant Cascadian wrote:
> On 2022-01-25, Vagrant Cascadian wrote:
> > On 2022-01-15, Aurelien Jarno wrote:
> >> On 2022-01-11 16:40, Vagrant Cascadian wrote:
> >>> On 2022-01-11, Lennart Sorensen wrote:
> >>> > On Mon, Jan 10, 2022 at 05:10:04PM -0800, Vagrant Cascadian wrote:
> >>> >> Something in the toolchain recently changed which causes u-boot 
> >>> >> arch:all
> >>> >> build to FTBFS... I suspect binutils, as building in "bookworm" still
> >>> >> works fine where binutils hasn't yet migrated.
> >>> >> 
> >>> >> On arch:all builds the qemu-ppce500 target is cross-compiled.
> >>> >> 
> >>> >> Full log:
> >>> >> 
> >>> >>   
> >>> >> https://buildd.debian.org/status/fetch.php?pkg=u-boot=all=2022.01%2Bdfsg-1=1641860624=0
> >>> >> 
> >>> >> The hopefully relevent lines from the build log:
> ...
> >>> >> {standard input}: Assembler messages:
> >>> >> {standard input}:127: Error: unrecognized opcode: `tlbre'
> >>> >> {standard input}:418: Error: unrecognized opcode: `tlbre'
> >>> >> {standard input}:821: Error: unrecognized opcode: `msync'
> >>> >> {standard input}:821: Error: unrecognized opcode: `tlbwe'
> >>> >> {standard input}:884: Error: unrecognized opcode: `tlbsx'
> >>> >> make[4]: *** [/<>/scripts/Makefile.build:253: 
> >>> >> arch/powerpc/cpu/mpc85xx/tlb.o] Error 1
> >>> >> make[3]: *** [/<>/Makefile:1810: 
> >>> >> arch/powerpc/cpu/mpc85xx] Error 2
> >>> >> make[3]: *** Waiting for unfinished jobs
> >>> >>   powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
> > ...
> >>> The binutils versions appear to be:
> >>> 
> >>>   succeeding, bookworm 2.37-10.1
> >>>   failing, sid 2.37.50.20220106-2
> >>> 
> >>
> >> Yep, this is due to commit b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a on
> >> the binutils side [1], which changes the behavior of `.machine`
> >> directives to override, rather than augment, the base CPU. GCC is called
> >> with -Wa,-me500 to enable PowerPC e500 instructions on the assembler
> >> side, but as the default GCC machine is ppc, a `.set machine ppc` is
> >> emitted at the beginning of the assembly code.
> >>
> >> One option would be to force the CPU to e500 on the GCC side, however
> >> support for it has been removed. The options is therefore to force the
> >> machine in the assembly code. This is what the attached patch does.
> >
> > Somehow I missed that you had attached a patch! I will try to get this
> > tested and uploaded to Debian soon...
> 
> Your patch fixed building qemu-ppce500, but now I think we have a
> potentially similar problem with qemu-riscv64 and qemu-riscv64_smode:
> 
> /<>/arch/riscv/cpu/cpu.c: Assembler messages:
> /<>/arch/riscv/cpu/cpu.c:94: Error: unrecognized opcode
>   `csrs sstatus,a5'
> /<>/arch/riscv/cpu/cpu.c:95: Error: unrecognized opcode
>   `csrw 0x003,0'
> make[4]: *** [/<>/scripts/Makefile.build:254:
>   arch/riscv/cpu/cpu.o] Error 1
> make[3]: *** [/<>/Makefile:1810: arch/riscv/cpu] Error 2
> make[3]: Leaving directory
>   '/<>/debian/build/qemu-riscv64_smode'

I guess this is due to:
http://lists.infradead.org/pipermail/linux-riscv/2022-January/011728.html

Unfortunately as the change has been done in a not yet released binutils
version, there is no way for the fix to have been done upstream yet.

Note that this also breaks at least linux and opensbi.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Bug#1004207: locales: Add schwa combination in IT Keyboard layout

2022-01-23 Thread Aurelien Jarno
control: reassign -1 xkb-data
control: retitle -1 xkb-data: Add schwa combination in IT Keyboard layout

On 2022-01-22 19:53, Nicola wrote:
> Package: locales
> Version: 2.33-2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> could be useful add a combination to keyboard layout to write the schwa
> character ( ə )
> 
> IMHO the actual combination of AltGr + SHIFT + e (that produces ¢ , witch is
> already also in AltGr + SHIFT + c) could be assigned to Schwa.
> 
> Personally I don't like too much the usage of schwa in Italian, but is 
> becoming
> more and more used.

The package responsible for providing keyboard layout is xkb-data. I am
reassigning the bug there.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1004039: libgl1-mesa-dri: radeonsi driver missing for riscv64

2022-01-20 Thread Aurelien Jarno
control: tag 1004039 + patch

Hi,

On 2022-01-19 18:51, W.J. van der Laan wrote:
> Package: libgl1-mesa-dri
> Version: 21.3.4-1
> Severity: important
> X-Debbugs-Cc: laa...@protonmail.com
> 
> Dear Maintainer,
> 
> The package libgl1-mesa-dri_*_riscv64.deb doesn't contain radeonsi_dri.so on
> riscv64, as it does for other platforms. This driver is required for 3D
> acceleration on newer AMD graphics cards.
> 
> What we suspect to be the cause is the following change in mesa packaging
>  
>   [ Aurelien Jarno ]
>   * Disable LLVM support on riscv64, it doesn't have JIT. (Closes: 
> #995618)
> 
>  -- Timo Aaltonen   Mon, 04 Oct 2021 15:18:27 +0300
> 
> LLVM is used to compile shaders for the GPU, as this is a kind of 
> cross-compiling
> it's not affected by the lack of JIT for riscv64. Removing LLVM on the other 
> hand
> makes that the driver is no longer being built.

Sorry about that. Disabling LLVM means that GPU support is not enabled,
but on the other hand enabling LLVM means that applications just crash
on video cards without acceleration. We need to find a way to get both
kind of systems working correctly.

After discussing with Jessica, it seems we can enable LLVM, but
disabling anything that needs CPU JIT support. It seems that is achieved
by disabling swrast on the Vulkan side and disabling draw-use-llvm on
the Gallium side. I therefore ended-up with the attached patch with does
that in addition to reenable LLVM support, and that works well for
software rendering on the CPU.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -u mesa-21.3.4/debian/control mesa-21.3.4/debian/control
--- mesa-21.3.4/debian/control
+++ mesa-21.3.4/debian/control
@@ -43,10 +43,10 @@
  libelf-dev [amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sparc64],
  libwayland-dev (>= 1.15.0) [linux-any],
  libwayland-egl-backend-dev (>= 1.15.0) [linux-any],
- llvm-13-dev [amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el s390x sparc64],
- libclang-13-dev [amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el s390x sparc64],
- libclang-cpp13-dev [amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el s390x sparc64],
- libclc-13-dev [amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el s390x sparc64],
+ llvm-13-dev [amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sparc64],
+ libclang-13-dev [amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sparc64],
+ libclang-cpp13-dev [amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sparc64],
+ libclc-13-dev [amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sparc64],
  wayland-protocols (>= 1.9),
  zlib1g-dev,
  libglvnd-core-dev (>= 1.3.2),
@@ -412,7 +412,7 @@
 
 Package: mesa-opencl-icd
 Section: libs
-Architecture: amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el s390x sparc64
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sparc64
 Pre-Depends: ${misc:Pre-Depends}
 Depends:
  libclc-13,
diff -u mesa-21.3.4/debian/rules mesa-21.3.4/debian/rules
--- mesa-21.3.4/debian/rules
+++ mesa-21.3.4/debian/rules
@@ -63,6 +63,10 @@
   ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el s390x sparc64))
 	VULKAN_DRIVERS += amd swrast
   endif
+  # Only enable amd on riscv64, swrast needs CPU JIT support which doesn't work yet
+  ifneq (,$(filter $(DEB_HOST_ARCH), riscv64))
+	VULKAN_DRIVERS += amd
+  endif
 
   ifeq ($(DEB_HOST_ARCH_OS), linux)
 	confflags_DRI3 = -Ddri3=enabled
@@ -111,7 +115,7 @@
 
   # LLVM is required for building r300g, radeonsi and llvmpipe drivers.
   # It's also required for building OpenCL support.
-  ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el s390x sparc64))
+  ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sparc64))
 	GALLIUM_DRIVERS += radeonsi
 	confflags_GALLIUM += -Dllvm=enabled
 	confflags_GALLIUM += -Dgallium-opencl=icd
@@ -133,6 +137,11 @@
   ifeq (,$(filter pkg.mesa.nolibva,$(DEB_BUILD_PROFILES)))
 	confflags_GALLIUM += -Dgallium-va=enabled
   endif
+
+  # llvmpipe needs CPU JIT support which doesn't work yet
+  ifneq (,$(filter $(DEB_HOST_ARCH), riscv64))
+confflags_GALLIUM += -Ddraw-use-llvm=false
+  endif
 endif
 
 


Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)

2022-01-19 Thread Aurelien Jarno
Hi,

On 2022-01-19 22:08, John Paul Adrian Glaubitz wrote:
> Hi Aurelien!
> 
> Unfortunately, glibc no longer builds with this change on powerpc and ppc64
> and kernel builds still fails on both targets:
> 
> > https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0
> > https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0

The ppc64el fix is not the cause for those failures. Previous glibc
versions also do not build on powerpc and ppc64 following the binutils
snapshot upload to sid. It's just that more code got broken on powerpc
and ppc64 than on ppc64el. I have queued the backported fixes from
upstream for the next upload.

> > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0
> > https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0

Those failures are completely unrelated to do with glibc. A porter need
to fix the kernel code to make it compatible with the new binutils.

Cheers
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)

2022-01-16 Thread Aurelien Jarno
control: reassign -1 glibc
control: found -1 glibc/2.29-1

On 2022-01-16 21:15, Paul Gevers wrote:
> Source: binutils, glibc
> Control: found -1 binutils/2.37.50.20220106-2
> Control: found -1 glibc/2.33-2
> Severity: serious
> Tags: sid bookworm
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> Control: affects -1 gcc-10 gcc-11
> 
> Dear maintainer(s),
> 
> With a recent upload of binutils the autopkgtest of glibc fails in testing
> when that autopkgtest is run with the binary packages of binutils from
> unstable. It passes when run with only packages from testing. In tabular
> form:
> 
>passfail
> binutils   from testing2.37.50.20220106-2
> glibc  from testing2.33-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 binutils, gcc-10 and
> gcc-11 to testing [1]. Due to the nature of this issue, I filed this bug
> report against the binutils and glibc source packages. Can you please
> investigate the situation and reassign the bug to the right package?

Recent versions of binutils changed the way the .machine directive works
on PowerPC. I have already backported a fix to our git.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Bug#1003819: tmpreaper: FBTFS

2022-01-16 Thread Aurelien Jarno
Source: tmpreaper
Version: 1.6.15
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

tmpreaper fails to build from source:
| checking for sys/wait.h that is POSIX.1 compatible... yes
| checking for errno.h... yes
| checking for limits.h... yes
| checking for stdlib.h... (cached) yes
| checking for unistd.h... (cached) yes
| checking for libmount/libmount.h... yes
| checking for gcc options needed to detect all undeclared functions... none 
needed
| checking whether GLOB_BRACE is declared... yes
| checking for getopt_long... yes
| checking for mnt_context_do_mount in -lmount... yes
| checking that generated files are newer than configure... done
| configure: creating ./config.status
| config.status: creating Makefile
| config.status: creating tmpreaper.8
| config.status: creating config.h
| config.status: config.h is unchanged
| config.status: executing depfiles commands
| make CPPFLAGS="-DDEBIAN" tmpreaper
| make[1]: Entering directory '/<>'
| make[1]: 'tmpreaper' is up to date.
| make[1]: Leaving directory '/<>'
| ./tmpreaper -h 2>&1 | grep 'tmpreaper -- Version: '1.6.15-DEB || (echo "You 
forgot to fix the VERSION in configure.ac!"; exit 1)
| You forgot to fix the VERSION in configure.ac!
| make: *** [debian/rules:44: build-stamp] Error 1
| dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess 
returned exit status 2

The full build log can be found there:
https://buildd.debian.org/fetch.php?pkg=tmpreaper=amd64=1.6.15=1641215840=0



Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target

2022-01-15 Thread Aurelien Jarno
control: tag -1 + upstream
control: tag -1 + patch

On 2022-01-11 16:40, Vagrant Cascadian wrote:
> On 2022-01-11, Lennart Sorensen wrote:
> > On Mon, Jan 10, 2022 at 05:10:04PM -0800, Vagrant Cascadian wrote:
> >> Package: u-boot
> >> Version: 2022.01+dfsg1-1
> >> Severity: serious
> >> X-Debbugs-Cc: debian-powe...@lists.debian.org, q...@packages.debian.org, 
> >> binut...@packages.debian.org
> >> 
> >> Something in the toolchain recently changed which causes u-boot arch:all
> >> build to FTBFS... I suspect binutils, as building in "bookworm" still
> >> works fine where binutils hasn't yet migrated.
> >> 
> >> On arch:all builds the qemu-ppce500 target is cross-compiled.
> >> 
> >> Full log:
> >> 
> >>   
> >> https://buildd.debian.org/status/fetch.php?pkg=u-boot=all=2022.01%2Bdfsg-1=1641860624=0
> >> 
> >> The hopefully relevent lines from the build log:
> >> 
> >>   powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/cpu/mpc85xx/.tlb.o.d 
> >> -nostdinc -isystem /usr/lib/gcc-cross/powerpc-linux-gnu/11/include 
> >> -Iinclude  -I/<>/include  
> >> -I/<>/arch/powerpc/include -include 
> >> /<>/include/linux/kconfig.h  
> >> -I/<>/arch/powerpc/cpu/mpc85xx -Iarch/powerpc/cpu/mpc85xx 
> >> -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security 
> >> -fno-builtin -ffreestanding -std=gnu11 -fshort-wchar -fno-strict-aliasing 
> >> -fno-PIE -Os -fno-stack-protector -fno-delete-null-pointer-checks 
> >> -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds 
> >> -Wno-array-bounds -Wno-stringop-overflow -Wno-maybe-uninitialized 
> >> -fmacro-prefix-map=/<>/= -g -fstack-usage 
> >> -Wno-format-nonliteral -Wno-address-of-packed-member 
> >> -Wno-unused-but-set-variable -Werror=date-time -Wno-packed-not-aligned 
> >> -D__powerpc__ -ffixed-r2 -m32 -fno-ira-hoist-pressure -Wa,-me500 
> >> -msoft-float -mno-string -fpic -mrelocatable -ffunction-sections 
> >> -fdata-sections -mcall-linux -msingle-pic-base -fno-jump-tables -pipe
> >> -DKBUILD_BASENAME='"tlb"'  -DKBUILD_MODNAME='"tlb"' -c -o 
> >> arch/powerpc/cpu/mpc85xx/tlb.o 
> >> /<>/arch/powerpc/cpu/mpc85xx/tlb.c
> >> ...
> >> {standard input}: Assembler messages:
> >> {standard input}:127: Error: unrecognized opcode: `tlbre'
> >> {standard input}:418: Error: unrecognized opcode: `tlbre'
> >> {standard input}:821: Error: unrecognized opcode: `msync'
> >> {standard input}:821: Error: unrecognized opcode: `tlbwe'
> >> {standard input}:884: Error: unrecognized opcode: `tlbsx'
> >> make[4]: *** [/<>/scripts/Makefile.build:253: 
> >> arch/powerpc/cpu/mpc85xx/tlb.o] Error 1
> >> make[3]: *** [/<>/Makefile:1810: arch/powerpc/cpu/mpc85xx] 
> >> Error 2
> >> make[3]: *** Waiting for unfinished jobs
> >>   powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
> >> 
> >> 
> >> If anyone has thoughts what might be the issue, please chime in!
> >> 
> >> 
> >> I could remove qemu-ppce500 from the build targets(all other targets
> >> build fine); I am not sure if it is used by qemu or if qemu builds all
> >> it's own firmwares.
> >
> > Which gcc version?  I believe gcc 9 removed the code for powerpcspe
> > which gcc 8 deprecated.  So at this point I think only llvm/clang supports
> > the powerpcspe targets.
> 
> gcc-11 11.2.0-13 in both the successfull (bookworm) and
> failing case (sid).
> 
> Which is why I suspect binutils, which differs between bookworm and
> sid...
> 
> > I don't recall if binutils also dropped support or have kept it around.
> 
> The binutils versions appear to be:
> 
>   succeeding, bookworm 2.37-10.1
>   failing, sid 2.37.50.20220106-2
> 

Yep, this is due to commit b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a on
the binutils side [1], which changes the behavior of `.machine`
directives to override, rather than augment, the base CPU. GCC is called
with -Wa,-me500 to enable PowerPC e500 instructions on the assembler
side, but as the default GCC machine is ppc, a `.set machine ppc` is
emitted at the beginning of the assembly code.

One option would be to force the CPU to e500 on the GCC side, however
support for it has been removed. The options is therefore to force the
machine in the assembly code. This is what the attached patch does.

Regards,
Aurelien

[1] 
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b25f942e18d6e

Bug#1003574: segfault in libc-2.33.so during i386 boot ofde QEMU VM

2022-01-15 Thread Aurelien Jarno
control: reopen -1
control: merge 1003610 -1
control: severity -1 serious
control: found -1 glibc/2.33-1
control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=28784

On 2022-01-12 14:08, Christian Kastner wrote:
> Hi Aurelien,
> 
> thank you for the quick reply.
> 
> On 2022-01-12 11:45, Aurelien Jarno wrote:
> >> # Boot image. -enable-kvm assumes that this is being tested on amd64
> >> # Optionally use -nographic for terminal output instead of GUI
> >> $ qemu-system-i386 \
> >>-machine q35 \
> >>-enable-kvm \
> > 
> > You might also want to try without -enable-kvm
> 
> Indeed, this fixed the issue.
> 
> So sorry for the noise. I was 120% sure that I had tried that.

My turn to be sorry, it appears to be a genuine issue on the GNU libc
side, and changing the CPU definition in QEMU, either with -cpu or by
disabling kvm) just hide the bug. I was not able to reproduce the issue
as you need a non-Intel CPU to get the issue with the command line your
provided.

This bug also affects via C7 CPUs. I have reported the issue upstream
and provided a patch, currently waiting for review.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1003610: libc6 crashes with VIA C7 and VIA Eden processors starting with 2.33

2022-01-13 Thread Aurelien Jarno
On 2022-01-13 14:20, Wolfgang Walter wrote:
> Am 2022-01-12 16:46, schrieb Aurelien Jarno:
> > On 2022-01-12 16:14, Wolfgang Walter wrote:
> > > Package: libc6
> > > Version: 2.33-2
> > > Severity: important
> > > 
> > > After upgrading from libc6 2.32 to 2.33 all machines with a VIA C7
> > > or VIA
> > > Eden show segfaults in libc (i.e. hostname fails to work, or rebooting
> > > fails). Machines with VIA Nehemiah work fine.
> > 
> > Could you please provide more details? At least the content of dmesg
> > when it happens or ideally a core dump or a backtrace.
> 
> Not easy. These machines just boot into a initramfs (which is a very minimal
> debian sid) from an usb-stick and nothing survives a reboot. /bin/sh points
> to bash.
> 
> The system does not use systemd but sysv.
> 
> The login prompt is:
> 
> (none) login:
> 
> 
> I cannot log into the machine, login seems also be broken, it always says
> "login incorrect".
> 
> If I try to reboot by entering ctrl-alt-del the reboot fails with:
> 
> INIT: Switching to runlevel: 6
> INIT: No inittab.d directory found
> INIT: Sending processes configured via /etc/inittab the TERM signal
> [  305.550677][ T1235] rc[1235]: segfault at 1c81000 ip b7ebf634 sp bfb5ce78
> error 6 in libc-2.33.so[b7d8e000+158000]
> [  305.550791][ T1235] Code: 95 04 00 03 1c 8b 01 ca ff e3 29 d9 8d b4 26 00
> 00 00 00 8d 76 00 0f 18 8a c0 03 00 00 0f 18 8a 80 03 00 00 81 eb 80 00 00
> 00 <66> 0f 7f 02 66 0f 7f 42 10 66 0f 7f 42 20 66 0f 7f 42 30 66 0f 7f
> Give root password for maintenance
> (or press Control-D to continue):

Thanks. This codes corresponds to memset_sse2:

  14e607:   81 c3 69 95 04 00   add$0x49569,%ebx
  14e60d:   03 1c 8badd(%ebx,%ecx,4),%ebx
  14e610:   01 ca   add%ecx,%edx
  14e612:   ff e3   jmp*%ebx
  14e614:   29 d9   sub%ebx,%ecx
  14e616:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
  14e61d:   8d 76 00lea0x0(%esi),%esi
  14e620:   0f 18 8a c0 03 00 00prefetcht0 0x3c0(%edx)
  14e627:   0f 18 8a 80 03 00 00prefetcht0 0x380(%edx)
  14e62e:   81 eb 80 00 00 00   sub$0x80,%ebx
=>14e634:   66 0f 7f 02 movdqa %xmm0,(%edx)
  14e638:   66 0f 7f 42 10  movdqa %xmm0,0x10(%edx)
  14e63d:   66 0f 7f 42 20  movdqa %xmm0,0x20(%edx)
  14e642:   66 0f 7f 42 30  movdqa %xmm0,0x30(%edx)
  14e647:   66 0f 7f 42 40  movdqa %xmm0,0x40(%edx)
 
> But I cannot login (Login incorrect). If I enter control-d instead, I get
> "sulogin: cannot read /dev/tty1: Operation not permitted".
> 
> The very same usb stick boots just fine with non VIA 7 / VIA Eden
> processors.
> 
> 
> I modified it a bit an set --autologin for one getty. This did not worḱ, I
> get a lot of things like
> 
> [   ..][ T1231] login[1231]: segfault at bfd3d000 ip b7eb5656 sp
> bfd36978 error 6 in libc-2.33.so[b7d84000+158000]
> 
> or
> 
> [ ][ T1241] sh[1241]: segfault at 12ac000 ip b7e03638 sp bff99ff8
> error 6 in libc-2.33.so[b7cd2000+158000]
> 
> 
> Now I tried  getty -n -l /bin/dash. This worked.
> 
> If I try to start bash, bash crashes with a segmentation fault. I have no
> debugger and no debugging symbols in this image at the moment, only strace
> 
> If I strace -f bash I get:
> 
> The last thing done is reading the first line of passwd, closing the file.
> Then there is a SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> si_addr=0x12d9000}
> 
> When I do a strace -f bash 2> /tmp/blub the last system call is uname(),
> then again a SEGV_MAPPERR
> 
> When bash segfaults I get no log that it crashed in libc6.
> 
> ls, rm, mount  etc seem to work.
> 
> But vim crashes in libc6, again at +158000 and with Code "1c 8b 01 ca ff e3
> 29 d9 8d b4 26 00 00 00 00 8d 76 00 0f 18 8a c0 03 00 00 0f 18 8a 80 03 00
> 00 81 eb 80 00 00 00 <66> 0f 7f 02 66 0f 7f 42 10 66 0f 7f 42 20 66 0f 7f 42
> 30 66 0f"
> 
> Also ip link ls crashes, again in libc6, again at +158000 and with Code "0f
> 18 8a 80 03 00 00 81 eb 80 00 00 00 00 66 0f 7f 02 66 0f 7f 42 10 66 0f 7f
> 42 20 66 0f 7f 42 30 66 0f 7f 42 40 66 0f 7f 42 50 <66> 0f 7f 02 66 0f 7f 42
> 70 71 c2 80 00 00 00 81 fb 80 00 00 00"
> 
> or ip addr ls
> 
> or less, perl, ssh, sshd, rsyslogd
> 
> The Code is not always the same, but <66> 0f 7f 42 seems to be and the crash
> in libc-2.33.so[x+158000]
> 

The above crashes are in memset_sse2 or bzero_sse2, I do not have enough
details to confirm, but that's not that important.

Bug#1003610: libc6 crashes with VIA C7 and VIA Eden processors starting with 2.33

2022-01-12 Thread Aurelien Jarno
On 2022-01-12 16:14, Wolfgang Walter wrote:
> Package: libc6
> Version: 2.33-2
> Severity: important
> 
> After upgrading from libc6 2.32 to 2.33 all machines with a VIA C7 or VIA
> Eden show segfaults in libc (i.e. hostname fails to work, or rebooting
> fails). Machines with VIA Nehemiah work fine.

Could you please provide more details? At least the content of dmesg
when it happens or ideally a core dump or a backtrace.

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1003574: segfault in libc-2.33.so during i386 boot ofde QEMU VM

2022-01-12 Thread Aurelien Jarno
tag: control -1 + unreproducible

Hi,

On 2022-01-11 23:38, Christian Kastner wrote:
> Package: libc6
> Version: 2.33-2
> Severity: normal
> 
> When booting an i386 VM built for autopkgtests, I see the following
> segfault during boot:
> 
> > [1.374128] Freeing unused kernel image (initmem) memory: 940K
> > [1.384002] Write protecting kernel text and read-only data: 11292k
> > [1.384526] Run /init as init process
> > Loading, please wait...
> > Starting version 250.2-1
> > [1.406157] udevadm[106]: segfault at bc ip b7d9f638 sp bf989cb8 
> > error 6 in libc-2.33.so[b7c6e000
> > [1.407017] Code: 1c 8b 01 ca ff e3 29 d9 8d b4 26 00 00 00 00 8d 76 00 
> > 0f 18 8a c0 03 00 00 0f 18 8a
> > Segmentation fault

Unfortunately the error message is cut, so it is not possible to find
where the crashes happen. A segmentation fault in libc6 is not necessary
libc6's fault.

> Boot continues briefly after that, but then drops to an emergency shell.
> 
> I've tried the other popular architectures, but I only saw this on i386.
> 
> 
> To reproduce, this requires qemu-system-x86 and autopkgtest >= 5.17.
> 
> # Build image
> $ sudo autopkgtest-build-qemu \
>   --mirror http://deb.debian.org/debian
>   --arch i386 \
>   unstable i386.img
> 
> # Boot image. -enable-kvm assumes that this is being tested on amd64
> # Optionally use -nographic for terminal output instead of GUI
> $ qemu-system-i386 \
>   -machine q35 \
>   -enable-kvm \

You might also want to try without -enable-kvm

>   -device virtio-serial \
>   -nic user,model=virtio \
>   -m 1024 -smp 1 \
>   i386.img

Unfortunately I have not been able to reproduce this issue here, the
image boots perfectly. This is using an up to date sid system. The
version of QEMU might be an important factor, and maybe your CPU.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1003483: texinfo FTBFS with glibc 2.34: ./malloc/dynarray-skeleton.c:195:24: error: expected declaration specifiers or ‘...’ before ‘(’ token __attribute_nonnull__ ((1))

2022-01-10 Thread Aurelien Jarno
Package: texinfo
Version: 6.8-3
Severity: important
Tags: patch upstream ftbfs

Dear maintainer,

texinfo fails to build from source when built against glibc 2.34
(currently in experimental):

| x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../..   -Wdate-time 
-D_FORTIFY_SOURCE=2  -g -O2 
-ffile-prefix-map=/tmp/autopkgtest-lxc.eesdofvc/downtmp/build.uke/src=. 
-fstack-protector-strong -Wformat -Wall -MT regex.o -MD -MP -MF $depbase.Tpo -c 
-o regex.o regex.c &&\
| mv -f $depbase.Tpo $depbase.Po
| In file included from regexec.c:1368,
|  from regex.c:74:
| ./malloc/dynarray-skeleton.c:195:24: error: expected declaration specifiers 
or ‘...’ before ‘(’ token
|   195 | __attribute_nonnull__ ((1))
|   |^
| ./malloc/dynarray-skeleton.c:205:51: error: expected declaration specifiers 
or ‘...’ before ‘(’ token
|   205 | __attribute_maybe_unused__ __attribute_nonnull__ ((1))
|   |   ^

A full build log is available on ci.debian.net as part of an autopkgtest
run:
https://ci.debian.net/data/autopkgtest/unstable/amd64/t/texinfo/18203753/log.gz

The issue is an incompatibility between the malloc code on the glibc
side and gnulib. A patch is available here:
https://src.fedoraproject.org/rpms/texinfo/blob/rawhide/f/texinfo-6.8-undo-gnulib-nonnul.patch

As we are preparing for the glibc 2.34 transition, it would be
appreciated if you can fix this issue in the next weeks.

Regards,
Aurelien


Bug#1003213: locales-all: introduce locales-utf8 package?

2022-01-10 Thread Aurelien Jarno
On 2022-01-09 18:12, Simon McVittie wrote:
> On Sun, 09 Jan 2022 at 13:48:06 +0100, Aurelien Jarno wrote:
> > On 2022-01-06 11:21, Simon McVittie wrote:
> > > * install locales-all (this costs > 200M but ensures that all locales are
> > >   available)
> > > 
> > > For "reasonably large" desktop and server systems, I wonder whether it
> > > might be better to generate a subset of locales-all with just the UTF-8
> > > locales that we recommend for general use, and install that by default?
> > 
> > Defining general use is something quite difficult. All languages and
> > countries should be considered equally, so we could differentiate
> > UTF-8 from non UTF-8 locales, but we should not make further selection.
> 
> Right, what I meant was: AIUI we recommend that all speakers of xx_YY
> use the xx_YY.utf8 locale, as opposed to a legacy national encoding, so
> we could (make it straightforward to) install all the UTF-8 locales
> like en_GB.utf8 and none of the legacy national encodings like
> en_GB.ISO-8859-15.
> 
> > That way of doing it would be fine from the desktop point of view (100M
> > is not that much compared to a desktop environment). However we can't
> > force the installation of locales-all-utf8 in d-i
> 
> I thought task-*-desktop could maybe pull it in?

Agree for the desktop case. But that's not possible for other type of
installations, so that doesn't provide a way to remove the "legacy"
locales package.

As said in my previous mail, if we start reorganizing the locales-all
package with the eventual goal of dropping the locales package
(something I would like to do for many years), we should ensure that it
works for all cases.

> > From the various discussion on IRC, we more or less concluded that the
> > way to go is to have one locale package per language, like it's done in
> > most other distributions. From there we could have task-$language
> > depends on locales-$language, also simplifying the d-i side.
> > 
> > Would that work for your use case?
> 
> That would mean that UIs like gnome-control-center would still not be able
> to offer to add (for example) a French locale on a system that had been
> installed in German, unless either the user knows that they need to install
> the French language pack first, or the UI grows distro-specific code to:
> 
> - know which languages would be candidates for being enabled if the
>   appropriate language pack was installed
> - ask PackageKit to install the necessary language pack when one of those
>   locales was chosen

Your usage of the term "language pack" is interesting. locales-all only
provide locales, not translations. So a user wanting to switch to the
desktop to German will still have to install the corresponding l10n
packages for firefox, thunderbird or libreoffice.

Would that work to improve d-i to allow users select multiple language
tasks, so that they can install supports for the languages they want?

> However, it's consistent with how e.g. Flatpak handles locales (there's one
> locale extension per language code, so for example fr_FR and fr_CH go
> together).
> 
> This would also allow avoiding a long-standing issue with Steam: some
> Steam games assume that en_US.UTF-8 is always available (they're wrong,
> and should be using C.UTF-8, but that's not portable), so the steam package
> could gain a Recommends: locales-en to work around that.
> 
> > > locales-utf8 would probably also be enough for many locale-sensitive
> > > packages' test suites.
> > 
> > Not sure about that. Test suites are the main reason why we had to
> > revert the removal of non UTF-8 locales.
> 
> I suspect this might be a bit circular: the reason that upstreams want
> to test support for legacy encodings, and the reason that we want to run
> those tests instead of skipping them, is because distros like us still
> (claim to) support those encodings, even though we no longer recommend
> them.

I agree, however they way we want to break the loop (not offering legacy
encodings to users) suggests that the test suites are going to be the
last users of the non-utf8 locales.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1003342: libc6: NIS client not working after update to libc6:amd64 2.33-1

2022-01-09 Thread Aurelien Jarno
Hi,

On 2022-01-08 17:15, Nuno Oliveira wrote:
> Package: libc6
> Version: 2.33-1
> Severity: normal
> 
> Hi,
> 
> After the update of libc6 2.32-5 -> 2.33-1, NIS users are not recognized 
> by the system anymore. The NIS setup was working OK before this upgrade, 
> which just included (according to aptitude):
> 
> REMOVE (PURGE)] libjson-c4:amd64 0.13.1+dfsg-9
> [UPGRADE] glibc-doc:amd64 2.32-5 -> 2.33-1
> [UPGRADE] glibc-doc-reference:amd64 2.32-1 -> 2.33-1
> [UPGRADE] libc-bin:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc-dev-bin:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc-l10n:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-dbg:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-dev:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-dev-i386:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-dev-x32:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-i386:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-x32:amd64 2.32-5 -> 2.33-1
> [UPGRADE] locales:amd64 2.32-5 -> 2.33-1
> [UPGRADE] nscd:amd64 2.32-5 -> 2.33-1
> ==
> 
> "ypcat passwd" works fine, as before. "finger username" does not work. 
> The system has libnss-nis and libnss-nisplus previously installed. The 
> usual usual instructions in /usr/share/doc/nis/nis.debian.howto.gz were 
> verified and they are still implemented as suggested (no changes). This 
> happens on multiple client systems, where the behavior seems to be 
> reproducible. "ypwhich" works normally.
> 
> Doing a "strace finger username" and checking the differences between a 
> working system (still libc6 2.32-5) and a nonworking system (with libc6 
> 2.33-1):
> 
> In the old system, after
> 
>   openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_compat.so.2", 
> O_RDONLY|O_CLOEXEC) = 3
>   ...
>   close(3)
> 
> there is a call to
> 
>   openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>   ...
>   close(3)= 0
>   openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_nis.so.2", 
> O_RDONLY|O_CLOEXEC) = 3
>   ...
>   close(3)
> 
> In the updated system (libc6 2.32-5), after the call to 

I guess you mean 2.33-1 here.

> libnss_compat.so.2, there is no following call to libnss_nis.so.2 or 
> /etc/ld.so.cache, although /lib/x86_64-linux-gnu/libnss_nis.so.2 exists, 
> and points to libnss_nis.so.2.0.0.

Thanks for the detail analysis. I can confirm the same issue. It has
been fixed by this upstream commit:

https://sourceware.org/git/?p=glibc.git;a=commit;h=9b456c5da968ee832ea4b2b73a18a5bf6d2118a6

Unfortunately, due to symbols changes, it is not backportable to glibc
2.33 easily without potentially breaking other NSS modules during
upgrade.

On the other hand, the problem is already fixed in glibc 2.34 (currently
in experimental), so the easiest fix might be to get glibc 2.34 ready to
be uploaded to unstable.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1003213: locales-all: introduce locales-utf8 package?

2022-01-09 Thread Aurelien Jarno
Hi,

On 2022-01-06 11:21, Simon McVittie wrote:
> Package: locales-all
> Version: 2.33-1
> Severity: wishlist
> 
> As discussed recently on -devel and previously in #701585, at the moment
> Debian users have a choice between two non-ideal locale setups:
> 
> * install locales and generate a subset of locale files with locale-gen
>   (this is optimal for small systems, but it's difficult for high-level
>   UIs like GNOME Settings to present this to users, particularly in a
>   non-distro-specific way)

Yes, this is the old way of doing that, and it's something that we want
to get rid of at some point. I think it's important thing to take into
account when discussing the future of locales-all. 

> * install locales-all (this costs > 200M but ensures that all locales are
>   available)
> 
> For "reasonably large" desktop and server systems, I wonder whether it
> might be better to generate a subset of locales-all with just the UTF-8
> locales that we recommend for general use, and install that by default?

Defining general use is something quite difficult. All languages and
countries should be considered equally, so we could differentiate
UTF-8 from non UTF-8 locales, but we should not make further selection.

> If I'm counting correctly, that would be about 100M, which is perhaps an
> acceptable price to pay for language settings being straightforward -
> a reasonably complete set of Noto fonts (without CJK) is already more
> than half of that.
> 
> locales-all could have a Depends on locales-utf8 and contain the remaining
> (legacy national character set) locales, if anyone still needs that.

That way of doing it would be fine from the desktop point of view (100M
is not that much compared to a desktop environment). However we can't
force the installation of locales-all-utf8 in d-i, so that wouldn't
solve the problematic of getting rid of the locales package.

From the various discussion on IRC, we more or less concluded that the
way to go is to have one locale package per language, like it's done in
most other distributions. From there we could have task-$language
depends on locales-$language, also simplifying the d-i side.

Would that work for your use case?

> locales-utf8 would probably also be enough for many locale-sensitive
> packages' test suites.

Not sure about that. Test suites are the main reason why we had to
revert the removal of non UTF-8 locales.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#993515: catch: FTBFS with glibc 2.34

2022-01-06 Thread Aurelien Jarno
On 2021-09-02 14:37, Graham Inggs wrote:
> Source: catch
> Version: 1.12.1-1.1
> Severity: important
> 
> Hi Maintainer
> 
> Catch will FTBFS once glibc is upgraded to 2.34 due to MINSIGSTKSZ and
> SIGSTKSZ no longer being defined.
> 
> This was fixed Catch2's upstream [1].  I'm not sure if this can be
> adapted for Catch(1).
> Another approach is to simply replace SIGSTKSZ with a constant, as
> done in Fedora [2].

Please note that glibc 2.34 is available in experimental for a few
weeks. It should ease testing the fix.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1003223: buildd.debian.org: exFAT do no work on internal hard drives.

2022-01-06 Thread Aurelien Jarno
control: reassign -1 src:linux

On 2022-01-06 16:07, Mats Lundström wrote:
> Package: buildd.debian.org

exfat support is provided by the kernel and has nothing to do with
buildd.debian.org. Reassigning the bug there.

> Severity: important
> X-Debbugs-Cc: t...@digitronics.se
>
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> 
> I am trying to migrate from Windows to Linux due to security, performance and 
> hardware compatibility issues. Some of the software that I use, are available 
> both in 
> Linux and Windows, so I have been doing some performance tests. Fastest is 
> Linux (tried Lubuntu, Ubuntu and Debian and it don't matter which one), just 
> followed by
> Windows 7. Windows 10 is way behind, due to constant external communication 
> with unknown source (have seen this clearly at my work) and sometimes forced 
> reboots due
> to forced system updates (this can't be tured off in Windows 10 ...) The 
> latter is a problem, when running software 24/7 that can't resume properly at 
> reboot without
> manual interaction. If this happen when at work or during the night, the 
> computer will idle. Windows 7 (SP1) is in many ways better than Windows 10, 
> but have issues
> when trying to install it on newer systems. (Systems with i5/i7/i9 and 
> chipset Z490/Z590 blocks any Windows 7 installation ...) With 35.5 years of 
> [prof.] hardware
> and software experience, I am still convinced that Windows 7 is the best 
> Windows version, despite some would say that it lacks security. By own 
> experience, Windows
> 10 isn't actually any better though, but rather worse.
> 
> 
>* What exactly did you do (or not do) that was effective (or ineffective)?
> 
> I do stuff, including professional work related, that still are only possible 
> on Windows computers. Therefore I intend to create a dual boot system and 
> need a hard
> drive with data, that can be read properly by both Linux and Windows. A hard 
> drive that uses NTFS have issues in Linux and a hard drive that uses ext4 is 
> basically
> ignored in Windows (it detects all the partitions though). Using the hard 
> drive with exFAT via USB works, but have stability, mechanical and formost 
> performance
> issues - no go.
> 
> 
>* What was the outcome of this action?
> 
> A complete 'read only' status, that can not be changed what so ever, even 
> logged in as root. Owner of the drive is 'root' and can not be changed 
> either. Have tried
> to fix the problem with a number of HDD utilities, but none of them can do 
> much at all. (Installing a Debian based OS has not been easy, because of 
> reports of assumed
> PCIe [8086: - lost this specific address, unfortunally ...] and MMIO 
> errors with the i9/Z590 system. OS's like Windows, CentOS/Red Hat, OpenSUSE 
> do not detect
> this at all ... OpenSUSE have severe issues with Nvidia drivers ...) Files 
> can be copied to the system drive and edited there, but can only be copied 
> back as a
> duplicate copy. Soon the hard drive will be filled with a number of copies 
> ... (The fastest way to fix this, is to clean up in Windows ...) Have tried 
> to transfer
> the data to new hard drive, to exclude any issues with the hard drive itself, 
> but no difference.
> 
> 
>* What outcome did you expect instead?
> 
> A 'read/write' status. This is somewhat surprising that exFAT has not been 
> included earlier, as the standard has existed since 2006. A hard drive that 
> only can be
> used as 'read only' makes no sense.
> 
> 
> Regards
> 
> Mats Lundström

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes

2022-01-06 Thread Aurelien Jarno
On 2022-01-06 05:36, Rich wrote:
> On Thu, Jan 6, 2022 at 5:22 AM Aurelien Jarno  wrote:
> 
> > On 2022-01-06 03:36, Rich wrote:
> > > Hi Aurelien,
> > > It's a VM running in qemu on an amd64 Debian bullseye system, no KVM
> > > acceleration to be found here.
> >
> > Ok, that might be a QEMU issue then. Which CPU do you emulate with QEMU?
> >
> 
> I don't explicitly specify a -M or -cpu, so whatever it defaults to, which
> according to -M help seems to be "pseries" mapping to pseries-6.1 here.

Thanks. That allowed me to reproduce the issue locally. I tracked down
it was due to the emulation of a POWER9 CPU, things work fine with a
POWER8 CPU. I found that it has been fixed recently in the upstream 2.33
branch:

https://sourceware.org/git/?p=glibc.git;a=commit;h=c493f6a0e4dcd6fff22da0df9fb2e52ecf41

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes

2022-01-06 Thread Aurelien Jarno
On 2022-01-06 03:36, Rich wrote:
> Hi Aurelien,
> It's a VM running in qemu on an amd64 Debian bullseye system, no KVM
> acceleration to be found here.

Ok, that might be a QEMU issue then. Which CPU do you emulate with QEMU?

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes

2022-01-06 Thread Aurelien Jarno
control: tag -1 + help
control: user debian-powe...@lists.debian.org
control: usertag -1 ppc64

On 2022-01-06 01:45, Rich Ercolani wrote:
> Package: libc6
> Version: 2.33-1
> Severity: important
> X-Debbugs-Cc: rincebr...@gmail.com
> 
> Dear Maintainer,
> 
> (I marked this as serious because it's "just" ppc64, but the system is 
> permaneantly unusable if this upgrade is installed.)

I have added the powerpc list in Cc: as the ppc64 porters are the people
who can help you there.

> I booted my ppc64 VM in qemu 6.1, apt update, apt upgrade, and 20-30 packages 
> in, it died horribly
> with Python3 packages erroring out with "Cannot get content of [whatever 
> package]".

Is it a VM running with KVM or is it using QEMU emulation?

> Trying to log into a shell over ssh or at a tty after this happens dies with 
> an error that flashes fast, but
> but seems to be "free(): invalid pointer"
> 
> Random applications will now just crash out, in addition to the obvious. (I'm 
> writing this from a session
> spawned before the upgrade, which can still spawn children successfully until 
> I log out.)
> 
> If I reboot after upgrading, all services fail to start on boot, and it never 
> spawns a login prompt or rescue
> prompt, it just sits forever on a list of failed service starts.
> 
> Anything that would be helpful to debug this? I have a snapshot of the VM 
> before this began, so I can
> just roll it back and repeat the exercise.

Ideally a backtrace would help, dmesg outputs can also be useful,
however given the state of you system, they might be difficult to get.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1002968: tbb: cmake support missing on ports architectures

2022-01-01 Thread Aurelien Jarno
Source: tbb
Version: 2020.3-1
Severity: important
User: debian-ri...@lists.debian.org
Usertags: riscv64

libtbb-dev only provides cmake files on official architectures, due to
this entry in debian/control:

| Build-Depends: debhelper-compat (= 12),
|libjs-jquery,
|dh-exec,
|gdb,
|    cmake [amd64 i386 arm64 armhf mips64el mipsel ppc64el s390x],

This causes some packages build-depending on libtbb-dev to fail to build
from sources on architectures not in the above list:
https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa=riscv64=2.4.0%2Bdfsg-1=1640971630=0

Therefore, could you please drop the architectures list from the
Build-Depends, as it is available on all architectures, including ports
ones?

Thanks,
Aurelien


Bug#1002914: userv: FBTFS

2021-12-31 Thread Aurelien Jarno
Source: userv
Version: 1.2.1~beta2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

userv fails to build from source:
| dh_auto_configure
|   ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking
| checking for gcc... gcc
| checking whether the C compiler works... yes
| checking for C compiler default output file name... a.out
| checking for suffix of executables... 
| checking whether we are cross compiling... no
| checking for suffix of object files... o
| checking whether the compiler supports GNU C... yes
| checking whether gcc accepts -g... yes
| checking for gcc option to enable C11 features... none needed
| checking how to run the C preprocessor... gcc -E
| checking for a BSD-compatible install... /usr/bin/install -c
| checking for md5sum... md5sum
| checking for socket in -lsocket... no
| checking for setenv... yes
| checking for strsignal... yes
| checking for vsnprintf... yes
| checking for grep that handles long lines and -e... /bin/grep
| checking for egrep... /bin/grep -E
| checking for EPROTO... yes
| checking for LOG_AUTHPRIV... yes
| checking for WCOREDUMP... yes
| checking your C compiler... works
| checking __attribute__((,,))... yes
| checking __attribute__((noreturn))... yes
| checking __attribute__((unused))... yes
| checking __attribute__((format...))... yes
| checking GCC warning flag(s) -Wall -Wno-implicit... no
| checking GCC warning flag(s) -Wwrite-strings... ok
| checking GCC warning flag(s) -Wpointer-arith... ok
| checking GCC warning flag(s) -Wimplicit -Wnested-externs... ok
| will build version 1.2.1~beta2
| configure: creating ./config.status
| config.status: creating Makefile
| config.status: creating config.h
| make[1]: Leaving directory '/<>'
|debian/rules override_dh_auto_build
| make[1]: Entering directory '/<>'
| /usr/bin/make OPTIMISE= XCFLAGS="-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security" 
XCPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" XLDFLAGS="-Wl,-z,relro" all docs
| make[2]: Entering directory '/<>'
| cat common.h config.h config.status Makefile | md5sum \
|   | sed -e 's/  -$//; s/../0x&,/g; s/,$//;' \
|   >pcsum.h.new
| cmp pcsum.h.new pcsum.h || mv -f pcsum.h.new pcsum.h
| cmp: pcsum.h: No such file or directory
| gcc -g  -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -D_GNU_SOURCE -Wwrite-strings -Wpointer-arith 
-Wimplicit -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -DVERSION='"1.2.1~beta2"' -DVEREXT='"std"'  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o overlord.o 
overlord.c
| m4  -- tokens.h.m4 >tokens.h.new && mv tokens.h.new tokens.h
| gcc -g  -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -D_GNU_SOURCE -Wwrite-strings -Wpointer-arith 
-Wimplicit -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -DVERSION='"1.2.1~beta2"' -DVEREXT='"std"'  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o process.o 
process.c
| echo '#define VERSION "1.2.1~beta2"' >version.h.new && mv -f version.h.new 
version.h
| gcc -g  -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -D_GNU_SOURCE -Wwrite-strings -Wpointer-arith 
-Wimplicit -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -DVERSION='"1.2.1~beta2"' -DVEREXT='"std"'  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o servexec.o 
servexec.c
| m4  -- lexer.l.m4 >lexer.l.new && mv lexer.l.new lexer.l
| flex  -t lexer.l > lexer.c
| /bin/sh: 1: flex: not found
| make[2]: *** [: lexer.c] Error 127
| make[2]: Leaving directory '/<>'
| make[1]: *** [debian/rules:20: override_dh_auto_build] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:12: build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

The full build log can be found there:
https://buildd.debian.org/fetch.php?pkg=userv=amd64=1.2.1%7Ebeta2=1640811612=0



Bug#1002913: openttd: FBTFS

2021-12-31 Thread Aurelien Jarno
Source: openttd
Version: 12.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

openttd fails to build from source:
| make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
|dh_cmake_install -a -O--buildsystem=cmake
| -- Install configuration: "RelWithDebInfo"
| -- Installing: /<>/debian/openttd/usr/games/openttd
| -- Install configuration: "RelWithDebInfo"
| -- Installing: 
/<>/debian/openttd/usr/share/applications/openttd.desktop
| -- Install configuration: "RelWithDebInfo"
| -- Installing: 
/<>/debian/openttd/usr/share/doc/openttd/COPYING.md
| -- Installing: /<>/debian/openttd/usr/share/doc/openttd/README.md
| -- Installing: 
/<>/debian/openttd/usr/share/doc/openttd/changelog.txt
| -- Installing: 
/<>/debian/openttd/usr/share/doc/openttd/multiplayer.md
| -- Installing: 
/<>/debian/openttd/usr/share/doc/openttd/known-bugs.txt
|debian/rules execute_after_dh_install
| make[1]: Entering directory '/<>'
| # Prevent installing duplicate license file
| rm debian/openttd/usr/share/doc/openttd/COPYING.md
| # These are unused
| rm -r debian/openttd-data/usr/share/pixmaps
| rm: cannot remove 'debian/openttd-data/usr/share/pixmaps': No such file or 
directory
| make[1]: *** [debian/rules:46: execute_after_dh_install] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:7: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

The full build log can be found there:
https://buildd.debian.org/fetch.php?pkg=openttd=amd64=12.1-1=1640717943=0



Bug#1002484: RM: hddtemp -- ROM; dead upstream, better alternatives

2021-12-22 Thread Aurelien Jarno
Package: ftp.debian.org
Severity: normal

Dear ftp-masters,

hddtemp is a software from another age that will not be shipped with
Debian Bookworm release [1]. However it could be easily replaced by the
drivetemp kernel module (available since kernel 5.6) which uses the same
hwmon interface as for NVME drives and other systems sensors and is
supported by lm-sensors. It does not require any privilege, as opposed
to hddtemp which runs as a daemon or a setuid binary.

The fact that hddtemp was not going to be released with Bookworm was
already announced in a NEWS file [1].

No packages currently (build-)depends on it, so please remove it from
the archive. There are a few packages still recommending or suggesting
it, but bugs have already been filled.

Thanks,
Aurelien

[1] https://sources.debian.org/src/hddtemp/0.3-beta15-54/debian/NEWS/



Bug#1002052: process-cpp: FTBFS on riscv64, linked with -lpthread instead of -pthread

2021-12-20 Thread Aurelien Jarno
Source: process-cpp
Version: 3.0.1-8
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

process-cpp fails to build on riscv64 with the following failure:

| Linking CXX shared library libprocess-cpp.so
| cd /<>/obj-riscv64-linux-gnu/src && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/process-cpp.dir/link.txt --verbose=1
| /usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=c++11 -Wall -fno-strict-aliasing -fvisibility=hidden 
-fvisibility-inlines-hidden -pedantic -Wextra -Werror -Wno-error=format  
-Wl,--version-script,/<>/symbols.map -Wl,-z,relro 
-Wl,--no-undefined -shared -Wl,-soname,libprocess-cpp.so.3 -o 
libprocess-cpp.so.3.0.0 CMakeFiles/process-cpp.dir/core/posix/backtrace.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/child_process.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/exec.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/fork.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/process.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/process_group.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/signal.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/signalable.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/standard_stream.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/wait.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/this_process.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/linux/proc/process/oom_adj.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/linux/proc/process/oom_score.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/linux/proc/process/oom_score_adj.cpp.o 
CMakeFiles/process-cpp.dir/core/posix/linux/proc/process/stat.cpp.o 
CMakeFiles/process-cpp.dir/core/testing/cross_process_sync.cpp.o 
CMakeFiles/process-cpp.dir/core/testing/fork_and_run.cpp.o  
/usr/lib/riscv64-linux-gnu/libboost_iostreams.so.1.74.0 
/usr/lib/riscv64-linux-gnu/libboost_system.so.1.74.0 -lpthread 
| /usr/bin/ld: CMakeFiles/process-cpp.dir/core/posix/child_process.cpp.o: in 
function `.L0 ':
| /usr/include/riscv64-linux-gnu/c++/11/bits/gthr-default.h:778: undefined 
reference to `__atomic_exchange_1'
| collect2: error: ld returned 1 exit status

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=process-cpp=riscv64=3.0.1-8=1639996742=0

The problem is that the linking is not done correctly, it uses -lpthread
meaning linking with the pthread library, instead of -pthread which
means enable thread support, and which brings libatomic.so on riscv64.
This can be fixed by using the THREADS_PREFER_PTHREAD_FLAG option, which
is "highly recommended" according to the documentation, but
unfortunately not the default.

This is what the attached patch does, could you please include it in the
next upload?

Thanks,
Aurelien
--- process-cpp-3.0.1/debian/patches/0003-link-pthread.patch
+++ process-cpp-3.0.1/debian/patches/0003-link-pthread.patch
@@ -0,0 +1,19 @@
+Description: Link with -pthread instead of -lpthread
+ The canonical way to link with the thread library is to use -pthread, which
+ brings in additional libraries like libatomic.so on riscv64. However cmake
+ defaults to link with -lpthread which only bring the libpthread.so library.
+ Fortunately it has the option THREADS_PREFER_PTHREAD_FLAG for that, which is
+ "highly recommended" but not the default.
+Author: Aurelien Jarno 
+Last-Update: 2021-12-20
+
+--- process-cpp-3.0.1.orig/CMakeLists.txt
 process-cpp-3.0.1/CMakeLists.txt
+@@ -20,6 +20,7 @@ project(process-cpp)
+ 
+ find_package(Boost COMPONENTS iostreams system REQUIRED)
+ find_package(PkgConfig REQUIRED)
++set(THREADS_PREFER_PTHREAD_FLAG ON)
+ find_package(Threads REQUIRED)
+ 
+ pkg_check_modules(PROPERTIES_CPP properties-cpp)
--- process-cpp-3.0.1/debian/patches/series
+++ process-cpp-3.0.1/debian/patches/series
@@ -1,2 +1,3 @@
 0001-Don-t-run-tests.patch
 0002-Reproducible-documentation.patch
+0003-link-pthread.patch


Bug#1001774: tm_isdst=1 with mktime produces unexpected output

2021-12-20 Thread Aurelien Jarno
On 2021-12-20 09:06, Daniel McDonald wrote:
> Dear Aurelian,
> 
> I can confirm that changing the timezone within Ubuntu 20.04 through Github 
> Actions resolves the bug. The default set timezone is “Etc/UTC” as reported 
> by “timedatectl”. Setting to “America/Los_Angeles” with “timedatectl” allows 
> for a passing workflow. A link to the pass, with contextual information, can 
> be found here (note, this is under a fork of CPython where this behavior was 
> being investigated):
> 
> https://github.com/wasade/cpython/runs/4584894670?check_suite_focus=true#step:17:76
> 
> While this is reassuring, it seems the behavior is qualitatively different 
> across operating systems (or glibc versions). I’m unsure if that is expected. 
> As an example, we pass on Ubuntu 18.04 without changing the timezone:
> 
> https://github.com/wasade/cpython/runs/4585124128?check_suite_focus=true#step:14:43

Ubuntu 18.04 seems to run glibc 2.27. Versions of glibc older than 2.29
are affected by bug #23789 [1], and do not report any error if the date
is not representable. This is arguably a bug in Ubuntu 18.04, but this
behaviour is expected.

Regards,
Aurelien


[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23789

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1001967: libc6: I use the unstable plus experimental branch of Debian. When performing apt upgrade or apt upgrade -t experimental this dependecies bug occours: libc6 : Breaks: libc6:i386 (!= 2.34-

2021-12-19 Thread Aurelien Jarno
On 2021-12-19 19:27, Aurelien Jarno wrote:
> control: tag -1 - upstream
> 
> On 2021-12-19 18:49, d deb wrote:
> > When performing "apt upgrade" or "apt upgrade -t experimental", this
> > dependecies error occorurs: libc6 : Rompe: libc6:i386 (!=
> > 2.34-0experimental1) ma la versione 2.33-1 è installata
> >  libc6:i386 : Rompe: libc6 (!= 2.33-1) ma la versione 2.34-0experimental1 è
> > installata
> 
> Your system have i386 as a foreign architecture. It requires that both
> amd64 and i386 versions are in sync. How did you initially install
> libc6:amd64 version 2.34-0experimental1?
> 

I just did some more testing to see if I can reproduce the issue, and
this time went to actually install the upgrade, and noticed that
libc6:i386 failed to unpack due to multiarch conflict on file
/usr/share/lintian/overrides/libc6.

I believe you encountered that issue and how your system arrived in this
state. I am working on a fix on I will upload version
2.34-0experimental2 soon.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1001967: libc6: I use the unstable plus experimental branch of Debian. When performing apt upgrade or apt upgrade -t experimental this dependecies bug occours: libc6 : Breaks: libc6:i386 (!= 2.34-

2021-12-19 Thread Aurelien Jarno
control: tag -1 - upstream

On 2021-12-19 18:49, d deb wrote:
> When performing "apt upgrade" or "apt upgrade -t experimental", this
> dependecies error occorurs: libc6 : Rompe: libc6:i386 (!=
> 2.34-0experimental1) ma la versione 2.33-1 è installata
>  libc6:i386 : Rompe: libc6 (!= 2.33-1) ma la versione 2.34-0experimental1 è
> installata

Your system have i386 as a foreign architecture. It requires that both
amd64 and i386 versions are in sync. How did you initially install
libc6:amd64 version 2.34-0experimental1?

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#1001954: collectd-core: Please drop the Suggests: hddtemp

2021-12-19 Thread Aurelien Jarno
Package: collectd-core
Version: 5.12.0-7
Severity: minor

Dear maintainer,

collectd-core suggests hddtemp which is going to be removed from the
archive.

hddtemp is a software from another age that will not be shipped with
Debian Bookworm release [1]. However it could be easily replaced by the
drivetemp kernel module (available since kernel 5.6) which uses the same
hwmon interface as for NVME drives and other systems sensors and is
supported by lm-sensors. It does not require any privilege, as opposed
to hddtemp which runs as a daemon or a setuid binary.

collectd-core currently suggests hddtemp. However it also has a module
using the libsensors5 library from lm-sensors, offering an easy
transition.  It also has a module that use libatasmart4 to provide an
alternative way to read ATA drive temperatures. Therefore the fix is
therefore to drop the hddtemp suggests. You might also want to stop
building the hddtemp.so module.

Note that suggests do not affected installability, so there is no
urgency in doing so, but it should eventually be dropped.

Regards,
Aurelien

[1] https://sources.debian.org/src/hddtemp/0.3-beta15-54/debian/NEWS/



Bug#1001953: netdata-core: Please drop the Suggests: hddtemp

2021-12-19 Thread Aurelien Jarno
Package: netdata-core
Version: 1.32.1-1
Severity: minor

netdata-core suggests hddtemp which is going to be removed from the
archive.

hddtemp is a software from another age that will not be shipped with
Debian Bookworm release [1]. However it could be easily replaced by the
drivetemp kernel module (available since kernel 5.6) which uses the same
hwmon interface as for NVME drives and other systems sensors and is
supported by lm-sensors. It does not require any privilege, as opposed
to hddtemp which runs as a daemon or a setuid binary.

netdata-core currently suggests hddtemp, however support for it has been
removed upstream in version 1.20.0 [2]. The only thing to do is
therefore to drop the hddtemp suggests. Note that suggests do not
affected installability, so there is no urgency in doing so, but it
should eventually be dropped.

Regards,
Aurelien

[1] https://sources.debian.org/src/hddtemp/0.3-beta15-54/debian/NEWS/
[2] 
https://github.com/netdata/netdata/commit/162b78443a0a48bf0c012da094760375b755173e



Bug#1001950: hobbit-plugins: Please drop the Suggests: hddtemp

2021-12-19 Thread Aurelien Jarno
Package: hobbit-plugins
Version: 20201127
Severity: minor

Dear maintainer,

hobbit-plugins suggests hddtemp which is going to be removed from the
archive.

hddtemp is a software from another age that will not be shipped with
Debian Bookworm release [1]. However it could be easily replaced by the
drivetemp kernel module (available since kernel 5.6) which uses the same
hwmon interface as for NVME drives and other systems sensors and is
supported by lm-sensors. It does not require any privilege, as opposed
to hddtemp which runs as a daemon or a setuid binary.

hobbit-plugins currently suggests hddtemp to provide the optional
feature of reporting drive temperatures. As it pokes at the /sys hwmon
directory directly for the CPu temperature, you might consider doing the
same for drives temperature using a path like:
/sys/devices/pci*/*/ata*/host*/target*/*/hwmon/hwmon*/temp*_input
Alternatively you might want to call the sensors binary (from
lm-sensors) with -u (raw ouput) or -j (json output) and parse its
output.

Note that recommends do not affected installability, so it is not an
issue if hddtemp is removed from the archived before this bug is fixed.

Regards,
Aurelien

[1] https://sources.debian.org/src/hddtemp/0.3-beta15-54/debian/NEWS/



Bug#1001949: phpsysinfo: Please drop the Suggests: hddtemp

2021-12-19 Thread Aurelien Jarno
Package: phpsysinfo
Version: 3.2.5-3
Severity: minor

Dear maintainer,

phpsysinfo suggests hddtemp which is going to be removed from the
archive.

hddtemp is a software from another age that will not be shipped with
Debian Bookworm release [1]. However it could be easily replaced by the
drivetemp kernel module (available since kernel 5.6) which uses the same
hwmon interface as for NVME drives and other systems sensors and is
supported by lm-sensors. It does not require any privilege, as opposed
to hddtemp which runs as a daemon or a setuid binary.

phpsysinfo currently suggests both hddtemp and lm-sensors, offering an
easy transition. The only thing to do is therefore to drop the hddtemp
suggests. Note that suggests do not affected installability, so there is
no urgency in doing so, but it should eventually be dropped.

Regards,
Aurelien

[1] https://sources.debian.org/src/hddtemp/0.3-beta15-54/debian/NEWS/



Bug#1001946: xfce4-sensors-plugin: Please drop the Recommends: hddtemp

2021-12-19 Thread Aurelien Jarno
On 2021-12-19 13:07, Aurelien Jarno wrote:
> Package: xfce4-sensors-plugin
> Version: 1.4.2-1
> Severity: minor 
> 
> Dear maintainer,
> 
> xfce4-sensors-plugin recommends hddtemp which is going to be removed from
> the archive.
> 
> hddtemp is a software from another age that will not be shipped with
> Debian Bookworm release [1]. However it could be easily replaced by the
> drivetemp kernel module (available since kernel 5.6) which uses the same
> hwmon interface as for NVME drives and other systems sensors and is
> supported by lm-sensors. It does not require any privileged, as opposed
> to hddtemp which runs as a daemon or a setuid binary.
> 
> xfce4-sensors-plugin currently recommends hddtemp, and it also depends
> on the libsensor5 library from lm-sensors, offering an easy transition.
> The only thing to do is therefore to drop the hddtemp recommends. Note
> that recommends do not affected installability, so there is no urgency
> in doing so, but it should eventually be dropped.

I was actually wrong about that. It appears that xfce4-sensors-plugin
also build-depends on hddtemp, therefore that should be dropped to,
probably de-activating the support at build time.

Thanks,
Aurelien



Bug#1001948: wmhdplop: Please drop the Recommends: hddtemp

2021-12-19 Thread Aurelien Jarno
Package: wmhdplop
Version: 0.9.11-2
Severity: normal

Dear maintainer,

wmhdplop recommends hddtemp which is going to be removed from the
archive.

hddtemp is a software from another age that will not be shipped with
Debian Bookworm release [1]. However it could be easily replaced by the
drivetemp kernel module (available since kernel 5.6) which uses the same
hwmon interface as for NVME drives and other systems sensors and is
supported by lm-sensors. It does not require any privilege, as opposed
to hddtemp which runs as a daemon or a setuid binary.

wmhdplop currently recommends hddtemp to provide the optional feature of
reporting drive temperatures. You might want to consider other
alternative to provide that feature:
- use of the libsensors5 library (from lm-sensors), which can report
  drive temperatures from ATA drives but also NVME drives.
- use of the libatasmart4 library (ATA drives only)
Note that recommends do not affected installability, so it is not an
issue if hddtemp is removed from the archived before this bug is fixed.

Regards,
Aurelien

[1] https://sources.debian.org/src/hddtemp/0.3-beta15-54/debian/NEWS/



Bug#1001945: sensors-applet: Please drop the Recommends: hddtemp

2021-12-19 Thread Aurelien Jarno
Package: sensors-applet
Version: 3.0.0+git6-0.5
Severity: minor

Dear maintainer,

sensors-applet recommends hddtemp which is going to be removed from the
archive.

hddtemp is a software from another age that will not be shipped with
Debian Bookworm release [1]. However it could be easily replaced by the
drivetemp kernel module (available since kernel 5.6) which uses the same
hwmon interface as for NVME drives and other systems sensors and is
supported by lm-sensors. It does not require any privileged, as opposed
to hddtemp which runs as a daemon or a setuid binary.

sensors-applet currently recommends both hddtemp, and it also depends on
the libsensor5 library from lm-sensors, offering an easy transition.
Therefore the fix is therefore to drop the hddtemp recommends and update
the package description accordingly. Note that recommends do not
affected installability, so there is no urgency in doing so, but it
should eventually be dropped.

Regards,
Aurelien

[1] https://sources.debian.org/src/hddtemp/0.3-beta15-54/debian/NEWS



  1   2   3   4   5   6   7   8   9   10   >