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
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
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
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 pa
> 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/man
x27;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 (
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 t
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
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
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 instal
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
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.fedoraprojec
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
[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 p
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, te
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
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[1]
> is rarely an ef
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
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 *_t
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
21 matches
Mail list logo
