> However, this is not. The documentation  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".
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
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
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
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.
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced
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 t
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,
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
Looks like Fedora has C.UTF-8 now, and even backported this change to their
They're not upstream, but a good part of distros that are not downstream
from Debian are downstream from Fedora. This availability makes defaulting
[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
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 exceptio
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
> is rarely an effecti
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:
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,
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.
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
Hi. You've probably noticed that already, but: when generating all locales,
[EMAIL PROTECTED] done
de_LI.UTF-8.../usr/share/i18n/locales/de_LI:73: LC_TELEPHONE: syntax error
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
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
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
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
I doubt that the testcase worked under previous kernels.
My bad, I did not test this
Mail list logo