Bug#1043250: tzdata: bring back top-level UTC

[Christoph Berg]

Control: severity -1 serious

Re: Thorsten Glaser
> >Why isn't Etc/UTC an alternative to UTC?
> 
> It’s not as portable, it binds to the Olson database whereas
> an otherwise unqualified UTC is pretty standard. Worse, if
> Etc/UTC is not available, the fallback makes it assume Etc,
> not UTC, as timezone name.

We can't know how many people out there have "TZ=UTC" in their shell
scripts, and we shouldn't break that. Perhaps Etc/UTC is more correct,
but I don't see why insisting on correctness needs to annoy users,
when the cost is just maintaining one symlink that we have shipped for
decades.

For a concrete data point: This change is now causing PostgreSQL to
FTBFS since UTC is used in the regression tests:

 SET TimeZone to 'UTC';
+ERROR:  invalid value for parameter "TimeZone": "UTC"

I'm hence raising to serious.

Christoph

Bug#1004577: ldconfig -p coredumps

[Christoph Berg]

Re: Florian Weimer
> > Package: libc-bin
> > Version: 2.33-3
> > Severity: important
> >
> > In 
> > https://salsa.debian.org/python-team/packages/python-telethon/-/jobs/2413916
> > there is a diff generated between the two builds because a core file
> > from `ldconfig -p` appears as /usr/lib/python3.10/dist-packages/core.
> 
> Is this the “FATAL: kernel too old” error?

I guess it is, yes.

