Bug#1005193: libc6: please split away gconv files
Package: libc6 Version: 2.34-0experimental2 Severity: wishlist Hi! The bulk of libc6 package consists of gconv files for obsolete locales. This costs us 8.2MB per arch, even for minimal containers. Fedora has done so, then lowered the dependency to Recommends last year: https://www.fedoraproject.org/wiki/Changes/Gconv_package_split_in_glibc They've decided to keep a handful of often used old locales, which is probably reasonable. Obviously, such a change would require adding dependencies on the split out gconv from packages that actually need to handle such locales, and that's non-trivial work -- but, any such work would require the extra package to actually exist. Thus: could you please move the gconv files to a new package; with a hard dependency from libc6 for now? Meow! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-rc3-00017-g9f7865599562 (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libc6 depends on: ii libgcc-s1 12-20220206-1 Versions of packages libc6 recommends: ii libidn2-0 2.3.2-2 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.79 ii glibc-doc 2.33-5 ii libc-l10n 2.34-0experimental2 pn libnss-nis pn libnss-nisplus ii locales2.34-0experimental2 -- debconf information excluded
Re: Options for 64-bit time_t support on 32-bit architectures
On Fri, Jul 19, 2019 at 11:19:23PM +0300, Adrian Bunk wrote: > On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote: > > Similar to the LFS support, with the > > additional property that binaries built in either mode should continue > > to work on kernels which predate support for the *_time64 system > > calls. > > Debian does not support running on kernels older than the one in the > previous stable release. Stretch supports running on Squeeze's kernel (-3 releases), Buster supports running on Wheezy's kernel (-3 releases). > E.g. Qt in Debian 9 unconditionally uses the getrandom syscall that is > not in kernel 3.16 in Debian 7. Individual packages may fail, yeah. No one is really going to run GUI stuff with an ancient kernel. It's really widespread in hosting scenarios, though -- and for big servery stuff, the running kernel might be still-supported 2.6.18 while 3.10 still gets newest shiniest stuff. (But not getrandom, dammit!). The time64 syscalls got added only in 5.1, which is not even in Buster. And 32-bit hardware notoriously needs ancient vendor kernels. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ At least spammers get it right: "Hello beautiful!". ⠈⠳⣄
Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?
On Thu, Feb 07, 2019 at 04:08:21PM +0100, Ansgar wrote:
> On Thu, 2019-02-07 at 09:59 -0500, Michael Stone wrote:
> > POSIX specifies the output format for various utilities in the C locale,
> > which defeats my understanding of the purpose of this proposal. So, for
> > example, in ls -l:
>
> I don't think the "C.UTF-8" locale covered by any promises POSIX might
> make for "C". (Nor is what happens when no LC_*, LANG vairables are
> set at all.)
Here's the latter:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html
"POSIX"
Specifies the minimal environment for C-language translation called the
POSIX locale. The POSIX locale is the default global locale at entry to
main().
"C"
Equivalent to "POSIX".
""
Specifies an implementation-defined native environment. [CX] The
determination of the name of the new locale for the specified category
depends on the value of the associated environment variables, LC_* and
LANG; see XBD Locale and Environment Variables.
So a process that doesn't call setlocale() at all must work within the
requirements of "C" (which C.UTF-8 almost meets standards-wise, but too many
programs misinterpret as raw 8-bit for a switch to be safe) -- but a process
that _does_ call setlocale("") when the env vars are unset may get anything
reasonable. I argue that C.UTF-8 is more reasonable than "C".
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄
Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?
On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote:
> 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.
I don't quite see how speech peppered with words like "imperialism" could be
taken seriously as insults, aside from bad-old-days soviet propaganda.
If I still didn't mark the tone as in jest enough, then apologies.
> > • 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.
Yeah.
> (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.)
Not really -- behaviour of C/POSIX for characters above 126 is _undefined_.
That locale is defined in a weird convoluted way designed to allow both
ASCII and IBM's encryption standards (aka variants of EBCDIC).
The only way I found so far that our current C.UTF-8 fails POSIX's demands
for "C" is:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html
7.3.1 LC_CTYPE
blank
# In the POSIX locale, only the and shall be included.
Another point is that setlocale(..., "") if the env vars are unset is
implementation-defined. I'd change it to result not in "C" but in C.UTF-8.
> > • 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?
Yeah, with a non-US time and date format. Possibly also collation where a
space is not ignored -- ie, dictionary order common to most of the world but
not the US -- "foo xxx" < "foobar". C.* does this, en_US.* does not. Even
worse, en_US ignores all (or most) non-letters, inconsistently with other
operating systems and libcs:
glibc:
0 9
0.9.0
0.9.0-a0-foo-bar
({---=[ 0.9.0-a11 ]=---})
0.9.0-a17-quux
(0.9.0-a2)
0.9.0+a99-1
0.9.0-rc1
0.9.1
0 9 9
({---=[ 0.9-a11 ]=---})
0.9 ab
Windows, musl, ...:
(0.9.0-a2)
({---=[ 0.9.0-a11 ]=---})
({---=[ 0.9-a11 ]=---})
0 9
0 9 9
0.9 ab
0.9.0
0.9.0+a99-1
0.9.0-a0-foo-bar
0.9.0-a17-quux
0.9.0-rc1
0.9.1
> As you say, I don't think a country-neutral specifically-English locale
> is going to happen before buster.
On the other hand, adding it but not using by default would probably be a
very good idea: in the future, it'd avoid situations where ssh-ing from one
machine to one running stable would have the default locale fail.
> 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.)
I can't recall any other difference out of the top of my head, yeah.
LC_COLLATE=en_US.UTF-8 has that ignoring space nastiness, though.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄
Bug#874160: systemd _sometimes_ does this
On Thu, Feb 07, 2019 at 03:36:59PM +0100, Adam Borowski wrote: > Turns out systemd independently does this, although not in every case. > If you have unset locale, it changes it to C.UTF-8 for X (gdm3) but not > for console logins. Turns out that console logins are the only exception; ansgar found this: https://github.com/systemd/systemd/issues/11668 > It'd be good to have this consistent both for X vs console, and systemd vs > other inits/rc systems. You said: # Even is the change is small, that might still change the behavior of # some programs, so I am not sure we want to diverge from upstream and # other distributions here. So with systemd forcing this, the result is us diverging from most other distributions only when init/rc is not systemd. Thus, could you please apply this patch -- or, should I bother sysvinit folks (and perhaps implement this in openrc) instead? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#874160: systemd _sometimes_ does this
Turns out systemd independently does this, although not in every case. If you have unset locale, it changes it to C.UTF-8 for X (gdm3) but not for console logins. It'd be good to have this consistent both for X vs console, and systemd vs other inits/rc systems. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?
On Thu, Feb 07, 2019 at 02:55:33PM +0500, Roman Mamedov wrote: > So for those of us (the entire world), who have been relying on this behavior: > > > * en_US (.UTF-8) is used as the default English locale for all places that > > don't have a specific variant (and often even then). Generally, technical > > users use English as a system locale > > How do we roll-back what you have done here, and still get en_US.UTF-8 while > retaining the proper 24-hour time? > dpkg-reconfigure locales does not list "C.UTF-8" in the main "locales to > generate" list, but does offer it on the next screen as "Default locale for > the > system environment". After selecting it, we get: > > # locale > LANG=C.UTF-8 > LANGUAGE= > LC_TIME="en_US.UTF-8" > LC_ALL=en_US.UTF-8 > > But still: > > # date > Thu 07 Feb 2019 09:53:47 AM UTC The root of this issue is worth raising on debian-devel: The en_US.UTF-8 locale has two purposes: • a locale for a silly country with weird customs (such as time going in four discontinuous segments during the day, writing date in a middle-endian format, an unit being shorter on land than surveyed but longer than that in the air, or another unit changing when measuring wet vs dry vs slightly moist things) • base locale for the most of the world save for a few places (UK, AU, ...) that have their specific locale -- and often even they use en_US for consistency reasons. So I wonder what would be the best solution? I can think of: • 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) -- nice for Unix greybeards, but some users might want case-insensitive sort, etc • inventing a new locale "en" without a country bias -- good in the long term but problematic a month before freeze -- could be good to have it anyway but not use it until after buster • ask glibc maintainers to revert the cherry-pick in #877900 for buster, then pick a long-term solution One particular regression caused by this change is sorting no longer working: "12:01am" "1:01am" "12:01pm" "1:01pm" will be ordered wrong. On one hand, leftpondians may be entitled to their own locale. On the other, let's punish the bastards for imperialism and imposing their own settings on the rest of the world. :p Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
[Oy vey, crosspost list from hell -- not sure how to trim...] On Tue, Dec 11, 2018 at 09:46:21PM +0100, Gregor Riepl wrote: > I do think this just reinforces the point that second-class architectures > should have better, more robust support from the Debian project. > For example, arch-specific packages most decidedly have a place in Debian > The build and package delivery infrastructure should offer the same features > for both first and second class archs, including installer image building for > all "tiers" (stable, testing, unstable). It seems to me that the important bit is the testing suite. As a (now lapsed) x32 porter, I tried to implement that on my own (goal being an unofficial, weakly security supported[1] Jessie for x32). And tracking testing on my own proved to be too hard. What directly defeated me were binNMUs: with every arch having its own NMU counter and hidden triggers, this is already a mess. Add NMUs due to private ported packages, and all hell breaks loose. The rest is easy in comparison: a porter team can decide whether to snapshot testing as unofficial stable; point releases are a matter of running a buildd job (and fixing failures), same for security. We'd be able to concentrate on actual arch-specific issues. > The main difference should (IMHO) be the amount of support you get: While a > first-class arch will get faster fixes and a more stable dependency tree, > other archs will be more "sloppy", for example by not blocking stable releases > with their own RC bugs etc. Yeah, a completely one-way relationship: no issue on second-class would block first-class. > If this can be fulfilled, I don't think being a second-class arch will be such > a big deal. Not sure how far Debian is from this goal, but I can understand > that many DDs and DMs would rather invest their time into projects they have a > stake in, rather than hardware they don't (or don't want to?) understand. Yes, x32 suffers from needing obscure and hard to get hardware. :) Meow! [1]. The vast majority of security issues are non arch dependent, so blindly tracking and building first-class security updates gets us nearly all the way, reducing the work to babysitting buildds and looking into FTBFSes or yet another whole-new-language-ecosystem getting allowed into stable. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Bug#874160: Fedora has C.UTF-8
Looks like Fedora has C.UTF-8 now, and even backported this change to their stable releases: https://bugzilla.redhat.com/show_bug.cgi?id=902094 They're not upstream, but a good part of distros that are not downstream from Debian are downstream from Fedora. This availability makes defaulting to C.UTF-8 that more viable. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road? For thousands of years, the ⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the ⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk. To where it came ⠈⠳⣄ together with silk (judging by today's amber stalls).
Bug#882129: libc6: please add "Conflicts: openrc (<< 0.27-2~)" -- system mostly unbootable
Package: libc6
Version: 2.25-1
Severity: important
Hi!
After upgrading libc6 to 2.25-1, most components of openrc segfault on
startup. This is pretty uncool for something that handles init scripts: it
renders the system effectively unbootable (strictly speaking, it boots, init
does its thing, but I for one would prefer hostname set, non-root
filesystems mounted, ssh running -- that sort of things).
Obviously, this is a severity:critical bug in openrc, and it's up to one of
its uploaders to fix it. Which we just did in 0.27-2.
But, that's not enough, as if libc6 is upgraded first (or only, on partial
upgrades), the user will end-up with openrc 0.27-1 but new libc. Thus,
there's a need to prevent such situation. Usually, we add Breaks: but
that's not enough:
• openrc is deconfigured
• libc6 is upgraded
• a daemon tries to stop or restart -- boom!
Thus, the obvious approach is to add "Conflicts: openrc (<< 0.27-2~)" to
libc6 and its arch variants (libc{6.1,0.1,0.3}). I'm not sure that's the
best solution: apt may prefer to instead remove openrc, and some other
upgrade non-nicety is likely to pop up in the future.
Would you have a better idea? If not, please add this Conflicts: stanza.
Meow!
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.0+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Bug#882130: libc6: reportbug script is borked
Package: libc6 Version: 2.25-1 Severity: normal Hi! When trying to "reportbug libc6", the package-specific script loops spewing pages of "E: No packages found" for minutes. The loop is not endless, though, and after some time it continues. But even then, reportbug acts as if libc6 was not installed (manual package selection among those within a pattern match, asking for version number, no list of dependencies, etc). Meow! -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0+ (SMP w/6 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install
On Sat, Oct 07, 2017 at 01:47:30PM -0700, Steve Langasek wrote: > On Sat, Oct 07, 2017 at 07:17:56AM +0200, Adam Borowski wrote: > > Obviously, this is an abuse, but that's the cost of being the default. If > > we had C.UTF-8 as a first-class locale, this wouldn't be that much an > > argument, but currently d-i falls back to en_US for English for most > > countries. > > > The decision belongs to the maintainer (I'm reassigning), but per the above > > reasoning, I expect wontfix. > > No, this is a nonsense argument. The en_US.UTF-8 locale must reflect the > actual usage in the US. "Well, systems use it as a default, so we're going > to overload it" would be idiotic. This is what d-i does, thus such overloading is really widespread at present. I'm not claiming this is a good idea, merely describing status quo. A thoughtless change would risk breaking systems that rely on times being sortable, fitting within current field width, etc. > There's also no reason to believe that's actually what has happened here. > > C.UTF-8 *is* a first-class locale, and if any installers are using > en_US.UTF-8 when they should use C.UTF-8, those installers must be fixed. d-i allows selecting C as locale, but that's real 7-bit C rather than C.UTF-8. As such, it's not really usable in most contexts. Furthermore, if your location is not UK, Ireland or a few others, d-i will default to en_US.UTF-8. > Furthermore, the only bug I'm aware of in this area is the fact that, when > no locale is configured in the environment, glibc falls back to C instead of > to C.UTF-8, despite the fact that this is shipped prebuilt in the libc > package and is always available. I agree here, that would be the natural thing to do. I've even submitted a patch implementing this (#874160), however it hasn't been accepted as the maintainer doesn't want a divergence with upstream. Upstream glibc already has a proposal with this change -- I've tried contacting its proposer but did not receive an answer. I don't know glibc upstream's politics well enough to drive it forward. > As to the actual bug, I don't know if this represents a deliberate change or > if it's accidental. Speaking for myself as an American, I can confirm the > described behavior... and can say that it completely escaped my notice, > because I prefer 24h time whenever given the option. Nevertheless, if this > bug is to be deemed 'wontfix', it must be done solely with respect to what > is correct for the *US* locale. You should have considering this before invading! :p Meow. -- ⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased ⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts. ⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got ⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.
Bug#874160: src:glibc: default locale to C.UTF-8
On Sun, Sep 03, 2017 at 11:54:03PM +0200, Aurelien Jarno wrote: > On 2017-09-03 18:49, Adam Borowski wrote: > > Package: src:glibc > > Version: 2.24-17 > > Severity: wishlist > > Tags: patch > > > > Hi! > > Here's a simple patch set to change the default of setlocale(…, "") to > > C.UTF-8. This is a drastically smaller change than altering the meaning of > > "C" to mean "C.UTF-8" that upstream is mulling over -- it affects only > > programs that already have locale support, when the user fails to set any. > > Even is the change is small, that might still change the behavior of > some programs, so I am not sure we want to diverge from upstream and > other distributions here. > > One example comes to my mind: initializing a postgresql database > cluster. When not using the --locale option this would cause the > database to use a non C locale, which has significant performance > impact. In this case, this will change anyway when (if?) upstream goes forward with their version -- which sounds as if postgresql wants an explicit LC_ALL=C. Doesn't pg_createcluster inherit locale settings from the user who's invoking it (thus usually en_US.UTF-8 or whatever)? Thus, in the vast majority of uses, there's no change, merely a certain way to force the C locate (unset LC_ALL LANG LC_CTYPE LC_...) won't work anymore. As for diverging from upstream, lemme ask the guy behind the upstream proposal wiki page what's the inclusion status. You probably have a wee bit better idea than me about upstream's workings, though. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄
Bug#874160: upstream talk
Re-reading upstream stuff, I see that their proposal for C.UTF-8 differs from ours, and includes having it as the default for setlocale(…, "") -- ie, just what I implemented in this patch. https://sourceware.org/glibc/wiki/Proposals/C.UTF-8 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄
Bug#874160: src:glibc: default locale to C.UTF-8
Package: src:glibc
Version: 2.24-17
Severity: wishlist
Tags: patch
Hi!
Here's a simple patch set to change the default of setlocale(…, "") to
C.UTF-8. This is a drastically smaller change than altering the meaning of
"C" to mean "C.UTF-8" that upstream is mulling over -- it affects only
programs that already have locale support, when the user fails to set any.
If none of LC_ALL, LANG nor LC_CTYPE are set, instead of taking this to mean
"C" we assume "C.UTF-8". This is explicitely allowed by POSIX (an
"implementation-defined default locale"). setlocale(…, "C") or not calling
it at all retain the old meaning[1].
This is the approach already taken by musl.
I'm not submitting this upstream first as C.UTF-8 is still a Debian-specific
thing.
The improvement would be: if for any reason the user fails to set the
locale, a daemon's startup script is too eager clearing its environment,
a build chroot fails to inherit env vars, etc -- in all of these cases we'll
fall back to an UTF-8 locale. Making a locale-aware program use "C" is
still fully possible via setting LC_ALL=C but we won't suffer from non-UTF8
by omission.
This is mostly an one-line patch (1/3), the other two update the testsuite
(2/3) and alter hard-coded output of /usr/bin/locale (3/3).
Meow!
[1]. Making "C" behave like "C.UTF-8" would be, according to my reading,
compliant with both POSIX-2008@2016 and C11 except for a minor iswblank()
weirdness, but this is not a part of this change.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.13.0-rc7-debug-ubsan-00220-g9baeac7d (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From 92d9938c6ba813afaf854d7bc12a9dc0c71371c3 Mon Sep 17 00:00:00 2001
From: Adam Borowski
Date: Sun, 3 Sep 2017 00:26:47 +0200
Subject: [PATCH 1/3] Default to C.UTF-8 on setlocale(..., "") if no env vars
are set.
This doesn't affects programs that are not prepared to handle arbitrary
locales as those either don't call setlocale() at all or use setlocale(...,
"C"); merely programs which would have used a proper locale had the user
set it up.
This provides a decent default when env var configuration is missing, in a
way that's more robust than mucking with login defs and daemon startup
scripts.
A default locale other than "C" is allowed by POSIX; also at least musl
uses an equivalent of C.UTF-8 already.
---
locale/findlocale.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/locale/findlocale.c b/locale/findlocale.c
index 4cb9d5ea8a..2a12b4e808 100644
--- a/locale/findlocale.c
+++ b/locale/findlocale.c
@@ -123,8 +123,12 @@ _nl_find_locale (const char *locale_path, size_t
locale_path_len,
+ _nl_category_name_idxs[category]);
if (!name_present (cloc_name))
cloc_name = getenv ("LANG");
+ /* If no env vars are set, we're free to choose an
+ "implementation-defined default locale":
+
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02
+ */
if (!name_present (cloc_name))
- cloc_name = _nl_C_name;
+ cloc_name = "C.UTF-8";
}
/* We used to fall back to the C locale if the name contains a slash
--
2.14.1
>From 612dc7f67f93882b7acb2f035b1cc200ceb2e153 Mon Sep 17 00:00:00 2001
From: Adam Borowski
Date: Sun, 3 Sep 2017 03:43:10 +0200
Subject: [PATCH 2/3] Adjust the setlocale test suite for C.UTF-8 as default.
---
localedata/bug-setlocale1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/localedata/bug-setlocale1.c b/localedata/bug-setlocale1.c
index 546ea7beb8..2c86e2361d 100644
--- a/localedata/bug-setlocale1.c
+++ b/localedata/bug-setlocale1.c
@@ -39,9 +39,9 @@ do_test (void)
if (d == NULL)
return 1;
- if (strcmp (d, "C") != 0)
+ if (strcmp (d, "C.UTF-8") != 0)
{
- puts ("*** LC_NUMERIC not C");
+ puts ("*** LC_NUMERIC not C.UTF-8");
result = 1;
}
--
2.14.1
>From fb6cc4a418c6278dfc2dcf45bc1ea40e06ef9caf Mon Sep 17 00:00:00 2001
From: Adam Borowski
Date: Sun, 3 Sep 2017 13:43:41 +0200
Subject: [PATCH 3/3] Change hard-coded value for "no defined vars" in
/usr/bin/locale.
---
locale/programs/locale.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/locale/programs/locale.c b/locale/programs/locale.c
index 9da3e5319f..131472766c 100644
--- a/locale/progra
Bug#861026: both kernel and glibc want s64 not long (s32)
> However, this is not. The documentation [2] defines struct timeval's "tv_nsec"
> field as "long int", so %ld is correct. But glibc seems to really define it
> as "__syscall_slong_t tv_nsec", and on x32 __syscall_slong_t appears to be
> "long long int".
> [2] https://www.gnu.org/software/libc/manual/html_node/Elapsed-Time.html
Both kernel and glibc use s64 in their ABI, and the high bits are actually
checked:
.--[ foo.c ]
#include
#include
#include
#include
int main()
{
struct timespec t;
t.tv_sec=1;
t.tv_nsec=0x1;
int ret = nanosleep(&t, 0);
printf("%d %s\n", ret, strerror(errno));
return 0;
}
`
amd64:
-1 Invalid argument
i386:
foo.c: In function ‘main’:
foo.c:10:15: warning: overflow in implicit constant conversion [-Woverflow]
t.tv_nsec=0x1;
^~~
0 Success
x32:
-1 Invalid argument
So no matter what we'd argue as being "correct", there's no changing the ABI
of an architecture that was finalized 5 years ago. Thus, all we can do is
having GNU folks document this.
On your side, I'd do an explicit cast to (int) and "%d" -- even on amd64 the
upper bits must always be 0 (or the kernel responds with -EINVAL).
It'd be interesting to see what's in arm64ilp32, though -- it's an
architecture that's in the same relation to armhf and arm64 as x32 is to
i386 and amd64, and it's about to get merged. Not in the merge window
that'll start in an hour-two from now, but possibly the next.
--
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!
Bug#742965: libc0.1: openpty()/forkpty() fail on kfreebsd >=9.0
On Wed, Apr 02, 2014 at 09:45:23AM +0200, Petr Salinger wrote: > The problem is not the handler for SIGCHLD, but it's content. Yeah, same happens with SA_NOCLDWAIT, it's about whether the child gets reaped. > I doubt that the testcase worked under previous kernels. My bad, I did not test this particular testcase but a larger body of code, with tons of different pty code paths (handling IRIX, old SunOS and such) on different Debian releases, it probably did something else. The small test case behaves the same on 8.x and 9.x. Sorry for undertesting. > The openpty() uses internally fork and waitpid. > The waitpid in the testcase signal handler eats result needed by > openpty implementation. The offending code is in grantpt(), which openpty() calls. I wonder how to fix it. Merely documenting the restriction isn't really an option, as no widespread system has it. Saving the signal handler, disabling it then restoring would work but introduces a slight race condition (a child process can exit while we're in grantpt()). It's interesting what real FreeBSD does. Apparently, grantpt() is a no-op there: http://svnweb.freebsd.org/base/head/lib/libc/stdlib/ptsname.c?view=markup but blindly commenting out the calls to grantpt()+unlockpt() doesn't seem work to for us. Meow! -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140403140650.ga12...@angband.pl
Bug#742965: libc0.1: openpty()/forkpty() fail on kfreebsd >=9.0
Package: libc0.1
Version: 2.18-4
Severity: normal
If a process has a handler for SIGCHLD, openpty() fails on kfreebsd with 9.x
kernels. It worked ok on 8.x, and works on "real" (ie, no glibc) FreeBSD.
A reduced test case attached; when commenting out the sigaction line,
openpty() starts working again.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.2-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc0.1 depends on:
ii libgcc1 1:4.8.2-16
libc0.1 recommends no packages.
Versions of packages libc0.1 suggests:
ii debconf [debconf-2.0] 1.5.52
pn glibc-doc
ii locales2.18-4
-- debconf information:
glibc/upgrade: true
glibc/disable-screensaver:
glibc/restart-services:
glibc/restart-failed:
libraries/restart-without-asking: false
// Link with -lutil
#include
#include
#include
#include
#include
#include
#include
static void sigchild(int dummy)
{
while (waitpid(-1,0,WNOHANG)>0);
}
int main()
{
int master, slave;
struct sigaction act;
sigemptyset(&act.sa_mask);
act.sa_flags=SA_RESTART;
act.sa_handler=sigchild;
sigaction(SIGCHLD,&act,0);
if (openpty(&master, &slave, 0, 0, 0))
{
printf("Failed: %s\n", strerror(errno));
return 1;
}
printf("Ok!\n");
return 0;
}
Bug#687522: locales: please generate locale "$LANG" if debconf fails
Package: locales Version: 2.13-35 Severity: wishlist So I installed a yet another chroot. Stuff inside keeps complaining about the configured locale not being present (the host has en_US.UTF-8, debootstrap doesn't install "locales" by itself). Thus, I go and install it by hand: locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory debconf: delaying package configuration, since apt-utils is not installed Can not write log, openpty() failed (/dev/pts not mounted?) Selecting previously unselected package locales. (Reading database ... 14565 files and directories currently installed.) Unpacking locales (from .../locales_2.13-35_all.deb) ... Can not write log, openpty() failed (/dev/pts not mounted?) Setting up locales (2.13-35) ... locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline Generating locales (this might take a while)... Generation complete. ... yet no locales get generated by default. I need to install "dialog" as well, then "dpkg-reconfigure locales" and find the locale in the long list. It'd be nice if, when debconf fails but $LANG/$LC_* are set, the list of locales to generate defaulted not to empty but to the relevant environment variables. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv6l) Foreign Architectures: i386 Kernel: Linux 3.2.27+ (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.46 ii libc6 [glibc-2.13-1] 2.13-35 locales recommends no packages. locales suggests no packages. -- debconf information: * locales/default_environment_locale: en_US.UTF-8 * locales/locales_to_be_generated: en_GB.UTF-8 UTF-8, en_US.UTF-8 UTF-8 -- 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/20120913123428.10499.62113.reportbug@lorien
Bug#453041: de_LI: syntax error
Hi. You've probably noticed that already, but: when generating all locales, I get: de_DE.UTF-8... done de_DE.ISO-8859-1... done [EMAIL PROTECTED] done de_LI.UTF-8.../usr/share/i18n/locales/de_LI:73: LC_TELEPHONE: syntax error done de_LU.UTF-8... done de_LU.ISO-8859-1... done [EMAIL PROTECTED] done dz_BT.UTF-8... done el_GR.UTF-8... done -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363442: libc6-xen should not conflict with any other libc6-$flavor
On Fri, Apr 21, 2006 at 02:15:16PM +0200, Gabor Gombas wrote: > On Wed, Apr 19, 2006 at 01:02:59PM -0500, Adam Heath wrote: > > I'm ready to upload xen 3.0.2, with a dependency on libc6-xen. > > IMHO just go ahead with the upload :-) The removal of the other > optimized flavors due to the conflict with libc6-xen should only cause > some performance regression when you boot a non-xen kernel, it should ^^ > not have any effect on usability. Is the part about performance regression actually true? I've spent quite a bit of time trying to find a test case where the difference could be measureable, and failed. I'm not knowledgeable about TLS issues, but it appears that the slowdown is on the rate on one CPU cycle per some glibc calls -- way below any reasonable threshold, and certainly not enough to warrant the extra disk space and confusion. So, what about dropping libc6-xen and simply rebuilding libc6-i686 with -mno-tls-direct-seg-refs? Both packages are identical otherwise; they could be merged with a Provides: clause. Cheers and schtuff, -- 1KB // Q: How do you spot a good inetd? // A: It build-depends on equivs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
