Bug#888183: libc6: Breaks openvz virtuals again
>>>>> "AJ" == Aurelien Jarno <aurel...@aurel32.net> writes: AJ> No, that simply doesn't scale. Other packages than the one in src:glibc AJ> depends on libc6 >= 2.26, and more and more are going to pick up this AJ> dependency in the next months. They might also be unpacked before libc6 AJ> preinst is ran. We can't add this check in every package. Then re-direct this to apt. There needs then to be a way to mark the deb that it *must* be installed first, before anything which depends on it. Not just "at the same time", but *before*. And then add that notation to the glibc debs. -JimC -- James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Bug#888183: libc6: Breaks openvz virtuals again
AJ> Do you have a list of other packages from the glibc src that are AJ> upgraded before? The following packages have unmet dependencies: libc-dev-bin : Depends: libc6 (> 2.26) but 2.25-6 is installed libc6-dev : Depends: libc6 (= 2.26-4) but 2.25-6 is installed libc6-i386 : Depends: libc6 (= 2.26-4) but 2.25-6 is installed libc6-pic : Depends: libc6 (= 2.26-4) but 2.25-6 is installed libc6-x32 : Depends: libc6 (= 2.26-4) but 2.25-6 is installed locales : Depends: libc-bin (> 2.26) but 2.25-6 is installed nscd : Depends: libc6 (> 2.26) but 2.25-6 is installed And on another box: The following packages have unmet dependencies: libc-dev-bin : Depends: libc6 (> 2.26) but 2.25-6 is installed libc6-dev : Depends: libc6 (= 2.26-2) but 2.25-6 is installed libnih1 : Depends: libc6 (> 2.26) but 2.25-6 is installed locales : Depends: libc-bin (> 2.26) And a third: The following packages have unmet dependencies: libc-dev-bin : Depends: libc6 (> 2.26) but 2.25-6 is installed libc6-dev : Depends: libc6 (= 2.26-4) but 2.25-6 is installed locales : Depends: libc-bin (> 2.26) but 2.25-6 is installed Those are after one previous attempt at --fix-broken. AJ> In any case it's not something we can control, the abort is done AJ> inside the libc6 preinst, there is no way the libc6 package can AJ> do that earlier. Of course it is. Just make every deb from the glibc src do that abort. Idealy, w/ a warning on how to hold them so that the rest of the upgradable packages can do so. -JimC -- James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Bug#888183: libc6: Breaks openvz virtuals again
>>>>> "AJ" == Aurelien Jarno <aurel...@aurel32.net> writes: AJ> It's exactly what the message does. It stopped the upgrade and prevented AJ> libc6 to be unpacked. That way your system is still usable. But that is NOT what the message does. The other debs from the glibc source are already upgraded and now everything breaks. The dialog has to occur before *any* of the debs from the glibc src are upgraded. -JimC -- James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Bug#888183: libc6: Breaks openvz virtuals again
>>>>> "AJ" == Aurelien Jarno <aurel...@aurel32.net> writes: AJ> This is perfectly normal that you do no get a dialog asking wether you AJ> want to upgrade libc6, as your kernel is too old for that. Not it is not normal. It still should have given that dialog so that I could skip libc and its fellows and upgrade what would have worked. AJ> 2.6.32 kernels are not supported anymore, you need at least a 3.2 kernel AJ> to run buster. Which is a bug. AJ> I'll add an entry to NEWS so that people get warned *before* trying to AJ> upgrade. *How* will they see it first? I only see package news after I upgrade, thanks to listchanges. AJ> You can use http://snapshot.debian.org/ to properly downgrade to the AJ> version prior to migration of glibc 2.26 to testing, which happened on AJ> 2018-01-12. Taking a bit of margin, that gives you: AJ> deb http://snapshot.debian.org/archive/debian/20180110T00Z/ buster main After running: echo 'Acquire::Check-Valid-Until "false";' >/etc/apt/apt.conf.d/98expires my update script almost worked with that. I still needed --fix-broken install. And a subsequent switch to stretch, even with dist-upgrade, didn't switch anything over to the stretch packages. Except of course on the 3 machines which report: apt: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /lib/x86_64-linux-gnu/libudev.so.1) I had to grab this and install it with dpkg to get apt working again on those (after a *lot* of earlier attempts): http://snapshot.debian.org/archive/debian/20180109T213416Z/pool/main/s/systemd/libudev1_232-25%2Bdeb9u1_amd64.deb -JimC -- James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Bug#855606: sqrt() regression on powerpc/jessie
>>>>> Christoph Berg <m...@debian.org> writes: > Jessie: 0X1.C48C6001F0ABFP+3 > Sid:0X1.C48C6001F0ACP+3 Looking tat the code glibc switched from fsqrt to a software version, resulting in the ulp difference. I see on pgsql-hackers, though, that glibc has enabled fma and as a result that difference is avoided. So jessie's libc6 on ppc32 needs to include the fma patch or switch back to using fsqrt. -JimC -- James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Bug#855606: sqrt() regression on powerpc/jessie
It may be a bit more informative to add:
printf("0X %A\n", r);
to that main() to see exactly what is different between the two.
The only ppc I have access to are those in the gcc farm and those (the
online ones anyway) only run fedora and aix, so I cannot test it
myself.
Except that everything else reports:
0X 0X1.C48C6001F0ACP+3
-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Bug#727841: powl() inaccurate but only at runtime
Z == Zefram zef...@fysh.org writes: Z On amd64, powl() is generating inaccurate results when called at runtime, Z but if a call to it gets constant-folded at compile time (by gcc 4.7) Z then the constant-folded result is much more accurate. AIUI, gcc uses multi-precision arith for constant folding, so that it can generate accurate results even when cross-compiling. The difference you show is likely libm vs mpfr. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- 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/m34n7mvr41@carbon.jhcloos.org
Bug#727841: powl() inaccurate but only at runtime
[I hit send to soon ... -JimC] And glibc 2.17 gets the same result as gcc does. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- 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/m3y54yucbw@carbon.jhcloos.org
Bug#538912: E: Couldn't configure pre-depend libc6-i386 for libc6-dev-i386, probably a dependency cycle.
Package: libc6-i386 Version: 2.9-21 Severity: important apt-get is unable to upgrade or dist-upgrade, failing immediately with: E: Couldn't configure pre-depend libc6-i386 for libc6-dev-i386, probably a dependency cycle. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6-i386 depends on: ii libc6 2.9-21 GNU C Library: Shared libraries libc6-i386 recommends no packages. libc6-i386 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#498171: Incorrect Debian README in tzdata
Aurelien == Aurelien Jarno [EMAIL PROTECTED] writes: Aurelien Look again at the README.Debian file. It doesn't pretend that Aurelien the right db should return the TAI time. Aurelien It is the db to use if your hardware clock is set to TAI, so Aurelien that the returned time is correct. The hardware clock is not relevant once the system is up, and ntp deals with (fractions of) seconds since its epoch, which is defined relative to UTC. right converts from seconds since 1970/January/01T00:00:00 UTC (the time_t epoch) to UTC-based time; posix converts to POSIX-based time. The README should say something to the effect that if you care about real wall-clock time use right and if you want to pretend that every day has exactly 60*60*24 seconds choose posix. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498171: Incorrect Debian README in tzdata
Package: tzdata Version: 2008e-4 Severity: minor The README added to the tzdata package is wrong. The right db is UTC, and the posix db is POSIX. TAI is not represented by the tzdata at all. A TAI zone db would be 10 seconds ahead of POSIX. Ie, 14:15:42 POSIX time is 14:15:52 TAI (and is currently 14:15:19 in right) on any given day in any given zone. (POSIX' epoch may be specified in UTC, but since they pretend that leap seconds do not exist they consequently define their own time.) posix is the default not because that is what anyone uses in real life, but because too much code incorrectly assumes that hours start at int(t/3600) and POSIX chickened out from Doing The Right Thing Anyway. Including a README about it is a Good Thing, but the initial one is misleading. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-xenU (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tzdata depends on: ii debconf [debconf-2.0] 1.5.23 Debian configuration management sy tzdata recommends no packages. tzdata suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