> We could remove this check from upstream, and just try to run code and
> see how far we get.  I assume that these days, the check does more harm
> than good.  People with pre-3.2 kernels (glibc's built-in baseline) will
> likely run a heavily patched 2.6.32 kernel, and that should be *almost*
> there.

That would fix the problem, yes.

Christoph

Bug#1004577: ldconfig -p coredumps

[Christoph Berg]

Package: libc-bin
Version: 2.33-3
Severity: important

In https://salsa.debian.org/python-team/packages/python-telethon/-/jobs/2413916
there is a diff generated between the two builds because a core file
from `ldconfig -p` appears as /usr/lib/python3.10/dist-packages/core.

Backtrace:

[0] 18:56 myon@sid-amd64.maxwell:~/de/py/debian/output/reprotest 1j $ gdb 
/sbin/ldconfig core
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /sbin/ldconfig...
Reading symbols from 
/usr/lib/debug/.build-id/f3/4bf815c30c307353fa1703469d5f1f4b3c9356.debug...
[New LWP 12315]
Core was generated by `/sbin/ldconfig -p'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7f205bb9f621 in ?? ()
(gdb) bt
#0  0x7f205bb9f621 in ?? ()
#1  0x in ?? ()

The build artifacts are available from the salsa page; I don't have
any access to the system there.

There is another ldconfig segfault reported in #806911, I don't
know if that is related.

Christoph

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

[Christoph Berg]

Re: Paul Gevers 2019-04-06 
> 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.

Opened #926627 for that.

Note that I still need input on how to raise the message on the
packaging side.

Christoph

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

[Christoph Berg]

Re: Philipp Kern 2019-03-26 <66988de0-f9be-14c0-6b64-df64261fe...@philkern.de>
> I suspect this is why MySQL keeps a whole zoo of collations internally
> that never change.

DB2 and Oracle bundle ICU for that reason, afaict. (But bundling
software has other problems, as we all know...)

> Is there a way upon next (re)start to have a startup script check for
> this case and reindex automatically then - at the expense of a hugely
> enlarged downtime? Say, with a flag file that keeps the glibc major
> version at last restart time around - for the first iteration on this?

We were thinking about doing something like that, but that doesn't
work for the general case - most libc upgrades do not break
everything, and reindexing would be overkill. It might help for the
2.28 upgrade, but getting this to work consistently would require lots
of scripting with lots of cornercases to cover. I don't think it is
possible to get this working reliably now, especially as we would need
to push that "fix" into stretch-proposed-updates as well. (Because
libc6 will likely be upgraded first, before the new postgresql-common
version could take action.)

> That's at least better than silent data corruption, even if still
> disruptive. On the other hand I guess you'd need to start the cluster
> for serving anyway for reindex to work and would then serve broken data
> in the meantime, too?

That's part of the problem, yes.

Christoph

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

[Christoph Berg]

Re: Florian Weimer 2019-03-25 <87o95yhp3h@mid.deneb.enyo.de>
> > For PostgreSQL, this means that the ordering of indexes on disk is
> > becoming corrupt, and all "text" (varchar, char, ...) indexes need to
> > be rebuilt. (And worse, if that is not done immediately, the tables
> > might become corrupt because some tuples aren't index-visible anymore
> > due to the incorrect btree ordering.)
> 
> That's fairly normal in a glibc update.  glibc upstream prefers it
> this way.  I've discussed it several times with other glibc
> maintainers.

Changes are normal. What's not normal here is the scale of the
changes, indexes will break for virtually all users.

> My understanding is that ICU provides versioned collation tables,
> which would allow you to avoid this issue.
> 
>   

Unfortunately not. PostgreSQL supports ICU, but not as the global
locale for clusters/databases, which is still libc only. And even if
it was supported, it's not the default, and we are still breaking all
installations.

> > I've been thinking about this for some time, and the best I could come
> > up so far is "raise a debconf note that people need to invoke REINDEX
> > DATABASE". The open question about this plan is, how should this note
> > be triggered.
> 
> That might not work for unique indices because locale data changes
> could cause strings to sort the same that were distinct before the
> update.

Well, that's not an argument for silently doing nothing. And I doubt
that this case even exists, for any two distinct strings, the
collation should output a consistent "less than" or "greater than"
answer.

I forgot to mention Plan 3: Mention this in the release notes.
That should be done anyway, the question being if that is enough.
My suspicion is that few people actually read the release notes, so
some notification from inside the system would be needed as well.
Be it a debconf note, and/or a NEWS.Debian entry somewhere.

I deem this to be release-critical for PostgreSQL users. The reason
I'm asking here is to get input which plan is the best.

Christoph

Glibc 2.28 breaks collation for PostgreSQL (and others?)

[Christoph Berg]

Hi,

with the update to glibc 2.28, collation aka sort ordering is
changing:

$ echo $LANG
de_DE.utf8
$ (echo 'a-a'; echo 'a a'; echo 'a+a'; echo 'aa') | sort

stretch:
  aa
  a a
  a-a
  a+a

buster:
  a a
  a+a
  a-a
  aa

A vast number of locales is affected, including en_US, possibly all of
them.

For PostgreSQL, this means that the ordering of indexes on disk is
becoming corrupt, and all "text" (varchar, char, ...) indexes need to
be rebuilt. (And worse, if that is not done immediately, the tables
might become corrupt because some tuples aren't index-visible anymore
due to the incorrect btree ordering.)

https://postgresql.verite.pro/blog/2018/08/27/glibc-upgrade.html
https://www.postgresql.org/message-id/9cbd8ba7-899f-4ed3-92b1-902b0d245...@manitou-mail.org

The PostgreSQL project is discussing how this could be handled inside
the database, but a) it's totally unclear how this could be detected
generically, not just for this set of test strings, and b) Debian
needs a fix now, not something that might appear in PostgreSQL 12 or 13.

I've been thinking about this for some time, and the best I could come
up so far is "raise a debconf note that people need to invoke REINDEX
DATABASE". The open question about this plan is, how should this note
be triggered.

Plan 1: Add a check if there are any postgresql clusters in
/etc/postgresql/, and raise the warning from locales.postinst and
locales-all.postinst.

Plan 2: Add a trigger to postgresql-common that checks if
locales(-all) are being upgraded, and raise the warning from there.
(This plan has the downside that we'd need to fix postgresql-common in
stretch to have the same check.)

Plan 1 looks much better.

I'm sorry that I didn't raise that earlier because I had hoped to come
up with some smarter solution that would take some burden from the
user having to run commands manually.

Does that make sense? Are there any options that I missed? Are there
any other packages affected? How do we proceed?

Christoph

Bug#710275: check for postgresql in NSS check

[Christoph Berg]

Re: Aurelien Jarno 2017-11-17 
> @@ -22,6 +22,8 @@ glibc (2.25-0experimental4) UNRELEASED; urgency=medium
>* debian/sysdeps/ppc64el.mk: disable lock elision.  Closes:# 878071.
>* debian/script.in/nohwcap.sh: fix alpha ev67 optimized package name.
>  Closes: #881147.
> +  * debian/debhelper.in/libc.postinst, script.in/nsscheck.sh: check for
> +postgresql in NSS check.  Closes: #710275.
>  
>   -- Aurelien Jarno   Sun, 27 Aug 2017 01:51:15 +0200

Hi,

thanks for the fix!

Would it be possible to have it backported to (old?)stable as well?

Christoph

Bug#855606: sqrt() regression on powerpc/jessie

[Christoph Berg]

Re: James Cloos 2017-02-21 
> 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

Jessie: 0X1.C48C6001F0ABFP+3
Sid:0X1.C48C6001F0ACP+3

Christoph

Bug#855606: sqrt() regression on powerpc/jessie

[Christoph Berg]

Package: libc6
Version: 2.19-18+deb8u7
Severity: normal
Tags: jessie

The following C program produces different output on Jessie and Sid. I
believe the Sid output is the correct one, and in fact this is the
output that has been observed for the "point" (and "polygon")
regression tests for PostgreSQL on all platforms for the last 20 years
since the test got added.


$ cat sqrt.c
#include 
#include 
#include 

double
pg_hypot(double x, double y)
{
double  yx;

/* Some PG-specific code deleted here */

/* Else, drop any minus signs */
x = fabs(x);
y = fabs(y);

/* Swap x and y if needed to make x the larger one */
if (x < y)
{
double  temp = x;

x = y;
y = temp;
}

/*
 * If y is zero, the hypotenuse is x.  This test saves a few cycles in
 * such cases, but more importantly it also protects against
 * divide-by-zero errors, since now x >= y.
 */
if (y == 0.0)
return x;

/* Determine the hypotenuse */
yx = y / x;
return x * sqrt(1.0 + (yx * yx));
}


int main ()
{
//fesetround(FE_TONEAREST);
printf("fegetround is %d\n", fegetround());
double r = pg_hypot(10.0, 10.0);
printf("14 %.14g\n", r);
printf("15 %.15g\n", r);
printf("16 %.16g\n", r);
printf("17 %.17g\n", r);
return 0;
}


Jessie output:
fegetround is 0
14 14.142135623731
15 14.1421356237309
16 14.14213562373095
17 14.142135623730949

Sid output:
fegetround is 0
14 14.142135623731
15 14.142135623731
16 14.14213562373095
17 14.142135623730951


The Sid output is also observed when running the binary compiled on
Jessie on Sid, so it's a library issue, not a compiler/binary one.


The problem might be due to the fix for #843904.


FTBFS in postgresql-9.4 in jessie-pu:
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4=powerpc=9.4.11-0%2Bdeb8u1=1487473754=0
FTBFS in postgresql-9.6 in jessie-backports:
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6=powerpc=9.6.1-2~bpo8%2B1=1485184696=0

Thread on pgsql-hackers:
https://www.postgresql.org/message-id/20170220155819.m2s43pf2pvkes4pc%40msg.credativ.de

Christoph


signature.asc
Description: PGP signature

Bug#356846: O: pth -- The GNU Portable Threads

[Christoph Berg]

Package: wnpp
Severity: normal

The current maintainer of pth, Luis Bustamante [EMAIL PROTECTED],
has orphaned this package.

If you want to be the new maintainer, please take it -- see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly. I'm Cc'ing the glibc
maintainers in case they are interested.

Some information about this package:

Package: pth
Binary: libpth-prof, libpth-dev, libpthread-dev, libpthread2, libpth-dbg, 
libpth2
Version: 2.0.1-2.1
Priority: optional
Section: libs
Maintainer: Luis Bustamante [EMAIL PROTECTED]
Build-Depends: debhelper ( 3.0.0), autotools-dev, libtool
Architecture: any
Standards-Version: 3.6.1
Format: 1.0
Directory: pool/main/p/pth
Files:
 7f4bc83521abfb324e5950df3f070985 652 pth_2.0.1-2.1.dsc
 549b59457f7c3de7372df68b365589e6 635769 pth_2.0.1.orig.tar.gz
 2928567ac4c86a89ebdc089b651beb2c 10819 pth_2.0.1-2.1.diff.gz

Package: libpth-prof
Priority: extra
Section: libdevel
Installed-Size: 144
Maintainer: Luis Bustamante [EMAIL PROTECTED]
Architecture: i386
Source: pth
Version: 2.0.1-2.1
Depends: libpth2 (= 2.0.1-2.1)
Filename: pool/main/p/pth/libpth-prof_2.0.1-2.1_i386.deb
Size: 62598
MD5sum: 252f6958edb39e88fc978cbb10317c2e
Description: The GNU Portable Threads (for profiling)
 Pth is a very portable POSIX/ANSI-C based library for Unix
 platforms which provides non-preemptive priority-based
 scheduling for multiple threads of execution (multithreading)
 inside server applications. All threads run in the same address
 space of the server application, but each thread has its own
 individual program-counter, run-time stack, signal mask and
 errno variable.
 .
 More information can be found at the libpth web site
 http://www.gnu.org/software/pth/ .
Tag: devel::library

Package: libpth-dev
Priority: optional
Section: libdevel
Installed-Size: 232
Maintainer: Luis Bustamante [EMAIL PROTECTED]
Architecture: i386
Source: pth
Version: 2.0.1-2.1
Replaces: libpth13-dev
Depends: libpth2 (= 2.0.1-2.1)
Suggests: libpth-dbg, libpth-prof
Conflicts: libpth13-dev
Filename: pool/main/p/pth/libpth-dev_2.0.1-2.1_i386.deb
Size: 92
MD5sum: ac8df362ebf73a0296074e4309a1d520
Description: Header files for The GNU Portable Threads
 Pth is a very portable POSIX/ANSI-C based library for Unix
 platforms which provides non-preemptive priority-based
 scheduling for multiple threads of execution (multithreading)
 inside server applications. All threads run in the same address
 space of the server application, but each thread has its own
 individual program-counter, run-time stack, signal mask and
 errno variable.
 .
 More information can be found at the libpth web site
 http://www.gnu.org/software/pth/ .
Tag: devel::library, role::sw:devel-lib

Package: libpth-dbg
Priority: extra
Section: libdevel
Installed-Size: 636
Maintainer: Luis Bustamante [EMAIL PROTECTED]
Architecture: i386
Source: pth
Version: 2.0.1-2.1
Depends: libc6 (= 2.3.2.ds1-21)
Filename: pool/main/p/pth/libpth-dbg_2.0.1-2.1_i386.deb
Size: 247224
MD5sum: 86cfa3ba7d15a60dfd7d21cc15bea752
Description: The GNU Portable Threads (with debugging information)
 Pth is a very portable POSIX/ANSI-C based library for Unix
 platforms which provides non-preemptive priority-based
 scheduling for multiple threads of execution (multithreading)
 inside server applications. All threads run in the same address
 space of the server application, but each thread has its own
 individual program-counter, run-time stack, signal mask and
 errno variable.
 .
 More information can be found at the libpth web site
 http://www.gnu.org/software/pth/ .
Tag: devel::debugger, devel::library

Package: libpth2
Priority: optional
Section: libs
Installed-Size: 156
Maintainer: Luis Bustamante [EMAIL PROTECTED]
Architecture: i386
Source: pth
Version: 2.0.1-2.1
Replaces: libpth-dbg ( 2.0.1-2.1), libpth-prof ( 2.0.1-2.1), libpth-dev ( 
2.0.1-2.1), libpth14
Depends: libc6 (= 2.3.2.ds1-21)
Conflicts: libpth-dbg ( 2.0.1-2.1), libpth-prof ( 2.0.1-2.1), libpth-dev 
( 2.0.1-2.1), libpth14
Filename: pool/main/p/pth/libpth2_2.0.1-2.1_i386.deb
Size: 72786
MD5sum: dc03db52180cd7b3af3104072a95ba0a
Description: The GNU Portable Threads
 Pth is a very portable POSIX/ANSI-C based library for Unix
 platforms which provides non-preemptive priority-based
 scheduling for multiple threads of execution (multithreading)
 inside server applications. All threads run in the same address
 space of the server application, but each thread has its own
 individual program-counter, run-time stack, signal mask and
 errno variable.
 .
 More information can be found at the libpth web site
 http://www.gnu.org/software/pth/ .
Tag: devel::library


Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

upgrading mysql (Release update: kde3.3, upload targets, kernels, infrastructure)

[Christoph Berg]

Re: Steve Langasek in [EMAIL PROTECTED]
   symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link 
   time reference  (/usr/lib/libmysqlclient.so.10)
 
  I don't know this problem is missing GLIBC_2.2 symbols issue.  It
  does not clear Christoph's problematic architecture.
 
 This is the only warning shown on my system when installing woody
 mysqlclient on sarge glibc, and is the only major ABI regression of this
 kind I'm aware of between woody and sarge glibc.  Unless Christoph can offer
 more precise information about the symbols that were missing on his system,
 I assume this is the problem he's referring to.

Right. mysqladmin ping threw that warning and then died. Installing
Sarge's mysql packages made the DB work again. I didn't investigate
this any further, and the system was downgraded again in the meantime
(which was a pita due to tons of backports that were installed, but
that's another issue).

I can't say which other packages were affected, the only client for
that mysql DB is horde/imp(3), and that even seemed to work without
the DB.

The proper fix would have been to make the Woody mysql packages depend
on that specific libc6 version, but that's too late now. I doubt
making Sarge's libc6 Conflict: with the Woody mysql makes sense here,
but I can't think of another way to fix it now.

Should I give the upgrade another try in a chroot sandbox and then
file a (RC?) bug that mysql is not upgradable?

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#235759: Bug#228486: No mention of german quotes in release-notes yet

[Christoph Berg]

Re: GOTO Masanori in [EMAIL PROTECTED]
 The locales for German style languages (e.g. [EMAIL PROTECTED])
  unfortunately use an aesthetically unpleasing way of representing
  open quotation marks.

You should mention that this only applies to non-utf-8 locales.

de_DE.ISO-8859-1:
| $rm a
| rm: Aufruf von lstat fr ,,a nicht mglich: Datei oder Verzeichnis nicht 
gefunden

de_DE.UTF-8 is fine:
| $rm a
| rm: Aufruf von lstat fr a nicht mglich: Datei oder Verzeichnis 
nicht gefunden

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature