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 *_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?

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 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?

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 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

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 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

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!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ 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?

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, 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

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 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

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 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

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, 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

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 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

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 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

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 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

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 technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 



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

2017-09-03 Thread Adam Borowski
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 <kilob...@angband.pl>
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 <kilob...@angband.pl>
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 <kilob...@angband.pl>
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/lo

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] 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(, 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

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 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

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 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  none
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 stdio.h
#include pty.h
#include string.h
#include errno.h
#include sys/types.h
#include sys/wait.h
#include signal.h

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

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 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

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
  [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

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 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]