Processed: Re: Bug#1110125: glibc: FTBFS on hurd-amd64 and hurd-i386 on post-build tests failures

Processing control commands: > tag -1 + pending Bug #1110125 [src:glibc] glibc: FTBFS on hurd-amd64 and hurd-i386 on post-build tests failures Added tag(s) pending. -- 1110125: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110125 Debian Bug Tracking System Contact ow...@bugs.debian.org wit

Re: Bug#1108193: apt: Ordering issue with libc6:i386 on amd64-m-a system breaks partial upgrade ("just apt and dpkg") from bookworm to trixie

triggers, so in later dist-upgrades the cycle at hand is expected to disappear. If we are trying to relax it, we'd have to re-add code for restarting systemd to libc6.postinst: if the installed systemd does not support triggers; then # Expect a bookworm systemd: # * If it

Re: Bug#1108193: apt: Ordering issue with libc6:i386 on amd64-m-a system breaks partial upgrade ("just apt and dpkg") from bookworm to trixie

t. We observe that we do not expect to bump the > > Breaks version in forky as it is an artifact of transitioning to dpkg > > triggers, so in later dist-upgrades the cycle at hand is expected to > > disappear. If we are trying to relax it, we'd have to re-add code for > >

Re: Bug#1108193: apt: Ordering issue with libc6:i386 on amd64-m-a system breaks partial upgrade ("just apt and dpkg") from bookworm to trixie

r dist-upgrades the cycle at hand is expected to > disappear. If we are trying to relax it, we'd have to re-add code for > restarting systemd to libc6.postinst: > > if the installed systemd does not support triggers; then > # Expect a bookworm systemd: > #

Re: Bug#1108193: apt: Ordering issue with libc6:i386 on amd64-m-a system breaks partial upgrade ("just apt and dpkg") from bookworm to trixie

shall ensure that systemd ends up being restarted, but what also does is require that systemd.postinst is run before libc6.postinst. We observe that we do not expect to bump the Breaks version in forky as it is an artifact of transitioning to dpkg triggers, so in later dist-upgrades the cycle a

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

Hello fellow developers, On Sun, Apr 13, 2025 at 05:25:59PM +0200, Helmut Grohne wrote: > All of the perl ones have been filed and gregor already fixed (thanks!) > a significant fraction including all 11 perl-xs-dev ones. I > guess that on third of these is fixed in git or unstable. I guess half

Processed: Re: mdadm: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

Processing commands for cont...@bugs.debian.org: > retitle 1103448 glibc: [INTL:pt_BR] debconf templates translation Bug #1103448 [mdadm] mdadm: [INTL:pt_BR] Brazilian Portuguese debconf templates translation Changed Bug title to 'glibc: [INTL:pt_BR] debconf templates translation' from 'mdadm: [

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

Hello fellow developers, On Thu, Apr 10, 2025 at 07:37:32AM +0200, Helmut Grohne wrote: > how about libc6-dev stops depending on libcrypt-dev? with minor disagreement in details, I have received much positive feedback and therefore moved forward. > So far so good. That's 1 + 95 + 11 + 1 = 108 so

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

Hi, On 2025-04-10 07:37, Helmut Grohne wrote: > Hello fellow developers, [ Snip ] > Question 1: Do you see important aspects missed in this analysis? No > Question 2: Do you agree that this change is worth the effort? I don't know. I do not see a huge benefit from the glibc point of view, bu

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

Hi Marco, On Thu, Apr 10, 2025 at 11:01:24AM +0200, Marco d'Itri wrote: > On Apr 10, Helmut Grohne wrote: > > how about libc6-dev stops depending on libcrypt-dev? > Sure. Thanks for the feedback. > > material of course. Also libc6-dev would still "Recommends: > > libcrypt-dev", but libcrypt-de

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

On Apr 10, Helmut Grohne wrote: how about libc6-dev stops depending on libcrypt-dev? Sure. material of course. Also libc6-dev would still "Recommends: libcrypt-dev", but libcrypt-dev would no longer be build-essential. What purpose would this Recommends solve? Assuming "no" and "yes" as a

Processed: Re: Bug#1089636: libcap2: FTBFS due to test suite failure on powerpc

Processing control commands: > reassign -1 libcap2 Bug #1089636 [glibc] glibc-2.40 printf() segfaults on mips64el, powerpc Bug reassigned from package 'glibc' to 'libcap2'. Ignoring request to alter found versions of bug #1089636 to the same values previously set Ignoring request to alter fixed v

