Bug#1034578: bullseye-pu: package tzdata/2021a-1+deb11u10
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: tzd...@packages.debian.org, debian-gl...@lists.debian.org Control: affects -1 + src:tzdata [ Reason ] Include the changes found tzdata 2023c into the bullseye package, namely the change to Lebanon DST. Given the confusion about DST in Lebanon, and with a point release so close, I haven't judged necessary to go through stable-updates. [ Impact ] Users in Lebanon will still have the wrong time. [ Tests ] There are not tests for the current change. [ Risks ] The change is trivial and is based on upstream change, and is in sid for almost 3 weeks. [ 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 ] This basically reverts the change done in version 2021a-1+deb11u9 to match the status quo about DST in Lebanon. It's best summarized by the upstream changelog: "Model Lebanon's DST chaos by reverting data to tzdb 2023a". [ Other info ] I have already uploaded the package to the archive. Thanks for considering. diff -Nru tzdata-2021a/debian/changelog tzdata-2021a/debian/changelog --- tzdata-2021a/debian/changelog 2023-03-24 22:41:33.0 + +++ tzdata-2021a/debian/changelog 2023-04-18 20:03:16.0 + @@ -1,3 +1,11 @@ +tzdata (2021a-1+deb11u10) bullseye; urgency=medium + + * Cherry-pick patch from upstream: +- 24-lebanon-dst2.patch: Revert the Lebanon DST change introduced in + 2023b and backported to 2021a-1+deb11u9. + + -- Aurelien Jarno Tue, 18 Apr 2023 22:03:16 +0200 + tzdata (2021a-1+deb11u9) bullseye; urgency=medium * Cherry-pick patches from upstream: diff -Nru tzdata-2021a/debian/patches/24-lebanon-dst2.patch tzdata-2021a/debian/patches/24-lebanon-dst2.patch --- tzdata-2021a/debian/patches/24-lebanon-dst2.patch 1970-01-01 00:00:00.0 + +++ tzdata-2021a/debian/patches/24-lebanon-dst2.patch 2023-04-18 20:00:36.0 + @@ -0,0 +1,110 @@ +commit 0e0b0eb3e5b3c046971ff69aae1ca69c1450f5b4 +Author: Paul Eggert +Date: Mon Mar 27 10:17:37 2023 -0700 + +Revert 2023b’s data changes + +* NEWS: Mention this. +* asia (Lebanon): Revert to 2023a data. Add commentary. +* tz-link.html: Warn further about confusion. + +diff --git a/NEWS b/NEWS +index 9b235a29..fe0e809b 100644 +--- a/NEWS b/NEWS +@@ -4,6 +4,9 @@ + + Changes to future timestamps + ++Model Lebanon's DST chaos by reverting data to tzdb 2023a. ++(Thanks to Jad Baz for the heads-up.) ++ + This year Lebanon springs forward April 20/21 not March 25/26. + (Thanks to Saadallah Itani.) + +diff --git a/asia b/asia +index dd06a5fd..180b3992 100644 +--- a/asia b/asia +@@ -2693,9 +2693,37 @@ ZoneAsia/Pyongyang 8:23:00 - LMT 1908 Apr 1 + # Lebanon + # + # From Saadallah Itani (2023-03-23): +-# Lebanon too announced today delay of Spring forward from March 25 to April 20. +-# From Paul Eggert (2023-03-23): ++# Lebanon ... announced today delay of Spring forward from March 25 to April 20. ++# ++# From Paul Eggert (2023-03-27): ++# This announcement was by the Lebanese caretaker prime minister Najib Mikati. + # https://www.mtv.com.lb/en/News/Local/1352516/lebanon-postpones-daylight-saving-time-adoption ++# A video was later leaked to the media of parliament speaker Nabih Berri ++# asking Mikati to postpone DST to aid observance of Ramadan, Mikati objecting ++# that this would cause problems such as scheduling airline flights, to which ++# Berri interjected, "What flights?" ++# ++# The change was controversial and led to a partly-sectarian divide. ++# Many Lebanese institutions, including the education ministry, the Maronite ++# church, and two news channels LCBI and MTV, ignored the announcement and ++# went ahead with the long-scheduled spring-forward on March 25/26, some ++# arguing that the prime minister had not followed the law because the change ++# had not been approved by the cabinet. Google went with the announcement; ++# Apple ignored it. At least one bank followed the announcement for its doors, ++# but ignored the announcement in internal computer systems. ++# Beirut international airport listed two times for each departure. ++# Dan Azzi wrote "My view is that this whole thing is a Dumb and Dumber movie." ++# Eventually the prime minister backed down, said the cabinet had decided to ++# stick with its 1998 decision, and that DST would begin midnight March 29/30. ++# https://www.nna-leb.gov.lb/en/miscellaneous/604093/lebanon-has-two-times-of-day-amid-daylight-savings ++# https://www.cnbc.com/2023/03/27/lebanon-in-two-different-time-zones-as-government-disagrees-on-daylight-savings.html ++# ++# Although we could model the chaos with two Zones, that would likely cause ++# more trou
Bug#1034548: bullseye-pu: package glibc/2.31-13+deb11u6
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: gl...@packages.debian.org, debian-b...@lists.debian.org,
debian-gl...@lists.debian.org
Control: affects -1 + src:glibc
[ Reason ]
There are multiple fixes in this upload, all coming from the upstream
stable branch:
- Multiple crashes or memory leak in printf-family functions
- Overflow fix in the AVX2 implementation of wcsnlen
[ Impact ]
In case the update isn't approved, systems will be left with issues
which combined with other vulnerabilities might lead to denial of
service.
[ Tests ]
The upstream fixes come with additional tests, which represent a
significant part of the diff.
[ Risks ]
The most risky parts are probably the printf-family functions changes,
however those changes are in testing/sid for ~1.5 years (since glibc
2.32), but have only been identified as problematic recently. The
wcsnlen fix is in testing/sid for ~4 months. All of those changes come
with additional tests.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Let me comment the changelog:
- Drop debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
(obsolete).
The upstream stable branch for glibc 2.31 now includes the fix
introduced in glibc 2.31-13+deb11u5 to fix some crash on some CPU.
Therefore this patch is not needed anymore.
- Fix memory leak in printf-family functions with long multibyte strings.
This fixes a memory leak that might lead to OOM when calling with
long multibyte strings. The simplest reproducer is:
printf("%.1371337ls", L"A\n");
- Fix a crash in printf-family due to width/precision-dependent
allocations.
This fixes a crash due to a missing overflow check in the requested
precision. The simplest reproducer is:
fprintf (fp, "%2$.*1$a", 0x7fff, 1e200);
- Fix a segfault in printf handling thousands separator.
This segmentation fault has been fixed as a side effect of the
previous fix, but comes with a specific test. The simplest reproducer
is:
setlocale(LC_ALL, "en_US.UTF-8");
printf("%'1000d\n", 1000);
- Fix an overflow in the AVX2 implementation of wcsnlen when crossing
pages.
The overflow happens when wcsnlen is called with a huge maxlen
argument (e.g. (1UL << 63)), triggering an assertion in the wcsnlen
code.
diff --git a/debian/changelog b/debian/changelog
index 50f6135b..3d95edf8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+glibc (2.31-13+deb11u6) UNRELEASED; urgency=medium
+
+ [ Aurelien Jarno ]
+ * debian/patches/git-updates.diff: update from upstream stable branch:
+- Drop debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
+ (obsolete).
+- Fix memory leak in printf-family functions with long multibyte strings.
+- Fix a crash in printf-family due to width/precision-dependent
+ allocations.
+- Fix a segfault in printf handling thousands separator.
+- Fix an overflow in the AVX2 implementation of wcsnlen when crossing
+ pages.
+
+ -- Aurelien Jarno Sun, 16 Apr 2023 18:58:33 +0200
+
glibc (2.31-13+deb11u5) bullseye; urgency=medium
* debian/patches/local-require-bmi-in-avx2-ifunc.diff: new patch extracted
diff --git a/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
b/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
deleted file mode 100644
index 936f89ae..
--- a/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
+++ /dev/null
@@ -1,38 +0,0 @@
-This patch is extracted from upstream commit 83c5b368226c ("x86-64: Require
-BMI2 for strchr-avx2.S"). It changes the common ifunc AVX2 selector to require
-the BMI2 instructions, and the backported fixes for memchr and strlen rely on
-that change.
-
a/sysdeps/x86_64/multiarch/ifunc-avx2.h
-+++ b/sysdeps/x86_64/multiarch/ifunc-avx2.h
-@@ -21,28 +21,28 @@ IFUNC_SELECTOR (void)
-
- extern __typeof (REDIRECT_NAME) OPTIMIZE (sse2) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2_rtm) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (evex) attribute_hidden;
-
- static inline void *
- IFUNC_SELECTOR (void)
- {
- const struct cpu_features* cpu_features = __get_cpu_features ();
-
- if (CPU_FEATURES_ARCH_P (cpu_features, AVX2_Usable)
-+ && CPU_FEATURES_CPU_P (cpu_features, BMI2)
- && CPU_FEATURES_ARCH_P (cpu_features, AVX_Fast_Unaligned_Load))
- {
- if (CPU_FEATURES_ARCH_P (cpu_features, AVX512VL_Usable)
--&& CPU_FEATURES_ARCH_P (cpu_features, AVX512BW_Usable)
--&& CPU_FEATURES_CPU_P (cpu_features, BMI2
Bug#1034424: buildd.debian.org: Please use predictible build paths
Hi, On 2023-04-16 15:16, Vagrant Cascadian wrote: > On 2023-04-16, Aurelien Jarno wrote: > > I have tried adding a simple .sbuildrc defining $build_path to '/build' > > to zandonai.d.o. Unfortunately while it more or less does what you want > > for the build path, it completely clutter the logs, as any text matching > > "build" is now replaced by "<>": > > > > https://buildd.debian.org/status/fetch.php?pkg=gnome-keyring=s390x=42.1-1%2Bb2=1681671508=0 > > > > > I guess one option is to use a build path unlikely to match any string > > from a build log, like with the randomized directory. Something like > > "/build/reproducible-path/"? > > Just for clarity, then the the PKGBUILDIR would end up being > /build/reproducible-path/PACKAGE-VERSION ? That works! Or something even > shorter ... e.g. /build/path/PACKAGE-VERSION or > /build/debian/PACKAGE-VERSION ? Really, the 2nd directory matters > little, as long as it is predictible. :) Yes, setting $build_path to '/build/debian' indeed means that PKGBUILDDIR is /build/debian/PACKAGE-VERSION. Unfortunately the string 'build/debian' appears in a few build logs: 0ad apktool gatk-bwamem gatk-fermilite gkl grpc-java haskell-debian libsis-jhdf5-java mupdf nacl openjfx pytorch xtables-addons Do you have other short suggestions? Do we want to show it has been built on a debian buildd? In that case /build/debian-buildd might do it. > We have noticed various packages (for better or worse) do tend to derive > information from the top-level build directory by assuming it is > PACKAGE-VERSION; probably good to cater to that assuption. > > Anything along the above lines sounds good, really! Although once a > particular bikeshed is chosen, ideally we should commit to it for the > forseeable future! :) Yes, definitely. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1034424: buildd.debian.org: Please use predictible build paths
Hi, On 2023-04-14 15:06, Vagrant Cascadian wrote: > Source: buildd.debian.org > Severity: wishlist > User: reproducible-bui...@lists.alioth.debian.org > Usertags: buildpath toolchain > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > Thanks for maintaining buildd.debian.org, which consistently cranks out > countless builds of packages that I and many others use! > > > We had a bit of a discussion in in the #reproduciblebuilds channel about > build paths, and it occurred to me that if buildd.debian.org used a > predictible build path. > > Build paths are one of the larger sources sources of reproducibility > issues(~10% of the archive are still affected), and while the workaround > is relatively simple (build in a chroot with the same build path), not > having to do so would be very helpful! > > For example, a build of 0ad uses a randomized string in the Build-Path: > > > https://buildinfos.debian.net/buildinfo-pool/0/0ad/0ad_0.0.26-3_i386.buildinfo > > Build-Path: /build/0ad-al23I5/0ad-0.0.26 This indeed corresponds to the default path used by sbuild. > If this were instead a build path such as: > > Build-Path: /build/0ad-0.0.26-3_i386 This does not seems to be possible to include _i386, but /build/0ad-0.0.26-3 is something possible. > I understand that the build path is randomized a bit in order to avoid > collisions with concurrent builds of the same package version. Yes, that's indeed the reason for the default configuration of sbuild, and I guess also in case the same build is ran multiple time consecutively and the build directory hasn't been cleaned. That said we don't do concurrent buildds nor mount the /build partition on the official buildds. This means it is perfectly fine to use a non randomized path. > Just the fact that it is recorded in the .buildinfo is certainly helpful > and makes it possible to reproduce a build after the fact, but being > able to predict the used build-path would allow performing builds > concurrently (assuming they were pulling from the same package mirrors). > > At least some sbuild backends (unshare mode) can provide an independent > /build directory for each build, avoiding the risk of collisions. My > understanding is buildd.debian.org uses a variant of sbuild? The official buildds use the sbuild from stable, just with the configuration tweaked a tiny bit to use a big tmpfs for building. > I think I could probably come up with a way in sbuild to configure a > unique /build directory using bind-mounts to a randomized directory, if > that would be helpful. Other approaches might involve using mount > namespaces? I have tried adding a simple .sbuildrc defining $build_path to '/build' to zandonai.d.o. Unfortunately while it more or less does what you want for the build path, it completely clutter the logs, as any text matching "build" is now replaced by "<>": https://buildd.debian.org/status/fetch.php?pkg=gnome-keyring=s390x=42.1-1%2Bb2=1681671508=0 I guess one option is to use a build path unlikely to match any string from a build log, like with the randomized directory. Something like "/build/reproducible-path/"? Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1034246: bullseye-pu: package usb.ids/2023.01.16-0+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: usb@packages.debian.org Control: affects -1 + src:usb.ids [ Reason ] This new upstream version of the USB ID database adds a few USB devices. [ Impact ] New USB devices will not be displayed with a human readable name for package using this database. [ Tests ] There is no test associated with this database. This package only contains data, no code. [ Risks ] Risks are very low, such update are routinely done in stable. [ Checklist ] [ ] *all* changes are documented in the d/changelog [ ] I reviewed all changes and I approve them [ ] attach debdiff against the package in (old)stable [ ] the issue is verified as fixed in unstable [ Changes ] I would like to do an update of the usb.ids package to add/update around ~150USB devices to the usb.ids database. Those changes are already in testing/sid for more than 2 months. I have figured out that it's easier to just upload the package from testing/sid with a new changelog entry, however it comes with a new Standards-Version and debhelper compat level. Those have no impact on the resulting binary package. [ Other info ] I have already uploaded the package to the archive. Thanks for considering.
Bug#1034134: [pre-approval] unblock: glibc/2.36-9
control: tags -1 -moreinfo On 2023-04-10 18:30, Sebastian Ramacher wrote: > Control: tags -1 moreinfo confirmed > > On 2023-04-10 11:02:23 +0200, Aurelien Jarno wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > X-Debbugs-Cc: gl...@packages.debian.org, debian-gl...@lists.debian.org > > Control: affects -1 + src:glibc > > > > [ Reason ] > > An RC bug reported by a user (#1033931) triggered a routing update of > > the glibc package from the upstream stable tree, which contains the fix. > > > > The upstream stable tree also includes a fix to the daylight computation > > affecting at least the Africa/Tripoli timezone, as well as a fix to the > > testsuite on POWER when compiling with -mcpu=power10 (which is not the > > case of Debian). > > > > This is also the occasion to update the debconf translation that has > > been received since the toolchain freeze. > > Please go ahead and remove the moreinfo tag once the version is > available in unstable. The update is now available in unstable, and has been built on all release architectures. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1034134: [pre-approval] unblock: glibc/2.36-9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: gl...@packages.debian.org, debian-gl...@lists.debian.org Control: affects -1 + src:glibc [ Reason ] An RC bug reported by a user (#1033931) triggered a routing update of the glibc package from the upstream stable tree, which contains the fix. The upstream stable tree also includes a fix to the daylight computation affecting at least the Africa/Tripoli timezone, as well as a fix to the testsuite on POWER when compiling with -mcpu=power10 (which is not the case of Debian). This is also the occasion to update the debconf translation that has been received since the toolchain freeze. [ Impact ] The FIS-GT.M database randomly crash on x86 processors using the SSE2 version of memcmp, due to a bug in that specific implementation. [ Tests ] The changes to the SSE2 version of memcmp is covered by the existing testsuite. The changes to the daylight computation comes with a new test, which unfortunately can't be run, as it requires a binary test file which can't be included easily in the diff, so it is disabled in the debian package, but I verified manually it passes correctly. [ Risks ] The changes in the resulting binary packages are quite small if we except the translation updates, and have been shipped in some other distributions for a couple of months. Let me anyway detail the changelog that might look scarying at a first glance: | [ Aurelien Jarno ] | * debian/po/it.po: Update Italian debconf translation, by Luca Monducci. |Closes: #1028133. | * debian/po/tr.po: Update Turkish debconf translation, by Atila KOÇ. |Closes: #1028306. | * debian/po/cs.po: Update Czech debconf translation, by Miroslav Kure. |Closes: #1028326. | * debian/po/zh_CN.po: Update Chinese debconf translation, by Tianyu Chen. | * debian/po/pt.po: Update Portugues debconf translation, by Pedro Ribeiro. |Closes: #1028353. | * debian/po/sk.po: Fix invalid control sequence in Slovak translation. | * debian/po/pt_BR.po: Update Brazilian Portuguese debconf translation, by |Adriano Rafael Gomes. Closes: #1029005. | * debian/po/nl.po: Update Dutch debconf translation, by Frans Spiesschaert. |Closes: #1029018, #1033905. | * debian/po/ro.po: Update Romanian debconf translation, by Remus-Gabriel |Chelu. Closes: #1031163. All of the above are just debconf translation updates received recently, it would be good to have them for Bookworm. They represent the majority of the diff. | * debian/patches/git-updates.diff: update from upstream stable branch: |- Prevent SIGSEGV in the SSE2 version of memcmp when data is concurrently | modified. Closes: #1033931. |- Fix a corner case in daylight computation affecting the Africa/Tripoli | zone since tzdata 2022g. |- Fix elf/tst-tlsopt-powerpc failure when compiled with -mcpu=power10. Those are the changes pulled from the upstream stable branch. Note that the changes to elf/tst-tlsopt-powerpc is not relevant for Debian as the ppc64el toolchain does not default to -mcpu=power10 (and neither the ppc64 nor powerpc one do), and anyway the change is in the testsuite so does not affect the resulting binary packages. | * patches/any/local-disable-tst-bz29951.diff: disable new test included in |the latest update from upstream stable branch, as git-updates.diff can't |include the corresponding binary test file. As explained above we can't easily run the new test for the daylight computation fix, so this patch disables it until we can find a better solution. | [ Samuel Thibault ] | * debian/sysdeps/hurd.mk: Add -fno-omit-frame-pointer to extra_cflags. | * debian/testsuite-xfail-debian.mk: Update hurd results. | * debian/patches/hurd-i386/git-intr-msg-cfa.diff: Fix stack unwinding over |_hurd_intr_rpc_mach_msg, for go runtime. | * debian/libc0.3.symbols.hurd-i386: Update symbols with new RPCs. Those are changes that have been accumulated in git since the toolchain freeze, and only affect hurd specific code, so with no impact on the binaries of the release architectures. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing diff --git a/debian/changelog b/debian/changelog index d1a16865..d67a3e5d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,41 @@ +glibc (2.36-9) unstable; urgency=medium + + [ Aurelien Jarno ] + * debian/po/it.po: Update Italian debconf translation, by Luca Monducci. +Closes: #1028133. + * debian/po/tr.po: Update Turkish debconf translation, by Atila KOÇ. +Closes: #1028306. + * debian/po/cs.po: Update Czech debconf translation, by Miroslav Kure. +Closes: #1028326. + * debian/po/zh_CN.po: Update Chinese debconf translation, by Tianyu Chen. + * debian/po/pt.po: Update Portugues debconf translation, by Pedro Ribeiro. +Closes: #1028353. + * debian/po
Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail
On 2023-03-24 13:58, Vagrant Cascadian wrote:
> Adding u-boot maintainers for rpi (Matthias Brugger, Peter Robinson)
> platforms and u-boot list to CC.
>
> On 2023-03-22, Salvatore Bonaccorso wrote:
> > Thanks for tracking this down. I would like to loop in Masahiro and
> > upstream to see if something can/should be done on upstream side.
> >
> > Masahiro, in short, upstream change 994b7ac1697b ("arm64: remove
> > special treatment for the link order of head.o") (which got backported
> > as well to 6.1.14) caused the vmlinuz size to icrease significantly,
> > causing boot failures on Raspberry Pi 3 Model B Plus with u-boot
> > parameters previously working. Full quoting the Debian report below
>
> In general it would be nice to not have the kernel grow nearly 25% in
> size from a single commit; was that an expected outcome from the above
> upstream change? Was the "special treament" originally done to keep the
> kernel size down?
This is currently being tracked [1], but the issue seems to be linked to
the version of the tools used in Debian, and the fact that we build our
kernels with BTF support, so the issue is likely to be difficult to find.
[1] https://lore.kernel.org/linux-arm-kernel/zbovcrmxjk7np...@aurel32.net/
> As for u-boot, It seems u-boot might need to update the various load
> addresses for the kernel, device tree and ramdisk at some point
> regardless of weather this particular issue gets fixed in the kernel, as
> the kernel will likely continue to grow a bit over time...
Yes that's probably a sane thing to do, at least in Debian.
> Aurelien Jarno included a patch referenced below which bumps the
> tolerances in u-boot from 36MB to 42MB.
>
>
> > On Tue, Mar 21, 2023 at 11:11:13PM +0100, Aurelien Jarno wrote:
> >> Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
> >> Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
> >> to boot with:
> >>
> >> | 40175552 bytes read in 1695 ms (23 MiB/s)
> >> | 43794863 bytes read in 1817 ms (23 MiB/s)
> >> | Moving Image from 0x8 to 0x20, end=299
> >> | ERROR: RD image overlaps OS image (OS=0x20..0x299)
> >>
> >> I tracked the issue to a significant increase of the kernel size between
> >> version 6.1.12-1 and 6.15-1:
> >>
> >> | 31492 /boot/vmlinuz-6.1.0-5-arm64
> >> | 39236 /boot/vmlinuz-6.1.0-6-arm64
> >>
> >> This is more than the 36MB that is allowed by u-boot with the default
> >> load addresses. A workaround is to shift the load addresses at the
> >> u-boot level as in the attached patch.
> >>
> >> I have tracked issue on the upstream kernel side to the following commit
> >> on the stable tree:
> >>
> >> | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
> >> | Author: Masahiro Yamada
> >> | Date: Thu Oct 13 08:35:00 2022 +0900
> >> |
> >> | arm64: remove special treatment for the link order of head.o
> >> |
> >> | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
> >> |
> >> | In the previous discussion (see the Link tag), Ard pointed out that
> >> | arm/arm64/kernel/head.o does not need any special treatment - the
> >> only
> >> | piece that must appear right at the start of the binary image is the
> >> | image header which is emitted into .head.text.
> >> |
> >> | The linker script does the right thing to do. The build system does
> >> | not need to manipulate the link order of head.o.
> >> |
> >> | Link:
> >> https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
> >> | Suggested-by: Ard Biesheuvel
> >> | Signed-off-by: Masahiro Yamada
> >> | Reviewed-by: Nicolas Schier
> >> | Link:
> >> https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
> >> | Signed-off-by: Will Deacon
> >> | Signed-off-by: Tom Saeger
> >> | Signed-off-by: Greg Kroah-Hartman
> >>
> >> The problem is still reproducible on Linus' master.
> >>
> >> I am reporting the bug to the linux package as I believed there is no
> >> real reason for such an increase in the kernel size. In case I missed
> >> something and this is actually wanted, the bug can be reassigned to the
> >> u-boot package.
> >>
> >> Regards
> >> Aurelien
> >
> >> --- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail
Source: linux Version: 6.1.15-1 Severity: important Tags: upstream X-Debbugs-Cc: vagr...@debian.org Control: affects -1 + u-boot-rpi Hi, Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed to boot with: | 40175552 bytes read in 1695 ms (23 MiB/s) | 43794863 bytes read in 1817 ms (23 MiB/s) | Moving Image from 0x8 to 0x20, end=299 | ERROR: RD image overlaps OS image (OS=0x20..0x299) I tracked the issue to a significant increase of the kernel size between version 6.1.12-1 and 6.15-1: | 31492 /boot/vmlinuz-6.1.0-5-arm64 | 39236 /boot/vmlinuz-6.1.0-6-arm64 This is more than the 36MB that is allowed by u-boot with the default load addresses. A workaround is to shift the load addresses at the u-boot level as in the attached patch. I have tracked issue on the upstream kernel side to the following commit on the stable tree: | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef | Author: Masahiro Yamada | Date: Thu Oct 13 08:35:00 2022 +0900 | | arm64: remove special treatment for the link order of head.o | | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream. | | In the previous discussion (see the Link tag), Ard pointed out that | arm/arm64/kernel/head.o does not need any special treatment - the only | piece that must appear right at the start of the binary image is the | image header which is emitted into .head.text. | | The linker script does the right thing to do. The build system does | not need to manipulate the link order of head.o. | | Link: https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/ | Suggested-by: Ard Biesheuvel | Signed-off-by: Masahiro Yamada | Reviewed-by: Nicolas Schier | Link: https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org | Signed-off-by: Will Deacon | Signed-off-by: Tom Saeger | Signed-off-by: Greg Kroah-Hartman The problem is still reproducible on Linus' master. I am reporting the bug to the linux package as I believed there is no real reason for such an increase in the kernel size. In case I missed something and this is actually wanted, the bug can be reassigned to the u-boot package. Regards Aurelien --- u-boot-2023.01+dfsg.orig/include/configs/rpi.h +++ u-boot-2023.01+dfsg/include/configs/rpi.h @@ -95,32 +95,32 @@ * text_offset bytes (specified in the header of the Image) into a 2MB * boundary. The 'booti' command relocates the image if necessary. Linux uses * a default text_offset of 0x8. In summary, loading at 0x8 - * satisfies all these constraints and reserving memory up to 0x0240 - * permits fairly large (roughly 36M) kernels. + * satisfies all these constraints and reserving memory up to 0x02a0 + * permits fairly large (roughly 42M) kernels. * * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't * conflict with something else. Reserving 1M for each of them at - * 0x0240-0x0250 and 0x0250-0x0260 should be plenty. + * 0x02a0-0x02b0 and 0x02c0-0x02d0 should be plenty. * * On ARM, both the DTB and any possible initrd must be loaded such that they * fit inside the lowmem mapping in Linux. In practice, this usually means not * more than ~700M away from the start of the kernel image but this number can * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line * parameter given to the kernel. So reserving memory from low to high - * satisfies this constraint again. Reserving 1M at 0x0260-0x0270 for - * the DTB leaves rest of the free RAM to the initrd starting at 0x0270. + * satisfies this constraint again. Reserving 1M at 0x02c0-0x02d0 for + * the DTB leaves rest of the free RAM to the initrd starting at 0x02d0. * Even with the smallest possible CPU-GPU memory split of the CPU getting - * only 64M, the remaining 25M starting at 0x0270 should allow quite + * only 64M, the remaining 19M starting at 0x02d0 should allow quite * large initrds before they start colliding with U-Boot. */ #define ENV_MEM_LAYOUT_SETTINGS \ "fdt_high=" FDT_HIGH "\0" \ "initrd_high=" INITRD_HIGH "\0" \ "kernel_addr_r=0x0008\0" \ - "scriptaddr=0x0240\0" \ - "pxefile_addr_r=0x0250\0" \ - "fdt_addr_r=0x0260\0" \ - "ramdisk_addr_r=0x0270\0" + "scriptaddr=0x02a0\0" \ + "pxefile_addr_r=0x02b0\0" \ + "fdt_addr_r=0x02c0\0" \ + "ramdisk_addr_r=0x02d0\0" #if CONFIG_IS_ENABLED(CMD_MMC) #define BOOT_TARGET_MMC(func) \
Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs
Hi, On 2023-03-16 13:44, Paul Gevers wrote: > Hi, > > [@aurel32, glibc question at the bottom] > > On 16-03-2023 11:57, Bastian Germann wrote: > > Am 16.03.23 um 09:13 schrieb Paul Gevers: > > > I'm not 100% sure I parse that sentence as you intended, so let me > > > ask explicitly: if we binNMU (now or in the future) src:argon2 > > > version 0~20171227-0.3 in bookworm, would it also loose its linking > > > to libpthread? That would be a time bomb (not only in the archive, > > > but also for downstreams and other users that do rebuilds). I > > > *think* you're saying that despite libc's version, that is *not* the > > > case. > > > > Time bomb confirmed. > > Thanks. That changes things. > > > > For the record, with my current understanding I prefer the scenario > > > of keeping the versions of argon2 and cryptsetup in bookworm as they > > > are. Feel free to convince the Release Team of the opposite in an > > > unblock request. > > > > cryptsetup will need to migrate to mitigate the time bomb. > > Ack. > > > As I already mentioned on this or some related bug, I would find it nice > > for #1014110 to be fixed in bookworm (threaded argon2 executable) but I > > do not insist on it. > > cryptsetup can only migrate when argon2 migrates, which leaves me two > options: letting argon2 in as it is now in unstable or going for cryptsetup > via t-p-u. Both sub-optimal, because argon2 has changes that weren't even > meeting the freeze policy rules at the time of the upload. > > While writing this up and discussing with others, I realized that the error > is coming from one of glibc's binaries. It has been stated that the issue > started with with a change there, but is that change done on purpose, or a From what I understand the change has been triggered by the move of the pthread_exit() function from libpthread.so.1 to libc.so.6, which happened in glibc 2.34. libgcc_s.so.1 is loaded dynamically when such function is used to avoid a dependency loop, so libc.so.6 is NOT linked against libgcc_s.so.1. This is not something new, it has been like that for 10+ years. > bug? I.e. is one of glibc's binaries missing a dependency? Technically the libc6 package is indeed missing a dependency against libgcc-s1. This is not an issue given libgcc-s1 is de facto essential. On the glibc side, it should be possible to add such a dependency (although it would not have prevented this bug), but that will create a dependency loop, and tools (apt, aptitude, rebootstrap, ...) would have to learn how to deal with it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#986724: Already fixed
Hi, On 2023-03-11 03:08, Andreas Teiß wrote: > Hello, > > is this bug already fixed in libc6 2.28-10+deb10u2? The bug is still not fixed upstream, so there is no chance we can have fixed it in 2.28-10+deb10u2. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1030855: ring_20230206.0~ds1-2_amd64-buildd.changes REJECTED
Hi, On 2023-02-09 09:41, Amin Bandali wrote: > Hello, > > Aurelien Jarno writes: > > > Source: ring > > Version: 20230206.0~ds1-2 > > Severity: serious > > > > On 2023-02-08 08:40, Debian FTP Masters wrote: > >> jami_20230206.0~ds1-2_amd64.deb: has 5 file(s) with a timestamp too far in > >> th= > >> e past: > >> usr/share/applications/jami.desktop (Thu Jan 1 00:00:01 1970) > >> usr/share/i= > >> cons/hicolor/scalable/apps/jami.svg (Thu Jan 1 00:00:01 1970) > >> usr/share/jam= > >> i/jami.desktop (Thu Jan 1 00:00:01 1970) > >> usr/share/metainfo/jami.appdata.xm= > >> l (Thu Jan 1 00:00:01 1970) usr/share/pixmaps/jami.xpm (Thu Jan 1 > >> 00:00:01= > >> 1970) > >> > >> > >> > >> =3D=3D=3D > >> > >> Please feel free to respond to this email if you don't understand why > >> your files were rejected, or if you upload new files which address our > >> concerns. Please note I am only the messenger here, I am just forwarding a mail (in the BTS so that there is a trace) from Debian FTP Masters telling that your package has been rejected from the archive. I have added them in Cc so they can provide an answer to your question. > Yes please, I'd like to understand why timestamps in the far past are > a 'serious' bug and warrant a rejection. Upstream Jami project has The serious severity of the bug is because your source package has been rejected by Debian FTP Masters, and thus the source and binaries are not in sync, not the timestamp issue. > worked on making various aspects of the release and build processes of > Jami reproducible over the years, including Jami's release tarballs. > The release tarballs are generated with a few additional options[1] to > aide reproducibility, including setting '--mtime=@1' to use the epoch > as the timestamp for all the files included in the release tarballs. > This is quite close to the archive recommendations[2] by the > reproducible builds project. > > So, why would this be considered an issue? > This is a question to be answered by Debian FTP Masters. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1030855: ring_20230206.0~ds1-2_amd64-buildd.changes REJECTED
Source: ring Version: 20230206.0~ds1-2 Severity: serious On 2023-02-08 08:40, Debian FTP Masters wrote: > jami_20230206.0~ds1-2_amd64.deb: has 5 file(s) with a timestamp too far in th= > e past: > usr/share/applications/jami.desktop (Thu Jan 1 00:00:01 1970) usr/share/i= > cons/hicolor/scalable/apps/jami.svg (Thu Jan 1 00:00:01 1970) usr/share/jam= > i/jami.desktop (Thu Jan 1 00:00:01 1970) usr/share/metainfo/jami.appdata.xm= > l (Thu Jan 1 00:00:01 1970) usr/share/pixmaps/jami.xpm (Thu Jan 1 00:00:01= > 1970) > > > > =3D=3D=3D > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > >
Bug#822733: tzdata: Drop /etc/timezone
Hi, On 2023-02-07 23:39, Michael Biebl wrote: > Hi > > Am 07.02.23 um 23:01 schrieb Aurelien Jarno: > > > 2022g-3. You probably want to change d-i to not create that file. > > Where specifically does d-i (i.e. which component) create /etc/timezone? This is done in tzsetup. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#822733: tzdata: Drop /etc/timezone
On 2023-02-06 13:05, Benjamin Drung wrote: > On Sun, 2023-01-29 at 15:45 +0100, Michael Biebl wrote: > > Am 29.01.2023 um 15:38 schrieb Luca Boccassi: > > > On Sun, 29 Jan 2023, 13:15 Michael Biebl, > > <mailto:bi...@debian.org>> wrote: > > > > > > Am 28.01.2023 um 02:12 schrieb Luca Boccassi: > > > > I'm looking at this again, because handling /etc/timezone is one > > > of the > > > > last large technical debt patches that we carry in Debian for > > > > src:systemd, and we want to drop it for Trixie. > > > > The idea is to add a tmpfiles.d entry in the systemd package that > > > > unconditionally deletes /etc/timezone if present. If someone wants > > > to > > > > keep using it, they can simply override the tmpfiles.d entry with > > > the > > > > usual mechanisms. > > > > > > > > So, could you please reconsider the proposal to stop creating it > > > if it > > > > doesn't exist (but keep updating if it does) in the tzdata > > > postinst as > > > > above for Trixie? > > > > > > I'm a bit confused: If you forcefully want to delete /etc/timezone > > > via a > > > tmpfiles snippet, why let tzdata update an existing /etc/timezone? > > > > > > > > > Because it can be overridden as mentioned, so in case there are unknown > > > corner cases where it's still needed, a drop-in can be added to avoid > > > deleting the file and it will still get updated. In the future we can > > > then consider removing this as well. > > > > > > > I would prefer, if all this is handled within tzdata. > > - It should stop creating /etc/timezone > > - It should delete /etc/timezone on upgrades as a one-time action Note that this means that newly installed systems will still have /etc/timezone, as they won't see the upgrade from versions older than 2022g-3. You probably want to change d-i to not create that file. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1030732: bullseye-pu: package debian-ports-archive-keyring/2023.02.01~deb11u1
dFYRvY26/6+Akz6lBZqWuce0kpUNvgNOyecSIo5ETo8hM9P -CIfd83AwX2F+DxVi6MBvEGJTff35AB/lBQ70y3gq0eOWQMLY3WrtS6dnAOio7Ni4 -eoO0ZUHZOppTDKd0CE7sTdn5hP9wvQ7K2oR0J//46I4+qJEWnzgptGDh50fsDIfI -pI++fsBsiCwUQol63ibe0xJZcvA9fr+utHOmVgmxh7jj+/2t2jbM/SQz0wnGq1bt -AGZugySOCSsIBCWdvQusvuPdN8tDrIVKUw2PyQT93ZWfBjCLRjgAgH/srGyVsIyt -dL5jt6XF7bu/DyXRHa4= -=Ec85 +AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEE0MmH177D7d+JSGzCtSPl8/xO +XywFAmPaBeYFCQPtZIcACgkQtSPl8/xOXywRLw//eb4iof+TvokwL7u37b/K4HVF +Lb+KGfcnBLBvPni+yeZCoy1JXsirTHBgKo9cYjEVVVUbqDQVgh9j+qCUq2Z8eCCm +r7Asqp+rX3fFs9+dMhlDJbKTVc59qRlKemeCnpz0tiaZedtWHW1Y3SY1eJDMrSPn +VqUTE+akGc6JghuDHQxPNYkuG/PmWzae0idF1rVF8DZY9j327DuGdlppQptmo2N3 +cuJzz6MPuMHLAd6UDwwb/7vCHcCtQBM8wOIgBTcNWO5MESs40dQPvPw+eF36w+m0 +QKLrmAIOAxUOcCpLl4ws0v63K0M6BIw+m0+KKtU0BE70yT/4xH77cFGq8MOEtVQa +RXEycW7rvFSaU/IfX27qoj/oMZkjtwTbRlECqWvbgmbJZwhpUqvJb8FLKqJlC7a+ +DMAhCTMjXzarxGfsqxc3+iuD4RP098h26nFCBZdeLbCbgyCZdu/X45EUw9ZOgjAS +2gcJNuCTuqwr7qw2Dwz9xWGvWlC+FotPQHK7K+xHBzum8PuZJC+e0gBmZxi0b8wv +f+qbDR5Y6f0rQvd4qZrQNs5nuHGKUhevbd+DdsfGLa6UAmD6x0YKlhFJK48KxWkZ +GUxYhlw1WaAsORJ9ld1uCaYS4Id4DhXQysV0rmjwElxUdSTkx9SfwA1XKACymveQ +DvWkU9uuQqWVoOfJEQyJAlQEEwEKAD4WIQTQyYfXvsPt34lIbMK1I+Xz/E5fLAUC +Yc3U3wIbAwUJAgtjgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRC1I+Xz/E5f +LCN2D/9zQ57i4qdy2dC8Xny/vA1DFBw/BuuDzTYl/pdyxb1Dp/kwVWty84kZdnnn +gmSSjef30WuqlhsEj2M+oMCF1IRzGz+O5eyYDi2rTM78gKWrH8ADp4b/5IgMCMtW +GeFAXqAYyXEf6or+z5eIFsUX/WLzCOcAUQ9bCDxuNmlnUr18pCeymBsdO28mHYkC ++tRYa+vOofVzWgbRKOuQm+GDwJE8ijOCh0cK02vfz5R5r6kkO07H6VUTK4bSMJkN +DykmSW2MRw3PZSWsEFQZj0CplkIFBKvGLCZ/J7qYzEXzWW3v878dawMwO4iIsO3n +hpTMYCt+jFvjlgSTPBbYEUCz2F/s6d394WHyzIKI9bIb791d0VhG9jbr/r4CTPqU +Fmpa5x7SSlQ2+A07J5xIijkROjyEz08Ih93zcDBfYX4PFWLowG8QYlN9/fkAH+UF +DvTLeCrR45ZAwtjdau1Lp2cA6Kjs2Lh6g7RlQdk6mlMMp3QITuxN2fmE/3C9Dsra +hHQn//jojj6okRafOCm0YOHnR+wMh8ikj75+wGyILBRCiXreJt7TElly8D1+v660 +c6ZWCbGHuOP7/a3aNsz9JDPTCcarVu0AZm6DJI4JKwgEJZ29C6y+4903y0OshUpT +DY/JBP3dlZ8GMItGOACAf+ysbJWwjK10vmO3pcXtu78PJdEdrg== +=PGIR -END PGP PUBLIC KEY BLOCK- diff -Nru debian-ports-archive-keyring-2022.02.15/active-keys/debian-ports-archive-2024.key debian-ports-archive-keyring-2023.02.01~deb11u1/active-keys/debian-ports-archive-2024.key --- debian-ports-archive-keyring-2022.02.15/active-keys/debian-ports-archive-2024.key 1970-01-01 01:00:00.0 +0100 +++ debian-ports-archive-keyring-2023.02.01~deb11u1/active-keys/debian-ports-archive-2024.key 2023-02-01 07:59:29.0 +0100 @@ -0,0 +1,30 @@ +-BEGIN PGP PUBLIC KEY BLOCK- + +mQINBGO5rVwBEADNxqEMv1Rvc8dS1cietFTGWb6mm6cdBQ2SdWfdqhbvcsaNZd4/ +ETttmcNHb8HOqk6bm9L7GNEDWMUTajIIZ8/x5RKqii23qKXf4EBxW0ZCpo70HqYs +JTZhmuFNIJgyWBaRd5279WP4skzkDH/iyhukzfZSYJseU3nt5KWaOJPnsk96whbv +sryuzC1+NNaYIS2WeAl5MEYRYmUAGOAwssfMkPYQF8k6WOVfz8oDwEJ5uVBiyMCw +KigrgDCr2YIpc1RLtkNItuF5bTuTMd+GBCDYMaqltrtYgsYrWRcOUcmHLVC3lD+O +Ja69noO+RXuxyp8Rd97p5tdjyPoQoGWA2qy1AoTuRnFyCA7ZzjtZvSgSeI2e+SBs +hl/vzqPwgS49tindtZA3gouHB8kHq9tdL2qc/0OHLJzRiS7asg2r5lp+igESMH/S +Kb76uwYSijPesn2ntnFtQnMl4P7NVHm7JiQ0XS/pUy/cTBDwyg8pzpQ0tCJg3FeU +q52nGGxqIOBO1/5U0ZGHLnlqPQ1Vx1YceXr2Gr2WgIT4U5jh9dwyuWytS6BhFYWB +CwdZBebrteREnxa7E1OB1r5KSZa/F/XQ/aX6DiwCXJ95BrN3/NVgeTeglGvpV7q5 +u/LeWvEBFgIOHwSMIo3sjaqFvJJRhnAd3LHBTwXVSLoxvPimKO4WzAXg3QARAQAB +tFVEZWJpYW4gUG9ydHMgQXJjaGl2ZSBBdXRvbWF0aWMgU2lnbmluZyBLZXkgKDIw +MjQpIDxmdHBtYXN0ZXJAcG9ydHMtbWFzdGVyLmRlYmlhbi5vcmc+iQJUBBMBCgA+ +AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEAcLW89GkatHA3C89jWlnRoi2 +yzYFAmPaBgcFCQPkESsACgkQjWlnRoi2yzZkeBAAn6HV2bzRRcM620Aa57CB1Wej +bpvgipuUZJqqn7IeCSgboCEVglpfnbOI5FmNWSNNTaJF2Rb9fG0a627tzE5mJat9 +14Mi+ZmYwtgoOJcLNcBAI7y187N6/FfMjpjQJDcwwaPaHngoNhqq59VQo0xxO5Y4 +AjkP+I7hMyI5PBv1fbjyzPsqqm8P5Vta9x47cp9tVXEM0mx0YwXHbRHMyJkZF3Mw +xqNW1dlLcOcjQad/koQHzGVGCMQ/4pfVZ0yQI8Iu+2YU3V2YBrNWQVDniPE0vbF+ +9s2Gw5YDWou8fYPC3oY4HJZxQ+3urEpZ4G07OKuwV+fpxo7+UxUiAD0DZ6Zv4Rhq +OJQE1GGpNf/8S9kEVXWH5Vah1kJk0Sd/s3ASxSfVDZxJAnncmVpj2jWKYxkmZUTA +PWaX1KO3o3HBWB2ydcY+9mQDRa+2DgN9crfuAF5BcYmGhvFpkrcOWDCrXqCIIfH/ +IrjEhxeB4hPJCiqXfV+ZUP6br7zbh+IgGEWhT1KBwxAz7evISYosLWrouZinIP7s +2choiV2bFdNzJ4P9MU7+9m2M6wH/VuzteR8x/Uj/vq1LRfzKecxcfXA7Gl1/91Zf +3zOZeVEtKgs44xX2AjfLKvLn7MN15Hyo4pvqXTxNva/jCzcenhDxWlhgbiAwwt3a +H71cHqY7HYYokB3agFU= +=FL2R +-END PGP PUBLIC KEY BLOCK- diff -Nru debian-ports-archive-keyring-2022.02.15/debian/changelog debian-ports-archive-keyring-2023.02.01~deb11u1/debian/changelog --- debian-ports-archive-keyring-2022.02.15/debian/changelog2022-02-15 13:04:48.0 +0100 +++ debian-ports-archive-keyring-2023.02.01~deb11u1/debian/changelog 2023-02-05 22:38:24.0 +0100 @@ -1,3 +1,28 @@ +debian-ports-archive-keyring (2023.02.01~deb11u1) bullseye; urgency=medium + + * Upload to bullseye. + + -- Aurelien Jarno Sun, 05 Feb 2023 22:38:24 +0100 + +debian-ports-archive-keyring (2023.02.01) unstable; urgency=high + + * Set the priority to high as it fixes issues already affected debian-ports. + * Move the 2022 key (ID: E852514F5DF312F6) to the removed keyring. + * Extend the 20
Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack
Hi, On 2023-01-16 13:26, Guillem Jover wrote: > Hi! > > On Mon, 2023-01-16 at 12:47:23 +0100, Axel Beckert wrote: > > Aurelien Jarno wrote: > > > On 2022-10-26 22:09, Aurelien Jarno wrote: > > > > Note that the other official architecture still have a kernel > > > > compatibility set to 3.2, so that will make a difference between > > > > architectures. There are discussions to increase it upstream, but this > > > > won't happened for bookworm. > > > > > > > > On 2022-10-25 21:07, Simon McVittie wrote: > > > > > Or, if the mips porters consider this backwards compatibility to be > > > > > more important than the security hardening of a non-executable stack, > > > > > then Lintian should stop issuing warnings about the executable stack > > > > > on > > > > > mips*el to improve its signal/noise ratio. > > > > > > > > At this stage there is nothing that can be done on the glibc side, the > > > > decision has to be taken by the mips porters. > > > > > > We are getting very close to the toolchain freeze. Any decision about > > > that? > > > > JFYI: There is the request to disable this tag completely on MIPS > > architectures in https://bugs.debian.org/1025436 > > > > Now I wonder if this would actually help or worsen the situation for > > the glibc maintainers. > > > > Guillem: You wrote something about "bullseye" in #1025436. I think you > > meant "bookworm" instead. Am I right? > > Indeed, sorry, I was going by Aurelien's comment, but botched the > release name. :) But in any case, I'll defer to whatever take Aurelien > or other glibc maintainers have on this. Given we got no decision from the MIPS porters before the toolchain freeze, we'll have to live with the executable stack on mips*el for bookworm. Therefore I believe it's a good idea to disable that tag on mips*el on the lintian side. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1028504: libc6: valgrind reports "Invalid read of size 8" deep in decompose_rpath in dl-load.c
control: reassign -1 valgrind control: affects -1 libc6 Hi, On 2023-01-12 10:15, Mike Hommey wrote: > Package: libc6 > Version: 2.36-8 > Severity: important > > STR: > - apt install firefox valgrind > - valgrind --show-mismatched-frees=no firefox > > valgrind will quickly show errors like: > ==6383== Invalid read of size 8 > ==6383==at 0x4023A34: strncmp (strcmp-sse2.S:162) Looking at the source code the code in the glibc is correct. It reads the data in chunk of 16-bytes, which indeed can go slightly over the allocated memory, but extra care is taken to not cross a cache line. The solution there is to add a suppression file to valgrind to ignore that. I am therefore reassigning the bug to the valgrind package. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#688318: tzdata packages updates consistently cause /etc/timezone to be reset to an undesirable value
On 2023-01-06 20:33, Benjamin Drung wrote: > On Fri, 21 Sep 2012 09:25:50 -0500 Shelby Cain > wrote: > > Package: tzdata > > Version: 2012e-0ubuntu0.12.04.1 > > Severity: important > > > > Every time an update to the tzdata package is published, it results in > my /etc/timezone being reset from > > "US/Central" to "America/Chicago". While technically America/Chicago > is indeed the same timezone, it is > > unintuitive to say the least considering the fact that I live 929 > miles (~1500 km) from Chicago, Illinois. > > There are symlinks in /usr/share/zoneinfo for backward compatibility. > US/Central is a symlink pointing to America/Chicago. > > The Debian package updates some of those backward compatible symlinks to > their new targets (see convert_timezone in debian/tzdata.config). This > is useful for changes like renaming Kiev to Kyiv. These timezones that > are updated are not presented as option in debconf – except for the > symlinks in US. This is inconsistent and needs to be fixed. > > So there are two possible solution: > > 1. Drop the US area from the debconf template. Then only continents and > oceans remain as areas. This would be more consistent. > > 2. Drop the US/* timezones from convert_timezone. > > It tend to prefer option one (for consistency), but I can see that users > might find option two easier for them. From a maintainer point of view (consistency), and also from a European point of view, the first option looks the best. But I think US users are used to timezones and not cities to select their timezones, so option 2 is probably the best here, even if considered as deprecated upstream. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters
Hi Axel,
On 2023-01-05 03:25, Axel Beckert wrote:
> Hi Aurelien,
>
> Axel Beckert wrote:
> > Aurelien Jarno wrote:
> > > An alternative is to not try to support all systems and reinvent the
> > > wheel, and instead assume a POSIX system.
> >
> > I'd say on Debian — independent of the actually used kernel — we can
> > do assume this at least.
> >
> > > That way the attached patch can be used.
> >
> > Nice patch! Thanks!
>
> Hrm, with that patch, autopkgtest fails the test case for #600246,
> i.e. it seems to reopen the infamous and seemingly non-trivial
> https://bugs.debian.org/600246 — not sure why though. (Wonder if
> Thorsten's patch works better for #600246 than the current one. Or
> maybe my way of testing is borked?)
It appear I tried to replace too much code with the glibc function,
only the wide array can be easily replaced by wcwidth. I have attached
an updated version of the patch. It appears to fix the reported bug and
still pass the autopkgtest.
Cheers
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--- screen-4.9.0.orig/encoding.c
+++ screen-4.9.0/encoding.c
@@ -22,6 +22,7 @@
*/
#include
+#include
#include "config.h"
#include "screen.h"
@@ -1145,127 +1146,10 @@ int c;
{0xF, 0xD},
{0x10, 0x10FFFD},
};
- /* A sorted list of intervals of double width characters generated by
- * https://github.com/GNOME/glib/blob/glib-2-50/glib/gen-unicode-tables.pl */
- static const struct interval wide[] = {
-{0x1100, 0x115F},
-{0x231A, 0x231B},
-{0x2329, 0x232A},
-{0x23E9, 0x23EC},
-{0x23F0, 0x23F0},
-{0x23F3, 0x23F3},
-{0x25FD, 0x25FE},
-{0x2614, 0x2615},
-{0x2648, 0x2653},
-{0x267F, 0x267F},
-{0x2693, 0x2693},
-{0x26A1, 0x26A1},
-{0x26AA, 0x26AB},
-{0x26BD, 0x26BE},
-{0x26C4, 0x26C5},
-{0x26CE, 0x26CE},
-{0x26D4, 0x26D4},
-{0x26EA, 0x26EA},
-{0x26F2, 0x26F3},
-{0x26F5, 0x26F5},
-{0x26FA, 0x26FA},
-{0x26FD, 0x26FD},
-{0x2705, 0x2705},
-{0x270A, 0x270B},
-{0x2728, 0x2728},
-{0x274C, 0x274C},
-{0x274E, 0x274E},
-{0x2753, 0x2755},
-{0x2757, 0x2757},
-{0x2795, 0x2797},
-{0x27B0, 0x27B0},
-{0x27BF, 0x27BF},
-{0x2B1B, 0x2B1C},
-{0x2B50, 0x2B50},
-{0x2B55, 0x2B55},
-{0x2E80, 0x2E99},
-{0x2E9B, 0x2EF3},
-{0x2F00, 0x2FD5},
-{0x2FF0, 0x2FFB},
-{0x3000, 0x303E},
-{0x3041, 0x3096},
-{0x3099, 0x30FF},
-{0x3105, 0x312F},
-{0x3131, 0x318E},
-{0x3190, 0x31BA},
-{0x31C0, 0x31E3},
-{0x31F0, 0x321E},
-{0x3220, 0x3247},
-{0x3250, 0x4DBF},
-{0x4E00, 0xA48C},
-{0xA490, 0xA4C6},
-{0xA960, 0xA97C},
-{0xAC00, 0xD7A3},
-{0xF900, 0xFAFF},
-{0xFE10, 0xFE19},
-{0xFE30, 0xFE52},
-{0xFE54, 0xFE66},
-{0xFE68, 0xFE6B},
-{0xFF01, 0xFF60},
-{0xFFE0, 0xFFE6},
-{0x16FE0, 0x16FE3},
-{0x17000, 0x187F7},
-{0x18800, 0x18AF2},
-{0x1B000, 0x1B11E},
-{0x1B150, 0x1B152},
-{0x1B164, 0x1B167},
-{0x1B170, 0x1B2FB},
-{0x1F004, 0x1F004},
-{0x1F0CF, 0x1F0CF},
-{0x1F18E, 0x1F18E},
-{0x1F191, 0x1F19A},
-{0x1F200, 0x1F202},
-{0x1F210, 0x1F23B},
-{0x1F240, 0x1F248},
-{0x1F250, 0x1F251},
-{0x1F260, 0x1F265},
-{0x1F300, 0x1F320},
-{0x1F32D, 0x1F335},
-{0x1F337, 0x1F37C},
-{0x1F37E, 0x1F393},
-{0x1F3A0, 0x1F3CA},
-{0x1F3CF, 0x1F3D3},
-{0x1F3E0, 0x1F3F0},
-{0x1F3F4, 0x1F3F4},
-{0x1F3F8, 0x1F43E},
-{0x1F440, 0x1F440},
-{0x1F442, 0x1F4FC},
-{0x1F4FF, 0x1F53D},
-{0x1F54B, 0x1F54E},
-{0x1F550, 0x1F567},
-{0x1F57A, 0x1F57A},
-{0x1F595, 0x1F596},
-{0x1F5A4, 0x1F5A4},
-{0x1F5FB, 0x1F64F},
-{0x1F680, 0x1F6C5},
-{0x1F6CC, 0x1F6CC},
-{0x1F6D0, 0x1F6D2},
-{0x1F6D5, 0x1F6D5},
-{0x1F6EB, 0x1F6EC},
-{0x1F6F4, 0x1F6FA},
-{0x1F7E0, 0x1F7EB},
-{0x1F90D, 0x1F971},
-{0x1F973, 0x1F976},
-{0x1F97A, 0x1F9A2},
-{0x1F9A5, 0x1F9AA},
-{0x1F9AE, 0x1F9CA},
-{0x1F9CD, 0x1F9FF},
-{0x1FA70, 0x1FA73},
-{0x1FA78, 0x1FA7A},
-{0x1FA80, 0x1FA82},
-{0x1FA90, 0x1FA95},
-{0x2, 0x2FFFD},
-{0x3, 0x3FFFD},
- };
if (c >= 0xdf00 && c <= 0xdfff)
return 1; /* dw combining sequence */
- return ((bisearch(c, wide, sizeof(wide) / sizeof(struct interval) - 1)) ||
+ return ((wcwidth(c) == 2) ||
(cjkwidth &&
bisearch(c, ambiguous,
sizeof(ambiguous) / sizeof(struct interval) - 1)));
Bug#1027789: libc-bin: zic should not be installed in /sbin/
Hi, On 2023-01-03 12:18, Jérémy Lal wrote: > Package: libc-bin > Version: 2.36-7 > Severity: normal > > It seems very odd that zic is installed in /sbin/zic. Could you please elaborate? zic is primarily used for administration tasks and requires write access to /usr/share/zoneinfo in its default invocation. Also please note that the debian package uses the same path than upstream (as in glibc, tzdata, Linux man-pages), and matches what is done on other SysV or BSD systems. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters
control: reassign -1 screen
control: retitle -1 GNU Screen does not support Unicode 14
control: affects -1 libc6
Hi,
On 2023-01-03 02:28, Vincent Lefevre wrote:
> On 2023-01-02 23:08:39 +0100, Aurelien Jarno wrote:
> > This U+1FAF6 character is new in Unicode 14, which is supported starting
> > with glibc 2.35. Older glibc does not know about this character, causing
> > mutt to display it with '?'. With newer glibc mutt displays the
> > character.
> >
> > Now I am not sure it is a bug in glibc, it rather seems an issue with
> > screen. I can reproduce the shifts in both, stable and unstable, by
> > putting this char in a file and just running cat on the file.
>
> I've look at the "screen" code, and it has a file encoding.c with
> some kind of table (intervals) of double-width characters, and it
> gives the URL of a script to regenerate these tables.
>
> Since these tables depend on the Unicode version (which depends on
> the libc6 version), shouldn't the screen package have a versioned
> dependency on libc6?
Do you mean having a strict dependency on the major glibc version? That
sounds like an additional pain for new glibc releases, given how GNU
screen is developed upstream. And screen has an udeb, so it's not easy
to remove it from testing if it gets in the way.
An alternative is to not try to support all systems and reinvent the
wheel, and instead assume a POSIX system. That way the attached patch
can be used.
In any case this doesn't seem to me a glibc issue, I am therefore
reassigning the bug to the screen package.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--- screen-4.9.0.orig/encoding.c
+++ screen-4.9.0/encoding.c
@@ -22,6 +22,7 @@
*/
#include
+#include
#include "config.h"
#include "screen.h"
@@ -962,313 +963,7 @@ int
utf8_isdouble(c)
int c;
{
- /* A sorted list of intervals of ambiguous width characters generated by
- * https://github.com/GNOME/glib/blob/glib-2-50/glib/gen-unicode-tables.pl */
- static const struct interval ambiguous[] = {
-{0x00A1, 0x00A1},
-{0x00A4, 0x00A4},
-{0x00A7, 0x00A8},
-{0x00AA, 0x00AA},
-{0x00AD, 0x00AE},
-{0x00B0, 0x00B4},
-{0x00B6, 0x00BA},
-{0x00BC, 0x00BF},
-{0x00C6, 0x00C6},
-{0x00D0, 0x00D0},
-{0x00D7, 0x00D8},
-{0x00DE, 0x00E1},
-{0x00E6, 0x00E6},
-{0x00E8, 0x00EA},
-{0x00EC, 0x00ED},
-{0x00F0, 0x00F0},
-{0x00F2, 0x00F3},
-{0x00F7, 0x00FA},
-{0x00FC, 0x00FC},
-{0x00FE, 0x00FE},
-{0x0101, 0x0101},
-{0x0111, 0x0111},
-{0x0113, 0x0113},
-{0x011B, 0x011B},
-{0x0126, 0x0127},
-{0x012B, 0x012B},
-{0x0131, 0x0133},
-{0x0138, 0x0138},
-{0x013F, 0x0142},
-{0x0144, 0x0144},
-{0x0148, 0x014B},
-{0x014D, 0x014D},
-{0x0152, 0x0153},
-{0x0166, 0x0167},
-{0x016B, 0x016B},
-{0x01CE, 0x01CE},
-{0x01D0, 0x01D0},
-{0x01D2, 0x01D2},
-{0x01D4, 0x01D4},
-{0x01D6, 0x01D6},
-{0x01D8, 0x01D8},
-{0x01DA, 0x01DA},
-{0x01DC, 0x01DC},
-{0x0251, 0x0251},
-{0x0261, 0x0261},
-{0x02C4, 0x02C4},
-{0x02C7, 0x02C7},
-{0x02C9, 0x02CB},
-{0x02CD, 0x02CD},
-{0x02D0, 0x02D0},
-{0x02D8, 0x02DB},
-{0x02DD, 0x02DD},
-{0x02DF, 0x02DF},
-{0x0300, 0x036F},
-{0x0391, 0x03A1},
-{0x03A3, 0x03A9},
-{0x03B1, 0x03C1},
-{0x03C3, 0x03C9},
-{0x0401, 0x0401},
-{0x0410, 0x044F},
-{0x0451, 0x0451},
-{0x2010, 0x2010},
-{0x2013, 0x2016},
-{0x2018, 0x2019},
-{0x201C, 0x201D},
-{0x2020, 0x2022},
-{0x2024, 0x2027},
-{0x2030, 0x2030},
-{0x2032, 0x2033},
-{0x2035, 0x2035},
-{0x203B, 0x203B},
-{0x203E, 0x203E},
-{0x2074, 0x2074},
-{0x207F, 0x207F},
-{0x2081, 0x2084},
-{0x20AC, 0x20AC},
-{0x2103, 0x2103},
-{0x2105, 0x2105},
-{0x2109, 0x2109},
-{0x2113, 0x2113},
-{0x2116, 0x2116},
-{0x2121, 0x2122},
-{0x2126, 0x2126},
-{0x212B, 0x212B},
-{0x2153, 0x2154},
-{0x215B, 0x215E},
-{0x2160, 0x216B},
-{0x2170, 0x2179},
-{0x2189, 0x2189},
-{0x2190, 0x2199},
-{0x21B8, 0x21B9},
-{0x21D2, 0x21D2},
-{0x21D4, 0x21D4},
-{0x21E7, 0x21E7},
-{0x2200, 0x2200},
-{0x2202, 0x2203},
-{0x2207, 0x2208},
-{0x220B, 0x220B},
-{0x220F, 0x220F},
-{0x2211, 0x2211},
-{0x2215, 0x2215},
-{0x221A, 0x221A},
-{0x221D, 0x2220},
-{0x2223, 0x2223},
-{0x2225, 0x2225},
-{0x2227, 0x222C},
-{0x222E, 0x222E},
-{0x2234, 0x2237},
-{0x223C, 0x223D},
-{0x2248, 0x2248},
-{0x224C, 0x224C},
-{0x2252, 0x2252},
-{0x2260, 0x2261},
-{0x2264, 0x2267},
-{0x226A, 0x226B},
-{0x226E, 0x226F},
-{0x2282, 0x2283},
-{0x2286, 0x2287},
-{0x2295, 0x2295},
-{0x2299, 0x2299},
-{0x22A5, 0x22A5},
Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters
Hi, On 2023-01-02 16:34, Vincent Lefevre wrote: > Package: libc6 > Version: 2.36-7 > Severity: serious > > The new libc6 appears to have some change related to Unicode that > yields display issues in screen 4.9.0-3, such as horizontal and/or > vertical text shifting. A consequence of this text shifting is that > in Mutt (in particular with arrow_cursor), one may select a message > to be deleted, but a different message is actually deleted. > > There is no such issue under bullseye (Debian 11.6), which also has > GNU Screen 4.09.00, so the breakage appears to be due to libc6. > > If the change has been done on purpose, then there are missing > dependency relationships that should prevent the installation > of incompatible software until such software has been updated > to support this change. > > Example to reproduce the issue with the U+1FAF6 HEART HANDS character > under Debian/unstable: This U+1FAF6 character is new in Unicode 14, which is supported starting with glibc 2.35. Older glibc does not know about this character, causing mutt to display it with '?'. With newer glibc mutt displays the character. Now I am not sure it is a bug in glibc, it rather seems an issue with screen. I can reproduce the shifts in both, stable and unstable, by putting this char in a file and just running cat on the file. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack
Hi, On 2022-10-26 22:09, Aurelien Jarno wrote: > control: tag -1 + moreinfo > > Hi, > > On 2022-10-25 21:07, Simon McVittie wrote: > > Package: libc6-dev > > Version: 2.35-4 > > Severity: normal > > X-Debbugs-Cc: debian-m...@lists.debian.org, lint...@packages.debian.org, > > jrt...@debian.org > > User: debian-m...@lists.debian.org > > Usertags: mips mipsel > > > > All mips*el executables and libraries appear to have an executable stack, > > resulting in very large numbers of Lintian warnings, particularly for > > packages with many small ELF objects like > > <https://udd.debian.org/lintian/?packages=samba>. > > > > Jessica Clarke looked into this and found that this is intentionally done > > by glibc when targeting minimum kernel 4.8.0 or older with mips hardfloat: > > https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270ed30fdbae9ad25426/sysdeps/unix/sysv/linux/mips/configure.ac#L138-L143 > > > > Debian 9 had a kernel newer than 4.8.0, so I think Debian 12 probably > > doesn't need to go that far into backwards compatibility? If the mips > > porters agree, then glibc on mips*el should stop forcing an executable > > stack, either by increasing the minimal kernel version or by patching > > this out. That will provide some security hardening on mips*el. > > Note that the other official architecture still have a kernel > compatibility set to 3.2, so that will make a difference between > architectures. There are discussions to increase it upstream, but this > won't happened for bookworm. > > > Or, if the mips porters consider this backwards compatibility to be > > more important than the security hardening of a non-executable stack, > > then Lintian should stop issuing warnings about the executable stack on > > mips*el to improve its signal/noise ratio. > > At this stage there is nothing that can be done on the glibc side, the > decision has to be taken by the mips porters. We are getting very close to the toolchain freeze. Any decision about that? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1026962: openjfx: tries to build with -j64 on a host with 2 processors
Source: openjfx Version: 11.0.11+0-1.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) openjfx tries to build with -j64 on zani.debian.org, which only has 2 processors and 8GB of RAM: buildd 3853047 0.0 0.0 67668 4 ?S11:07 0:00 cmake --build /build/openjfx-fzmlCD/openjfx-11.0.11+1/modules/javafx.web/build/linux/Release --config Release -- -j64 buildd 3853048 0.0 0.0 3200 272 ?S11:07 0:00 /usr/bin/gmake -f Makefile -j64 This hogs the buildd resources and we had to kill the build.
Bug#1026253: transition: cfitsio
Hi Sebastian, On 2022-12-17 14:43, Sebastian Ramacher wrote: > Control: tags -1 confirmed > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-cfitsio.html > > Hi Aurelien > > On 2022-12-17 12:52:27 +0100, Aurelien Jarno wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: debian-astro-maintain...@lists.alioth.debian.org > > > > Dear release team, > > > > I would like to request a transition slot for cfitsio, changing the > > library name from libcfitsio9 to libcfitsio10. The change has been > > introduced in version 4.2.0-1 which in experimental for 2 weeks and has > > been built on all release architectures and most debian-ports > > architectures. > > > > I have locally rebuilt all the reversed dependencies on amd64, and found > > only 2 FTBFS: > > > > - tcl-fitstcl (#1026237) > > => this is fixed in experimental, it just need to be uploaded to sid > > in sync with cfitsio > > > > - purify (#1001528) > > => this package is in sid only > > > > There is already a tracker available here: > > > > https://release.debian.org/transitions/html/auto-cfitsio.html > > > > Thanks for considering. > > Please go ahead. Thanks for the fast answer. I have just uploaded it. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1026253: transition: cfitsio
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-astro-maintain...@lists.alioth.debian.org Dear release team, I would like to request a transition slot for cfitsio, changing the library name from libcfitsio9 to libcfitsio10. The change has been introduced in version 4.2.0-1 which in experimental for 2 weeks and has been built on all release architectures and most debian-ports architectures. I have locally rebuilt all the reversed dependencies on amd64, and found only 2 FTBFS: - tcl-fitstcl (#1026237) => this is fixed in experimental, it just need to be uploaded to sid in sync with cfitsio - purify (#1001528) => this package is in sid only There is already a tracker available here: https://release.debian.org/transitions/html/auto-cfitsio.html Thanks for considering. Regards Aurelien
Bug#1026237: tcl-fitstcl: FTBFS with cfitsio 4.2.0 / new upstream version 2.5
Source: tcl-fitstcl
Version: 2.4-4
Severity: important
Tags: ftbfs patch upstream
Hi Ole,
A new version of cfitsio has been released recently, and it fixes a few
security issues, but it also includes a soname change, meaning we have
to do a transition. I would like to try to get it into bookworm. So far
the version 4.2.0 is already in experimental.
I have tried to rebuild all the reverse dependencies and it appears that
unfortunately tcl-fitstcl fails to build against it. It is not fully
surprising, given it accesses internal cfitsio structures. However NASA
just released version 2.5 [1] which adds support for cfitsio 4.2.0 (but
removes support for older versions). The debian package also need some
changes to make it working, I have attached the debdiff I ended up with.
Would it be possible to upload this new version to experimental asap,
and if we can still get a transition slot, synchronize the upload to
unstable with cfitsio?
Thanks,
Aurelien
[1]
https://heasarc.gsfc.nasa.gov/docs/software/lheasoft/ftools/fv/fitsTcl_home.html
diff -Nru tcl-fitstcl-2.4/debian/control tcl-fitstcl-2.5/debian/control
--- tcl-fitstcl-2.4/debian/control 2019-02-28 21:06:35.0 +
+++ tcl-fitstcl-2.5/debian/control 2022-12-16 21:17:19.0 +
@@ -5,7 +5,7 @@
Uploaders: Ole Streicher
Build-Depends: debhelper (>= 12),
dh-autoreconf,
- libcfitsio-dev | libcfitsio3-dev,
+ libcfitsio-dev (>= 4.2.0),
tcl-dev,
wcslib-dev
Standards-Version: 4.3.0
diff -Nru
tcl-fitstcl-2.4/debian/patches/Propagate-CPPFLAGS-and-LDFLAGS-for-hardening.patch
tcl-fitstcl-2.5/debian/patches/Propagate-CPPFLAGS-and-LDFLAGS-for-hardening.patch
---
tcl-fitstcl-2.4/debian/patches/Propagate-CPPFLAGS-and-LDFLAGS-for-hardening.patch
2019-02-28 21:03:49.0 +
+++
tcl-fitstcl-2.5/debian/patches/Propagate-CPPFLAGS-and-LDFLAGS-for-hardening.patch
2022-12-16 21:17:19.0 +
@@ -19,7 +19,7 @@
+ ${CC} -c -o ${
+#include
+#include
@@ -134,15 +134,19 @@
+#endif
+#include "fitsio2.h"
+
-+#ifndef FFBISON
-+#include "eval_tab.h"
-+#endif
-+
+#define MAXDIMS 5
+#define MAXSUBS 10
+#define MAXVARNAME 80
+#define CONST_OP -1000
+#define pERROR -1
++#define MAX_STRLEN 256
++#define MAX_STRLEN_S "255"
++
++typedef struct ParseData_struct ParseData;
++typedef void* yyscan_t;
++#ifndef FFBISON
++#include "eval_tab.h"
++#endif
+
+
+typedef struct {
@@ -164,7 +168,7 @@
+ double dbl;
+ long lng;
+ char log;
-+ char str[256];
++ char str[MAX_STRLEN];
+ double *dblptr;
+ long *lngptr;
+ char *logptr;
@@ -175,17 +179,17 @@
+
+typedef struct Node {
+ intoperation;
-+ void (*DoOp)(struct Node *this);
++void (*DoOp)(ParseData *, struct Node *this);
+ intnSubNodes;
+ intSubNodes[MAXSUBS];
+ inttype;
+ lval value;
+} Node;
+
-+typedef struct {
++struct ParseData_struct {
+ fitsfile*def_fptr;
-+ int (*getData)( char *dataName, void *dataValue );
-+ int (*loadData)( int varNum, long fRow, long nRows,
++int (*getData)( ParseData *, char *dataName, void
*dataValue );
++int (*loadData)( ParseData *, int varNum, long fRow,
long nRows,
+ void *data, char *undef );
+
+ int compressed;
@@ -201,11 +205,14 @@
+ int nNodes;
+ int nNodesAlloc;
+ int resultNode;
-+
++
+ longfirstRow;
+ longnRows;
+
+ int nCols;
++ long nElements;
++ int nAxis;
++ longnAxes[MAXDIMS];
+ iteratorCol *colData;
+ DataInfo*varData;
+ PixelFilter *pixFilter;
@@ -213,12 +220,13 @@
+ longfirstDataRow;
+ longnDataRows;
+ longtotalRows;
++ longnPrevDataRows;
+
+ int datatype;
+ int hdutype;
+
+ int status;
-+} ParseData;
++};
+
+typedef enum {
+ rnd_fct = 1001,
@@ -263,68 +271,196 @@
+nonnull_fct,
+angsep_fct,
+gasrnd_fct,
-+poirnd_fct
++poirnd_fct,
++
Bug#1026110: xournal: FTBFS: Makefile:263: *** missing separator. Stop.
Package: xournal Version: 1:0.4.8.2016-7+b1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer(s), Your package fails to build with: |dh_auto_build | make -j8 | make[1]: Entering directory '/build/1st/xournal-0.4.8.2016' | Makefile:263: *** missing separator. Stop. | make[1]: Leaving directory '/build/1st/xournal-0.4.8.2016' | dh_auto_build: error: make -j8 returned exit code 2 | make: *** [debian/rules:6: binary] Error 25 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 The full build log is available from: https://buildd.debian.org/status/fetch.php?pkg=xournal=riscv64=1%3A0.4.8.2016-7%2Bb2=1671008048=0 https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/xournal_0.4.8.2016-7.rbuild.log.gz Regards Aurelien
Bug#1026058: rust-xmlparser: FTBFS: src/lib.rs - map_err_at (line 396)
Source: rust-xmlparser Version: 0.11.0-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, Your package fails to build with: | running 6 tests | test src/lib.rs - map_err_at (line 396) - compile ... FAILED | test src/stream.rs - stream::Stream::consume_byte (line 181) ... ok | test src/stream.rs - stream::Stream::advance (line 140) ... ok | test src/lib.rs - (line 7) ... ok | test src/stream.rs - stream::Stream::gen_text_pos_from (line 313) ... ok | test src/stream.rs - stream::Stream::starts_with (line 159) ... ok | | failures: | | src/lib.rs - map_err_at (line 396) stdout | error[E0433]: failed to resolve: use of undeclared type `Token` | --> src/lib.rs:399:25 | | | 5 | Error::InvalidToken(Token::SomeToken, stream.gen_error_pos_from(start), Some(e)) | | ^ use of undeclared type `Token` | | error[E0425]: cannot find value `stream` in this scope | --> src/lib.rs:397:13 | | | 3 | let start = stream.pos() - 2; // or any other number | | ^^ not found in this scope | | error[E0425]: cannot find function `some_func` in this scope | --> src/lib.rs:398:1 | | | 4 | some_func().map_err(|e| | | ^ not found in this scope | | error[E0433]: failed to resolve: use of undeclared type `Error` | --> src/lib.rs:399:5 | | | 5 | Error::InvalidToken(Token::SomeToken, stream.gen_error_pos_from(start), Some(e)) | | ^ not found in this scope | | | help: consider importing one of these items | | | 2 | use std::error::Error; | | | 2 | use std::fmt::Error; | | | 2 | use std::io::Error; | | | | error[E0425]: cannot find value `stream` in this scope | --> src/lib.rs:399:43 | | | 5 | Error::InvalidToken(Token::SomeToken, stream.gen_error_pos_from(start), Some(e)) | | ^^ not found in this scope | | error: aborting due to 5 previous errors | | Some errors have detailed explanations: E0425, E0433. | For more information about an error, try `rustc --explain E0425`. | Couldn't compile the test. | | failures: | src/lib.rs - map_err_at (line 396) | | test result: FAILED. 5 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 8.96s The full build log is available from: https://buildd.debian.org/status/fetch.php?pkg=rust-xmlparser=riscv64=0.11.0-1%2Bb1=1670942978=0 https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/rust-xmlparser_0.11.0-1.rbuild.log.gz Regards Aurelien
Bug#1025986: FTBFS: install: cannot change owner and permissions of ‘/<>/debian/.debhelper/generated/_source/home’: Operation not permitted
Source: runawk Version: 1.6.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, Your package fails to build with: | dh build-arch --buildsystem=mkcmake | dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) |dh_update_autotools_config -a -O--buildsystem=mkcmake |dh_auto_configure -a -O--buildsystem=mkcmake | dh_auto_configure: warning: Compatibility levels before 10 are deprecated (level 9 in use) | install: cannot change owner and permissions of ‘/<>/debian/.debhelper/generated/_source/home’: Operation not permitted | dh_auto_configure: error: install -m0755 -o 0 -g 0 -d /<>/debian/.debhelper/generated/_source/home returned exit code 1 | make: *** [debian/rules:6: build-arch] Error 25 | dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 The full build log is available from: https://buildd.debian.org/status/fetch.php?pkg=runawk=riscv64=1.6.0-2%2Bb1=1670843999=0 https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/runawk_1.6.0-2.rbuild.log.gz Regards Aurelien
Bug#1025985: glosstext: FTBFS: LaTeX Error: File `pdftexcmds.sty' not found.
Source: glosstex
Version: 0.4.dfsg.1-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi,
Your package fails to build with:
|Writing index file glosstex.idx
|(/usr/share/texlive/texmf-dist/tex/latex/hypdoc/hypdoc.sty
|(/usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty)
|(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
|(/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty)
|(/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty)
|
|! LaTeX Error: File `pdftexcmds.sty' not found.
|
|Type X to quit or to proceed,
|or enter new name. (Default extension: sty)
|
|Enter file name:
|! Emergency stop.
|
|
|l.111 \RequirePackage{pdftexcmds}[2018/09/10]
| ^^M
|No pages of output.
|Transcript written on glosstex.log.
|make[1]: *** [Makefile:83: glosstex.dvi] Error 1
|make[1]: Leaving directory '/<>'
|make: *** [debian/rules:12: install/glosstex] Error 2
|dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess
returned exit status 2
The full build log is available from:
https://buildd.debian.org/status/fetch.php?pkg=glosstex=riscv64=0.4.dfsg.1-4%2Bb1=1670830203=0
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/glosstex_0.4.dfsg.1-4.rbuild.log.gz
Regards
Aurelien
Bug#1025324: libc6: Xserver with nouveau not workiing.
control: reassign -1 libgl1-mesa-dri control: forcemerge 1025312 -1 control: affects 1025312 src:glibc Hi, On 2022-12-03 07:25, Agustin Martin wrote: > Hi all, > > Also hit by this problem (intel i5 box). > > Noticed that Xorg log showing the error is very similar to what is seen in > > #1025312 [libgl1-mesa-dri: multiple packages FTBFS and have > autopkgtest regressions running test programs under Xvfb] Thanks for the pointer, it indeed looks the real issue. Basically mesa calls dlclose(NULL), that's why libc6 appears in the backtrace. I am therefore reassigning the bug. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1025341: rust-lalrpop: flaky autopkgtest on s390x
Source: rust-lalrpop Version: 0.19.8-3 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of rust-lalrpop as it was blocking glibc. I noticed that it sometimes fails on s390x with the following error: thread 'lr1::build::test::expr_grammar1' has overflowed its stack fatal runtime error: stack overflow error: test failed, to rerun pass '--lib' Caused by: process didn't exit successfully: `/tmp/tmp.ylFj0b7NXt/target/s390x-unknown-linux-gnu/debug/deps/lalrpop-d02d6930d272c3cf` (signal: 6, SIGABRT: process abort signal) autopkgtest [23:12:06]: test librust-lalrpop-dev:lexer: ---] autopkgtest [23:12:06]: test librust-lalrpop-dev:lexer: - - - - - - - - - - results - - - - - - - - - - librust-lalrpop-dev:lexer FAIL non-zero exit status 101 See the logs of failed and successful runs: https://ci.debian.net/data/autopkgtest/testing/s390x/r/rust-lalrpop/28902703/log.gz https://ci.debian.net/data/autopkgtest/testing/s390x/r/rust-lalrpop/28902705/log.gz Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Regards Aurelien
Bug#1025324: libc6: Xserver with nouveau not workiing.
Hi, On 2022-12-02 16:07, Santiago José López Borrazás wrote: > Package: libc6 > Version: 2.36-6 > Severity: normal > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > It crashes only when I restart the graphical environment and gives me errors > on several sides when I have the module. I am loading through the generic > graphics card module. > > The failure is the following when booting Xorg. Attached is the Xorg file, > where the libc6 bug is specified. The fact that libc6 is mentioned might be normal, if some functions get passed wrong pointer values, they will crash. > In the previous version of libc6 it didn't crash for a moment. It is only in > the new version of libc6. Can you please give more details, especially which previous version of libc6 were you using? Also can you please try to downgrade your system to this version to confirm that the issue is linked to libc6? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1024130: glibc: discuss libutil and libanl libraries for loongarch
Hi, On 2022-11-15 16:23, 张丹丹 wrote: > Package: glibc > Version: 2.36-4 > Severity: wishlist > Tags: ftbfs patch > User: debian-de...@lists.debian.org > Usertags: loongarch64 > > Dear maintainer(s), > > I'm attaching a patch (only to provide the basis for this discussion) as a > discussion point. > Reference to other architectures such as amd64, arm64 and riscv64, we want to > be consistent with the Debian community's handling of libanl and libutil > libraries,meanwhile follow the rules of glibc upstream. Thanks for reaching the glibc team. Loongarch is one of the recently added architecture upstream, and indeed required some adaptation on the debian side. > - Loongarch want to use the default libc-dev.install and libc-udeb.install > processing methods in glibc package. > loongson@loongson-pc:zdd/glibc-2.36/debian/debhelper.in$ pwd > /home/loongson/glibc-2.36/debian/debhelper.in > loongson@loongson-pc:zdd/glibc-2.36/debian/debhelper.in$ ls libc-udeb.install > libc-dev.install > libc-dev.install libc-udeb.install The libc-udeb.install change should be fixed in git already, given we don't need libutil.so.1 in the udeb file anymore (all packages using it have been rebuilt), I have committed some changes to remove it. > - Loongarch want to be consistent with the debian community. > Glibc upstream processes all architectures libanl and libutil in the same way. > However, libutil and libanl are provided for other architectures in the > debian glibc package. > I survey from the file of > glibc-2.36/debian/debhelper.in/libc-dev-alt.lintian-overrides,such as: > # All functionality formerly implemented in the libraries libpthread, > # libdl, libutil, libanl has been integrated into libc. For backwards > # compatibility, empty static archives libpthread.a, libdl.a, libutil.a, > # libanl.a are provided, so that the linker options keep working. For libanl.a, I see two options that do not require to patch the upstream code: - Creating the empty libanl.a in the debian/rules.d/build.mk like it is already done for libpthread_nonshared.a. This ensure some portability for building packages that explicitly link with -lanl. I have no idea if there are a lot or not. - Patching providing a loong64 specific file for libc-dev, just like you did in the attached patch. Both options look fine for me, I don't really have a preference here. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1024474: pacman-package-manager_6.0.2-2_mips64el-buildd.changes REJECTED
Source: pacman-package-manager Version: 6.0.2-2 Severity: serious On 2022-11-20 00:06, Debian FTP Masters wrote: > Version check failed: > Your upload included the binary package libalpm-dev, version 13.0.2-1, for > mips64el, > however testing already has version 13.0.2-1. > Uploads to unstable must have a higher version than present in testing. > > Mapping sid to unstable. > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > >
Bug#1023870: dpkg: Problems in buildds due to slow compression
Hi Guillem, On 2022-11-13 11:04, Aurelien Jarno wrote: > Hi, > > On 2022-11-13 02:00, Guillem Jover wrote: > > Hi! > > > > On Sun, 2022-11-13 at 00:17:36 +0100, Aurelien Jarno wrote: > > > On 2022-11-12 22:28, Guillem Jover wrote: > > > > On Fri, 2022-11-11 at 19:15:59 +0100, Manuel A. Fernandez Montecelo > > > > wrote: > > > > > Package: dpkg > > > > > Version: 1.21.9 > > > > > Severity: normal > > > > > X-Debbugs-Cc: m...@debian.org, debian-wb-t...@lists.debian.org > > > > > > > > > After some investigation by aurel32 and myself, this was traced back > > > > > to the > > > > > commit f8d254943051e085040367d689048c00f31514c3 [2], in which the > > > > > calculation of > > > > > the memory that can be used, to determine the number of threads to > > > > > use, was > > > > > changed from half of the physical mem to be based on the memory > > > > > available. > > > > > > > > Ah, thanks for tracking this down! I think the problem is the usual > > > > "available" memory does not really mean what people think it means. :/ > > > > And I unfortunately missed that (even thought I was aware of it) when > > > > reviewing the patch. > > > > > > > > Attached is something I just quickly prepared, which I'll clean up and > > > > merge for the upcoming 1.21.10. Let me know if that solves the issue > > > > for you, otherwise we'd need to look for further changes. > > > > > > Thanks for providing a patch. I have not been able yet to try it for the > > > case where we have found the issue, i.e. building linux. However I have > > > tried to setup a similar environment: > > > > > - I took a just booted VM with 4 GB RAM, 4 GB swap and 4 GB tmpfs, and > > > very few > > > things running on it. > > > - I filled the tmpfs with 4 GB of random data, which means that after > > > moving the content of the tmpfs to the swap, 4 GB could still be used > > > without issue. > > > - I ended up with the following /proc/meminfo: > > > MemTotal:3951508 kB > > > MemFree: 130976 kB > > > MemAvailable: 10584 kB > > > Buffers:2448 kB > > > Cached: 3694676 kB > > > SwapCached:12936 kB > > > Active: 3111920 kB > > > Inactive: 610376 kB > > > Active(anon):3102668 kB > > > Inactive(anon): 606952 kB > > > Active(file): 9252 kB > > > Inactive(file): 3424 kB > > > Unevictable: 0 kB > > > Mlocked: 0 kB > > > SwapTotal: 4194300 kB > > > SwapFree:3777400 kB > > > Zswap: 0 kB > > > Zswapped: 0 kB > > > Dirty: 0 kB > > > Writeback: 0 kB > > > AnonPages: 12960 kB > > > Mapped: 6700 kB > > > Shmem: 3684416 kB > > > KReclaimable: 27616 kB > > > Slab: 54652 kB > > > SReclaimable: 27616 kB > > > SUnreclaim:27036 kB > > > KernelStack:2496 kB > > > PageTables: 1516 kB > > > NFS_Unstable: 0 kB > > > Bounce:0 kB > > > WritebackTmp: 0 kB > > > CommitLimit: 6170052 kB > > > Committed_AS:4212940 kB > > > VmallocTotal: 34359738367 kB > > > VmallocUsed: 16116 kB > > > VmallocChunk: 0 kB > > > Percpu: 2288 kB > > > HardwareCorrupted: 0 kB > > > AnonHugePages: 0 kB > > > ShmemHugePages:0 kB > > > ShmemPmdMapped:0 kB > > > FileHugePages: 0 kB > > > FilePmdMapped: 0 kB > > > HugePages_Total: 0 > > > HugePages_Free:0 > > > HugePages_Rsvd:0 > > > HugePages_Surp:0 > > > Hugepagesize: 2048 kB > > > Hugetlb: 0 kB > > > DirectMap4k: 110452 kB > > > DirectMap2M: 5132288 kB > > > DirectMap1G: 5242880 kB > > > > > With the current version of dpkg, it means it consider 10584 kB are > > > available > > > (not however that there is 130976 kB of unused physical RAM). With your > > > patch, > > > it's a bit better, as it would be 123408 kB. Still far less that one the > > > VM is > > > capable of. > > > > Err sorry, the patch was computing the used memory and not the truly > > available one! The updated patch should do better. :) > > Thanks for the updated patch. Computing the available memory manually > from the above values sounds like it should work, so I'll give it a try. I have run a build of the linux package on a buildd with your patch, and I confirm it fixes the issue. Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1023870: dpkg: Problems in buildds due to slow compression
Hi, On 2022-11-13 02:00, Guillem Jover wrote: > Hi! > > On Sun, 2022-11-13 at 00:17:36 +0100, Aurelien Jarno wrote: > > On 2022-11-12 22:28, Guillem Jover wrote: > > > On Fri, 2022-11-11 at 19:15:59 +0100, Manuel A. Fernandez Montecelo wrote: > > > > Package: dpkg > > > > Version: 1.21.9 > > > > Severity: normal > > > > X-Debbugs-Cc: m...@debian.org, debian-wb-t...@lists.debian.org > > > > > > > After some investigation by aurel32 and myself, this was traced back to > > > > the > > > > commit f8d254943051e085040367d689048c00f31514c3 [2], in which the > > > > calculation of > > > > the memory that can be used, to determine the number of threads to use, > > > > was > > > > changed from half of the physical mem to be based on the memory > > > > available. > > > > > > Ah, thanks for tracking this down! I think the problem is the usual > > > "available" memory does not really mean what people think it means. :/ > > > And I unfortunately missed that (even thought I was aware of it) when > > > reviewing the patch. > > > > > > Attached is something I just quickly prepared, which I'll clean up and > > > merge for the upcoming 1.21.10. Let me know if that solves the issue > > > for you, otherwise we'd need to look for further changes. > > > > Thanks for providing a patch. I have not been able yet to try it for the > > case where we have found the issue, i.e. building linux. However I have > > tried to setup a similar environment: > > > - I took a just booted VM with 4 GB RAM, 4 GB swap and 4 GB tmpfs, and very > > few > > things running on it. > > - I filled the tmpfs with 4 GB of random data, which means that after > > moving the content of the tmpfs to the swap, 4 GB could still be used > > without issue. > > - I ended up with the following /proc/meminfo: > > MemTotal:3951508 kB > > MemFree: 130976 kB > > MemAvailable: 10584 kB > > Buffers:2448 kB > > Cached: 3694676 kB > > SwapCached:12936 kB > > Active: 3111920 kB > > Inactive: 610376 kB > > Active(anon):3102668 kB > > Inactive(anon): 606952 kB > > Active(file): 9252 kB > > Inactive(file): 3424 kB > > Unevictable: 0 kB > > Mlocked: 0 kB > > SwapTotal: 4194300 kB > > SwapFree:3777400 kB > > Zswap: 0 kB > > Zswapped: 0 kB > > Dirty: 0 kB > > Writeback: 0 kB > > AnonPages: 12960 kB > > Mapped: 6700 kB > > Shmem: 3684416 kB > > KReclaimable: 27616 kB > > Slab: 54652 kB > > SReclaimable: 27616 kB > > SUnreclaim:27036 kB > > KernelStack:2496 kB > > PageTables: 1516 kB > > NFS_Unstable: 0 kB > > Bounce:0 kB > > WritebackTmp: 0 kB > > CommitLimit: 6170052 kB > > Committed_AS:4212940 kB > > VmallocTotal: 34359738367 kB > > VmallocUsed: 16116 kB > > VmallocChunk: 0 kB > > Percpu: 2288 kB > > HardwareCorrupted: 0 kB > > AnonHugePages: 0 kB > > ShmemHugePages:0 kB > > ShmemPmdMapped:0 kB > > FileHugePages: 0 kB > > FilePmdMapped: 0 kB > > HugePages_Total: 0 > > HugePages_Free:0 > > HugePages_Rsvd:0 > > HugePages_Surp:0 > > Hugepagesize: 2048 kB > > Hugetlb: 0 kB > > DirectMap4k: 110452 kB > > DirectMap2M: 5132288 kB > > DirectMap1G: 5242880 kB > > > With the current version of dpkg, it means it consider 10584 kB are > > available > > (not however that there is 130976 kB of unused physical RAM). With your > > patch, > > it's a bit better, as it would be 123408 kB. Still far less that one the VM > > is > > capable of. > > Err sorry, the patch was computing the used memory and not the truly > available one! The updated patch should do better. :) Thanks for the updated patch. Computing the available memory manually from the above values sounds like it should work, so I'll give it a try. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1023870: dpkg: Problems in buildds due to slow compression
Hi, On 2022-11-12 22:28, Guillem Jover wrote: > Hi! > > On Fri, 2022-11-11 at 19:15:59 +0100, Manuel A. Fernandez Montecelo wrote: > > Package: dpkg > > Version: 1.21.9 > > Severity: normal > > X-Debbugs-Cc: m...@debian.org, debian-wb-t...@lists.debian.org > > > After some investigation by aurel32 and myself, this was traced back to the > > commit f8d254943051e085040367d689048c00f31514c3 [2], in which the > > calculation of > > the memory that can be used, to determine the number of threads to use, was > > changed from half of the physical mem to be based on the memory available. > > Ah, thanks for tracking this down! I think the problem is the usual > "available" memory does not really mean what people think it means. :/ > And I unfortunately missed that (even thought I was aware of it) when > reviewing the patch. > > Attached is something I just quickly prepared, which I'll clean up and > merge for the upcoming 1.21.10. Let me know if that solves the issue > for you, otherwise we'd need to look for further changes. Thanks for providing a patch. I have not been able yet to try it for the case where we have found the issue, i.e. building linux. However I have tried to setup a similar environment: - I took a just booted VM with 4 GB RAM, 4 GB swap and 4 GB tmpfs, and very few things running on it. - I filled the tmpfs with 4 GB of random data, which means that after moving the content of the tmpfs to the swap, 4 GB could still be used without issue. - I ended up with the following /proc/meminfo: MemTotal:3951508 kB MemFree: 130976 kB MemAvailable: 10584 kB Buffers:2448 kB Cached: 3694676 kB SwapCached:12936 kB Active: 3111920 kB Inactive: 610376 kB Active(anon):3102668 kB Inactive(anon): 606952 kB Active(file): 9252 kB Inactive(file): 3424 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 4194300 kB SwapFree:3777400 kB Zswap: 0 kB Zswapped: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 12960 kB Mapped: 6700 kB Shmem: 3684416 kB KReclaimable: 27616 kB Slab: 54652 kB SReclaimable: 27616 kB SUnreclaim:27036 kB KernelStack:2496 kB PageTables: 1516 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit: 6170052 kB Committed_AS:4212940 kB VmallocTotal: 34359738367 kB VmallocUsed: 16116 kB VmallocChunk: 0 kB Percpu: 2288 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB ShmemHugePages:0 kB ShmemPmdMapped:0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k: 110452 kB DirectMap2M: 5132288 kB DirectMap1G: 5242880 kB With the current version of dpkg, it means it consider 10584 kB are available (not however that there is 130976 kB of unused physical RAM). With your patch, it's a bit better, as it would be 123408 kB. Still far less that one the VM is capable of. For our use case, I wonder if the memory contained in Shmem (which in that case maps to the memory used for the tmpfs) should be considered as available, as it could be moved to the swap easily. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1023870: dpkg: Problems in buildds due to slow compression
Hi, On 2022-11-12 23:04, Adrian Bunk wrote: > On Fri, Nov 11, 2022 at 07:15:59PM +0100, Manuel A. Fernandez Montecelo wrote: > >... > > The origins of this bug report are because there are sometimes problems > > building > > packages in buildds, the compression phase is very slow and sometimes the > > build > > is aborted due to inactivity: > > > > E: Build killed with signal TERM after 300 minutes of inactivity [1] > > > > After some investigation by aurel32 and myself, this was traced back to the > > commit f8d254943051e085040367d689048c00f31514c3 [2], in which the > > calculation of > > the memory that can be used, to determine the number of threads to use, was > > changed from half of the physical mem to be based on the memory available. > > > > For example in buildds with not-so-large amount of RAM, using part of it for > > tempfs (which is how buildds are set-up), the reported available memory > > maybe is > > not very large. For example it could be MemAvailable=2GB for 16GB of > > physical > > RAM in the machine. In the dpkg code, for the purposes of the calculation > > of > > how much memory can be used, the result appears to be to be half of the > > MemAvailable [3], so only 1GB. > > > > According to the tables in xz man page, for compression the algorithm can > > use > > 674MB. So as a result, dpkg-deb uses single-threaded compression, even if > > it > > could easily use 2-3 threads and still use only RAM; or use the full number > > of > > threads in the machine (e.g. 4 or 8) even if it means swapping out some of > > the > > content of tempfs -- which is not a problem in most cases for buildds, > > specially > > if using fast disks. > > I don't see src:linux changing the compression from the default level 6, > so that should be < 100 MB per core. > > I am wondering whether these buildds are for some reason running into > the 128 MiB default at the bottom of the commit when the reading from > /proc fails for some reason. No the problem they have is that the build is done in a 80GB tmpfs, with 100GB swap. This works because the kernel is slowly moving things to swap when there is no RAM available. However for packages needing more build space than the physical RAM, the kernel seems to start moving data to the swap when MemAvailable is in the order of 100MB to 200MB. dpkg therefore considers there are no memory available, that said after moving a bit more data from the tmpfs to the swap, plenty of memory would be available for dpkg to do the parallel compression. To make a comparison, if GCC need 4GB of RAM, it just allocate them, and the kernel takes care of moving things to swap. In the worst case the OOM killer just kill GCC. On the other hand dpkg look how much memory available without moving things to the swap, and only uses that. > > As a result of all this, it is taking upwards of 600 mins of CPU time to > > compress recent linux-image-*-dbg packages in the buildds of riscv64 > > architecture at the moment, so when using 2 threads of less, it's > > guaranteed to > > be aborted. > > > > But this also affects other arches and other packages in other ways, at > > least by > > making the build needlessly slow in many cases. > > There is an even more worrysome issue, from xz(1): > If the specified memory usage limit is exceeded when decompressing, xz > will display an error and decompressing the file will fail. If the > limit is exceeded when compressing, xz will try to scale the settings > down so that the limit is no longer exceeded > > Different compression of packages in the archive based on what is in > /proc on the buildd is not desirable. A *very* quick look at the xz source seems to show it looks at the physical memory here, so we're good. > > It's not very clear what could be the solution for this, as the default > > could be > > OK for desktops and many machines in which there's plenty of available RAM, > > but > > this is not the case of all of our buildds. It might not be possible to > > detect > > which is the best from within dpkg. > >... > > Sebastian, was there any real-world problem motivating your commit, > or did it just sound more correct? > > With default settings there should be < 100 MB/core RAM usage, > and even with "xz -9"[1] RAM usage should be < 700 MB/core. I think the use case there, is for the desktop. It's preferable to use 2 threads only on a 4 core processor than sending Firefox to the swap. That said that heuristics is not necessary the best for the build daemon. > These numbers shouldn't be a problem on buildds that successfully > manage to build packages large enough that multithreaded compression > is even possible. Yep, we always have at least 1GB per core on all our buildds. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1023531: utox: autopkgtest regression on s390x: test_chrono fails
On 2022-11-10 08:37, Paul Gevers wrote: > Hi, > > On 09-11-2022 23:02, Aurelien Jarno wrote: > > Unfortunately I am not sure we want to do that, as we don't know if this > > GCC version incompatibility (that seems specific to s390x, at least in > > the utox context) will also happen for the next GCC version. > > I noticed yesterday that the previous build of check was done with gcc-10, > so not the previous gcc. Apparently mixing gcc-10 check and gcc-11 glibc was > "fine". > > > Now if we consider it will break again, the more elegant solution would > > be to change check to use dynamic linking instead of static linking. > > Alternatively we can export the GCC version used to compile GLIBC (for > > instance providing libc6-gcc11 or libc6-gcc12) and add some code in > > check to add a depends on that. A simpler way would just be to add a > > depends on the major glibc version (so libc6 (>> 2.36), libc6 (<< 2.37)) > > as we *tend* to change the GCC version used at the same time than the > > major version (at least for sid, not true for experimental). > > So maybe we (Release Team and glibc maintainers) should ignore this issue > for now. At least, not create overly complicated solutions outside of check, > just to accommodate only that package. > That's indeed the best, it just mean we should carefully look at autopkgtest on new glibc versions, and look for real issues among the flaky tests. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1023531: utox: autopkgtest regression on s390x: test_chrono fails
Hi, On 2022-11-09 22:24, Paul Gevers wrote: > Control: affects -1 utox > > Hi Aurelien, Christian, > > On 09-11-2022 21:25, Aurelien Jarno wrote: > > It happens that emalloc is provided by libcheck_pic.a (from the check > > package) and that ASAN trips when linked objects are built with > > different GCC versions. In that case both glibc and check needs to be > > built with the same GCC version. The switch of glibc from GCC 11 to GCC > > 12 triggered the issue. > > Thanks for your, as always, splendid debugging work. > > > I am not sure why it happens on s390x only > > though. > > > > It appears that the easiest way to fix the problem is to binNMU check: > > > >wb nmu check . ANY . -m 'Rebuild against GCC 12 (Closes: #1023531).' > > > > I'll add a breaks on the glibc side once done. > > How can we prevent this from slipping into testing in the future? It's not > really great that glibc and check need to be in lockstep and we have no > triggers in place to detect that. (I mean, relying on the utox test feels, > ... sub-optimal). The opposite could happen as well, that check is build > with the next gcc while glibc is with an older version. Unfortunately I am not sure we want to do that, as we don't know if this GCC version incompatibility (that seems specific to s390x, at least in the utox context) will also happen for the next GCC version. Now if we consider it will break again, the more elegant solution would be to change check to use dynamic linking instead of static linking. Alternatively we can export the GCC version used to compile GLIBC (for instance providing libc6-gcc11 or libc6-gcc12) and add some code in check to add a depends on that. A simpler way would just be to add a depends on the major glibc version (so libc6 (>> 2.36), libc6 (<< 2.37)) as we *tend* to change the GCC version used at the same time than the major version (at least for sid, not true for experimental). Regard Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1023531: utox: autopkgtest regression on s390x: test_chrono fails
control: reassign -1 check On 2022-11-06 17:21, Aurelien Jarno wrote: > On 2022-11-06 08:12, Paul Gevers wrote: > > Source: utox > > Version: 0.18.1-1 > > Severity: serious > > User: debian...@lists.debian.org > > Usertags: regression > > > > Dear maintainer(s), > > > > Your package has an autopkgtest, great. With a recent upload of glibc it > > started to fail on s390x. Looking at the history [1], I noticed that > > apparently the test can flip from passing for a while to failing for a while > > and back. Unfortunately, we don't keep the logs so long to inspect if > > previous (pre August 2022) failures were due to the same reason. > > Unfortunately, the output of the failure is rather limited (it seems there > > is more info logged, but that log file is not echoed to the autopkgtest log > > or stored as an autopkgtest artifact. > > > > Can you please investigate the situation? At least this is a autopkgtest > > regression on a release architecture, but maybe (hopefully?) this points at > > more severe issues. > > > > If you find out that it's really a regression in glibc functionality and the > > upload doesn't "just" trigger faulty behavior in utox, don't hesitate to > > reassign to glibc. Also, don't hesitate to contact the s390x porters if you > > need help figuring out this s390x specific issue. > > For the record, this is the contect of the log file: > > 2/2 Testing: test_chrono > 2/2 Test: test_chrono > Command: "/home/aurel32/utox-0.18.1/build/tests/test_chrono" > Directory: /home/aurel32/utox-0.18.1/build/tests > "test_chrono" start time: Nov 06 10:53 UTC > Output: > -- > Running suite(s): Chrono > > = > ==778737==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 24 byte(s) in 1 object(s) allocated from: > #0 0x3ffa94b9173 in __interceptor_malloc > ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 > #1 0x2aa138068cd in emalloc > (/home/aurel32/utox-0.18.1/build/tests/test_chrono+0x68cd) > It happens that emalloc is provided by libcheck_pic.a (from the check package) and that ASAN trips when linked objects are built with different GCC versions. In that case both glibc and check needs to be built with the same GCC version. The switch of glibc from GCC 11 to GCC 12 triggered the issue. I am not sure why it happens on s390x only though. It appears that the easiest way to fix the problem is to binNMU check: wb nmu check . ANY . -m 'Rebuild against GCC 12 (Closes: #1023531).' I'll add a breaks on the glibc side once done. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1023531: utox: autopkgtest regression on s390x: test_chrono fails
On 2022-11-06 08:12, Paul Gevers wrote: > Source: utox > Version: 0.18.1-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainer(s), > > Your package has an autopkgtest, great. With a recent upload of glibc it > started to fail on s390x. Looking at the history [1], I noticed that > apparently the test can flip from passing for a while to failing for a while > and back. Unfortunately, we don't keep the logs so long to inspect if > previous (pre August 2022) failures were due to the same reason. > Unfortunately, the output of the failure is rather limited (it seems there > is more info logged, but that log file is not echoed to the autopkgtest log > or stored as an autopkgtest artifact. > > Can you please investigate the situation? At least this is a autopkgtest > regression on a release architecture, but maybe (hopefully?) this points at > more severe issues. > > If you find out that it's really a regression in glibc functionality and the > upload doesn't "just" trigger faulty behavior in utox, don't hesitate to > reassign to glibc. Also, don't hesitate to contact the s390x porters if you > need help figuring out this s390x specific issue. For the record, this is the contect of the log file: 2/2 Testing: test_chrono 2/2 Test: test_chrono Command: "/home/aurel32/utox-0.18.1/build/tests/test_chrono" Directory: /home/aurel32/utox-0.18.1/build/tests "test_chrono" start time: Nov 06 10:53 UTC Output: -- Running suite(s): Chrono = ==778737==ERROR: LeakSanitizer: detected memory leaks Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x3ffa94b9173 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x2aa138068cd in emalloc (/home/aurel32/utox-0.18.1/build/tests/test_chrono+0x68cd) Indirect leak of 8 byte(s) in 1 object(s) allocated from: #0 0x3ffa94b9173 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x2aa138068cd in emalloc (/home/aurel32/utox-0.18.1/build/tests/test_chrono+0x68cd) SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s). = ==778740==ERROR: LeakSanitizer: detected memory leaks Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x3ffa94b9173 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x2aa138068cd in emalloc (/home/aurel32/utox-0.18.1/build/tests/test_chrono+0x68cd) Indirect leak of 8 byte(s) in 1 object(s) allocated from: #0 0x3ffa94b9173 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x2aa138068cd in emalloc (/home/aurel32/utox-0.18.1/build/tests/test_chrono+0x68cd) SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s). 0%: Checks: 2, Failures: 0, Errors: 2 /home/aurel32/utox-0.18.1/tests/test_chrono.c:59:E:chrono_target:test_chrono_target:0: (after this point) Early exit with return value 1 /home/aurel32/utox-0.18.1/tests/test_chrono.c:71:E:chrono_callback:test_chrono_callback:0: (after this point) Early exit with return value 1 Test time = 0.06 sec -- Test Failed. "test_chrono" end time: Nov 06 10:53 UTC "test_chrono" time elapsed: 00:00:00 -- End testing: Nov 06 10:53 UTC Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1023266: RM: stsci.distutils -- ROM; FTBFS, dead upstream, not rdep, not needed anymore
Package: ftp.debian.org Severity: normal stsci.distutils used to be a build-dependency of pyfits, which has been replaced years ago by astropy. It is therefore not needed anymore in Debian. In addition it is dead upstream and FTBFS in sid.
Bug#1022926: transition: glibc 2.36
On 2022-10-31 21:20, Sebastian Ramacher wrote:
> Control: tags -1 = confirmed
>
> On 2022-10-30 19:06:09 +0100, Aurelien Jarno wrote:
> > On 2022-10-30 17:10, Sebastian Ramacher wrote:
> > > Control: forwarded -1
> > > https://release.debian.org/transitions/html/glibc-2.36.html
> > > Control: tags -1 moreinfo
> > >
> > > On 2022-10-27 21:36:11 +0200, Aurelien Jarno wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: transition
> > > > X-Debbugs-Cc: debian-gl...@lists.debian.org
> > > >
> > > > Dear release team,
> > > >
> > > > I would like to get a transition slot for glibc 2.36. It has been
> > > > available in experimental for a bit more than one month and does not
> > > > have any known major issue. It has been built successfully on all
> > > > release architectures and many ports architectures. A few issues found
> > > > through the autopkgtest pseudo excuses for experimental have been fixed.
> > > > The remaining ones are due to britney bugs, broken autopkgtest or
> > > > packages parts of the transition.
> > > >
> > > > As glibc is using symbol versioning, there is no soname change. That
> > > > said a few packages are using libc internal symbols and have to be
> > > > rebuilt for this transition. Here is the corresponding ben file:
> > > >
> > > > title = "glibc";
> > > > is_affected = .depends ~ /libc[0-9.]* \(< > > > is_good = .depends ~ /libc[0-9.]* \(<< 2.37\)/;
> > > > is_bad = .depends ~ /libc[0-9.]* \(<< 2.36\)/;
> > > >
> > > > In addition a few new symbols have been added that might prevent a few
> > > > other packages to migrate to testing until glibc migrates if they pick
> > > > up the new symbols, however those are really limited in this version and
> > > > mostly linked to new filesystem, processes or random functions, so
> > > > unlikely to be massively used by default.
> > > >
> > > > Note that this version builds with GCC 12 instead of GCC 11, so it is a
> > > > prerequisite for not shipping bookworm with GCC 11.
> > >
> > > Speaking of GCC 12 … #1022991 seems to have a first patch available
> > > upstream. Is there any chance that we could start this transition
> > > together with a fix for that bug?
> >
> > I would not say we have patch yet. I posted a first patch on the mailing
> > list yesterday [1], and we have two epidermic answers from both sides
> > ("Why this patch is approved?" or "So MIPS ABI idiocrasies strike
> > again"). One come with a proposal and another one with a partial patch.
> > So that's 3 different options in total. I am also worried that the
> > problem could be more widespread as there is a claim that clock_adjtime
> > is broken on all 64bit system.
> >
> > So IMHO, we should just wait that things calm done, and that people
> > really try to understand the problem, its consequences and how to fix
> > it, instead of just proposing random patches.
> >
> > But once we have something acceptable, I am find including it either in
> > a 2.35 upload or a 2.36 one, both are fine to me.
>
> Okay, then let's not wait for #1022991. None of the reverse dependencies
> should get stuck behind gcc-12. Please go ahead with this transition.
Thanks, I have just uploaded it.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Bug#1022926: transition: glibc 2.36
On 2022-10-30 17:10, Sebastian Ramacher wrote:
> Control: forwarded -1
> https://release.debian.org/transitions/html/glibc-2.36.html
> Control: tags -1 moreinfo
>
> On 2022-10-27 21:36:11 +0200, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: debian-gl...@lists.debian.org
> >
> > Dear release team,
> >
> > I would like to get a transition slot for glibc 2.36. It has been
> > available in experimental for a bit more than one month and does not
> > have any known major issue. It has been built successfully on all
> > release architectures and many ports architectures. A few issues found
> > through the autopkgtest pseudo excuses for experimental have been fixed.
> > The remaining ones are due to britney bugs, broken autopkgtest or
> > packages parts of the transition.
> >
> > As glibc is using symbol versioning, there is no soname change. That
> > said a few packages are using libc internal symbols and have to be
> > rebuilt for this transition. Here is the corresponding ben file:
> >
> > title = "glibc";
> > is_affected = .depends ~ /libc[0-9.]* \(< > is_good = .depends ~ /libc[0-9.]* \(<< 2.37\)/;
> > is_bad = .depends ~ /libc[0-9.]* \(<< 2.36\)/;
> >
> > In addition a few new symbols have been added that might prevent a few
> > other packages to migrate to testing until glibc migrates if they pick
> > up the new symbols, however those are really limited in this version and
> > mostly linked to new filesystem, processes or random functions, so
> > unlikely to be massively used by default.
> >
> > Note that this version builds with GCC 12 instead of GCC 11, so it is a
> > prerequisite for not shipping bookworm with GCC 11.
>
> Speaking of GCC 12 … #1022991 seems to have a first patch available
> upstream. Is there any chance that we could start this transition
> together with a fix for that bug?
I would not say we have patch yet. I posted a first patch on the mailing
list yesterday [1], and we have two epidermic answers from both sides
("Why this patch is approved?" or "So MIPS ABI idiocrasies strike
again"). One come with a proposal and another one with a partial patch.
So that's 3 different options in total. I am also worried that the
problem could be more widespread as there is a claim that clock_adjtime
is broken on all 64bit system.
So IMHO, we should just wait that things calm done, and that people
really try to understand the problem, its consequences and how to fix
it, instead of just proposing random patches.
But once we have something acceptable, I am find including it either in
a 2.35 upload or a 2.36 one, both are fine to me.
Regards
Aurelien
[1] https://sourceware.org/pipermail/libc-alpha/2022-October/143049.html
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Bug#1023032: ksh93u+m_1.0.4-1_all-buildd.changes REJECTED
Source: ksh93u+m Version: 1.0.4-1 Severity: serious On 2022-10-29 12:35, Debian FTP Masters wrote: > > > Version check failed: > Your upload included the binary package ksh, version 20220829, for all, > however testing already has version 20220829. > Uploads to unstable must have a higher version than present in testing. > > Mapping sid to unstable. > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > >
Bug#1022991: libc6: broken y2038 support in fstatat on mips64el
control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=29730 On 2022-10-28 20:35, Aurelien Jarno wrote: > Package: libc6 > Version: 2.35-1 > Severity: critical > Tags: upstream > Justification: breaks unrelated software > > On mips64el the fstat/fstatat/lstat functions return EOVERFLOW when they > are called on files with a mtime, atime or ctime that can't be > represented within a 32-bit time_t. This should not happen as time_t is > 64-bit on mips64el. This is a regression from glibc 2.34 and can be > reproduce with: > > (sid_mips64el-dchroot)aurel32@eller:~$ touch -d 20390101 t > (sid_mips64el-dchroot)aurel32@eller:~$ chmod +x t > chmod: cannot access 't': Value too large for defined data type > (sid_mips64el-dchroot)aurel32@eller:~$ > > This breaks unrelated software, for instance the build of gcc-12 on the > build daemons: > > https://buildd.debian.org/status/fetch.php?pkg=gcc-12=mips64el=12.2.0-7=1666806816=0 I have identified the commit causing the issue, and forwarded the bug upstream. See: https://sourceware.org/bugzilla/show_bug.cgi?id=29730 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1022991: libc6: broken y2038 support in fstatat on mips64el
Package: libc6 Version: 2.35-1 Severity: critical Tags: upstream Justification: breaks unrelated software On mips64el the fstat/fstatat/lstat functions return EOVERFLOW when they are called on files with a mtime, atime or ctime that can't be represented within a 32-bit time_t. This should not happen as time_t is 64-bit on mips64el. This is a regression from glibc 2.34 and can be reproduce with: (sid_mips64el-dchroot)aurel32@eller:~$ touch -d 20390101 t (sid_mips64el-dchroot)aurel32@eller:~$ chmod +x t chmod: cannot access 't': Value too large for defined data type (sid_mips64el-dchroot)aurel32@eller:~$ This breaks unrelated software, for instance the build of gcc-12 on the build daemons: https://buildd.debian.org/status/fetch.php?pkg=gcc-12=mips64el=12.2.0-7=1666806816=0
Bug#1022926: transition: glibc 2.36
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-gl...@lists.debian.org Dear release team, I would like to get a transition slot for glibc 2.36. It has been available in experimental for a bit more than one month and does not have any known major issue. It has been built successfully on all release architectures and many ports architectures. A few issues found through the autopkgtest pseudo excuses for experimental have been fixed. The remaining ones are due to britney bugs, broken autopkgtest or packages parts of the transition. As glibc is using symbol versioning, there is no soname change. That said a few packages are using libc internal symbols and have to be rebuilt for this transition. Here is the corresponding ben file: title = "glibc"; is_affected = .depends ~ /libc[0-9.]* \(<
Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack
control: tag -1 + moreinfo Hi, On 2022-10-25 21:07, Simon McVittie wrote: > Package: libc6-dev > Version: 2.35-4 > Severity: normal > X-Debbugs-Cc: debian-m...@lists.debian.org, lint...@packages.debian.org, > jrt...@debian.org > User: debian-m...@lists.debian.org > Usertags: mips mipsel > > All mips*el executables and libraries appear to have an executable stack, > resulting in very large numbers of Lintian warnings, particularly for > packages with many small ELF objects like > <https://udd.debian.org/lintian/?packages=samba>. > > Jessica Clarke looked into this and found that this is intentionally done > by glibc when targeting minimum kernel 4.8.0 or older with mips hardfloat: > https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270ed30fdbae9ad25426/sysdeps/unix/sysv/linux/mips/configure.ac#L138-L143 > > Debian 9 had a kernel newer than 4.8.0, so I think Debian 12 probably > doesn't need to go that far into backwards compatibility? If the mips > porters agree, then glibc on mips*el should stop forcing an executable > stack, either by increasing the minimal kernel version or by patching > this out. That will provide some security hardening on mips*el. Note that the other official architecture still have a kernel compatibility set to 3.2, so that will make a difference between architectures. There are discussions to increase it upstream, but this won't happened for bookworm. > Or, if the mips porters consider this backwards compatibility to be > more important than the security hardening of a non-executable stack, > then Lintian should stop issuing warnings about the executable stack on > mips*el to improve its signal/noise ratio. At this stage there is nothing that can be done on the glibc side, the decision has to be taken by the mips porters. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1021062: fixed in bash 5.2-2
control: reopen 1021062 On 2022-10-24 09:04, Debian FTP Masters wrote: > Source: bash > Source-Version: 5.2-2 > Done: Matthias Klose > > We believe that the bug you reported is fixed in the latest version of > bash, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 1021...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Matthias Klose (supplier of updated bash package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > Format: 1.8 > Date: Mon, 24 Oct 2022 10:34:28 +0200 > Source: bash > Architecture: source > Version: 5.2-2 > Distribution: unstable > Urgency: medium > Maintainer: Matthias Klose > Changed-By: Matthias Klose > Closes: 1021062 > Changes: > bash (5.2-2) unstable; urgency=medium > . >* Apply upstream patches 001 - 002. > - Expanding unset arrays in an arithmetic context can cause a >segmentation fault. > - Starting bash with an invalid locale specification for >LC_ALL/LANG/LC_CTYPE can cause the shell to crash. Closes: #1021062. This is the wrong bug number, the problem might be fixed in bash, but is still present in libreadline8. Reopening. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1022564: locale related segmentation fault
control: reassign -1 libreadline8 control: forcemerge 1021062 -1 Hi, On 2022-10-24 05:16, Aleksi Suhonen wrote: > Package: libc6 > Version: 2.35-3 > Severity: important > > I ran into this issue while updating packages on a Debian/sid machine, and > the install scripts for "ntpsec" and "tzdata" started failing with segfault. > I couldn't find a way to reproduce it on that machine immediately. I started > suspecting the machine might be failing. > > But then I ran into the problem on another machine that runs "bird" routing > daemon, as its control program "birdc" also started segfaulting, but started > working if I set LC_ALL=C. Then I found I could also get the install scripts > on the first machine to work with LC_ALL=C. > > So, steps to reproduce: > > root# apt-get install bird > root# LC_ALL=asdf birdc The problem you observed is not linked to glibc, but is a known bug in libreadline8 affecting many packages. Please see bug#1021062. I am therefore reassigning the bug. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1021977: Fwd: Tzdata timezone files corruption after clean debian 11 installation
Dear Satish, On 2022-10-18 22:17, Satish Binda wrote: > because normally it is just one line ascii or ansi or utf-8, perhaps utf-16 > but not an easy to digest binary file, at length, that no one knows about That is not correct. The file format is described by RFC8536 [1] and is a binary format. Regards Aurelien [1] https://datatracker.ietf.org/doc/html/rfc8536 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1021977: Fwd: Tzdata timezone files corruption after clean debian 11 installation
Dear Satish, Thanks for the attachement. It indeed matches the file provided in the tzdata package in version 2021a-1+deb11u7. Can you please tell me why do you believe it is corrupted or affected by a malware? Regards Aurelien On 2022-10-18 20:44, Satish Binda wrote: > Dear Aurel, > > I included the attachment this time. > > Yours truly, > > Satish > -- Forwarded message - > From: Satish Binda > Date: Tue, Oct 18, 2022 at 10:04 AM > Subject: Tzdata timezone files corruption after clean debian 11 installation > To: > Cc: > > > Package: tzdata > Version: 2021a-1+deb11u7 > > Dear Debian, > > I wanted to change my timezone from europe/amsterdam to utc. > when i viewed the europe/amsterdam timezone file. I got corruption or > malware > as I included in this email. > > All zone files as I can see contain either corruption or malware. > > This is on a fresh install of debian 11. > > I am going to reinstall the tzdata package if possible; but it is quite a > breach. > > Yours truly, > > Satish Binda > The Netherlands > (ultra violence / agent 1 / kick some dust) -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1021977: Tzdata timezone files corruption after clean debian 11 installation
Hi, On 2022-10-18 10:04, Satish Binda wrote: > Package: tzdata > Version: 2021a-1+deb11u7 > > Dear Debian, > > I wanted to change my timezone from europe/amsterdam to utc. > when i viewed the europe/amsterdam timezone file. I got corruption or Can you please give some details about what you tried to do, for instance which command did you try to "view" the timezone file? > malware > as I included in this email. I do not find anything included in the email, can you please give some more details? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1021426: bullseye-pu: package glibc/2.31-13+deb11u5
Hi, On 2022-10-14 11:58, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2022-10-08 at 11:30 +0200, Aurelien Jarno wrote: > > The glibc/2.31-13+deb11u4 update introduced a regression (bug > > #1019855) on some early Intel Haswell processors which expose the > > AVX2 instructions, but lack the BMI2 instructions. On such systems > > the memchr and strlen related functions fails with SIGILL, rendering > > them unusable. > > > > The issue is that some of the backported commits to fix the overflow > > bugs in the AVX2 implementation of wmemchr and wcslen that went in > > the upstream 2.31 branch, started to use BMI2 instructions in > > addition to the AVX2 instructions, without checking for the > > availability of those instructions. This was done in another commit > > that hasn't been backported. > > > > It happens that a microcode update for the affected CPUs (either > > through the BIOS/firmware or from a package) fixes this, so it went > > barely noticed up to now, especially given other distributions > > usually install firmware updates by default. > > > > [ Impact ] > > While the number of affected systems is probably small, this bug > > makes them unusable. > [...] > > Given the severity of the bug, it might be a good idea to release it > > through stable-updates. > > Please go ahead. Thanks for the review, I have just uploaded it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1019535: gcc-12: please change the default hash style to both
On 2022-10-10 12:43, Matthias Klose wrote: > Control: tags -1 + moreinfo > > the change to use the gnu style instead of the both style was done in 2013. > Why do we want to change that again nine years later? As said in my initial mail, the point is that it has been found nine years after that removing the DT_HASH table makes Debian and a few other distribution incompatible with the Generic System V Application Binary Interface [1]. This has been found to break the "Easy Anti-Cheat" system [2] on distributions that have their toolchain differing from the upstream default --hash-style=both, as since version 2.36 glibc uses the system defaults instead of enforcing it. Distributions which use the toolchain default have been unaffected. With this new data points, we should at least think again about the change that was done nine years ago, and see if it is still the correct one. Regards Aurelien [1] https://groups.google.com/g/generic-abi/c/th5919osPAQ [2] https://sourceware.org/git/?p=glibc.git;a=patch;h=e47de5cb2d4dbecb58f569ed241e8e95c568f03c > gcc-4.8 (4.8.1-4) unstable; urgency=low > > > > * Update to SVN 20130619 (r200219) from the gcc-4_8-branch. > > - Bump the libgo soname (change in type layout for functions that take > > function arguments). > > - Fix finding the liblto_plugin.so without x permissions set (see > > PR driver/57651). Closes: #712704. > > * Update maintainer list. > > * Fall back to the binutils version of the binutils build dependency > > if the binutils version used for the build cannot be determined. > > * For ARM multilib builds, use libsf/libhf system directories to lookup > > files for the non-default multilib (for now, only for the cross > compilers). > > * Split out a gcj-4.8 package, allow to build a gcj cross compiler. > > * Allow one to cross build gcj. > > * Don't include object.di in the D cross compiler, but depend on gdc > instead. > > * Allow one to cross build gdc. > > * Pass --hash-style=gnu instead of --hash-style=both to the linker. > > > > -- Matthias Klose Wed, 19 Jun 2013 23:48:02 +0200 > > -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT
On 2022-10-12 10:59, Johannes Schauer Marin Rodrigues wrote: > Quoting Aurelien Jarno (2022-10-11 22:14:31) > > From what I have understood from your explanation, if the directory exists > > chroot_canon() will work, so `ldconfig -r` will be able to create the > > aux-cache file in it. > > I can confirm this conclusion. The following patch makes our CI pass without > any other changes to glibc. > > --- glibc-2.35/debian/debhelper.in/libc-bin.dirs2022-09-22 > 22:06:02.0 +0200 > +++ glibc-2.35/debian/debhelper.in/libc-bin.dirs2022-10-12 > 10:15:46.0 +0200 > @@ -1,2 +1,3 @@ > usr/lib/locale > usr/share/libc-bin > +var/cache/ldconfig Thanks for the test. It needs a bit more than that though, as we want a 0700 permission. > > I still think that the bug should be fixed on the glibc upstream side, > > but that would allow to easy fix it on the package side, and it's > > probably better to have a closer match of the dpkg database and the file > > system. > > Though I have heard from some people that they want packages to ship only > files > under /usr and have everything else be created upon instantiation of the > machine. This change would go the opposite direction. This would need more changes though, ldconfig also currently does not work if /var/cache doesn't exist. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1020500: glibc: flaky autopkgtest on armel: multiple different failures
Hi Paul, A small update on this bug. Now that glibc 2.35-3 migrated to testing, the only unsolved issue is that one: On 2022-10-07 21:14, Paul Gevers wrote: > On 07-10-2022 20:55, Aurelien Jarno wrote: > > > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/23501044/log.gz > > > > > > -- > > > FAIL: elf/tst-debug1 > > > original exit status 1 > > > Didn't expect signal from child: got `Bus error' > > > -- > > > > I have not been able to reproducible this bug after 1M tests on > > amdahl.d.o, an RPI3 (running an arm64 kernel) and a STM32MP1 board > > (armhf). Would it be possible to give more details, like any > > corresponding dmesg entry to have a better idea of the issue? > > I'll try to have a look if I spot this again. The original dmesg is gone by > now. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1014729: glibc 2.34 breaks wcc autopkgtest on amd64: open: Invalid argument
control: forwarded -1 https://github.com/endrazine/wcc/pull/39 control: tag -1 + patch On 2022-07-12 12:46, Michael Hudson-Doyle wrote: > On Tue, 12 Jul 2022 at 04:30, Aurelien Jarno wrote: > > > On 2022-07-11 10:06, Michael Hudson-Doyle wrote: > > > It looks like a no-change rebuild fixed this in Ubuntu fwiw. > > > > Thanks, I confirm that in Debian too. Do you have an idea why? It could > > be a missing or too loose dependency. > > > > No. I got as far as reading > https://github.com/endrazine/wcc/blob/master/README.md and then was > completely unsurprised that it depends on the details of everything. It > would probably be quite fun to dig into why it's failing but I don't really > have the time for that today. This issue is due to the merge of libdl.so into libc.so. This makes wsh to try to load unused weak symbols, which results in dlsym() to return NULL. And that is not properly handled by wsh. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT
On 2022-10-11 22:06, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Aurelien Jarno (2022-10-11 21:55:47) > > Ok, thanks for the details, I'll look at the patch. > > thank you! > > > Anyway that makes me wonder if we should ship that directory in the libc6 Note that it should be the libc-bin package, not the libc6 one. > > package, just like apt ships /var/cache/apt and debconf ships > > /var/cache/debconf. > > In our DPKG_ROOT CI we compare a chroot tarball created the normal way with a > tarball created with dpkg run with --force-script-chrootless. We added an > additional mode that tries out if this whole thing also works when run without > being the root user but run as the normal user under fakeroot and then we > found > the missing /var/cache/ldconfig directory. > > So if libc6 would ship that directory, I think my patch would still be needed. > Because if `ldconfig -r` doesn't use the directory, then the last modification > timestamps will differ between a chroot created the normal way and a chroot > created without actually ever running chroot() (the DPKG_ROOT way). From what I have understood from your explanation, if the directory exists chroot_canon() will work, so `ldconfig -r` will be able to create the aux-cache file in it. I still think that the bug should be fixed on the glibc upstream side, but that would allow to easy fix it on the package side, and it's probably better to have a closer match of the dpkg database and the file system. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT
Hi, On 2022-10-11 21:50, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Aurelien Jarno (2022-10-11 21:41:05) > > On 2022-10-11 07:57, Johannes Schauer Marin Rodrigues wrote: > > > Package: glibc > > > Version: 2.35-3 > > > Severity: normal > > > Tags: patch > > > > > > Hi, > > > > > > when running libc-bin.postinst with DPKG_ROOT non-empty, ldconfig from > > > the outside is used to operate on the chroot and thus ldconfig will > > > never create the empty /var/cache/ldconfig directory inside the chroot. > > > > I don't get why this is needed. The point of calling ldconfig -r is to > > create that directory and create the aux-cache file in it. In my tests > > ldconfig does create that directory properly when ran with -r. > > > > > Please consider creating that directory if DPKG_ROOT is non-empty. > > > > Even if it ends up that in some conditions yet to be found, the > > directory is not created, this doesn't seems correct. This means that > > aux-cache file is also not created, which is more problematic. > > I now have a much better understanding about what is happening and filed this > patch: > > https://sourceware.org/pipermail/libc-alpha/2022-October/142592.html > > The problem occurs only if the opt_chroot variable is not NULL. This happens > when you pass -r but the chroot() call fails, for example because you are > running as an unprivileged user with fakeroot. In that case, chroot_canon() > will return NULL because /var/cache/ldconfig doesn't exist in the chroot yet. > This leads to aux_cache_file being set to NULL and that means that in the end > save_aux_cache() doesn't get called. Ok, thanks for the details, I'll look at the patch. Anyway that makes me wonder if we should ship that directory in the libc6 package, just like apt ships /var/cache/apt and debconf ships /var/cache/debconf. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT
Hi, On 2022-10-11 07:57, Johannes Schauer Marin Rodrigues wrote: > Package: glibc > Version: 2.35-3 > Severity: normal > Tags: patch > > Hi, > > when running libc-bin.postinst with DPKG_ROOT non-empty, ldconfig from > the outside is used to operate on the chroot and thus ldconfig will > never create the empty /var/cache/ldconfig directory inside the chroot. I don't get why this is needed. The point of calling ldconfig -r is to create that directory and create the aux-cache file in it. In my tests ldconfig does create that directory properly when ran with -r. > Please consider creating that directory if DPKG_ROOT is non-empty. Even if it ends up that in some conditions yet to be found, the directory is not created, this doesn't seems correct. This means that aux-cache file is also not created, which is more problematic. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1021426: bullseye-pu: package glibc/2.31-13+deb11u5
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-gl...@lists.debian.org
[ Reason ]
The glibc/2.31-13+deb11u4 update introduced a regression (bug #1019855)
on some early Intel Haswell processors which expose the AVX2
instructions, but lack the BMI2 instructions. On such systems the memchr
and strlen related functions fails with SIGILL, rendering them unusable.
The issue is that some of the backported commits to fix the overflow
bugs in the AVX2 implementation of wmemchr and wcslen that went in the
upstream 2.31 branch, started to use BMI2 instructions in addition to
the AVX2 instructions, without checking for the availability of those
instructions. This was done in another commit that hasn't been
backported.
It happens that a microcode update for the affected CPUs (either through
the BIOS/firmware or from a package) fixes this, so it went barely
noticed up to now, especially given other distributions usually install
firmware updates by default.
[ Impact ]
While the number of affected systems is probably small, this bug makes
them unusable.
[ Tests ]
This has been tested, by replacing all BMI2 instructions in the glibc
source code by the UD2 x86 instruction. This triggered the same issue
than the reported one in bug#1019855. Then the detection of BMI2
instructions has been disabled in the source code, and the resulting
glibc was working as expected without generating SIGILL.
[ Risks ]
The change is intentionally minimal, smaller than the upstream one, and
only targets the runtime execution. Some tests of the testsuite will
still fail on affected systems. This part can be fixed later in a point
release. This way the risks should be minimal.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
The change is very simple and consists in adding a check for BMI2
instructions in the ifunc selector that selects the AVX2 optimized code.
[ Other info ]
Given the severity of the bug, it might be a good idea to release it
through stable-updates.
diff --git a/debian/changelog b/debian/changelog
index 7952bf8b..f127d64d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+glibc (2.31-13+deb11u5) bullseye; urgency=medium
+
+ * debian/patches/local-require-bmi-in-avx2-ifunc.diff: new patch extracted
+from an upstream commit, to change the AVX2 ifunc selector to require the
+BMI2 feature. It happened that the wmemchr and wcslen changes backported
+in 2.31-13+deb11u4 relied on that commit which got forgotten.
+Closes: #1019855.
+
+ -- Aurelien Jarno Sat, 08 Oct 2022 11:25:58 +0200
+
glibc (2.31-13+deb11u4) bullseye; urgency=medium
[ Aurelien Jarno ]
diff --git a/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
b/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
new file mode 100644
index ..936f89ae
--- /dev/null
+++ b/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
@@ -0,0 +1,38 @@
+This patch is extracted from upstream commit 83c5b368226c ("x86-64: Require
+BMI2 for strchr-avx2.S"). It changes the common ifunc AVX2 selector to require
+the BMI2 instructions, and the backported fixes for memchr and strlen rely on
+that change.
+
+--- a/sysdeps/x86_64/multiarch/ifunc-avx2.h
b/sysdeps/x86_64/multiarch/ifunc-avx2.h
+@@ -21,28 +21,28 @@ IFUNC_SELECTOR (void)
+
+ extern __typeof (REDIRECT_NAME) OPTIMIZE (sse2) attribute_hidden;
+ extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2) attribute_hidden;
+ extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2_rtm) attribute_hidden;
+ extern __typeof (REDIRECT_NAME) OPTIMIZE (evex) attribute_hidden;
+
+ static inline void *
+ IFUNC_SELECTOR (void)
+ {
+ const struct cpu_features* cpu_features = __get_cpu_features ();
+
+ if (CPU_FEATURES_ARCH_P (cpu_features, AVX2_Usable)
++ && CPU_FEATURES_CPU_P (cpu_features, BMI2)
+ && CPU_FEATURES_ARCH_P (cpu_features, AVX_Fast_Unaligned_Load))
+ {
+ if (CPU_FEATURES_ARCH_P (cpu_features, AVX512VL_Usable)
+-&& CPU_FEATURES_ARCH_P (cpu_features, AVX512BW_Usable)
+-&& CPU_FEATURES_CPU_P (cpu_features, BMI2))
++&& CPU_FEATURES_ARCH_P (cpu_features, AVX512BW_Usable))
+ return OPTIMIZE (evex);
+
+ if (CPU_FEATURES_CPU_P (cpu_features, RTM))
+ return OPTIMIZE (avx2_rtm);
+
+ if (!CPU_FEATURES_ARCH_P (cpu_features, Prefer_No_VZEROUPPER))
+ return OPTIMIZE (avx2);
+ }
+
+ return OPTIMIZE (sse2);
+ }
diff --git a/debian/patches/series b/debian/patches/series
index 02bd18e7..c72ebf30 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -22,6 +22,8 @@ alpha/local-string-functions.diff
alpha/submitted-fts64.diff
alpha/submitted-makecontext.diff
+amd64
Bug#1020500: glibc: flaky autopkgtest on armel: multiple different failures
Hi, On 2022-09-22 11:19, Paul Gevers wrote: > Source: glibc > Version: 2.33-7 > Severity: serious > User: debian...@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > I looked at the results of the autopkgtest of your package. I noticed that > it regularly fails on armel while testing if other packages can migrate. A > retry (or retry of retry) passes, so it doesn't seem related to those > packages. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. I now looked at it because both gcc-11 and gcc-12 showed up as > regressing the glibc autopkgtest. > > Don't hesitate to reach out if you need help and some more information > from our infrastructure. Please find my answer (and questions for each test below). > https://ci.debian.net/packages/g/glibc/testing/armel/ > > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/23501044/log.gz > > -- > FAIL: elf/tst-debug1 > original exit status 1 > Didn't expect signal from child: got `Bus error' > -- I have not been able to reproducible this bug after 1M tests on amdahl.d.o, an RPI3 (running an arm64 kernel) and a STM32MP1 board (armhf). Would it be possible to give more details, like any corresponding dmesg entry to have a better idea of the issue? > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26322757/log.gz > > nptl/tst-rwlock9 > [...] > Timed out: killed the child process > Termination time: 2022-09-22T07:41:04.502168635 > Last write to standard output: 2022-09-22T07:28:34.991525943 I have been able to reproduce that one, with a probability of around 1/2500 on average. I have tracked it down to this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24774 It appears to be fixed by this patch that didn't seem to attract a lot of interest: https://sourceware.org/pipermail/libc-alpha/2021-September/131546.html I just reviewed and tested it, so let's see if it get merged soon: https://sourceware.org/pipermail/libc-alpha/2021-September/131546.html > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26218800/log.gz > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26223226/log.gz > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26322746/log.gz > > -- > FAIL: rt/tst-cpuclock2-time64 > original exit status 1 > live thread clock ffb6e90e resolution 0.1 > live thread before sleep => 0.000254800 > self thread before sleep => 0.000728320 > live thread after sleep => 0.473986200 > self thread after sleep => 0.001080840 > clock_nanosleep on process slept 97739240 (outside reasonable range) > -- I also can't reproduce this one after 10 tests on amdahl.d.o, an RPI3 (running an arm64 kernel) and a STM32MP1 board (armhf). According to upstream it seems that this test is known to fail heavy loaded hosts as it relies on wall time. Is it the case of the debci workers, do they have dedicated CPUs to run their tests? Are the armel workers different than the others? Nevertheless the part of the test that relies on wall time has been removed from upstream so this should be considered as fixed in glibc 2.35 that is now in testing: https://sourceware.org/git/?p=glibc.git;a=commit;h=f3c6c190388bb445568cfbf190a0942fc3c28553 > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/25779292/log.gz > > /bin/bash testdata/gen-XT5.sh > > /tmp/autopkgtest-lxc.pjd0aipn/downtmp/build.Ui1/src/build-tree/armel-libc/timezone/testdata/XT5.tmp > /bin/bash: line 1: > /tmp/autopkgtest-lxc.pjd0aipn/downtmp/build.Ui1/src/build-tree/armel-libc/timezone/testdata/XT5.tmp: > No such file or directory This has been fixed in glibc 2.35 that is now in testing: https://sourceware.org/git/?p=glibc.git;a=commit;h=62db87ab24f9ca483f97f5e52ea92445f6a63c6f Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1021408: golang-github-anacrolix-missinggo: flaky autopkgtest on armhf: FAIL: TestAsCompletedDelayed
Source: golang-github-anacrolix-missinggo Version: 2.1.0-6 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it regularly fails on armhf while testing if other packages can migrate. A retry (or retry of retry) passes, so it doesn't seem related to those packages. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. I now looked at it because both glibc showed up as regressing the golang-github-anacrolix-missinggo autopkgtest. Here are a few successful runs: https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26710743/log.gz https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26853370/log.gz https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26853490/log.gz Here are a few failed runs: https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26853369/log.gz https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26853371/log.gz https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26853484/log.gz Regards Aurelien
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
Hi, On 2022-10-04 08:51, Aurelien Jarno wrote: > Hi > > On 2022-09-25 13:43, Aurelien Jarno wrote: > > > Running a quick diff against old procinfo reveals that "flags" has the > > > following new entries now: > > > > > > tsc_deadline_timer ssbd ibrs ibpb stibp bmi1 bmi2 md_clear flush_l1d > > > > > > > it looks like that the BMI2 > > > > instructions support has been added in a microcode update > > > > > > As such it does appear that indeed this is the case. > > > > Thanks for the confirmation, it seems that the microcode update is also > > useful for security reasons in order to mitigate the speculative > > execution side channel issues (the famous spectre/meltdown). > > > > Neverthless the AVX2 code should not use BMI2 instructions if they are > > not available. > > This has been fixed upstream and in the sid package. Next step is to get > it fixed for stable. Please find a test version here for people who have the possibility to try: https://people.debian.org/~aurel32/glibc/ Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
Hi, On 2022-10-04 19:44, debian-bug-rep...@p0358.net wrote: > > Is there an easy way to unbrick a system affected by the issue? such as > > a kernel-line option or a configuration file in /etc? I don't see how I > > can set a GLIBC_TUNABLES environment variable for the whole system. > > I was trying during my testing to set such option globally somehow, but > failed, though maybe some method for this exists. As it stands I only see > two possibilities of unbricking a system, both assuming you can access the > partition externally from some bootable system: > > 1. Downgrade the affected libc6 package to a version before the one causing > issues (either chroot and dpkg, or just extract and physically replace the > files), after booting apt-mark hold libc6 to prevent faulty update from > being installed until the issue is fixed > > 2. Or install intel-microcode package, assuming the microcode update adds > the missing instructions in particular case, basically coincidentally fixing > this issue (the updated CPU microcode is loaded on every bootup) Please note that the microcode update might also be done through a BIOS/firmware update if available. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
Hi On 2022-09-25 13:43, Aurelien Jarno wrote: > > Running a quick diff against old procinfo reveals that "flags" has the > > following new entries now: > > > > tsc_deadline_timer ssbd ibrs ibpb stibp bmi1 bmi2 md_clear flush_l1d > > > > > it looks like that the BMI2 > > > instructions support has been added in a microcode update > > > > As such it does appear that indeed this is the case. > > Thanks for the confirmation, it seems that the microcode update is also > useful for security reasons in order to mitigate the speculative > execution side channel issues (the famous spectre/meltdown). > > Neverthless the AVX2 code should not use BMI2 instructions if they are > not available. This has been fixed upstream and in the sid package. Next step is to get it fixed for stable. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1021214: bullseye-pu: package libconfuse/3.3-2+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org
[ Reason ]
A heap-based buffer over-read has been found in libconfuse, labeled as
CVE-2022-40320, and reported as bug #1019596. The security team
considers this vulnerability as low severity which does not warrant a
DSA.
[ Impact ]
In case the update isn't approved, the vulnerability will still be
present users systems.
[ Tests ]
The changed code is tested by the testsuite, but there is no specific
test to check the vulnerability is fixed.
[ Risks ]
The fix is very simple and comes from upstream. It has been in
testing/sid for 2 weeks.
[ 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 ]
There is a single change in this version:
* Add debian/patches/CVE-2022-40320.patch from upstream to fix a heap-based
buffer over-read in cfg_tilde_expand (CVE-2022-40320). Closes: #1019596.
The change is to ensure the string copied with strncpy is always zero
terminated.
[ Other info ]
Given the changes are minimal, I have already uploaded the package to
the archive. Thanks for considering.
diff -Nru libconfuse-3.3/debian/changelog libconfuse-3.3/debian/changelog
--- libconfuse-3.3/debian/changelog 2021-01-10 15:30:20.0 +0100
+++ libconfuse-3.3/debian/changelog 2022-10-04 00:14:59.0 +0200
@@ -1,3 +1,10 @@
+libconfuse (3.3-2+deb11u1) bullseye; urgency=medium
+
+ * Add debian/patches/CVE-2022-40320.patch from upstream to fix a heap-based
+buffer over-read in cfg_tilde_expand (CVE-2022-40320). Closes: #1019596.
+
+ -- Aurelien Jarno Tue, 04 Oct 2022 00:14:59 +0200
+
libconfuse (3.3-2) unstable; urgency=medium
* German translation update, by Fabian Baumanis. Closes: #978117.
diff -Nru libconfuse-3.3/debian/patches/CVE-2022-40320.patch
libconfuse-3.3/debian/patches/CVE-2022-40320.patch
--- libconfuse-3.3/debian/patches/CVE-2022-40320.patch 1970-01-01
01:00:00.0 +0100
+++ libconfuse-3.3/debian/patches/CVE-2022-40320.patch 2022-09-14
22:39:16.0 +0200
@@ -0,0 +1,37 @@
+commit d73777c2c3566fb2647727bb56d9a2295b81669b
+Author: Joachim Wiberg
+Date: Fri Sep 2 16:12:46 2022 +0200
+
+Fix #163: unterminated username used with getpwnam()
+
+Signed-off-by: Joachim Wiberg
+
+diff --git a/src/confuse.c b/src/confuse.c
+index 6d1fdbd..05566b5 100644
+--- a/src/confuse.c
b/src/confuse.c
+@@ -1894,18 +1894,20 @@ DLLIMPORT char *cfg_tilde_expand(const char *filename)
+ passwd = getpwuid(geteuid());
+ file = filename + 1;
+ } else {
+- /* ~user or ~user/path */
+- char *user;
++ char *user; /* ~user or ~user/path */
++ size_t len;
+
+ file = strchr(filename, '/');
+ if (file == 0)
+ file = filename + strlen(filename);
+
+- user = malloc(file - filename);
++ len = file - filename - 1;
++ user = malloc(len + 1);
+ if (!user)
+ return NULL;
+
+- strncpy(user, filename + 1, file - filename - 1);
++ strncpy(user, [1], len);
++ user[len] = 0;
+ passwd = getpwnam(user);
+ free(user);
+ }
diff -Nru libconfuse-3.3/debian/patches/series
libconfuse-3.3/debian/patches/series
--- libconfuse-3.3/debian/patches/series2021-01-10 15:12:53.0
+0100
+++ libconfuse-3.3/debian/patches/series2022-09-14 22:39:16.0
+0200
@@ -1 +1,2 @@
de.po.patch
+CVE-2022-40320.patch
Bug#1020943: (no subject)
Hi, On 2022-10-02 06:27, Szilfai Balázs wrote: > Sorry, I attached it. Thanks a lot. For the record, here is the backtrace with the debugging symbols attached: #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x7f05dfb045df in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x7f05dfab8a02 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x7f05dfaa3469 in __GI_abort () at ./stdlib/abort.c:79 #4 0x7f05dfaa3395 in __assert_fail_base (fmt=0x7f05dfc32cd0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5629b6c94ff2 "dh->usable", file=0x5629b6c9438c "cache.c", line=425, function=) at ./assert/assert.c:92 #5 0x7f05dfab1ab2 in __GI___assert_fail (assertion=assertion@entry=0x5629b6c94ff2 "dh->usable", file=file@entry=0x5629b6c9438c "cache.c", line=line@entry=425, function=function@entry=0x5629b6c951b0 <__PRETTY_FUNCTION__.0> "prune_cache") at ./assert/assert.c:101 #6 0x5629b6c87116 in prune_cache (table=table@entry=0x5629b6c9a340 , now=, now@entry=1664656110, fd=fd@entry=-1) at ./nscd/cache.c:425 #7 0x5629b6c7c02e in nscd_run_prune (p=) at ./nscd/connections.c:1553 #8 0x7f05dfb0284a in start_thread (arg=) at ./nptl/pthread_create.c:442 #9 0x7f05dfb860ac in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1021062: libc6: nonexistent locale crashes programs (for example, bash, gdb, ...)
control: clone 1021062 -1 control: reassign -1 bash control: found -1 bash/5.2-1 Hi, On 2022-10-02 07:27, Kan-Ru Chen wrote: > reassign 1021062 libreadline8 > found 1021062 libreadline8/8.2-1 > thanks > > On Sun, Oct 2, 2022, at 1:56 AM, Aurelien Jarno wrote: > > control: reassign -1 bash > > control: found -1 bash/5.2-1 > > > > Hi, > > > > On 2022-10-01 21:01, Kan-Ru Chen wrote: > >> Package: libc6 > >> Version: 2.35-1 > >> Severity: grave > >> Justification: renders package unusable > >> X-Debbugs-Cc: kos...@debian.org > >> > >> Dear maintainer, > >> > >> After upgrading to libc6 2.35-1 (or 2.36-1 in experimental), nonexistent > >> locale setting > >> starts to crash the system. > >> > >> This is dangerous because a remote system might not always have the same > >> locale installed. > >> An auto update will soft-brick the system unless the sysadmin knows to set > >> their LC_ALL=POSIX > >> before attempting to ssh. > >> > >> Steps to reproduce: > >> > >> >From a clean installed Debian sid, upgrade to libc6 2.35-1. > >> Only install C locale and en_US.UTF-8. > >> > >> $ LC_ALL=ja_JP.UTF-8 bash > >> bash: warning: setlocale: LC_ALL: cannot change locale (ja_JP.UTF-8) > >> Segmentation fault (core dumped) > >> > >> $ LC_ALL=ja_JP.UTF-8 gdb bash > >> > >> Fatal signal: Segmentation fault > >> - Backtrace - > >> 0x55ed3e1e8dcf ??? > >> 0x55ed3e2df312 ??? > >> 0x55ed3e2df488 ??? > >> 0x7f0b4a39ba9f ??? > >> 0x7f0b4b412204 _rl_init_locale > >> 0x7f0b4b4122f1 _rl_init_eightbit > >> 0x7f0b4b3f10f2 rl_initialize > >> ... snip ... > > > > FYI, this is the full backtrace with the debug packages installed: > > > > #0 0x7f8079d0ccc7 in __GI_kill () at > > ../sysdeps/unix/syscall-template.S:120 > > #1 0x559be26519c9 in termsig_handler (sig=11) at .././sig.c:625 > > #2 0x559be2651c21 in termsig_handler (sig=) at > > .././sig.c:492 > > #3 termsig_sighandler (sig=) at .././sig.c:547 > > #4 > > #5 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74 > > #6 0x559be26b8682 in _rl_init_locale () at > > ../../.././lib/readline/nls.c:150 > > #7 0x559be26b8772 in _rl_init_eightbit () at > > ../../.././lib/readline/nls.c:227 > > #8 0x559be269766e in readline_initialize_everything () at > > ../../.././lib/readline/readline.c:1292 > > #9 rl_initialize () at ../../.././lib/readline/readline.c:1183 > > #10 0x559be2662b05 in initialize_readline () at .././bashline.c:522 > > #11 0x559be26040a5 in yy_readline_get () at > > /usr/local/src/chet/src/bash/src/parse.y:1514 > > #12 0x559be2606aa1 in yy_getc () at > > /usr/local/src/chet/src/bash/src/parse.y:1462 > > #13 shell_getc (remove_quoted_newline=remove_quoted_newline@entry=1) at > > /usr/local/src/chet/src/bash/src/parse.y:2393 > > #14 0x559be2608eeb in read_token (command=0) at > > /usr/local/src/chet/src/bash/src/parse.y:3400 > > #15 0x559be260d05b in yylex () at > > /usr/local/src/chet/src/bash/src/parse.y:2890 > > #16 yyparse () at ./build-bash/y.tab.c:1854 > > #17 0x559be2603586 in parse_command () at .././eval.c:348 > > #18 0x559be2603714 in read_command () at .././eval.c:392 > > #19 0x559be26038c6 in reader_loop () at .././eval.c:139 > > #20 0x559be26023b5 in main (argc=1, argv=0x7ffe3da22078, > > env=0x7ffe3da22088) at .././shell.c:833 > > > > So the problem is that _rl_init_locale (from bash) calls strlen(NULL). > > > >> Downgrade to 2.34-8 seems also don't fix the issue, probably some locale > >> state was invalidated when upgrading. > > > > This is because you upgraded other packages than glibc (here bash), and the > > bug > > is not in glibc. Downgrading bash fixes the issue. Reassigning the bug. > > Thanks! > > That explains why not all programs crash like this. The common library they > used is > libreadline and I confirmed downgrade libreadline8 to 8.2~rc2-2 fixed the > issue. > Reassigning to libreadline8. I did the test of downgrading bash yesterday (i.e. without downgrading libreadline8), and it fixes the issue you reported with bash. It appears that bash has an embedded copy of readline, hence the issue with both. I am therefore cloning the bug to bash. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020943: (no subject)
On 2022-10-01 22:36, Szilfai Balázs wrote: > Core dump attached. Thanks, could you please attach the following file instead of the text output? /var/lib/systemd/coredump/core.nscd.0.e89b6fce3d004f04b16f3e5a8f439a82.2560572.166465611000.zst Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020943: nscd: Segmention fault when trying to launch on Debian/testing
Hi, On 2022-09-29 09:37, Adrian Immanuel Kiess wrote: > Package: nscd > Version: 2.35-1 > Severity: normal > > Dear Maintainer, > >* What led up to the situation? > Upgrading nscd on Debian/testing >* What exactly did you do (or not do) that was effective (or > ineffective)? > apt -u dist-upgrade >* What was the outcome of this action? > nscd segfaults when trying to launch >* What outcome did you expect instead? > Working nscd > > currently on Debian/testing, nscd crashes when trying to launch. Unfortunately I am not able to reproduce this issue locally, I will therefore need some help to diagnose the problem: - Can you please share your /etc/nscd.conf? - Do you have any related message available in dmesg? > >From logwatch: > > WARNING: Segmentation Faults in these executables > nscd : 2461 Time(s) > > Here is the journalctl output: > > sept. 29 09:12:13 g6.lan.dac systemd[1]: Started Name Service Cache Daemon. > sept. 29 09:12:15 g6.lan.dac systemd[1]: nscd.service: Main process exited, > code=killed, status=11/SEGV Would it be possible to share the corresponding core dump file? Sharing it privately is also fine if you prefer. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020969: buildd.debian.org: Dell XPS 15 9520 - Boot hangs
control: reassign -1 installation-reports Hi, On 2022-09-29 20:58, Waido wrote: > Package: buildd.debian.org > Severity: important > X-Debbugs-Cc: waidoshor...@protonmail.com > > Dear Maintainer, > > I'm trying to install Debian 11.5 (Bullseye) on a notebook Dell XPS 15 9520. > The installation finished successfully but from the first boot of the > notebook on the screen appears the message > > dell_smm_hwmon: unable to get SMM Dell signature > > and the notebook hangs. I can't get to the shell prompt. > From a live distro, inside installed distro, I created the file > /etc/modprobe.d/blacklist.conf with the content > > blacklist dell-smm-hwmon > > Now the notebook boots ... and hangs without showing the previous message, > without showing any error or interesting message. The buildd.debian.org pseudo package is for bugs concerning the build daemons infrastructure, which is responsible for building packages from source for all architectures. It has nothing to do with the installer. I am therefore reassigning this to the installation-reports package, for you to get more chances to find people helping you. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1021062: libc6: nonexistent locale crashes programs (for example, bash, gdb, ...)
control: reassign -1 bash control: found -1 bash/5.2-1 Hi, On 2022-10-01 21:01, Kan-Ru Chen wrote: > Package: libc6 > Version: 2.35-1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: kos...@debian.org > > Dear maintainer, > > After upgrading to libc6 2.35-1 (or 2.36-1 in experimental), nonexistent > locale setting > starts to crash the system. > > This is dangerous because a remote system might not always have the same > locale installed. > An auto update will soft-brick the system unless the sysadmin knows to set > their LC_ALL=POSIX > before attempting to ssh. > > Steps to reproduce: > > >From a clean installed Debian sid, upgrade to libc6 2.35-1. > Only install C locale and en_US.UTF-8. > > $ LC_ALL=ja_JP.UTF-8 bash > bash: warning: setlocale: LC_ALL: cannot change locale (ja_JP.UTF-8) > Segmentation fault (core dumped) > > $ LC_ALL=ja_JP.UTF-8 gdb bash > > Fatal signal: Segmentation fault > - Backtrace - > 0x55ed3e1e8dcf ??? > 0x55ed3e2df312 ??? > 0x55ed3e2df488 ??? > 0x7f0b4a39ba9f ??? > 0x7f0b4b412204 _rl_init_locale > 0x7f0b4b4122f1 _rl_init_eightbit > 0x7f0b4b3f10f2 rl_initialize > ... snip ... FYI, this is the full backtrace with the debug packages installed: #0 0x7f8079d0ccc7 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120 #1 0x559be26519c9 in termsig_handler (sig=11) at .././sig.c:625 #2 0x559be2651c21 in termsig_handler (sig=) at .././sig.c:492 #3 termsig_sighandler (sig=) at .././sig.c:547 #4 #5 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74 #6 0x559be26b8682 in _rl_init_locale () at ../../.././lib/readline/nls.c:150 #7 0x559be26b8772 in _rl_init_eightbit () at ../../.././lib/readline/nls.c:227 #8 0x559be269766e in readline_initialize_everything () at ../../.././lib/readline/readline.c:1292 #9 rl_initialize () at ../../.././lib/readline/readline.c:1183 #10 0x559be2662b05 in initialize_readline () at .././bashline.c:522 #11 0x559be26040a5 in yy_readline_get () at /usr/local/src/chet/src/bash/src/parse.y:1514 #12 0x559be2606aa1 in yy_getc () at /usr/local/src/chet/src/bash/src/parse.y:1462 #13 shell_getc (remove_quoted_newline=remove_quoted_newline@entry=1) at /usr/local/src/chet/src/bash/src/parse.y:2393 #14 0x559be2608eeb in read_token (command=0) at /usr/local/src/chet/src/bash/src/parse.y:3400 #15 0x559be260d05b in yylex () at /usr/local/src/chet/src/bash/src/parse.y:2890 #16 yyparse () at ./build-bash/y.tab.c:1854 #17 0x559be2603586 in parse_command () at .././eval.c:348 #18 0x559be2603714 in read_command () at .././eval.c:392 #19 0x559be26038c6 in reader_loop () at .././eval.c:139 #20 0x559be26023b5 in main (argc=1, argv=0x7ffe3da22078, env=0x7ffe3da22088) at .././shell.c:833 So the problem is that _rl_init_locale (from bash) calls strlen(NULL). > Downgrade to 2.34-8 seems also don't fix the issue, probably some locale > state was invalidated when upgrading. This is because you upgraded other packages than glibc (here bash), and the bug is not in glibc. Downgrading bash fixes the issue. Reassigning the bug. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020894: glibc: Firefox 88 broken after glibc upgrade
control: found -1 2.34-1 control: found -1 2.35-1 Hi, On 2022-09-28 07:51, программист некто wrote: > Source: glibc > Version: 2.36-1 > Severity: important > > Hello. Tabs in Firefox 88 stop working after upgrade glibc to 2.36-1 from > 2.33-8. Every new opened tab immediately crashes. For security reasons, Firefox use a sandbox filter based on seccomp for the tabs processes. It explicitly lists the syscalls that can be used by the tabs processes, however as Firefox uses glibc, when glibc start using a new syscall (in your case clone3), this list needs to be updated on the Firefox side. In the case of clone3, this has been done in Firefox 91, you can find more details here: https://bugzilla.mozilla.org/show_bug.cgi?id=1715254 To continue using Firefox 88, you might want to disable the sandbox filter by setting the MOZ_DISABLE_CONTENT_SANDBOX environment variable to 1 (e.g. export MOZ_DISABLE_CONTENT_SANDBOX=1) before launching Firefox, but please be aware of the security implications. > I try to install old version glibc and found that 2.34 and 2.35 also breaks > Firefox 88. Thanks for testing older versions, I have updated the bug report to reflect that. > There is a regression in glibc. The problem is actually on the firefox side, which does not support newer glibc version. Nevertheless we'll add a Breaks against firefox and firefox-esr (<< 91) to the libc6 package to ensure smooth upgrade and prevent this bug to happen. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
Hi, On 2022-09-26 09:45, Vasudev Kamath wrote: > And post removing /usr/lib version of libc it seems to work fine and no > crash is happening. > > └─(09:44:30 on master)──> expr > > 1 ↵ ──(Mon,Sep26)─┘ > expr: missing operand > Try 'expr --help' for more information. > ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ > └─(09:44:39 on master)──> Thanks for all the details. It's great that your system is now fixed. Do you have an idea why libc6 2.34 ended up in /usr/lib/x86_64-linux-gnu? I do not see any explanation from the glibc side. Did you attempt a usrmerge migration that failed after moving some files, or do you think it's unrelated? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020705: glibc: Keep DT_HASH
control: reassign 1020705 src:gcc-12 control: forcemerge 1019535 1020705 Hi, On 2022-09-25 13:21, Jeremy Bicha wrote: > Source: glibc > Version: 2.36-1 > Tags: patch > > Please consider restoring DT_HASH in your glibc 2.36 packaging. Here's > an article with more details: > > https://lwn.net/Articles/904892/ I already filled #1019535 which I consider is the way to go, but I am opened for discussion. I am still waiting for an answer from the GCC maintainer. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
control: notfound -1 glibc/2.34-8 control: found -1 glibc/2.35-1 Hello Vasudev, On 2022-09-24 21:18, Vasudev Kamath wrote: > > > Hello Vasudev, > > ok, reverting back would explain reportbug using version 2.34-8. > > > > But was this core taken at a time where all libc packages > > should have been at 2.35-1 ? > > Then I don't understand that "Module" line, > > which shows the build-id from 2.34-8. This mail should fix the BTS version. > Ah sorry I did coredumpctl debug post reverting the libc6. But core file > attached is taken when actual 2.35 was installed. I have looked at the coredump you sent me: $ eu-unstrip -n --core core.expr.1000.d5ff83e0fd69439497afd17511de3417.85280.166392358300 0x5604c0781000+0x1e000 b919757cbc30fbb64b14498222499d972fd80acd@0x5604c0781368 . - /usr/bin/expr 0x7fbfabc0+0x201000 ef3afb43092687d7fcc8167fabdee73f4a3287f1@0x7fbfabc00380 - - /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffdc5bde000+0x1000 c35c947b072ff69b395cd326b83b24630f2c5065@0x7ffdc5bde54c . - linux-vdso.so.1 0x7fbfac04c000+0x362b8 a03c3b14d371da908a3f22007b3f0c73d1f9f634@0x7fbfac04c248 /lib64/ld-linux-x86-64.so.2 - ld-linux-x86-64.so.2 0x7fbfabfc9000+0x80bc8 25c73b398493c695a013a6d9d493a8316aac0fa0@0x7fbfabfc9248 /usr/lib/x86_64-linux-gnu/libgmp.so.10 - libgmp.so.10 ef3afb43092687d7fcc8167fabdee73f4a3287f1 => comes from libc6 version 2.34-8 a03c3b14d371da908a3f22007b3f0c73d1f9f634 => comes from libc6 version 2.35-1 So the crash is likely due to a mismatch between glibc. I believe this is due to an issue with usrmerge as the paths reported by your core file seems to show that your system is merged, while reportbug says "merged-usr: no". By using a non usrmerged system, with libc6 2.34-8 duplicated in both /lib/x86_64-linux-gnu/ and /usr/lib/x86_64-linux-gnu, and upgrading it to libc6 2.35-1, I am able to reproduce your issue with expr: $ expr *** stack smashing detected ***: terminated Aborted > > And if I understand you right the stack smashing > > is from "autoreconf --version". > > But I could not find it executing any "expr" processes in my test VM. > > Actually just invoking autoconf was crashing and just executing expr itself > was also crashing. If needed I can install latest libc and provide any > required information. Do let me know Before trying to upgrade again, we should ensure your system is in a sane state. Could you please send us the output of: ls -ld /lib ls -l /lib/x86_64-linux-gnu/libc.so.6 ls -l /usr/lib/x86_64-linux-gnu/libc.so.6 Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020683: usbutils: Please include lsusbs.py
Hi, On 2022-09-25 10:17, Sam Morris wrote: > Package: usbutils > Version: 1:014-1 > Severity: wishlist > > usbutils includes a lsusbs.py command which gives much more readable > output than lsusb. > > Looks like only 'usr/bin/lsusb.py' has to be added to debian/install to > get it included in the binary package. This is not so easy as it looks like, there are reasons for lsusb.py to not be provided in the usbutils package: - The debian policy forbids to install a script in /usr/bin with the .py extension. It can not be called lsusb given the existing binary already provided by usbutils. - lsusb.py needs python3 and the usb.ids database, so it increases the disk footprint from ~0.5MB to ~22.3MB which has a big impact for embedded systems. - lsusb.py lacks a manpage. If lsusb.py is really way more useful than lsusb, an option might be to ship it in a separate package (usbutils-py? lsusb-py?) and change the binary name (lsusb-py? lsusb-python?). Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
On 2022-09-25 12:02, debian-bug-rep...@p0358.net wrote: > > Now that we understood the bug, I actually find strange that the > > microcode update is fixing this, it looks like that the BMI2 > > instructions support has been added in a microcode update. Would it be > > possible to give the output of /proc/cpuinfo with and without the > > microcode update applied? > > The /proc/cpuinfo without microcode update is already attached somewhere > above in the bug report, the new one after update is as follows: > > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 60 > model name : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz > stepping: 3 > microcode : 0x28 > cpu MHz : 2400.000 > cache size : 3072 KB > physical id : 0 > siblings: 4 > core id : 0 > cpu cores : 2 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 13 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 > ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt > tsc_deadline_timer xsave avx f16c rdrand lahf_lm abm cpuid_fault epb > invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept > vpid ept_ad fsgsbase tsc_adjust bmi1 smep bmi2 erms invpcid xsaveopt dtherm > arat pln pts md_clear flush_l1d > vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb > flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple > bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf > mds swapgs itlb_multihit srbds > bogomips: 4788.76 > clflush size: 64 > cache_alignment : 64 > address sizes : 39 bits physical, 48 bits virtual > power management: > > Please note that "avx2" is once again missing due to the kernel masking flag > from before that I once again forgot to remove before rebooting, and sorry > for confusion it might cause -- that flag would normally be there. > > Running a quick diff against old procinfo reveals that "flags" has the > following new entries now: > > tsc_deadline_timer ssbd ibrs ibpb stibp bmi1 bmi2 md_clear flush_l1d > > > it looks like that the BMI2 > > instructions support has been added in a microcode update > > As such it does appear that indeed this is the case. Thanks for the confirmation, it seems that the microcode update is also useful for security reasons in order to mitigate the speculative execution side channel issues (the famous spectre/meltdown). Neverthless the AVX2 code should not use BMI2 instructions if they are not available. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
On 2022-09-25 00:35, debian-bug-rep...@p0358.net wrote: > Hello, sorry for delayed response, I've managed to collect and analyze a few > coredump files with valid symbols (I installed libc6-dbg and dpkg-dev, and > pointed gdb at Debian's debuginfod server, also used apt-get source to get > the sources for libc6). Thanks a lot for your work. With more data, it's way easier to understand the issue. > It seems there are at least 3-4 distinct places it crashes at, two places at > memchr-avx2.S, one at strlen-avx2.S, and potentially one at > syscall-template.S, although that last one may be just some kind of kill > signal redirect. The failing places in memchr-avx2.S and strlen-avx2.S points to BMI2 (bit manipulation instructions) which have been introduced in the AVX2 code, which should not have happened. The syscall-template.S is likely code that catches the signal to display a message and then re-emit it. > It does seem in case of this SIGILL there's no additional stack trace, also > the path containing ".." seems to cause the source code resolution to fail, > but still the debug symbols seem to show the file source and line, so it > should hopefully help see what exactly fails. > > I'm yet to try rebooting with microcode package installed though (I'll soon > check it and update on whether it helps, but even if it does, one without > bootable system first won't get a chance to install it; I'm a bit curious > how these changes did trigger this, given all these years it didn't happen > to occur before) I agree with you that this should be fixed without a microcode update, I am going to report that issue upstream and we'll get the fix in the Debian package. Now that we understood the bug, I actually find strange that the microcode update is fixing this, it looks like that the BMI2 instructions support has been added in a microcode update. Would it be possible to give the output of /proc/cpuinfo with and without the microcode update applied? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020654: C.UTF-8: surprising differences in character classes
Hi, On 2022-09-24 23:16, Thorsten Glaser wrote: > Package: locales > Version: 2.35-1 > Severity: normal > X-Debbugs-Cc: t...@mirbsd.de > > While adjusting my localedata patch script to the latest glibc uploads > I discovered a surprising difference in some categories — for example: Starting with glibc 2.35, we do not patch the glibc to add C.UTF-8 support, instead we use the upstream code which comes with the following NEWS entry [1]: * Support for the C.UTF-8 locale has been added to glibc. The locale supports full code-point sorting for all valid Unicode code points. A limitation in the framework for fnmatch, regexec, and regcomp requires a compromise to save space and only ASCII-based range expressions are supported for now (see bug 28255). The full size of the locale is only ~400KiB, with 346KiB coming from LC_CTYPE information for Unicode. This locale harmonizes downstream C.UTF-8 already shipping in various downstream distributions. The locale is not built into glibc, and must be installed. The point of having it merged upstream, is that all distributions will now use the same definition for the C.UTF-8 locale, which was not the case before. > (sid-amd64)tglase@tglase:~ $ LC_ALL=C ./tstspc > U+0009 > U+000A > U+000B > U+000C > U+000D > U+0020 > (sid-amd64)tglase@tglase:~ $ LC_ALL=C.UTF-8 ./tstspc > U+0009 > U+000A > U+000B > U+000C > U+000D > U+0020 > U+1680 > U+2000 > U+2001 > U+2002 > U+2003 > U+2004 > U+2005 > U+2006 > U+2008 > U+2009 > U+200A > U+2028 > U+2029 > U+205F > U+3000 This is expected given the LC_CTYPE information used for the C.UTF-8 comes from Unicode. > The test program is thus: gcc -O2 -Wall -Wextra -Wformat -o tstspc tstspc.c > > //cut-here-- [snip] > //cut-here-- > > > In my localedata patch script, I take specific care to change the > copy of i18n_ctype before applying it to C.UTF-8 as follows: > > space → ..; > cntrl → ..; > blank → ; > > They are as mandated by POSIX for the C locale. I believe I said > in my original 2013 proposal for a C.UTF-8 locale that it should > be as close to C as possible while using UTF-8 as encoding. Those are mandated for the POSIX C locale, but POSIX does not say anything (yet) about the C.UTF-8 locale. The choice made by upstream has been discussed during many years [2], if you disagree with it, please come back to upstream. Regards Aurelien [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=faa7ec1871da1a34ed943fd8d406496e58fb2c2e;hb=f94f6d8a3572840d3ba42ab9ace3ea522c99c0c2 [2] https://sourceware.org/glibc/wiki/Proposals/C.UTF-8 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
Hi, On 2022-09-23 21:28, Bernhard Übelacker wrote: > On Fri, 23 Sep 2022 14:45:07 +0530 Vasudev Kamath wrote: > > Package: libc6 > > Version: 2.34-8 > > > I upgraded libc6 to latest released 2.35-1 > > > Module ld-linux-x86-64.so.2 with build-id > > a03c3b14d371da908a3f22007b3f0c73d1f9f634 > > Module libc.so.6 with build-id > > ef3afb43092687d7fcc8167fabdee73f4a3287f1 > > Module libgmp.so.10 with build-id > > 25c73b398493c695a013a6d9d493a8316aac0fa0 > > Module expr with build-id > > b919757cbc30fbb64b14498222499d972fd80acd > > > > Versions of packages libc6 suggests: > > ii debconf [debconf-2.0] 1.5.79 > > pn glibc-doc > > ii libc-l10n 2.35-1 > > ii libnss-nis 3.1-4 > > ii libnss-nisplus 1.3-4 > > ii locales2.35-1 > > > > Hello Vasudev, > I wonder if this libc6 installation is completed. > Because the bug report mentions version 2.34-8 from testing, > but e.g. locales and libc-l10n is 2.35-1. > > Also searching for a package containing the debug information > for the build-id from the modules listing returns currently > the version 2.34-8 from testing. > > But the build-id for ld-linux-x86-64.so.2 points to 2.35-1. > > Maybe the libc package installation got interrupted? Good catch. I also noticed that the libraries seems to be located in /usr/lib/x86_64-linux-gnu/, which is typical of a usrmerge system, but reportbug says "merged-usr: no". Vasudev, you should probably check that you do not have too versions of the glibc on your system, one in /lib/x86_64-linux-gnu/ and another one in /usr/lib/x86_64-linux-gnu/ without the /lib -> usr/lib symlink. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1019845: transition: glibc 2.35
On 2022-09-22 23:51, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2022-09-18 10:11:58 +0200, Sebastian Ramacher wrote: > > Control: forwarded -1 > > https://release.debian.org/transitions/html/glibc-2.35.html > > > > On 2022-09-14 22:17:47 +0200, Aurelien Jarno wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > X-Debbugs-Cc: debian-gl...@lists.debian.org > > > > > > Dear release team, > > > > > > I would like to get a transition slot for glibc 2.35. It has been > > > available in experimental for one month and does not have any known > > > major issue. It has been built successfully on all release architectures > > > and many ports architectures. A few issues found through the autopkgtest > > > pseudo excuses for experimental have been fixed. The remaining ones are > > > due to britney bugs, broken autopkgtest or packages parts of the > > > transition. > > > > > > As glibc is using symbol versioning, there is no soname change. That > > > said a few packages are using libc internal symbols and have to be > > > rebuilt for this transition. Here is the corresponding ben file: > > > > > > title = "glibc"; > > > is_affected = .depends ~ /libc[0-9.]* \(< > > is_good = .depends ~ /libc[0-9.]* \(<< 2.36\)/; > > > is_bad = .depends ~ /libc[0-9.]* \(<< 2.35\)/; > > > > > > In addition a few new symbols have been added that might prevent a few > > > other packages to migrate to testing until glibc migrates if they pick > > > up the new symbols, however those are really limited in this version and > > > mostly linked to the new math functions introduced for ISO C2x support, > > > so unlikely to be massively used by default. Therefore overall this > > > transition should be way simpler than the glibc 2.34 one. > > > > > > Thanks for considering. > > > > Let's start with this one after the udeb block is lifted and the D-I > > alpha is done. > > The udeb block was lifted. Please go ahead. Thanks. I have uploaded it it, but it seems to be stuck in a dinstall that takes a lot of time. I guess it'll be there (and maybe built on some architectures) when I wake up tomorrow :) Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
Hi, Have you been able to progress on that? Do you need some help for a specific step? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
nately, not that easily unless you want to compile the upstream sources. As you pointed, the changes are very likely related to the AVX2 changes, so having the address of the illegal instruction would help a lot to understand the issue. > This machine, in case it matters, is a Lenovo G510 laptop. There is some > update available for the BIOS, but it requires booting up Windows to perform > it. Should I attempt that? I found some ancient thread on some forum that > mentioned BIOS update fixes some issues with "freezes" on As said above, I find strange that the problem has not been noticed yet given it affects at least two distributions, and that it dates from a few months in sid. You might want to install the intel-microcode package and reboot to see if it helps, it should have the same effects than updating the BIOS for the point of view of the current bug. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
Hi, On 2022-09-15 01:37, debian-bug-rep...@p0358.net wrote: > Package: libc6 > Version: 2.31-13+deb11u4 > Severity: critical > > Dear Maintainer, > > After an upgrade to version +deb11u4 on my system running Haswell > (4th gen Intel Core) CPU, most of the programs including bash or dpkg > are immediately crashing with SIGILL. The problem seems to be caused/ > related to AVX2 and changes made to some functions utilizing this > instruction set. I don't know much about Debian bug reporting, so forgive me > any mistakes I've made. > The issue is on both host, LXC and Docker. > I have described more on this link: > https://github.com/debuerreotype/docker-debian-artifacts/issues/175 > where I also linked my coredump from example program and described stuff > more thoroughly. First of all, sorry about the issue, it should not have slipped in a stable release. Unfortunately I am not able to reproduce the issue. I have tried on 3rd gen or 5th gen Intel Core CPUs, but failed to reproduce it. Therefore I will need your help to understand the issue. The first thing would be to provide the output of /proc/cpuinfo > Coredump link directly just in case: > https://github.com/debuerreotype/docker-debian-artifacts/files/9569748/core.bash.10.2663c40e671041e6b40c882a70b83c3f.1480736.166318582400.zip Unfortunately I am not able to use this core dump to get the instruction that trigger the SIGILL, even after installing debug symbols packages. > Also log lines from kernel: > kernel: [834669.721253] traps: dpkg[1455373] trap invalid opcode > ip:7fa39701951d sp:7ffc4ad26e58 error:0 in libc-2.31.so[7fa396edd000+15a000] > kernel: [834669.732958] traps: dpkg[1455374] trap invalid opcode > ip:7f529ca9551d sp:7fffb6f0a238 error:0 in libc-2.31.so[7f529c959000+15a000] > kernel: [834669.840128] traps: dpkg[1455375] trap invalid opcode > ip:7f1874cc951d sp:7fffc2c2f5d8 error:0 in libc-2.31.so[7f1874b8d000+15a000] > kernel: [834669.907918] traps: dpkg[1455378] trap invalid opcode > ip:7f3b4f8d851d sp:7fff3ec970f8 error:0 in libc-2.31.so[7f3b4f79c000+15a000] > kernel: [834712.152139] traps: passwd[1455693] trap invalid opcode > ip:7fefee4b52b7 sp:7cb506b8 error:0 in libc-2.31.so[7fefee37d000+15a000] Same from there due to ASLR. It seems to fail in at least two different locations. Do you have some extra lines around, sometimes the kernel dump the addresses around the instruction pointer? > Not sure what exactly might be causing the issue, but if these changes > aren't pulled, potentially anyone with this or similar CPU as me will > upgrade and end up with bricked system. The changes that are in this stable release have been (or at least were supposed to, given the bug you reported) in testing/sid for a few months. Are you able to do a test with debian sid, for instance in docker? > I will proceed to try using `clearcpuid=293` kernel flag myself, but > consider how many distros depend on Debian, live CDs etc, with people unable > to figure out why their system became useless, unable to trace the source, > and blaming it just on Linux... If you believe the issue is due to AVX2, clearcpuid won't help, as it just clear the corresponding flags from the kernel point of view, but the cpuid instruction will just continue to behave the same. The way to do disable that features at the glibc level is to set the GLIBC_TUNABLES environment variable to "glibc.cpu.hwcaps=-AVX2_Usable". Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1019845: transition: glibc 2.35
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-gl...@lists.debian.org Dear release team, I would like to get a transition slot for glibc 2.35. It has been available in experimental for one month and does not have any known major issue. It has been built successfully on all release architectures and many ports architectures. A few issues found through the autopkgtest pseudo excuses for experimental have been fixed. The remaining ones are due to britney bugs, broken autopkgtest or packages parts of the transition. As glibc is using symbol versioning, there is no soname change. That said a few packages are using libc internal symbols and have to be rebuilt for this transition. Here is the corresponding ben file: title = "glibc"; is_affected = .depends ~ /libc[0-9.]* \(<
Bug#1018799: gcc-12: Workround for fixing -latomic issue on riscv64 after glibc2.34
Hi,
On 2022-09-06 09:56, Bo YU wrote:
> Hi,
> On Wed, Aug 31, 2022 at 07:04:53PM +0200, Aurelien Jarno wrote:
> ...
> > reason for limiting the link with -latomic to pthread, but that has been
> > discussed internally before the patch submission to GCC, and has been
> > lost.
> >
> > Anyway this is probably something to try, but the way is done in Arch,
> > i.e. patching the binaries, is ugly. It's probably better to patch the
> > sources that way (completely untested):
> >
> > diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
> > --- a/gcc/config/riscv/linux.h
> > +++ b/gcc/config/riscv/linux.h
> > @@ -40,7 +40,7 @@ along with GCC; see the file COPYING3. If not see
> > #undef LIB_SPEC
> > #ifdef LD_AS_NEEDED_OPTION
> > #define LIB_SPEC GNU_USER_TARGET_LIB_SPEC \
> > - " %{pthread:" LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION "}"
> > + LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION
> > #else
> > #define LIB_SPEC GNU_USER_TARGET_LIB_SPEC " -latomic "
> > #endif
>
> I have built gcc-12 debian packages with your help and patch:
> https://drive.google.com/drive/folders/1jdqA9mrBea0BHhePVSHkPPOYo6pc7-dq?usp=sharing
>
> I tried it once but it doesn't seem to solve the problem. But there is a
> high probability that there is something wrong with my testing method:
>
> I installed gcc-12/g++-12 by manual on a clean riscv64 chroot and then
> try build thinkfan[0] with dpkg-buildpackage.
>
> I was wondering if it would be simpler to directly manipulate atomic
> statements in a c program also. Or could you help to verify it work or
> not again? The patch attached is full change at this time.
I confirm that the issue is still there, it seems that the patch is not
applied. The way to verify it is calling gcc -dumpspecs.
I have tried to rebuild gcc with the patch, and I ended up with the
attached patch, which is a slightly modified version of what I sent you.
Unfortunately it doesn't build. It appears that latomic is not built as
part of the gcc bootstrap process, so the gcc binary from stage 1 simply
doesn't work due to the lack of libatomic... I guess this is 1) why that
flag is only enabled for pthread 2) why gentoo is patching the binary
instead.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru gcc-12-12.2.0/debian/changelog gcc-12-12.2.0/debian/changelog
--- gcc-12-12.2.0/debian/changelog 2022-09-08 13:52:13.00000 +
+++ gcc-12-12.2.0/debian/changelog 2022-09-11 11:58:07.0 +
@@ -1,3 +1,9 @@
+gcc-12 (12.2.0-2+latomic) UNRELEASED; urgency=medium
+
+ * Try to always link with libatomic.
+
+ -- Aurelien Jarno Sun, 11 Sep 2022 11:58:07 +
+
gcc-12 (12.2.0-2) unstable; urgency=medium
* Update to git 20220908 from the gcc-12 branch.
diff -Nru gcc-12-12.2.0/debian/patches/gcc-riscv64-latomic.diff
gcc-12-12.2.0/debian/patches/gcc-riscv64-latomic.diff
--- gcc-12-12.2.0/debian/patches/gcc-riscv64-latomic.diff 1970-01-01
00:00:00.0 +
+++ gcc-12-12.2.0/debian/patches/gcc-riscv64-latomic.diff 2022-09-11
11:58:07.0 +
@@ -0,0 +1,14 @@
+# DP: Always link with -latomic on riscv64, even if -pthread is not used. Since
+# glibc 2.34, cmake does not use -pthread anymore.
+
+--- a/src/gcc/config/riscv/linux.h
b/src/gcc/config/riscv/linux.h
+@@ -40,7 +40,7 @@ along with GCC; see the file COPYING3. If not see
+ #undef LIB_SPEC
+ #ifdef LD_AS_NEEDED_OPTION
+ #define LIB_SPEC GNU_USER_TARGET_LIB_SPEC \
+- " %{pthread:" LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION "}"
++ " " LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION
+ #else
+ #define LIB_SPEC GNU_USER_TARGET_LIB_SPEC " -latomic "
+ #endif
diff -Nru gcc-12-12.2.0/debian/rules.patch gcc-12-12.2.0/debian/rules.patch
--- gcc-12-12.2.0/debian/rules.patch2022-08-22 07:44:25.0 +
+++ gcc-12-12.2.0/debian/rules.patch2022-09-11 11:58:01.0 +
@@ -61,6 +61,7 @@
musl-ssp \
pr79724-revert \
pr104290-followup \
+ gcc-riscv64-latomic \
ifneq (,$(filter $(distrelease),precise xenial bionic focal groovy hirsute))
debian_patches += pr100067-revert
signature.asc
Description: PGP signature
Bug#1019535: gcc-12: please change the default hash style to both
Source: gcc-12 Version: 12-20220319-1 Severity: important X-Debbugs-Cc: debian-gl...@lists.debian.org Dear maintainer, GCC in Debian is patched [1] to force ld to use the DT_GNU_HASH hash table using --hash-style=gnu, instead of the default --hash-style=both which includes both the DT_HASH and DT_GNU_HASH hash tables. The GNU libc was explicitly forcing --hash-style=both, but starting with glibc 2.36 it does not enforce that anymore, and thus rely on the system default. On systems using the default "both" hash style like in the upstream GCC it does not change anything, but on systems that have changed the default to "gnu", this causes issue with at least the "Easy Anti-Cheat" system [3]. It appears that that DT_HASH hash table is still mandatory in the Generic System V Application Binary Interface [4] although this might change. Given that I wonder if the default hash-style in GCC should be changed back to the default --hash-style=both. On a side note, I wonder if the default change should be made on the binutils side (using the --enable-default-hash-style= option), instead of patching the upstream GCC sources. Regards Aurelien [1] https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/patches/gcc-hash-style-gnu.diff [2] https://sourceware.org/git/?p=glibc.git;a=patch;h=e47de5cb2d4dbecb58f569ed241e8e95c568f03c [3] https://sourceware.org/bugzilla/show_bug.cgi?id=29456 [4] https://groups.google.com/g/generic-abi/c/th5919osPAQ
Bug#1017832: dh-lua causes FTBFS error with glibc 2.35 due to catchsegv removal
Hi Paul, On 2022-09-04 07:52, Paul Gevers wrote: > Hi Aurelien, > > On Sat, 3 Sep 2022 11:36:07 +0200 Aurelien Jarno wrote: > > On 2022-08-21 11:49, Aurelien Jarno wrote: > > > dh-lua uses catchsegv, a binary currently provided by libc-bin when > > > executing the lua tests. This binary has been removed from glibc 2.35, > > > causing debci [1] or FTBFS failures on packages using dh-lua. > > > > I have attached a patch that stops wrapping test commands with > > > catchsegv, fixing the debci and FTBFS issue. Could you please schedule > > > an upload with this patch? > > > > First of all, I am very sorry to be a bit pushy there. This is the last > > fix needed before we can start the glibc 2.35 transition. > > To be honest, I don't think you need to be sorry here. glibc is way to > important to not be allowed to be pushy sometimes. Thanks for take so good > care of it. I really appreciate all the preparation you do before uploading > to unstable. > > > I have uploaded a NMU fixing this issue to DELAYED/15. Please find the > > corresponding debdiff attached. Also please feel free to ask me to delay > > or cancel this NMU. > > With my Release Manager hat on, I think it's quite OK to speed this up 10 > days (and preferably the maintainers just ack the change and you drop the > delay). Thanks for the hint, I have just done that. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1017832: dh-lua causes FTBFS error with glibc 2.35 due to catchsegv removal
control: tag -1 +pending Dear maintainer(s), On 2022-08-21 11:49, Aurelien Jarno wrote: > Source: dh-lua > Version: 27 > Severity: important > Tags: patch > User: debian-gl...@lists.debian.org > Usertags: glibc2.35 > > Dear maintainer(s), > > dh-lua uses catchsegv, a binary currently provided by libc-bin when > executing the lua tests. This binary has been removed from glibc 2.35, > causing debci [1] or FTBFS failures on packages using dh-lua. > > I have attached a patch that stops wrapping test commands with > catchsegv, fixing the debci and FTBFS issue. Could you please schedule > an upload with this patch? First of all, I am very sorry to be a bit pushy there. This is the last fix needed before we can start the glibc 2.35 transition. I have uploaded a NMU fixing this issue to DELAYED/15. Please find the corresponding debdiff attached. Also please feel free to ask me to delay or cancel this NMU. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net diff -Nru dh-lua-27/debian/changelog dh-lua-27+nmu1/debian/changelog --- dh-lua-27/debian/changelog 2020-06-30 18:22:21.0 +0200 +++ dh-lua-27+nmu1/debian/changelog 2022-09-03 11:25:48.0 +0200 @@ -1,3 +1,11 @@ +dh-lua (27+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * make/dh-lua.Makefile.single: stop wrapping commands through catchsegv +(closes: #1017832). + + -- Aurelien Jarno Sat, 03 Sep 2022 09:25:48 + + dh-lua (27) unstable; urgency=medium * Upload to unstable since Lua 5.4 is finally released. diff -Nru dh-lua-27/make/dh-lua.Makefile.single dh-lua-27+nmu1/make/dh-lua.Makefile.single --- dh-lua-27/make/dh-lua.Makefile.single 2020-06-30 18:22:21.0 +0200 +++ dh-lua-27+nmu1/make/dh-lua.Makefile.single 2022-09-03 11:25:39.0 +0200 @@ -307,35 +307,35 @@ test-lua-dynamic-real: @echo "** lua dynamic ($(LUA_VERSION)) *" - $(H)$(call run_multiple_tests,$(LUA_TEST),catchsegv $(LUA) -l$(LUA_MODNAME)) + $(H)$(call run_multiple_tests,$(LUA_TEST),$(LUA) -l$(LUA_MODNAME)) @echo "**" test-lua-dynamic-real-custom: @echo "** lua dynamic custom ($(LUA_VERSION)) **" - $(H)$(call run_custom_test,$(LUA_TEST_CUSTOM),catchsegv $(LUA)) + $(H)$(call run_custom_test,$(LUA_TEST_CUSTOM),$(LUA)) @echo "*" test-lua-dynamic-apkgt-real: @echo " lua dynamic ($(LUA_VERSION), autopkgtest) *" $(H)$(call run_multiple_tests,\ - $(LUA_TEST),catchsegv $(LUA) -l$(LUA_MODNAME),_apkgt) + $(LUA_TEST),$(LUA) -l$(LUA_MODNAME),_apkgt) @echo "**" test-lua-dynamic-apkgt-real-custom: @echo "* lua dynamic custom ($(LUA_VERSION), autopkgtest) **" - $(H)$(call run_custom_test,$(LUA_TEST_CUSTOM),catchsegv $(LUA),_apkgt) + $(H)$(call run_custom_test,$(LUA_TEST_CUSTOM),$(LUA),_apkgt) @echo "*" test-app-static-real: $(UID)/app-static @echo "*** app static ($(LUA_VERSION)) *" - $(H)$(call run_multiple_tests,$(LUA_TEST),catchsegv $(UID)/app-static) + $(H)$(call run_multiple_tests,$(LUA_TEST),$(UID)/app-static) @echo "**" test-app-dynamic-real: $(UID)/app-dynamic @echo "** app dynamic ($(LUA_VERSION)) *" $(H)$(call run_multiple_tests,$(LUA_TEST),\ $(LBTL) --mode=execute -dlopen $(UID)/$(LIBNAME).la \ - catchsegv $(UID)/app-dynamic) + $(UID)/app-dynamic) @echo "**" ifneq "$(DEB_HOST_ARCH)" "$(DEB_BUILD_ARCH)" signature.asc Description: PGP signature
Bug#1018881: glibc: iconv not working properly on m68k and sh4
control: tag -1 + unreproducible On 2022-09-02 07:29, John Paul Adrian Glaubitz wrote: > Hi! > > On 9/1/22 23:59, Aurelien Jarno wrote: > > The problem is that the > > /usr/lib/m68k-linux-gnu/gconv/gconv-modules.cache file is somehow > > truncated for the glibc 2.34 build. Running iconvconfig by hand to > > generate it fixes the issue. > > > > It seems to be the right size for the glibc 2.35 build. > > Yes, running iconvconfig manually fixes the problem indeed. Now I just > need to figure out why the file is truncated in the first place. I ran a build on mitchy.debian.net and the file is correctly generated. Is there anything different on the buildds? Cheers, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1018881: glibc: iconv not working properly on m68k and sh4
Hi, On 2022-09-01 12:41, John Paul Adrian Glaubitz wrote: > Source: glibc > Version: 2.34-7 > Severity: normal > User: debian-sup...@lists.debian.org > Usertags: m68k sh4 > X-Debbugs-Cc: debian-...@lists.debian.org,debian-sup...@lists.debian.org > > Hello! > > iconv stopped working on m68k and sh4 starting with glibc 2.34 and > I have no clue why. The issue can be reproduced on real hardware > qemu-user and qemu-system. > > The problem becomes visible when the configure script of the gettext > package is being run on the affected architectures: > > checking for iconv... yes > checking for working iconv... no > checking for iconv declaration... > extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, > char * *outbuf, size_t *outbytesleft); > checking for inttypes.h... (cached) yes > checking for limits.h... (cached) yes > > The configure script runs a small program which I have extracted and > attached to this bug report as iconv.c. > > Running it on amd64 returns a zero exit code: > > (sid-amd64-sbuild)root@nofan:/# gcc -o iconv iconv.c -lc > (sid-amd64-sbuild)root@nofan:/# ./iconv > (sid-amd64-sbuild)root@nofan:/# echo $? > 0 > (sid-amd64-sbuild)root@nofan:/# > > On m68k and sh4, the exit code is 16 which is why the above configure > check fails: > > glaubitz@tirpitz:~$ uname -a > Linux tirpitz 5.11.0-rc4-00012-g10c03c5bf422 #161 PREEMPT Mon Jan 18 21:10:17 > CET 2021 sh4a GNU/Linux > glaubitz@tirpitz:~$ gcc -o iconv iconv.c -lc > glaubitz@tirpitz:~$ ./iconv > glaubitz@tirpitz:~$ echo $? > 16 > glaubitz@tirpitz:~$ The problem is that the /usr/lib/m68k-linux-gnu/gconv/gconv-modules.cache file is somehow truncated for the glibc 2.34 build. Running iconvconfig by hand to generate it fixes the issue. It seems to be the right size for the glibc 2.35 build. > I have run out of ideas why iconv fails, so I was wondering whether this might > be a packaging issue. I have found a similar iconv issue being discussed on a > Fedora mailing list where the cause was iconv data being moved out of the main > glibc packages [1]. > > Maybe we have a similar problem in Debian which manifests on m68k and sh4 only > due to some reverse dependencies being out of date? Not his is unrelated, we haven't changed that part of the packaging. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1018845: bullseye-pu: package sbuild/0.81.2+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
For a few days, dak started to use a quoted-printable transfer encoding.
This means that the Subject header can't be interpreted directly and
needs to be decoded first. This also means that the Content-Type header
has to be preserved when forwarding mails.
[ Impact ]
Packages don't get cleaned on the buildds, mails from dak that are
forwarded to the buildd maintainers (e.g. package rejection) are
mangled.
[ Tests ]
The code has been running on ppc64el-osuosl-01.d.o for a few days.
[ Risks ]
Code is rather simple and only touches 3 lines of code.
[ 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 ]
* Buildd::Mail: support MIME encoded Subject: header
This decode the Subject: header using the Encode::from_to perl function,
which handle both base64 and quoted-printed, so should work even if dak
switch to base64.
* Buildd::Mail: also copy the Content-Type: header when forwarding mail
This makes sures that the Content-Type: header is forwarded with the
mail, otherwise the mail is not interpreted correctly by the admin's
mailer.
[ Other info ]
Given the changes where minimal, I have already uploaded the package to
the archive.
diff -Nru sbuild-0.81.2/debian/changelog sbuild-0.81.2+deb11u1/debian/changelog
--- sbuild-0.81.2/debian/changelog 2021-01-31 14:34:54.0 +
+++ sbuild-0.81.2+deb11u1/debian/changelog 2022-08-31 19:59:38.0
+
@@ -1,3 +1,11 @@
+sbuild (0.81.2+deb11u1) bullseye; urgency=medium
+
+ [ Aurelien Jarno ]
+ * Buildd::Mail: support MIME encoded Subject: header
+ * Buildd::Mail: also copy the Content-Type: header when forwarding mail
+
+ -- Aurelien Jarno Wed, 31 Aug 2022 21:59:38 +0200
+
sbuild (0.81.2) unstable; urgency=medium
* Package sbuild-qemu should be arch:all, not arch:amd64.
diff -Nru sbuild-0.81.2/lib/Buildd/Mail.pm
sbuild-0.81.2+deb11u1/lib/Buildd/Mail.pm
--- sbuild-0.81.2/lib/Buildd/Mail.pm2021-01-31 14:34:54.0 +
+++ sbuild-0.81.2+deb11u1/lib/Buildd/Mail.pm2022-08-31 19:59:38.0
+
@@ -34,6 +34,7 @@
use File::Basename;
use MIME::QuotedPrint;
use MIME::Base64;
+use Encode;
BEGIN {
use Exporter ();
@@ -148,6 +149,7 @@
goto forward_mail if !$self->get('Mail Header')->{'subject'};
my $subject = $self->get('Mail Header')->{'subject'};
+Encode::from_to($subject, "MIME-Header", "utf-8");
if ($subject =~ /^Re: Log for \S+ build of (\S+)(?: on [\w-]+)?
\(dist=(\S+)\)/i) {
# reply to a build log
@@ -466,6 +468,7 @@
($header->{'reply-to'} ? "Reply-To:
$header->{'reply-to'}\n" : "").
($header->{'in-reply-to'} ? "In-Reply-To:
$header->{'in-reply-to'}\n" : "").
($header->{'references'} ? "References:
$header->{'references'}\n" : "").
+ ($header->{'content-type'} ? "Content-Type:
$header->{'content-type'}\n": "").
"Resent-From: $Buildd::gecos
<$Buildd::username\@$Buildd::hostname>\n".
"Resent-To: " . $self->get_conf('ADMIN_MAIL') . "\n\n".
$self->get('Mail Body Text') );
