Bug#727786: removal of libc6-amd64 makes system unusable

Package: eglibc Version: 2.13-38 Severity: grave Justification: leaves system unusable [Sorry for not filing this bug with reportbug, but due to this bug that doesn't work anymore. I am also unable to sign my mail at this moment, due to this bug.] For building an i386-only package I libc6-amd64

Bug#727786: follow-up for: removal of libc6-amd64 makes system unusable

Seems this bug was indeed already reported: 699206 and 707185. However, it is not clear to me how I can get my system working again. Obviously, I can not remove or create symlinks to the right location as ln and friends don't work anymore (not to mention that sudo and getty don't help). Seems

Bug#727786: follow-up 2 for: removal of libc6-amd64 makes system unusable

So I was indeed able to recover my system by changing the symlink in /lib64/ with an emergency USB key. For the record, after shutdown, the system of course would not come up. I am afraid that people with less patience than I would conclude that their system was hopelessly ruined. However, I have

Bug#727786: follow-up for: removal of libc6-amd64 makes system unusable

Just an important note for anybody ending up at this bug and wanting to remove libc6-amd64. As long as you have root access to the system and have not powered off yet, I believe you can fix this issue without rescue CD/USB. With root access (sudo does not work anymore, because the setguid fails)

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

Hi Florian, On 29-07-18 13:26, Florian Weimer wrote: > I'm not sure why it is necessary to build glibc three times (unless > it's impossible to get multi-arch packages into the buildroot). I am not sure if I understand what you mean, but currently having multiple arches available in the

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

Hi Florian, On 30-07-18 23:14, Florian Weimer wrote: > * Paul Gevers: >> On 29-07-18 13:26, Florian Weimer wrote: >>> I'm not sure why it is necessary to build glibc three times (unless >>> it's impossible to get multi-arch packages into the buildroot). >> >

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

Hi all, On Sat, 4 Aug 2018 18:48:44 +0200 Aurelien Jarno wrote: > On 2018-07-23 22:17, Paul Gevers wrote: > > On Sun, 01 Apr 2018 21:56:33 +0200 Florian Weimer > > wrote: > > > > I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours > > &g

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

On Sun, 01 Apr 2018 21:56:33 +0200 Florian Weimer wrote: > > I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours > > built on amd64, the glibc takes around 20 minutes to build and the > > testsuite around 2h to run. > > This is still rather slow. I see native builds on

Re: glibc and abi-compliance-checker break multiple KDE autopkgtests

Hi all, On 09/06/18 21:13, Paul Gevers wrote: > So it seems they are requested by something, and because the are not > available in testing, apt-get is not limited by our pinning to take them > from unstable. I believe it must be a "Provides" of some sort. What I > want to

glibc and abi-compliance-checker break multiple KDE autopkgtests

Dear glibc, abi-compliance-checker and Qt/KDE maintainers, With recent upload of glibc and abi-compliance-checker the autopkgtest of libkf5calendarsupport, kf5-kdepim-apps-libs and akonadi-calendar started to fail when run in testing with either glibc or abi-compliance-checker from unstable.

Re: glibc and abi-compliance-checker break multiple KDE autopkgtests

Hi Samuel, all, On 06-09-18 11:19, Samuel Thibault wrote: > It'd be useful for the abi-compliance-checker test to actually output > error messages, > > https://ci.debian.net/data/autopkgtest/testing/amd64/k/kf5-kdepim-apps-libs/944759/log.gz > > it not very talkative :) I agree, but I found

Re: glibc and abi-compliance-checker break multiple KDE autopkgtests

Hi On 06-09-18 11:53, Samuel Thibault wrote: > Samuel Thibault, le jeu. 06 sept. 2018 11:44:45 +0200, a ecrit: >> Paul Gevers, le jeu. 06 sept. 2018 11:22:46 +0200, a ecrit: >>> On 06-09-18 11:19, Samuel Thibault wrote: >>>> It'd be useful for the abi-compliance-c

Re: glibc and abi-compliance-checker break multiple KDE autopkgtests

Hi On 06-09-18 16:39, Antonio Terceiro wrote: >>> Does this mean that libc++-8-dev is breaking the ABI of the Qt/KDE >>> packages? Luckily libc++-8-dev will not migrate to testing due to >>> https://bugs.debian.org/714686 Does it need a "Breaks" then? >> >> Actually due to a bug in the migration

gnupg2 autopkgtest uses multi-arch which seems fragile

Hi gnupg2 maintainers, all, I am investigating the autopkgtest regressions of glibc¹ (2 left after some retries). I notice that gnupg2 fails (also in the retry) with the error below. I don't fully understand yet, but I think this is due to some requirement that only unstable can fulfill at the

Re: gnupg2 autopkgtest uses multi-arch which seems fragile