Processed: Re: Bug#1089636: libcap2: FTBFS due to test suite failure on powerpc

Processing control commands: > reassign -1 glibc Bug #1089636 [libcap2] libcap2: FTBFS due to test suite failure on mips64el, powerpc Bug reassigned from package 'libcap2' to 'glibc'. No longer marked as found in versions libcap2/1:2.66-5 and libcap2/1:2.75-2. Ignoring request to alter fixed vers

Processed: Re: Bug#1100805: gcc-14 version 14.2.0-18 causes glibc to be miscompiled on armhf

Processing control commands: > clone -1 -2 Bug #1100805 [gcc-14] gcc-14 version 14.2.0-18 causes glibc to be miscompiled on armhf Bug 1100805 cloned as bug 1100821 > reassign -2 src:glibc Bug #1100821 [gcc-14] gcc-14 version 14.2.0-18 causes glibc to be miscompiled on armhf Bug reassigned from p

Processed: Re: Bug#1100544: reopening, c-t-b-mipsen is still unfixed

Processing control commands: > reassign -1 cross-toolchain-base-mipsen Bug #1100544 [libc6-dev-i386] glibc adds some conflicts letting gcc-14-cross ftbfs Bug reassigned from package 'libc6-dev-i386' to 'cross-toolchain-base-mipsen'. Ignoring request to alter found versions of bug #1100544 to the

Processed: Re: Bug#1100544: glibc adds some conflicts letting gcc-14-cross ftbfs

Processing control commands: > reassign -1 libc6-dev-i386 Bug #1100544 [src:glibc] glibc adds some conflicts letting gcc-14-cross ftbfs Bug reassigned from package 'src:glibc' to 'libc6-dev-i386'. No longer marked as found in versions glibc/2.41-4. Ignoring request to alter fixed versions of bug #

Processed: Re: Bug#1099624: libc6 2.41 pthread cause pari to FTBFS

Processing control commands: > forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=32782 Bug #1099624 [libc6] libc6 2.41 pthread cause pari to FTBFS Set Bug forwarded-to-address to 'https://sourceware.org/bugzilla/show_bug.cgi?id=32782'. -- 1099624: https://bugs.debian.org/cgi-bin/bugr

Processed: Re: Bug#1099197: Makes postgresql-15-pllua uninstallable

Processing control commands: > severity -1 important Bug #1099197 [libc6] Makes postgresql-15-pllua uninstallable Severity set to 'important' from 'grave' -- 1099197: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1099197 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#1094785: locales: en_AU locale uses Sunday as first day of week but Australia uses Monday

Processing control commands: > forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=24877 Bug #1094785 [locales] locales: en_AU locale uses Sunday as first day of week but Australia uses Monday Set Bug forwarded-to-address to 'https://sourceware.org/bugzilla/show_bug.cgi?id=24877'. > fix

Re: Bug#816802: Processed: Re: Bug#816802: tzdata: hwclock not set properly when "tzdata-2016a-1" is installed

On Wed, Jan 15, 2025 at 08:21:12AM +, Mark Hindley wrote: > This report is very old and much has changed. Is this still an issue for you? I assume not. Closing. Thanks Mark

[Git][glibc-team/glibc][sid] hurd: Re-xfail tst-tunables

Samuel Thibault pushed to branch sid at GNU Libc Maintainers / glibc Commits: 8c8a7f28 by Samuel Thibault at 2025-01-25T02:36:26+01:00 hurd: Re-xfail tst-tunables Apparently still a problem - - - - - 1 changed file: - debian/testsuite-xfail-debian.mk View it on GitLab: https

Re: Processed: Re: Bug#816802: tzdata: hwclock not set properly when "tzdata-2016a-1" is installed

Control: tags -1 moreinfo Aurelien, Thanks Christophe, This report is very old and much has changed. Is this still an issue for you? Mark

Processed: Re: Bug#816802: tzdata: hwclock not set properly when "tzdata-2016a-1" is installed

Processing control commands: > reassign -1 initscripts Bug #816802 [tzdata] tzdata: hwclock not set properly when "tzdata-2016a-1" is installed Bug reassigned from package 'tzdata' to 'initscripts'. No longer marked as found in versions tzdata/2016a-1. Ignoring request to alter fixed versions of

Bug#848143: marked as done (No non-systemd way of programmatically changing the timezone without re-doing what tzdata does)

Your message dated Mon, 13 Jan 2025 23:09:06 + with message-id and subject line Bug#848143: fixed in tzdata 2024b-6 has caused the Debian Bug report #848143, regarding No non-systemd way of programmatically changing the timezone without re-doing what tzdata does to be marked as done. This

