Bug#1072204: setupcon: race condition with systemd-tmpfiles
Control: Tags -1 + pending Marc Leeman, le mer. 29 mai 2024 11:46:46 +0200, a ecrit: > On occasion I have a situation where console-setup.service fails to > start up due to a race condition. After investigating this, it was > already reported in Ubuntu back in 2019 and I have verified that the > patch they have implemented resolves the issue for me: Ok, applied, thanks! Samuel
Bug#1072472: util-linux: Please ignore y2k issue on 32bit hurd
Package: util-linux Version: 2.40.1-1 Severity: important Tags: patch Hello, With the incoming hurd-amd64 support, we don't plan to support hurd-i386 beyond 2038, so we don't plan to bother about y2k issues there, thus fixing the FTBFS https://buildd.debian.org/status/fetch.php?pkg=util-linux=hurd-i386=2.40.1-4=1717104811=0 configure: error: could not enable timestamps after mid-January 2038. This package recommends support for these later timestamps. However, to proceed with signed 32-bit time_t even though it will fail then, configure with '--disable-year2038'. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.9.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii libblkid1 2.40.1-1 ii libc6 2.38-11 ii libcap-ng0 0.8.5-1 ii libcrypt1 1:4.4.36-4 ii libmount1 2.40.1-1 ii libpam0g 1.5.3-7 ii libselinux13.5-2+b2 ii libsmartcols1 2.40.1-1 ii libsystemd0255.5-1 ii libtinfo6 6.5-2 ii libudev1 255.5-1 ii libuuid1 2.40.1-1 Versions of packages util-linux recommends: ii sensible-utils 0.0.22 Versions of packages util-linux suggests: ii dosfstools 4.2-1.1 ii kbd 2.6.4-2 ii util-linux-extra2.40.1-1 ii util-linux-locales 2.40.1-1 -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. --- debian/rules.original 2024-06-02 14:26:40.0 + +++ debian/rules2024-06-02 14:27:16.0 + @@ -24,6 +24,11 @@ endif endif +ifeq ($(DEB_HOST_ARCH),hurd-i386) +# we don't plan to keep the 32bit support beyond 2038 + CONFOPTS += --disable-year2038 +endif + CONFOPTS += --enable-write
Bug#1072338: syndication: fix building with nocheck
Source: syndication Version: 5.115.0-2 Severity: important Hello, syndication currently fails to build with DEB_BUILD_OPTIONS=nocheck: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libkf5syndication5abi1/DEBIAN/symbols doesn't match completely debian/libkf5syndication5abi1.symbols --- debian/libkf5syndication5abi1.symbols (libkf5syndication5abi1_1:5.115.0-2_amd64) +++ dpkg-gensymbolsscli3z 2024-06-01 08:16:49.0 + @@ -1,7 +1,7 @@ libKF5Syndication.so.5abi1 libkf5syndication5abi1 #MINVER# * Build-Depends-Package: libkf5syndication-dev ABI_5_1@ABI_5_1 18.07.90 - _ZN11Syndication10LoaderUtil9parseFeedERK10QByteArrayRK4QUrl@ABI_5_1 1:5.69.0 +#MISSING: 1:5.115.0-2# _ZN11Syndication10LoaderUtil9parseFeedERK10QByteArrayRK4QUrl@ABI_5_1 1:5.69.0 _ZN11Syndication10PersonImplC1ERK7QStringS3_S3_@ABI_5_1 18.07.90 _ZN11Syndication10PersonImplC1Ev@ABI_5_1 18.07.90 _ZN11Syndication10PersonImplC2ERK7QStringS3_S3_@ABI_5_1 18.07.90 Indeed, with tests disabled, ./src/syndication_private_export.h defines SYNDICATION_TESTS_EXPORT to empty, and thus this declaration hides the symbol: ./src/loaderutil_p.h:Q_REQUIRED_RESULT SYNDICATION_TESTS_EXPORT QUrl parseFeed(const QByteArray , const QUrl ); So it's effectively an optional symbol, could you apply the attached patch to fix this? Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.9.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- debian/libkf5syndication5abi1.symbols.orig 2024-06-01 09:52:19.0 + +++ debian/libkf5syndication5abi1.symbols 2024-06-01 09:52:21.0 + @@ -2,7 +2,7 @@ libKF5Syndication.so.5abi1 libkf5syndication5abi1 #MINVER# * Build-Depends-Package: libkf5syndication-dev ABI_5_1@ABI_5_1 18.07.90 - _ZN11Syndication10LoaderUtil9parseFeedERK10QByteArrayRK4QUrl@ABI_5_1 1:5.69.0 + (optional)_ZN11Syndication10LoaderUtil9parseFeedERK10QByteArrayRK4QUrl@ABI_5_1 1:5.69.0 _ZN11Syndication10PersonImplC1ERK7QStringS3_S3_@ABI_5_1 18.07.90 _ZN11Syndication10PersonImplC1Ev@ABI_5_1 18.07.90 _ZN11Syndication10PersonImplC2ERK7QStringS3_S3_@ABI_5_1 18.07.90
Bug#1072337: gst-plugins-good1.0: Missing build-dep for non-linux
Samuel Thibault, le sam. 01 juin 2024 11:30:27 +0200, a ecrit: > Some dependencies are missing for gst-plugins-good1.0 on non-linux: > > --- debian/control.orig 2024-06-01 11:28:00.933813029 +0200 > +++ debian/control2024-06-01 11:30:01.364309857 +0200 > @@ -27,6 +27,7 @@ > libaa1-dev (>= 1.4p5), > libflac-dev (>= 1.1.4), > libdv4-dev | libdv-dev, > + libsoup-3.0-dev [!linux-any], > libxdamage-dev, > libxext-dev, > libxfixes-dev, I forgot to mention why only on non-linux: > https://buildd.debian.org/status/fetch.php?pkg=gst-plugins-good1.0=hurd-i386=1.24.4-1=1717159633=0 > ../ext/adaptivedemux2/meson.build:104:6: ERROR: Problem encountered: > adaptivedemux2: Either libsoup2 or libsoup3 is needed In ./ext/soup/meson.build this is inside if host_system != 'linux' or default_library in ['static', 'both'] Samuel
Bug#1072337: gst-plugins-good1.0: Missing build-dep for non-linux
Source: gst-plugins-good1.0 Version: 1.24.4-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertag: hurd Hello, Some dependencies are missing for gst-plugins-good1.0 on non-linux: https://buildd.debian.org/status/fetch.php?pkg=gst-plugins-good1.0=hurd-i386=1.24.4-1=1717159633=0 ../ext/adaptivedemux2/meson.build:104:6: ERROR: Problem encountered: adaptivedemux2: Either libsoup2 or libsoup3 is needed https://buildd.debian.org/status/fetch.php?pkg=gst-plugins-good1.0=hurd-i386=1.24.4-1=1717233674=0 ../ext/qt6/meson.build:64:6: ERROR: Program 'qsb-qt6 qsb' not found or not executable the attached patch fixes them, could you apply it? Thanks, Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.9.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- debian/control.orig 2024-06-01 11:28:00.933813029 +0200 +++ debian/control 2024-06-01 11:30:01.364309857 +0200 @@ -27,6 +27,7 @@ libaa1-dev (>= 1.4p5), libflac-dev (>= 1.1.4), libdv4-dev | libdv-dev, + libsoup-3.0-dev [!linux-any], libxdamage-dev, libxext-dev, libxfixes-dev, @@ -51,7 +52,7 @@ qttools5-dev [amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x hurd-i386 powerpc ppc64 sparc64], qt6-base-private-dev [amd64 arm64 armel armhf mips64el ppc64el riscv64 s390x hurd-i386 powerpc ppc64 sparc64], qt6-declarative-dev [amd64 arm64 armel armhf mips64el ppc64el riscv64 s390x hurd-i386 powerpc ppc64 sparc64], - qt6-shader-baker [amd64 arm64 armel armhf mips64el ppc64el riscv64 s390x powerpc ppc64 sparc64], + qt6-shader-baker [amd64 arm64 armel armhf mips64el ppc64el riscv64 s390x hurd-i386 powerpc ppc64 sparc64], qt6-tools-dev [amd64 arm64 armel armhf mips64el ppc64el riscv64 s390x hurd-i386 powerpc ppc64 sparc64], qt6-wayland-dev [amd64 arm64 armel armhf mips64el ppc64el riscv64 s390x powerpc ppc64 sparc64], libqt5x11extras5-dev [amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x hurd-i386 powerpc ppc64 sparc64],
Bug#1072224: gst-plugins-base1.0: FTBFS on hurd-any
Source: gst-plugins-base1.0 Version: 1.24.4-1 Severity: important Tags: patch ftbfs User: debian-h...@lists.debian.org Usertags: hurd Hello, The attached patch fixes the build of gst-plugins-base1.0 on hurd-any, could you apply it? Thanks, Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.9.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- debian/rules.original 2024-05-30 17:12:55.0 + +++ debian/rules2024-05-30 17:32:59.0 + @@ -33,6 +33,7 @@ ifeq ($(DEB_HOST_ARCH_OS),hurd) conf_flags += -Dcdparanoia=disabled +conf_flags += -Ddrm=disabled endif ifneq ($(DEB_HOST_ARCH_OS),linux) --- debian/libgstreamer-gl1.0-0.symbols.orig2024-05-30 17:31:05.0 + +++ debian/libgstreamer-gl1.0-0.symbols 2024-05-30 17:31:32.0 + @@ -36,7 +36,7 @@ (arch=linux-any kfreebsd-any)gst_egl_image_from_dmabuf@Base 1.14.0 (arch=linux-any kfreebsd-any)gst_egl_image_from_dmabuf_direct@Base 1.16.0 (arch=linux-any kfreebsd-any)gst_egl_image_from_dmabuf_direct_target@Base 1.18.0 - gst_egl_image_from_dmabuf_direct_target_with_dma_drm@Base 1.23.1 + (arch=linux-any kfreebsd-any)gst_egl_image_from_dmabuf_direct_target_with_dma_drm@Base 1.23.1 gst_egl_image_from_texture@Base 1.14.0 gst_egl_image_get_image@Base 1.14.0 gst_egl_image_get_type@Base 1.14.0
Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py
Control: reopen -1 = > I have read the other replies to the bug, which I missed previously. > It's not upstream's intention to ship the modules in dist-packages. Nevermind this, I misread upstream's response. Upstream contacted me to ask about it and it's clear to me now. Nilson: > As Sherlock is a private module, I moved it to usr/share according to this > policy here: Sherlock is not a private module. Please proceed with importing the upstream PR to fix the issue. Cheers, -- Samuel Henrique
Bug#1071823: console-setup: [Hurd i386] debconf: lsmod: not found
Hello, Martin-Éric Racine, le sam. 25 mai 2024 10:07:45 +0300, a ecrit: > Severity: important Why important? > While upgrading from 1.223 to 1.226 on Hurd i386: > > Fetched 32.4 MB in 23s (1429 kB/s) > > > Extracting templates from packages: 100% > Preconfiguring packages ... > /var/cache/debconf/tmp.ci/console-setup.config.otOVsK: 1196: lsmod: not found What consequence does it have? I don't remember upgrading console-setup getting broken. If it's only a warning, that's completely fine. Samuel
Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py
Control: reopen -1 = The latest upload broke the package, this time by mis-placing the files in /usr/share/: https://salsa.debian.org/pkg-security-team/sherlock/-/commit/58dacca3117b66341a4371431d6f38a1d35b08c9 https://salsa.debian.org/pkg-security-team/sherlock/-/commit/00a20c5cc3a9c42a295e886dee1db49472338c4e The commit "58dacca3117b66341a4371431d6f38a1d35b08c" is also doing more than what's described in its message. I'm not sure dh_link is the right place to remove test files, but I haven't looked into that deeply. This breaks the ability to import sherlock into other python scripts, since it's not under dist-packages anymore. The original proposed solution to the issue still stands: we just need to not ship files at the root of dist-packages. Regards, -- Samuel Henrique
Bug#1065456: python3.11: Please don't enable dtrace on hurd
Hello, Pinging on this? Samuel Samuel Thibault, le lun. 04 mars 2024 23:59:15 +0100, a ecrit: > python3.11 currently fails to build on hurd-any because debian/rules > enables dtrace, which is not available on hurd-any. > > Could you apply the attached patch that fixes this, on python3.11 as > well as on python3.12? > > Thanks, > Samuel --- debian/rules.orig 2024-03-03 10:23:40.0 +0100 +++ debian/rules2024-03-04 23:54:06.808627222 +0100 @@ -441,7 +441,6 @@ --with-computed-gotos \ --without-ensurepip \ --with-system-expat \ - --with-dtrace \ --with-ssl-default-suites=openssl \ --with-wheel-pkg-dir=/usr/share/python-wheels/ \ --with-ssl-default-suites=openssl \ @@ -453,6 +452,10 @@ common_configure_args += --with-system-ffi endif +ifeq (,$(filter $(DEB_HOST_ARCH_OS), hurd)) + common_configure_args += --with-dtrace +endif + ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) common_configure_args += --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) common_configure_args += --with-build-python
Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py
Control: reopen -1 = I see on git that the bug was closed with a Conflicts+Replaces stanza, but that's not the correct solution for this issue. As discussed on this bugreport, the fix is to not ship the file. Reopening to block the problematic package to migrate to testing. Cheers, -- Samuel Henrique
Bug#1070957: nghttp3: Stable backports for nghttp3 and ngtcp2
Source: nghttp3 Severity: wishlist X-Debbugs-Cc: c...@packages.debian.org, samuel...@debian.org Hello Sakirnth, This is another issue related to HTTP3 support for curl. If we push the newer nghttp3 and ngtcp2 packages to stable-backports, we will be able to enable HTTP3 in curl there too. I would like to upload the current packages we have on testing (for both nghttp3 and ngtcp2) to stable-bpo, so they can clear the NEW queue (it might take a while). Then once the updated packages hit testing, I can update them on bpo and unblock http3 for curl there. Do you see any issues with this or have a preference on not following this approach? Regards, -- Samuel Henrique
Bug#1070079: nghttp3: Update to 1.1.0 or newer
Hello Sakirnth, > I am good and I hope you too. All good on my side too :) > On 4/29/24 22:24, Samuel Henrique wrote: > > So maybe it even makes sense to get the latest releases for the transition. > > I agree. I normaly do both nghttp3 and ngtcp2 the same time, therefore I > didn't want to block the t64 transition. Since ngtcp2 was a reverse > dependency of affected packages. I will try to upload the latest version > this weekend to experimental. Cool, I've already done a test build of curl and spotted no issues, but I will only upload it to experimental once ngtcp2 is also there (curl requires at least 1.2.0, latest is 1.5.0). > > Would you be interested in any kind of help for this? > > Thanks, I will let you know this weekend. Probably in testing the > rebuild of Wireshark with the new version of nghttp3. Sounds good, just let me know. > > If you would like, we could also put the package under the curl team. We are > > not a "real team" in the sense that we don't gate contributions, that's > > just to > > make it more easy and clear that people should feel free to do team-uploads. > > Yes, that would be good. Given that I can put ngtcp2 also under the curl > team. Awesome! Have a nice weekend! -- Samuel Henrique
Bug#1037258: curl -I (HEAD request) fails with HTTP/2 against a Debian Apache instance
I've requested help from upstream on curl-library: https://curl.se/mail/lib-2024-05/0020.html It looks like the regression is partially back on the 8.7.1 as well: > HTTP/2 200 > expires: Fri, 01 Jan 1980 00:00:00 GMT > pragma: no-cache > cache-control: no-cache, max-age=0, must-revalidate > x-content-type-options: nosniff > x-frame-options: sameorigin > referrer-policy: no-referrer > x-xss-protection: 1 > permissions-policy: interest-cohort=() > strict-transport-security: max-age=15552000 > vary: Accept-Encoding > x-clacks-overhead: GNU Terry Pratchett > content-type: text/plain > date: Sat, 11 May 2024 19:33:28 GMT > server: Apache > > curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1) I get both the payload and the error. Regards -- Samuel Henrique
Bug#1070917: pycurl: Please revert back to the GnuTLS libcurl, for HTTP3 support
Source: pycurl Version: 7.45.3-2 Severity: wishlist X-Debbugs-Cc: c...@packages.debian.org, samuel...@debian.org Hello Scott, On the latest upload of pycurl, the libcurl variant used to link against was switched from GnutTLS to OpenSSL. The request came from #1065007 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065007) but I don't think there were any valid reasons for the switch documented on the request. We are about to enable HTTP3 on the GnutTlS libcurl, and it's very unlikely that we will get HTTP3 support for the OpenSSL libcurl before the next stable release. If you revert the change back to GnutTLS, then pycurl will have support for HTTP3 very soon, otherwise it won't get it until after the next stable release. I also have plans on moving curl (the CLI) to the GnutTLS libcurl so we can get HTTP3 support on the curl command for the next stable release. For reference, this table lists the options which would be missing from GnuTLS, compared to OpenSSL (some of them are OpenSSL-specific so GnuTLS is not really missing): https://curl.se/libcurl/c/tls-options.html Curl upstream has shown interest in helping increase the compatibility for GnutTLS, so we can open a feature request for any option there that's mising. I believe it won't be an issue to revert back to GnuTLS because that's what the package was using before the latest upload. Regards, -- Samuel Henrique
Bug#1070300: pmix_psquash_base_select failed during MPI_INIT on 32bit architectures
Samuel Thibault, le sam. 04 mai 2024 11:49:40 +0200, a ecrit: > Samuel Thibault, le ven. 03 mai 2024 19:00:22 +0200, a ecrit: > > This has been posing migration issues for quite some time, I have > > uploaded the attached fix to delayed/0. > > Some of the components depend on libmca_common_libdstore which also > needs to be installed, otherwise openmpi emits some text on stderr, > which some autopkgtest don't like, I have uploaded the attached changes > to delayed/0 Sorry it seems my tests had gone bogus, I do remember testing the result but apparently obviously failed to. I have double-checked my changes this time, as attached and uploaded to delayed/0 (now that openmpi got a bit force-migrated to testing) Samuel diff -Nru openmpi-4.1.6/debian/changelog openmpi-4.1.6/debian/changelog --- openmpi-4.1.6/debian/changelog 2024-05-04 11:32:26.0 +0200 +++ openmpi-4.1.6/debian/changelog 2024-05-05 20:38:36.0 +0200 @@ -1,3 +1,10 @@ +openmpi (4.1.6-13.3) unstable; urgency=medium + + * Non-maintainer Upload + * Really install libmca_common_dstore. + + -- Samuel Thibault Sun, 05 May 2024 20:38:36 +0200 + openmpi (4.1.6-13.2) unstable; urgency=medium * Non-maintainer Upload diff -Nru openmpi-4.1.6/debian/rules openmpi-4.1.6/debian/rules --- openmpi-4.1.6/debian/rules 2024-05-04 11:32:26.0 +0200 +++ openmpi-4.1.6/debian/rules 2024-05-05 20:38:36.0 +0200 @@ -289,10 +289,11 @@ dh_install -p libopenmpi3t64 $(LIBDIR)/openmpi/lib/libpmix.so.2.2.35 $(LIBDIR) ; \ dh_install -p libopenmpi3t64 /usr/share/pmix ; \ dh_install -p libopenmpi3t64 "/usr/lib/$(DEB_HOST_MULTIARCH)/openmpi/lib/pmix/*.so" ; \ - if test -f $(DESTDIR)/$(LIBDIR)/openmpi/lib/libmca_common_libdstore.so.1.0.2 ; then \ - dh_install -p libopenmpi3t64 $(LIBDIR)/libmca_common_libdstore.so.1.0.2 ; \ - dh_link -p libopenmpi3t64 $(LIBDIR)/libmca_common_libdstore.so.1.0.2 $(LIBDIR)/libmca_common_libdstore.so.1 ; \ - dh_link -p libopenmpi-dev $(LIBDIR)/libmca_common_libdstore.so.1 $(LIBDIR)/libmca_common_libdstore.so ; \ + if test -f $(DESTDIR)/$(LIBDIR)/openmpi/lib/libmca_common_dstore.so.1.0.2 ; then \ + dh_install -p libopenmpi3t64 $(LIBDIR)/openmpi/lib/libmca_common_dstore.so.1.0.2 $(LIBDIR) ; \ + dh_link -p libopenmpi3t64 $(LIBDIR)/libmca_common_dstore.so.1.0.2 $(LIBDIR)/libmca_common_dstore.so.1 ; \ + dh_link -p libopenmpi-dev $(LIBDIR)/libmca_common_dstore.so.1 $(LIBDIR)/openmpi/lib/libmca_common_dstore.so ; \ + dh_link -p libopenmpi-dev $(LIBDIR)/libmca_common_dstore.so.1 $(LIBDIR)/libmca_common_dstore.so ; \ fi ; \ dh_link -p libopenmpi3t64 $(LIBDIR)/libpmix.so.2.2.35 $(LIBDIR)/libpmix.so.2 ; \ dh_link -p libopenmpi-dev $(LIBDIR)/libpmix.so.2 $(LIBDIR)/openmpi/lib/libpmix.so ; \
Bug#1070300: pmix_psquash_base_select failed during MPI_INIT on 32bit architectures
Samuel Thibault, le ven. 03 mai 2024 19:00:22 +0200, a ecrit: > This has been posing migration issues for quite some time, I have > uploaded the attached fix to delayed/0. Some of the components depend on libmca_common_libdstore which also needs to be installed, otherwise openmpi emits some text on stderr, which some autopkgtest don't like, I have uploaded the attached changes to delayed/0 Samuel diff -Nru openmpi-4.1.6/debian/changelog openmpi-4.1.6/debian/changelog --- openmpi-4.1.6/debian/changelog 2024-05-03 18:53:52.0 +0200 +++ openmpi-4.1.6/debian/changelog 2024-05-04 11:32:26.0 +0200 @@ -1,3 +1,11 @@ +openmpi (4.1.6-13.2) unstable; urgency=medium + + * Non-maintainer Upload + * Also install libmca_common_dstore. + * Do not install .la pmix files. + + -- Samuel Thibault Sat, 04 May 2024 11:32:26 +0200 + openmpi (4.1.6-13.1) unstable; urgency=medium * Non-maintainer Upload diff -Nru openmpi-4.1.6/debian/rules openmpi-4.1.6/debian/rules --- openmpi-4.1.6/debian/rules 2024-05-03 18:49:28.0 +0200 +++ openmpi-4.1.6/debian/rules 2024-05-04 11:32:26.0 +0200 @@ -288,7 +288,12 @@ echo "PMIX: install " ; \ dh_install -p libopenmpi3t64 $(LIBDIR)/openmpi/lib/libpmix.so.2.2.35 $(LIBDIR) ; \ dh_install -p libopenmpi3t64 /usr/share/pmix ; \ - dh_install -p libopenmpi3t64 /usr/lib/$(DEB_HOST_MULTIARCH)/openmpi/lib/pmix ; \ + dh_install -p libopenmpi3t64 "/usr/lib/$(DEB_HOST_MULTIARCH)/openmpi/lib/pmix/*.so" ; \ + if test -f $(DESTDIR)/$(LIBDIR)/openmpi/lib/libmca_common_libdstore.so.1.0.2 ; then \ + dh_install -p libopenmpi3t64 $(LIBDIR)/libmca_common_libdstore.so.1.0.2 ; \ + dh_link -p libopenmpi3t64 $(LIBDIR)/libmca_common_libdstore.so.1.0.2 $(LIBDIR)/libmca_common_libdstore.so.1 ; \ + dh_link -p libopenmpi-dev $(LIBDIR)/libmca_common_libdstore.so.1 $(LIBDIR)/libmca_common_libdstore.so ; \ + fi ; \ dh_link -p libopenmpi3t64 $(LIBDIR)/libpmix.so.2.2.35 $(LIBDIR)/libpmix.so.2 ; \ dh_link -p libopenmpi-dev $(LIBDIR)/libpmix.so.2 $(LIBDIR)/openmpi/lib/libpmix.so ; \ dh_link -p libopenmpi-dev $(LIBDIR)/libpmix.so.2 $(LIBDIR)/libpmix.so ; \
Bug#1070300: pmix_psquash_base_select failed during MPI_INIT on 32bit architectures
Hello, This has been posing migration issues for quite some time, I have uploaded the attached fix to delayed/0. Samuel diff -Nru openmpi-4.1.6/debian/changelog openmpi-4.1.6/debian/changelog --- openmpi-4.1.6/debian/changelog 2024-04-27 18:37:26.0 +0200 +++ openmpi-4.1.6/debian/changelog 2024-05-03 18:53:52.0 +0200 @@ -1,3 +1,10 @@ +openmpi (4.1.6-13.1) unstable; urgency=medium + + * Non-maintainer Upload + * Also install pmix components on 32-bit systems. Closes: #1070300 + + -- Samuel Thibault Fri, 03 May 2024 18:53:52 +0200 + openmpi (4.1.6-13) unstable; urgency=medium * Move pmix help files to libopenmpi3t64, not openmpi3-common diff -Nru openmpi-4.1.6/debian/rules openmpi-4.1.6/debian/rules --- openmpi-4.1.6/debian/rules 2024-04-27 18:37:26.0 +0200 +++ openmpi-4.1.6/debian/rules 2024-05-03 18:49:28.0 +0200 @@ -287,7 +287,8 @@ if $(DO_OWN_PMIX); then \ echo "PMIX: install " ; \ dh_install -p libopenmpi3t64 $(LIBDIR)/openmpi/lib/libpmix.so.2.2.35 $(LIBDIR) ; \ - dh_install -p libopenmpi3t64 /usr/share/pmix/* ; \ + dh_install -p libopenmpi3t64 /usr/share/pmix ; \ + dh_install -p libopenmpi3t64 /usr/lib/$(DEB_HOST_MULTIARCH)/openmpi/lib/pmix ; \ dh_link -p libopenmpi3t64 $(LIBDIR)/libpmix.so.2.2.35 $(LIBDIR)/libpmix.so.2 ; \ dh_link -p libopenmpi-dev $(LIBDIR)/libpmix.so.2 $(LIBDIR)/openmpi/lib/libpmix.so ; \ dh_link -p libopenmpi-dev $(LIBDIR)/libpmix.so.2 $(LIBDIR)/libpmix.so ; \
Bug#1070079: nghttp3: Update to 1.1.0 or newer
Source: nghttp3 X-Debbugs-Cc: c...@packages.debian.org, samuel...@debian.org Version: 1.1.0-1 Severity: wishlist Hello Sakirnth, I hope you're doing well. I see that you uploaded nghttp3 1.1.0-1 and ngtcp2 1.1.0-1 to experimental already. Do you have any plans to push those to unstable anytime soon? I would like to enable HTTP3 on libcurl-gnutls and it requires: nghttp3: v1.1.0 ngtcp2: v1.2.0 The latest releases are: nghttp3 v1.2.0 ngtcp2 v1.4.0 So maybe it even makes sense to get the latest releases for the transition. Would you be interested in any kind of help for this? If you would like, we could also put the package under the curl team. We are not a "real team" in the sense that we don't gate contributions, that's just to make it more easy and clear that people should feel free to do team-uploads. Regards, -- Samuel Henrique
Bug#1069258: ruby-curb: test regression with curl 8.7.1: client read function EOF fail, only only 4/5 of needed bytes read
Hello all, > These messages with "only only (n)/(n+1) of needed bytes read" seem to > be characteristic. As well as being a FTBFS, this is also an autopkgtest > regression when upgrading curl, which is one of several factors preventing > curl from migrating; that, in turn, blocks elfutils, which blocks GLib, > which will likely be blocking a significant chunk of the 64-bit time_t > transition. I believe this is an issue on ruby-curb and not on curl, check the following thread on curl-library for details and possible solutions: https://curl.se/mail/lib-2024-03/0054.html Cheers, -- Samuel Henrique
Bug#1059679: lua-json missing lua 5.4 files
Hi, I'm running into the same issue, is it possible to provide an update for this package? Thanks. Samuel
Bug#1069791: console-setup: Build larger console fonts for HiDPI/accessibility with future 6.9 kernels
Joseph Carter, le dim. 28 avril 2024 16:21:06 -0700, a ecrit: > Even so, could you try to include a DejaVuSansMonoBold font as well? It's also included in my change. Samuel
Bug#595696: Bug#594817: console-setup should configure the width of the console
Samuel Thibault, le mar. 01 sept. 2015 19:40:30 +0200, a ecrit: > Anton Zinoviev, le Tue 01 Sep 2015 20:31:33 +0300, a écrit : > > On Tue, Aug 25, 2015 at 10:20:46PM +0200, Samuel Thibault wrote: > > > Samuel Thibault, le Sun 29 Aug 2010 21:08:05 +0200, a écrit : > > > > We could even imagine to > > > > rasterize a vector font on the fly for very big sizes. > > > > > > otf2bdf and bdf2psf could be used for that, for instance if the user > > > specifies the width (which will be the most probable use, people usually > > > > I am afraid of such automatic conversion. There are too many > > combinations which can easily lead to many undiscovered bugs... I'd > > prefer if we use otf2bdf and bdf2psf manually in order to add a few new > > fonts in the source package of console-setup. > > Right, that can be enough, indeed. We can add more as screen get more > dpi (and make it simple to change in the package build for users to > build them easily if they need) I just did that :) Up to 64b width, the maximum width that will be allowed by linux 6.9. Samuel
Bug#1069791: console-setup: Build larger console fonts for HiDPI/accessibility with future 6.9 kernels
Control: forcemerge -1 816111 Hello, T. Joseph Carter, le mer. 24 avril 2024 13:25:22 -0700, a ecrit: > Linux kernel 6.9+ will support larger font sizes for HiDPI screens. This > is probably aimed at "more than 4k" monitors, but for accessibility > reasons it would be really useful to have larger sizes available sooner > for those of us already have 4k sorts of screens. Yes, that was the points in adding the support in the kernel :) > Perhaps this might best be done by putting those huge-sized fonts in an > appropriately named -huge fonts package? I'll leave the implementation > details to you, this is just a request for the fonts to be created. We already had the request in #816111, also #595696 was about possibly generalizing to using rasterized fonts. I gave a try at converting terminus.ttf to bdf with otf2bdf: otf2bdf -c C -p 32 -r 72 /usr/share/fonts/truetype/terminus/TerminusTTF-4.46.0.ttf > /tmp/terminus.bdf bdf2psf --fb /tmp/terminus.bdf /usr/share/bdf2psf/standard.equivalents ascii.set 256 /tmp/terminus.psf /tmp/terminus.sfm but the baseline is not coherent. Using DejaVuSansMono seems to be working better: otf2bdf -c C -p 32 -r 100 /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf > /tmp/DejaVuSansMono.bdf bdf2psf --fb --width 32 /tmp/DejaVuSansMono.bdf /usr/share/bdf2psf/standard.equivalents ascii.set 256 /tmp/DejaVuSansMono.psf /tmp/DejaVuSansMono.sfm (I'm adding a new --width parameter to bdf2psf to specify the expected width since AVERAGE_WIDTH as set by otf2bdf doesn't really tell) Samuel
Bug#1069433: gtg-trace: FTBFS on armhf: tests fail
Control: reassign -1 openmpi
Control: affects -1 gtg-trace
Hello,
Lucas Nussbaum, le sam. 20 avril 2024 14:52:03 +0200, a ecrit:
> > --
> > Sorry! You were supposed to get help about:
> > pmix_init:startup:internal-failure
> > But I couldn't open the help file:
> > /usr/share/pmix/help-pmix-runtime.txt: No such file or directory.
> > Sorry!
> > --
> > [ip-10-84-234-251:1132190] PMIX ERROR: NOT-FOUND in file
> > ../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/server/pmix_server.c
> > at line 237
> > running testEvent_parall 1
> > --
This happens on i386 too, but also with the following trivial testcase
on armhf and i386:
$ cat test.c
#include
#include
int main(int argc, char *argv[]) {
int size, rank;
MPI_Init(, );
MPI_Comm_size(MPI_COMM_WORLD, );
MPI_Comm_rank(MPI_COMM_WORLD, );
printf("%d/%d\n", rank, size);
MPI_Finalize();
return 0;
}
$ mpicc test.c -o test
$ mpirun -np 2 ./test
--
Sorry! You were supposed to get help about:
pmix_init:startup:internal-failure
But I couldn't open the help file:
/usr/share/pmix/help-pmix-runtime.txt: No such file or directory. Sorry!
--
[abel:25256] PMIX ERROR: NOT-FOUND in file
../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/server/pmix_server.c at
line 237
Thus reassigning to openmpi. It seems that even if pmix is not built on
32bit archs any more, openmpi is still enabling pmix support, perhaps
that needs to be disabled?
Samuel
Bug#1065007: pycurl: Please reconsider SSL choice (OpenSSL instead of GnuTLS)
Hello Boyuan and Scott, > I was made aware of issues encountered by multiple users due to pycurl using > GnuTLS instead of OpenSSL. Reviewing https://bugs.debian.org/515200 , it > looks like the > only reason of not using OpenSSL is the old OpenSSL licensing issue in the > past. That bug is 15 years old and you did not mention any details about the issues that you're having. Effectively there is no documented reason to switch to openssl on this bug. Scott, I see that you went ahead and switched to openssl anyway: > I don't have any objections to rebuilding pycurl with openssl. We are close to enabling support to http3 for the gnutls libcurl, so this switch kills any possibility of pycurl supporting http3, at least until openssl gets proper http3 support (might not happen for the next stable release). On the curl side, we are considering switching the default backend used by curl (the cli) for the gnutls one, so we can enable http3. Boyuan, can you provide any details on the issues you found? Otherwise I would recommend staying with gnutls for now and so pycurl will soon make use of a http3-enabled libcurl. Cheers, -- Samuel Henrique
Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`
Sebastian Ramacher, le lun. 15 avril 2024 05:41:48 +0200, a ecrit: > On 2024-04-14 14:19:18 +0200, Santiago Vila wrote: > > El 14/4/24 a las 13:25, Sylvestre Ledru escribió: > > > I am sorry but I am not sure to see how it is actionable. > > > > > > Without a test case, i don't think there is much I can do here. > > > > The test case is that nvda2speechd fails to build from source. > > > With rust, cargo, custom build script, there are many things that can go > > > wrong before LLVM. > > > > > > Sebastian, I think it could be move to normal. From LLVM perspective, it > > > isn't serious severity (many programs are built with LLVM 16). > > > > We can release trixie with compilers having bugs, but I don't think it > > would be ok at > > all to release trixie as stable with packages which do not build from > > source, that would > > be against Release Policy. > > > > So, in my opinion, this is still RC, either in the compiler or in the > > package failing > > to build. If solving this in the compiler is too complex, then the bug > > should be reassigned back to src:nvda2speechd. > > Given that nvda2speechd downloads rust and plenty of crates during the > build, it will have to prevent odd interactions with the system provided > LLVM. Let's keep this as RC bug against nvda2speechd. The problem is that bindgen insists on interacting with the system-provided LLVM: https://github.com/rust-lang/rust-bindgen/blob/main/bindgen/lib.rs#L620 It force-loads libclang, and when that's libclang16, we get the bug. For now I "fixed" the bug by dropping the rust/cargo/clang build-deps entirely, and build-dep on libclang 14 rather than 16. I don't know why the issue shows up only when building speech-dispatcher-sys, perhaps that's just because it's the only crate that uses bindgen. Samuel
Bug#632868: base-files: derive PATH in /etc/profile from /etc/login.defs
Hello, Santiago Vila, le lun. 15 avril 2024 13:08:30 +0200, a ecrit: > Can we also drop PATH from /etc/profile in non-Linux systems like hurd-i386? > (I'm Cc:ing Samuel for that). I tried to comment out the PATH definition from /etc/profile on the exodar porterbox, and it seems to be going fine? Samuel
Bug#1060394: network setup for bookworm uses eth0 instead of enX0
(Though of course the patch needs to be applied to a new copy of
40-setup-networking-deb that only the bookworm profile uses, and not the
previous versions of debian)
Samuel
Samuel Thibault, le mar. 09 avril 2024 11:45:10 +0200, a ecrit:
> Indeed, we meet the same issue, and the proposed patch is what we'll be
> using.
>
> Samuel
>
> Valentin Kleibel, le mer. 10 janv. 2024 17:29:01 +0100, a ecrit:
> > The default network interface naming scheme for bookworm don-U's is enX[num]
> > but the network setup script used to fill /etc/network/interfaces still
> > assumes eth0 for the first network interface.
> >
> > I think either the script
> > /usr/share/xen-tools/common/40-setup-networking-deb should be changed or a
> > changed copy should be used for
> > /usr/share/xen-tools/bookworm.d/40-setup-networking instead of the symlink.
> >
> > I've attached a simple patch that i used creating new bookworm domUs.
> >
> > Thanks for your work,
> > Valentin
>
> > --- /usr/share/xen-tools/common/40-setup-networking-deb.orig2024-01-09
> > 18:22:08.130262212 +0100
> > +++ /usr/share/xen-tools/common/40-setup-networking-deb 2024-01-09
> > 18:21:34.908959639 +0100
> > @@ -49,9 +49,9 @@
> > iface lo inet loopback
> >
> > # The primary network interface
> > -auto eth0
> > -iface eth0 inet dhcp
> > -# post-up ethtool -K eth0 tx off
> > +auto enX0
> > +iface enX0 inet dhcp
> > +# post-up ethtool -K enX0 tx off
> >
> > #
> > # The commented out line above will disable TCP checksumming which
> > @@ -105,14 +105,14 @@
> > iface lo inet loopback
> >
> > # The primary network interface
> > -auto eth0
> > -iface eth0 inet static
> > +auto enX0
> > +iface enX0 inet static
> > address ${ip1}
> > ${gway}
> > netmask ${netmask}
> > ${bcast}
> > ${point}
> > - # post-up ethtool -K eth0 tx off
> > + # post-up ethtool -K enX0 tx off
> >
> > #
> > # The commented out line above will disable TCP checksumming which
> > @@ -131,11 +131,11 @@
> > logMessage Adding etho:${interface}
> >
> > cat <>${prefix}/etc/network/interfaces
> > -auto eth0:${interface}
> > -iface eth0:${interface} inet static
> > +auto enX0:${interface}
> > +iface enX0:${interface} inet static
> > address ${value}
> > netmask ${netmask}
> > - # post-up ethtool -K eth0 tx off
> > + # post-up ethtool -K enX0 tx off
> > E_O_STATIC
> > count=`expr $count + 1`
> > interface=`expr $interface + 1`
>
>
> --
> Samuel
> ---
> Pour une évaluation indépendante, transparente et rigoureuse !
> Je soutiens la Commission d'Évaluation de l'Inria.
--
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
Bug#1060394: network setup for bookworm uses eth0 instead of enX0
Hello,
Indeed, we meet the same issue, and the proposed patch is what we'll be
using.
Samuel
Valentin Kleibel, le mer. 10 janv. 2024 17:29:01 +0100, a ecrit:
> The default network interface naming scheme for bookworm don-U's is enX[num]
> but the network setup script used to fill /etc/network/interfaces still
> assumes eth0 for the first network interface.
>
> I think either the script
> /usr/share/xen-tools/common/40-setup-networking-deb should be changed or a
> changed copy should be used for
> /usr/share/xen-tools/bookworm.d/40-setup-networking instead of the symlink.
>
> I've attached a simple patch that i used creating new bookworm domUs.
>
> Thanks for your work,
> Valentin
> --- /usr/share/xen-tools/common/40-setup-networking-deb.orig2024-01-09
> 18:22:08.130262212 +0100
> +++ /usr/share/xen-tools/common/40-setup-networking-deb 2024-01-09
> 18:21:34.908959639 +0100
> @@ -49,9 +49,9 @@
> iface lo inet loopback
>
> # The primary network interface
> -auto eth0
> -iface eth0 inet dhcp
> -# post-up ethtool -K eth0 tx off
> +auto enX0
> +iface enX0 inet dhcp
> +# post-up ethtool -K enX0 tx off
>
> #
> # The commented out line above will disable TCP checksumming which
> @@ -105,14 +105,14 @@
> iface lo inet loopback
>
> # The primary network interface
> -auto eth0
> -iface eth0 inet static
> +auto enX0
> +iface enX0 inet static
> address ${ip1}
> ${gway}
> netmask ${netmask}
> ${bcast}
> ${point}
> - # post-up ethtool -K eth0 tx off
> + # post-up ethtool -K enX0 tx off
>
> #
> # The commented out line above will disable TCP checksumming which
> @@ -131,11 +131,11 @@
> logMessage Adding etho:${interface}
>
> cat <>${prefix}/etc/network/interfaces
> -auto eth0:${interface}
> -iface eth0:${interface} inet static
> +auto enX0:${interface}
> +iface enX0:${interface} inet static
> address ${value}
> netmask ${netmask}
> - # post-up ethtool -K eth0 tx off
> + # post-up ethtool -K enX0 tx off
> E_O_STATIC
> count=`expr $count + 1`
> interface=`expr $interface + 1`
--
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
Bug#1051402: emacspeak fails byte-compile during install or upgrade since emacs 29
Control: tags -1 + pending Hello, Michiel, le ven. 05 avril 2024 21:11:34 +0100, a ecrit: > I believe this specific issue (emacspeak-proced.el:156:4: Error: Misplaced t > or ‘otherwise’ clause) is fixed upstream by this commit: > > https://github.com/tvraman/emacspeak/commit/806c044b08ccf8c53ce744a1578103037c622048 > > Hope this helps in some way, It does fix things up indeed, thanks! Samuel
Bug#1068236: autopkgtest: does not manage to uninstall non-t64 libraries
Package: autopkgtest Severity: normal Hello, The starpu package migration status exposes an interesting issue: https://qa.debian.org/excuses.php?package=starpu The armel and armhf archs get a regression on the eztrace package, for instance on armel: https://ci.debian.net/packages/e/eztrace/testing/armel/44565975/ What happens is that: - the testbed preparation for the first test (command1) installs the non-t64 libraries libevent-core-2.1-7 libevent-pthreads-2.1-7 libopen-trace-format2-10 libopenmpi3 libpmix2 from testing. - Then other tests install other packages from testing. - The last test (command9) is the one that actually tries to install the newer libstarpu-dev library from unstable. autopkgtest first realizes that asking apt to pull only starpu from unstable won't work (since it depends on some other t64 libraries), so it tries again with enabling unstable for all packages: autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from unstable - But apparently apt does not like replacing libevent-core-2.1-7 libevent-pthreads-2.1-7 libopen-trace-format2-10 libopenmpi3 libpmix2 with libevent-core-2.1-7t64 libevent-pthreads-2.1-7t64 libopen-trace-format2-10t64 libopenmpi3t64 libpmix2t64 Then autopkgtest runs apt a last time to get more information: autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt install on test deps directly for further data about failing dependencies in test logs which does happen to find the expected solution, but autopkgtest stops there. Should we perhaps make autopkgtest really try this last attempt? Samuel
Bug#1026877: opari2: please make the build reproducible
James Addison, le dim. 31 mars 2024 23:44:20 +0100, a ecrit: > Source: opari2 > Followup-For: Bug #1026877 > Control: close -1 2.0.7-2 Thanks!
Bug#1068100: armci-mpi: autopkgtest spuriously fails
Samuel Thibault, le sam. 30 mars 2024 16:55:11 +0100, a ecrit:
> I have forwarded a fix to upstream
> https://github.com/pmodels/armci-mpi/pull/47
> which is already merged.
>
> Unless somebody objects, I'll NMU it.
I have uploaded the attached changes to delayed/2.
Samuel
diff -Nru armci-mpi-0.3.1~beta/debian/changelog
armci-mpi-0.3.1~beta/debian/changelog
--- armci-mpi-0.3.1~beta/debian/changelog 2023-03-19 14:08:54.0
+0100
+++ armci-mpi-0.3.1~beta/debian/changelog 2024-03-30 23:17:18.0
+0100
@@ -1,3 +1,12 @@
+armci-mpi (0.3.1~beta-7.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * patches/fix-test.patch: Fix test_mpi_indexed_gets.c test and strengthen
+the others. Closes: #1066227.
+ * patches/ftbfs.patch: Fix build with qa=+bug-implicit-func.
+
+ -- Samuel Thibault Sat, 30 Mar 2024 23:17:18 +0100
+
armci-mpi (0.3.1~beta-7) unstable; urgency=medium
* Team upload.
diff -Nru armci-mpi-0.3.1~beta/debian/patches/fix-test.patch
armci-mpi-0.3.1~beta/debian/patches/fix-test.patch
--- armci-mpi-0.3.1~beta/debian/patches/fix-test.patch 1970-01-01
01:00:00.0 +0100
+++ armci-mpi-0.3.1~beta/debian/patches/fix-test.patch 2024-03-30
23:17:18.0 +0100
@@ -0,0 +1,193 @@
+https://github.com/pmodels/armci-mpi/pull/47
+
+commit 80cc91748392aec9eced295eb531548a565dac0e
+Author: Samuel Thibault
+Date: Sat Mar 30 16:35:11 2024 +0100
+
+tests/mpi/test_mpi_indexed_gets.c: Fix reception buffer initialization
+
+loc_buf was completely uninitialized, while the second and third loop nests
+are checking that the values are 1.0 + rank. With luck it would be zero,
and
+thus the actual - expected > 1e-10 check would pass (since the difference
is
+then negative). With less luck the check would spuriously fail for the part
+that is not overwritten by the MPI_Get.
+
+ Signed-off-by: Samuel Thibault
+
+commit 9c0f6b08ba706a7c2f3e74d325cfd2a010300108
+Author: Samuel Thibault
+Date: Sat Mar 30 16:38:58 2024 +0100
+
+tests/mpi: Fix comparison of floating-double types
+
+In case the actual value is zero and the expected value is positive, the
+check would spuriously succeed.
+
+ Signed-off-by: Samuel Thibault
+
+commit cd001a46801fed9f406ea57238a131b0a0e063fe
+Author: Samuel Thibault
+Date: Sat Mar 30 16:41:58 2024 +0100
+
+tests/mpi/test_mpi_indexed_gets.c: Strengthen test
+
+Now that it is fixed, we can make it actually perform strided accesses.
+
+ Signed-off-by: Samuel Thibault
+
+---
+ tests/mpi/test_mpi_accs.c |2 +-
+ tests/mpi/test_mpi_indexed_accs.c |6 +++---
+ tests/mpi/test_mpi_indexed_gets.c | 12 +++-
+ tests/mpi/test_mpi_indexed_puts_gets.c |6 +++---
+ tests/mpi/test_mpi_subarray_accs.c |6 +++---
+ 5 files changed, 17 insertions(+), 15 deletions(-)
+
+--- a/tests/mpi/test_mpi_indexed_gets.c
b/tests/mpi/test_mpi_indexed_gets.c
+@@ -19,7 +19,7 @@
+
+ #define XDIM 8
+ #define YDIM 1024
+-#define SUB_XDIM 8
++#define SUB_XDIM 4
+ #define SUB_YDIM 256
+
+ int main(int argc, char **argv) {
+@@ -44,8 +44,10 @@ int main(int argc, char **argv) {
+ if (rank == 0)
+ printf("MPI RMA Strided Get Test:\n");
+
+-for (i = 0; i < XDIM*YDIM; i++)
++for (i = 0; i < XDIM*YDIM; i++) {
+ *(win_buf + i) = 1.0 + rank;
++*(loc_buf + i) = 1.0 + rank;
++}
+
+ MPI_Win_create(win_buf, bufsize, 1, MPI_INFO_NULL, MPI_COMM_WORLD,
_win);
+
+@@ -88,7 +90,7 @@ int main(int argc, char **argv) {
+ for (j = 0; j < SUB_YDIM; j++) {
+ const double actual = *(loc_buf + i + j*XDIM);
+ const double expected = (1.0 + peer);
+-if (actual - expected > 1e-10) {
++if (fabs(actual - expected) > 1e-10) {
+ printf("%d: Data validation failed at [%d, %d] expected=%f
actual=%f\n",
+ rank, j, i, expected, actual);
+ errors++;
+@@ -100,7 +102,7 @@ int main(int argc, char **argv) {
+ for (j = 0; j < SUB_YDIM; j++) {
+ const double actual = *(loc_buf + i + j*XDIM);
+ const double expected = 1.0 + rank;
+-if (actual - expected > 1e-10) {
++if (fabs(actual - expected) > 1e-10) {
+ printf("%d: Data validation failed at [%d, %d] expected=%f
actual=%f\n",
+ rank, j, i, expected, actual);
+ errors++;
+@@ -112,7 +114,7 @@ int main(int argc, char **argv) {
+ for (j = SUB_YDIM; j < YDIM; j++) {
+ const double actual = *(loc_buf + i + j*XDIM);
+ const double expected = 1.0 + rank;
+-if (actual - expected > 1e-10) {
++if (fabs(actual - expected) > 1e-10) {
+ printf("%d: Data validation failed at [%d, %d] expected=%f
actual=%f\n",
+ rank, j, i, expected, actual);
+ errors++;
+--- a/tests/mpi/test_mp
Bug#1068100: armci-mpi: autopkgtest spuriously fails
Source: armci-mpi
Version: 0.3.1~beta-7
Severity: serious
Tags: patch upstream fixed-upstream
Forwarded: https://github.com/pmodels/armci-mpi/pull/47
Justification: Prevents mpich migration
Hello,
The test_mpi_indexed_gets test is currently failing spuriously
in debian unstable due to an uninitialized value, e.g.
https://ci.debian.net/packages/a/armci-mpi/testing/amd64/44486187/ ,
preventing the newer mpich version from migrating to unstable.
I have forwarded a fix to upstream
https://github.com/pmodels/armci-mpi/pull/47
which is already merged.
Unless somebody objects, I'll NMU it.
Samuel
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'),
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500,
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500,
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'),
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 6.8.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
commit 80cc91748392aec9eced295eb531548a565dac0e
Author: Samuel Thibault
Date: Sat Mar 30 16:35:11 2024 +0100
tests/mpi/test_mpi_indexed_gets.c: Fix reception buffer initialization
loc_buf was completely uninitialized, while the second and third loop nests
are checking that the values are 1.0 + rank. With luck it would be zero, and
thus the actual - expected > 1e-10 check would pass (since the difference is
then negative). With less luck the check would spuriously fail for the part
that is not overwritten by the MPI_Get.
Signed-off-by: Samuel Thibault
commit 9c0f6b08ba706a7c2f3e74d325cfd2a010300108
Author: Samuel Thibault
Date: Sat Mar 30 16:38:58 2024 +0100
tests/mpi: Fix comparison of floating-double types
In case the actual value is zero and the expected value is positive, the
check would spuriously succeed.
Signed-off-by: Samuel Thibault
commit cd001a46801fed9f406ea57238a131b0a0e063fe
Author: Samuel Thibault
Date: Sat Mar 30 16:41:58 2024 +0100
tests/mpi/test_mpi_indexed_gets.c: Strengthen test
Now that it is fixed, we can make it actually perform strided accesses.
Signed-off-by: Samuel Thibault
diff --git a/tests/mpi/test_mpi_indexed_gets.c
b/tests/mpi/test_mpi_indexed_gets.c
index dc1bd9d..3570492 100644
--- a/tests/mpi/test_mpi_indexed_gets.c
+++ b/tests/mpi/test_mpi_indexed_gets.c
@@ -44,8 +44,10 @@ int main(int argc, char **argv) {
if (rank == 0)
printf("MPI RMA Strided Get Test:\n");
-for (i = 0; i < XDIM*YDIM; i++)
+for (i = 0; i < XDIM*YDIM; i++) {
*(win_buf + i) = 1.0 + rank;
+*(loc_buf + i) = 1.0 + rank;
+}
MPI_Win_create(win_buf, bufsize, 1, MPI_INFO_NULL, MPI_COMM_WORLD,
_win);
diff --git a/tests/mpi/test_mpi_accs.c b/tests/mpi/test_mpi_accs.c
index ee9b0a9..730a632 100644
--- a/tests/mpi/test_mpi_accs.c
+++ b/tests/mpi/test_mpi_accs.c
@@ -55,7 +55,7 @@ int main(int argc, char **argv) {
for (j = 0; j < YDIM; j++) {
const double actual = *(buffer + i + j*XDIM);
const double expected = (1.0 + rank) + (1.0 +
((rank+nranks-1)%nranks)) * (ITERATIONS);
-if (actual - expected > 1e-10) {
+if (fabs(actual - expected) > 1e-10) {
printf("%d: Data validation failed at [%d, %d] expected=%f
actual=%f\n",
rank, j, i, expected, actual);
errors++;
diff --git a/tests/mpi/test_mpi_indexed_accs.c
b/tests/mpi/test_mpi_indexed_accs.c
index 78c06bd..0fc3baa 100644
--- a/tests/mpi/test_mpi_indexed_accs.c
+++ b/tests/mpi/test_mpi_indexed_accs.c
@@ -97,7 +97,7 @@ int main(int argc, char **argv) {
for (j = 0; j < SUB_YDIM; j++) {
const double actual = *(win_buf + i + j*XDIM);
const double expected = (1.0 + rank) + (1.0 +
((rank+nranks-1)%nranks)) * (ITERATIONS);
-if (actual - expected > 1e-10) {
+if (fabs(actual - expected) > 1e-10) {
printf("%d: Data validation failed at [%d, %d] expected=%f
actual=%f\n",
rank, j, i, expected, actual);
errors++;
@@ -109,7 +109,7 @@ int main(int argc, char **argv) {
for (j = 0; j < SUB_YDIM; j++) {
const double actual = *(win_buf + i + j*XDIM);
const double expected = 1.0 + rank;
-if (actual - expected > 1e-10) {
+if (fabs(actual - expected) > 1e-10) {
printf("%d: Data validation failed at [%d, %d] expected=%f
actual
Bug#1066735: mpich: fails to connect processes and report ranks with trivial mpi test
Samuel Thibault, le mar. 26 mars 2024 18:38:22 +0100, a ecrit: > Samuel Thibault, le ven. 15 mars 2024 10:31:54 +0100, a ecrit: > > Lucas Nussbaum, le mer. 13 mars 2024 15:56:40 +0100, a ecrit: > > I'm 0/1 > > I'm 0/1 > > > > and the same with a hosts file containing localhost twice. > > I tried with disabling PMIX (commenting PMIX:= > --with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2), and that fixed it. > > Unless somebody complains, I will NMU that change, to get back mpich > working in unstable. I have uploaded the attached change to DELAYED/2. Samuel diff -Nru mpich-4.2.0/debian/changelog mpich-4.2.0/debian/changelog --- mpich-4.2.0/debian/changelog2024-02-27 09:59:43.0 +0100 +++ mpich-4.2.0/debian/changelog2024-03-26 22:40:26.0 +0100 @@ -1,3 +1,10 @@ +mpich (4.2.0-5.1) unstable; urgency=medium + + * Non-maintainer upload. + * rules: Re-disable pmix: Closes: #1066735 + + -- Samuel Thibault Tue, 26 Mar 2024 22:40:26 +0100 + mpich (4.2.0-5) unstable; urgency=medium * Install mod files in include dir until all deps updated diff -Nru mpich-4.2.0/debian/rules mpich-4.2.0/debian/rules --- mpich-4.2.0/debian/rules2024-02-27 09:59:43.0 +0100 +++ mpich-4.2.0/debian/rules2024-03-26 22:40:26.0 +0100 @@ -54,12 +54,12 @@ PMIX:= ifeq (,$(findstring $(DEB_HOST_ARCH),$(NO_CH4_ARCH))) DEVICE:= --with-device=ch4:ofi - PMIX:= --with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2 + #PMIX:= --with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2 endif ifneq (,$(filter $(DEB_HOST_ARCH),$(UCX_ARCH))) DEVICE:= --with-device=ch4:ucx UCX:= --with-ucx=/usr - PMIX:= --with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2 + #PMIX:= --with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2 endif extra_flags += \
Bug#1066735: mpich: fails to connect processes and report ranks with trivial mpi test
Hello,
Samuel Thibault, le ven. 15 mars 2024 10:31:54 +0100, a ecrit:
> Lucas Nussbaum, le mer. 13 mars 2024 15:56:40 +0100, a ecrit:
> > > [P0T0] Starting EZTrace (pid: 878489)...
> > > [P0T0] MPI mode selected
> > > This program requires 2 MPI processes, aborting...
> > > dir: mpi_ping_trace
> > > /bin/rm: cannot remove 'mpi_ping_trace': Directory not empty
> > > [P0T0] Stopping EZTrace (pid:878489)...
> > > [P0T0] Starting EZTrace (pid: 878488)...
> > > [P0T0] MPI mode selected
> > > This program requires 2 MPI processes, aborting...
> > > [P0T0] Stopping EZTrace (pid:878488)...
> > > [[1;32mOK[0m]
>
> The test does run 2 processes. I tried this:
>
> $ cat test.c
> #include
> #include
> int main(int argc, char *argv[]) {
> int rank, size;
> MPI_Init(, );
> MPI_Comm_rank(MPI_COMM_WORLD, );
> MPI_Comm_size(MPI_COMM_WORLD, );
> printf("I'm %d/%d\n", rank, size);
> return 0;
> }
>
> And it reports:
>
> $ mpirun -np 2 ./test
> Authorization required, but no authorization protocol specified
>
> Authorization required, but no authorization protocol specified
>
> Authorization required, but no authorization protocol specified
>
> Authorization required, but no authorization protocol specified
>
> I'm 0/1
> I'm 0/1
>
> and the same with a hosts file containing localhost twice.
I tried with disabling PMIX (commenting PMIX:=
--with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2), and that fixed it.
Unless somebody complains, I will NMU that change, to get back mpich
working in unstable.
Samuel
Bug#1067468: these tests also fail with openmpi on amd64 and ppc64el
Hello, Matthias Klose, le ven. 22 mars 2024 03:29:04 +0100, a ecrit: > On 22.03.24 01:22, Samuel Thibault wrote: > > Matthias Klose, le ven. 22 mars 2024 01:11:09 +0100, a ecrit: > > > these tests also fail with openmpi on amd64 and ppc64el > > > > ? I can't reproduce this. > > sorry, only saw that for an Ubuntu build: > https://launchpad.net/ubuntu/+source/eztrace/2.1-7ubuntu3 Ok. These failures look extremely odd. > Running mpirun.openmpi --oversubscribe -np 2 > /<>/build-openmpi/src/eztrace -p -t openmpi ./mpi_ping 2: Eztrace test Mode 2: Eztrace test Mode 2: Abort(33616) on node 0: Fatal error in internal_Comm_size: Invalid communicator, error stack: 2: internal_Comm_size(30769): MPI_Comm_size(comm=0xb6061990, size=0xb86caa54) failed 2: internal_Comm_size(30723): Invalid communicator The program has basically only called int comm_size = -1; MPI_Init(, ); MPI_Comm_size(MPI_COMM_WORLD, _size); Which is essentially a smoketest for a working mpi implementation. And these error messages are coming from mpich, not from openmpi! I'm wondering if ubuntu is perhaps mixing libmpi from mpich and from openmpi? > but please could you run all three testsuites, and only then fail the build? Done so in the git tree. I have also added a smoketest for working MPI implementations (without any use of eztrace). Samuel
Bug#1067468: these tests also fail with openmpi on amd64 and ppc64el
Matthias Klose, le ven. 22 mars 2024 01:11:09 +0100, a ecrit: > these tests also fail with openmpi on amd64 and ppc64el ? I can't reproduce this. Samuel
Bug#1066490: motif: FTBFS: XpmCrBufFrI.c:155:5: error: implicit declaration of function ‘strcpy’ [-Werror=implicit-function-declaration]
Hello,
Lucas Nussbaum, le mer. 13 mars 2024 12:53:39 +0100, a ecrit:
> > XpmCrBufFrI.c:155:5: error: implicit declaration of function ‘strcpy’
> > [-Werror=implicit-function-declaration]
> > 155 | strcpy(ptr, buf);
> > | ^~
Given the severity, the importance of the package, the time_t rebuild
issues, and the simplicity of a fix, I have uploaded the attached
changes to DELAYED/0.
Samuel
diff -Nru motif-2.3.8/debian/changelog motif-2.3.8/debian/changelog
--- motif-2.3.8/debian/changelog2020-07-02 11:30:19.0 +0200
+++ motif-2.3.8/debian/changelog2024-03-21 23:42:09.0 +0100
@@ -1,3 +1,10 @@
+motif (2.3.8-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * patches/implicit: Fix build with qa=+bug-implicit-func (Closes: #1066490)
+
+ -- Samuel Thibault Thu, 21 Mar 2024 23:42:09 +0100
+
motif (2.3.8-3) unstable; urgency=medium
[ Graham Inggs ]
diff -Nru motif-2.3.8/debian/patches/implicit
motif-2.3.8/debian/patches/implicit
--- motif-2.3.8/debian/patches/implicit 1970-01-01 01:00:00.0 +0100
+++ motif-2.3.8/debian/patches/implicit 2024-03-21 23:38:08.0 +0100
@@ -0,0 +1,26 @@
+---
+ demos/unsupported/xmform/xmform.c |1 +
+ lib/Xm/XpmI.h |2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+--- a/lib/Xm/XpmI.h
b/lib/Xm/XpmI.h
+@@ -129,7 +129,7 @@ extern "C" {
+ extern FILE *popen();
+ #endif
+
+-#if defined(SYSV) || defined(SVR4) || defined(VMS) || defined(WIN32) ||
defined (_SVID_SOURCE)
++#if defined(SYSV) || defined(SVR4) || defined(VMS) || defined(WIN32) ||
defined (_SVID_SOURCE) || defined (_POSIX_SOURCE)
+ #include
+
+ #ifndef index
+--- a/demos/unsupported/xmform/xmform.c
b/demos/unsupported/xmform/xmform.c
+@@ -50,6 +50,7 @@ xmform*topShadowColor: white
+ xmform*bottomShadowColor:black
+ ***---*/
+
++#include
+ #include
+ #include
+ #include
diff -Nru motif-2.3.8/debian/patches/series motif-2.3.8/debian/patches/series
--- motif-2.3.8/debian/patches/series 2020-07-02 10:59:29.0 +0200
+++ motif-2.3.8/debian/patches/series 2024-03-21 23:37:12.0 +0100
@@ -17,3 +17,4 @@
pass-hardening-flags.patch
revert-fix-1617.patch
cross.patch
+implicit
Bug#1067467: eztrace fails tests during the build on almost all architectures
Control: block -1 by 1066735 Ok, it's the third one, I'll just add a block instead of merging again. Samuel Matthias Klose, le jeu. 21 mars 2024 23:23:21 +0100, a ecrit: > Package: src:eztrace > Version: 2.1-7 > Severity: serious > Tags: sid trixie ftbfs > > eztrace fails tests during the build on almost all architectures, e.g. > > > 90% tests passed, 2 tests failed out of 21 > > Total Test time (real) = 42.52 sec > > The following tests FAILED: > 2 - mpi_tests (Failed) > 9 - mpi_tests (Failed) > Errors while running CTest > make[2]: *** [Makefile:74: test] Error 8 > make[2]: Leaving directory '/<>/build-mpich'
Bug#1066844: at-spi2-core: needs re-bootstrapping on armel, armhf for 64-bit time_t transition
Hello, The rebootstrap happened, I have reverted the temporary changes in the tree, that'll get uploaded whenever we make an upload. Samuel
Bug#1065787: 64-bit time_t transition: cargo needs manual intervention
On Sat, 16 Mar 2024 at 14:29, Simon McVittie wrote: > On Thu, 14 Mar 2024 at 22:03:57 -0700, Otto Kekäläinen wrote: > > For example curl isn't building on armel/armhf now and numerous packages > > that > > depend of curl are not building on armel/armhf. > > I believe a maintainer upload or NMU of #1066981 and #1066982 would > now be enough to unblock curl, which would hopefully unblock a lot of > the C/C++ ecosystem (in particular fixing the unsatisfiable dependency > libdebuginfod1t64 -> libcurl3t64-gnutls on armel/armhf, which would allow > gdb to be installed), while also making life easier for the people trying > to re-bootstrap cargo. I've uploaded curl 8.6.0-4 with the patches from #1066981 and #1066982, thank you for those, Simon! Cheers, -- Samuel Henrique
Bug#1066932: gcc-14: Please enable m2 on hurd-any
Source: gcc-14 Version: 14-20240303-1 Severity: normal Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hello, Now that upstream has fixed the m2 portability (available in the 20240303 snapshot), could you enable m2 on hurd-any, as the attached patch does? Thanks, Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. diff --git a/debian/rules.defs b/debian/rules.defs index 928d4e56..44f3f3a0 100644 --- a/debian/rules.defs +++ b/debian/rules.defs @@ -1195,7 +1195,7 @@ ifneq ($(with_base_only),yes) endif endif m2_no_cpus = loong64 powerpc ppc64 sh4 -m2_no_systems = gnu +m2_no_systems = ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus))) with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU) endif
Bug#1066735: mpich: fails to connect processes and report ranks with trivial mpi test
Control: notfound -1 4.1.2-3 Samuel Thibault, le ven. 15 mars 2024 10:31:54 +0100, a ecrit: > $ mpirun -np 2 ./test > Authorization required, but no authorization protocol specified > > Authorization required, but no authorization protocol specified > > Authorization required, but no authorization protocol specified > > Authorization required, but no authorization protocol specified > > I'm 0/1 > I'm 0/1 Note: this is new with mpich 4.2.0, 4.1.2-3 is fine. Samuel
Bug#1066735: mpich: fails to connect processes and report ranks with trivial mpi test
Control: reassign -1 mpich
Control: retitle -1 mpich: fails to connect processes and report ranks
Control: affects -1 + eztrace
Hello,
Lucas Nussbaum, le mer. 13 mars 2024 15:56:40 +0100, a ecrit:
> > [P0T0] Starting EZTrace (pid: 878489)...
> > [P0T0] MPI mode selected
> > This program requires 2 MPI processes, aborting...
> > dir: mpi_ping_trace
> > /bin/rm: cannot remove 'mpi_ping_trace': Directory not empty
> > [P0T0] Stopping EZTrace (pid:878489)...
> > [P0T0] Starting EZTrace (pid: 878488)...
> > [P0T0] MPI mode selected
> > This program requires 2 MPI processes, aborting...
> > [P0T0] Stopping EZTrace (pid:878488)...
> > [[1;32mOK[0m]
The test does run 2 processes. I tried this:
$ cat test.c
#include
#include
int main(int argc, char *argv[]) {
int rank, size;
MPI_Init(, );
MPI_Comm_rank(MPI_COMM_WORLD, );
MPI_Comm_size(MPI_COMM_WORLD, );
printf("I'm %d/%d\n", rank, size);
return 0;
}
And it reports:
$ mpirun -np 2 ./test
Authorization required, but no authorization protocol specified
Authorization required, but no authorization protocol specified
Authorization required, but no authorization protocol specified
Authorization required, but no authorization protocol specified
I'm 0/1
I'm 0/1
and the same with a hosts file containing localhost twice.
Samuel
Bug#1065570: Interface border is replaced by ascii chars
Samuel Thibault, le sam. 09 mars 2024 22:42:36 +0100, a ecrit: > Samuel Thibault, le sam. 09 mars 2024 22:02:46 +0100, a ecrit: > > x11r, le jeu. 07 mars 2024 02:13:22 +, a ecrit: > > > That's all the relevant information I can think of for now. Maybe see if > > > your KVM is able to reproduce using the pxelinux.cfg above or removing > > > the "VGA=788" parameter from the kernel command line? > > > > Ahah! That's indeed the trigger. I also have to pass -vga vmware to > > qemu, so the linux console stays in pure text mode, no fbcon. > > > > As I was guessing, it's the console-setup configuration that mangles > > everything, we'll be able to have a look. > > > > I couldn't reproduce it with all other parameters being the default, > > I'll dig more. > > d-i debian-installer/locale string en_US > > This is the eventual culprit, it should be > > d-i debian-installer/locale string en_US.UTF-8 I'm fixing the d-i manual. Samuel
Bug#1065570: Interface border is replaced by ascii chars
Samuel Thibault, le sam. 09 mars 2024 22:02:46 +0100, a ecrit: > x11r, le jeu. 07 mars 2024 02:13:22 +, a ecrit: > > That's all the relevant information I can think of for now. Maybe see if > > your KVM is able to reproduce using the pxelinux.cfg above or removing the > > "VGA=788" parameter from the kernel command line? > > Ahah! That's indeed the trigger. I also have to pass -vga vmware to > qemu, so the linux console stays in pure text mode, no fbcon. > > As I was guessing, it's the console-setup configuration that mangles > everything, we'll be able to have a look. > > I couldn't reproduce it with all other parameters being the default, > I'll dig more. d-i debian-installer/locale string en_US This is the eventual culprit, it should be d-i debian-installer/locale string en_US.UTF-8 Do we actually support non-UTF-8 locales, actually? Samuel
Bug#1065561: console-setup: typos in documentation
Control: tags -1 + pending Applied, thanks!
Bug#1065570: Interface border is replaced by ascii chars
Control: reassign -1 console-setup Control: tags -1 + d-i Hello, x11r, le jeu. 07 mars 2024 02:13:22 +, a ecrit: > That's all the relevant information I can think of for now. Maybe see if your > KVM is able to reproduce using the pxelinux.cfg above or removing the > "VGA=788" parameter from the kernel command line? Ahah! That's indeed the trigger. I also have to pass -vga vmware to qemu, so the linux console stays in pure text mode, no fbcon. As I was guessing, it's the console-setup configuration that mangles everything, we'll be able to have a look. I couldn't reproduce it with all other parameters being the default, I'll dig more. Samuel
Bug#1065666: mesa: Upgrading to mesa from testing breaks compiz
Source: mesa Version: 23.3.5-1 Severity: serious Tags: a11y Justification: breaks compiz Hello, When upgrading mesa to the version from testing, compiz does not start any more. I tried both upgrading only mesa (and deps), as well as mesa and the rest of the system, with the same result. compiz gets stuck here: #0 0x7f15fadefa80 in __GI___poll (fds=fds@entry=0x7ffc95974370, nfds=nfds@entry=1, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f15facd94d3 in poll (__timeout=-1, __nfds=1, __fds=0x7ffc95974370) at /usr/include/x86_64-linux-gnu/bits/poll2.h:47 #2 read_block (len=8, buf=0x56080e7564e0, fd=4) at ../../src/xcb_in.c:394 #3 _xcb_in_read_block (c=c@entry=0x56080e75ebb0, buf=0x56080e7564e0, len=len@entry=8) at ../../src/xcb_in.c:1087 #4 0x7f15facd6b56 in read_setup (c=0x56080e75ebb0) at ../../src/xcb_conn.c:180 #5 xcb_connect_to_fd (fd=fd@entry=4, auth_info=auth_info@entry=0x7ffc959744b0) at ../../src/xcb_conn.c:384 #6 0x7f15facdb192 in xcb_connect_to_display_with_auth_info (displayname=displayname@entry=0x0, auth=auth@entry=0x0, screenp=screenp@entry=0x7ffc959745ac) at ../../src/xcb_util.c:536 #7 0x7f15facdb30a in xcb_connect (displayname=displayname@entry=0x0, screenp=screenp@entry=0x7ffc959745ac) at ../../src/xcb_util.c:493 #8 0x7f15f83081cd in device_select_find_xcb_pci_default (devices=devices@entry=0x56080e7564c0, device_count=device_count@entry=1) at ../src/vulkan/device-select-layer/device_select_x11.c:72 #9 0x7f15f8307cfb in get_default_device (expose_only_one_dev=, pPhysicalDevices=, physical_device_count=1, selection=, info=) at ../src/vulkan/device-select-layer/device_select_layer.c:498 #10 device_select_EnumeratePhysicalDevices (instance=, pPhysicalDeviceCount=0x7ffc95974740, pPhysicalDevices=0x7ffc95974760) at ../src/vulkan/device-select-layer/device_select_layer.c:594 #11 0x7f15f8350a9c in vkEnumeratePhysicalDevices () from /lib/x86_64-linux-gnu/libvulkan.so.1 #12 0x7f15f64aa37e in choose_pdev (dev_minor=-1, dev_major=-1, screen=0x56080e732cc0) at ../src/gallium/drivers/zink/zink_screen.c:1637 #13 zink_internal_create_screen (config=, dev_major=dev_major@entry=-1, dev_minor=dev_minor@entry=-1) at ../src/gallium/drivers/zink/zink_screen.c:3210 #14 0x7f15f64ab73e in zink_create_screen (winsys=, config=) at ../src/gallium/drivers/zink/zink_screen.c:3557 #15 0x7f15f611a2d5 in pipe_loader_sw_create_screen (dev=, config=, sw_vk=) at ../src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c:426 #16 0x7f15f611a218 in pipe_loader_create_screen_vk (dev=0x56080e72ce20, sw_vk=sw_vk@entry=false) at ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:184 #17 0x7f15f611a24b in pipe_loader_create_screen (dev=) at ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:190 #18 0x7f15f5ab6c2e in kopper_init_screen (screen=0x56080e729360) at ../src/gallium/frontends/dri/kopper.c:134 #19 0x7f15f5abb6dc in driCreateNewScreen2 (scrn=0, fd=-1, loader_extensions=0x7f15fa8e47e0 , driver_extensions=, driver_configs=0x7ffc95975370, data=0x56080e696910) at ../src/gallium/frontends/dri/dri_util.c:139 #20 0x7f15fa8a3523 in driswCreateScreenDriver (screen=0, priv=0x56080e694430, driver=0x7f15fa8cc31b "zink") at ../src/glx/drisw_glx.c:979 #21 0x7f15fa8a8401 in AllocAndFetchScreenConfigs (dpy=dpy@entry=0x56080e3c0270, priv=priv@entry=0x56080e694430, zink=zink@entry=1) at ../src/glx/glxext.c:798 #22 0x7f15fa8a9385 in __glXInitialize (dpy=dpy@entry=0x56080e3c0270) at ../src/glx/glxext.c:928 #23 0x7f15fa8a61d6 in GetGLXPrivScreenConfig (ppsc=, ppriv=, scrn=0, dpy=0x56080e3c0270) at ../src/glx/glxcmds.c:147 #24 glXGetConfig (dpy=0x56080e3c0270, vis=0x56080e676820, attribute=1, value_return=0x7ffc959754ec) at ../src/glx/glxcmds.c:722 #25 0x56080c4764e2 in addScreen (display=display@entry=0x56080e3beef0, screenNum=screenNum@entry=0, wmSnSelectionWindow=wmSnSelectionWindow@entry=6291457, wmSnAtom=wmSnAtom@entry=436, wmSnTimestamp=wmSnTimestamp@entry=244386) at ./src/screen.c:1984 #26 0x56080c471407 in addDisplay (name=name@entry=0x0) at ./src/display.c:2755 #27 0x56080c46b8e2 in main (argc=, argv=0x7ffc95976278) at ./src/main.c:519 (gdb) info thread Id Target Id Frame * 1Thread 0x7f15fac147c0 (LWP 1034) "compiz" 0x7f15fadefa80 in __GI___poll (fds=fds@entry=0x7ffc95974370, nfds=nfds@entry=1, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 (I'll bounce to this bts the original report from a compiz user) Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'),
Bug#1065570: Interface border is replaced by ascii chars
Hello, x11r, le mer. 06 mars 2024 23:29:24 +, a ecrit: > The mangling does not happen immediately. It happens after the "Installing > the base system" step (not sure what the step after that is supposed to be). > Here's a pastebin of the preseed.cfg: https://pastebin.com/K7vwkpMu I still cannot reproduce with: mkdir tmp cd tmp wget https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/netboot.tar.gz tar xf netboot.tar.gz wget -O preseed.cfg https://pastebin.com/raw/K7vwkpMu dd < /dev/zero > disk.img bs=1M count=1 seek=1 kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive file=disk.img,cache=unsafe -m 1G and appending ip=dhcp auto=enable language=en country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" url=tftp://10.0.2.2/preseed.cfg on the boot kernel command line. It does show up fine up to the reboot step. Any idea what is different with your case? (except the virtualization software) Samuel
Bug#1065570: Interface border is replaced by ascii chars
Hello, x11r, le mer. 06 mars 2024 22:39:23 +, a ecrit: > The machine is PXE booted with the kernel parameters: > initrd=debian-installer/amd64/initrd.gz ip=dhcp auto=enable language=en > country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" > url=tftp://10.0.0.1/preseed.cfg > > Console is accessed over VGA. VMSVGA for the VirtualBox tests we've ran and a > VGA KVM for the tests on bare metal. I still cannot reproduce with unpacking the tarball and running kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive -m 1G and passing the kernel parameters. Does the mangling happen right from the first screen, or after some steps? It could be useful to share your preseed.cfg (take care of removing any hardcoded password). Samuel
Bug#1065570: ***UNCHECKED*** Re: Bug#1065570: Interface border is replaced by ascii chars
Hello, Please re-send your mail unencrypted, so everybody can read the information. Samuel
Bug#1065570: Interface border is replaced by ascii chars
x11r, le mer. 06 mars 2024 18:59:50 +, a ecrit: > I've been working with a small team at my college trying to develop a tool to > automate PXE booting and installation. We have targeted Debian as the first > OS we want to get working over PXE boot. On every test we've ran of the > Debian installation process, there's a visual bug that occurs late in the > installation process. Effectively, the border of the progress interface turns > into Çâö repeatedly. You can see an image of it in the issue here > https://github.com/xeluior/genisys/issues/82 That looks like an utf-8 encoding issue. Please tell us exactly how you boot it (kernel parameters and how you access the console). Samuel
Bug#1065456: python3.11: Please don't enable dtrace on hurd
Package: python3.11 Version: 3.11.8-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hello, python3.11 currently fails to build on hurd-any because debian/rules enables dtrace, which is not available on hurd-any. Could you apply the attached patch that fixes this, on python3.11 as well as on python3.12? Thanks, Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3.11 depends on: ii libpython3.11-stdlib 3.11.8-1 ii media-types 10.1.0 ii mime-support 3.66 ii python3.11-minimal3.11.8-1 Versions of packages python3.11 recommends: ii ca-certificates 20240203 Versions of packages python3.11 suggests: ii binutils 2.42-3 pn python3.11-doc ii python3.11-venv 3.11.8-1 -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. --- debian/rules.orig 2024-03-03 10:23:40.0 +0100 +++ debian/rules2024-03-04 23:54:06.808627222 +0100 @@ -441,7 +441,6 @@ --with-computed-gotos \ --without-ensurepip \ --with-system-expat \ - --with-dtrace \ --with-ssl-default-suites=openssl \ --with-wheel-pkg-dir=/usr/share/python-wheels/ \ --with-ssl-default-suites=openssl \ @@ -453,6 +452,10 @@ common_configure_args += --with-system-ffi endif +ifeq (,$(filter $(DEB_HOST_ARCH_OS), hurd)) + common_configure_args += --with-dtrace +endif + ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) common_configure_args += --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) common_configure_args += --with-build-python
Bug#1065081: [Tts-project] Bug#1065081: Doesn't include the systemd unit needed for socket activation
Hello,
Sebastien Bacher, le jeu. 29 févr. 2024 15:49:03 +0100, a ecrit:
> While rebasing the Ubuntu package on the new Debian version I noticed that
> the .install doesn't include the new systemd socket activation units (which
> is needed for tts in the firefox snap for example). THe attached patch fixes
> the issue, I've also bumped the compat level to 13 which default to
> --fail-missing and would catch such errors
Indeed, thanks!
Samuel
> diff -Nru speech-dispatcher-0.12.0~rc2/debian/changelog
> speech-dispatcher-0.12.0~rc2/debian/changelog
> --- speech-dispatcher-0.12.0~rc2/debian/changelog 2024-02-22
> 20:26:39.0 +0100
> +++ speech-dispatcher-0.12.0~rc2/debian/changelog 2024-02-29
> 14:50:31.0 +0100
> @@ -1,3 +1,13 @@
> +speech-dispatcher (0.12.0~rc2-2) UNRELEASED; urgency=medium
> +
> + * debian/control:
> +- update to compat 13 which default to dh_missing --fail-missing
> + * debian/rules, debian/speech-dispatcher.install:
> +- include the usr/lib/systemd/user directory which has the new
> + socket activation entry
> +
> + -- Sebastien Bacher Thu, 29 Feb 2024 14:50:31 +0100
> +
> speech-dispatcher (0.12.0~rc2-1) experimental; urgency=medium
>
>* New upstream RC release
> diff -Nru speech-dispatcher-0.12.0~rc2/debian/control
> speech-dispatcher-0.12.0~rc2/debian/control
> --- speech-dispatcher-0.12.0~rc2/debian/control 2024-02-22
> 20:20:46.0 +0100
> +++ speech-dispatcher-0.12.0~rc2/debian/control 2024-02-29
> 14:50:31.0 +0100
> @@ -5,7 +5,7 @@
> Uploaders:
> Paul Gevers , Samuel Thibault
> Build-Depends:
> - debhelper-compat (= 12), dh-exec, dh-sequence-python3,
> + debhelper-compat (= 13), dh-exec, dh-sequence-python3,
> automake, libtool,
> python3:any, python3-xdg,
> flite1-dev (>= 1.4), flite,
> diff -Nru speech-dispatcher-0.12.0~rc2/debian/rules
> speech-dispatcher-0.12.0~rc2/debian/rules
> --- speech-dispatcher-0.12.0~rc2/debian/rules 2024-02-22 20:20:46.0
> +0100
> +++ speech-dispatcher-0.12.0~rc2/debian/rules 2024-02-29 14:50:31.0
> +0100
> @@ -4,6 +4,7 @@
> include /usr/share/dpkg/pkg-info.mk
>
> export deb_systemdsystemunitdir = $(shell pkgconf
> --variable=systemdsystemunitdir systemd | sed s,^/,,)
> +export deb_systemduserunitdir = $(shell pkgconf
> --variable=systemduserunitdir systemd | sed s,^/,,)
>
> # NAS is in universe in Ubuntu
> ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
> diff -Nru speech-dispatcher-0.12.0~rc2/debian/speech-dispatcher.install
> speech-dispatcher-0.12.0~rc2/debian/speech-dispatcher.install
> --- speech-dispatcher-0.12.0~rc2/debian/speech-dispatcher.install
> 2024-02-22 20:26:39.0 +0100
> +++ speech-dispatcher-0.12.0~rc2/debian/speech-dispatcher.install
> 2024-02-29 14:50:31.0 +0100
> @@ -10,5 +10,7 @@
> usr/share/speech-dispatcher
> etc/speech-dispatcher
> [linux-any] ${deb_systemdsystemunitdir}/speech-dispatcherd.service
> +[linux-any] ${deb_systemduserunitdir}/speech-dispatcher.service
> +[linux-any] ${deb_systemduserunitdir}/speech-dispatcher.socket
> usr/share/man/man1/speech-dispatcher.1
> usr/share/man/man1/spd-say.1
> ___
> Tts-project mailing list
> tts-proj...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/tts-project
--
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
Bug#1065258: 6 packages from starpu-contrib have an undeclared file conflict
Andreas Beckmann, le dim. 03 mars 2024 12:25:23 +0100, a ecrit: > I only checked one, but it's probably the same for all of them. The > Breaks+Replaces are not correct, they miss the "contrib" part: > > Package: libstarpu-contribrm-1.4-1t64 > Source: starpu-contrib > Version: 1.4.3+dfsg-4 > Installed-Size: 92 > Maintainer: Samuel Thibault > Architecture: amd64 > Replaces: libstarpurm-1.4-1 > ^ > Provides: libstarpu-anyrm-1.4-1, libstarpu-contribrm-1.4-1 (= 1.4.3+dfsg-4) > Depends: libc6 (>= 2.34), libhwloc15 (>= 2.10.0), libstarpu-contrib-1.4-4t64 > (>= 1.4.3+dfsg) > Conflicts: libstarpurm-1.4-1t64 > Breaks: libstarpurm-1.4-1 (<< 1.4.3+dfsg-4) > ^ Ah, indeed, those need to be sed-ed too. > And probably you should add a Conflicts: libstarpurm-1.4-1, too, > otherwise pre-t64 libstarpurm-1.4-1 and post-t64 libstarpu-contribrm-1.4-1t64 > will be co-installable, resulting in another potential file conflict. Indeed. Thanks for checking, Samuel
Bug#1065316: libatspi2.0-dev 2.51.90-1 no longer multi-arch installable due to dependencies
Hello, Simon McVittie, le dim. 03 mars 2024 00:43:12 +, a ecrit: > This was an unintended regression caused by changes made in > gobject-introspection, ironically to make multiarch co-installability and > cross-compilation of GObject-Introspection data possible. Heh :) > I am sorry to have inconvenienced you No problem, thanks for the quick feedback! > Samuel or other AT-SPI maintainers, if you want to avoid this unwanted > dependency while also bringing libatspi2.0-dev one step closer to being > cross-compilable itself, please consider replacing the build-dependency on > libgirepository1.0-dev with the canonicalized package names corresponding > to the GIR modules required by the upstream source, which according to > the build log means this: Oh, indeed. This does look right and produces correct binaries, I'll upload that, thanks! Samuel
Bug#1065316: libatspi2.0-dev 2.51.90-1 no longer multi-arch installable due to dependencies
Hello, Christian Klein, le sam. 02 mars 2024 16:33:15 +0100, a ecrit: > libatspi2.0-dev is no longer muti-arch installable. > It now has a dependency on libgirepository1.0-dev, which isn't multi-arch. > 2.50.0-1 didn't have that dependency > > Looking at the changelog, I don't see why the additional dependency is > necessary. This is coming from gir:Depends: ./debian/libatspi2.0-dev.substvars:gir:Depends=gir1.2-atspi-2.0 (= 2.51.90-1), gir1.2-dbus-1.0-dev, gir1.2-gobject-2.0-dev, libgirepository1.0-dev I don't know the ins and outs why this comes like this, thus asking for help on this. > This breaks libgtk-3-dev multiarch install, since libgtk-3-dev depends on > libatspi2.0-dev via libatk-bridge2.0-dev. > > Even worse, for i386, this now pulls in ~250MB additional packages, because > libgirepository1.0-dev needs gobject-introspection:i386, which pulls in > gcc-i686-linux-gnu. Samuel
Bug#1065308: RM: libtirpc-common [all] -- ROP; decruft for debootstrap installability
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: libti...@packages.debian.org Control: affects -1 + src:libtirpc User: ftp.debian@packages.debian.org Usertags: remove Hello, Sorry I wasn't sure how to specify it exactly, but basically, could you please remove libtirpc-common_1.3.4+ds-1 from unstable for arch:all ? (now that libtirpc 1.3.4+ds-1.1 was built for all archs) Currently debootstrap fails to create a chroot for various reasons, one of which being that we currently have both libtirpc-common_1.3.4+ds-1 and libtirpc-common_1.3.4+ds-1.1 in unstable, and debootstrap isn't smart enough to determine that it's the latter that it should install, since libtirpc3t64_1.3.4+ds-1.1 depends on that one. Unfortunately debootstrap ends up choosing to install libtirpc-common_1.3.4+ds-1, and when libtirpc3t64_1.3.4+ds-1.1 is being configured we end up with dpkg: dependency problems prevent configuration of libtirpc3t64:hurd-i386: libtirpc3t64:hurd-i386 depends on libtirpc-common (>= 1.3.4+ds-1.1); however: Version of libtirpc-common on system is 1.3.4+ds-1. (here on hurd-i386, but other archs will have the same issue) Samuel
Bug#1064673: pocketsphinx-python: FTBFS: ImportError: /usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.cpython-311-x86_64-linux-gnu.so: undefined symbol: SWIG_Python_str_AsChar
control: reassign -1 python3-sphinxbase control: affects -1 pocketsphinx-python Lucas Nussbaum via Pkg-a11y-devel, le dim. 25 févr. 2024 20:38:23 +0100, a ecrit: > > File "/usr/lib/python3.12/unittest/loader.py", line 137, in > > loadTestsFromName > > module = __import__(module_name) > > ^^^ > > File "/<>/tests/test_jsgf.py", line 32, in > > from pocketsphinx import Pocketsphinx, Jsgf > > File "/<>/pocketsphinx/__init__.py", line 35, in > > from sphinxbase.sphinxbase import * > > File "/usr/lib/python3/dist-packages/sphinxbase/sphinxbase.py", line 24, > > in > > from . import _sphinxbase > > ImportError: > > /usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.cpython-312-x86_64-linux-gnu.so: > > undefined symbol: SWIG_Python_str_AsChar More simply, $ python3 -c 'from sphinxbase import sphinxbase' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/sphinxbase/sphinxbase.py", line 24, in from . import _sphinxbase ImportError: /usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.cpython-311-x86_64-linux-gnu.so: undefined symbol: SWIG_Python_str_AsChar and indeed, in swig's ./CHANGES.current I can see 2023-12-20: wsfulton #2190 Replace SWIG_Python_str_AsChar with SWIG_PyUnicode_AsUTF8AndSize. So this needs fixing (just rebuilding sphinxbase doesn't work). I can see in https://codesearch.debian.net/search?q=SWIG_Python_str_AsChar=1 that a lot of packages might be affected by this incompatibility... Samuel
Bug#1064974: alsa-lib: Missing libasound2t64 / libasound2-udeb relation
Source: alsa-lib Version: 1.2.10-3.1 Severity: serious Tags: d-i a11y Justification: makes brltty FTBFS User: debian-...@lists.debian.org Usertags: time-t Hello, The t64 change apparently missed adding a relation between the libasound2t64 deb and the libasound2-udeb udeb libraries, to that brltty now ftbfs when checking that brltty-udeb only depends on libraries inside d-i: https://salsa.debian.org/a11y-team/brltty/-/jobs/5377227 I guess --add-udeb=libasound2-udeb needs to be added to the dh_makeshlibs invocation for libasound2t64. Probably other packages producing udeb libraries are affected by the same kind of issue. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1063524: brltty: move aliased files to /usr (DEP17)
Helmut Grohne, le dim. 18 févr. 2024 07:45:17 +0100, a ecrit: > > > diff --minimal -Nru brltty-6.6/debian/brltty-udeb.dirs > > > brltty-6.6/debian/brltty-udeb.dirs > > > --- brltty-6.6/debian/brltty-udeb.dirs2021-01-28 17:18:34.0 > > > +0100 > > > +++ brltty-6.6/debian/brltty-udeb.dirs2024-02-08 17:59:12.0 > > > +0100 > > > @@ -1,7 +1,7 @@ > > > -lib/debian-installer.d > > > -lib/debian-installer-startup.d > > > +usr/lib/debian-installer.d > > > +usr/lib/debian-installer-startup.d > > > > These are not currently read by the debian installer, so we mustn't move > > these files for now. > > I have moved such files elsewhere, so if this really causes problems > still, I'd like to learn soon and handle it. I have now tested it completely, it seems to be going fine indeed. Samuel
Bug#1063524: brltty: move aliased files to /usr (DEP17)
Helmut Grohne, le dim. 18 févr. 2024 07:45:17 +0100, a ecrit: > > > diff --minimal -Nru brltty-6.6/debian/brltty-udeb.dirs > > > brltty-6.6/debian/brltty-udeb.dirs > > > --- brltty-6.6/debian/brltty-udeb.dirs2021-01-28 17:18:34.0 > > > +0100 > > > +++ brltty-6.6/debian/brltty-udeb.dirs2024-02-08 17:59:12.0 > > > +0100 > > > @@ -1,7 +1,7 @@ > > > -lib/debian-installer.d > > > -lib/debian-installer-startup.d > > > +usr/lib/debian-installer.d > > > +usr/lib/debian-installer-startup.d > > > > These are not currently read by the debian installer, so we mustn't move > > these files for now. > > Keep in mind that the installer has been /usr-merged. Oh, it has? I didn't know that. Samuel
Bug#1063524: brltty: move aliased files to /usr (DEP17)
Hello, Helmut Grohne, le ven. 09 févr. 2024 07:25:07 +0100, a ecrit: > If you wish to continue backporting, you may defer applying this patch > or add a manual dh_movetousr call before dh_installdeb. Yes, we very often backport brltty, so I'll follow that road for now. I'll upload a patched package to experimental for users to check. > diff --minimal -Nru brltty-6.6/debian/brltty-udeb.dirs > brltty-6.6/debian/brltty-udeb.dirs > --- brltty-6.6/debian/brltty-udeb.dirs2021-01-28 17:18:34.0 > +0100 > +++ brltty-6.6/debian/brltty-udeb.dirs2024-02-08 17:59:12.0 > +0100 > @@ -1,7 +1,7 @@ > -lib/debian-installer.d > -lib/debian-installer-startup.d > +usr/lib/debian-installer.d > +usr/lib/debian-installer-startup.d These are not currently read by the debian installer, so we mustn't move these files for now. Samuel
Bug#1064159: bookworm-pu: package ebook-speaker/6.2.0-4+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: ebook-spea...@packages.debian.org
Control: affects -1 + src:ebook-speaker
User: release.debian@packages.debian.org
Usertags: pu
Hello,
I have uploaded ebook-speaker_6.2.0-4+deb12u1 for inclusion in
bookworm.
[ Reason ]
As reported on
https://github.com/book-readers/ebook-speaker/issues/4
Some users see ebook-speaker just completely fail... just because their
login is longer than 8 characters. oldstable already had the issue.
[ Impact ]
Users with a login longer than 8 characters cannot use ebook-speaker.
[ Tests ]
This was tested manually.
[ Risks ]
The code is rather simple.
[ 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 patch gets rid of the use of the cuserid() function which brings the
length limitation. Instead we just compare gids as int rather than
interating over the logins of the group, which won't pose such kind of
issues.
Thanks,
Samuel
diff -Nru ebook-speaker-6.2.0/debian/changelog
ebook-speaker-6.2.0/debian/changelog
--- ebook-speaker-6.2.0/debian/changelog2022-01-08 18:01:53.0
+0100
+++ ebook-speaker-6.2.0/debian/changelog2022-02-06 01:10:26.0
+0100
@@ -1,3 +1,9 @@
+ebook-speaker (6.2.0-4+deb12u1) bookworm; urgency=medium
+
+ * patches/long-logins: Fix testing belonging to the audio group.
+
+ -- Samuel Thibault Sun, 06 Feb 2022 01:10:26 +0100
+
ebook-speaker (6.2.0-4) unstable; urgency=medium
* control: Bump Standards-Version to 4.6.0 (no change)
diff -Nru ebook-speaker-6.2.0/debian/patches/long-logins
ebook-speaker-6.2.0/debian/patches/long-logins
--- ebook-speaker-6.2.0/debian/patches/long-logins 1970-01-01
01:00:00.0 +0100
+++ ebook-speaker-6.2.0/debian/patches/long-logins 2022-02-06
01:10:26.0 +0100
@@ -0,0 +1,47 @@
+commit b29f4884e9a7637e09f93f8d53973c83a69670d9
+Author: Samuel Thibault
+Date: Sun Feb 11 21:32:24 2024 +0100
+
+Fix testing belonging to the audio group
+
+cuserid() is limited to L_cuserid characters, which is 9. This means that
+users with a longer login were never seen as belonging to the group.
+
+Let us just replace with using getgroups, which allows
+- to actually check the current allowed groups,
+- to compare gids, which don't pose length limitations.
+
+Fixes #4
+
+diff --git a/src/common.c b/src/common.c
+index a580153..6658c40 100644
+--- a/src/common.c
b/src/common.c
+@@ -911,17 +911,18 @@ void get_list_of_sound_devices (misc_t *misc,
audio_info_t *sound_devices)
+char *str, *orig_language;
+struct group *grp;
+FILE *p;
++ int ngroups;
++
++ ngroups = getgroups (0, NULL);
++ gid_t groups[ngroups];
++ getgroups (ngroups, groups);
+
+grp = getgrnam ("audio");
+- found = 0;
+- for (g = 0; grp->gr_mem[g]; g++)
+- {
+- if (strcmp (grp->gr_mem[g], cuserid (NULL)) == 0)
+- {
+- found = 1;
+- break;
+- } // if
+- } // for
++ found = getegid () == grp->gr_gid;
++
++ for (g = 0; !found && g < ngroups; g++)
++ found = groups[g] == grp->gr_gid;
++
+if (found == 0)
+{
+ beep ();
diff -Nru ebook-speaker-6.2.0/debian/patches/series
ebook-speaker-6.2.0/debian/patches/series
--- ebook-speaker-6.2.0/debian/patches/series 2021-10-23 21:25:33.0
+0200
+++ ebook-speaker-6.2.0/debian/patches/series 2022-02-06 01:10:26.0
+0100
@@ -2,3 +2,4 @@
path-fix
format
automake
+long-logins
diff -Nru ebook-speaker-6.2.0/debian/salsa-ci.yml
ebook-speaker-6.2.0/debian/salsa-ci.yml
--- ebook-speaker-6.2.0/debian/salsa-ci.yml 2021-09-26 11:05:02.0
+0200
+++ ebook-speaker-6.2.0/debian/salsa-ci.yml 2022-02-06 01:10:26.0
+0100
@@ -3,6 +3,9 @@
- https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
-
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+variables:
+ RELEASE: bookworm
+
test-crossbuild-arm64:
allow_failure: false
Bug#1063643: gcc-14: Fix disabling go and m2 according to OS
Samuel Thibault, le sam. 10 févr. 2024 13:07:44 +0100, a ecrit: > There was a typo in rules.defs concerning go_no_systems and > m2_no_systems: they are still compared against DEB_TARGET_ARCH_OS, > while their content is gnu-system-like (kfreebsd-gnu, gnu), and > indeed all other foo_no_systems variables are compared against > DEB_TARGET_GNU_SYSTEM. > > This was making the hurd-i386 build get stuck while building m2, the > attached patch fixes it. Actually in the gcc-14 case there was another typo, updated patch attached. Samuel diff --git a/debian/rules.defs b/debian/rules.defs index 2810b233..6ef02c98 100644 --- a/debian/rules.defs +++ b/debian/rules.defs @@ -989,7 +989,7 @@ endif ifneq (,$(filter $(DEB_TARGET_ARCH),$(go_no_cpus))) with_go := disabled for arch $(DEB_TARGET_ARCH) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems))) with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes) @@ -1185,11 +1185,11 @@ ifneq ($(with_base_only),yes) endif endif m2_no_cpus = loong64 powerpc ppc64 sh4 -n2_no_systems = gnu +m2_no_systems = gnu ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus))) with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(m2_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(m2_no_systems))) with_m2 := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifeq ($(m2_no_cross)-$(DEB_CROSS),yes-yes)
Bug#1063684: cross-gcc-dev: needs update for gcc-13
Package: cross-gcc-dev Version: 248 Severity: important Hello, The gcc-13 doesn't apply any more, e.g. when using rebootstrap: Applying patch /usr/share/cross-gcc/patches/gcc-13/0003-Compilers-now-depend-on-cpp-instead-of-gcc-base.patch patching file debian/control.m4 Hunk #1 FAILED at 1157. Hunk #2 FAILED at 3661. 2 out of 2 hunks FAILED -- rejects in file debian/control.m4 patching file debian/rules.conf Hunk #1 succeeded at 1281 (offset 26 lines). Patch /usr/share/cross-gcc/patches/gcc-13/0003-Compilers-now-depend-on-cpp-instead-of-gcc-base.patch does not apply (enforce with -f) Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cross-gcc-dev depends on: ii coreutils 9.4-3+b1 ii make 4.3-4.1 cross-gcc-dev recommends no packages. cross-gcc-dev suggests no packages. -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria.
Bug#1063643: gcc-14: Fix disabling go and m2 according to OS
Source: gcc-14 Version: 14-20240201-3 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hello, There was a typo in rules.defs concerning go_no_systems and m2_no_systems: they are still compared against DEB_TARGET_ARCH_OS, while their content is gnu-system-like (kfreebsd-gnu, gnu), and indeed all other foo_no_systems variables are compared against DEB_TARGET_GNU_SYSTEM. This was making the hurd-i386 build get stuck while building m2, the attached patch fixes it. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. diff --git a/debian/rules.defs b/debian/rules.defs index 2810b233..1bb4b96e 100644 --- a/debian/rules.defs +++ b/debian/rules.defs @@ -989,7 +989,7 @@ endif ifneq (,$(filter $(DEB_TARGET_ARCH),$(go_no_cpus))) with_go := disabled for arch $(DEB_TARGET_ARCH) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems))) with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes) @@ -1189,7 +1189,7 @@ n2_no_systems = gnu ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus))) with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(m2_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(m2_no_systems))) with_m2 := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifeq ($(m2_no_cross)-$(DEB_CROSS),yes-yes)
Bug#1063642: gcc-13: Fix disabling go and m2 according to OS
Package: gcc-13 Version: 13.2.0-13 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hello, There was a typo in rules.defs concerning go_no_systems and m2_no_systems: they are still compared against DEB_TARGET_ARCH_OS, while their content is gnu-system-like (kfreebsd-gnu, gnu), and indeed all other foo_no_systems variables are compared against DEB_TARGET_GNU_SYSTEM. This was making the hurd-i386 build get stuck while building m2, the attached patch fixes it. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-13 depends on: ii binutils 2.42-2 ii gcc-13-base 13.2.0-13 ii gcc-13-x86-64-linux-gnu 13.2.0-13 Versions of packages gcc-13 recommends: ii libc6-dev 2.37-15~deb13u1 Versions of packages gcc-13 suggests: ii gcc-13-doc 13.2.0-1 pn gcc-13-locales ii gcc-13-multilib 13.2.0-13 -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. diff --git a/debian/rules.defs b/debian/rules.defs index 8638be92..4fa62c62 100644 --- a/debian/rules.defs +++ b/debian/rules.defs @@ -1019,41 +1019,41 @@ endif go_no_cpus := arc avr hppa loong64 go_no_cpus += m68k # See PR 79281 / PR 83314 go_no_systems := kfreebsd-gnu ifneq (,$(filter $(distrelease),precise)) go_no_cpus = armhf go_no_archs = armhf endif # Debian #969221 go_no_cpus += sh4 go_no_archs += sh4 ifneq ($(with_base_only),yes) ifneq ($(separate_lang),yes) with_go := yes endif endif ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(go_no_cpus))) with_go := disabled for cpu $(DEB_TARGET_ARCH_CPU) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems))) with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifneq (,$(filter $(DEB_TARGET_ARCH),$(go_no_archs))) with_go := disabled for architecture $(DEB_TARGET_ARCH) endif ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes) with_go := disabled for cross compiler package endif ifeq ($(DEB_STAGE)-$(filter libgo, $(with_rtlibs)),rtlibs-) with_go := disabled for rtlibs stage endif with_go := $(call envfilt, go, , , $(with_go)) # Build all packages needed for Go development ifneq (,$(findstring gcc, $(PKGSOURCE))) ifeq ($(with_go),yes) ifeq ($(with_dev),yes) with_godev := yes endif with_libgo := yes @@ -1262,41 +1262,41 @@ endif with_objcxx := $(call envfilt, obj-c++, , c++ objc, $(with_objcxx)) ifeq ($(with_objcxx),yes) enabled_languages += obj-c++ endif # Modula-2 --- m2_no_cross := yes m2_no_cross := no ifneq ($(with_base_only),yes) ifneq ($(separate_lang),yes) with_m2 := yes endif endif m2_no_cpus = loong64 powerpc ppc64 sh4 m2_no_systems = gnu kfreebsd-gnu ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus))) with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(m2_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(m2_no_systems))) with_m2 := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifeq ($(m2_no_cross)-$(DEB_CROSS),yes-yes) with_m2 := disabled for cross compiler package endif ifeq ($(DEB_STAGE)-$(filter libgm2, $(with_rtlibs)),rtlibs-) with_m2 := disabled for rtlibs stage endif ifneq (,$(filter $(distrelease),precise)) with_m2 := disabled for $(distrelease) backport endif #with_m2 := disabled for GCC 13 with_m2 := $(call envfilt, m2, , , $(with_m2)) # Build all packages needed for Modula-2 development ifeq ($(with_m2),yes) ifeq ($(with_dev),yes) with_m2dev := yes endif
Bug#1061992: curl: NMU diff for 64-bit time_t transition
Hello Michael, > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > curl as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). Can you tell us which case it is? Is it confirmed affected or is this a guess? I know the curl project has put a lot of effort into this issue already but I don't know the specifics enough to understand whether this is a false positive or not. https://daniel.haxx.se/blog/2018/02/01/reducing-2038-problems-in-curl/ https://github.com/curl/curl/issues/2238 > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. The debdiff is reversed, took me a bit to understand it. Does this mean we should hold on pushing new uploads to testing and experimental until this is done? If so, how long will it take? The curl repo is under the debian namespace on salsa, so feel free to push your commits there once the upload is done (debian/experimental branch for experimental). Regards -- Samuel Henrique
Bug#1061901: compiz: NMU diff for 64-bit time_t transition
Hello,
mwhud...@debian.org, le mar. 30 janv. 2024 01:24:00 +, a ecrit:
> diff -Nru compiz-0.8.18/debian/control compiz-0.8.18/debian/control
> --- compiz-0.8.18/debian/control 2023-01-01 21:58:27.0 +
> +++ compiz-0.8.18/debian/control 2024-01-30 01:22:56.0 +
> @@ -159,7 +159,10 @@
> This package contains the standard plugins that come with compiz. Compiz
> without these plugins is not very useful.
>
> -Package: libdecoration0
> +Package: libdecoration0t64
> +Provides: ${t64:Provides}
> +Replaces: libdecoration0
> +Breaks: libdecoration0 (<< ${source:Version})
> Section: libs
> Architecture: any
> Multi-Arch: same
This seems to be missing updating the Depends: libdecoration0?
Samuel
Bug#1061923: at-spi2-core: NMU diff for 64-bit time_t transition
Hello,
Steve Langasek, le lun. 29 janv. 2024 19:48:58 -0800, a ecrit:
> diff -Nru at-spi2-core-2.50.0/debian/control
> at-spi2-core-2.50.0/debian/control
> --- at-spi2-core-2.50.0/debian/control2023-09-18 06:55:59.0
> -0700
> +++ at-spi2-core-2.50.0/debian/control2024-01-29 19:39:57.0
> -0800
> @@ -51,7 +51,10 @@
> This package contains the core components of GNOME Accessibility for the
> Debian
> installer.
>
> -Package: libatspi2.0-0
> +Package: libatspi2.0-0t64
> +Provides: ${t64:Provides}
> +Replaces: libatspi2.0-0
> +Breaks: libatspi2.0-0 (<< ${source:Version})
> Section: libs
> Architecture: any
> Multi-Arch: same
> @@ -130,7 +133,10 @@
> Description: AT-SPI 2 toolkit bridge - module for d-i
> This package includes the gtk-module for the Debian installer.
>
> -Package: libatk-bridge2.0-0
> +Package: libatk-bridge2.0-0t64
> +Provides: ${t64:Provides}
> +Replaces: libatk-bridge2.0-0
> +Breaks: libatk-bridge2.0-0 (<< ${source:Version})
> Section: libs
> Architecture: any
> Multi-Arch: same
> @@ -160,7 +166,10 @@
> These are the development files for libatk-bridge2.0, needed for
> compilation of programs which use it.
>
> -Package: libatk1.0-0
> +Package: libatk1.0-0t64
> +Provides: ${t64:Provides}
> +Replaces: libatk1.0-0
> +Breaks: libatk1.0-0 (<< ${source:Version})
> Section: libs
> Architecture: any
> Multi-Arch: same
This seems to be missing updating the Depends: libatspi2.0-0 and
libatk-bridge2.0-0 and libatk1.0-0?
Samuel
Bug#1061257: fakeroot: missing renameat2 diversion
Package: fakeroot
Version: 1.32.2-1+b1
Severity: important
Tags: patch upstream
Hello,
I couldn't find the upstream for fakeroot, so reporting here.
I was getting testsuite issues on hurd-amd64, the t.tar test would fail:
13c13
< rw-r--r-- root/root 0 tar/1.file
---
> rw-r--r-- daemon/sys 0 tar/1.file
18c18
< rw-r--r-- root/root 0 tar/3.file
---
> rw-r--r-- daemon/sys 0 tar/3.file
20c20
< rw-r--r-- root/root 0 tar/5.file
---
> rw-r--r-- daemon/sys 0 tar/5.file
24c24
< rw-r--r-- root/root 0 tar/fjsdk.file
---
> rw-r--r-- daemon/sys 0 tar/fjsdk.file
35c35
< rw-r--r-- root/root 0 tar/vn.34.654l..file
---
> rw-r--r-- daemon/sys 0 tar/vn.34.654l..file
It seems like fakeroot is not catching file removals and the inode cache
gets confused. Indeed coreutils now uses renameat2, which fakeroot
doesn't divert yet. The attach patch implements that and indeed fixes
the test.
Samuel
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'),
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500,
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500,
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500,
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fakeroot depends on:
ii libc62.37-13
ii libfakeroot 1.32.2-1+b1
fakeroot recommends no packages.
fakeroot suggests no packages.
-- no debconf information
Index: fakeroot-1.32.2/config.h.in
===
--- fakeroot-1.32.2.orig/config.h.in
+++ fakeroot-1.32.2/config.h.in
@@ -144,6 +144,9 @@
/* Define to 1 if you have the `renameat' function. */
#undef HAVE_RENAMEAT
+/* Define to 1 if you have the `renameat2' function. */
+#undef HAVE_RENAMEAT2
+
/* have the semun union */
#undef HAVE_SEMUN_DEF
Index: fakeroot-1.32.2/configure.ac
===
--- fakeroot-1.32.2.orig/configure.ac
+++ fakeroot-1.32.2/configure.ac
@@ -360,7 +360,7 @@ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
],[ AC_MSG_RESULT([no])
])
-AC_CHECK_FUNCS(fchmodat fchownat fstatat mkdirat mknodat openat renameat
unlinkat lchmod fgetattrlist)
+AC_CHECK_FUNCS(fchmodat fchownat fstatat mkdirat mknodat openat renameat
renameat2 unlinkat lchmod fgetattrlist)
save_LIBS="$LIBS"
# Linux
Index: fakeroot-1.32.2/libfakeroot.c
===
--- fakeroot-1.32.2.orig/libfakeroot.c
+++ fakeroot-1.32.2/libfakeroot.c
@@ -1382,6 +1382,29 @@ int renameat(int olddir_fd, const char *
return 0;
}
#endif /* HAVE_RENAMEAT */
+#ifdef HAVE_RENAMEAT2
+int renameat2(int olddir_fd, const char *oldpath,
+ int newdir_fd, const char *newpath, unsigned int flags){
+ int r,s;
+ INT_STRUCT_STAT st;
+
+ /* If newpath points to an existing file, that file will be
+ unlinked. Make sure we tell the faked daemon about this! */
+
+ /* we need the st_new struct in order to inform faked about the
+ (possible) unlink of the file */
+
+ r=INT_NEXT_FSTATAT(newdir_fd, newpath, , AT_SYMLINK_NOFOLLOW);
+
+ s=next_renameat2(olddir_fd, oldpath, newdir_fd, newpath, flags);
+ if(s)
+return -1;
+ if(!r)
+INT_SEND_STAT(,unlink_func);
+
+ return 0;
+}
+#endif /* HAVE_RENAMEAT2 */
#endif /* HAVE_FSTATAT */
Index: fakeroot-1.32.2/wrapfunc.inp
===
--- fakeroot-1.32.2.orig/wrapfunc.inp
+++ fakeroot-1.32.2/wrapfunc.inp
@@ -203,6 +203,9 @@ mkdirat;int;(int dir_fd, const char *pat
#ifdef HAVE_RENAMEAT
renameat;int;(int olddir_fd, const char *oldpath, int newdir_fd, const char
*newpath);(olddir_fd, oldpath, newdir_fd, newpath)
#endif /* HAVE_RENAMEAT */
+#ifdef HAVE_RENAMEAT2
+renameat2;int;(int olddir_fd, const char *oldpath, int newdir_fd, const char
*newpath, unsigned int flags);(olddir_fd, oldpath, newdir_fd, newpath, flags)
+#endif /* HAVE_RENAMEAT2 */
#ifdef HAVE_UNLINKAT
unlinkat;int;(int dir_fd, const char *pathname, int flags);(dir_fd, pathname,
flags)
#endif /* HAVE_UNLINKAT */
Bug#1006496: hurd: transfer options from d-i to installed system
Hello,
Here is a refreshed patch.
Samuel
Samuel Thibault, le sam. 01 juil. 2023 15:27:39 +0200, a ecrit:
> Hello,
>
> Ping on this?
>
> Samuel Thibault, le sam. 26 févr. 2022 13:00:41 +0100, a ecrit:
> > Source: grub2
> > Version: 2.06-2
> > Severity: normal
> > Tags: patch
> >
> > Hello,
> >
> > It is useful for people to see the Linux kernel options they pass to d-i
> > to be propagated to the installed system, e.g. for serial console setup,
> > disk probing etc. We would like to have this propagation performed for
> > hurd as well, the attach patch implements this.
> >
> > (I have already made the d-i grub-installer package preseed
> > grub2/gnumach_cmdline)
> >
> > Samuel
--- config.in.original 2022-02-24 22:43:14.0 +
+++ config.in 2022-02-24 22:46:16.0 +
@@ -58,6 +58,9 @@
if [ "${GRUB_CMDLINE_LINUX_DEFAULT+set}" = set ]; then
db_set grub2/linux_cmdline_default "$GRUB_CMDLINE_LINUX_DEFAULT"
fi
+if [ "${GRUB_CMDLINE_GNUMACH+set}" = set ]; then
+ db_set grub2/gnumach_cmdline "$GRUB_CMDLINE_GNUMACH"
+fi
# Watch for the inverted logic here...
if [ "${GRUB_DISABLE_OS_PROBER+set}" = set ]; then
if [ "${GRUB_DISABLE_OS_PROBER}" = "false" ]; then
@@ -72,8 +75,16 @@
;;
esac
-db_input ${priority} grub2/linux_cmdline || true
-db_input medium grub2/linux_cmdline_default || true
+case `dpkg --print-architecture` in
+ hurd-*)
+db_input medium grub2/gnumach_cmdline || true
+ ;;
+ *)
+db_input ${priority} grub2/linux_cmdline || true
+db_input medium grub2/linux_cmdline_default || true
+ ;;
+esac
+
db_input low grub2/enable_os_prober || true
case @PACKAGE@ in
grub-*efi*)
--- postinst.in.original2022-02-24 22:44:15.0 +
+++ postinst.in 2022-02-24 22:44:23.0 +
@@ -392,6 +392,7 @@
apply_conf_tweaks "$conf_files" merge_debconf_into_conf GRUB_CMDLINE_LINUX
grub2/linux_cmdline
apply_conf_tweaks "$conf_files" merge_debconf_into_conf
GRUB_CMDLINE_LINUX_DEFAULT grub2/linux_cmdline_default
+apply_conf_tweaks "$conf_files" merge_debconf_into_conf
GRUB_CMDLINE_GNUMACH grub2/gnumach_cmdline
# Horrible stuff here, as the os-prober option is a negative
# setting (GRUB_DISABLE_OS_PROBER). To not confuse people with
--- templates.in.original 2022-02-24 22:46:36.0 +
+++ templates.in2022-02-24 22:47:12.0 +
@@ -12,6 +12,13 @@
The following string will be used as Linux parameters for the default menu
entry but not for the recovery mode.
+Template: grub2/gnumach_cmdline
+Type: string
+_Description: GNU Mach command line:
+ The following GNU Mach command line was extracted from /etc/default/grub.
+ Please verify that it is correct, and modify it if necessary. The command line
+ is allowed to be empty.
+
Template: grub2/force_efi_extra_removable
Type: boolean
Default: false
--- default/grub.original 2022-02-26 11:56:38.0 +
+++ default/grub2022-02-24 22:43:55.0 +
@@ -8,6 +8,7 @@
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="@DEFAULT_CMDLINE@"
GRUB_CMDLINE_LINUX=""
+GRUB_CMDLINE_GNUMACH=""
# If your computer has multiple operating systems installed, then you
# probably want to run os-prober. However, if your computer is a host
Bug#1061201: dosfstools: Add nocheck profile
Package: dosfstools Version: 4.2-1 Severity: normal Tags: patch Hello, To simplify bootstrapping new ports, it would be useful to make the xxd build-dep !nocheck, as the attached patch does. Thanks, Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dosfstools depends on: ii libc6 2.37-13 dosfstools recommends no packages. dosfstools suggests no packages. -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. --- debian/control.original 2024-01-20 18:55:48.889900271 +0100 +++ debian/control 2024-01-20 18:55:51.539916307 +0100 @@ -2,7 +2,7 @@ Section: otherosfs Priority: optional Maintainer: Andreas Bombe -Build-Depends: debhelper-compat (= 13), xxd +Build-Depends: debhelper-compat (= 13), xxd Standards-Version: 4.5.1 Rules-Requires-Root: no Homepage: https://github.com/dosfstools/dosfstools
Bug#1055434: libwebp <-> tiff build-dep loop
Hello, Boyuan Yang, le jeu. 11 janv. 2024 13:37:45 -0500, a ecrit: > On Mon, 6 Nov 2023 01:42:57 +0100 Samuel Thibault > wrote: > > There is a direct build-depend loop between libwebp and tiff. Could you > > introduce a notiff build profile in order to break this loop? Otherwise > > one can't seamlessly bootstrap new Debian ports. > > According to > https://wiki.debian.org/BuildProfileSpec#Adding_new_profiles_to_this_registry > , > adding a new build profile may need some discussion to reach a consensus. Do > you > think it is necessary to start a discussion on debian-devel for notiff > profile? AIUI that is for cross-packages profiles. Packages themselves can freely add their own profile names, see pkg.$sourcepackage.$anything in https://wiki.debian.org/BuildProfileSpec#Registered_profile_names e.g. here pkg.libwebp.notiff. Samuel
Bug#1060219: xvkbd: Fn keys are usually white on white & change color depending on what key is clicked.
Hello, p...@tutanota.de, le dim. 07 janv. 2024 23:39:17 +0100, a ecrit: > it occurs to me - there are some statements in the > theme that are gtk deprecated. Which theme? Do you mean a desktop theme or xvkbd customization? Samuel
Bug#1060219: xvkbd: Fn keys are usually white on white & change color depending on what key is clicked.
Hello, Lew_Rockwell_Fan via Pkg-a11y-devel, le dim. 07 janv. 2024 14:34:49 -0500, a ecrit: >* What outcome did you expect instead? I hoped the color scheme would > become stable, or at least usable. White on white is not usable. It's also an > eye sore, almost literally. white on white? Could you post a screenshot? This is what I am getting. Which graphical environment are you using? (desktop? Xorg? Wayland?) Samuel
Bug#1060220: rootskel: Can't stick to pure vga textmode any more
Samuel Thibault, le dim. 07 janv. 2024 21:24:23 +0100, a ecrit: > Samuel Thibault, le dim. 07 janv. 2024 21:14:53 +0100, a ecrit: > > https://www.debian.org/releases/stable/i386/ch05s02.en.html#idm1171 > > > > documents a way to keep the pure vga text mode, but this doesn't seem to > > be working any more: vga=normal fb=false doesn't seem to be effective > > any more, vga=normal does indeed keep the textmode vga, but then even > > with fb=false the fbcon still gets triggered. I tried to manually set > > TERM_TYPE=dumb with the same result. > > > > Any idea what nowadays could be triggering the fbcon? > > Note: this is new in bookworm, bullseye doesn't pose the problem. > > I assigned the bug to rootskel, but not much has changed for it between > the two, so probably the bug isn't there, but I don't really know where > to look at otherwise. Could it be udev? Would there be a way to disable that? Samuel
Bug#1060220: rootskel: Can't stick to pure vga textmode any more
Samuel Thibault, le dim. 07 janv. 2024 21:14:53 +0100, a ecrit: > Source: rootskel > Version: 1.136 > Severity: important > Tags: a11y > > Hello, > > https://www.debian.org/releases/stable/i386/ch05s02.en.html#idm1171 > > documents a way to keep the pure vga text mode, but this doesn't seem to > be working any more: vga=normal fb=false doesn't seem to be effective > any more, vga=normal does indeed keep the textmode vga, but then even > with fb=false the fbcon still gets triggered. I tried to manually set > TERM_TYPE=dumb with the same result. > > Any idea what nowadays could be triggering the fbcon? Note: this is new in bookworm, bullseye doesn't pose the problem. I assigned the bug to rootskel, but not much has changed for it between the two, so probably the bug isn't there, but I don't really know where to look at otherwise. Samuel
Bug#1060220: rootskel: Can't stick to pure vga textmode any more
Source: rootskel Version: 1.136 Severity: important Tags: a11y Hello, https://www.debian.org/releases/stable/i386/ch05s02.en.html#idm1171 documents a way to keep the pure vga text mode, but this doesn't seem to be working any more: vga=normal fb=false doesn't seem to be effective any more, vga=normal does indeed keep the textmode vga, but then even with fb=false the fbcon still gets triggered. I tried to manually set TERM_TYPE=dumb with the same result. Any idea what nowadays could be triggering the fbcon? Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.6.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1060165: RM: liblouisutdml/2.12.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: liblouisut...@packages.debian.org Control: affects -1 + src:liblouisutdml Hello, One month later, upstream liblouisutdml is failing to update to the newer liblouis (3.28): https://github.com/liblouis/liblouisutdml/issues/103 thus making it fail to build in unstable (#1058514) and its autopkgtest failing with the newer liblouis, thus leading to an automatic request for removal of liblouis (#1060148). We really rather want to update liblouis and remove liblouisutdml from testing rather than see liblouis stuck at 3.27. Thanks, Samuel
Bug#1060093: lirc: FTBFS on hurd-i386
Svante Signell, le ven. 05 janv. 2024 23:20:54 +0100, a ecrit: > On Fri, 2024-01-05 at 21:58 +0100, Samuel Thibault wrote: > > Svante Signell, le ven. 05 janv. 2024 21:14:19 +0100, a ecrit: > > > --- a/debian/rules 2023-12-16 18:35:11.0 +0100 > > > +++ b/debian/rules 2024-01-02 12:49:12.0 +0100 > > > @@ -4,7 +4,14 @@ > > > include /usr/share/dpkg/pkg-info.mk > > > > > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > > -export > > > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DE > > > B_HOST_MULTIARCH) > > > + > > > +ifeq ($(DEB_HOST_ARCH_OS), hurd) > > > +#FIXME: Replace gnu0 with either gnu or hurd in python3.11! > > > +#/usr/lib/python3.11/__pycache__/_sysconfigdata__gnu0_i386- > > > gnu.cpython-311.pyc > > > + export > > > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__gnu0_$(DEB_HOST_MULTIARC > > > H) > > > +else > > > + export > > > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DE > > > B_HOST_MULTIARCH) > > > > Probably better just ask python itself: > > > > export _PYTHON_SYSCONFIGDATA_NAME:=_sysconfigdata__$(shell python3 -c > > 'import os; print(os.sys.platform)')_$(DEB_HOST_MULTIARCH) > > Why does the os.sys.platform report gnu0? It should be gnu or > preferrably hurd?? Well, here this question does not matter: it reports what it should report, i.e. what is used to name the sysconfig data file. If the string should be changed, that should be discussed with upstream python, not this package in particular (and this package should just adapt to whatever os.sys.platform comes to expose). > > > @@ -33,7 +40,7 @@ > > > else > > > dh_auto_configure -- \ > > > SH_PATH=/bin/sh \ > > > - MODINFO=/sbin/modinfo \ > > > + MODINFO= \ > > > --disable-uinput --disable-devinput > > > > We do want modinfo on the linux platform, please make this os- > > specific. > > Note the else: > ifeq ($(DEB_HOST_ARCH_OS), linux) > dh_auto_configure -- \ > SH_PATH=/bin/sh \ > MODINFO=/sbin/modinfo \ > --enable-uinput --enable-devinput > else > dh_auto_configure -- \ > SH_PATH=/bin/sh \ > MODINFO= \ > --disable-uinput --disable-devinput > endif Ah, ok, I didn't have the broader context in the patch. Samuel
Bug#1060093: lirc: FTBFS on hurd-i386
Hello, Thanks for your patches. Svante Signell, le ven. 05 janv. 2024 21:14:19 +0100, a ecrit: > --- a/debian/rules2023-12-16 18:35:11.0 +0100 > +++ b/debian/rules2024-01-02 12:49:12.0 +0100 > @@ -4,7 +4,14 @@ > include /usr/share/dpkg/pkg-info.mk > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > -export > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH) > + > +ifeq ($(DEB_HOST_ARCH_OS), hurd) > +#FIXME: Replace gnu0 with either gnu or hurd in python3.11! > +#/usr/lib/python3.11/__pycache__/_sysconfigdata__gnu0_i386-gnu.cpython-311.pyc > + export > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__gnu0_$(DEB_HOST_MULTIARCH) > +else > + export > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH) Probably better just ask python itself: export _PYTHON_SYSCONFIGDATA_NAME:=_sysconfigdata__$(shell python3 -c 'import os; print(os.sys.platform)')_$(DEB_HOST_MULTIARCH) > @@ -33,7 +40,7 @@ > else > dh_auto_configure -- \ > SH_PATH=/bin/sh \ > - MODINFO=/sbin/modinfo \ > + MODINFO= \ > --disable-uinput --disable-devinput We do want modinfo on the linux platform, please make this os-specific. Samuel
Bug#1059986: dpkg: Please add hurd-arm64 case
Hello, Guillem Jover, le jeu. 04 janv. 2024 20:23:02 +0100, a ecrit: > but even though I've seen already some toolchain patches flying by, > AFAIUI there's still no GNU Mach support, so I think I'd prefer to > wait until that materializes, Ok. > as per the FAQ entry on new ports. I don't think this would block > anything right now anyway, no? I've hacked by chroot to add the arch to be able to build packages already ;) I was mostly anticipating this piece of the port which is needed for proper set up of most of the rest :) Samuel
Bug#1059986: dpkg: Please add hurd-arm64 case
Package: dpkg Version: 1.22.2 Severity: normal User: debian-h...@lists.debian.org Usertags: hurd Hello, aarch64-gnu support is coming too :) Could you add a hurd-amd64 case in dpkg? Thanks, Samuel -- Package-specific info: This system uses merged-usr-via-aliased-dirs, going behind dpkg's back, breaking its core assumptions. This can cause silent file overwrites and disappearances, and its general tools misbehavior. See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.6.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-5+b1 ii libc62.37-13 ii liblzma5 5.4.5-0.1 ii libmd0 1.1.0-1 ii libselinux1 3.5-1+b1 ii libzstd1 1.5.5+dfsg2-2 ii tar 1.34+dfsg-1.3 ii zlib1g 1:1.3.dfsg-3 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.7.6 pn debsig-verify -- Configuration Files: /etc/logrotate.d/dpkg changed [not included] -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria.
Bug#1059624: linux-image-6.1.0-16-amd64: aacraid abort request / SCSI hang after upgrade from 11.8 -> 12.4
Hi Salvatore, > Greg just queued it: > https://lore.kernel.org/all/2023123013-dose-skirmish-27c2@gregkh/ queued sounds good, so happy there is a solution in sight. The good thing about this bug is that we can use our "faulty" server again, we thought the server had a hardware issue: https://bugzilla.kernel.org/show_bug.cgi?id=217599#c55 Samuel
Bug#1059624: linux-image-6.1.0-16-amd64: aacraid abort request / SCSI hang after upgrade from 11.8 -> 12.4
Hi Salvatore, > Thanks for your testing! Yes this is enough from your side, thanks a > lot for taking the time for the explict test rounds! no problem, thanks for all you work on the Debian project! I hope you get a feedback on your question here: https://lore.kernel.org/all/zy8oxge0qkyuk...@eldamar.lan/ I've been very careful since the last O_DIRECT issue.. But on the other hand, hanging storage is also not without danger. Samuel
Bug#1059624: linux-image-6.1.0-16-amd64: aacraid abort request / SCSI hang after upgrade from 11.8 -> 12.4
Hi Salvatore, > So it would be welcome if you find time to make it possible to test it by > saturday evening. my test was quicker than expected since i found a way to reproduce the issue on my test server. Behind the Adaptec 8805 is a raid6 storage with 54TB and LUKS encrypted. As soon I open and mount the LUKS drive with kernel 6.1.67-1 the controller hang: [ 480.888273] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,3,0): [ 480.902784] aacraid: Host bus reset request. SCSI hang ? [ 480.902933] aacraid :02:00.0: outstanding cmd: midlevel-0 [ 480.902935] aacraid :02:00.0: outstanding cmd: lowlevel-0 [ 480.902936] aacraid :02:00.0: outstanding cmd: error handler-0 [ 480.902936] aacraid :02:00.0: outstanding cmd: firmware-251 [ 480.902937] aacraid :02:00.0: outstanding cmd: kernel-0 [ 480.916921] aacraid :02:00.0: Controller reset type is 3 [ 480.917076] aacraid :02:00.0: Issuing IOP reset [ 517.004437] aacraid :02:00.0: IOP reset succeeded [ 517.029007] aacraid: Comm Interface type2 enabled [ 529.479247] aacraid :02:00.0: Scheduling bus rescan [ 539.678274] aacraid :02:00.0: DDR cache data recovered successfull This is reproducible with every luksClose and luksOpen mount. Now I booting into your test kernel 6.1.67-1a~test and try the same again: [9.610151] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready [ 81.503552] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Quota mode: none. [ 119.133460] EXT4-fs (dm-0): unmounting filesystem. [ 138.547366] sd 0:0:3:0: [sda] Very big device. Trying to use READ CAPACITY(16). [ 139.214205] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Quota mode: none. [ 162.376044] EXT4-fs (dm-0): unmounting filesystem. [ 182.222397] sd 0:0:3:0: [sda] Very big device. Trying to use READ CAPACITY(16). [ 182.913977] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Quota mode: none. [ 217.611072] EXT4-fs (dm-0): unmounting filesystem. [ 230.778060] sd 0:0:3:0: [sda] Very big device. Trying to use READ CAPACITY(16). [ 231.386349] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Quota mode: none. No errors and the LUKS device is opened in ~1 second not like before in 1 minute. Since I can not technical overview the patch/revert, is this enough testing for you? Thanks for the test kernel. Samuel
Bug#1059656: bookworm-pu: package espeak-ng/1.51+dfsg-10+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: espeak...@packages.debian.org Control: affects -1 + src:espeak-ng [ Reason ] This upload provides fixes for CVEs. They are not a regression over oldstable. [ Impact ] Blind users using the espeak-ng speech synthesis might be at risk when e.g. reading a webpage that contains the CVE triggers. [ Tests ] CVE tests are getting added in the patch. [ Risks ] The code is relatively simple, comes from upstream, and has been in testing since December 24th. [ 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 [ Change s]in *all* the changes) The changes fix various use-after-free, unitialized buffers (which lead to missing \0 terminators), and missing buffer bound checks. diff -Nru espeak-ng-1.51+dfsg/debian/changelog espeak-ng-1.51+dfsg/debian/changelog --- espeak-ng-1.51+dfsg/debian/changelog2023-01-26 01:09:47.0 +0100 +++ espeak-ng-1.51+dfsg/debian/changelog2023-12-21 01:26:02.0 +0100 @@ -1,3 +1,10 @@ +espeak-ng (1.51+dfsg-10+deb12u1) bookworm; urgency=medium + + * patches/CVE: Fix CVE-2023-49990, CVE-2023-49991, CVE-2023-49992, +CVE-2023-49993, CVE-2023-49994 (Closes: Bug#1059060) + + -- Samuel Thibault Thu, 21 Dec 2023 01:26:02 +0100 + espeak-ng (1.51+dfsg-10) unstable; urgency=medium * watch: Use API instead of releases page. diff -Nru espeak-ng-1.51+dfsg/debian/patches/CVE espeak-ng-1.51+dfsg/debian/patches/CVE --- espeak-ng-1.51+dfsg/debian/patches/CVE 1970-01-01 01:00:00.0 +0100 +++ espeak-ng-1.51+dfsg/debian/patches/CVE 2023-12-21 01:26:02.0 +0100 @@ -0,0 +1,326 @@ +commit 58f1e0b6a4e6aa55621c6f01118994d01fd6f68c +Merge: f983e445 e7bcd3cc +Author: Alexander Epaneshnikov +Date: Sun Dec 17 15:29:30 2023 +0300 + +tests: fix CVE crashes (#1846) + +Fixes: #1823, #1824, #1825, #1826, #1827 + +- Add crash test and vectors provided by @SEU-SSL +- Disallow dummy/null voice load (that causes incorrect translator +initialization) +- Fix empty `phondata` file load (that causes unitialized memory access) +- Limit max word length for RemoveEnding (causes buffer overflow) +- Limit punctlist initialization from embedded commands (buffer +overflow) +- Fix unitialized pitch in wavegen (DBZ and indexing problems) +- Properly zeroize stack variables before use in TranslateClause and +SetWordStress + +TODO (in nextup PR): add & fix more vectors from fuzzer. + +commit 9decedb8c229e1a4219baceaab7a3d656e889e31 +Author: Samuel Thibault +Date: Thu Jun 30 00:50:18 2022 +0200 + +Fix missing checks for EOF + +commit c4c05820c4a47369d5a81e4a506fe7abb2fa7ed6 +Author: Yury Popov +Date: Sat Dec 16 19:24:51 2023 +0300 + +tests: add CVE crash vectors + +commit e79405772cecf47053116aeaad10e64606292b14 +Author: Yury Popov +Date: Sat Dec 16 23:55:03 2023 +0300 + +voices: disallow dummy voice when not compiling + +commit 7d4ad3c2ae063cb08bfd606021bc323dfbadaba9 +Author: Yury Popov +Date: Sat Dec 16 21:50:07 2023 +0300 + +synthdata: fix empty file load + +commit b99f332c576eb49839613a55cfd3e0e1b5487191 +Author: Yury Popov +Date: Sat Dec 16 22:45:15 2023 +0300 + +dictionary: limit word length + +commit 1a7ecfc2f202438b17e742368f910e6099ce02b7 +Author: Yury Popov +Date: Sat Dec 16 22:50:01 2023 +0300 + +readclause: limit embedded punctlist length + +commit a5eb246debb51ba328ef399350dfcd5d87782245 +Author: Yury Popov +Date: Sat Dec 16 23:03:16 2023 +0300 + +wavegen: fix unitialized pitch + +commit 5f7db763e2eff1d8174d2b65a4bbe4b2a85c8a0c +Author: Yury Popov +Date: Sat Dec 16 23:17:45 2023 +0300 + +translate: fix number_buf initialization + +commit e7bcd3cc1599ebb531bb62fc3007d3ce1dade167 +Author: Yury Popov +Date: Sat Dec 16 23:26:07 2023 +0300 + +dictionary: fix stack initialization + +--- + src/libespeak-ng/dictionary.c |4 + src/libespeak-ng/readclause.c | 12 ++-- + src/libespeak-ng/synthdata.c | 18 ++ + src/libespeak-ng/translate.c |1 + + src/libespeak-ng/voices.c | 20 + src/libespeak-ng/wavegen.c |9 ++--- + tests/crash.test | 17 + + tests/crash_vectors/cve-2023-49990.txt |1 + + tests/crash_vectors/cve-2023-49991.txt |1 + + tests/crash_vectors/cve-2023-49994.txt |1 + + 10 files changed, 63 insertions(+), 21 deletions(-) + +--- a/src/libespeak-ng/readclause.c b/src/libespeak-ng/readclause.c +@@ -335,7 +335,7 @@ static int AnnouncePunctuation(Translato + + if ((*bufix == 0) || (end_clause == 0) || (tr->langopts.param[LOPT_ANNOUNC
Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak
Hello, Tobias Frost, le mar. 26 déc. 2023 09:44:09 +0100, a ecrit: > I'm puzzled… The changelog is still having multiple entries. > Did the upload fail? Timestamp of the dsc I've checked: 2023-12-19 23:40 > > You changelog file must be -- as this is the initial upload to Debian exactly > this: > > multispeech (4.6.1-1) unstable; urgency=medium > > * Initial release. (Closes: #1055902) > > -- Igor B. Poretsky Sun, 10 Dec 2023 16:01:03 +0300 > > > Thats it. The file ends here. Is this really a strict requirement? When a package has had a life before entering Debian, it can be useful to keep the history of the packaging. Samuel
Bug#1059624: linux-image-6.1.0-16-amd64: aacraid abort request / SCSI hang after upgrade from 11.8 -> 12.4
Hi Salvatore, > if you are allowed to deploy unofficial builds: Would you be willing > to test that the packages in > https://people.debian.org/~carnil/tmp/linux/1059624/ fix the problem? > They contain that specific revert on top. I have signed the sha256sum > file with my key found in the Debian keyring. thank you, I can test this kernel on a test server with the same Adaptec controller. > I cannot really determine right now how many people are affected. In theory, anyone who uses aacraid drivers/controllers. > So in case you manage to test the above packages quite soon there is a > chance we can have it in the next upload. Otherwise in the next after. I'll try to test this by saturday evening, is that too late? Samuel
Bug#1059624: linux-image-6.1.0-16-amd64: aacraid abort request / SCSI hang after upgrade from 11.8 -> 12.4
Hi Salvatore, > And can you confirm that the patch revert fixes your issue? unfortunately not, we downgraded to Debian 11 to get the server working again and I have not enough knowledge to build and test such an kernel. > The revert landed in mainline, but has not been queued for the stable series > yet. I guess it's better to wait for the stable series revert (from the Debian standpoint) and backport it than into Debian 12? Thanks. Samuel
Bug#1059624: linux-image-6.1.0-16-amd64: aacraid abort request / SCSI hang after upgrade from 11.8 -> 12.4
Package: src:linux Version: 6.1.67-1 Severity: normal X-Debbugs-Cc: samuelwol...@googlemail.com Hello, we upgraded our server with Adaptec ASR8805 raid controller from Debian 11.8 to 12.4. After booting into the 6.1x kernel the system boot and works without load, but as soon the server has some load the system stops/freeze with abort request / SCSI hang. This is a known issue, is it possible to backport this bugfix into Debian 12? https://bugzilla.kernel.org/show_bug.cgi?id=217599 -- Package-specific info: ** Version: Linux version 6.1.0-16-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-16-amd64 root=UUID=3f04dcfb-f323-4b62-aefa-219e71ea4f35 ro quiet splash ** Not tainted
Bug#1059498: vmg does not start, with the error message "Failed to get raw image from device."
Hello, Did you run it from an Xorg or from a Wayland session? Samuel
Bug#1059259: lwip: CVE-2023-49287
Control: severity -1 wishlist Hello, Moritz Mühlenhoff, le ven. 22 déc. 2023 10:03:28 +0100, a ecrit: > CVE-2023-49287[0]: > | TinyDir is a lightweight C directory and file reader. Buffer > | overflows in the `tinydir_file_open()` function. This vulnerability > | has been patched in version 1.2.6. > > https://github.com/cxong/tinydir/security/advisories/GHSA-jf5r-wgf4-qhxf > https://github.com/cxong/tinydir/commit/8124807260735a837226fa151493536591f6715d > https://github.com/hnsecurity/vulns/blob/main/HNS-2023-04-tinydir.txt > > falcosecurity-libs embeds a copy of tinydir, if it's not used to > open files from potentially untrusted paths, feel free to downgrade. The tinydir_file_open function is not used at all indeed. (and we don't ship the only lwip app that includes tinydir.h anyway) Samuel
Bug#1059183: RM: loadlin -- ROM; uploads are stuck
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: load...@packages.debian.org Control: affects -1 + src:loadlin Hello, I have been waiting for a year and a half for loadlin's NEW to be processed. I tried pinging from times to times in various ways, to no available. Since that prevents from any further upload of loadin, I cannot fix the various bugs #1016428 #1052746 #1059172 which are hindering other Debian work. RM is basically the last straw I can see myself use, unamused. Samuel
Bug#1055316: heimdal: fails to build against glibc 2.38
Brian May, le lun. 11 déc. 2023 17:54:42 +1100, a ecrit: > Samuel Thibault writes: > >> Whaat is the process for a breaks transition? > > > > Some details examples are discussed in Bug#1043184 in the case of krb5. > > Thinking if I just drop the symbols, this is going to break > libafsauthent2 while we still have glibc 2.37 in unstable. Does this > sound correct? Indeed. > Although maybe this does not matter, I see that there is already a > serious bug against openafs anyway since > August... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043131 It made the package out of testing, so in practice breaking libafsauthent2 would not break testing, only unstable, and the kernel module can't be built at the moment, so that could be just ignored. Another way would be to change heimdal to always keep the rk_strlcpy and rk_strlcat symbols for now, even when glibc provides strlcpy and strlcat. That way glibc 2.38 can be uploaded fine, and dropping rk_strlcpy and rk_strlcat can be done later on, once glibc 2.38 is settled (and when we know that openafs can migrate again to testing). Samuel