Hi Ian, Thanks for helping out. On 09-07-18 15:02, Ian Jackson wrote: > Ian Jackson writes ("Re: gnupg2 autopkgtest uses multi-arch which seems > fragile"): >> I looked in: >> >> * debian/tests/control in the gnupg2 source tree. >> One test, of gpgv-win32. Depends on gpgv-win32, gnupg2, > >

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

On Mon, 18 May 2015 15:47:34 -0300 Antonio Terceiro wrote: > The glibc test runs times out at ci.debian.net after running for ~3h, > apparently since they were introduced: > https://ci.debian.net/packages/g/glibc/unstable/amd64/ Is there any hope to have this fixed? > I am

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

Hi Aurelien, On 14-03-18 00:15, Aurelien Jarno wrote: > On 2018-03-13 21:13, Paul Gevers wrote: >> On Mon, 18 May 2015 15:47:34 -0300 Antonio Terceiro >> <terce...@debian.org> wrote: >>> The glibc test runs times out at ci.debian.net after running for ~3h,

Bug#915325: r-cran-rgenoud: autopkgtest needs update for new version of glibc

Source: r-cran-rgenoud Version: 5.8-2.0-2 X-Debbugs-CC: debian...@lists.debian.org, gl...@packages.debian.org User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:glibc Dear maintainers, With a recent upload of glibc the autopkgtest of r-cran-rgenoud fails in testing

KDE/Qt tests [was Re: Bug#906694: purpose: autopkgtest regression]

Hi Maximiliano, others On Mon, 3 Dec 2018 11:24:15 -0300 Maximiliano Curia wrote: > About the kde frameworks uploads, they are handled in a bundle, and breaks > and > dependencies are added so they migrate to testing as needed, the same breaks > and dependencies can cause temporary

Re: cross-toolchain-base: FTBFS: applying patches fails

user debian...@lists.debian.org usertags needs-update thanks Hi all, On Sat, 29 Dec 2018 23:46:40 +0100 Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > debian/rules build > > linux: 4.19.12-1 /

Re: glibc and abi-compliance-checker break multiple KDE autopkgtests

Dear all, On 09-09-18 22:04, Paul Gevers wrote: > On 09/06/18 21:13, Paul Gevers wrote: >> So it seems they are requested by something, and because the are not >> available in testing, apt-get is not limited by our pinning to take them >> from unstable. I believe it must be

Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)

Dear all, Regarding this PostgreSQL reindexing issue, is there anything we need to mention in the release-notes? If this isn't fleshed out, but the most likely answer is yes, than I'd appreciate it to receive a bug against release-notes to remind us about it later on. Text can come later when it

release-notes? Was: Re: kbdnames are generated with incorrect translations

Hi all, On Fri, 15 Mar 2019 14:38:07 + Iain Lane wrote: > Package: keyboard-configuration > Version: 1.188 > Severity: serious > Tags: patch [...] > The generated names in keyboard-configuration.config are translated > incorrectly: > > laney@raleigh> dpkg --ctrl-tarfile

Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'

Dear Adrian, On 07-05-2020 10:07, Adrian Bunk wrote: > This is a toolchain problem affecting many packages: > https://sourceware.org/bugzilla/show_bug.cgi?id=25051 Do you have any rough estimate how many? Is there any way to predict which packages are effected, or to detect which packages are

Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'

Hi Adrian, On 07-05-2020 12:16, Adrian Bunk wrote: > On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote: >> If we can detect this failure >> mode (and similar ones in the future) we can of course generate hints >> based on this heuristics and have the f

Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'

Hi Adrian, On 10-05-2020 15:25, Paul Gevers wrote: > I'm running another check on "cannot allocate memory in static TLS > block" now, will take a while. Also for this one, only vtkplotter showed up. Paul signature.asc Description: OpenPGP digital signature

Arch qualification for buster: call for DSA, Security, toolchain concerns

from testing before bullseye is frozen. We are currently unaware of any new architectures likely to be ready in time for inclusion in bullseye. On behalf of the release team, Paul Gevers signature.asc Description: OpenPGP digital signature

Bug#976409: glibc breaks node-iconv autopkgtest: AssertionError [ERR_ASSERTION]: Missing expected exception

Source: glibc, node-iconv Control: found -1 glibc/2.31-5 Control: found -1 node-iconv/2.3.5-4 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of glibc the

Bug#976410: glibc breaks libpod autopkgtest: dh_auto_build: error: cd _output && go install -trimpath ...

Source: glibc, libpod Control: found -1 glibc/2.31-5 Control: found -1 libpod/2.0.6+dfsg1-2 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of glibc the

Re: Bug#988740: unblock: glibc/2.31-12

Hi Cyril On 20-05-2021 08:23, Cyril Brulebois wrote: > Having udeb-producing packages change under our feet when we're in > the middle of unentangling the rendering mess isn't exactly nice… I'm terribly sorry, but I thought we discussed migrating udeb generating packages recently on IRC