Processed (with 1 error): Re: Bug#404205: libc6: readdir() return value is not always as documented

Processing control commands: > reassign -1 manpages-dev Bug #404205 [libc6] libc6: readdir() return value is not always as documented Bug reassigned from package 'libc6' to 'manpages-dev'. No longer marked as found in versions glibc/2.3.2.ds1-22. Ignoring request to alter fixed versions of bug #40

Processed: Re: Bug#651005: /usr/share/man/man3/pthread_cond_wait.3.gz: pthread_cond_wait documentation incorrect, does not allow for spurious wakeups

Processing control commands: > reassign -1 651005 manpages-dev Bug #651005 [glibc-doc] /usr/share/man/man3/pthread_cond_wait.3.gz: pthread_cond_wait documentation incorrect, does not allow for spurious wakeups Bug reassigned from package 'glibc-doc' to '651005'. Warning: Unknown package '651005'

Processed: Re: Bug#1091473: /usr/sbin/dpkg-reconfigure: dpkg-reconfigure: The C and C.UTF-8 locales are not listed

Processing control commands: > reassign -1 locales Bug #1091473 [debconf] /usr/sbin/dpkg-reconfigure: dpkg-reconfigure: The C and C.UTF-8 locales are not listed Bug reassigned from package 'debconf' to 'locales'. No longer marked as found in versions debconf/1.5.87. Ignoring request to alter fixe

Processed: Re: Bug#1088290: libc6: On mips64el, nbdkit --help segfaults in printf()

Processing control commands: > reassign -1 nbdkit Bug #1088290 [libc6] libc6: On mips64el, nbdkit --help segfaults in printf() Bug reassigned from package 'libc6' to 'nbdkit'. No longer marked as found in versions glibc/2.40-4 and glibc/2.40-3. Ignoring request to alter fixed versions of bug #1088

Processed: Re: Bug#1088290: libc6: On mips64el, nbdkit --help segfaults in printf()

Processing control commands: > found -1 glibc/2.40-3 Bug #1088290 [libc6] libc6: On mips64el, nbdkit --help segfaults in printf() Marked as found in versions glibc/2.40-3. -- 1088290: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088290 Debian Bug Tracking System Contact ow...@bugs.debian.o

Re: Plans to update leap-seconds.list?

Hi, On 2024-11-12 12:08, David Coulthart wrote: > Hi, > > Are there plans to update the leap-seconds.list file in the current > oldoldstable (buster), oldstable (bullseye), and/or stable (bookworm) > distributions before the current file expires on December 28, 2024? I'm > aware that there are no

Re: src:tzdata: fails to migrate to testing for too long

Hi Santiago, On 08-11-2024 02:50, Santiago Vila wrote: So: Could some Release Manager evaluate if we really need Bug #1084190 at this point? My hint for tzdata [1], which is in place since 2024-11-02, implicitly defers this judgement call for now to the maintainers, which should be the first

Re: src:tzdata: fails to migrate to testing for too long

Hello. One of the reasons tzdata will not migrate to testing is that it has an artificial bug preventing it from doing so: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084190 In my opinion (after reporting several tzdata-related bugs and also fixing some of them), the breakage introduced

Re: Bug#1079443: Processed: Re: dracut-install ... -m =drivers/XXX is ignored

On 2024-08-24 19:57, Aurelien Jarno wrote: > control: unmerge 1079443 > control: retitle 1079443 fts_* calling non-LFS __readdir > > On 2024-08-24 21:40, Stepan Golosunov wrote: > > On Sat, Aug 24, 2024 at 05:20:44PM +0200, Aurelien Jarno wrote: > > > control: forcemerge 916276 1079443 > > > > >

Re: Updates to the trixie freeze policy

Hi, Thanks for contacting maintainers impacted by the new timeline scheme. On 2024-11-02 18:35, Sebastian Ramacher wrote: > Dear toolchain, debian-installer, and image maintainers, > > We, as the release team, are aware that we are late with the > announcement of the freeze timeline for trixie.

Re: Updates to the trixie freeze policy

Hi, Sebastian Ramacher (2024-11-02): > Dear toolchain, debian-installer, and image maintainers, > > We, as the release team, are aware that we are late with the > announcement of the freeze timeline for trixie. After some internal > discussions on how we want to handle the freeze for trixie base

Processed: Re: breakage due to tzdata System V name removal

