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 was installed on my multiarch system. After removal of the package I got apt telling me: The following packages were automatically installed and are no longer required: libc6-amd64:i386 libc6-dev:i386 linux-libc-dev:i386 Use 'apt-get autoremove' to remove them. So, I followed up with paul@wollumbin ~ $ sudo apt-get autoremove Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: libc6-amd64:i386 libc6-dev:i386 linux-libc-dev:i386 0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded. After this operation, 31.5 MB disk space will be freed. Do you want to continue [Y/n]? (Reading database ... 227583 files and directories currently installed.) Removing libc6-amd64 ... dpkg (subprocess): unable to execute installed post-removal script (/var/lib/dpkg/info/libc6-amd64.postrm): No such file or directory dpkg: error processing libc6-amd64 (--remove): subprocess installed post-removal script returned error exit status 2 Removing libc6-dev:i386 ... Removing linux-libc-dev:i386 ... Errors were encountered while processing: libc6-amd64 E: Problem executing scripts DPkg::Post-Invoke '/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 1 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null' E: Sub-process returned an error code E: Sub-process /usr/bin/dpkg returned an error code (1) Now, all my executables in /usr/bin and /bin are not usable: paul@wollumbin ~ $ ll /usr/bin/ bash: /bin/ls: No such file or directory I can still cd to /bin or /usr/bin, but the system complains that there the files are not there. I hope I still can fix this... but at the moment my possibilities are limited. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526c1485.30...@debian.org
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 like I need to create a rescue USB drive without the possibility to copy files around Hope I can do this. I'll leave my laptop on tonight, if anybody has a great idea, feel free to share. Paul -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526c1c28.2020...@debian.org
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 one issue remaining: what to do now with the half-installed state of libc6-amd64. Trivially, I don't trust removing libc6-amd64 will do the right thing and currently apt is blocked by the state of libc6-amd64. I thought reinstalling libc6-amd64 would at least keep apt happy, but no. paul@wollumbin ~/motif/debian-pkg-xshisen $ sudo apt-get install libc6-amd64 Reading package lists... Done Building dependency tree Reading state information... Done libc6-amd64:i386 is already the newest version. libc6-amd64:i386 set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 0 B/4,393 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue [Y/n]? dpkg: error processing libc6-amd64 (--configure): package libc6-amd64 is not ready for configuration cannot configure (current status `half-installed') Errors were encountered while processing: libc6-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) Advice is welcome. signature.asc Description: OpenPGP digital signature
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) you can do: apt-get remove libc6-amd64 cd lib64 /lib/x86_64-linux-gnu/ld-2.13.so /bin/rm ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/ld-2.13.so /bin/ln -s /lib/x86_64-linux-gnu/ld-2.13.so ld-linux-x86-64.so.2 Done. I haven't tested this sequence (as I did not have a root login available) but I am pretty sure this would work. Paul signature.asc Description: OpenPGP digital signature
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 #d-release. I now realize that's a bit longer
ago than I though. To quote you:
[00:00:00] - {Day changed to Monday, 26 April 2021}
[22:06:17] looks to me we have enough to fix and/or to debug on
our plate that we won't be issuing another RC in a week or so, so
freezing everyone (keeping everyone frozen) will only generate more
requests for acks; at this stage, it's likely easier to let stuff
migrate and deal with consequences afterward
I interpreted that as you are sort of fine at this moment if we migrated
the packages if they are otherwise fine. We should have agreed on a
schedule and it was on my TODO list to ask you today.
Additional note: glibc is on the list of build-essentials [1], so,
according to our freeze policy [2] it would have needed a pre-approval
already.
Paul
[1] https://release.debian.org/bullseye/essential-and-build-essential.txt
[2] https://release.debian.org/bullseye/freeze_policy.html#transition
OpenPGP_signature
Description: OpenPGP digital signature
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 we try to do is help each other. Paul OpenPGP_signature Description: OpenPGP digital signature
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 openssh-server package installed, not the ssh metapackage > (i.e. the package with the same name as the service). > > I've proposed > https://salsa.debian.org/glibc-team/glibc/-/merge_requests/3 to fix > this. glibc maintainers, if there's any way to get this into bullseye, > I'm sure it would help avoid some people upgrading remote systems ending > up being unable to fix them if something goes wrong between configuring > libc6 and configuring openssh-server. Also CCing debian-release for > their information, as I know it's pretty late for glibc changes. I think we really want this. I *think* I ran into exactly this issue two days ago when I upgraded my NAS. It's really scary to notice that you can't log into your system and your only connection is the current one running the upgrade. In my case, it was asking questions along the way. I had considered running the upgrade in screen. In the end it look longer than expected and I left my laptop on. If I would have run in screen and disconnected, I would have had no idea what hit me. Paul OpenPGP_signature Description: OpenPGP digital signature
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 autopkgtest of openconnect fails in testing when that autopkgtest is run with the binary packages of glibc from unstable. It passes when run with only packages from testing. In tabular form: passfail glibc from testing2.31-16 openconnectfrom testing8.10-2 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. Unfortunately, the log is rather brief. Currently this regression is blocking the migration of glibc to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from glibc/2.31-16. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=glibc https://ci.debian.net/data/autopkgtest/testing/amd64/o/openconnect/14748886/log.gz autopkgtest [07:17:01]: test upstream-test-suite: [--- PASS: auth-certificate FAIL: auth-nonascii PASS: auth-pkcs11 PASS: auth-username-pass PASS: id-test autopkgtest [07:17:36]: test upstream-test-suite: ---] OpenPGP_signature Description: OpenPGP digital signature
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 autopkgtest of ruby-rugged fails in testing when that autopkgtest is run with the binary packages of glibc from unstable. It passes when run with only packages from testing. In tabular form: passfail glibc from testing2.31-16 ruby-ruggedfrom testing1.1.0+ds-4 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of glibc to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from glibc/2.31-16. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=glibc https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-rugged/14750518/log.gz autopkgtest [11:15:38]: test gem2deb-test-runner: [--- ┌──┐ │ Checking Rubygems dependency resolution on ruby2.7 │ └──┘ GEM_PATH= ruby2.7 -e gem\ \"rugged\" ┌──┐ │ Run tests for ruby2.7 from debian/ruby-tests.rb │ └──┘ mv lib .gem2deb.lib mv ext .gem2deb.ext RUBYLIB=. GEM_PATH= ruby2.7 debian/ruby-tests.rb Run options: --seed 56390 # Running: S....F... Finished in 16.209826s, 33.8683 runs/s, 144.0484 assertions/s. 1) Failure: RemoteNetworkTest#test_remote_check_connection_push_credentials [/tmp/autopkgtest-lxc.3h184rhw/downtmp/build.1At/src/test/remote_test.rb:40]: Expected false to be truthy. 549 runs, 2335 assertions, 1 failures, 0 errors, 5 skips You have skipped tests. Run with --verbose for details. mv .gem2deb.lib lib mv .gem2deb.ext ext autopkgtest [11:15:55]: test gem2deb-test-runner: ---] OpenPGP_signature Description: OpenPGP digital signature
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 is run with the binary packages of glibc >> from unstable. It passes when run with only packages from testing. In >> tabular form: >> >>passfail >> glibc from testing2.31-16 >> ruby-ruggedfrom testing1.1.0+ds-4 >> versioned deps [0] from testingfrom unstable >> all others from testingfrom testing > > Unfortunately I have not been able to reproduce this behaviour. > > In my testing, the autopktest failure happens already happen in pure > testing (i.e. glibc 2.31-13), and it also appears with testing + glibc > 2.31-16. I therefore don't believe glibc has anything to do with this > failure. The migration-reference/0 result on arm64 agrees with you, hence reassigning to ruby-rugged alone. Paul OpenPGP_signature Description: OpenPGP digital signature
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: > > https://salsa.debian.org/glibc-team/glibc/-/commit/f19229fededcccf1b5a9803840ad46d52a803c98 > > > Replace the non UTF-8 locales removal by a deprecation as they are still used > in many other packages > > * Replace the non UTF-8 locales removal by a deprecation as they are still > used in many other packages (especially testsuites): non UTF-8 locales are > not offered anymore in the debconf dialog (except for the ones already > configured), but they are still listed in SUPPORTED and provided in the > locales-all package (Closes: #992500, #992653): > - debian/patches/localedata/locale-en_DK.diff, > debian/patches/localedata/locale-eu_FR.diff, > debian/patches/localedata/supported.diff: revert the removal of non-UTF-8 > locales. > - debian/debhelper.in/locales-all.NEWS: remove 2.31-14 entry. > - debian/rules.d/debhelper.mk: fill __PROVIDED_LOCALES__ with UTF-8 > locales only. > If I understand correctly, you'd still want openconnect to drop testing in the way it does now. Should we clone this bug and assign the clone to openconnect (at lower severity)? Paul OpenPGP_signature Description: OpenPGP digital signature
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),
With a recent upload of binutils the autopkgtest of glibc fails in
testing when that autopkgtest is run with the binary packages of
binutils from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
binutils from testing2.37.50.20220106-2
glibc from testing2.33-2
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of binutils, gcc-10
and gcc-11 to testing [1]. Due to the nature of this issue, I filed this
bug report against the binutils and glibc source packages. Can you
please investigate the situation and reassign the bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=binutils
https://ci.debian.net/data/autopkgtest/testing/ppc64el/g/glibc/18280958/log.gz
powerpc64le-linux-gnu-gcc-10
../sysdeps/ieee754/ldbl-128ibm/tst-strtold-ldbl-128ibm.c -c -std=gnu11
-fgnu89-inline -pipe -O2 -g
-fdebug-prefix-map=/tmp/autopkgtest-lxc.448kjxt6/downtmp/build.UW5/src=.
-mcpu=power8 -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants
-frounding-math -fstack-protector-strong -Wstrict-prototypes
-Wold-style-definition -fmath-errno -mabi=ieeelongdouble -Wno-psabi
-mno-gnu-attribute -mlong-double-128 -mabi=ibmlongdouble
-isystem
/tmp/autopkgtest-lxc.448kjxt6/downtmp/build.UW5/src/debian/include
-I../include
-I/tmp/autopkgtest-lxc.448kjxt6/downtmp/build.UW5/src/build-tree/ppc64el-libc/stdlib
-I/tmp/autopkgtest-lxc.448kjxt6/downtmp/build.UW5/src/build-tree/ppc64el-libc
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64/le/fpu
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64/fpu
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64/le
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64
-I../sysdeps/unix/sysv/linux/wordsize-64
-I../sysdeps/unix/sysv/linux/powerpc -I../sysdeps/powerpc/nptl
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux
-I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix/powerpc -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/powerpc/powerpc64/le/power8/fpu/multiarch
-I../sysdeps/powerpc/powerpc64/le/power7/fpu/multiarch
-I../sysdeps/powerpc/powerpc64/le/fpu/multiarch
-I../sysdeps/powerpc/powerpc64/le/power8/fpu
-I../sysdeps/powerpc/powerpc64/le/power7/fpu
-I../sysdeps/powerpc/powerpc64/le/fpu
-I../sysdeps/powerpc/powerpc64/fpu
-I../sysdeps/powerpc/powerpc64/le/power8/multiarch
-I../sysdeps/powerpc/powerpc64/le/power7/multiarch
-I../sysdeps/powerpc/powerpc64/le/multiarch
-I../sysdeps/powerpc/powerpc64/multiarch
-I../sysdeps/powerpc/powerpc64/le/power8
-I../sysdeps/powerpc/powerpc64/power8
-I../sysdeps/powerpc/powerpc64/le/power7
-I../sysdeps/powerpc/powerpc64/power7
-I../sysdeps/powerpc/powerpc64/power6
-I../sysdeps/powerpc/powerpc64/power4 -I../sysdeps/powerpc/power4
-I../sysdeps/powerpc/powerpc64/le -I../sysdeps/powerpc/powerpc64
-I../sysdeps/wordsize-64 -I../sysdeps/powerpc/fpu -I../sysdeps/powerpc
-I../sysdeps/ieee754/ldbl-128ibm-compat
-I../sysdeps/ieee754/ldbl-128ibm/include
-I../sysdeps/ieee754/ldbl-128ibm -I../sysdeps/ieee754/ldbl-opt
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/float128 -I../sysdeps/ieee754
-I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem
/usr/lib/gcc/powerpc64le-linux-gnu/10/include -isystem
/tmp/autopkgtest-lxc.448kjxt6/downtmp/build.UW5/src/debian/include
-D_LIBC_REENTRANT -include
/tmp/autopkgtest-lxc.448kjxt6/downtmp/build.UW5/src/build-tree/ppc64el-libc/libc-modules.h
-DMODULE_NAME=testsuite -include ../include/libc-symbols.h -DPIC
-DTOP_NAMESPACE=glibc -o
/tmp/autopkgtest-lxc.448kjxt6/downtmp/build.UW5/src/build-tree/ppc64el-libc/stdlib/tst-strtold-ldbl-128ibm.o
-MD -MP -MF
/tmp/autopkgtest-lxc.448kjxt6/downtmp/build.UW5/src/build-tree/ppc64el-libc/stdlib/tst-strtold-ldbl-128ibm.o.dt
-MT
/tmp/autopkgtest-lxc.448kjxt6/downtmp/build.UW5/src/build-tree/ppc64el-libc/stdlib/tst-strtold-ldbl-128ibm.o
{standard input}: Assembler messages:
{standard input}:78: Error: unrecognized opcode: `vspltisb'
{standard input}:79: Error: unrecognized opcode: `vspltisb'
{standard input}:80: Error: unrecognized opcode: `vpkuwus'
{standard input}:81: Error: unrecognized opcode: `mfvscr'
{standard input}:82: Error: unrecognized opcode: `stvx'
make[3]: ***
[/tmp/autopkgtest-lxc.448kjxt6/downtmp/build.UW5/src
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 timing from the kernel, gcc, binutils and glibc that we should take into account. Does the following timeline seem reasonable to you considering plans of your upstream? (the bullseye schedule + 2 years): 2023-01-12 - Milestone 1 - Transition and Toolchain freeze 2023-02-12 - Milestone 2 - Soft Freeze 2023-03-12 - Milestone 3 - Hard Freeze TBA- Milestone 4 - Full Freeze On behalf of the Release Team, Paul OpenPGP_signature Description: OpenPGP digital signature
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 that autopkgtest is run with the binary packages of gcc-12
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
gcc-12 from testing12.1.0-5
glibc from testing2.33-7
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of gcc-12 to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=gcc-12
https://ci.debian.net/data/autopkgtest/testing/arm64/g/glibc/23190432/log.gz
'GCONV_PATH=/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/iconvdata
LOCPATH=/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/localedata
LC_ALL=C' '
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/elf/ld-linux-aarch64.so.1
--library-path
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/math:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/elf:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/dlfcn:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/nss:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/nis:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/rt:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/resolv:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/mathvec:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/support:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/nptl';
\
../scripts/evaluate-test.sh posix/wordexp-tst $? false false >
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/posix/wordexp-tst.test-result
$* test failed
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/posix/annexc
'aarch64-linux-gnu-gcc-10' \
'-I../csu -I../iconv -I../locale -I../localedata -I../iconvdata
-I../assert -I../ctype -I../intl -I../catgets -I../math -I../setjmp
-I../signal -I../stdlib -I../stdio-common -I../libio -I../dlfcn
-I../nptl -I../malloc -I../string -I../wcsmbs -I../timezone -I../time
-I../dirent -I../grp -I../pwd -I../posix -I../io -I../termios
-I../resource -I../misc -I../socket -I../sysvipc -I../gmon -I../gnulib
-I../wctype -I../manual -I../shadow -I../gshadow -I../po -I../argp
-I../rt -I../conform -I../debug -I../mathvec -I../support -I../nptl_db
-I../inet -I../resolv -I../nss -I../hesiod -I../sunrpc -I../nis
-I../nscd -I../login -I../elf -I../include
-I/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc
-I../sysdeps/unix/sysv/linux/aarch64 -I../sysdeps/aarch64/nptl
-I../sysdeps/unix/sysv/linux/generic
-I../sysdeps/unix/sysv/linux/wordsize-64
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux
-I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix
-I../sysdeps/posix -I../sysdeps/aarch64/fpu
-I../sysdeps/aarch64/multiarch -I../sysdeps/aarch64
-I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-128
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754 -I../sysdeps/generic -nostdinc -isystem
/usr/lib/gcc/aarch64-linux-gnu/10/include -isystem
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/debian/include -I..'
>
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/posix/annexc.out;
\
../scripts/evaluate-test.sh posix/annexc $? true false >
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/posix/annexc.test-result
${*} test failed
$@ test failed
$* quoted test failed
$@ quoted test failed
$# test failed
$2 ${3} $4 test failed
${11} test failed
"a $@ b" test failed
-
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/posix/wordexp-test-result10
differ: char 1, line 1
OpenPGP_signature
Description: OpenPGP digital signature
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) 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. Paul 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' -- 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 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) -- 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 OpenPGP_signature Description: OpenPGP digital signature
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. Maybe this changes some of the metrics. 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. 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? Yes, and as mentioned above we changed it too. But as said, we ran a lot of parallel workers, so they could be heavy loaded. We also have an amd64 host that runs lots of parallel workers, and so does s390x, but maybe they are a bit better spec-ed than the armel VM was. 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 That's good to hear. So, lets see the coming time if thing changed (hopefully for the better).. Paul OpenPGP_signature Description: OpenPGP digital signature
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 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 later works. On ci.d.n, we rebuild our containers on a daily basis, so I suspect this has to do with glibc being updated in the testbed, the testbed not being restarted and than causing issues. I'm actually in dubio if I should file this bug against sudo, as it may only be the messenger, hence I x-debbugs-cc-ed the glibc and openldap maintainers into the bug too. Please let us figure out where the issue lies and reassign appropriately. Paul [1] https://ci.debian.net/packages/s/sudo/testing/s390x/ https://ci.debian.net/data/autopkgtest/testing/s390x/s/sudo/28781616/log.gz autopkgtest [01:07:28]: test 03-getroot-ldap: [--- clean up ldap database ... reconfigure slapd ... start slapd ... add sudo schema to slapd ... autopkgtest [01:07:30]: test 03-getroot-ldap: ---] 03-getroot-ldap FAIL non-zero exit status 253 OpenPGP_signature Description: OpenPGP digital signature
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 later works. On ci.d.n, we rebuild our containers on a daily basis, so I suspect this has to do with glibc being updated in the testbed, the testbed not being restarted and than causing issues. I'm actually in dubio if I should file this bug against sudo, as it may only be the messenger, hence I x-debbugs-cc-ed the glibc and openldap maintainers into the bug too. Please let us figure out where the issue lies and reassign appropriately. 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, and glibc hasn't migrated yet. Still, it's a weird pattern. Paul OpenPGP_signature Description: OpenPGP digital signature
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, and glibc hasn't migrated yet. Still, it's a weird pattern. Is there still something that sudo can do here? The last pure testing run [1] also failed, so maybe all the glibc triggered failures were just coincidence and the test is flaky (on s390x). I fixed an issue in the ldap autopkgtest¹ recently, but your logs looks like the test gets further than the place where this issue errors out. Would more output in the test help? I would say this always helps. What is the canonical way to write a test that can have its verbosity turned up for debugging, how is this wish communicated to a system that runs the tests in an automated way? Why would you want to disable verbosity of tests? I recommend to always enable verbose logs. There's no way to trigger an existing test on the infrastructure with different options/environment variables. However, when run manually one has the full freedom to ask autopkgtest to run commands before the actual test in the testbed. Can a mere mortal DD run an autopkgtest on a porterbox? Yes. I suggest to check https://salsa.debian.org/mbanck/dd-autopkgtest/ for a helper script to do that. Paul [1] https://ci.debian.net/data/autopkgtest/testing/s390x/s/sudo/29143772/log.gz OpenPGP_signature Description: OpenPGP digital signature
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 testing when that autopkgtest is run with the binary packages of tzdata from unstable. It passes when run with only packages from testing. In tabular form: passfail tzdata from testing2023c-10 gnustep-base from testing1.29.0-6 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of tzdata to testing [1]. Of course, tzdata shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in tzdata was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from tzdata should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=tzdata https://ci.debian.net/data/autopkgtest/testing/amd64/g/gnustep-base/37117679/log.gz 106s Tests/base/NSCalendarDate/test00.m: 106s Failed test: (2023-08-25 06:10:33.417 +) test00.m:253 ... date check with 2002-03-31 01:30:00 106s Failed test: (2023-08-25 06:10:33.417 +) test00.m:268 ... date check with 2002-03-31 01:30:00 106s Failed test: (2023-08-25 06:10:33.417 +) test00.m:272 ... date check with 2002-03-31 00:30:00 106s Failed test: (2023-08-25 06:10:33.417 +) test00.m:430 ... date year calculation preserves timezone OpenPGP_signature.asc Description: OpenPGP digital signature
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 testing when that autopkgtest is run with the binary packages of tzdata from unstable. It passes when run with only packages from testing. In tabular form: passfail tzdata from testing2023c-10 python3.12 from testing3.12.0~rc1-1 all others from testingfrom testing I copied some of the output at the bottom of this report. I note that src:tzdata recently introduced a tzdata-legacy package although I don't know if that has to do with the failure. Currently this regression is blocking the migration of tzdata to testing [1]. Of course, tzdata shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in tzdata was intended and your package needs to update to the new situation. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=tzdata https://ci.debian.net/data/autopkgtest/testing/amd64/p/python3.12/37119077/log.gz 947s == 947s FAIL: test_variable_tzname (test.test_email.test_utils.LocaltimeTests.test_variable_tzname) 947s -- 947s Traceback (most recent call last): 947s File "/usr/lib/python3.12/test/support/__init__.py", line 862, in inner 947s return func(*args, **kwds) 947s^^^ 947s File "/usr/lib/python3.12/test/test_email/test_utils.py", line 155, in test_variable_tzname 947s self.assertEqual(t1.tzname(), 'MSK') 947s AssertionError: 'Europe' != 'MSK' 947s - Europe 947s + MSK OpenPGP_signature.asc Description: OpenPGP digital signature
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 testing when that autopkgtest is run with the binary packages of tzdata from unstable. It passes when run with only packages from testing. In tabular form: passfail tzdata from testing2023c-10 python3.11 from testing3.11.4-1 all others from testingfrom testing I copied some of the output at the bottom of this report. I note that src:tzdata recently introduced a tzdata-legacy package although I don't know if that has to do with the failure. Currently this regression is blocking the migration of tzdata to testing [1]. Of course, tzdata shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in tzdata was intended and your package needs to update to the new situation. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=tzdata https://ci.debian.net/data/autopkgtest/testing/amd64/p/python3.11/37127326/log.gz 1107s == 1107s FAIL: test_variable_tzname (test.test_email.test_utils.LocaltimeTests.test_variable_tzname) 1107s -- 1107s Traceback (most recent call last): 1107s File "/usr/lib/python3.11/test/support/__init__.py", line 847, in inner 1107s return func(*args, **kwds) 1107s^^^ 1107s File "/usr/lib/python3.11/test/test_email/test_utils.py", line 155, in test_variable_tzname 1107s self.assertEqual(t1.tzname(), 'MSK') 1107s AssertionError: 'Europe' != 'MSK' 1107s - Europe 1107s + MSK OpenPGP_signature.asc Description: OpenPGP digital signature
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 version. I am not able to reproduce the issue, so it is very likely linked to debci. Would it be possible to now why cc1 get killed? OOM? timeout? I extracted the attached journal piece indicating OOM. Failed test: https://ci.debian.net/packages/g/glibc/testing/arm64/40439311/ This one is too old, the date is not in the journal anymore. Paul Jan 03 22:53:54 ci-worker-arm64-03 kernel: dpkg-query invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0 Jan 03 22:53:54 ci-worker-arm64-03 kernel: CPU: 1 PID: 2152163 Comm: dpkg-query Tainted: GW 6.4.0-0.deb12.2-arm64 #1 Debian 6.4.4-3~bpo12+1 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Hardware name: OpenStack Foundation OpenStack Nova, BIOS 0.0.0 02/06/2015 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Call trace: Jan 03 22:53:54 ci-worker-arm64-03 kernel: dump_backtrace+0xa0/0x128 Jan 03 22:53:54 ci-worker-arm64-03 kernel: show_stack+0x20/0x38 Jan 03 22:53:54 ci-worker-arm64-03 kernel: dump_stack_lvl+0x48/0x60 Jan 03 22:53:54 ci-worker-arm64-03 kernel: dump_stack+0x18/0x28 Jan 03 22:53:54 ci-worker-arm64-03 kernel: dump_header+0x4c/0x218 Jan 03 22:53:54 ci-worker-arm64-03 kernel: oom_kill_process+0x148/0x308 Jan 03 22:53:54 ci-worker-arm64-03 kernel: out_of_memory+0xec/0x5a0 Jan 03 22:53:54 ci-worker-arm64-03 kernel: __alloc_pages+0xca0/0xde8 Jan 03 22:53:54 ci-worker-arm64-03 kernel: alloc_pages+0xb4/0x160 Jan 03 22:53:54 ci-worker-arm64-03 kernel: folio_alloc+0x24/0x68 Jan 03 22:53:54 ci-worker-arm64-03 kernel: filemap_alloc_folio+0x144/0x160 Jan 03 22:53:54 ci-worker-arm64-03 kernel: __filemap_get_folio+0xf0/0x2f8 Jan 03 22:53:54 ci-worker-arm64-03 kernel: filemap_fault+0x49c/0x998 Jan 03 22:53:54 ci-worker-arm64-03 kernel: __do_fault+0x44/0x230 Jan 03 22:53:54 ci-worker-arm64-03 kernel: __handle_mm_fault+0xb8c/0x1238 Jan 03 22:53:54 ci-worker-arm64-03 kernel: handle_mm_fault+0x160/0x290 Jan 03 22:53:54 ci-worker-arm64-03 kernel: do_page_fault+0x270/0x490 Jan 03 22:53:54 ci-worker-arm64-03 kernel: do_translation_fault+0x54/0x70 Jan 03 22:53:54 ci-worker-arm64-03 kernel: do_mem_abort+0x4c/0xa8 Jan 03 22:53:54 ci-worker-arm64-03 kernel: el0_ia+0x70/0x148 Jan 03 22:53:54 ci-worker-arm64-03 kernel: el0t_64_sync_handler+0xc4/0x120 Jan 03 22:53:54 ci-worker-arm64-03 kernel: el0t_64_sync+0x190/0x198 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Mem-Info: Jan 03 22:53:54 ci-worker-arm64-03 kernel: active_anon:644290 inactive_anon:541258 isolated_anon:0 active_file:488 inactive_file:211 isolated_file:0 unevictable:0 dirty:10 writeback:0 slab_reclaimable:84360 slab_unreclaimable:712733 mapped:536 shmem:947 pagetables:3927 sec_pagetables:0 bounce:0 kernel_misc_reclaimable:0 free:31884 free_pcp:100 free_cma:0 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 active_anon:2577160kB inactive_anon:2165032kB active_file:1952kB inactive_file:844kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:2144kB dirty:40kB writeback:0kB shmem:3788kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 6144kB writeback_tmp:0kB kernel_stack:4512kB pagetables:15708kB sec_pagetables:0kB all_unreclaimable? no Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 DMA free:36984kB boost:0kB min:17152kB low:21440kB high:25728kB reserved_highatomic:0KB active_anon:1498272kB inactive_anon:1194072kB active_file:792kB inactive_file:436kB unevictable:0kB writepending:4kB present:3145728kB managed:3080192kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Jan 03 22:53:54 ci-worker-arm64-03 kernel: lowmem_reserve[]: 0 0 4929 4929 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 Normal free:90552kB boost:0kB min:27900kB low:34872kB high:41844kB reserved_highatomic:0KB active_anon:1078488kB inactive_anon:971360kB active_file:28kB inactive_file:1176kB unevictable:0kB writepending:36kB present:5242880kB managed:5047724kB mlocked:0kB bounce:0kB free_pcp:364kB local_pcp:0kB free_cma:0kB Jan 03 22:53:54 ci-worker-arm64-03 kernel: lowmem_reserve[]: 0 0 0 0 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 DMA: 1014*4kB (UME) 1017*8kB (UME) 304*16kB (UME) 327*32kB (UME) 95*64kB (UME) 28*128kB (UME) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 37184kB Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 Normal: 219*4kB (E) 994*8kB (UE) 1709*16kB (UE) 1672*32kB (UE) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB
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 architectures. Can you tell me how you saw that? I neither spotted that, nor is not having swap a conscious act, so rather a mistake. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
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, but apparently that was never made a swap file and mounted. After fixing, now $(cat /proc/meminfo | grep SwapTotal) says: ci-worker-arm64-02: SwapTotal: 4084220 kB ci-worker-arm64-03: SwapTotal: 4084220 kB ci-worker-arm64-04: SwapTotal: 4084220 kB ci-worker-arm64-06: SwapTotal: 4084220 kB ci-worker-arm64-05: SwapTotal: 4084220 kB ci-worker-arm64-07: SwapTotal: 4084220 kB ci-worker-arm64-11: SwapTotal: 4084220 kB ci-worker-arm64-10: SwapTotal: 4084220 kB ci-worker-arm64-08: SwapTotal: 4084220 kB ci-worker-arm64-09: SwapTotal: 4084220 kB Paul OpenPGP_signature.asc Description: OpenPGP digital signature
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 architectures. This does seem to align with us upgrading from the bookworm kernel to the backports kernel because of bug 1050256. That still doesn't explain while the problem with glibc seems to have started one week ago. Indeed, but 4 GB of swap looks like it would help. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
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 blacklisting glibc for now, and will revisit that when this bug gets > closed. Soon, we want to use autopkgtest results to influence unstable-to-testing migration. It would be a shame to have glibc missing. Paul signature.asc Description: OpenPGP digital signature
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 >> 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 can drop the autopkg tests entries in the next upload if that can help. No, that doesn't help anything, as the current situation already achieves the same thing. We are on the verge of enabling autopkgtest influence on unstable-to-testing migration and only a working autopkgtest changes anything there. Having glibc autopkgtest appears to me like a very-nice-to-have. Do you know why the autopkgtest runs so long? As Antonio mentioned in other similar bug reports, the time out only counts for individual test cases, so if you can break down the autopkgtest into smaller fragments, the time out may not be an issue. I haven't checked if glibc does, but remember that the idea is to test as-installed packages, so rebuilding should be avoided unless needed for the test itself. Even then, when test need binaries/artifacts that aren't build by default, one could create a binary package containing these artifacts in the regular build and depend on it while autopkgtesting. E.g. MariaDB/MySQL do that. Paul signature.asc Description: OpenPGP digital signature
Bug#903389: glibc/2.27-4 appears to break unrar-free/1:0.0.1+cvs20140707-4 autopktest: different Valgrind status codes
Source: glibc, unrar-free Version: glibc/2.27-4 Version: unrar-free/1:0.0.1+cvs20140707-4 User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainers, With a recent upload of glibc the autopkgtest of unrar-free started to fail in unstable and testing. I have copied the error below. Currently this regression is delaying the migration of glibc to testing by 13 days. Could you please investigate the situation and determine which package needs to fix something, and assign appropriately? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul https://ci.debian.net/data/autopkgtest/testing/amd64/u/unrar-free/580036/log.gz autopkgtest [04:34:30]: test 0003-CVE-2017-14122: [--- testList ==2455== Memcheck, a memory error detector ==2455== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2455== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2455== Command: unrar-free --list unrar-gpl-stack-overread.rar ==2455== ==2455== Conditional jump or move depends on uninitialised value(s) ==2455==at 0x4CD8251: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2455==by 0x4D47C9B: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2455==by 0x300017: ??? ==2455==by 0x1FFF00082F: ??? ==2455==by 0x1FFF00075F: ??? ==2455==by 0x7BA89AD5AB3DB7FF: ??? ==2455== Uninitialised value was created ==2455==at 0x4D2FF79: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2455==by 0x4D30050: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2455==by 0x4DF8C3F: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2455==by 0x24F: ??? ==2455==by 0x20FFF: ??? ==2455==by 0x4CC5FD8: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2455== unrar 0.0.1 Copyright (C) 2004 Ben Asselstine, Jeroen Dekkers RAR archive /tmp/autopkgtest-lxc.2yuhzvmm/downtmp/build.vTB/src/unrar-gpl-stack-overread.rar Pathname/Comment Size Packed Ratio Date Time Attr CRC Meth Ver --- 00 0% 00-00-00 00:00 .A m�? 0.0 --- 100 -nan% ==2455== ==2455== HEAP SUMMARY: ==2455== in use at exit: 0 bytes in 0 blocks ==2455== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==2455== ==2455== All heap blocks were freed -- no leaks are possible ==2455== ==2455== For counts of detected and suppressed errors, rerun with: -v ==2455== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ASSERT:Valgrind status code expected:<0> but was:<122> testExtract ==2461== Memcheck, a memory error detector ==2461== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2461== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2461== Command: unrar-free --extract unrar-gpl-stack-overread.rar ==2461== ==2461== Conditional jump or move depends on uninitialised value(s) ==2461==at 0x4CD8251: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x4D47C9B: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x300017: ??? ==2461==by 0x1FFF00081F: ??? ==2461==by 0x1FFF00074F: ??? ==2461==by 0x8ADEDE16FA0B85FF: ??? ==2461==by 0x77007B: ??? ==2461== Uninitialised value was created ==2461==at 0x4D2FF79: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x4D30050: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x4DF8C3F: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x24F: ??? ==2461==by 0x20FFF: ??? ==2461==by 0x4CC5FD8: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461== ==2461== Conditional jump or move depends on uninitialised value(s) ==2461==at 0x4CD8251: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x4CC7EED: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461== Uninitialised value was created ==2461==at 0x4D2FF79: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x4D30050: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x4DF8C3F: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x24F: ??? ==2461==by 0x20FFF: ??? ==2461==by 0x4CC5FD8: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461== ==2461== Conditional jump or move depends on uninitialised value(s) ==2461==at 0x4CDD923: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x4015489: ??? (in /lib/x86_64-linux-gnu/ld-2.27.so) ==2461==by 0xFFAF: ??? ==2461==by 0x3F: ??? ==2461==by 0x700100: ??? ==2461==by 0x7: ??? ==2461== Uninitialised value was created ==2461==at 0x4D2FF79: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x4D30050: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==2461==by 0x4DF8C3F: ??? (in /lib/x86_64-linux-gnu/libc-2.
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 moment (also, the test passes there). Because the autopkgtest of gnupg2 does this, the regular fall-back isn't available and the test errors out. Does anybody see what goes wrong? And how should this be solved? If not I recommend to add a "flaky" restriction to the restrictions of the autopktest of gnupg2 as it seems to me that this isn't suitable for unstable-to-testing migration checks. Paul ¹ https://qa.debian.org/excuses.php?package=glibc https://ci.debian.net/data/autopkgtest/testing/amd64/g/gnupg2/580042/log.gz Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: wine32:i386 : Depends: libc6:i386 (>= 2.17) but it is not going to be installed Depends: libwine:i386 (= 3.0.2-1) but it is not going to be installed E: Unable to correct problems, you have held broken packages. autopkgtest [04:35:17]: test gpgv-win32: ---] signature.asc Description: OpenPGP digital signature
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,
>
> I have found it:
>
> debian/tests/gpgv-win32 manually installs wine32 using apt.
I noticed my original e-mail wasn't very clear because I thought the
above was obvious.
> This seems quite wrong. If a package needs to be installed, it should
> be handled via Depends in debian/tests/control. Otherwise all of the
> machinery to select which packages are being tested is utterly
> defeated.
Some packages have the purpose of installing stuff, so they may want to
do so I guess (e.g. apt does that). So I nearly agree with your
argument, but not fully. But as an example of your argument we already
have bug #900470 where syslog-ng tries to upgrade upgrade itself but
fails to do so due to our setup. The argument should be that in
autopkgtests the setup may be weird and tests should not need to know. I
guess what gnupg2 wants/needs is a way to either declare multi-arch
(maybe a new restriction?) with semantics to declare the dependencies
there or maybe they would be happy with an i386 test only, but ci.d.n
doesn't have that yet.
Paul
signature.asc
Description: OpenPGP digital signature
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 relatively current > hardware taking 2 minutes, plus 12 to 15 minutes to build and run the > test suite (all with parallel make, although parallel make for tests > is disabled automatically for some subdirectories). 200 minutes on > current (amd64) hardware sounds quite excessive. I just did a retry on our infrastructure and it ran in 57 minutes. But it ran on one of the two big workers (8 cores and 30 GB memory). We want to make all workers equal and we are going down to 2 cores and 7.2 GB. Could it be that the memory is the actual problem and/or also an issue? Paul signature.asc Description: OpenPGP digital signature
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 autopkgtest testbed isn't supported. I have seen packages try (gnupg2), but this goes easily wrong considering the unstable-to-testing migration setup. If there is a real need for this, it should come from autopkgtest. Paul signature.asc Description: OpenPGP digital signature
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). >> >> I am not sure if I understand what you mean, but currently having >> multiple arches available in the autopkgtest testbed isn't supported. I >> have seen packages try (gnupg2), but this goes easily wrong considering >> the unstable-to-testing migration setup. If there is a real need for >> this, it should come from autopkgtest. > In concrete terms, what I meant was: Why build libc6-i386 on amd64 > when there is a libc6:i386 package as well? I have no idea. > In Fedora, there's a restriction that buildds cannot install foreign > architecture packages. Some packages need a 32-bit glibc on a 64-bit > builder, too. (Typical gcc flags, for example, or fake amd64 packages > such as amd64). That made me wonder if Debian has a similar > restriction for its buildds. I don't know what the restrictions are on buildds. But autopkgtest doesn't run on buildds, so I'm not sure if you question is relevant (unless the above paragraph answers your own question). In autopkgtest installing foreign architecture packages isn't supported yet as I mentioned in my previous e-mail. Paul signature.asc Description: OpenPGP digital signature
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 > > > > 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 relatively current > > > hardware taking 2 minutes, plus 12 to 15 minutes to build and run the > > > test suite (all with parallel make, although parallel make for tests > > > is disabled automatically for some subdirectories). 200 minutes on > > > current (amd64) hardware sounds quite excessive. > > > > I just did a retry on our infrastructure and it ran in 57 minutes. But > > it ran on one of the two big workers (8 cores and 30 GB memory). We want > > to make all workers equal and we are going down to 2 cores and 7.2 GB. > > > > Could it be that the memory is the actual problem and/or also an issue? > > I don't think think the memory is really a problem, at least not for the > values you give. A few tests might be memory hungry, but 4GB should be > enough. I retried another time, now that all the workers are equivalent. The current test suite runs in around 2:10 on our infrastructure. Albeit long, I will remove glibc from the blacklist. However, we would still appreciate it when the test can be made smarter. Paul signature.asc Description: OpenPGP digital signature
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. These autopkgtests all run abi-compliance-checker and fail on it. Currently these regressions are contributing to the delay of the migration of glibc [1] and abi-compliance-checker [2] to testing. Could you please help to investigate the situation? Normally I would file bugs but because the similarity between the packages that fail for glibc and abi-compliance-checker and the fact that three packages fail I fell back to this e-mail, as it seems to be too much coincidence. Feel free to ask help about the CI side of things from the Debian-CI team (in CC). More information about this e-mail can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=glibc [2] https://qa.debian.org/excuses.php?package=abi-compliance-checker signature.asc Description: OpenPGP digital signature
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 that there are more logs in the artifacts. Paul signature.asc Description: OpenPGP digital signature
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-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 that there are more logs in the artifacts. >> >> Ah, right. They seem to only point at c++ headers, so it'd rather be a >> g++ issue? > > All the passed artifacts I can find have libc++-dev 6.0.1-1, not > libc++-8-dev 1:8~svn340819-1. 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? Does anybody know why libc++-8-dev is installed when glibc or abi-compliance-checker come from unstable? It seems that package is providing something that in testing is provided by libc++-dev (Or somewhere else in the dependency chain this goes "wrong" and leads to this outcome). This is maybe also the reason why the autopkgtest of these packages fail already longer in unstable. Apparently the wrong libc++*-dev package gets installed. Paul PS to all: if we determine how this goes wrong and if I can't get the CI framework to do the right thing and this is outside of glibc and abi-compliance-checker, I'll ask the migration software to ignore these failures. signature.asc Description: OpenPGP digital signature
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 process this package migrated to >> testing on 2018-08-26 despite the RC bug. It has been removed from >> testing during last night. >> >>> Does anybody know why libc++-8-dev is installed when glibc or >>> abi-compliance-checker come from unstable? It seems that package is >>> providing something that in testing is provided by libc++-dev (Or >>> somewhere else in the dependency chain this goes "wrong" and leads to >>> this outcome). >> >> I have been able to install libc++-dev along glibc 2.27-6, so I wonder >> if it is not just a matter of regenerating the testing chroot following >> the libc++-8-dev removal from testing. > > the containers on ci.debian.net are recreated from scratch once a day, > so this should solve itsef, I guess? I don't know. In the failing cases, libc++-8-dev was installed from unstable, not from testing: Get:2 http://deb.debian.org/debian unstable/main amd64 libc++abi1-8 amd64 1:8~svn340819-1 [81.3 kB] Get:3 http://deb.debian.org/debian unstable/main amd64 libc++1-8 amd64 1:8~svn340819-1 [214 kB] Get:4 http://deb.debian.org/debian unstable/main amd64 libc++-8-helpers all 1:8~svn340819-1 [28.3 kB] Get:5 http://deb.debian.org/debian unstable/main amd64 libc++-8-dev amd64 1:8~svn340819-1 [1,473 kB] 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 know (and I will spend some time on it) is what in the dependency chain makes us end up with this as an option. Paul signature.asc Description: OpenPGP digital signature
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 know (and I will spend some time on it) is what in the > dependency chain makes us end up with this as an option. I was not able to figure out in the time I spend on it why apt-get ended up with installing those packages. Does anybody know the right commands and their arguments to figure out this specific question? Paul PS: the last line that I used was: apt-cache dotty $(echo $(apt-cache showsrc kf5-kdepim-apps-libs | grep Binary | sed s/Binary:// | sed s/,//g) | sort --unique) dh-acc exuberant-ctags | grep '++8' signature.asc Description: OpenPGP digital signature
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 a "Provides" of some sort. What I >> want to know (and I will spend some time on it) is what in the >> dependency chain makes us end up with this as an option. > > I was not able to figure out in the time I spend on it why apt-get ended > up with installing those packages. Does anybody know the right commands > and their arguments to figure out this specific question? > > Paul > PS: the last line that I used was: > apt-cache dotty $(echo $(apt-cache showsrc kf5-kdepim-apps-libs | grep > Binary | sed s/Binary:// | sed s/,//g) | sort --unique) dh-acc > exuberant-ctags | grep '++8' I went ahead and let glibc and abi-compliance-checker migrate to testing. I ran reference runs of the failing tests today to check if everything is all-right, and it is. So this is a versioned Depends/Breaks/Conflicts issue somewhere. I am very uncomfortable about this, because today qtbase-opensource-src started to be hit by the same issue. Paul @ qtbase-opensource-src maintainers, this conversation starts here: https://lists.debian.org/debian-ci/2018/09/msg00010.html signature.asc Description: OpenPGP digital signature
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 when that autopkgtest is run with the binary packages of glibc
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
glibcfrom testing2.28-1
r-cran-rgenoud from testing5.8-2.0-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is contributing to the delay of the migration
of glibc to testing [1]. Of course, glibc shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in glibc was intended and your package needs to update to the new
situation. If needed, please change the bug's severity.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from glibc should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
glibc/2.28-1. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=glibc
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-rgenoud/1418394/log.gz
> test_check("rgenoud")
Loading required package: rgenoud
## rgenoud (Version 5.8-2.0, Build Date: 2018-04-03)
## See http://sekhon.berkeley.edu/rgenoud for additional documentation.
## Please cite software as:
## Walter Mebane, Jr. and Jasjeet S. Sekhon. 2011.
## ``Genetic Optimization Using Derivatives: The rgenoud package for R.''
## Journal of Statistical Software, 42(11): 1-26.
##
-- 1. Failure: Tests the new version of genoud() where the seeds are not
given (
biclaw1$value not equal to 1.65353.
1/1 mismatches
[1] 1.67 - 1.65 == 0.0176
-- 2. Failure: Tests the new version of genoud() where the seeds are not
given (
biclaw1$par not equal to c(-0.5001947, -0.5001947).
2/2 mismatches (average diff: 0.5)
[1] -1 - -0.5 == -0.5
[2] -1 - -0.5 == -0.5
-- 3. Failure: Tests the new version of genoud() where the seeds are not
given (
biclaw1$gradients not equal to c(-1.526799e-06, -8.571643e-07).
1/2 mismatches
[1] -3e-09 - -1.53e-06 == 1.52e-06
== testthat results
===
OK: 22 SKIPPED: 0 FAILED: 3
1. Failure: Tests the new version of genoud() where the seeds are not
given (@test-genoud_no_given_seed.R#84)
2. Failure: Tests the new version of genoud() where the seeds are not
given (@test-genoud_no_given_seed.R#85)
3. Failure: Tests the new version of genoud() where the seeds are not
given (@test-genoud_no_given_seed.R#86)
Error: testthat unit tests failed
Execution halted
autopkgtest [04:54:09]: test run-unit-test: ---]
signature.asc
Description: OpenPGP digital signature
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 uninstallability in unstable, thus, > having a lot of temporary regressions, in order to have a "smoother" testing. > > At the same time, the autopkgtest run (mostly) upstream's unittests (mostly > the ones that can't be run as part of the build). But, sadly, upstream > doesn't > enforce running their unittests as part of their development nor release > process, so, some regressions in part of their unittests is "normal". This > fits "nicely" with the current way Debian delays the transitions to testing, > which gives enough time to unstable users to report real regressions in > behaviour. > > All of this is to explain that, currently, a report about autopkgtest issues > is not really useful to us, and would be time better spent reporting them > directly upstream (if it applies). Furthermore, once the autopkgtest are used > to block the migration to testing completely, we would be forced to to simply > drop most of the tests (as long as upstream doesn't change their policy > regarding unittest). > > This can be considered as a documentation of the current state of affairs > regarding kde frameworks and kde plasma. No response needed. However, currently regressions due to glibc in kio, kdelibs4support, khtml and kparts are blocking the migration of glibc to testing. Should we be ignoring those regressions as well? If that is the case, can you please already start removing the tests, as they also hamper other packages, or maybe you want to mark them as "flaky" [1]. All four fail on the abi-compliance test. Paul [1] https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst signature.asc Description: OpenPGP digital signature
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 / 4.18.20-2cross2 > > glibc: 2.28-4 / 2.28-2cross2 > > > > old linux version: 4.18.20-2 / 2 > > old glibc version: 2.28-2 / 2 > > > > new linux version: 4.19.12-1cross1 > > new glibc version: 2.28-4cross1 > > START stamp-dir/init-glibc > > rm -rf glibc-2.28 > > tar -x -f /usr/src/glibc/glibc-2.28.tar.xz > > cp -a /usr/src/glibc/debian/ glibc-2.28 > > cd glibc-2.28 ; \ > > QUILT_PATCHES=/<>/debian/patches/glibc/debian quilt --quiltrc > > /dev/null push -a && \ > > rm -rf .pc/ > > Applying patch dpkg-shlibs.patch > > patching file debian/rules.d/debhelper.mk > > > > Applying patch local-kill-locales.patch > > patching file debian/rules > > patching file localedata/SUPPORTED > > > > Applying patch glibc-build-tools.diff > > patching file debian/rules > > > > Applying patch gcc-8-armel.diff > > patching file debian/sysdeps/armel.mk > > Hunk #1 FAILED at 1. > > 1 out of 1 hunk FAILED -- rejects in file debian/sysdeps/armel.mk > > Patch gcc-8-armel.diff does not apply (enforce with -f) > > make: *** [debian/rules:436: stamp-dir/init-glibc] Error 1 I hope you are aware that the same issue is currently blocking the latest version of glibc from migrating to testing as the autopkgtest of cross-toolchain-base fails on the same error: https://ci.debian.net/data/autopkgtest/testing/amd64/c/cross-toolchain-base/1663556/log.gz autopkgtest [05:36:03]: test build: [--- Testing cross builds on amd64 ... + CROSS_ARCHS=ppc64el DEB_BUILD_OPTIONS=parallel=2 dpkg-buildpackage -d -b --no-sign dpkg-buildpackage: info: source package cross-toolchain-base dpkg-buildpackage: info: source version 30 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Matthias Klose dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean linux: 4.19.12-1 / 4.18.20-2cross2 glibc: 2.28-4 / 2.28-2cross2 old linux version: 4.18.20-2 / 2 old glibc version: 2.28-2 / 2 new linux version: 4.19.12-1cross1 new glibc version: 2.28-4cross1 rm -rf linux-source-* rm -rf glibc-* rm -rf gcc rm -rf binutils-* rm -rf debian/tmp.ppc64el rm -f debian/files debian/no-packages rm -f debian/cross-compile find debian -name '*~' | xargs -r rm -f rm -f *.*deb *.changes *.buildinfo rm -rf repackfiles tmp tmp-* debian/tmp.* rm -rf stamp-dir/ mkdir stamp-dir/ dh_clean debian/rules build linux: 4.19.12-1 / 4.18.20-2cross2 glibc: 2.28-4 / 2.28-2cross2 old linux version: 4.18.20-2 / 2 old glibc version: 2.28-2 / 2 new linux version: 4.19.12-1cross1 new glibc version: 2.28-4cross1 START stamp-dir/init-glibc rm -rf glibc-2.28 tar -x -f /usr/src/glibc/glibc-2.28.tar.xz cp -a /usr/src/glibc/debian/ glibc-2.28 cd glibc-2.28 ; \ QUILT_PATCHES=/tmp/autopkgtest-lxc.3kye5ugg/downtmp/build.o4e/src/debian/patches/glibc/debian quilt --quiltrc /dev/null push -a && \ rm -rf .pc/ Applying patch dpkg-shlibs.patch patching file debian/rules.d/debhelper.mk Applying patch local-kill-locales.patch patching file debian/rules patching file localedata/SUPPORTED Applying patch glibc-build-tools.diff patching file debian/rules Applying patch gcc-8-armel.diff patching file debian/sysdeps/armel.mk Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- rejects in file debian/sysdeps/armel.mk Patch gcc-8-armel.diff does not apply (enforce with -f) make: *** [debian/rules:436: stamp-dir/init-glibc] Error 1 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 autopkgtest [05:36:10]: test build: ---] Paul signature.asc Description: OpenPGP digital signature
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 is clear what needs to be done. Paul
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 keyboard-configuration_1.188_all.deb | > tar xO- ./config | grep "en_GB\*model\*sun_type6_jp" > en_GB*model*sun_type6_jp*Sun Type 6 (Japonesa) > en_GB*model*sun_type6_jp_usb*Sun Type 6 USB (Japonesa) > > That should be "(Japanese)". Very many other entries are also affected. > I've provided a patch on the referenced salsa URL. This apparently wasn't uploaded, so it's to late for the initial buster release. Does it make any sense to mention this in the release notes? I tend to say it doesn't, but will do it nevertheless when others think it does. Paul signature.asc Description: OpenPGP digital signature
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 effected? > There is nothing a binary-all python module can do to fix > architecture-specific toolchain bugs. Ack. > Is there a non-manual way to express that the autopkgtest must not run > on arm64 and powerpc64el? There is currently not even a manual way except for marking the test as skippable and exitting with error code 77 on unsupported architectures. Mind you, I don't think toolchain issues should be marked at the package level (but maybe you didn't mean that). 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 failures ignored until the toolchain issues are fixed. Paul signature.asc Description: OpenPGP digital signature
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 failures ignored until the >> toolchain issues are fixed. > > A failing arm64 or ppc64el autopkgtest log containing the string > "libgomp.so.1: cannot allocate memory in static TLS block" > is this bug. On ci.d.n I checked for all tests on arm64 the most recent log. The only autopkgtest with the string "/lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate memory in static TLS block" in the logs is vtkplotter. I'm running another check on "cannot allocate memory in static TLS block" now, will take a while. Paul signature.asc Description: OpenPGP digital signature
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
Hi, [Note, this e-mail may look familiar as it is mostly copied over from the buster call, not much has changed, AFAICT]. As part of the interim architecture qualification for bullseye, we request that DSA, the security team, Wanna build, and the toolchain maintainers review and update their list of known concerns for bullseye release architectures. Summary of the current concerns and issues: * DSA have announced a blocking issue for armel and armhf (see below) * Concerns from DSA about ppc64el and s390x have been carried over from (stretch and) buster. * Concerns from the GCC maintainers about i386, armel, armhf, mips64el and mipsel have been carried over from (stretch and) buster. If the issues and concerns from you or your team are not up to date, then please follow up to this email (keeping debian-release@l.d.o in CC to ensure we are notified). Whilst porters remain ultimately responsible for ensuring the architectures are ready for release, we do expect that you / your team are willing to assist with clarifications of the concerns and to apply patches/changes in a timely manner to resolve the concerns. List of blocking issues by architecture === The following is a summary from the current architecture qualification table. armel/armhf: * Undesirable to keep the hardware running beyond 2020. armhf VM support uncertain. (DSA) - Source: [DSA Sprint report] - I was under the impression that this issue has been resolved (at least for armhf) by now, but we like a fresh statement on this. [DSA Sprint report]: https://lists.debian.org/debian-project/2018/02/msg4.html List of concerns for architectures == The following is a summary from the current architecture qualification table. * Concern for ppc64el and s390x: we are dependent on sponsors for hardware. (Raised by DSA; carried over from stretch and buster) * Concern for armel and armhf: only secondary upstream support in GCC (Raised by the GCC maintainer; carried over from stretch and buster) * Concern for mips, mips64el, mipsel and ppc64el: no upstream support in GCC; Debian carries patches in binutils and GCC that haven't been integrated upstream even after a long time. (Raised by the GCC maintainer; carried over from stretch and buster) Architecture status === These are the architectures currently being built for bullseye: * Intel/AMD-based: amd64, i386 * ARM-based: arm64, armel, armhf * MIPS-based: mipsel, mips64el * Other: ppc64el, s390x If the blocking issues cannot be resolved, affected architectures are at risk of removal 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 autopkgtest of node-iconv fails in
testing on all architectures when that autopkgtest is run with the
binary packages of glibc from unstable. It passes when run with only
packages from testing. In tabular form:
passfail
glibc from testing2.31-5
node-iconv from testing2.3.5-4
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of glibc to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=glibc
https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-iconv/8618841/log.gz
autopkgtest [07:11:24]: test pkg-js-autopkgtest:
/usr/share/pkg-js-autopkgtest/runner
autopkgtest [07:11:24]: test pkg-js-autopkgtest: [---
# Using package.json
# Node module name is iconv
# Build files found:
# Test files found: test
# Files/dir to be installed from source: test
# Copy test files
# Copy debian/tests/pkg-js content
'debian/tests/pkg-js' ->
'/tmp/autopkgtest-lxc.djwhve30/downtmp/autopkgtest_tmp/smokeZDEmls/debian/tests/pkg-js'
'debian/tests/pkg-js/test' ->
'/tmp/autopkgtest-lxc.djwhve30/downtmp/autopkgtest_tmp/smokeZDEmls/debian/tests/pkg-js/test'
# Searching module in /usr/lib/nodejs/iconv
# Searching module in /usr/lib/aarch64-linux-gnu/nodejs/iconv
# Found /usr/lib/aarch64-linux-gnu/nodejs/iconv
# Searching files to link in /usr/lib/aarch64-linux-gnu/nodejs/iconv
'./build' -> '/usr/lib/aarch64-linux-gnu/nodejs/iconv/build'
'./lib' -> '/usr/lib/aarch64-linux-gnu/nodejs/iconv/lib'
'./package.json' -> '/usr/lib/aarch64-linux-gnu/nodejs/iconv/package.json'
# Searching module in /usr/share/nodejs/iconv
# Launch debian/tests/pkg-js/test with sh -ex
+ mkdir -p test/tmp
+ node test/run-tests.js
assert.js:101
throw new AssertionError(obj);
^
AssertionError [ERR_ASSERTION]: Missing expected exception.
at Object.
(/tmp/autopkgtest-lxc.djwhve30/downtmp/autopkgtest_tmp/smokeZDEmls/test/test-basic.js:136:8)
at Module._compile (internal/modules/cjs/loader.js:1015:30)
at Object.Module._extensions..js
(internal/modules/cjs/loader.js:1035:10)
at Module.load (internal/modules/cjs/loader.js:879:32)
at Function.Module._load (internal/modules/cjs/loader.js:724:14)
at Module.require (internal/modules/cjs/loader.js:903:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object.
(/tmp/autopkgtest-lxc.djwhve30/downtmp/autopkgtest_tmp/smokeZDEmls/test/run-tests.js:2:1)
at Module._compile (internal/modules/cjs/loader.js:1015:30)
at Object.Module._extensions..js
(internal/modules/cjs/loader.js:1035:10) {
generatedMessage: false,
code: 'ERR_ASSERTION',
actual: undefined,
expected: undefined,
operator: 'throws'
}
autopkgtest [07:11:25]: test pkg-js-autopkgtest: ---]
OpenPGP_signature
Description: OpenPGP digital signature
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 autopkgtest of libpod fails in testing when that autopkgtest is run with the binary packages of glibc from unstable. It passes when run with only packages from testing. In tabular form: passfail glibc from testing2.31-5 libpod from testing2.0.6+dfsg1-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of glibc to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=glibc https://ci.debian.net/data/autopkgtest/testing/amd64/libp/libpod/8618093/log.gz cd _output && go install -trimpath -v -p 2 -tags "apparmor ostree seccomp selinux systemd varlink" -ldflags "-X main.buildInfo=2.0.6+dfsg1-2" github.com/containers/libpod/cmd/podman github.com/containers/libpod/cmd/podman/common github.com/containers/libpod/cmd/podman/containers github.com/containers/libpod/cmd/podman/generate github.com/containers/libpod/cmd/podman/healthcheck github.com/containers/libpod/cmd/podman/images github.com/containers/libpod/cmd/podman/inspect github.com/containers/libpod/cmd/podman/manifest github.com/containers/libpod/cmd/podman/networks github.com/containers/libpod/cmd/podman/parse github.com/containers/libpod/cmd/podman/play github.com/containers/libpod/cmd/podman/pods github.com/containers/libpod/cmd/podman/registry github.com/containers/libpod/cmd/podman/report github.com/containers/libpod/cmd/podman/system github.com/containers/libpod/cmd/podman/system/connection github.com/containers/libpod/cmd/podman/utils github.com/containers/libpod/cmd/podman/validate github.com/containers/libpod/cmd/podman/volumes github.com/containers/libpod/docs github.com/containers/libpod/docs/varlink github.com/containers/libpod/hack/podman-registry-go github.com/containers/libpod/libpod github.com/containers/libpod/libpod/common github.com/containers/libpod/libpod/define github.com/containers/libpod/libpod/driver github.com/containers/libpod/libpod/events github.com/containers/libpod/libpod/filters github.com/containers/libpod/libpod/image github.com/containers/libpod/libpod/layers github.com/containers/libpod/libpod/linkmode github.com/containers/libpod/libpod/lock github.com/containers/libpod/libpod/lock/file github.com/containers/libpod/libpod/lock/shm github.com/containers/libpod/libpod/logs github.com/containers/libpod/libpod/logs/reversereader github.com/containers/libpod/pkg/annotations github.com/containers/libpod/pkg/api/handlers github.com/containers/libpod/pkg/api/handlers/compat github.com/containers/libpod/pkg/api/handlers/libpod github.com/containers/libpod/pkg/api/handlers/swagger github.com/containers/libpod/pkg/api/handlers/utils github.com/containers/libpod/pkg/api/server github.com/containers/libpod/pkg/api/server/idletracker github.com/containers/libpod/pkg/api/types github.com/containers/libpod/pkg/auth github.com/containers/libpod/pkg/autoupdate github.com/containers/libpod/pkg/bindings github.com/containers/libpod/pkg/bindings/containers github.com/containers/libpod/pkg/bindings/generate github.com/containers/libpod/pkg/bindings/images github.com/containers/libpod/pkg/bindings/manifests github.com/containers/libpod/pkg/bindings/network github.com/containers/libpod/pkg/bindings/play github.com/containers/libpod/pkg/bindings/pods github.com/containers/libpod/pkg/bindings/system github.com/containers/libpod/pkg/bindings/volumes github.com/containers/libpod/pkg/cgroups github.com/containers/libpod/pkg/channelwriter github.com/containers/libpod/pkg/checkpoint github.com/containers/libpod/pkg/criu github.com/containers/libpod/pkg/ctime github.com/containers/libpod/pkg/domain/entities github.com/containers/libpod/pkg/domain/filters github.com/containers/libpod/pkg/domain/infra github.com/containers/libpod/pkg/domain/infra/abi github.com/containers/libpod/pkg/domain/infra/abi/parse github.com/containers/libpod/pkg/domain/infra/abi/terminal github.com/containers/libpod/pkg/domain/infra/tunnel github.com/containers/libpod/pkg/domain/utils github.com/containers/libpod/pkg/env github.com/containers/libpod/pkg/errorhandling github.com/containers/libpod/pkg/hooks github.com/containers/libpod/pkg/hooks/0.1.0 github.com/containers/libpod/pkg/hooks/1.0.0 github.com/containers/libpod/pkg/hooks/exec github.com/containers/libpod/pkg/inspect github.com
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 check based on libcrypt1 > > > > reverse > > > > dependencies in sid shows perl-base, login and util-linux. I'm > > > > not sure > > > > if this list is exhaustive, though. > > Having libc6 Conflict with one of those packages should be enough, > right? Shouldn't this bug be reassigned to libc6? Paul OpenPGP_signature Description: OpenPGP digital signature
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 libcrypt1:amd64) > > Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ... > > De-configuring libc6:amd64 (2.28-10) ... > > Unpacking libcrypt1:amd64 (1:4.4.17-1) ... > > Errors were encountered while processing: > > /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb > > Error: Timeout was reached > > E: Sub-process /usr/bin/dpkg returned an error code (1) Could this be the same problem as in bug #974552? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974552 Paul OpenPGP_signature Description: OpenPGP digital signature
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 fails regularly on lately. Unfortunately, the log of glibc is so long that it gets truncated on the ci.d.n infrastructure, so I can't copy any useful log. 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. Please get in touch if you need a full log, I can try to generate one. Paul https://ci.debian.net/packages/g/glibc/testing/amd64/ https://ci.debian.net/packages/g/glibc/testing/arm64/ https://ci.debian.net/packages/g/glibc/testing/armhf/ https://ci.debian.net/packages/g/glibc/testing/i386/ OpenPGP_signature Description: OpenPGP digital signature
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 wondering if this flakyness comes from activities in parallel runs. I'll try again tomorrow. Paul OpenPGP_signature Description: OpenPGP digital signature
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 after reading the discussion in these bugs. Can we have an upload soon to have exposure? Paul OpenPGP_signature Description: OpenPGP digital signature
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 fails. > > Please find attached a full log of a failure. > > Please let me know if I need to try to get more info. Did you see this reply? Did it help? Paul OpenPGP_signature Description: OpenPGP digital signature
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: OpenPGP digital signature
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 kernel (at least in the case of this build log). That's correct, all workers run stable except s390x. > Could it be that kernel.unprivileged_userns_clone is enabled on some of > the runners? It doesn't seem to be the case of all the runners as the > autopkgtest ran successfully for the latest glibc upload. paul@mulciber ~/debian-maint/ci.d.n-config $ rake -j40 run:workers # Enter command to run (use arrow keys for history): $ cat /proc/sys/kernel/unprivileged_userns_clone [] ci-worker-armhf-01: 0 ci-worker13: 1 ci-worker-s390x-01: 1 ci-worker12: 0 ci-worker11: 0 ci-worker03: 0 ci-worker05: 0 ci-worker-i386-04: 1 ci-worker-i386-01: 1 ci-worker-i386-03: 1 ci-worker06: 0 ci-worker01: 1 ci-worker09: 0 ci-worker07: 0 ci-worker-i386-02: 0 ci-worker02: 0 ci-worker10: 0 ci-worker-ppc64el-02: 0 ci-worker-ppc64el-04: 0 ci-worker04: 0 ci-worker08: 0 ci-worker-arm64-04: 0 ci-worker-ppc64el-03: 0 ci-worker-arm64-07: 1 ci-worker-arm64-02: 0 ci-worker-arm64-05: 0 ci-worker-arm64-06: 0 ci-worker-arm64-03: 0 ci-worker-arm64-11: 0 ci-worker-arm64-08: 0 ci-worker-arm64-09: 1 ci-worker-arm64-10: 0 ci-worker-ppc64el-01: 0 [Note: some ci-workerXX are i386 workers, most are amd64]. > In anycase as it is reproducible with the bullseye kernel, this > definitely needs a fix. Thanks for working on this. If I want to make our workers equal, I guess changing them all to the default sounds sane, right? Do you know if the default is different for buster and bullseye? If so, does it make sense to already go with the bullseye default? Paul OpenPGP_signature Description: OpenPGP digital signature
