Bug#999465: tzdata: asks debconf question tzdata/Areas twice
Package: tzdata Version: 2021e-1 Severity: normal Hi, when (manually) installing tzdata in my minimal pbuilder chroots, the debconf question tzdata/Areas gets asked twice: once in the pre-configuration step, once during package configuration: # apt-get install tzdata Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: tzdata 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/291 kB of archives. After this operation, 3431 kB of additional disk space will be used. debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78, <> line 1.) debconf: falling back to frontend: Readline Preconfiguring packages ... Configuring tzdata -- Please select the geographic area in which you live. Subsequent configuration questions will narrow this down by presenting a list of cities, representing the time zones in which they are located. 1. Africa 2. America 3. Antarctica 4. Australia 5. Arctic 6. Asia 7. Atlantic 8. Europe 9. Indian 10. Pacific 11. US 12. Etc Geographic area: 8 Please select the city or region corresponding to your time zone. 1. Amsterdam 5. Belfast 9. Brussels13. Chisinau17. Guernsey 21. Jersey 25. Lisbon 29. Madrid 33. Monaco 37. Paris 41. Rome45. Saratov 49. Stockholm 53. Ulyanovsk 57. Vienna 61. Zagreb 2. Andorra6. Belgrade10. Bucharest 14. Copenhagen 18. Helsinki 22. Kaliningrad 26. Ljubljana 30. Malta 34. Moscow 38. Podgorica 42. Samara 46. Simferopol 50. Tallinn54. Uzhgorod 58. Vilnius62. Zaporozhye 3. Astrakhan 7. Berlin 11. Budapest 15. Dublin 19. Isle_of_Man 23. Kiev 27. London 31. Mariehamn 35. Nicosia 39. Prague 43. San_Marino 47. Skopje 51. Tirane 55. Vaduz 59. Volgograd 63. Zurich 4. Athens 8. Bratislava 12. Busingen 16. Gibraltar 20. Istanbul 24. Kirov28. Luxembourg 32. Minsk 36. Oslo 40. Riga 44. Sarajevo48. Sofia 52. Tiraspol 56. Vatican60. Warsaw Time zone: 7 Selecting previously unselected package tzdata. (Reading database ... 14597 files and directories currently installed.) Preparing to unpack .../tzdata_2021e-1_all.deb ... Unpacking tzdata (2021e-1) ... Setting up tzdata (2021e-1) ... debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78.) debconf: falling back to frontend: Readline Configuring tzdata -- Please select the geographic area in which you live. Subsequent configuration questions will narrow this down by presenting a list of cities, representing the time zones in which they are located. 1. Africa 2. America 3. Antarctica 4. Australia 5. Arctic 6. Asia 7. Atlantic 8. Europe 9. Indian 10. Pacific 11. US 12. Etc Geographic area: 8 Current default time zone: 'Europe/Berlin' Local time is now: Thu Nov 11 13:40:48 CET 2021. Universal Time is now: Thu Nov 11 12:40:48 UTC 2021. Run 'dpkg-reconfigure tzdata' if you wish to change it. The minimal chroot has a pre-existing /etc/timezone containing Etc/UTC, but even if I delete that before installing tzdata that question is repeated. There are no pre-existing "*tzdata*" entries in the debconf database. Andreas PS: tzdata gets usually installed as a dependency when manually entering the pbuilder environment and doing apt-get build-dep $pkg to do some interactive build testing ...
Bug#993075: libnsl-dev: rpcsvc/nis.h includes no longer available rpc/rpc.h
Package: libnsl-dev Version: 1.3.0-2 Severity: serious Tags: sid bookworm Control: affects -1 + src:sendmail rpcsvc/nis.h wants to include rpc/rpc.h, but that header is no longer provided by libc6-dev in sid: $ echo '#include ' | gcc -x c -c - In file included from :1: /usr/include/rpcsvc/nis.h:35:10: fatal error: rpc/rpc.h: No such file or directory 35 | #include | ^~~ compilation terminated. Andreas
Bug#983910: rpcsvc-proto: uninstallable due to Conflicts: libc6
Followup-For: Bug #983910 Control: found -1 1.4.2-2 > * Replace the conflicts with libc6-dev by breaks + replaces on libc6-dev > (<< 2.31-13). Closes: #983910. That is not sufficient: Selecting previously unselected package rpcsvc-proto. Preparing to unpack .../rpcsvc-proto_1.4.2-2_amd64.deb ... Unpacking rpcsvc-proto (1.4.2-2) ... dpkg: error processing archive /var/cache/apt/archives/rpcsvc-proto_1.4.2-2_amd64.deb (--unpack): trying to overwrite '/usr/bin/rpcgen', which is also in package libc-dev-bin 2.31-13 Errors were encountered while processing: /var/cache/apt/archives/rpcsvc-proto_1.4.2-2_amd64.deb Andreas
Bug#983910: rpcsvc-proto: uninstallable due to Conflicts: libc6
On 03/03/2021 10.33, Aurelien Jarno wrote: See the changelog. This is done on purpose until we can actually schedule the transition. I just needed a bug number to automatically flag the uninstallable package in piuparts ;-) Andreas
Bug#983910: rpcsvc-proto: uninstallable due to Conflicts: libc6
Package: rpcsvc-proto Version: 1.4.2-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Package: rpcsvc-proto Version: 1.4.2-1 Architecture: amd64 Depends: libc6 (>= 2.14) Conflicts: libc6 That does not work. Andreas
Bug#982443: libc6: Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!
Package: libc6 Version: 2.31-9 Severity: important Control: block 981899 with -1 One of the adequate autopkg tests now triggers an assertion in libc6, which is a regression from buster. I've extracted that test to build the attached self-contained reproducer. sid$ make mkdir -p tmp # missing-version-information cc -shared -Wl,--soname=libadequate-test-versionless.so.0 -Wl,--version-script=verscript-global lib.c -o tmp/libadequate-test-versionless.so.0 ln -sf libadequate-test-versionless.so.0 tmp/libadequate-test-versionless.so cc undef.c -Ltmp -o tmp/adequate-test-msvi -ladequate-test-versionless cc -shared -Wl,--soname=libadequate-test-versionless.so.0 lib.c -o tmp/libadequate-test-versionless.so.0 LD_LIBRARY_PATH=tmp ldd -r tmp/adequate-test-msvi tmp/adequate-test-msvi: tmp/libadequate-test-versionless.so.0: no version information available (required by tmp/adequate-test-msvi) linux-vdso.so.1 (0x7ffd73deb000) libadequate-test-versionless.so.0 => tmp/libadequate-test-versionless.so.0 (0x7f6c563b1000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f6c561e8000) /lib64/ld-linux-x86-64.so.2 (0x7f6c563bd000) Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed! make: *** [Makefile:13: all] Error 1 The test builds a binary that is linked against a shared library with versioned symbols, but at runtime only a library with unversioned symbols is available. adequate then looks for the "no version information available" output, but nevertheless expects ldd to not fail. buster$ make mkdir -p tmp # missing-version-information cc -shared -Wl,--soname=libadequate-test-versionless.so.0 -Wl,--version-script=verscript-global lib.c -o tmp/libadequate-test-versionless.so.0 ln -sf libadequate-test-versionless.so.0 tmp/libadequate-test-versionless.so cc undef.c -Ltmp -o tmp/adequate-test-msvi -ladequate-test-versionless cc -shared -Wl,--soname=libadequate-test-versionless.so.0 lib.c -o tmp/libadequate-test-versionless.so.0 LD_LIBRARY_PATH=tmp ldd -r tmp/adequate-test-msvi tmp/adequate-test-msvi: tmp/libadequate-test-versionless.so.0: no version information available (required by tmp/adequate-test-msvi) linux-vdso.so.1 (0x7ffdd352) libadequate-test-versionless.so.0 => tmp/libadequate-test-versionless.so.0 (0x7f32e0977000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f32e07b2000) /lib64/ld-linux-x86-64.so.2 (0x7f32e0983000) buster$ echo $? 0 Andreas libc6assertion.tar.gz Description: Unix tar archive
Bug#965932: libc6: breaks openssh-server/buster
Package: libc6 Version: 2.31-1 Severity: critical Justification: breaks unrelated software; breaks remote access TL;DR: sshd privsep child dies with SIGSYS in clock_nanosleep() (libc6 2.31-1) while it succeeded using nanosleep() under libc6 2.30-8 The machine in question is running buster with some selected packages (mainly compilers and development stuff) from bullseye (and is located at a remote location). The running kernel is 4.19.0-9-amd64 4.19.118-2. openssh-server 1:7.9p1-10+deb10u2 is running. After upgrading libc6 from 2.30-8 to 2.31-1 (which caused sshd to restart), sshd was running, but dropped incoming connections during authentication. Luckily I still had a terminal open and could downgrade again to 2.30-8 which restored accessibility. Thanks to the people trying to guess usernames and passwords, I noticed this difference in /var/log/auth.log: with 2.31-1: Jul 20 21:52:11 hostname sshd[25603]: Invalid user ping from 139.219.0.102 port 39588 Jul 20 21:52:11 hostname sshd[25603]: pam_unix(sshd:auth): check pass; user unknown Jul 20 21:52:11 hostname sshd[25603]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=139.219.0.102 Jul 20 21:52:13 hostname sshd[25603]: Failed password for invalid user ping from 139.219.0.102 port 39588 ssh2 after downgrading to 2.30-8: Jul 20 21:54:33 hostname sshd[26824]: Invalid user mickey from 51.83.131.123 port 32822 Jul 20 21:54:33 hostname sshd[26824]: pam_unix(sshd:auth): check pass; user unknown Jul 20 21:54:33 hostname sshd[26824]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=51.83.131.123 Jul 20 21:54:35 hostname sshd[26824]: Failed password for invalid user mickey from 51.83.131.123 port 32822 ssh2 Jul 20 21:54:35 hostname sshd[26824]: Received disconnect from 51.83.131.123 port 32822:11: Bye Bye [preauth] Jul 20 21:54:35 hostname sshd[26824]: Disconnected from invalid user mickey 51.83.131.123 port 32822 [preauth] I can reproduce this by running sshd in a mininmal buster chroot and upgrading libc6 (+ libgcc-s1 libcrypto1 libc-bin). (There is even no need to restart sshd (which was started under 2.31-1) after downgrading libc6 again to 2.30-8 to get it functional again.) I haven't tried sshd/bullseye. I haven't tried booting with 2.31-1. $ ssh -vvv foo@localhost -p 9922 [...] debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 31 debug1: Server host key: ecdsa-sha2-nistp256 SHA256:/07awyZSdCd9QgaTWi1dn3kEg9rbZtYC+ejHd6ZFi2w debug3: put_host_port: [127.0.0.1]:9922 debug3: put_host_port: [localhost]:9922 debug3: hostkeys_foreach: reading file "/home/beckmann/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /home/beckmann/.ssh/known_hosts:4 debug3: load_hostkeys: loaded 1 keys from [localhost]:9922 debug1: Host '[localhost]:9922' is known and matches the ECDSA host key. debug1: Found key in /home/beckmann/.ssh/known_hosts:4 debug3: send packet: type 21 debug2: set_newkeys: mode 1 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug1: SSH2_MSG_NEWKEYS received debug2: set_newkeys: mode 0 debug1: rekey after 134217728 blocks debug1: Will attempt key: /home/beckmann/.ssh/id_dsa debug1: Will attempt key: /home/beckmann/.ssh/id_ecdsa debug1: Will attempt key: /home/beckmann/.ssh/id_ed25519 debug1: Will attempt key: /home/beckmann/.ssh/id_xmss debug2: pubkey_prepare: done debug3: send packet: type 5 debug3: receive packet: type 7 debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs= debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 Connection closed by 127.0.0.1 port 9922 # /usr/sbin/sshd -ddd debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 328 debug2: parse_server_config: config /etc/ssh/sshd_config len 328 debug3: /etc/ssh/sshd_config:13 setting Port 9922 debug3: /etc/ssh/sshd_config:26 setting SyslogFacility LOCAL7 debug3: /etc/ssh/sshd_config:27 setting LogLevel DEBUG3 debug3: /etc/ssh/sshd_config:56 setting PasswordAuthentication yes debug3: /etc/ssh/sshd_config:61 setting ChallengeResponseAuthentication no debug3: /etc/ssh/sshd_config:84 setting UsePAM yes debug3: /etc/ssh/sshd_config:89 setting X11Forwarding yes debug3: /etc/ssh/sshd_config:93 setting PrintMotd no debug3: /etc/ssh/sshd_config:111 setting AcceptEnv LANG LC_* debug3: /etc/ssh/sshd_config:114 setting Subsystem sftp /usr/lib/openssh/sftp-server debug1: sshd version OpenSSH_7.9, OpenSSL 1.1.1d 10 Sep 2019 debug1: private host key #0: ssh-rsa SHA256:Ny3efyKdYNkwzXduBRO9Fzl0k2K505paO5QFGGw0o1s debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:/07awyZSdCd9QgaTWi1dn3kEg9rbZtYC+ejHd6ZFi2w debug1: private host key #2: ssh-ed25519 SHA256:COeHE8usWY7gfl1+F5DqGx8pptr/4duLPiaPai3J5uo debug1:
Bug#965109: libc6: 'semop(1): encountered an error: Function not implemented' in fakeroot under qemu
Package: libc6 Version: 2.31-1 Severity: important Hi, I just noticed some packages recently started failing to build with pbuilder in qemu (qemu-user-static) foreign arch chroots (on amd64 host) with this error: dpkg-buildpackage: info: source package xtrs dpkg-buildpackage: info: source version 4.9d-2 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by G. Branden Robinson dpkg-source --before-build . dpkg-buildpackage: info: host architecture armhf fakeroot debian/rules clean semop(1): encountered an error: Function not implemented dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 1 I believe that is caused by the the ongoing glibc 2.31 transition, since that seems to be the component that has recently changed in the sid chroot. It may also have just exposed a latent bug in fakeroot/qemu. Andreas
Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
Package: libc6-x32,libc6-i386
Version: 2.28-8
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts in a --merged-usr environment I noticed that
installing, removing, and installing again a package shipping /lib32,
/libx32 will actually unmerge that directory.
The package will take ownership of the preexisting symlinks
/lib{32,x32} -> /usr/lib{32,x32} that were created by debootstrap,
remove them and create plain /usr/lib{32,x32} directories in the next
installation.
(/lib64 should be mostly safe due to /lib64/ld-linux-x86-64.so.2, but
perhaps on !x86 architectures)
The preinst scripts could check whether the package is being installed
in a --merged-usr environment and create (dangling) symlinks if
/usr/lib{32,x32} is missing. And postrm remove could recreate them if
they went missing.
Andreas
Bug#883705: Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Control: tag -1 unreproducible Control: close -1 On 2017-12-06 19:39, Julien Aubin wrote: > Weird... this time I re-upgraded libc6 and things work fine... looks like > something wrong went during the install. And I cannot reproduce the issue > anymore... :'( WTF ??? OK, I'm closing the two bugs as unreproducible. Andreas
Bug#882346: libc0.1-dev: fails to upgrade, trying to overwrite /usr/include/x86_64-kfreebsd-gnu/sys/random.h
Package: libc0.1-dev Version: 2.25-1 Severity: serious While trying to upgrade a sid chroot on falla.d.o: Preparing to unpack .../libc0.1-dev_2.25-1_kfreebsd-amd64.deb ... Unpacking libc0.1-dev:kfreebsd-amd64 (2.25-1) over (2.24-17) ... dpkg: error processing archive /var/cache/apt/archives/libc0.1-dev_2.25-1_kfreebsd-amd64.deb (--unpack): trying to overwrite '/usr/include/x86_64-kfreebsd-gnu/sys/random.h', which is also in package kfreebsd-kernel-headers 10.3~3 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Andreas
Bug#872201: libc-bin: sometimes throws std::logic_error while processing triggers
> terminate called after throwing an instance of 'std::logic_error' > what(): basic_string::_M_construct null not valid Could this be related to #871275 "libapt-pkg5.0: requires rebuild against GCC 7 and symbols/shlibs bump" which was fixed recently in apt? IIRC this started after making gcc-7 the default ... I'll look if there are new occurrences of this bug. Andreas
Bug#872201: libc-bin: sometimes throws std::logic_error while processing triggers
Control: severity -1 important On 2017-08-19 10:29, Aurelien Jarno wrote: > Any news about this? This bug now blocks the migration of glibc to > testing. Downgrading. Andreas
Bug#872201: libc-bin: sometimes throws std::logic_error while processing triggers
[ adding apt@, therefore quoting fully ] On 2017-08-15 22:56, Aurelien Jarno wrote: > control: tag - 1 + help > control: tag - 1 + moreinfo > > On 2017-08-15 09:58, Andreas Beckmann wrote: >> Package: libc-bin >> Version: 2.24-14 >> Severity: serious >> User: debian...@lists.debian.org >> Usertags: piuparts >> >> Hi, >> >> during several tests with piuparts in sid I noticed spurious and >> unreproducible errors while processing libc-bin triggers. >> Often apt-get just exits with an error code (but no error message >> at all) after processing the triggers. >> A few times I also get an error message about an uncaught exception. >> These failures usually go away after rerunning the test. >> >> >From the attached log (scroll to the bottom...): >> >> Processing triggers for libc-bin (2.24-14) ... >> terminate called after throwing an instance of 'std::logic_error' >> what(): basic_string::_M_construct null not valid > > What make you think it's an issue in libc-bin? The trigger processing > code just does: > > if [ "$1" = "triggered" ] || [ "$1" = "configure" ]; then > ldconfig || ldconfig --verbose > exit 0 > fi > > And there is no C++ code in ldconfig. Moreover even if ldconfig fails > the error is ignored and the install should not stop. OK, that probably leaves dpkg (no C++ either) and apt-get as the call chain to the trigger processing ... adding apt@ to the loop. #871275 could be a candidate, i.e. a g++7 rebuild might fix it. I reran the test where I attached the logfile yesterday repeatedly for 100 times with no failure. But I could probably dig out a dozen of similar failures from other piuparts tests. (These failures will be retried frequently, so will eventually succeed.) If there is some way to get more debug output for this problem, I could enable that globally in my piuparts instance. Andreas
Bug#872201: libc-bin: sometimes throws std::logic_error while processing triggers
Package: libc-bin Version: 2.24-14 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during several tests with piuparts in sid I noticed spurious and unreproducible errors while processing libc-bin triggers. Often apt-get just exits with an error code (but no error message at all) after processing the triggers. A few times I also get an error message about an uncaught exception. These failures usually go away after rerunning the test. >From the attached log (scroll to the bottom...): Processing triggers for libc-bin (2.24-14) ... terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_M_construct null not valid cheers, Andreas gcal-common_3.6.3-3.log.gz Description: application/gzip
Bug#864470: glibc-doc-reference: outdated version
Package: glibc-doc-reference Version: 2.19-1 Severity: important This package looks outdated compared to glibc 2.24-11 in stretch/sid. Andreas
Bug#861238: libc-bin: prompting due to modified conffiles which were not modified by the user: /etc/ld.so.conf
Package: libc-bin
Version: 2.19-18+deb8u7
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...
This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."
https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.
In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.
>From the attached log (scroll to the bottom...):
Setting up libc-bin (2.19-18+deb8u7) ...
Installing new version of config file /etc/bindresvport.blacklist ...
Installing new version of config file /etc/gai.conf ...
Configuration file `/etc/ld.so.conf'
==> File on system created by you or by a script.
==> File also in package provided by package maintainer.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** ld.so.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing libc-bin
(--configure):
EOF on stdin at conffile prompt
Errors were encountered while processing:
libc-bin
This was found on i386 with amd64-libs installed on the upgrade path
squeeze -> wheezy -> jessie -> stretch
while upgrading to jessie.
In my piuparts scripts I have the following exception for cleaning
this up before purge, but that doesn't apply in this case, since it
is not yet purge time:
# amd64-libs leaves a superfluous line there ...
sed -i '3{/^$/d}' /etc/ld.so.conf
amd64-libs wasn't seen any more after squeeze :-)
Maybe it is sufficient for libc-bin in jessie to
a) add Breaks: amd64-libs and
b) put the sed magic into the preinst
cheers,
Andreas
amd64-libs_None.log.gz
Description: application/gzip
Bug#854141: [Piuparts-devel] tzdata: purging tzdata leaves dangling /etc/localtime symlink
On 2017-03-22 17:02, Michael Biebl wrote: > Well, the log says that tzdata_2017a-1 was installed and tested. > Now I'm confused. Can you explain what piuparts is doing there? And piuparts expects the chroot after the test to be in the same state as before the test. But that chroot was created with the previous version of tzdata installed, which was purged in a further minimizing step, but left that dangling symlink ... and got stored to disk as the base chroot for further sid tests. But now this link suddenly disappeared after installing+purging the new version, making piuparts unhappy. Andreas
Bug#854141: [Piuparts-devel] tzdata: purging tzdata leaves dangling /etc/localtime symlink
Control: notfound -1 2017a-1 On 2017-03-22 16:46, Michael Biebl wrote: > That bug seems to be still unfixed in the latest version > > https://piuparts.debian.org/sid/fail/tzdata_2017a-1.log > > 0m17.0s ERROR: FAIL: After purging files have disappeared: > /etc/localtime -> /usr/share/zoneinfo/Etc/UTCnot owned Nope, that just means the chroot needs to be regenerated with the new tzdata (which is now in testing, too). But that should have happened inbetween, so rescheduling the tzdata test in sid (from March 13) should be sufficient. Andreas
Bug#854141: tzdata: purging tzdata leaves dangling /etc/localtime symlink
Package: tzdata Version: 2016j-2 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8 (or 10.8): https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. >From the attached log (scroll to the bottom...): 0m36.2s ERROR: FAIL: Package purging left files on system: /etc/localtime -> /usr/share/zoneinfo/Etc/UTC not owned (tested with a even more minimal chroot that does not have tzdata installed) cheers, Andreas tzdata_2016j-2.log.gz Description: application/gzip
Bug#800574: Bug#807244: libegl1-nvidia: Programs crash due to elisian-unlock on skylake processor with nvidia driver 352.63-1 (experimental)
Hi Aurelien, thanks for your analysis. On 2015-12-08 10:23, Aurelien Jarno wrote: > I disagree it is supposed to be fixed. Intel got a few bugs in there > TSX-NI implementation for Haswell and Broadwell and possibly early > versions of Skylake, and to avoid data loss we have therefore disabled > lock elision for some CPU revisions. That's what I meant with "fixed". But obviously there are two problems here: buggy hardware (blacklisted, #800574) and ... > That said the bugs in the Intel > implementation are corner cases, and it took quite some time for them to > get discovered. If your program crashes reproducibly, it's definitely not > an issue with the TSX-NI implementation. Disabling --enable-lock-elision > it's just a workaround for the real issue. People now start to have CPUs > with a working TSX-NI implementation which is therefore not blacklisted > and thus the problem is appearing again. ... buggy software (#807244), which is only exposed by running on hardware with working TSX-NI. That could also explain the fact that the bug was introduced in 352+. Jelle, I didn't dig through the nvidia forums, but if this info isn't mentioned there already, maybe you could post it: > According to the backtrace the problem is typical of a call to > mutex_unlock() on a mutex which hasn't been locked with mutex_lock() > before. (or was already unlocked.) Andreas
Bug#800574: Bug#807244: libegl1-nvidia: Programs crash due to elisian-unlock on skylake processor with nvidia driver 352.63-1 (experimental)
Dear libc maintainers, we recently got a bug report regarding the TSX-NI / lock elision bug in combination with the non-free nvidia driver (#807244). Since that is supposed to be fixed with the libc in experimental (and now sid as well), perhaps you could take a look why this still happens. Several forum posts denote that "compiling glibc without --enable-lock-elision" works around that issue. A few ideas from my side, but since I don't have the hardware to test, I cannot check anything: * that specific CPU needs to be blacklisted / is incorrectly whitelisted * nvidia utilizes a code path in libc that is not covered by the current patch (and that code path is not used by any other application) * nvidia does call something it shouldn't call directly ... thus circumenting the runtime-disabling of the specific routines in libc6 * nvidia code does issue the problematic instructions itself (but the backtrace points to libc, so this sounds unlikely) Is there some way to check at runtime how lock elision is handled by libc (on a concrete system)? Andreas On 2015-12-06 17:53, Jelle Haandrikman wrote: > On a system with an Nvidia GTX 970, Intel Skylake i5-6600k running driver > 352.63-1 (experimental) several programs crash due to TSX-NI / elision unlock. > This affects sddm, unlocking kscreen, vlc and deleting files using dolphin. > > Other people also have found this issue. > http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/nvidia-linux/825702-nvidia-s-latest-binary-driver-is-causing-problems-for-some-skylake-linux-users > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800574 #800574 > https://devtalk.nvidia.com/default/topic/893325/newest-and-beta-linux-driver-causing-segmentation-fault-core-dumped-on-all-skylake-platforms/ > > Bug #800574 suggest to disable elisian-unlock in glibc. Which is already > incorporated in experimental. This does not alleviate the issue. See the > "steps > to reproduce" below. The same bug suggests that the nvidia driver still has > problems. I also run intel-microcode update, but that doesn't solve anything. > Step to reproduce: gdb vlc > output: > (gdb) run > Starting program: /usr/bin/vlc > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > VLC media player 2.2.1 Terry Pratchett (Weatherwax) (revision > 2.2.1-0-ga425c42) > > Program received signal SIGSEGV, Segmentation fault. > __lll_unlock_elision (lock=0x726d0d08, private=0) > at ../sysdeps/unix/sysv/linux/x86/elision-unlock.c:29 > 29 ../sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such file or > directory. > (gdb) bt > #0 __lll_unlock_elision (lock=0x726d0d08, private=0) > at ../sysdeps/unix/sysv/linux/x86/elision-unlock.c:29 > #1 0x7247f26c in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1 > #2 0x7240fa22 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1 > #3 0x7fffd960 in ?? () > #4 0x72493ea1 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1 > #5 0x7fffd960 in ?? () > #6 0x77def59e in _dl_close_worker (map=, > force=) > at dl-close.c:291 > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > /usr/lib/x86_64-linux-gnu/libEGL.so.1 -> /usr/lib/x86_64-linux- > gnu/nvidia/libEGL.so.1 > > "dmesg|grep pthread" result: > breetai@mainbak:~$ dmesg |grep pthread > [73330.105569] traps: vlc[16815] general protection ip:7f47ac388950 > sp:7ffe3908ad98 error:0 in libpthread-2.22.so[7f47ac376000+18000] > [78860.282876] traps: dolphin[18294] general protection ip:7fc3b0c1b950 > sp:7ffd0a0828d8 error:0 in libpthread-2.22.so[7fc3b0c09000+18000] > [90812.515421] traps: krunner[20723] general protection ip:7f930fa19950 > sp:7ffc9b5cd988 error:0 in libpthread-2.22.so[7f930fa07000+18000] > [90826.164341] traps: akonadi_migrati[21161] general protection > ip:7f33b7e39950 > sp:7fff9d61bef8 error:0 in libpthread-2.22.so[7f33b7e27000+18000] > [92621.782318] traps: vlc[21962] general protection ip:7f4241467950 > sp:7ffd8fa98f68 error:0 in libpthread-2.22.so[7f4241455000+18000] > breetai@mainbak:~$ > > > installed packages: > System runs testing. > > libc6:amd64 2.22-0experimental0 from experimental > nvidia-driver 352.63-1from experimental > intel-microcode 3.20151106.1from testing > vlc 2.2.1-5+b1 from testing
Bug#779294: /usr/bin/python: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python)
Control: reassign -1 apt,python2.7,libc6 Control: tags -1 jessie [putting the apt maintainers into the loop, perhaps they can tell us why this is happening] On 2015-02-26 18:33, Matthias Klose wrote: On 02/26/2015 06:01 PM, Andreas Beckmann wrote: during a test with piuparts I noticed a failure to upgrade from 'wheezy'. I'm not exactly sure which package to blame. This happened on i386, I cannot reproduce it on amd64. The package being tested was lsb-desktop, but it can probably show up elsewhere as well. From the attached log (scroll to the bottom...): (Reading database ... 18847 files and directories currently installed.) Preparing to replace libpython2.7 2.7.3-6+deb7u2 (using .../libpython2.7_2.7.8-11_i386.deb) ... Unpacking replacement libpython2.7:i386 ... Preparing to replace python2.7 2.7.3-6+deb7u2 (using .../python2.7_2.7.8-11_i386.deb) ... Unpacking replacement python2.7 ... Preparing to replace python2.7-minimal 2.7.3-6+deb7u2 (using .../python2.7-minimal_2.7.8-11_i386.deb) ... Unpacking replacement python2.7-minimal ... dpkg: warning: unable to delete old directory '/etc/python2.7': Directory not empty Selecting previously unselected package libpython2.7-minimal:i386. Unpacking libpython2.7-minimal:i386 (from .../libpython2.7-minimal_2.7.8-11_i386.deb) ... Preparing to replace debconf 1.5.49 (using .../debconf_1.5.55_all.deb) ... /usr/bin/python: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) dpkg: warning: subprocess old pre-removal script returned error exit status 1 dpkg: trying script from the new package instead ... /usr/bin/python: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) dpkg: error processing /var/cache/apt/archives/debconf_1.5.55_all.deb (--unpack): subprocess new pre-removal script returned error exit status 1 /usr/bin/python: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) dpkg: error while cleaning up: subprocess installed post-installation script returned error exit status 1 Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/debconf_1.5.55_all.deb This looks a bit like python was unpacked before the new glibc. debconf calls pycompile (and python). It looks like this kind of thing can happen with any binary which needs the new glibc, and in this case it hits python. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54f0c2c6.9070...@debian.org
Bug#710521: ldd -r /usr/bin/go segfaults
Version: 2.17-7 Followup-For: Bug #710521 Hi, same segfault happens with /usr/bin/godoc (from golang-go 2:1.1-1, too) /usr/bin/osdctl (from osdsh 0.7.0-10) /usr/bin/osdsh (from osdsh 0.7.0-10) Andreas -- 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/20130713140251.11147.34964.report...@cake.ae.cs.uni-frankfurt.de
Bug#698586: tzdata: should Conflicts: tz-brasil
Package: tzdata Version: 2012j-1 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, tz-brasil was a package in lenny that had outlived its usefulness long ago: http://bugs.debian.org/578318 but it is still possible to have it installed in long grown systems (where it still could mess around with tzdata files). Adding a Conflicts: tz-brasil to tzdata should put a real end to this. cheers, Andreas -- 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/20130120182502.8653.32436.report...@cake.ae.cs.uni-frankfurt.de
Bug#629819: libc6-dev: moving crt1.o crti.o etc. to /usr/lib/triplet breaks external multiarch unaware applications
Package: libc6-dev Version: 2.13-5 Severity: normal Hi, the moving of crt1.o, crti.o, ... from /usr/lib to /usr/lib/triplet breaks external applications that are not aware of the new multiarch paths. One such application is GCC from SVN, which now fails to compile with this error: /usr/bin/ld: cannot find crti.o: No such file or directory (seems to happen the first time the stage1 compiler is used to link something). Testing something with gcc-trunk (and eventually bisecting gcc) is something I do quite regularily. In general I like the multiarch idea and don't want to go the road back. So a possible solution I see to make such external applications work again could be the introduction of a libc6-dev-compat package that ships the links /usr/lib/*.o - /usr/lib/triplet/*.o. This package should not be installed by default, but only by the admin knowing what he does. Andreas -- System Information: Debian Release: wheezy/sid APT prefers oldstable APT policy: (600, 'oldstable'), (600, 'unstable'), (600, 'testing'), (600, 'stable'), (500, 'stable-updates'), (130, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libc6-dev depends on: ii libc-dev-bin 2.13-5 Embedded GNU C Library: Developmen ii libc6 2.13-5 Embedded GNU C Library: Shared lib ii linux-libc-dev2.6.39-1 Linux support headers for userspac Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.6.0-5 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.4-6The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.5-5The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.6-3The GNU C compiler ii gcc-4.5 [c-compiler] 4.5.3-1The GNU C compiler ii gcc-4.6 [c-compiler] 4.6.0-11 The GNU C compiler Versions of packages libc6-dev suggests: pn glibc-doc none (no description available) pn manpages-dev none (no description available) -- no debconf information -- 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/20110608154158.7533.83848.report...@cake.ae.cs.uni-frankfurt.de
Bug#555644: libc6: fails to update from 2.10 -- incorrect invoke-rc.d call in postinst script
Package: libc6
Version: 2.10.1-6
Severity: serious
Hi,
when updating a sid/amd64 chroot (on a lenny(+older squeeze kernel)/amd64 host),
libc6 fails to update properly.
Last previous update was performed on Oct 12, no problems at that time.
This time, libc6 was going to be updated from 2.9-27 to 2.10.1-6 and
configuration fails with:
(since I didn't keep the original error message
and it was way to messed up by a lot of packages failing with
unconfigured libc6, I can still reproduce the problem by manually
reinstalling libc6)
# dpkg -i /var/cache/apt/archives/libc6_2.10.1-6_amd64.deb
(Reading database ... 28139 files and directories currently installed.)
Preparing to replace libc6 2.10.1-6 (using .../libc6_2.10.1-6_amd64.deb) ...
Unpacking replacement libc6 ...
Setting up libc6 (2.10.1-6) ...
Checking for services that may need to be restarted...
Checking init scripts...
invoke-rc.d: unknown initscript, /etc/init.d/-query not found.
dpkg: error processing libc6 (--install):
subprocess installed post-installation script returned error exit status 100
Errors were encountered while processing:
libc6
One reason for this are some incorrect calls to invoke-rc.d:
# grep -query /var/lib/dpkg/info/*
/var/lib/dpkg/info/libc6.postinst: invoke-rc.d -query
${service} start ; status=$?
/var/lib/dpkg/info/libc6.preinst: invoke-rc.d -query
${service} start ; status=$?
This should have been --query.
Surprisingly this update worked on another machine with a similar chroot
without problems, that chroot was updated once more inbetween and
yesterdays update was only from libc6 2.10.1-1 to 2.10.1-6.
If I manually fix the spelling of --query in the postinst script and try
to configure libc6, new errors occur:
# dpkg --configure libc6
Setting up libc6 (2.10.1-6) ...
Checking for services that may need to be restarted...
Checking init scripts...
dpkg: error processing libc6 (--configure):
subprocess installed post-installation script returned error exit status 105
Errors were encountered while processing:
libc6
Error 105 seems to be a return value from invoke-rc.d --query,
probably misinterpreted as a failure by set -e.
Andreas
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (600, 'unstable'), (600, 'testing'), (600, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6 depends on:
ii libc-bin 2.10.1-6 GNU C Library: Binaries
ii libgcc1 1:4.4.1-6 GCC support library
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy
pn glibc-doc none (no description available)
pn locales none (no description available)
-- debconf information:
glibc/restart-services:
glibc/disable-screensaver:
glibc/upgrade: true
glibc/restart-failed:
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535313: libc6-dev-i386 content is left in /emul/ia32-linux after upgrade from 2.9-12 to 2.9-20
Hi, yesterday I ran into this problem, too, and found that the content of libc6-dev-i386 was still under /emul/ia32-linux/usr/lib (but registered with dpkg for /usr/lib32) because the files were unpacked before the lib32 symlink was replaced by a directory. Probably the Depends: libc6-i386 needs to be raised to Pre-Depends libc6-i386 (= 2.9-xx) for libc6-dev-i386 (where xx is a fixed version, 21 would be the next) as it was/needs to be done for all other *ia32* lib packages. Then there has to be some cleanup done to the forgotten files in /emul/ia32-linux/. This problem can easily be reproduced in a minimalistic squeeze chroot (e.g. pbuilder) with libc6-dev-i386 installed when all eglibc packages are updated to the version from sid. Andreas -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#422598: libc6: Segmentation fault in printf()/vfprintf()/strlen()
Package: libc6
Version: 2.5-6
Severity: normal
Hi,
there happens a segmentation fault with the following code:
#include stdio.h
int main(int argc, char**argv)
{
printf(%s\n, strerror(atoi(argv[1])));
}
I have observed this on amd64 libc6 2.5-5 and 2.5-6,
it does not occur on i386 libc6 2.5-5.
The amd64 system is actually an amd64 schroot running on a sarge/i386
host.
If there is anything I can do to help you debug this, please let me
know. A small test log is appended below.
Andreas
$ vi strerror.c
$ gcc -g -o strerror strerror.c
$ ./strerror 0 ; echo $?
Segmentation fault
139
$ gdb ./strerror
GNU gdb 6.6-debian
This GDB was configured as x86_64-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) set args 0
(gdb) run
Starting program: /home/beckmann/strerror 0
Program received signal SIGSEGV, Segmentation fault.
0x2ad8f39eeab0 in strlen () from /lib/libc.so.6
(gdb) bt full
#0 0x2ad8f39eeab0 in strlen () from /lib/libc.so.6
No symbol table info available.
#1 0x2ad8f39beb15 in vfprintf () from /lib/libc.so.6
No symbol table info available.
#2 0x2ad8f39c4a6a in printf () from /lib/libc.so.6
No symbol table info available.
#3 0x00400549 in main (argc=2, argv=0x7f9b5838) at
strerror.c:5
No locals.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (30, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.16.29.2.em64t-smp (SMP w/16 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369388: /usr/bin/locale: misleading error: locale: Cannot set LC_ALL to default locale: No such file or directory
Package: libc6
Version: 2.3.6-7
Severity: normal
File: /usr/bin/locale
Hi,
I stomped over this error message when one of the LC_* variables was set
to a locale that was not generated on that particular machine. It had
nothing to do with LC_ALL (which is unset) and can be reproduced by
doing
$ LC_NAME=foobar locale
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=POSIX
LC_TIME=en_DK.UTF-8
LC_COLLATE=POSIX
LC_MONETARY=POSIX
LC_MESSAGES=POSIX
LC_PAPER=POSIX
LC_NAME=foobar
LC_ADDRESS=POSIX
LC_TELEPHONE=POSIX
LC_MEASUREMENT=POSIX
LC_IDENTIFICATION=POSIX
LC_ALL=
The error message should probably mention the variable (LC_NAME instaed
of LC_ALL) and the invalid/unavailable setting ('foobar' in this case).
What's the 'default locale' the error mentions?
Andreas
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (900, 'testing'), (900, 'stable'), (600, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-k7
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages libc6 depends on:
ii tzdata2006c-2Time Zone and Daylight Saving Time
libc6 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#213051: libc6-dev: gcc-2.95 -static fails: undefined reference to `.udiv'
Package: libc6-dev Version: 2.3.2-7 Severity: normal Statically linking a program with gcc-2.95 fails with the following errors: $ gcc-2.95 -static test.c /usr/lib/gcc-lib/sparc-linux/2.95.4/libgcc.a(_udivdi3.o)(.text+0xac): In function `__udivdi3': : undefined reference to `.udiv' /usr/lib/gcc-lib/sparc-linux/2.95.4/libgcc.a(_umoddi3.o)(.text+0xac): In function `__umoddi3': : undefined reference to `.udiv' collect2: ld returned 1 exit status test.c is just an empty main(). I also checked this problem against the following versions of libc6-dev: 2.3.2-8: problem occurs 2.2.5-11.5: works fine Unfortunately I couldn't find any older 2.3.x .debs gcc-3.2 and gcc-3.3 both work fine with 2.3.2-7 installed gcc versions: ii gcc-2.95 2.95.4-17 The GNU C compiler. ii gcc-3.2 3.2.3-8 The GNU C compiler ii gcc-3.3 3.3.2-0pre4 The GNU C compiler -- System Information: Debian Release: testing/unstable Architecture: sparc Kernel: Linux argonath-linux 2.4.22-anbe2-sparc64-smp #1 SMP Thu Sep 25 06:25:50 CEST 2003 sparc64 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6-dev depends on: ii libc6 2.3.2-7GNU C Library: Shared libraries an -- no debconf information Is there any other information you need? Andreas
Bug#213051: libc6-dev: gcc-2.95 -static fails: undefined reference to `.udiv'
Package: libc6-dev Version: 2.3.2-7 Severity: normal Statically linking a program with gcc-2.95 fails with the following errors: $ gcc-2.95 -static test.c /usr/lib/gcc-lib/sparc-linux/2.95.4/libgcc.a(_udivdi3.o)(.text+0xac): In function `__udivdi3': : undefined reference to `.udiv' /usr/lib/gcc-lib/sparc-linux/2.95.4/libgcc.a(_umoddi3.o)(.text+0xac): In function `__umoddi3': : undefined reference to `.udiv' collect2: ld returned 1 exit status test.c is just an empty main(). I also checked this problem against the following versions of libc6-dev: 2.3.2-8: problem occurs 2.2.5-11.5: works fine Unfortunately I couldn't find any older 2.3.x .debs gcc-3.2 and gcc-3.3 both work fine with 2.3.2-7 installed gcc versions: ii gcc-2.95 2.95.4-17 The GNU C compiler. ii gcc-3.2 3.2.3-8 The GNU C compiler ii gcc-3.3 3.3.2-0pre4 The GNU C compiler -- System Information: Debian Release: testing/unstable Architecture: sparc Kernel: Linux argonath-linux 2.4.22-anbe2-sparc64-smp #1 SMP Thu Sep 25 06:25:50 CEST 2003 sparc64 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6-dev depends on: ii libc6 2.3.2-7GNU C Library: Shared libraries an -- no debconf information Is there any other information you need? Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