Processing control commands: > affects -1 -src:systemd Bug #1084190 [tzdata] breakage due to tzdata System V name removal Removed indication that 1084190 affects src:systemd -- 1084190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084190 Debian Bug Tracking System Contact ow...@bugs.debian

Processed: Re: Bug#1086502: libc6-dev: Please add newer hwcap hwcap2 particularly for ARM*

Processing control commands: > severity -1 wishlist Bug #1086502 [libc6-dev] libc6-dev: Please add newer hwcap hwcap2 particularly for ARM* Severity set to 'wishlist' from 'normal' -- 1086502: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086502 Debian Bug Tracking System Contact ow...@bug

Processed: Re: breakage due to tzdata System V name removal

Processing control commands: > affects -1 src:systemd Bug #1084190 [tzdata] breakage due to tzdata System V name removal Added indication that 1084190 affects src:systemd -- 1084190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084190 Debian Bug Tracking System Contact ow...@bugs.debian.or

Re: Package: locales Version: 2.36-9+deb12u8

Hi, Thanks for the feedback. facebook linkedin instagram DarkoŠturlan Servisi Ram d.o.o.

Re: Package: locales Version: 2.36-9+deb12u8

Hi, On 2024-10-06 20:48, Darko Šturlan wrote: > Hi, > Can you please change Croatia's currency to EUR as of 1.1.2023 it's > official https://croatia.hr/en-gb/money/currency This change indeed arrived to late for the bookworm toolchain freeze. I have backported it [1], it should appear the next ti

Processed: Re: Bug#1083095: libc6: SIGSEGV in _dl_open on ARM64 (aarch64) at libc6 2.36-9+deb12u8 called by bash-static 5.2.15-2+b7

Processing control commands: > found -1 2.36-9+deb12u8 Bug #1083095 [libc6] libc6: SIGSEGV in _dl_open on ARM64 (aarch64) at libc6 2.36-9+deb12u8 called by bash-static 5.2.15-2+b7 Marked as found in versions glibc/2.36-9+deb12u8. -- 1083095: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=108

Processed: Re: Bug#1084190: breakage due to tzdata System V name removal

Processing control commands: > tags -1 ftbfs Bug #1084190 [tzdata] breakage due to tzdata System V name removal Added tag(s) ftbfs. > affects -1 src:glib2.0 Bug #1084190 [tzdata] breakage due to tzdata System V name removal Added indication that 1084190 affects src:glib2.0 -- 1084190: https://bu

Re: #1076089 Langage in installed system is English

Hi, On 2024-10-05 20:39, Holger Wansing wrote: > [ Adding locales people to the loop ] > > Hi, > > Bernhard wrote: > > I added the boot parameter "locale=de_DE.UTF-8". > > But, the installed system is in English. > > Attached, there are the installer-logs. > > I did some test installations, an

Re: #1076089 Langage in installed system is English

[ Adding locales people to the loop ] Hi, Bernhard wrote: > I added the boot parameter "locale=de_DE.UTF-8". > But, the installed system is in English. > Attached, there are the installer-logs. I did some test installations, and I can confirm there is an issue with this: After a fresh testing|

Processed: Re: Bug#1084111: dateutil.tz.gettz always UTC with tzdata 2024b

Processing control commands: > clone -1 -2 Bug #1084111 [tzdata,python3-dateutil] dateutil.tz.gettz always UTC with tzdata 2024b Bug 1084111 cloned as bug 1084120 > reassign -1 tzdata Bug #1084111 [tzdata,python3-dateutil] dateutil.tz.gettz always UTC with tzdata 2024b Bug reassigned from packag

Re: Need information where tests can be found for libnsl2 Debian package

Hi, On 2024-09-18 05:55, adithya.balaku...@toshiba-tsip.com wrote: > Hi, > I work for CIP (Civil Infrastructure Platform) project which is a Debian > based distribution. We are working for IEC-62443-4-2 assessment. > The IEC standard has a requirement that all packages included in the image > sh

Processed: Re: Bug#1078127: libc6: mcheck(NULL) fails even at the beginning of a program

Processing control commands: > tags -1 upstream Bug #1078127 [libc6] libc6: mcheck(NULL) fails even at the beginning of a program Added tag(s) upstream. > forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=32156 Bug #1078127 [libc6] libc6: mcheck(NULL) fails even at the beginning of a

Processed: Re: Bug#1079443: Processed: Re: dracut-install ... -m =drivers/XXX is ignored

Processing control commands: > unmerge 1079443 Bug #1079443 [src:glibc] fts_build() calling __getdents breaks 32bit on 64bit Bug #916276 [src:glibc] glibc: Please add prelimenary patch to fix regression on qemu-user Bug #1002699 [src:glibc] libc6: m68k,s390 readdir not returning filled in dirent