Re: Bug#988740: unblock: glibc/2.31-12

Hi kibi, On 24-05-2021 06:30, Cyril Brulebois wrote: > Nothing dramatic, we'll be more explicit next time and pick an option > for real instead of considering both options and letting one pick a > favorite. :) Let's agree on that indeed. It's a shame that we get into these annoyances, while all

Re: Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

Hi all, On 04-07-2021 00:42, Colin Watson wrote: > Sorry for my delay - it took me a while to spot the problem. libc6's > postinst does arrange to restart services where needed, but in this case > it doesn't realize that you have the ssh service installed because you > only have the

Bug#985617: glibc: flaky autopkgtest on most architectures

Hi Aurelien, On 23-04-2021 14:49, Aurelien Jarno wrote: > Nope, unfortunately it seems the mail didn't reach me or the mailing > list, maybe it was too big? It did reach the BTS. I guess size may have been a factor yes, the log can be picked up in the BTS. Paul OpenPGP_signature Description:

Bug#985617: glibc: flaky autopkgtest on most architectures

Hi Aurelien, On 25-04-2021 01:55, Aurelien Jarno wrote: > It appears that all the failures are related to containers. I have been > able to reproduce the issue with a bullseye kernel, which defaults to > kernel.unprivileged_userns_clone=1. It seems the autopkgtest runners > still use a buster

Bug#985617: glibc: flaky autopkgtest on most architectures

Hi Aurelien, On 21-03-2021 00:03, Aurelien Jarno wrote: > Yes, could you please provide a full log? I am not able to reproduce the > issue locally nor on barriere.d.o, so I have no idea what fails. Of course when you try to, it doesn't work. I had 5 runs on arm64 which all succeeded. I'm

Bug#985617: glibc: flaky autopkgtest on most architectures

Source: glibc Version: 2.31-9 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), Your package has an autopkgtest, great. However, I looked into the history of your autopkgtest [1] and I noticed it

Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system

Hi, On Fri, 5 Mar 2021 14:41:23 +0100 Aurelien Jarno wrote: > > Selecting previously unselected package libcrypt1:amd64. > > dpkg: considering deconfiguration of libc6:amd64, which would be broken by > > installation of libcrypt1:amd64 ... > > dpkg: yes, will deconfigure libc6:amd64 (broken by

Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

Hi, On Fri, 20 Nov 2020 13:44:50 +0100 Alois Wohlschlager wrote: > > > > Another option might be to have the new libc6 Conflict with old > > > > versions > > > > of Essential:yes packages that need libcrypt1, forcing those > > > > Essential:yes > > > > packages to get upgraded first. A quick

Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

Hi Ivo, Marco, On 06-04-2021 22:10, Ivo De Decker wrote: > I ran a number of (partial and full) upgrade tests, and they all seem to work > fine. In all cases, libcrypt1 is installed before libc6, and there is no > intermediate situations where libcrypt.so.1 is missing. The patch looks sensible

Bug#985617: glibc: flaky autopkgtest on most architectures

Hi Aurelien, On Mon, 22 Mar 2021 19:54:22 +0100 Paul Gevers wrote: > Hi Aurelien,, > > On 21-03-2021 00:03, Aurelien Jarno wrote: > > Yes, could you please provide a full log? I am not able to reproduce the > > issue locally nor on barriere.d.o, so I have no idea what fa

Bug#992654: glibc breaks ruby-rugged autopkgtest: RemoteNetworkTest#test_remote_check_connection_push_credentials

Control: reassign -1 ruby-rugged 1.1.0+ds-4 Control: retitle -1 ruby-rugged autopkgtest regressed in Augustus 2021 Control: tag -1 - unreproducible On 22-08-2021 00:32, Aurelien Jarno wrote: >> With a recent upload of glibc the autopkgtest of ruby-rugged fails in >> testing when that autopkgtest

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

On Thu, 12 Aug 2021 21:51:09 -0400 Andres Salomon wrote: > So this only affects users who do or do not have the ssh metapackage > installed? I'm pretty sure it effects both. Paul OpenPGP_signature Description: OpenPGP digital signature

Bug#992653: glibc breaks openconnect autopkgtest: FAIL: auth-nonascii

Source: glibc, openconnect Control: found -1 glibc/2.31-16 Control: found -1 openconnect/8.10-2 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of glibc the

Bug#992654: glibc breaks ruby-rugged autopkgtest: RemoteNetworkTest#test_remote_check_connection_push_credentials

Source: glibc, ruby-rugged Control: found -1 glibc/2.31-16 Control: found -1 ruby-rugged/1.1.0+ds-4 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of glibc the

Bug#992653: marked as pending in glibc

Control: reassign -1 src:glibc 2.31-16 Hi Aurelien, On 23-08-2021 21:31, Aurelien Jarno wrote: > Bug #992653 in glibc reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > >

checking on bookworm freeze dates proposal

Dear colleagues, The Release Team would like to propose a bookworm freeze timeline. Don't worry, the timeline is a plan, if serious (timing) issues come up we will adapt. However, before making the plan public in a wider audience, we'd like to know from you if you already foresee clashes in

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

Source: binutils, glibc Control: found -1 binutils/2.37.50.20220106-2 Control: found -1 glibc/2.33-2 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Control: affects -1 gcc-10 gcc-11 Dear maintainer(s),

Bug#1050530: python3.11: autopkgtest needs update for new version of tzdata

Source: python3.11 Version: 3.11.4-1 Severity: serious X-Debbugs-CC: tzd...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:tzdata Dear maintainer(s), With a recent upload of tzdata the autopkgtest of python3.11 fails in

Bug#1050529: python3.12: autopkgtest needs update for new version of tzdata

Source: python3.12 Version: 3.12.0~rc1-1 Severity: serious X-Debbugs-CC: tzd...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:tzdata Dear maintainer(s), With a recent upload of tzdata the autopkgtest of python3.12 fails in

Bug#1050528: gnustep-base: autopkgtest needs update for new version of tzdata

Source: gnustep-base Version: 1.29.0-6 Severity: serious X-Debbugs-CC: tzd...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:tzdata Dear maintainer(s), With a recent upload of tzdata the autopkgtest of gnustep-base fails in

Bug#1014109: gcc-12 breaks glibc autopkgtest on arm64: XFAIL: posix/annexc

Source: gcc-12, glibc Control: found -1 gcc-12/12.1.0-5 Control: found -1 glibc/2.33-7 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of gcc-12 the autopkgtest of glibc fails in testing on arm64 when

Bug#1020500: glibc: flaky autopkgtest on armel: multiple different failures

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)

