Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)
On 3/26/2019 3:20 PM, Christoph Berg wrote: > 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.) Technically the latter could be solved by libc6 in testing adding a breaks on postgresql-common. As neither postgresql-common nor postgresql-client-common seem to depend on libc6 at all, it doesn't immediately seem crazy to me to do that. But I don't dispute that the complexity could be high to do this properly. It's unfortunate that this came up that late, given that it was already a problem for users of testing. Kind regards Philipp Kern
Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)
On 3/26/2019 9:45 AM, Christoph Berg wrote: > 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 suspect this is why MySQL keeps a whole zoo of collations internally that never change. >>> 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. 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? 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? Kind regards Philipp Kern
Re: Please auto-build glibc-doc-reference
Hey Aurelien, On 05.12.2017 22:45, Aurelien Jarno wrote: > The glibc-doc-reference package is non-free because it is licensed under > the GNU Free Documentation License with invariant sections. Besides that > there is nothing which prevent building and distributing the package. > > Therefore could you please whitelist it? done. Kind regards and thanks Philipp Kern
Re: Merging libnss-dns-udeb and libnss-files-udeb back into libc6-udeb
On Sun, Mar 13, 2016 at 02:26:26AM +0100, Aurelien Jarno wrote: > For historical reason, disk space on boot floppies, the libnss_dns.so.2 > and libnss_files.so.2 libraries are in separate udeb packages, namely > libnss-dns-udeb and libnss-files-udeb. This is not the case of the deb > package, where everything is in the libc6 package. > > In practice these libraries are really small by nowadays standards (22kB > and 47kB uncompressed), and moreover libnss-dns-udeb is already included > in all images. In addition these libraries are tightly coupled to the > libresolv library which is in libc6-udeb. The recent CVE-2015-7547 has > shown that, and Ubuntu hit a bug by having the two out of sync in their > installer [1]. We would have got the same if debian-installer was pulling > its udeb from debian-security. > > That's why I would like to propose to merge back libnss-dns-udeb and > libnss-files-udeb back into libc6-udeb. The idea is to make libc6-udeb > to provide them, it seems udpkg supports that. The only packages having > a dependency on libnss-files-udeb are espeakup-udeb, rdnssd-udeb, > open-iscsi and openssh-client-udeb, and none of them has a versioned > dependency. None of the udeb have a dependency on libnss-files-udeb. > > Any opinion on that? It sounds like a good idea to me. :) Kind regards Philipp Kern
Re: Handling s390 libc ABI change in Debian
On Tue, Jul 15, 2014 at 07:18:39AM +0200, Aurelien Jarno wrote: I can follow up with a list affected packages, but we are slowly discovering them one by one, so it might takes time. So far we have: * Mixing modules/libraries built with pre-2.19 and 2.19 libc - perl - libpng * Using libc 2.19 without rebuilding anything: - gauche - mono I think it's pretty important for perl to keep working as much as is required for the system to upgrade itself. I'd be a bit less concerned (aside already broken binary compatibility) if the base system keeps working during the upgrade. We could conceivably document the breakage in the release upgrade notes, as long as updates can complete and suggest a reboot afterwards. It's a huge work for Debian, maybe not for other distribution, as it basically means we have to rebootstrap everything. This includes manual bootstrapping of self-dependent languages (haskell, gnat, ...) and manual handling of some dependencies loop. In addition it's something which hasn't been done since the libc5 transition, so we might discover some unexpected issues. Will it necessarily explode if both libcs are loaded into the same address space or only if the broken functionality is used? Would setjmp/longjmp only break if used across libc6/6.1 boundaries? Passing around an incompatible pthread struct seems bad, though. If this would work, a re-bootstrap would not necessarily be needed, I think? Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Re: glibc: disabling armhf ldconfig support
Aurelien, thanks for informing us. On Thu, Jul 05, 2012 at 12:08:06AM +0200, Aurelien Jarno wrote: As a consequence the armhf value will have to be changed in the future, which might have some side effects. What kind of side effects might happen? I.e. is it likely to break pure armhf systems in any way? When would one mix and match armel and armhf libraries? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#670597: libc6: /lib/ld-linux.so.3 symlink not set
On Fri, Apr 27, 2012 at 12:04:29PM +, Adam Conrad wrote: Closing this bug, as it was discovered that the failing binaries in question were from debian-ports, not from debian.org. Maintaining backward compat with non-official archives is a non-starter, and hopefully most people know how to work around this with violent apt-pinning sidegrades, or reinstalling from the official archive. However it would be nice if you could avoid breaking all our official buildds in the process next time. I.e. a notice *before* breaking the ports' users would've been helpful, especially as that change wasn't particularly time critical *for Debian*. Thanks Philipp Kern -- 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/20120429145703.ga21...@hub.kern.lc
Bug#658171: libc6: dns resolving failing after point release update
I wonder what Ulrich Drepper was up to with [1]. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=12684 signature.asc Description: Digital signature
Re: [SRM] Uploading new upstream stable version to Squeeze?
Aurelien, On Sun, Jun 05, 2011 at 12:23:51PM +0200, Aurelien Jarno wrote: For a few upstream releases now, some people are maintaining a stable branch for some versions of the glibc [1], which is followed by eglibc [2]. This is the case for the 2.11 version we are using in Squeeze, it is not sure yet which next version will have a long term support. The branch only consists of patches cherry-picked from HEAD after a few weeks. Some of the patches in this branch fix already reported bugs [3], but some of them [4] are likely to be reported later during Squeeze lifetime. I am therefore thinking about uploading the next upstream stable version (2.11.4 is currently in test period, it will be released in the next days), similarly to what is currently done for the kernel. What's your opinion on that, is it something that you would allow? [3] and [4] look fine, I'd like to see the whole diff against Squeeze, though. Is it reviewable? (Added test cases also seem like a great idea, FWIW.) Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Fwd: tzdata-2011d in volatile
Dear Glibc maintainers, we just received the following request for 2011d in lenny-volatile and squeeze-updates. Could you prepare the uploads? Thanks Philipp Kern ---BeginMessage--- Hi, tzdata-2011d includes an update to Turkish daylight saving time change. The day the DST is applied was postponed for one day, from Mar 27th, to Mar 28th 2011. Further information is available at posts: http://article.gmane.org/gmane.comp.time.tz/3658 http://article.gmane.org/gmane.comp.time.tz/3662 Can you publish tzdata-2011d-1 package for lenny and squeeze ? -- Gökdeniz Karadağ -- To UNSUBSCRIBE, email to debian-volatile-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d888717.5000...@gmail.com ---End Message--- signature.asc Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 01:52:35PM -0800, Steve Langasek wrote: [1] i486 is an arbitrary name that happens to correspond to the base instruction set that was in use on Debian at the time multiarch was first formulated, but it doesn't match the current base instruction set on Debian (i586) or Ubuntu (i686), doesn't match the directory configured in the current eglibc package on Ubuntu (/lib/i686-linux-gnu), and is going to look weird to other distributions when we try to talk to them about this since they've also long since moved to i686 as their base compatibility. Sorry to skip multiarch[1], but I need to comment on this one. Isn't the base instruction set still i486? I still haven't found any practical example of a change of ISA between i486 and i586. For all means they seem to be equivalent, with i686 being the next break. The only exception that might be is that 486 can actually lack FPUs, while Pentiums don't. But for all practically relevant cases I'd assume that they don't, and I'd be surprised if we'd cater for that. Out of curiosity: Where will optimized libraries be placed? Kind regards Philipp Kern [1] As you said pre-depends are messy but the safe bet. It would be best if we could somehow ensure that libc6 is upgraded first and that everything needed for the unpack is still there at that point (i.e. some liberal use of pre-depends somewhere in just the base set instead of everywhere). signature.asc Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 02:29:26PM -0800, Steve Langasek wrote: [1] As you said pre-depends are messy but the safe bet. It would be best if we could somehow ensure that libc6 is upgraded first and that everything needed for the unpack is still there at that point (i.e. some liberal use of pre-depends somewhere in just the base set instead of everywhere). Ok. I think that's certainly going to be more manageable than trying to add pre-depends to everything, anyway. Any concerns about bumping the dependency for all libraries via dpkg-shlibdeps? What's the timeframe for eglibc to be ready? If it's able to migrate to testing fairly soon and as it's just shlibdeps and as it's at the beginning of the cycle, I don't really see any. It should not be the primary blocker for migration for weeks, though. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#502311: Exact errors differ by architecture
On Thu, Oct 16, 2008 at 09:54:05PM +0200, Aurelien Jarno wrote: On Thu, Oct 16, 2008 at 07:20:35PM +0200, Frank Lichtenheld wrote: Note that the list of regressions differ by architecture, but it is probably not useful at this point to make a separate bug for each of them, right? Yes, they differ by architecture, because the list has been established by building the package on a machine, verifying that there is no regression compared to version 2.7 and use the result as a baseline. We definitely have something different on those machines compared to the machines I used. I think it may be the kernel. The buildd in question runs Etch's kernel (2.6.18-6-mckinley #1 SMP Fri Jun 6 23:07:37 UTC 2008). Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502311: glibc_2.8+20080809-2(ia64/experimental): regressions in testsuite
Package: glibc Version: 2.8+20080809-2 Severity: serious There was an error while trying to autobuild your package: Automatic build of glibc_2.8+20080809-2 on alkman.ayous.org by sbuild/ia64 98-farm Build started at 20081014-2333 [...] ** Using build dependencies supplied by package: Build-Depends: gettext, make (= 3.80), dpkg-dev (= 1.14.17), bzip2, lzma, file, quilt, autoconf, sed (= 4.0.5-4), gawk, debhelper (= 5.0), linux-libc-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], mig (= 1.3-2) [hurd-i386], hurd-dev (= 20080607-3) [hurd-i386], gnumach-dev [hurd-i386], libpthread-stubs0-dev [hurd-i386], kfreebsd-kernel-headers [kfreebsd-i386 kfreebsd-amd64], binutils (= 2.17cvs20070426), g++-4.2 (= 4.2.1) [alpha], g++-4.3 (= 4.3.0-7) [!alpha], g++-4.3-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 sparc] [...] Encountered regressions that don't match expected failures: bug-iconv6.out, Error 1 tst-iconv7.out, Error 1 tst-mutexpi5a.out, Error 1 tst-robust1.out, Error 1 tst-robust2.out, Error 1 tst-robust3.out, Error 1 tst-robust4.out, Error 1 tst-robust5.out, Error 1 tst-robust6.out, Error 1 tst-robust7.out, Error 1 tst-robust8.out, Error 1 tst-robust9.out, Error 1 tst-robustpi8.out, Error 1 make: *** [/build/buildd/glibc-2.8+20080809/stamp-dir/check_libc] Error 1 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 ** A full build log can be found at: http://experimental.debian.net/build.php?arch=ia64pkg=glibcver=2.8+20080809-2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453314: locales: first_weekday setting in en_GB.UTF-8 possibly incorrect
Package: locales Version: 2.7-2 Severity: normal Hi there, the weekday setting in en_GB.UTF-8's locale file seems incorrect to me: $ LC_ALL=en_GB.UTF-8 locale -k LC_TIME|grep '^first_' first_weekday=2 first_workday=1 $ LC_ALL=en_US.UTF-8 locale -k LC_TIME|grep '^first_' first_weekday=1 first_workday=2 And indeed clock-applet of Gnome thinks that my week starts on Tuesday (which is how I noticed it). A Gentoo system, also with 2.7, gives me the following (the calendar displayed by the applet is correct): $ LC_ALL=en_US.UTF-8 locale -k LC_TIME|grep '^first_' first_weekday=1 first_workday=2 $ LC_ALL=en_GB.UTF-8 locale -k LC_TIME|grep '^first_' first_weekday=1 first_workday=1 I am not exactly sure if the difference of 1 day in week-1stday is relevant here. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