Re: Bug#1079443: Processed: Re: dracut-install ... -m =drivers/XXX is ignored

control: unmerge 1079443 control: retitle 1079443 fts_* calling non-LFS __readdir On 2024-08-24 21:40, Stepan Golosunov wrote: > On Sat, Aug 24, 2024 at 05:20:44PM +0200, Aurelien Jarno wrote: > > control: forcemerge 916276 1079443 > > > > Hi > > > > On 2024-08-24 10:27, Debian Bug Tracking Sys

Re: Bug#1079443: Processed: Re: dracut-install ... -m =drivers/XXX is ignored

On Sat, Aug 24, 2024 at 05:20:44PM +0200, Aurelien Jarno wrote: > control: forcemerge 916276 1079443 > > Hi > > On 2024-08-24 10:27, Debian Bug Tracking System wrote: > > Processing control commands: > > > > > reassign -1 glibc > > Bug #1079443 [dracut-install] dracut-install ... -m =drivers/XXX

Processed: Re: Processed (with 1 error): Re: Processed: Re: dracut-install ... -m =drivers/XXX is ignored

Processing commands for cont...@bugs.debian.org: > reassign 1079443 src:glibc Bug #1079443 [glibc] fts_build() calling __getdents breaks 32bit on 64bit Bug reassigned from package 'glibc' to 'src:glibc'. Ignoring request to alter found versions of bug #1079443 to the same values previously set Ig

Processed (with 1 error): Re: Processed: Re: dracut-install ... -m =drivers/XXX is ignored

Processing control commands: > forcemerge 916276 1079443 Bug #916276 [src:glibc] glibc: Please add prelimenary patch to fix regression on qemu-user Bug #1002699 [src:glibc] libc6: m68k,s390 readdir not returning filled in dirent pointer Unable to merge bugs because: package of #1079443 is 'glibc

Re: Processed: Re: dracut-install ... -m =drivers/XXX is ignored

control: forcemerge 916276 1079443 Hi On 2024-08-24 10:27, Debian Bug Tracking System wrote: > Processing control commands: > > > reassign -1 glibc > Bug #1079443 [dracut-install] dracut-install ... -m =drivers/XXX is ignored > Bug reassigned from package 'dracut-install' to 'glibc'. > No longer

Processed: Re: dracut-install ... -m =drivers/XXX is ignored

Processing control commands: > reassign -1 glibc Bug #1079443 [dracut-install] dracut-install ... -m =drivers/XXX is ignored Bug reassigned from package 'dracut-install' to 'glibc'. No longer marked as found in versions dracut/103-1.1. Ignoring request to alter fixed versions of bug #1079443 to th

Re: Bug#1079443: dracut-install ... -m =drivers/XXX is ignored [on armhf]

user debian-...@lists.debian.org usertag 1079443 time-t thanks Hi debian-arm, in case you don't know yet, here is a bug affecting dracut-install on armhf (and probably armel), causing the built initramfs to lack a lot of kernel modules. Probably makes a lot of things unbootable. It looks like t

Processed: Re: Bug#1076217: locales,gosa-dev: install program with same name (update-locale)

Processing control commands: > reassign -1 gosa-dev Bug #1076217 [locales,gosa-dev] locales,gosa-dev: install program with same name (update-locale) Bug reassigned from package 'locales,gosa-dev' to 'gosa-dev'. Ignoring request to alter found versions of bug #1076217 to the same values previousl

Re: Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

Hi Sam, * Sam Hartman [2024-07-05 09:43]: "Chris" == Chris Hofstaedtler writes: Chris> Adam (adsb) points out that the test code in Chris> lib/rpc/unit-test/client.c [1] uses code that does not Chris> support IPv6(-only). I.e. gethostbyname for a name that has Chris> no IPv4 addre

Re: Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

Hi, On 2024-07-05 09:43, Sam Hartman wrote: > > "Chris" == Chris Hofstaedtler writes: > Chris> Adam (adsb) points out that the test code in > Chris> lib/rpc/unit-test/client.c [1] uses code that does not > Chris> support IPv6(-only). I.e. gethostbyname for a name that has > Ch

Re: Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

> "Chris" == Chris Hofstaedtler writes: Chris> Adam (adsb) points out that the test code in Chris> lib/rpc/unit-test/client.c [1] uses code that does not Chris> support IPv6(-only). I.e. gethostbyname for a name that has Chris> no IPv4 address will fail. So, are the builds goi