Bug#1020500: glibc: flaky autopkgtest on armel: multiple different failures

Hi Aurelien, Thanks for your thorough testing. First off, we have recently changed our setup for armel and armhf testing. The real host is the same, but instead of one VM for armel where we ran 10 debci workers in parallel, we now have smaller VM's with only 4 parallel debci workers per VM.

Re: Bug#1025243: sudo: autopkgtest fails if glibc is upgraded in testbed (on s390x)

Hi Marc, On 09-12-2022 19:34, Marc Haber wrote: On Thu, Dec 01, 2022 at 01:02:45PM +0100, Paul Gevers wrote: And right after hitting the send button I realized that my reasoning is at least partially flawed. The testbed will always update glibc, because the testbed is build from testing

Re: sudo: autopkgtest fails if glibc is upgraded in testbed (on s390x)

Hi, On 01-12-2022 12:57, Paul Gevers wrote: I looked at the results of the autopkgtest of your package because it showed up in the glibc regressions. I noticed that it regularly fails on s390x [1] for the first try to test glibc (same happened at least once on i386 too). The retry one day

Bug#1025243: sudo: autopkgtest fails if glibc is upgraded in testbed (on s390x)

Source: sudo Version: 1.9.10-3 Severity: important X-Debbugs-CC: gl...@packages.debian.org openl...@package.debian.org User: debian...@lists.debian.org Usertags: flaky Control: affects -1 src:glibc slapd Dear maintainer(s), I looked at the results of the autopkgtest of your package because it

Bug#1060202: glibc - autopkgtest flacky on arm64

Hi, On 08-01-2024 01:45, Aurelien Jarno wrote: I am still not sure why it got killed on arm64 and not on other debci workers, there as still swap available. Actually looking at the munin plot, it seems that the arm64 debci workers stopped using swap around September 2023 contrary to the other

Bug#1060202: glibc - autopkgtest flacky on arm64

Hi, On 08-01-2024 01:45, Aurelien Jarno wrote: I am still not sure why it got killed on arm64 and not on other debci workers, there as still swap available. Actually looking at the munin plot, it seems that the arm64 debci workers stopped using swap around September 2023 contrary to the other

Bug#1060202: glibc - autopkgtest flacky on arm64

Hi all, On 08-01-2024 19:50, Paul Gevers wrote: Can you tell me how you saw that? I neither spotted that, nor is not having swap a conscious act, so rather a mistake. I just checked and it seems that on ci-worker-arm64-08 was not having swap. We did have /swap created as our other workers

Bug#1060202: glibc - autopkgtest flacky on arm64

Hi, On 07-01-2024 18:21, Aurelien Jarno wrote: Timeout while building: https://ci.debian.net/packages/g/glibc/unstable/arm64/41516611/ There are indeed many failures with cc1 getting killed, it seems that it started around 2024-01-02. I haven't spotted any change to the toolchain nor kernel