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 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.) smcv  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.
Package: glibc-source Version: 2.28-1 Severity: important autopkgtest fails while trying to test whether glibc in unstable could migrate to testing: https://ci.debian.net/data/autopkgtest/testing/amd64/c/cross-toolchain-base/1438735/log.gz > 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/debhelper.mk > > 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. smcv
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 file: # /etc/ld.so.conf.d/x86-linux-glibc.conf /lib/x86-linux-glibc /usr/lib/x86-linux-glibc 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.) S -- 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/20110223225551.ga17...@reptile.pseudorandom.co.uk