Re: Upcoming oldstable point release (11.10)

On Wed, Jun 12, 2024 at 09:11:32PM +0100, Jonathan Wiltshire wrote: > The next point release for "bullseye" (11.10) is scheduled for Saturday, > February 10th. Processing of new uploads into bullseye-proposed-updates > will be frozen during the preceding weekend. The correct date for 11.10 is Satu

Re: Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

On Mon, Jun 10, 2024 at 11:59:34AM +0200, Chris Hofstaedtler wrote: > Hi, > > On Mon, Feb 12, 2024 at 08:43:07AM -0700, Sam Hartman wrote: > > > "Simon" == Simon McVittie writes: [..] > > Simon> However, even with both of those, if the krb5 test suite (or > > Simon> protocol) is resol

Re: Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

Hi, On Mon, Feb 12, 2024 at 08:43:07AM -0700, Sam Hartman wrote: > > "Simon" == Simon McVittie writes: [..] > Simon> I am unsure whether there is consensus that "the result of > Simon> gethostname() resolves to some address of the local machine" > Simon> is also a reasonable thing

Re: Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

Hi Aurelien, Trimmed Cc list for glibc matters. On Wed, Jun 05, 2024 at 11:16:50PM +0200, Aurelien Jarno wrote: > Oops, I was convinced that #1071462 was filled with severity serious. > Nevermind. It migrated anyway. :) > Ok, a simultaneous experimental NMU sounds good. Ok, will do with a bit

Re: Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

Hi Helmut On 2024-06-05 14:21, Helmut Grohne wrote: > Hi Aurelien, > > On Tue, Jun 04, 2024 at 06:58:00PM +0200, Aurelien Jarno wrote: > > It would be really great if glibc can migrate before as it fixes an RC > > bug. That said there are suspicions that it introduced bug #1072521, so > > it migh

Re: Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

Hi Aurelien, On Tue, Jun 04, 2024 at 06:58:00PM +0200, Aurelien Jarno wrote: > It would be really great if glibc can migrate before as it fixes an RC > bug. That said there are suspicions that it introduced bug #1072521, so > it might be worth investigating before it gets pushed into testing. > Un

Re: Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

Hi, On 2024-06-03 23:10, Helmut Grohne wrote: > On Wed, May 29, 2024 at 03:14:59PM +0200, Helmut Grohne wrote: > > Since noble includes these changes and I'd get this done sooner rather > > than later, how about moving forward with June 5th after 22:30 UTC (such > > that all buildds have regenerat

Re: Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

El 3/6/24 a las 23:10, Helmut Grohne escribió: On Wed, May 29, 2024 at 03:14:59PM +0200, Helmut Grohne wrote: Since noble includes these changes and I'd get this done sooner rather than later, how about moving forward with June 5th after 22:30 UTC (such that all buildds have regenerated their

Re: Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

* Helmut Grohne [240603 23:11]: > On Wed, May 29, 2024 at 03:14:59PM +0200, Helmut Grohne wrote: > > Since noble includes these changes and I'd get this done sooner rather > > than later, how about moving forward with June 5th after 22:30 UTC (such > > that all buildds have regenerated their chroo

Re: Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

On Wed, May 29, 2024 at 03:14:59PM +0200, Helmut Grohne wrote: > Since noble includes these changes and I'd get this done sooner rather > than later, how about moving forward with June 5th after 22:30 UTC (such > that all buildds have regenerated their chroots before the upload)? I got vaguely pos

Re: Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8

fixed 1070666 glibc/2.38-7 thanks Hi, On Thu, May 16, 2024 at 10:46:28PM +0300, Eugene Berdnikov wrote: > Installation of util-linux 2.40.1-1 (and accompanied libmount1, > libuuid1, libblkid1, libsmartcols1 of the same version) solves > the problem, output of "last" is correct. Thanks for rep

Processed: Re: Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8

Processing commands for cont...@bugs.debian.org: > fixed 1070666 glibc/2.38-7 Bug #1070666 [glibc] util-linux: last(1) is broken on i386 since 2.40-8 Marked as fixed in versions glibc/2.38-7. > thanks Stopping processing here. Please contact me if you need assistance. -- 1070666: https://bugs.de

Re: Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8

