Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-19 Thread Simon McVittie
On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote:
> Remaining usecases of i386 will be old binaries, some old Linux binaries 
> but especially old software (including many games) running in Wine.
> Old Linux binaries will still need the old 32bit time_t.

Based on background from my contributions to the Steam Runtime:

I don't have numbers, but you might be surprised how many Linux-supporting
games are 32-bit. The Steam client itself is currently also 32-bit
(with some 64-bit subprocesses); this is somewhat deliberate, to act as
a canary for whether 32-bit code works at all, particularly when combined
with graphics.

The Steam Runtime (a LD_LIBRARY_PATH library bundle used to run Steam and
Steam games) is built on an increasingly ancient version of Ubuntu, but
it tries to use newer libraries of the same SONAME from the host system
where available, which they often will be, because people who install
Steam probably also install Wine, which has 32-bit dependencies. If those
libraries have an incompatible ABI involving 64-bit time_t, and it is used
at the ABI "surface" between a host-system library and a Steam Runtime
library or the game, then 32-bit games, and the Steam client itself,
will crash.

The Steam Runtime also relies on the host system for the OpenGL stack
(in practice Mesa or proprietary NVIDIA drivers), and for glibc itself.

In practice, many of the 32-bit games are not ever going to be recompiled
against a new ABI; the games are no longer developed or actively
supported, and their developers might no longer even be still in business.

Outside the Steam ecosystem, 32-bit games typically rely on host-system
libraries for things like SDL, X11 libraries, audio libraries and graphics
format libraries. It's unfortunate that GTK is one of the libraries
with time_t in its ABI, because GTK 2 is a fairly common choice for
game launcher/frontend programs.


Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

2019-02-07 Thread Simon McVittie
On Thu, 07 Feb 2019 at 14:05:33 +0100, Adam Borowski wrote:
> a locale for a silly country with weird customs

Please don't take this tone. Insulting people who disagree with you[1]
is rarely an effective way to persuade them that you're right and
they're wrong.

> • promoting C.UTF-8 in our user interfaces (allowing to select it in d-i,
>   making dpkg-reconfigure locales DTRT, making it the d-i default)

I think this is exactly the "international/culture-neutral English"
locale that you're looking for. (Well, the C/POSIX locale is the formally
standardized form of that, but breaks text outside the ASCII range;
C.UTF-8 is the C locale with Unicode support added.)

> • inventing a new locale "en" without a country bias
>   -- good in the long term but problematic a month before freeze

I assume this would be a UTF-8 locale like en_US.utf8 and en_GB.utf8,
so probably en.utf8, possibly with a simple "en" alias?

As you say, I don't think a country-neutral specifically-English locale
is going to happen before buster.

How would this locale differ from C.UTF-8? Is the only difference
that C.UTF-8 has strict lexicographical sorting, whereas "en" would have
case-insensitive sorting like en_GB.utf8 does? (If that's the only
difference, then perhaps something like "LANG=C.utf8 LC_COLLATE=en_US.utf8"
is enough.)


[1] As it happens, I do agree with you that AM/PM time and middle-endian
dates are not a good default; but I'm from a different English-speaking
country with its own weird customs.

Bug#915621: glibc-source: needs versioned Breaks on some binary from cross-toolchain-base (<< 29~)

2018-12-05 Thread Simon McVittie
Package: glibc-source
Version: 2.28-1
Severity: important

autopkgtest fails while trying to test whether glibc in unstable could
migrate to testing:

> tar -x -f  /usr/src/glibc/glibc-2.28.tar.xz
> cp -a /usr/src/glibc/debian/ glibc-2.28
> cd glibc-2.28 ; \
> QUILT_PATCHES=/tmp/autopkgtest-lxc.ufw2cd2w/downtmp/build.UwU/src/debian/patches/glibc/debian
>  quilt --quiltrc /dev/null push -a && \
> rm -rf .pc/
> Applying patch dpkg-shlibs.patch
> patching file debian/rules.d/
> Applying patch local-kill-locales.patch
> patching file debian/rules
> patching file localedata/SUPPORTED
> Hunk #1 FAILED at 2.
> 1 out of 1 hunk FAILED -- rejects in file localedata/SUPPORTED

I think this means glibc-source should have a Breaks: on some binary
package that gets installed by cross-toolchain-base's autopkgtest, so
that the testing migration infrastructure knows that cross-toolchain-base
28 and glibc-source 2.28 is not a valid combination.

Unfortunately, cross-toolchain-base's d/tests/control doesn't include
any binary packages built by cross-toolchain-base. Perhaps one needs to
be added, as a way to tell the testing migration infrastructure what is
going on?

Presumably this also means that cross-toolchain-base's autopkgtest is
not actually testing anything about the previously built .debs, which
seems contrary to the design of autopkgtest. I would have expected an
autopkgtest for cross-toolchain-base to be something more like this:

- install linux-libc-dev-arm64-cross, libc6-arm64-cross, etc.
- use them to compile and link a "hello, world" arm64 executable
- (optionally) use qemu or something to run it

where the choice of arm64 is arbitrary, but should ideally not match
the architecture of the CI infrastructure.


Re: RFC: use of shlib bump for libc dependency on new multiarch directories?

2011-02-23 Thread Simon McVittie
On Wed, 23 Feb 2011 at 13:52:35 -0800, Steve Langasek wrote:
 we almost certainly will not be using the path which has been enabled
 in glibc up to now, namely /lib/i486-linux-gnu.

I'd heard that, and was somewhat concerned about whether that'd block
multiarch for yet another release cycle; I'm glad to hear it isn't.

One possibility that occurred to me is adding a Pre-Depends on a new package
(multiarch-enabler, perhaps) which is arch:any and just contains this

# /etc/

Am I right in thinking that (probably only needed for the native architecture,
even) would be enough to bootstrap support for the multiarch paths in the
native architecture's linker far enough to perform the upgrade? A future
libc6 could even Replace it or something.

(It'd be a bit subtle by being transitively Essential, though.)


To UNSUBSCRIBE, email to
with a subject of unsubscribe. Trouble? Contact