Bug#861026: both kernel and glibc want s64 not long (s32)

2017-04-23 Thread Adam Borowski
> 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]

Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install

2017-10-07 Thread Adam Borowski
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

Bug#874160: src:glibc: default locale to C.UTF-8

2017-09-03 Thread Adam Borowski
itectures: 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

Bug#874160: upstream talk

2017-09-03 Thread Adam Borowski
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

Bug#874160: src:glibc: default locale to C.UTF-8

2017-09-03 Thread Adam Borowski
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

Bug#882129: libc6: please add "Conflicts: openrc (<< 0.27-2~)" -- system mostly unbootable

2017-11-19 Thread Adam Borowski
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,

Bug#882130: libc6: reportbug script is borked

2017-11-19 Thread Adam Borowski
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

Bug#874160: Fedora has C.UTF-8

2018-11-06 Thread Adam Borowski
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

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

2018-12-11 Thread Adam Borowski
[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

Bug#874160: systemd _sometimes_ does this

2019-02-07 Thread Adam Borowski
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

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

2019-02-07 Thread Adam Borowski
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 effecti

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

2019-02-07 Thread Adam Borowski
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

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

2019-02-07 Thread Adam Borowski
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,

Bug#874160: systemd _sometimes_ does this

2019-02-07 Thread Adam Borowski
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! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁

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

2019-07-19 Thread Adam Borowski
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

Bug#453041: de_LI: syntax error

2007-11-29 Thread Adam Borowski
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

Bug#363442: libc6-xen should not conflict with any other libc6-$flavor

2006-07-26 Thread Adam Borowski
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

Bug#687522: locales: please generate locale $LANG if debconf fails

2012-09-13 Thread Adam Borowski
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

Bug#742965: libc0.1: openpty()/forkpty() fail on kfreebsd =9.0

2014-03-29 Thread Adam Borowski
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

Bug#742965: libc0.1: openpty()/forkpty() fail on kfreebsd =9.0

2014-04-03 Thread Adam Borowski
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