Hello. On Tue, May 14, 2024 at 10:44:37PM +0200, Aurelien Jarno wrote: > On 2024-05-14 21:51, Chris Hofstaedtler wrote: > > Hi Eugene, > > > > could you please try again with: > > util-linux 2.40.1-1 > > glibc 2.38-7 or newer > > > > and report back, if the problem is fixed for you? > > [..

Re: Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38

On 2024-05-05 15:02, Cordell Bloor wrote: There is nothing that can be done in rocm-hipamd to address this bug, aside from removing arm64 from the rocm-hipamd architecture list. The incompatibility is not with the HIP runtime, but with the HIP language. This is a disagreement that glibc and

Processed: Re: Bug#1071172: libc6-dev omits the bits directory

Processing control commands: > tags -1 + moreinfo Bug #1071172 [libc6-dev] libc6-dev omits the bits directory Added tag(s) moreinfo. -- 1071172: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071172 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#1071093: libc6: [adequate] undefined-symbol

Processing control commands: > reassign -1 adequate Bug #1071093 [libc6] libc6:i386: [adequate] undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 Bug reassigned from package 'libc6' to 'adequate'. No longer marked as found in versions glibc/2.38-11. Ignoring request to alter fixed versions o

Re: Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8

Hi, On 2024-05-14 21:51, Chris Hofstaedtler wrote: > Hi Eugene, > > could you please try again with: > util-linux 2.40.1-1 > glibc 2.38-7 or newer > > and report back, if the problem is fixed for you? > > The newer util-linux is rebuilt against the fixed glibc, so it > hopefully is now fine. It

Re: Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8

Control: reassign 1070666 glibc Control: affects 1070666 util-linux On Mon, May 06, 2024 at 11:51:50PM +0300, Eugene Berdnikov wrote: > Upgrade of util-linux from 2.39.3-6 to 2.40-8 on i386 systems breaks > last(1), while the same upgrade on amd64 systems does not break it. > Examples on my hos

Processed: Re: Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8

Processing control commands: > reassign 1070666 glibc Bug #1070666 [util-linux] util-linux: last(1) is broken on i386 since 2.40-8 Bug reassigned from package 'util-linux' to 'glibc'. No longer marked as found in versions util-linux/2.40-8. Ignoring request to alter fixed versions of bug #1070666

Re: Processed: glibc: packages FTBFS caused by vector math library header on arm64

On 2024-05-07 00:29, Simon Chopin wrote: > As the one who reported the issue in the glibc upstream tracker, I'm now > of the opinion it's not a glibc bug, but rather issues with the > individual packages that are now FTBFS. As far as I know, this is either > a parser pretending to be GCC without im

Re: Please give me write access to glibc -security branches

On Mon, May 06, 2024 at 09:22:09PM +0200, Aurelien Jarno wrote: > Hi Adrian, Hi Aurelien, > On 2024-05-06 00:15, Adrian Bunk wrote: > > Hi, > > > > please give me write access to glibc -security branches for pushing > > (E)LTS updates there. > > TTBOMK there is no such things like giving access

Re: Please give me write access to glibc -security branches

Hi Adrian, On 2024-05-06 00:15, Adrian Bunk wrote: > Hi, > > please give me write access to glibc -security branches for pushing > (E)LTS updates there. TTBOMK there is no such things like giving access to some branches only, so you should no have access to the glibc repository on salsa. Please

Re: Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38

Tags: patch Hi Graham, On 2024-05-05 07:31, Graham Inggs wrote: As can be seen in reproducible builds [1], rocm-hipamd FTBFS on arm64 with glibc 2.38. I've copied what I hope is the relevant part of the log below. A bug was filed against glibc [2], but it seems glibc upstream do not consider

Re: Bug#1069841: python-icalendar: FTBFS with tzdata 2024a: UnknownTimeZoneError: 'America/Godthab'

Control: retitle -1 python-icalendar: FTBFS with tzdata 2024a: UnknownTimeZoneError: 'America/Godthab' On Thu, 25 Apr 2024 at 18:27:15 +0200, Santiago Vila wrote: > E pytz.exceptions.UnknownTimeZoneError: 'America/Godthab' This was presumably triggered by this change in tzdata 2024

Processed: Re: Bug#1041415: details

Processing control commands: > tag -1 + fixed-upstream Bug #1041415 [libc6] libc6: fchmodat emulation fails in the absence of /proc Added tag(s) fixed-upstream. -- 1041415: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041415 Debian Bug Tracking System Contact ow...@bugs.debian.org with pro

Processed: Re: Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t

Processing control commands: > tags -1 + patch Bug #1068251 [src:glibc] glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t Added tag(s) patch. -- 1068251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068251 Debian Bug Tracking System Contact ow...@bugs.debian.org

Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

Rich Felker dixit: >Is there anything weird about how these objects were declared that >might have caused ld not to resolve them statically like it should? It >seems odd that these data symbols, but not any other ones, would be >left as symbolic relocations. I don’t think so? In I already poste

Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

On Fri, Apr 05, 2024 at 05:04:37AM +, Thorsten Glaser wrote: > Markus Wichmann dixit: > > >can check with readelf -r what the relocation types are. If they are not > >relative, they will not be processed. > > Gotcha! They are all R_390_RELATIVE except for: > > 00045ff0 00110016 R_39

Processed (with 1 error): Re: Bug#411059: sash: bad practice of multiple accounts with uid==0 lead to broken system

Processing control commands: > title -1 nscd caches "wrong" name for accounts with the same uid Unknown command or malformed arguments to command. > found -1 2.37-15 Bug #411059 [nscd] nscd: getpwuid() behavior differs from default (de-facto standard) Marked as found in versions glibc/2.37-15.

Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

* Thorsten Glaser [2024-04-05 05:04:37 +]: > Markus Wichmann dixit: > > >can check with readelf -r what the relocation types are. If they are not > >relative, they will not be processed. > > Gotcha! They are all R_390_RELATIVE except for: > > 00045ff0 00110016 R_390_64 000

Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

Am Fri, Apr 05, 2024 at 05:58:15AM + schrieb Thorsten Glaser: > Markus Wichmann dixit: > >In any case, the emission of non-relative relocations is the issue here, > >and it is coming from the linker. > > They are present in the glibc static-pie binary as well, though. > And tbh they look to me

Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

Markus Wichmann dixit: >I may not really know what I am talking about, so take this with a grain >of salt, but isn't this missing a -Bsymbolic somewhere? Ironically, that >switch causes ld to not emit symbolic relocations. I seem to remember >reading long ago in Rich's initial -static-pie proposal

Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

Am Fri, Apr 05, 2024 at 05:04:37AM + schrieb Thorsten Glaser: > Should be correct: > > /usr/libexec/gcc/s390x-linux-gnu/13/collect2 -fno-lto -dynamic-linker > /lib/ld-musl-s390x.so.1 -nostdlib -static -static -pie --no-dynamic-linker -o > mksh /usr/lib/s390x-linux-musl/rcrt1.o /usr/lib/s390x

Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

Markus Wichmann dixit: >can check with readelf -r what the relocation types are. If they are not >relative, they will not be processed. Gotcha! They are all R_390_RELATIVE except for: 00045ff0 00110016 R_390_64 00042c58 u_ops + 70 00045ff8 00110016 R_390_64

Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

Hi, in static-pie, relocations get processed in _start, before main() is called. In musl, this is done by linking with rcrt1.o as start file instead of crt1.o. And that file processes all relative relocations. You can check with readelf -r what the relocation types are. If they are not relative, t

Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

Dixi quod… >Now I (or someone) is going to have to reduce that to a testcase, so No success with that, unfortunately. >But this does seem to be a toolchain bug: adding -static-pie to the >glibc dynamic-pie link command and… > >(gdb) print initcoms >$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494

Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

Dixi quod… >Hmm, actually… I could… test whether that one fixes static-pie >on zelenka. Or at least the same approach. I’ll get back with >report from that. Having looked at the spec file, the only extra things the stock specs do that the overriding specs don’t is: *link: […] %{!static|static-pi

Processed: Re: Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

Processing control commands: > severity -1 normal Bug #1068188 [glibc-doc] pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1 Severity set to 'normal' from 'serious' -- 1068188: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068188 Debian Bug Tracking System Contact ow...@bugs.debian.

Processed: Re: Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

Processing control commands: > found -1 glibc/2.37-15.1 Bug #1068188 [glibc-doc] pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1 Marked as found in versions glibc/2.37-15.1. -- 1068188: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068188 Debian Bug Tracking System Contact ow...@b

Re: Upcoming stable point release (12.6)

On Fri, 2024-02-16 at 17:35 +, Jonathan Wiltshire wrote: > The next point release for "bookworm" (12.6) is scheduled for > Saturday, April 6th. Processing of new uploads into bookworm- > proposed-updates will be frozen during the preceeding weekend. Due to recent events, the point release has

Re: Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

Hi, On Sat, Mar 09, 2024 at 09:50:11PM +0100, Sebastian Ramacher wrote: > > I'd now like to coordinate a time of upload. Given that chroots are > > rebuilt in Wednesday and Sunday, I suggest we pick a Thursday morning > > for the actual upload. If I unexpectedly break stuff, I still have a few > >

  1   2   3   4   5   6   7   8   9   10   >