Bug#1016821: libspf2: FTBFS with glibc 2.34
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
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
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
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
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
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
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
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
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
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
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'
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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)
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)
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
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
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
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
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
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
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))
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?
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
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?
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
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.
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
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
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
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
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
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
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
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
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
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-
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-
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
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
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
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
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
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
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
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
