Bug#932384: libc6: utmp broken

2019-07-19 Thread Thorsten Glaser
Aurelien Jarno dixit:

[ explanations ]
>Therefore there is no bug, neither in glibc nor in the manpage. Closing
>it.

Agreed. Thank you for reviewing the problem, though.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)



Bug#932384: libc6: utmp broken

2019-07-18 Thread Thorsten Glaser
On Thu, 18 Jul 2019, Thorsten Glaser wrote:

> glibc maintainers: unsure why screen works but not the example
> code given that screen isn’t sgid… maybe you should have a look
> at that, it still doesn’t work with the correct utmp permissions.

This might also be a bug in the example program; if so, reassign
to manpages-dev (= 5.01-1), cf. #932382

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**



Re: Bug#932384: libc6: utmp broken

2019-07-18 Thread Thorsten Glaser
reassign 932380 initscripts
found 932380 2.95-1
notfound 932380 2.93-8
retitle 932380 initscripts: /etc/init.d/bootmisc.sh: wrong /var/run/utmp 
permissions
severity 932380 important
unblock 932380 by 932384
block 932384 by 932380
thanks

On Thu, 18 Jul 2019, Thorsten Glaser wrote:

> After hitting #932380

I’ve had a look at what was recently updated, found initscripts
as something that matches a recursive grep for utmp in /etc, and
sure, the diff between 2.93-8 and 2.95-1 in etc/init.d/bootmisc.sh
contains this:

-   chmod 664 /var/run/utmp
+   chmod 644  "${utmp}" || log_warning_msg "failed to chmod 
${utmp}"

So there we are.

Dmitry: please also move the chmod BELOW the chown, as chown
is known to sometimes reset permissions (in some documented
cases, not a bug):

tglase@tglase:~ $ diff -u /etc/init.d/bootmisc.sh bootmisc.sh
--- /etc/init.d/bootmisc.sh 2019-05-15 13:03:46.0 +0200
+++ bootmisc.sh 2019-07-18 17:51:51.887830376 +0200
@@ -33,8 +33,8 @@
 
readonly utmp='/var/run/utmp'
if > "${utmp}" ; then
-   chmod 644  "${utmp}" || log_warning_msg "failed to chmod 
${utmp}"
chgrp utmp "${utmp}" || log_warning_msg "failed to chgrp 
${utmp}"
+   chmod 664  "${utmp}" || log_warning_msg "failed to chmod 
${utmp}"
return 0
else
log_failure_msg "failed to truncate ${utmp}"

XTaran: after “sudo chmod 664 /var/run/utmp” GNU screen works as
intended again, closing your bug.

glibc maintainers: unsure why screen works but not the example
code given that screen isn’t sgid… maybe you should have a look
at that, it still doesn’t work with the correct utmp permissions.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**



Re: Bug#932384: libc6: utmp broken

2019-07-18 Thread Thorsten Glaser
On Thu, 18 Jul 2019, Thorsten Glaser wrote:

> utmp entries cannot be added (and the GNU screen source code contains
> curse^Wcomplaints about the GNU API for utmp lacking the ability to
> return success/error information, so the applications cannot even de‐
> tect this!), while the file is set up correctly:

After some more experimentation:

• this affects buster(!)
• it works as root but not as regular user

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**



Bug#932384: libc6: utmp broken

2019-07-18 Thread Thorsten Glaser
Package: libc6
Version: 2.28-10
Severity: important

After hitting #932380 I looked at the source code of GNU screen,
saw it uses the getutline(3) function, and compiled the example
from its manpage.

The output is not what I expected:

tglase@tglase:~ $ ./a.out
before adding entry:
tglase   :0   2019-07-18 16:07
after adding entry:
tglase   :0   2019-07-18 16:07
after removing entry:
tglase   :0   2019-07-18 16:07

This is the same, no matter whether I’m in GNU screen in xterm,
or just in xterm, or even on the Linux text console:

tglase@tglase:~ $ ./a.out
before adding entry:
tglase   tty2 2019-07-18 17:25
tglase   :0   2019-07-18 16:07
after adding entry:
tglase   tty2 2019-07-18 17:25
tglase   :0   2019-07-18 16:07
after removing entry:
tglase   tty2 2019-07-18 17:25
tglase   :0   2019-07-18 16:07

utmp entries cannot be added (and the GNU screen source code contains
curse^Wcomplaints about the GNU API for utmp lacking the ability to
return success/error information, so the applications cannot even de‐
tect this!), while the file is set up correctly:

tglase@tglase:~ $ ll /var/run/utmp
-rw-r--r-- 1 root utmp 4608 Jul 18 17:26 /var/run/utmp
tglase@tglase:~ $ w | cat
 17:27:33 up  1:21,  1 user,  load average: 1.35, 1.68, 2.12
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
tglase   :0   -16:07   ?xdm?  14:24   0.03s 
/usr/bin/ck-launch-session /usr/bin/monkeysphere-validation-agent /bin/mksh 
/usr/share/tarent/autokde.d/loadenv.sh icewm-session


-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)


Bug#923067: libc0.1: missing UTIME_OMIT for utimensat(2) and futimens(2)

2019-02-24 Thread Thorsten Glaser
On Sat, 23 Feb 2019, Thorsten Glaser wrote:

> then give-back src:pax on both kfreebsd architectures.

In the meantime, I had to do a pax upload to fix bugs anyway,
so I just added a configure-time check for UTIME_OMIT, so it
built now, although not using utimensat/futimes. In case you
wonder…

bye,
//mirabilos
-- 
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
   veni, vidi, fixi(t) ;-)



Bug#923067: libc0.1: missing UTIME_OMIT for utimensat(2) and futimens(2)

2019-02-23 Thread Thorsten Glaser
Package: libc0.1
Version: 2.25-2
Severity: normal

glibc on Debian GNU/kFreeBSD is missing UTIME_OMIT, making src:pax
FTBFS. While I could work around this by using the older functions,
https://www.freebsd.org/cgi/man.cgi?query=utimensat indicates that
the FreeBSD kernel has gained native support for that in 10.3, which
incidentally is the version in Debian.

So, please add that to the headers, then give-back src:pax on both
kfreebsd architectures.

Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 10.3-0-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc0.1 depends on:
ii  libgcc1  1:8.2.0-21

libc0.1 recommends no packages.

Versions of packages libc0.1 suggests:
ii  debconf [debconf-2.0]  1.5.70
pn  glibc-doc  
ii  libc-l10n  2.25-2
ii  locales2.25-2

-- debconf information:
  glibc/disable-screensaver:
  glibc/restart-services:
  glibc/kernel-too-old:
  glibc/kernel-not-supported:
* libraries/restart-without-asking: false
  glibc/upgrade: true
  glibc/restart-failed:



Bug#873097: glibc: FTBFS on *all* architectures except m68k, powerpcspe, sh4

2017-08-24 Thread Thorsten Glaser
Source: glibc
Version: 2.24-16
Severity: serious
Justification: fails to build from source (but built successfully in the past)

cf. https://buildd.debian.org/status/package.php?p=glibc

For over three days now, src:glibc is FTBFS’ing virtually everywhere:

amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el,
s390x, alpha, hppa, hurd-i386, kfreebsd-amd64, kfreebsd-i386, powerpc,
ppc64, sparc64, x32 — the list is so long it doesn’t fit into the
bugreport’s Subject.

Causa seems to be something about the expected testsuite failures
having been adjusted in the last upload, which is probably why the
three slow architectures have been spared.


Bug#868153: glibc: FTBFS on x32: tst-getaddrinfo5 (tries to use the network), tst-robust8 (unknown)

2017-07-12 Thread Thorsten Glaser
On Wed, 12 Jul 2017, Thorsten Glaser wrote:

> An extra data point:
> 
> (pbuild18806-dpo)root@tglase:/tmp/buildd/glibc-2.24 # 
> ./build-tree/x32-libc/nptl/tst-robust8
> 
> This reproducibly (several times in a row) terminates after
> about one second with errorlevel 0 so I have no idea what
> in this test supposedly fails.

Ah, one out of ten did not, it terminated with:

Timed out: killed the child process

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg



Bug#868153: glibc: FTBFS on x32: tst-getaddrinfo5 (tries to use the network), tst-robust8 (unknown)

2017-07-12 Thread Thorsten Glaser
An extra data point:

(pbuild18806-dpo)root@tglase:/tmp/buildd/glibc-2.24 # 
./build-tree/x32-libc/nptl/tst-robust8

This reproducibly (several times in a row) terminates after
about one second with errorlevel 0 so I have no idea what
in this test supposedly fails.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg



Bug#826256: locales: wrong width for hexagrams (and possibly others) in 2.22

2017-07-11 Thread Thorsten Glaser
tags 826256 = upstream
forwarded 826256 https://sourceware.org/bugzilla/show_bug.cgi?id=21750
thanks

OK, I’ve forwarded this upstream and refreshed the researched data:
https://sourceware.org/bugzilla/show_bug.cgi?id=21750

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg



Re: Bug#849923: openssh-server: no login possible after upgrade on x32

2017-01-03 Thread Thorsten Glaser
On Mon, 2 Jan 2017, Aurelien Jarno wrote:

> Looking at the issue, it actually appears in __vdso_clock_gettime, which
> is provided by the kernel. This code handle the simple cases (REALTIME, 
> MONOTONIC, REALTIME_COARSE and _MONOTONIC_COARSE) and fallbacks to 
> the syscall in otherwise, CLOCK_BOOTTIME in the case of sshd.

Ouch – and the kernel probably thinks it’s getting away with this as
the kernel architecture is amd64…

Can you please forward this to someone at the kernel side (either Debian
or upstream) who can have a look? In the meantime, I’ll point this issue
out in #debian-x32 on IRC, so the other porters can also look.

> On 2017-01-02 17:49, Colin Watson wrote:

> > sshd's seccomp sandbox is denying a clock_gettime call.  But it's more

Probably a stupid idea, but a short-term stopgap: can we disable seccomp
on x32 for now? That needs:

• in debian/rules:
+confflags += --host=${DEB_HOST_GNU_TYPE}
  This sets $host to x86_64-pc-linux-gnux32 instead of the
  auto-detected x86_64-pc-linux-gnu (which is amd64)

• in configure.ac:
 AC_MSG_CHECKING([for seccomp architecture])
 seccomp_audit_arch=
 case "$host" in
+x86_64-*-gnux32)
+   # disabled for now, see Debian #849923
+   ;;
 x86_64-*)
seccomp_audit_arch=AUDIT_ARCH_X86_64
;;

With this, we can then also later fix the architecture, should
the kernel be fixed.

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg



Bug#826256: locales: wrong width for hexagrams (and possibly others) in 2.22

2016-06-03 Thread Thorsten Glaser
Aurelien Jarno dixit:

>EastAsian.txt explicitly lists the hexagrams as neutral width, so I don't

Yes it does, but neutral does NOT always mean 1. I even looked
it up today, as I was not familiar enough with neutral yet.

>Looking at the behaviour from other systems, freebsd and netbsd both
>return -1 here, while openbsd returns 1. None of them returns 2.

-1 is utterly wrong, it’s returned for a control character… likely
missing locale support. The last time I looked at OpenBSD, they did
not have any support for anything resembling UTF-8 either, but from
what I’ve heard, they’re working on changing it.

>Therefore, can you please give a pointer explaining while the width
>should be 2 instead of 1?

I can give two pointers.

One being the presence of 4DC0 (et al.) in src:unifont (= 1:8.0.01-1)
in font/plane00/unifont-base.hex as a fullwidth (“wide”, in Unicode
speak; as I learnt today, UAX #11 “fullwidth” is a subset of “wide”
that only applies when it has a “ decomposition”) character,
i.e. one with 64 nybbles, like 3000, and unlike 0041.

Two being src:xterm (= 324-2) wcwidth.c, the function mk_wcwidth has
codepoints 2E80‥0xA4CF, excluding 303F, as wide.

The xterm argument is actually extremely strong – it’s t̲h̲e̲ single
most widespeadly used wcwidth() implementation, copied into lots
of code that doesn’t (or can’t) rely on the system’s implementation.

Similarily, GNU libutf8 uses (relevant part of the if construct):
|| (c >= 0x2e80 && c < 0xa4d0  /* CJK ... Yi */
&& !((c & ~0x0011) == 0x300a || c == 0x303f))

This is almost the same as xterm, with the additional exception of
300A, 300B, 301A, 301B added (which I contest, they are W(ide) in
a random EastAsianWidth file I’ve got lying around, but that’s a
different topic and correct in glibc already anyway).

AFAICT glibc currently has Unicode 7.0.0 data in use. When I run
my script on UCD+EAW 7.0.0, I get the following output. The format
is: bsearch form, i.e. a list of (low, high) tuples; the code first
checks for NUL, DEL, C0 and C1 control characters, then bsearches
mb_ucs_combining, then mb_ucs_fullwidth, and if it’s still not found,
the width is 1 (UAX #11 “ambiguous” is assumed narrow):

static const struct mb_ucsrange mb_ucs_combining[] = {
{ 0x0300, 0x036F },
{ 0x0483, 0x0489 },
{ 0x0591, 0x05BD },
{ 0x05BF, 0x05BF },
{ 0x05C1, 0x05C2 },
{ 0x05C4, 0x05C5 },
{ 0x05C7, 0x05C7 },
{ 0x0600, 0x0605 },
{ 0x0610, 0x061A },
{ 0x061C, 0x061C },
{ 0x064B, 0x065F },
{ 0x0670, 0x0670 },
{ 0x06D6, 0x06DD },
{ 0x06DF, 0x06E4 },
{ 0x06E7, 0x06E8 },
{ 0x06EA, 0x06ED },
{ 0x070F, 0x070F },
{ 0x0711, 0x0711 },
{ 0x0730, 0x074A },
{ 0x07A6, 0x07B0 },
{ 0x07EB, 0x07F3 },
{ 0x0816, 0x0819 },
{ 0x081B, 0x0823 },
{ 0x0825, 0x0827 },
{ 0x0829, 0x082D },
{ 0x0859, 0x085B },
{ 0x08E4, 0x0902 },
{ 0x093A, 0x093A },
{ 0x093C, 0x093C },
{ 0x0941, 0x0948 },
{ 0x094D, 0x094D },
{ 0x0951, 0x0957 },
{ 0x0962, 0x0963 },
{ 0x0981, 0x0981 },
{ 0x09BC, 0x09BC },
{ 0x09C1, 0x09C4 },
{ 0x09CD, 0x09CD },
{ 0x09E2, 0x09E3 },
{ 0x0A01, 0x0A02 },
{ 0x0A3C, 0x0A3C },
{ 0x0A41, 0x0A42 },
{ 0x0A47, 0x0A48 },
{ 0x0A4B, 0x0A4D },
{ 0x0A51, 0x0A51 },
{ 0x0A70, 0x0A71 },
{ 0x0A75, 0x0A75 },
{ 0x0A81, 0x0A82 },
{ 0x0ABC, 0x0ABC },
{ 0x0AC1, 0x0AC5 },
{ 0x0AC7, 0x0AC8 },
{ 0x0ACD, 0x0ACD },
{ 0x0AE2, 0x0AE3 },
{ 0x0B01, 0x0B01 },
{ 0x0B3C, 0x0B3C },
{ 0x0B3F, 0x0B3F },
{ 0x0B41, 0x0B44 },
{ 0x0B4D, 0x0B4D },
{ 0x0B56, 0x0B56 },
{ 0x0B62, 0x0B63 },
{ 0x0B82, 0x0B82 },
{ 0x0BC0, 0x0BC0 },
{ 0x0BCD, 0x0BCD },
{ 0x0C00, 0x0C00 },
{ 0x0C3E, 0x0C40 },
{ 0x0C46, 0x0C48 },
{ 0x0C4A, 0x0C4D },
{ 0x0C55, 0x0C56 },
{ 0x0C62, 0x0C63 },
{ 0x0C81, 0x0C81 },
{ 0x0CBC, 0x0CBC },
{ 0x0CBF, 0x0CBF },
{ 0x0CC6, 0x0CC6 },
{ 0x0CCC, 0x0CCD },
{ 0x0CE2, 0x0CE3 },
{ 0x0D01, 0x0D01 },
{ 0x0D41, 0x0D44 },
{ 0x0D4D, 0x0D4D },
{ 0x0D62, 0x0D63 },
{ 0x0DCA, 0x0DCA },
{ 0x0DD2, 0x0DD4 },
{ 0x0DD6, 0x0DD6 },
{ 0x0E31, 0x0E31 },
{ 0x0E34, 0x0E3A },
{ 0x0E47, 0x0E4E },
{ 0x0EB1, 0x0EB1 },
{ 0x0EB4, 0x0EB9 },
{ 0x0EBB, 0x0EBC },
{ 0x0EC8, 0x0ECD },
{ 0x0F18, 0x0F19 },
{ 0x0F35, 0x0F35 },
{ 0x0F37, 0x0F37 },
{ 0x0F39, 0x0F39 },
{ 0x0F71, 0x0F7E },
{ 0x0F80, 0x0F84 },
{ 0x0F86, 0x0F87 },
{ 0x0F8D, 0x0F97 },
{ 0x0F99, 0x0FBC },
{ 

Bug#826256: locales: wrong width for hexagrams (and possibly others) in 2.22

2016-06-03 Thread Thorsten Glaser
Package: locales
Version: 2.22-0experimental0
Severity: normal
Tags: upstream

Starting with locales 2.22-0experimental0, some chars have the wrong
width; downgrading locales to 2.21-9 fixes the bugs.

Test program:

tglase@tglase:~ $ cat x.c
#define _XOPEN_SOURCE
#include 
#include 
#include 

#define D(x) printf("%04X %d\n",(x),wcwidth(x))

int
main(void)
{
setlocale(LC_ALL, "");

D(0x41);
D(0x0300);
D(0x3000);
D(0x4DC0);
D(0xFFFD);
return (0);
}
tglase@tglase:~ $ gcc x.c
tglase@tglase:~ $ rm -rf tloc; mkdir tloc   
   
tglase@tglase:~ $ localedef -i en_US -c -f UTF-8 tloc/en_US.UTF-8   
   
tglase@tglase:~ $ LOCPATH=$PWD/tloc LC_ALL=en_US.UTF-8 ./a.out  
   
0041 1
0300 0
3000 2
4DC0 1
FFFD 1

Output while locales_2.21-9_all.deb was installed during localedef:

tglase@tglase:~ $ LOCPATH=$PWD/tlocx LC_ALL=en_US.UTF-8 ./a.out 
   
0041 1
0300 0
3000 2
4DC0 2
FFFD 1

This is because /usr/share/i18n/charmaps/UTF-8.gz now lacks
entries for 4DC0‥4FFF.

According to my own code implementing Unicode in another operating
system, with focus on wcwidth(3), after parsing EastAsianWidth.txt
special handling is needed to set widths of 0xFF00, 0x3248‥0x324F,
and 0x4DC0‥0x4DFF to “wide”, as they’re “neutral” normally – which
can be either – but display on a fixed-width terminal is otherwise
impossible. (Chars outside the BMP were not considered – there may
be others needing such handling… personally, I’d consider at least
all emouji need to be fullwidth but there’s no standard backing it
yet.)

Rationale here: compatibility with wcwidth(3) implementations such
as the one in xterm. (I’ve done the code in MirBSD to generate the
data for my new wcwidth(3) implementation carefully so that – when
using the same Unicode version as Markus Kuhn did – both implemen‐
tations return the same width for all characters.)

This is especially important as I happen to use ䷐ (U+4DD0) for UI
elements, and now all I get is a half-width replacement character,
due to X11 font selection choosing the half-width font part, for a
full-width character cell with an empty right half.

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc-bin   2.22-10
ii  libc-l10n  2.22-10

locales recommends no packages.

locales suggests no packages.

-- debconf information:
  locales/locales_to_be_generated:
  locales/default_environment_locale: None



Bug#803144: apt-listchanges: changelogs for tglase.lan.tarent.de

2016-02-02 Thread Thorsten Glaser
On Tue, 2 Feb 2016, root wrote:

> tzdata (2016a-1) unstable; urgency=medium

>   * Change /etc/timezone into a symlink (closes: #803144)

You mean /etc/localtime, hopefully?!

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg



Bug#775179: libc-bin: C.UTF-8 locale has wrong time format

2015-01-12 Thread Thorsten Glaser
Package: libc-bin
Version: 2.19-13
Severity: normal

I’m puzzling a bit, and was searching for a locale with
ISO 8601 time, to set my LC_TIME to. During that, I found:

tglase@tglase:~ $ LC_TIME=en_GB.UTF-8 date +'%x %X'
12/01/15 10:28:01
tglase@tglase:~ $ LC_TIME=en_US.UTF-8 date +'%x %X'
01/12/2015 10:28:05 AM
tglase@tglase:~ $ LC_TIME=C.UTF-8 date +'%x %X'
01/12/2015 10:30:17
tglase@tglase:~ $ LC_TIME=C date +'%x %X'
01/12/15 10:30:19
tglase@tglase:~ $ ssh tglase-bsd date +'%x %X'
01/12/15 09:30:28

The last one is for verification (C is correct, C.UTF-8 isn’t);
the host has only the C locale but a different timezone, hence
the output.

-- System Information:
Debian Release: 8.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libc-bin depends on:
ii  libc62.19-13
ii  libcap2  1:2.24-6

libc-bin recommends no packages.

libc-bin suggests no packages.

-- no debconf information


-- 
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/20150112093606.4216.63240.report...@tglase.lan.tarent.de



Re: Time zone data for OpenJDK 8

2014-08-15 Thread Thorsten Glaser
On Fri, 15 Aug 2014, Emmanuel Bourg wrote:

 Why not, but the compiler for the old format isn't provided by
 openjdk-8, so we'll have another issue when openjdk-7 is removed
 (probably in Jessie+1). The old compiler would have to be copied into

Eh, just do that before the freeze if you don’t manage to
do #5 before the freeze, and then do #5 immediately after
the freeze, and do *not* copy the old compiler.


On Thu, 14 Aug 2014, Russ Allbery wrote:

 That isn't all that many zones.  I wonder if tz upstream would be willing
 to take those zones to avoid the divergence between Java and everyone

I think they do.

 That would require relicensing that file to not be under the GPL, but
 looking at the file I'm quite dubious it's even copyrightable.

They are not copyrightable, is also the stance of upstream.

In case of doubt: just describe, human-readably, what those
old timezones did, and someone can write a tz definition for
upstream from that. But I am sure this is not needed here.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in Notes on Programming in C


--
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/alpine.deb.2.11.1408150930260.23...@tglase.lan.tarent.de



Re: Time zone data for OpenJDK 8

2014-08-08 Thread Thorsten Glaser
On Fri, 8 Aug 2014, Emmanuel Bourg wrote:

 5. Implement a java.time.zone.ZoneRulesProvider [3] that reads the TZif2
 files installed by the tzdata package in /usr/share/zoneinfo. This would
 render the tzdata-java package obsolete in the long term. GNU ClassPath
 has a TZif2 parser [4] that could be used as a starting point.

Yay for this!

I have always wondered why Java, PHP, PostgreSQL, etc. have their
own timezone information instead of using the system’s. If you can
feed it upstream, even more +1 for you ☺

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
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/alpine.deb.2.11.1408080850140.21...@tglase.lan.tarent.de



Bug#722348: eglibc: ld-linux-x32.so segfaulting in jessie/sid

2014-04-08 Thread Thorsten Glaser
Source: eglibc
Version: 2.18-4
Followup-For: Bug #722348

Hi *,

these messages are due to the inclusion of x32 in parts of Debian
combined with the refusal of the Debian Linux Kernel team to add
x32 support.

Independent of the question of whether such support should be added
or not, it is inacceptable that a standard Debian system configuration
produces segfault output in dmesg and files such as /core upon package
installation/upgrades.

I think this could be fixed by the kernel returning ENOEXEC instead
of segfaulting, if it encounters an x32 binary but has no x32 support.
For this reason, I’d suggest reassigning this bug to src:linux to the
src:eglibc maintainers.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh


-- 
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/20140408114428.16170.9625.report...@tglase.lan.tarent.de



Re: eglibc 2.18 (m68k)

2014-01-19 Thread Thorsten Glaser
Dixi quod…

Adam Conrad dixit:

This would be much more useful to us if it hadn't been built with
DEB_BUILD_OPTIONS=nocheck, so we could see what the state of the
testsuite was.  But nice that it builds at all, I guess. :)

Mh. I can do that next time.

Done:

https://www.freewrt.org/~tg/sink/eglibc_2.18-0experimental1_m68k.build2.xz

bye,
//mirabilos
-- 
„Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit
der Aufschrift Ostdeutsche Eisenbahn durch Wuppertal. Ich glaubs machmal
nicht…“ -- Natureshadow, per SMS
„Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x


--
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/pine.bsm.4.64l.1401191304480.4...@herc.mirbsd.org



Re: eglibc 2.18 (m68k)

2014-01-16 Thread Thorsten Glaser
Adam Conrad dixit:

This would be much more useful to us if it hadn't been built with
DEB_BUILD_OPTIONS=nocheck, so we could see what the state of the
testsuite was.  But nice that it builds at all, I guess. :)

Mh. I can do that next time. Is there a way to run the tests
independent of the package builds, anyway?

Otherwise, well, it’s for experimental, so… sure. Will do.

bye,
//mirabilos
-- 
 Wish I had pine to hand :-( I'll give lynx a try, thanks.

Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine


--
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/pine.bsm.4.64l.1401160806370.2...@herc.mirbsd.org



eglibc 2.18 (was Re: gcc-4.9 uploaded to experimental)

2014-01-15 Thread Thorsten Glaser
Dixi quod…

Yunqiang Su dixit:

On Fri, Jan 10, 2014 at 7:23 PM, Matthias Klose d...@debian.org wrote:
 gcc-4.9 is uploaded to experimental, asking the porters to watch for build
 failures and corresponding patches. See

The build log on mips64el can be found from:
  http://mips64el.debian.net/attempted/gcc-4.9-mips64el.log.xz

m68k took a little longer, the full build log (cowbuilder, up-to-date
sid chroot, “nocheck”) is here:
http://www.freewrt.org/~tg/sink/gcc-4.9_4.9-20140109-1_m68k.build.xz

Tackling eglibc from experimental next… (we don’t have any buildds
for experimental, but I’ve got machines I can’t quickly make into
buildds, so cowbuilder it is).

Et voilà, here you are:

https://www.freewrt.org/~tg/sink/eglibc_2.18-0experimental1_m68k.build.xz


Debian Ports Archive Maintainer dixit:

Maintainer: Thorsten Glaser t...@mirbsd.de
Uploader: Thorsten Glaser (no PGP/MIME please, use Inline OpenPGP instead)=
 t...@mirbsd.org
Host: leda.debian.net
Accepted: eglibc_2.18-0experimental1_m68k.changes
Files:
libc6_2.18-0experimental1_m68k.deb
libc6-dev_2.18-0experimental1_m68k.deb
libc6-pic_2.18-0experimental1_m68k.deb
libc-bin_2.18-0experimental1_m68k.deb
libc-dev-bin_2.18-0experimental1_m68k.deb
multiarch-support_2.18-0experimental1_m68k.deb
libc6-prof_2.18-0experimental1_m68k.deb
locales-all_2.18-0experimental1_m68k.deb
nscd_2.18-0experimental1_m68k.deb
libc6-dbg_2.18-0experimental1_m68k.deb
libc6-udeb_2.18-0experimental1_m68k.udeb
libnss-dns-udeb_2.18-0experimental1_m68k.udeb
libnss-files-udeb_2.18-0experimental1_m68k.udeb


--
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/pine.bsm.4.64l.1401151805220.2...@herc.mirbsd.org



Bug#714219: libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking software

2013-07-31 Thread Thorsten Glaser
retitle 714219 libc6: crypt(3) returns NULL with EINVAL instead of falling back 
to DES, breaking lots of software
thanks

As seen on LWN: xlock can crash due to this, leaving
the screen unlocked.

At this point I feel confirmed in requesting that, no
matter what would actually be the “correct” action, a
defensive patch to revert to the old behaviour (and,
maybe, syslog) is urgently needed to be deployed. Who
knows what else lurks.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Mancke


--
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/alpine.deb.2.10.1307311600260.5...@tglase.lan.tarent.de



Bug#714219: #714219 - libc6: crypt(3) returns NULL… told you so

2013-07-19 Thread Thorsten Glaser
On Thu, 18 Jul 2013, Carlos O'Donell wrote:

* CVE-2013-4122: Handle NULL returns from glibc 2.17+ crypt()
  (Closes: #716835)

 I'm happy to see applications being fixed to follow the 
 documented standard.

Which is a violation of historic practice and “common law”.

I’d be as happy to see the documented standard fixed.

Oh well. I uploaded a new cvs package to Debian sid
yesterday that handles NULL returns as well (review
of that diff is welcome, ofc), but IMHO the greater
issue remains.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!


--
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/alpine.deb.2.10.1307190921230.30...@tglase.lan.tarent.de



Bug#714219: #714219 - libc6: crypt(3) returns NULL… told you so

2013-07-18 Thread Thorsten Glaser
Told you so…

-- Forwarded message --
Subject: apt-listchanges: changelogs for tglase.lan.tarent.de

cyrus-sasl2 (2.1.25.dfsg1-14) unstable; urgency=low

  * CVE-2013-4122: Handle NULL returns from glibc 2.17+ crypt()
(Closes: #716835)


--
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/alpine.deb.2.10.1307181210350.25...@tglase.lan.tarent.de



Re: [Debian #714219] libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software

2013-07-02 Thread Thorsten Glaser
Alexandre Oliva dixit:

fault.  In general, the former is more desirable; consider how much
headscratching would ensue should a password mysteriously fail to be
recognized, compared with that resulting from a segfault for
dereferencing the result of crypt.

Hrm.

On the other hand… is it possible to spew a warning somewhere,
for a couple of releases, and *then* switch to NULL? Heresy,
but might be interesting.

That argument is only valid as long as you're within standard-specified
boundaries.  The standard specifies a limited alphabet for the salt, and
if you pass in arguments that don't satisfy the specified requirements,
all best are off as far as the standard is concerned.

Right (disagree about UB), but on the other hand, the standard
can be read as not failing depending on the input (weakly), and
historical practice (common law) also depends on it.

Indeed, once we frame the situation as “POSIX crypt implements DES”, and
combine that with “FIPS mandates no DES”, the only possible outcome of

That, now, is an interesting reading of the standard (but of
course only applicable for FIPS-enabled systems) ☺

Now, once you bring extensions to the standard into the picture, then
the requirements from the standard are no longer strictly applicable.

Right, but there’s still the deviation from historical practice
of one or probably (didn’t look) even two or more decades, *and*
the knowledge it *will* change the behaviour of well-known soft‐
ware, such as GNU CVS, *and* even the standard-provided example
of how to use crypt() does not check for NULL, so it was clearly
thought to be a situation to never occur on a system in practice.

salt characters that are outside the POSIX mandated alphabet.  Under the
“undefined behavior” rule in the standard, it is perfectly acceptable

I think it’s more like implementation-defined behaviour: it’s
not acceptable for crypt() to run system(rm -rf ~ /); in those
cases, which *is* for ISO C UB.

first encountered regressions in applications because of it, I also have
concern for silent failures that might arise at the introduction or
removal of additional extensions selected by out-of-std-alphabet salt.

I personally think that the confusing “failure to log a specific
user in” is safer than the “crashes the entire dæmon” mode.

(Although pserver is run from inetd, and I’ve been telling people
to use CVS over ssh *only*, for years and years, so this doesn’t
affect my current case, it may still be valid for others…)

Imagine a remote login dæmon that uses crypt() in the main process…
this is a nice DoS, and now not even the superuser could log in
to fix it. (Things like that probably exist… Debian recently made
node.js change its binary name because ax25-node uses “node” too,
and systems running that are usually in very remote locations and
not easily administered.)

At this point, I'd rather we took the opportunity to fix code that makes
unsafe assumptions about the behavior of crypt than push the problem on

Can you always do that? (Ideally yes, but… hence the suggestion
of a transitioning period, if my other arguments – (to me) less
unsafe/undesirable; common law / historic practice – should not
suffice.)

for users to figure out when a glibc upgrade causes passwords to fail to
be recognized because the salt suggests the use of a different,

As opposed to having a libc upgrade make programs segfault?

I mean… sure, it may be easier to debug… but you might not
be in a mood to debug, and people who develop the software
in question may be not using glibc (in fact, I discovered
recently that Linux allows S_IFLNK with st_nlink ≠ 1 which
BSD doesn’t, and which now means I need to add Linux-specific
code to paxtar, so this also is a practical issue for
made-to-be-portable-later software).

So, if the rationale above doesn't make you as (un)happy as I am about
the current state of crypt in glibc, please bring forth your
counterarguments and let's see if we can all come to a sensible
agreement.

I hope to have brought enough arguments and reasoning;
I’m happy to discuss all of them further. Summarising:

• common law / historic practice

• compatibility with previous glibc
• compatibility with other current-day systems

• principle of less surprise / more over-all robustness
  in the face of real-world (buggy) software, including
  those copying from the examples given by POSIX

• my somewhat arguable reading of the standard

• known to break things (that *may* be fixed, sure)

• and if everything else fails, a transition period
  with some sort of warning (ProPolice SSP uses syslog()
  so maybe that’s acceptable, even inside the libc?)

Anyway, thanks for the report,

Thanks for being open to discuss this,
//mirabilos

PS and OT: can sources.redhat.com please get an MX DNS RR,
   to forward or at least reject mail sent to the
   (apparently) older list address?
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent 

Re: [Debian #714219] libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software

2013-07-01 Thread Thorsten Glaser
Aurelien Jarno dixit:

I am not sure we want to fix that. This behaviour has been introduced
voluntarily to fix some issues with the previous code:

  http://sourceware.org/ml/libc-alpha/2012-05/msg00893.html
[…]
The current behavior, while unpleasant, can lead to a DoS, but not to a
security issue, as the only thing you can access is the 0 address which
is not accessible as we now have the mmap_min_addr feature since Lenny.

Right, but a DoS is still an issue.

I am waiting for your inputs for proposal on how to fix that, if
possible in a way that doesn't lower the security.

Right. I’m back now, and have looked at the above-mentioned eMail
and the code and diff in question, and I’d basically change the
code so that every return (NULL) gets replaced by the equivalent
of:

somebuf[0] = *salt == 'x' ? '*' : 'x';
somebuf[1] = 0;
return (somebuf);

This would always avoid returning a NULL value, thus unbreaking
all applications that use that assumption.

Now, on to the separate NULL cases:

• returning NULL if FIPS is enabled and MD5 or DES are requested:
  these seem like a good thing at first, and backed by POSIX, until
  you realise that they do not only depend on system state (the
  /proc/sys/crypto/fips_enabled entry) but also on the input (since
  crypt() will still not return NULL if e.g. SHA-256 is used),
  which makes the argument that crypt() must either always return
  NULL or never, but not depending on its arguments, combined with
  the historical practice of assuming it never returns NULL “or one
  has more problems than that anyway since crypt() is dysfunctional”,
  more valid

• returning NULL if it’s not valid DES (or an otherwise unrecognised
  algorithm, e.g. #if !__OPTION_EGLIBC_CRYPT_UFC, probably too) is
  just the wrong thing to do, and it does break GNU CVS, among others.

That’s why I believe that crypt() should just _never_ return NULL.
The scheme of returning '*' or 'x', which are never valid matches,
distinguishing which one to return so that it never matches the
value passed, comes from dalias from musl, and I think it’s the
best compromise/solution.

Hence, Cc upstream, so that this can be discussed and, ideally,
implemented in both upstream and Debian.

Thanks,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec


--
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/pine.bsm.4.64l.1307011852130.24...@herc.mirbsd.org



Bug#714219: libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software

2013-06-26 Thread Thorsten Glaser
Package: libc6
Version: 2.17-6
Severity: important

Hi,

GNU libc6 in sid is breaking GNU CVS; some operations can
cause a segfault. I’ve tracked it down to:

tglase@tglase:~ $ cat x.c
#define _GNU_SOURCE
#include errno.h
#include stdio.h
#include string.h
#include unistd.h

void tst(const char *, const char *);
void tst(const char *x, const char *y) {
const char *z;
int e;

z = crypt(x, y);
e = errno;
printf(tst(\%s\, \%s\)\n - %p %s\n - %s\n,
x, y, z, z?z:(null), z?(ok):strerror(e));
}

int main(void) {
tst(foo, xy7k69x/M/s7g);
tst(bar, xy7k69x/M/s7g);
tst(   , %qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d);
return (0);
}
tglase@tglase:~ $ gcc -O2 -o x x.c -lcrypt
tglase@tglase:~ $ ./x
tst(foo, xy7k69x/M/s7g)
 - 0xf77b7140 xy7k69x/M/s7g
 - (ok)
tst(bar, xy7k69x/M/s7g)
 - 0xf77b7140 xy5FOaP3Hea0k
 - (ok)
tst(   , %qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d)
 - (nil) (null)
 - Invalid argument
tglase@tglase:~ $ scp x ${wheezysystem}:
x  
100% 5707 5.6KB/s   00:00
tglase@tglase:~ $ ssh ${wheezysystem} ./x
tst(foo, xy7k69x/M/s7g)
 - 0xb7742140 xy7k69x/M/s7g
 - (ok)
tst(bar, xy7k69x/M/s7g)
 - 0xb7742140 xy5FOaP3Hea0k
 - (ok)
tst(   , %qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d)
 - 0xb7742140 %q7LLO/mNILqg
 - (ok)

POSIX says crypt(3) only fails with ENOSYS if it’s not supported
at all, but then it’d fail consistently:

ERRORS  
 

 
 The crypt() function shall fail if:
 
   [ENOSYS] 
 
  The functionality is not supported on this implementation.
 

POSIX then goes on to use crypt() just like GNU CVS does:

if (strcmp(p-pw_passwd, crypt(oldpasswd, p-pw_passwd)) == 0) {
 

Other implementations (like BSD) also strongly suggest that,
unless a different algorithm is selected ($1$, $2a$, etc.)
DES is used, which the above example clearly states is supported,
and overlong salts are just cut off / their trail end ignored.

23:51⎜dalias in musl, we return * on error

If this is an error at all… on wheezy it was none, and BSD agrees:

tg@blau:~ $ uname -a; ./x   

MirBSD blau.mirbsd.org 10 Kv#10uB2-20130517 GENERIC#1405 i386
tst(foo, xy7k69x/M/s7g)
 - 0x23af3720 xy7k69x/M/s7g
 - (ok)
tst(bar, xy7k69x/M/s7g)
 - 0x23af3720 xy5FOaP3Hea0k
 - (ok)
tst(   , %qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d)
 - 0x23af3720 %q3ge9F/nF3ec
 - (ok)

Although the output on wheezy differs (it shouldn’t).


Please fix this to at least never return NULL with something
else than an ENOSYS condition (crypt(3) not implemented at all),
because this *will* break unrelated software.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh

Versions of packages libc6 depends on:
ii  libgcc1  1:4.8.1-4

Versions of packages libc6 recommends:
ii  libc6-i686  2.17-6

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.50
ii  glibc-doc  2.17-6
ii  locales-all [locales]  2.17-6

-- debconf information:
* glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
* glibc/restart-services: postfix openbsd-inetd cups cron
* libraries/restart-without-asking: true


-- 
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/20130626220647.9086.25208.report...@tglase.lan.tarent.de



Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)

2013-06-26 Thread Thorsten Glaser
Debian Bug Tracking System dixit:

If you wish to submit further information on this problem, please
send it to 714...@bugs.debian.org.

Oh well, a '%' is not in the list of DES inputs, so differing
is permitted, but returning NULL is so very not nice.

Shortening the string shows “DES” can be done on it, so do it;
just return * (or x if the input is * so it never matches)
if you absolutely can’t return anything else useful.

(We continued this discussion in IRC…)

bye,
//mirabilos
-- 
17:08⎜«Vutral» früher gabs keine packenden smartphones und so
17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig
17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch
17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt


--
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/pine.bsm.4.64l.1306262247030.3...@herc.mirbsd.org



Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)

2013-06-26 Thread Thorsten Glaser
Aurelien Jarno dixit:

As the function is POSIX compliant, it looks like to me a documentation
issue. Should this bug be reassigned to manpages-dev to mention the fact
that the function might return NULL in case of error?

The NULL-in-case-of-error mentioned by POSIX is when the
function is not implemented *at all*, i.e. all calls to
it would fail independent of the input (and then, you’d
have bigger problems).

Even the example code given in POSIX uses crypt() without
checking for NULL explicitly, assuming it’ll always get a
string out that just won’t compare equally if it’s not a
valid password.

There’s bound to be lots of software that uses crypt() like
this, especially as this behaviour has been in existence for
*decades* literally, and will continue to be on other OSes.

This probably *will* introduce security holes, especially
when the password hash is user-controlled; libc should behave
sanely here and just fall back to “DES”. Or just return *
unless the argument is * in which case it can return x.

I find it especially poor form of GNU when the GNU libc
breaks other GNU software…

bye,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec


--
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/pine.bsm.4.64l.1306262348430.3...@herc.mirbsd.org



Re: Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)

2013-06-26 Thread Thorsten Glaser
Aurelien Jarno dixit:

ambiguity that crypt can return NULL for any failure (i.e. not
successful completion):

Indeed, but, one, it doesn’t list any other error code (nor do
the glibc manpages) and two, there _is_ something called common
law: it’s been like this for decades.

This is *your* interpretation of POSIX. Quoting it, there is no

Do you, by inaction, want to sign responsible for all security
holes introduced into previously-working code in the archive
that now, without even a recompilation, breaks?

Or will you add some small patch fixing this behaviour and
feed that patch also upstream?

I do not disagree that user programs “probably” “should” check
for NULL, but let’s face reality. And libc *also* has some part
in the job: it should not make userspace’s live too hard.

bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (260 (281) bugs: 0 RC, 182 (196) IN, 78 (85) MW, 0 (0) FP)
‣ src:dash (87 (103) bugs: 3 RC, 41 (46) IN, 43 (54) MW, 0 FP)
‣ src:mksh (2 bugs: 0 RC, 0 IN, 2 MW, 0 FP, 1 gift)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?


--
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/pine.bsm.4.64l.1306270024230.3...@herc.mirbsd.org



Re: Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)

2013-06-26 Thread Thorsten Glaser
Aurelien Jarno dixit:

Please provide a patch, and I will add it in the next upload. If you
don't, you will sign responsible for all security holes introduced into
previously-working code in the archive.

It's freaking late at night, and I just spent hours fighting
with gnulib and *then* hours I'd rather be doing something
else discovering, analysing and discussing it, so gimme a
rest, I've got to work for money romoeeow. You responded first
that's why I wrote that.

If you dont have a patch tomorrow evening i'll try to oblige.

//mirabilos
-- 
17:08⎜«Vutral» früher gabs keine packenden smartphones und so
17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig
17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch
17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt


--
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/pine.bsm.4.64l.1306270100220.3...@herc.mirbsd.org



Bug#634261: weird if (somesymbol) in eglibc

2012-11-25 Thread Thorsten Glaser
Note that taking the address of a symbol can never be NULL
according to C99, so the compiler may probably optimise
*all* of “if (_IO_stdin_used == NULL) { … }” away. (That’s
because of the definition of NULL and object pointers.)

Maybe that’s what happens.

I agree something fishy is being done by eglibc here.

From /usr/include/libio.h this appears to be compatibility
code for glibc 2.0/2.1…

Reading “gcc foo.c -Wl,-t -static” with glibc is, compared
to other libcs, absolutely disgusting… but here we go.

/usr/lib/x86_64-linux-gnu/libc.a/uar://stdio.o (in new-mc
syntax) defines stdin and _IO_stdin in terms of _IO_2_1_stdin_
but doesn’t define _IO_stdin_used.

In fact, libc.a has no defintion of _IO_stdin_used *at all*,
and an nm on foo.o doesn’t show it either. (So where does it
come from? IMHO, if glibc insists on this hack, which probably
is “Undefined Behaviour” anyway, _IO_stdin_used should be
pulled in from stdio.o when linking on modernish glibcs.

bye,
//mirabilos, via Plänet Debian
-- 
In traditional syntax ' is ignored, but in c99 everything between two ' is
handled as character constant.  Therefore you cannot use ' in a preproces-
sing file in c99 mode.  -- Ragge
No faith left in ISO C99, undefined behaviour, etc.


--
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/pine.bsm.4.64l.1211252312170.30...@herc.mirbsd.org



Bug#693852: Powerpc/m68k issue running test_stack

2012-11-21 Thread Thorsten Glaser
Dixi quod…

Ivan Maidanski dixit:

Could you summarize please you suggestion how to fix this?

I need to make a couple more checks. *Maybe* it got fixed
with the new eglibc patch already, since the Debian package
7.3~alpha3+git20121114-1 unexpectedly *passed* all its tests.

OK, after some tests, I can confirm that the patched libc,
independent of the kernel, fixes the test_stack program.

@Debian eglibc maintainers: So this means that yes, please
include the patch when your policy permits (it’s fine if it
is not possible until after the wheezy release and unfreeze,
I’ll carry a patched version until then).

@boehm-gc people: I think you need to not do anything. Note
that I could not test master as autoreconf didn’t want to
work for me, but Ivan, if you could private-mail me a tarball
of master where I just need to run ./configure  make check,
I will gladly do that.

@Debian-68k people: this tests the eglibc patch and validates
that we indeed want it; as for the kernel patch, the test has
not yet compiled far enough to see. I’m running the rebuilt
kernel already (the atari flavour is built early enough ☺),
and it at least shows no regressions.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2


--
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/pine.bsm.4.64l.1211211917140.6...@herc.mirbsd.org



Bug#692154: Shouldn't description mention also 3.2 kernels?

2012-11-20 Thread Thorsten Glaser
Jonathan Nieder dixit:

- Athlon/Opteron, VIA C3 Nehemiah, but not VIA C3 Ezra).  
 ^
+ C3 Ezla).  
^

You introduced a pasto.

bye,
//mirabilos
-- 
Darwinism never[…]applied to wizardkind. There's a more than fair amount of[…]
stupidity in its gene-pool[…]never eradicated[…]magic evens the odds that way.
It's[…]harder to die for us than[…]muggles[…]wonder if, as technology[…]better
[…]same will[…]happen there too. Dursleys' continued existence indicates so.


--
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/pine.bsm.4.64l.1211202318120.29...@herc.mirbsd.org



Bug#693852: eglibc: please include m68k bugfix

2012-11-20 Thread Thorsten Glaser
Source: eglibc
Severity: wishlist

Hi,

can you please apply the following patch to, I guess, the next eglibc
upload after the unfreeze? I just threw it into an unpacked 2.13-36 tree
as debian/patches/m68k/cvs-fix-cancellable-syscall-with-5-or-6-arguments.diff
and updated the series file, and it worked for me:

 eglibc (2.13-36~m68k.1) unreleased; urgency=low
 .
   * Apply “m68k: fix cancellable syscall with 5 or 6 arguments”
 patch from Andreas Schwab

http://sourceware.org/git/?p=glibc.git;a=commit;h=67f2b51c62cb0367e30f26a8865d77fc6461bdb3
via Message-ID: m2fw46hhs3@igel.home

This patch is almost certainly responsible for fixing crashes in
programs using libatomic-ops due to register corruption.

Merci,
//mirabilos
-- 
Darwinism never[…]applied to wizardkind. There's a more than fair amount of[…]
stupidity in its gene-pool[…]never eradicated[…]magic evens the odds that way.
It's[…]harder to die for us than[…]muggles[…]wonder if, as technology[…]better
[…]same will[…]happen there too. Dursleys' continued existence indicates so.


--
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/pine.bsm.4.64l.1211202319380.29...@herc.mirbsd.org



Bug#693446: libc-bin: C.UTF-8 locale shows bogus dates

2012-11-18 Thread Thorsten Glaser
Aurelien Jarno dixit:

Indeed, LC_TIME has been written using en_US.UTF-8 as an example.

Ah, okay.

 Can we please have the C.UTF-8 locale be a copy of the C locale
 with *only* the encoding set to UTF-8, nothing else changed?

History has shown that writing such a locale is not as easy as you
think.

Right, especially as it’s kinda hard to take ‘C’ as base
when it’s the absence of localisation in most cases…

That will be fixed in the next upload.

Merci!

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2


--
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/pine.bsm.4.64l.1211182046110.24...@herc.mirbsd.org



Bug#693446: libc-bin: C.UTF-8 locale shows bogus dates

2012-11-16 Thread Thorsten Glaser
Package: libc-bin
Version: 2.13-35
Severity: important

Hi!

Reporting against libc-bin as that’s where this locale comes from:
tg@freewrt:~ $ dpkg -S /usr/lib/locale/C.UTF-8
libc-bin: /usr/lib/locale/C.UTF-8

Verified to exist in sid (2.13-36).

tg@freewrt:~ $ LC_ALL=C.UTF-8 perl -MPOSIX -e 'print strftime('\''%a %b %e %X 
%Y'\'', localtime()).\n;'
Fri Nov 16 03:42:25 PM 2012

Wrong. But the C locale is right:

tg@freewrt:~ $ LC_ALL=C perl -MPOSIX -e 'print strftime('\''%a %b %e %X %Y'\'', 
localtime()).\n;'
Fri Nov 16 15:42:26 2012

I think I know where this one comes from:

tg@freewrt:~ $ LC_ALL=en_US.UTF-8 perl -MPOSIX -e 'print strftime('\''%a %b %e 
%X %Y'\'', localtime()).\n;'
Fri Nov 16 03:42:32 PM 2012
tg@freewrt:~ $ LC_ALL=en_GB.UTF-8 perl -MPOSIX -e 'print strftime('\''%a %b %e 
%X %Y'\'', localtime()).\n;'
Fri Nov 16 15:42:36 2012

Can we please have the C.UTF-8 locale be a copy of the C locale
with *only* the encoding set to UTF-8, nothing else changed?

Can we please get this fixed in wheezy?

Thanks!


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh-static

-- no debconf information


--
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/20121116154655.5548.97730.report...@freewrt.org



Bug#665897: eglibc: [mips, mipsel] wrong RLIM_INFINITY for LFS

2012-03-26 Thread Thorsten Glaser
Source: eglibc
Version: 2.13-27

(The MIPS porters may please set a severity on this.)

I’ve discovered this as a problem with the shells’ ulimit builtin
(both mksh and GNU bash affected as they’re built with LFS, dash
isn’t, and mksh-static uses dietlibc on both mips and mipsel which
just ignores -D_FILE_OFFSET_BITS=64).

Basically, RLIM_INFINITY on a bunch of platforms is, apparently
historically, not all-bits-one but all-bits-one-SHR-1. This works
fine for the non-LFS case but disagrees with the data the Linux
kernel sends for the LFS case:

tg@gabrielli:~$ dchroot sid
Executing shell in chroot: /chroot/sid
(sid)tg@gabrielli:~$ cat x.c
#include sys/types.h
#include sys/time.h
#include sys/resource.h
#include err.h
#include stdio.h
int main(void) {
struct rlimit r;
if (getrlimit(RLIMIT_DATA, r))
err(1, getrlimit);
printf(%016llX %016llX\n, (unsigned long long)r.rlim_cur, (unsigned 
long long)RLIM_INFINITY);
return (0);
}
(sid)tg@gabrielli:~$ gcc x.c
(sid)tg@gabrielli:~$ ./a.out
7FFF 7FFF
(sid)tg@gabrielli:~$ gcc x.c -D_FILE_OFFSET_BITS=64
(sid)tg@gabrielli:~$ ./a.out
 7FFF

The documented ABI for this (via the linux-libc-dev package) is:

/usr/include/mips-linux-gnu/asm/resource.h:# define RLIM_INFINITY   
0x7fffUL
/usr/include/asm-generic/resource.h:# define RLIM_INFINITY  (~0UL)

So the special-casing of Alpha, MIPS and SPARC apparently is
wrong for the LFS case, and this is a bug in eglibc. At least
this is what I think after this analysis ;-)

Other info:

(sid)tg@gabrielli:~$ uname -a
Linux gabrielli 3.2.0-0.bpo.1-octeon #1 SMP Sun Feb 12 21:03:30 UTC 2012 mips64 
GNU/Linux
(sid)tg@eder:~$ uname -a
Linux eder 2.6.39-3-loongson-2e #1 Sat Aug 20 16:36:12 UTC 2011 mips64 GNU/Linux

These are the two affected systems I can reproduce things with
(mips and mipsel, in this order).

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r



--
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/pine.bsm.4.64l.1203262022440.27...@herc.mirbsd.org



Bug#534521: this is a bug in eglibc, not in pax

2012-02-27 Thread Thorsten Glaser
reassign 317466 src:eglibc
forcemerge 534521 317466
thanks

This is not a bug in pax, but eglibc _really_ should do something.

How about something like this (for all affected functions)?

#ifdef __USE_FILE_OFFSET64
FTSENT  *fts_read (FTS *) __asm__(fts_read64);
#else
FTSENT  *fts_read (FTS *);
#endif

Then just compile the *.c twice.

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr



--
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/pine.bsm.4.64l.1202272047150.13...@herc.mirbsd.org



Bug#317466: Bug#534521: this is a bug in eglibc, not in pax

2012-02-27 Thread Thorsten Glaser
Aurelien Jarno dixit:

I disagree. Pax isn't built with large file support (because fts.h
doesn't allow that), so even if eglibc is fixed, pax would need to be
fixed. Blocking bug should be used instead.

Right, I could have thought of that.

The problem is not having fts_read64, but having a different FTSENT 
structure.

The structure is changed along with the functions called.

Hrm, I think if users of this pass FTSENT pointers around
among themselves, this could indeed lead to problems. Damn.

How about providing a libfts64? (Or, more generic, a library
where everything where this is an issue has been built with
a 64-bit off_t)

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr



--
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/pine.bsm.4.64l.1202272238490.13...@herc.mirbsd.org



Bug#636286: tagging 636286

2012-01-01 Thread Thorsten Glaser
Aurelien Jarno dixit:

tags 636286 + wontfix

Uhm, why? If someone working for glibc upstream says that the
locale files produced by the Debian patched version of glibc
are invalid…

thanks

for doing so silently and with no reason. Maybe I should
indeed, as you expressed so nicely, stop to care about
open source projects.

//mirabilos
-- 
22:20⎜asarch The crazy that persists in his craziness becomes a master
22:21⎜asarch And the distance between the craziness and geniality is
only measured by the success 18:35⎜asarch Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent



--
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/pine.bsm.4.64l.120101250.20...@herc.mirbsd.org



Bug#652356: please use argument-safe bswap macros on all architectures

2011-12-19 Thread Thorsten Glaser
Dixi quod…

Jonathan Nieder dixit:

Thorsten, can you test this patch or arrange for it to be tested?

Will do that

Built, WFM.

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr



--
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/pine.bsm.4.64l.1112192220430@herc.mirbsd.org



Bug#652356: please use argument-safe bswap macros on all architectures

2011-12-17 Thread Thorsten Glaser
Aurelien Jarno dixit:

I am not an m68k porter, and I am not planning to try things. m68k is
lagging upstream wrt other architectures. Please work with upstream to
fix things, then I can include tested and accepted patches.

I’m not an m68k porter either, but this fix is easily done from working
with a libc (BSD libc in my case) skills. But okay. Am I guessing that
libc-po...@sourceware.org is “upstream”? It was hard to find information
about eglibc-ports on the ’net.

Anyway, here it is:


Dixi quod…

Aurelien Jarno dixit:

I have dropped it in favor of the default version for the next upload.

Why don’t you just use these? (Tested for 32-bit and 64-bit both.)
I’ve not looked at other architectures atm though.

--- usr/include/m68k-linux-gnu/bits/byteswap.h~2011-12-17 
02:44:08.0 +
+++ usr/include/m68k-linux-gnu/bits/byteswap.h 2011-12-17 02:49:34.0 
+
@@ -1,5 +1,5 @@
 /* Macros to swap the order of bytes in integer values.  m68k version.
-   Copyright (C) 1997, 2002, 2008 Free Software Foundation, Inc.
+   Copyright (C) 1997, 2002, 2008, 2011 Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
The GNU C Library is free software; you can redistribute it and/or
@@ -50,15 +50,15 @@
 #if defined __GNUC__  __GNUC__ = 2  !defined(__mcoldfire__)
 # define __bswap_32(x) \
   __extension__   \
-  ({ unsigned int __bswap_32_v;   \
- if (__builtin_constant_p (x))\
-   __bswap_32_v = __bswap_constant_32 (x);\
+  ({ unsigned int __bswap_32_v, __bswap_32_x = (x);   \
+ if (__builtin_constant_p (__bswap_32_x)) \
+   __bswap_32_v = __bswap_constant_32 (__bswap_32_x); \
  else \
__asm__ __volatile__ (ror%.w %#8, %0;\
swap %0; \
ror%.w %#8, %0   \
: =d (__bswap_32_v)  \
-   : 0 ((unsigned int) (x)));   \
+   : 0 (__bswap_32_x)); \
  __bswap_32_v; })
 #else
 static __inline unsigned int
@@ -85,11 +85,12 @@
   __extension__   
 \
   ({ union { unsigned long long int __ll; \
unsigned long int __l[2]; } __bswap_64_v, __bswap_64_r;\
- if (__builtin_constant_p (x))\
-   __bswap_64_r.__ll = __bswap_constant_64 (x);   \
+ unsigned long long int __bswap_64_x = (x);   
\
+ if (__builtin_constant_p (__bswap_64_x)) \
+   __bswap_64_r.__ll = __bswap_constant_64 (__bswap_64_x);
\
  else \
{  \
-   __bswap_64_v.__ll = (x);   \
+   __bswap_64_v.__ll = __bswap_64_x;  \
__bswap_64_r.__l[0] = __bswap_32 (__bswap_64_v.__l[1]);\
__bswap_64_r.__l[1] = __bswap_32 (__bswap_64_v.__l[0]);\
}  \


Aurelien Jarno dixit:

Other architectures don't have this problem with byteswap.h

I see. I didn’t know that for sure, so I suggested that in
general someone should look at it.

bye,
//mirabilos

PS: Please fix your MTA; hall.aurel32.net is sending 8-bit
data to a receiving MTA that does not announce 8BITMIME
support in its EHLO response. Or your MUA to use Quoted-
Printable by default.
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2



--
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/pine.bsm.4.64l.1112171247170@herc.mirbsd.org



Bug#652356: please use argument-safe bswap macros on all architectures

2011-12-17 Thread Thorsten Glaser
Aurelien Jarno dixit:

If you are not an m68k porter, you should simply stop to care about
m68k porting issues. 

I care about the entire Open Source ecosystem. (Way to motivate people.)

bye,
//mirabilos
-- 
13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs
13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you
13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺
16:06⎜Draget:#cvs Thank god I found you =)   20:03│«bioe007:#cvs» mira2k: ty
17:14⎜ldiain:#cvs Thanks big help you are :-)   bioe007 mira|nwt: ty again
18:35⎜«alturiak:#cvs» mirabilos: aw, nice. thanks :o
18:36⎜«ThunderChicken:#cvs» mirabilos FTW!  23:03⎜«mithraic:#cvs» aaah. thanks
18:41⎜«alturiak:#cvs» phew. thanks a bunch, guys. you just made my weekend :-)
18:10⎜«sumit:#cvs» mirabilos: oh ok.. thanks for that
21:57⎜bhuey:#cvs yeah, I really appreciate help
18:50⎜«grndlvl:#cvs» thankyou18:50⎜«grndlvl:#cvs» worked perfectly
20:50⎜paolo:#cvs i see. mirabilos, thnks for your support
00:36⎜«halirutan:#cvs» ok, the obvious way:-) thx
18:44⎜«arcfide:#cvs» mirabilos, I am running OpenBSD. 18:59⎜«arcfide:#cvs»
Hrm, yes, I see what you mean. 19:01⎜«arcfide:#cvs» Yeah, thanks for the help.
21:33⎜«CardinalFang:#cvs» Ugh.  Okay.  Sorry for the dumb question.  Thank you
21:34⎜centosian:#cvs mirabilos: whoa that's sweet
21:52⎜«garrett__:#cvs» much appreciated  «garrett__:#cvs» thanks for your time
23:39⎜symons:#cvs this worked, thank you very much 16:26⎜schweizer:#cvs ok
thx, i'll try that 20:00⎜«stableable:#cvs» Thank you.20:50⎜«s833:#cvs»
mirabilos: thanks a lot.19:34⎜bobbytek:#cvs Thanks for confirming :)
20:08⎜tsolox:#cvs ...works like a charm.. thanks mirabilos



--
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/pine.bsm.4.64l.1112171443480@herc.mirbsd.org



Bug#652356: please use argument-safe bswap macros on all architectures

2011-12-17 Thread Thorsten Glaser
Jonathan Nieder dixit:

There are kinder ways to say that.

Thanks.

Thorsten, can you test this patch or arrange for it to be tested?

Will do that once the next buildhost gets idle (one is currently
building gcc-4.6 (second upload in one day), the other working
its something off to build a kernel with gcc-4.6, to see whether
we can switch that there as well).

(At the patch: huh… I’d have used ({ instead of static inline,
plus didn’t know __builtin_constant_p works even like that. But
if it works, sure, why not.)

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in Notes on Programming in C



--
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/pine.bsm.4.64l.1112172225190@herc.mirbsd.org



Bug#652356: please use argument-safe bswap macros on all architectures

2011-12-16 Thread Thorsten Glaser
Source: eglibc

Hi,

(from #595496) please make sure that this passes on all
architectures:

cat x.c 'EOF'
#include stddef.h
#include stdint.h
#include byteswap.h

uint32_t
foo(uint32_t *bar, size_t *baz) {
return (bswap_32(bar[(*baz)++]));
}
EOF
gcc -Wall -c x.c


On amd64 it passes, on m68k it gives:

x.c: In function ‘foo’:
x.c:6:10: warning: operation on ‘*baz’ may be undefined [-Wsequence-point]
x.c:6:10: warning: operation on ‘*baz’ may be undefined [-Wsequence-point]
x.c:6:10: warning: operation on ‘*baz’ may be undefined [-Wsequence-point]

The difference is in /usr/include/$multiarsch/bits/byteswap.h:

#  define __bswap_32(x) \
 (__extension__   \
  ({ register unsigned int __v, __x = (x);\
 if (__builtin_constant_p (__x))  \
[…]

(amd64) vs. (m68k)

# define __bswap_32(x) \
  __extension__ \
  ({ unsigned int __bswap_32_v; \
 if (__builtin_constant_p (x))  \
[…]

That is, the amd64 version evaluates the argument only once.

Please ensure all flavours of the bswap macros on all architectures
behave the same; otherwise it’s an introduction to porting issues
that need not be. Porting is joyful enough already ;-)

Thanks in advance,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs



--
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/pine.bsm.4.64l.1112161525050@herc.mirbsd.org



Bug#652356: please use argument-safe bswap macros on all architectures

2011-12-16 Thread Thorsten Glaser
Aurelien Jarno dixit:

I have dropped it in favor of the default version for the next upload.

Why don’t you just use these? (Tested for 32-bit and 64-bit both.)
I’ve not looked at other architectures atm though.

--- usr/include/m68k-linux-gnu/bits/byteswap.h~ 2011-12-17 02:44:08.0 
+
+++ usr/include/m68k-linux-gnu/bits/byteswap.h  2011-12-17 02:49:34.0 
+
@@ -1,5 +1,5 @@
 /* Macros to swap the order of bytes in integer values.  m68k version.
-   Copyright (C) 1997, 2002, 2008 Free Software Foundation, Inc.
+   Copyright (C) 1997, 2002, 2008, 2011 Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
The GNU C Library is free software; you can redistribute it and/or
@@ -50,15 +50,15 @@
 #if defined __GNUC__  __GNUC__ = 2  !defined(__mcoldfire__)
 # define __bswap_32(x) \
   __extension__\
-  ({ unsigned int __bswap_32_v;\
- if (__builtin_constant_p (x)) \
-   __bswap_32_v = __bswap_constant_32 (x); \
+  ({ unsigned int __bswap_32_v, __bswap_32_x = (x);\
+ if (__builtin_constant_p (__bswap_32_x))  \
+   __bswap_32_v = __bswap_constant_32 (__bswap_32_x);  \
  else  \
__asm__ __volatile__ (ror%.w %#8, %0; \
 swap %0; \
 ror%.w %#8, %0   \
 : =d (__bswap_32_v)  \
-: 0 ((unsigned int) (x)));   \
+: 0 (__bswap_32_x)); \
  __bswap_32_v; })
 #else
 static __inline unsigned int
@@ -85,11 +85,12 @@
   __extension__
\
   ({ union { unsigned long long int __ll;  \
 unsigned long int __l[2]; } __bswap_64_v, __bswap_64_r;\
- if (__builtin_constant_p (x)) \
-   __bswap_64_r.__ll = __bswap_constant_64 (x);\
+ unsigned long long int __bswap_64_x = (x);
\
+ if (__builtin_constant_p (__bswap_64_x))  \
+   __bswap_64_r.__ll = __bswap_constant_64 (__bswap_64_x); \
  else  \
{   \
-__bswap_64_v.__ll = (x);   \
+__bswap_64_v.__ll = __bswap_64_x;  \
 __bswap_64_r.__l[0] = __bswap_32 (__bswap_64_v.__l[1]);\
 __bswap_64_r.__l[1] = __bswap_32 (__bswap_64_v.__l[0]);\
}   \



bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr



--
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/pine.bsm.4.64l.1112170250430@herc.mirbsd.org



Re: Cross Memory Attach v3

2011-12-16 Thread Thorsten Glaser
I’ve tested the below patch locally in the meantime, and it
does not break anything.

Aurelien Jarno dixit:

On Sun, Dec 11, 2011 at 10:11:03PM +, Thorsten Glaser wrote:
 Andreas Schwab dixit:
 
 Thorsten Glaser t...@mirbsd.de writes:
 
  Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/m68k/syscall.S
  ===
  --- eglibc-2.13.orig/ports/sysdeps/unix/sysv/linux/m68k/syscall.S 
  2011-12-04 14:36:16.0 +
  +++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/m68k/syscall.S  
  2011-12-04 14:36:26.0 +
  @@ -24,9 +24,9 @@
.text
   ENTRY (syscall)
move.l 4(%sp), %d0  /* Load syscall number.  */
  - _DOARGS_5 (24)  /* Frob arguments.  */
  + _DOARGS_6 (28)  /* Frob arguments.  */
trap 0 /* Do the system call.  */
  - UNDOARGS_5  /* Unfrob arguments.  */
  + UNDOARGS_6  /* Unfrob arguments.  */
cmp.l -4095, %d0   /* Check %d0 for error.  */
jcc SYSCALL_ERROR_LABEL /* Jump to error handler if negative.  */
rts /* Return to caller.  */
 
 Thanks, installed.
 
 (Where?) So, should $someone submit that to eglibc-ports and
 Debisn src:eglibc? Did it indeed do the trick?

This patch should be reported to libc-po...@sourceware.org. If it also 

Reporting hereby.

needs to be applied to the Debian package quickly, please open a bug 
report in the Debian BTS.

@kernel people, is this needed / useful? Do we want/need this?
(I wonder why it's not using _DOARGS_6 already, as that looks
as if it were designed for it.)

bye,
//mirabilos
-- 
22:20⎜asarch The crazy that persists in his craziness becomes a master
22:21⎜asarch And the distance between the craziness and geniality is
only measured by the success 18:35⎜asarch Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent


--
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/pine.bsm.4.64l.1112170255070@herc.mirbsd.org



Re: [m68k] eglibc expected(?) testsuite results

2011-12-16 Thread Thorsten Glaser
Finn Thain dixit:

 I have just included it as the expected tests results. I have to say the
 list of failure seems to say that m68k is not really in a good state.

Mh. I’m just the builder.

It might be worth running the tests on physical hardware instead of an 
emulator.

You just volunteered. (In fact, from what I heard on the list, the
FPU emulation is known bad; the rest is good enough to be usable.)

bye,
//mirabilos
-- 
In traditional syntax ' is ignored, but in c99 everything between two ' is
handled as character constant.  Therefore you cannot use ' in a preproces-
sing file in c99 mode.  -- Ragge
No faith left in ISO C99, undefined behaviour, etc.


--
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/pine.bsm.4.64l.1112170323190@herc.mirbsd.org



[m68k] eglibc expected(?) testsuite results

2011-12-15 Thread Thorsten Glaser
Just FYI, maybe you can do something with it (or not).
I built the latest eglibc 2.13-23 without nocheck.


make[1]: Leaving directory `/tmp/buildd/eglibc-2.13/build-tree/m68k-libc'
#
# Testsuite failures, someone should be working towards
# fixing these! They are listed here for the purpose of
# regression testing during builds.
# Format: Failed test, Error Make error code [(ignored)]
#
annexc.out, Error 1 (ignored)
bug-nextafter.out, Error 24
bug-nexttoward.out, Error 32
bug-regex20.out, Error 139
check-localplt.out, Error 1
sort-test.out, Error 1
test-double.out, Error 1
test-fenv.out, Error 1
test-float.out, Error 1
test-idouble.out, Error 1
test-ifloat.out, Error 1
test-misc.out, Error 1
tst-atomic-long.out, Error 1
tst-atomic.out, Error 1
tst-mqueue5.out, Error 1
tst-mqueue6.out, Error 1
tst-mutexpi2.out, Error 1
tst-mutexpi4.out, Error 1
tst-mutexpi5.out, Error 1
tst-mutexpi5a.out, Error 1
tst-mutexpi6.out, Error 1
tst-mutexpi7.out, Error 1
tst-mutexpi7a.out, Error 1
tst-mutexpi9.out, Error 1
tst-robust1.out, Error 1
tst-robust2.out, Error 1
tst-robust3.out, Error 1
tst-robust4.out, Error 1
tst-robust5.out, Error 1
tst-robust6.out, Error 1
tst-robust7.out, Error 1
tst-robust8.out, Error 1
tst-robust9.out, Error 1
tst-robustpi1.out, Error 1
tst-robustpi2.out, Error 1
tst-robustpi3.out, Error 1
tst-robustpi4.out, Error 1
tst-robustpi5.out, Error 1
tst-robustpi6.out, Error 1
tst-robustpi7.out, Error 1
tst-robustpi8.out, Error 1
tst-rxspencer.out, Error 139
*** WARNING ***
Please generate expected testsuite results for this arch!
*** WARNING ***
touch /tmp/buildd/eglibc-2.13/stamp-dir/check_libc


bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (239 (257) bugs: 0 RC, 166 (180) IN, 73 (77) MW, 0 FP)
‣ src:dash (72 (82) bugs: 3 RC, 27 (30) IN, 42 (49) MW, 0 FP)
‣ src:mksh (1 bug: 0 RC, 0 IN, 1 MW, 0 FP)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?


--
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/pine.bsm.4.64l.1112151245590.15...@herc.mirbsd.org



Re: [m68k] eglibc expected(?) testsuite results

2011-12-15 Thread Thorsten Glaser
Finn Thain dixit:

It might be helpful to do the same with gcc 4.4.

That was with gcc 4.4 (which src:eglibc forces).

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr


--
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/pine.bsm.4.64l.1112152055350@herc.mirbsd.org



Re: r4943 - in glibc-package/trunk/debian: . patches/localedata

2011-09-13 Thread Thorsten Glaser
Aurelien Jarno dixit:

Because it is supposed to replace the C locale, so to follow POSIX
rules like the C locale. I am personally not convinced that we should go

It’s supposed to offer a POSIX/C locale but with UTF-8 as
character set instead of 7-bit US ASCII, like the “proper”
POSIX/C locale, the latter even with questionable properties
for octets with high-bit7 – to achieve better overall usability
of UTF-8 as standard encoding, for example.

bye,
//mirabilos
-- 
  Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL.
 -- Henry Nelson, March 1999


--
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/pine.bsm.4.64l.1109132015160.27...@herc.mirbsd.org



Bug#636686: [multiarch] libc should Break perl ( 5.12.4-2)

2011-08-08 Thread Thorsten Glaser
Hi,

just a question: what do you do if the perl that ends up
in wheezy depends on eglibc 2.13 (e.g. due to some symbol
use)? That will make upgrades impossible…

bye,
//mirabilos, human m68k buildd
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (254 (273) bugs: 1 RC, 175 (190) IN, 78 (82) MW, 0 FP)
‣ src:dash (82 (90) bugs: 3 RC, 44 (47) IN, 35 (40) MW, 0 FP)
‣ src:mksh (2 bugs: 0 RC, 0 IN, 2 MW, 0 FP)



--
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/pine.bsm.4.64l.1108081637530.16...@herc.mirbsd.org



Bug#636286: eglibc: SIGSEGV in strcoll in UTF-8 locales with certain characters

2011-08-02 Thread Thorsten Glaser
Andreas Schwab dixit:

There is no testcase.

Meh, you know that when you say attach but forget to actually do it?
Thanks for spotting. Here it is.

bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (254 (273) bugs: 1 RC, 175 (190) IN, 78 (82) MW, 0 FP)
‣ src:dash (82 (90) bugs: 3 RC, 44 (47) IN, 35 (40) MW, 0 FP)
‣ src:mksh (2 bugs: 0 RC, 0 IN, 2 MW, 0 FP)#include err.h
#include locale.h
#include stdlib.h
#include string.h

const char s1[] = { 0x20, 0xe0, 0xa6, 0xac, 0x00 };
const char s2[] = { 0x20, 0xe0, 0xa6, 0xad, 0x00 };

int
main(void)
{
int r;

if (setlocale(LC_ALL, ) == NULL)
err(4, setlocale);
r = strcoll(s1, s2);
return (r  0 ? 1 : r == 0 ? 2 : 3);
}


Bug#636286: eglibc: SIGSEGV in strcoll in UTF-8 locales with certain characters

2011-08-01 Thread Thorsten Glaser
Source: eglibc
Version: 2.13-11
Severity: normal

(Only normal severity because this doesn't happen on i386)

root@aranym:~ # LC_ALL=C ./sfl; echo $?
1
root@aranym:~ # LC_ALL=CUT ./sfl; echo $?
sfl: setlocale: No such file or directory
4
root@aranym:~ # LC_ALL=C.UTF-8 ./sfl; echo $?
Segmentation fault
139

Works with no or a nonexistent locale, but not with
a UTF-8 locale. The problem was found in the code of
localechooser (a d-i component which runs sort over
native language lists at build).

Program received signal SIGSEGV, Segmentation fault.
0xc0094940 in findidx (s1=0x8556  ব, s2=0x855b  ভ, l=0xc0145990) at 
../locale/weight.h:126
126   return indirect[-i + offset];
(gdb) bt
#0  0xc0094940 in findidx (s1=0x8556  ব, s2=0x855b  ভ, 
l=0xc0145990) at ../locale/weight.h:126
#1  __strcoll_l (s1=0x8556  ব, s2=0x855b  ভ, l=0xc0145990) at 
strcoll_l.c:213
#2  0xc008f960 in strcoll (s1=0x8556  ব, s2=0x855b  ভ) at 
strcoll.c:37
#3  0x848e in main () at sfl.c:16
(gdb) print indirect
$1 = value optimized out
(gdb) print i
$2 = value optimized out
(gdb) print offset
$3 = value optimized out

I’ve got libc6-dbg installed, but it doesn’t seem to pick that
up, even with LD_LIBRARY_PATH=/usr/lib/debug/lib/m68k-linux-gnu
set. It does however load the symbols:

Reading symbols from /lib/m68k-linux-gnu/libc.so.6...Reading symbols from 
/usr/lib/debug/lib/m68k-linux-gnu/libc-2.13.so...done.   

I had to manually unpack and quilt push -a the source to get this
far, though. How am I supposed to use the libc6-dbg package then?

The error does NOT occur if the test programme is linked statically.

By preventing inlining and handcompiling strcoll_l.c with a
slightly adjusted (duplocale and __strcoll_l using) programme
I got this:

0x8796 in findidx (cpp=0xefbc0728) at ../locale/weight.h:126
126   return indirect[-i + offset];
(gdb) print cpp
$1 = (const unsigned char **) 0xefbc0728
(gdb) print *cpp
$2 = (const unsigned char *) 0x8000107c \246\254
(gdb) x/4xb *cpp
0x8000107c s1+2:  0xa60xac0x000x20
(gdb) print indirect
Cannot access memory at address 0xcda56b30
(gdb) print i
$3 = -1130053888
(gdb) print offset
$4 = value optimized out

Sorry, can’t debug this further.


https://wiki.debian.org/Aranym/Quick has an easy way to get a VM
image for testing.



-- System Information:
Debian Release: wheezy/sid
Architecture: m68k

Kernel: Linux 3.0.0-1-atari
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh-static



-- 
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/20110801235636.31812.58475.report...@aranym.mirbsd.org



Bug#522774: possible solutions for __unused problem

2011-06-19 Thread Thorsten Glaser
Robert Millan dixit:

I can see they wouldn't be excited about it, but they might also accept

You know that there are more than one BSD, but only one glibc,
IIRC Drepper isn’t even its maintainer any more. Try persuading
for example Theo de Raadt of anything which doesn’t have any
immediate technical merit… have fun ;-)

Honestly, when resolving this I’d go for “who has the older
rights”. Maybe look at how CSUR resolves different claims to
the same part of the Unicode PUA, or something like that.
Nevertheless, thanks on picking this up.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in Notes on Programming in C



--
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/pine.bsm.4.64l.1106191822090.20...@herc.mirbsd.org



Bug#522774: Bug#522773: possible solutions for __unused problem

2011-06-19 Thread Thorsten Glaser
Ben Hutchings dixit:

 Honestly, when resolving this I’d go for “who has the older
 rights”. Maybe look at how CSUR resolves different claims to
 the same part of the Unicode PUA, or something like that.
 Nevertheless, thanks on picking this up.

Debian GNU/Linux is the older system; the Debian GNU/kFreeBSD
maintainers have to deal with compatibility issues.

The use of __undefined in the BSDs predates use of it by
both Linux and GNU. (But when using this argumentation
style, we’d probably better take this upstream… except
that upstream may not be helping…)

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2



--
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/pine.bsm.4.64l.1106191908340.20...@herc.mirbsd.org



Bug#611926: eglibc compiles extremely huge binary-indep parts on buildds

2011-02-03 Thread Thorsten Glaser
Source: eglibc
Version: 2.11.2-11

Hi,

when building eglibc with --debbuildopts -B --binary-arch, after taking
a day or so for locales-all ☺ it still creates a source archive in
build-tree/eglibc-2.11.2.tar.xz which I think is for the eglibc-source
arch:all deb. This creates unnecessary burden on all buildds, especially
the slower architectures (think security buildds, too).

Please separate the build-arch and build-indep parts.

Thanks in advance,
//mirabilos
-- 
22:20⎜asarch The crazy that persists in his craziness becomes a master
22:21⎜asarch And the distance between the craziness and geniality is
only measured by the success   22:21⎜mksh it’s a
very thin line anyway… with some, you don’t know which side they’re on



--
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/pine.bsm.4.64l.1102032040040.16...@herc.mirbsd.org



Bug#601126: updated patch

2011-02-03 Thread Thorsten Glaser
Hi,

updated patch. Builds fine, my segfault’s gone too thanks to the
binutils change, and I unearthed another bug we can close. (That
is not in the package I just uploaded, but other than the debian
changelog, nothing differs.)

bye,
//mirabilos
-- 
22:20⎜asarch The crazy that persists in his craziness becomes a master
22:21⎜asarch And the distance between the craziness and geniality is
only measured by the success   22:21⎜mksh it’s a
very thin line anyway… with some, you don’t know which side they’re ondiff -u eglibc-2.11.2/debian/changelog eglibc-2.11.2/debian/changelog
--- eglibc-2.11.2/debian/changelog
+++ eglibc-2.11.2/debian/changelog
@@ -1,3 +1,14 @@
+eglibc (2.11.2-11+m68k.1) unreleased; urgency=low
+
+  * patches/m68k/cvs-fix-sem_t-alignment.patch: new from git (hotfix)
+  * sysdeps/m68k.mk: enable TLS (Closes: #601126) (Closes: #446503)
+- remove libc_extra_config_options (all of them, we have __thread
+  and TLS now; sanity checks were only disabled for linuxthreads)
+- use NPTL instead of linuxthreads
+  * debhelper.in/libc.preinst: require (Debian) 2.6.32 kernel on m68k
+
+ -- Thorsten Glaser t...@mirbsd.de  Wed, 02 Feb 2011 19:11:39 +
+
 eglibc (2.11.2-11) unstable; urgency=low
 
   * patches/kfreebsd/local-sysdeps.diff: remove stub marks for at* 
diff -u eglibc-2.11.2/debian/sysdeps/m68k.mk 
eglibc-2.11.2/debian/sysdeps/m68k.mk
--- eglibc-2.11.2/debian/sysdeps/m68k.mk
+++ eglibc-2.11.2/debian/sysdeps/m68k.mk
@@ -2,2 +2 @@
-libc_add-ons = ports linuxthreads $(add-ons)
-libc_extra_config_options = $(extra_config_options) --disable-sanity-checks 
--without-__thread --without-tls
+libc_add-ons = ports nptl $(add-ons)
diff -u eglibc-2.11.2/debian/patches/series eglibc-2.11.2/debian/patches/series
--- eglibc-2.11.2/debian/patches/series
+++ eglibc-2.11.2/debian/patches/series
@@ -152,6 +152,7 @@
 
 m68k/cvs-define-m68k-tls-relocations.patch
 m68k/cvs-tls-support.patch
+m68k/cvs-fix-sem_t-alignment.patch
 m68k/cvs-versions-def-2-12.patch
 m68k/local-compat.diff
 m68k/local-dwarf2-buildfix.diff
diff -u eglibc-2.11.2/debian/debhelper.in/libc.preinst 
eglibc-2.11.2/debian/debhelper.in/libc.preinst
--- eglibc-2.11.2/debian/debhelper.in/libc.preinst
+++ eglibc-2.11.2/debian/debhelper.in/libc.preinst
@@ -292,33 +292,22 @@
 mips*) realarch=mips;;
   esac
 
-  # The GNU libc requires a = 2.6.18 kernel (except on m68k)
+  # The GNU libc requires a = 2.6.32-3 Debian kernel on m68k
+  # for TLS, or a = 2.6.18 kernel on all other architectures
   if [ $realarch != m68k ]
   then
-  if linux_compare_versions $kernel_ver lt 2.6.18
-  then
-  echo WARNING: this version of the GNU libc requires kernel 
version
-  echo 2.6.18 or later.  Please upgrade your kernel before 
installing
-  echo glibc.
-  kernel26_help
-
-  exit 1
-  fi
+  vmin=2.6.18
+  else
+  vmin=2.6.32
   fi
-
-  # The GNU libc is now built with --with-kernel= = 2.4.1 on m68k
-  if [ $realarch = m68k ]
+  if linux_compare_versions $kernel_ver lt ${vmin}
   then
-  if linux_compare_versions $kernel_ver lt 2.4.1
-  then
-  echo WARNING: This version of glibc requires that you be running
-  echo kernel version 2.4.1 or later.  Earlier kernels contained
-  echo bugs that may render the system unusable if a modern version
-  echo of glibc is installed.
-  kernel26_help
+  echo WARNING: this version of the GNU libc requires kernel version
+  echo ${vmin} or later.  Please upgrade your kernel before installing
+  echo glibc.
+  kernel26_help
 
-  exit 1
-  fi
+  exit 1
   fi
 
   # From glibc 2.6-3 SPARC V8 support is dropped.
only in patch2:
unchanged:
--- eglibc-2.11.2.orig/debian/patches/m68k/cvs-fix-sem_t-alignment.patch
+++ eglibc-2.11.2/debian/patches/m68k/cvs-fix-sem_t-alignment.patch
@@ -0,0 +1,65 @@
+This series of m68k related commits fixes alignment of sem_t due to
+the kernel using the lower two bit for internal purposes, whereas on
+Linux/m68k, the alignment of long is not natural. I refrain from
+patching a ChangeLog file, since I saw this break with gcc earlier.
+ -- tg@d.o
+
+From: Andreas Schwab sch...@linux-m68k.org
+Date: Sun, 2 Jan 2011 19:14:41 + (+0100)
+Subject: m68k: force alignment of sem_t
+X-Git-Tag: glibc-2.13~7
+X-Git-Url: 
http://sourceware.org/git/?p=glibc-ports.git;a=commitdiff_plain;h=9524dbd1f3f91a9b381bb0e17dc5e150fe8be75a
+
+m68k: force alignment of sem_t
+---
+
+#diff --git a/ChangeLog.m68k b/ChangeLog.m68k
+#index ccd8b4e..feba28e 100644
+#--- a/ChangeLog.m68k
+#+++ b/ChangeLog.m68k
+#@@ -1,3 +1,8 @@
+#+2011-01-10  Andreas Schwab  sch...@linux-m68k.org
+#+
+#+ * sysdeps/unix/sysv/linux/m68k/nptl/bits/semaphore.h (sem_t):
+#+ Force alignment.
+#+
+# 2010-12-26  Andreas Schwab

Bug#601126: eglibc: [m68k] please apply patch for TLS support

2011-01-28 Thread Thorsten Glaser
Hi,

another (updated) version of the patch, changelog collapsed and a
“Closes” tag added; hotfix sync’d from git repository.

Builds on amd64… m68k takes a few days longer ☺

bye,
//mirabilos
-- 
22:20⎜asarch The crazy that persists in his craziness becomes a master
22:21⎜asarch And the distance between the craziness and geniality is
only measured by the success   22:21⎜mksh it’s a
very thin line anyway… with some, you don’t know which side they’re ondiff -u eglibc-2.11.2/debian/changelog eglibc-2.11.2/debian/changelog
--- eglibc-2.11.2/debian/changelog
+++ eglibc-2.11.2/debian/changelog
@@ -1,3 +1,14 @@
+eglibc (2.11.2-10+m68k.1) unreleased; urgency=low
+
+  * patches/m68k/cvs-fix-sem_t-alignment.patch: new from git (hotfix)
+  * sysdeps/m68k.mk: switch m68k to TLS (Closes: #601126)
+- remove libc_extra_config_options (all of them, we have __thread
+  and TLS now; sanity checks were only disabled for linuxthreads)
+- use NPTL instead of linuxthreads
+  * debhelper.in/libc.preinst: require (Debian) 2.6.32 kernel on m68k
+
+ -- Thorsten Glaser t...@mirbsd.de  Sat, 29 Jan 2011 00:37:03 +0100
+
 eglibc (2.11.2-10) unstable; urgency=low
 
   * Add patches/amd64/cvs-avx-tcb-alignment.diff from upstream to fix 
diff -u eglibc-2.11.2/debian/debhelper.in/libc.preinst 
eglibc-2.11.2/debian/debhelper.in/libc.preinst
--- eglibc-2.11.2/debian/debhelper.in/libc.preinst
+++ eglibc-2.11.2/debian/debhelper.in/libc.preinst
@@ -292,33 +292,22 @@
 mips*) realarch=mips;;
   esac
 
-  # The GNU libc requires a = 2.6.18 kernel (except on m68k)
+  # The GNU libc requires a = 2.6.32-3 Debian kernel on m68k
+  # for TLS, or a = 2.6.18 kernel on all other architectures
   if [ $realarch != m68k ]
   then
-  if linux_compare_versions $kernel_ver lt 2.6.18
-  then
-  echo WARNING: this version of the GNU libc requires kernel 
version
-  echo 2.6.18 or later.  Please upgrade your kernel before 
installing
-  echo glibc.
-  kernel26_help
-
-  exit 1
-  fi
+  vmin=2.6.18
+  else
+  vmin=2.6.32
   fi
-
-  # The GNU libc is now built with --with-kernel= = 2.4.1 on m68k
-  if [ $realarch = m68k ]
+  if linux_compare_versions $kernel_ver lt ${vmin}
   then
-  if linux_compare_versions $kernel_ver lt 2.4.1
-  then
-  echo WARNING: This version of glibc requires that you be running
-  echo kernel version 2.4.1 or later.  Earlier kernels contained
-  echo bugs that may render the system unusable if a modern version
-  echo of glibc is installed.
-  kernel26_help
+  echo WARNING: this version of the GNU libc requires kernel version
+  echo ${vmin} or later.  Please upgrade your kernel before installing
+  echo glibc.
+  kernel26_help
 
-  exit 1
-  fi
+  exit 1
   fi
 
   # From glibc 2.6-3 SPARC V8 support is dropped.
diff -u eglibc-2.11.2/debian/sysdeps/m68k.mk 
eglibc-2.11.2/debian/sysdeps/m68k.mk
--- eglibc-2.11.2/debian/sysdeps/m68k.mk
+++ eglibc-2.11.2/debian/sysdeps/m68k.mk
@@ -2,2 +2 @@
-libc_add-ons = ports linuxthreads $(add-ons)
-libc_extra_config_options = $(extra_config_options) --disable-sanity-checks 
--without-__thread --without-tls
+libc_add-ons = ports nptl $(add-ons)
diff -u eglibc-2.11.2/debian/patches/series eglibc-2.11.2/debian/patches/series
--- eglibc-2.11.2/debian/patches/series
+++ eglibc-2.11.2/debian/patches/series
@@ -152,6 +152,7 @@
 
 m68k/cvs-define-m68k-tls-relocations.patch
 m68k/cvs-tls-support.patch
+m68k/cvs-fix-sem_t-alignment.patch
 m68k/cvs-versions-def-2-12.patch
 m68k/local-compat.diff
 m68k/local-dwarf2-buildfix.diff
only in patch2:
unchanged:
--- eglibc-2.11.2.orig/debian/patches/m68k/cvs-fix-sem_t-alignment.patch
+++ eglibc-2.11.2/debian/patches/m68k/cvs-fix-sem_t-alignment.patch
@@ -0,0 +1,65 @@
+This series of m68k related commits fixes alignment of sem_t due to
+the kernel using the lower two bit for internal purposes, whereas on
+Linux/m68k, the alignment of long is not natural. I refrain from
+patching a ChangeLog file, since I saw this break with gcc earlier.
+ -- tg@d.o
+
+From: Andreas Schwab sch...@linux-m68k.org
+Date: Sun, 2 Jan 2011 19:14:41 + (+0100)
+Subject: m68k: force alignment of sem_t
+X-Git-Tag: glibc-2.13~7
+X-Git-Url: 
http://sourceware.org/git/?p=glibc-ports.git;a=commitdiff_plain;h=9524dbd1f3f91a9b381bb0e17dc5e150fe8be75a
+
+m68k: force alignment of sem_t
+---
+
+#diff --git a/ChangeLog.m68k b/ChangeLog.m68k
+#index ccd8b4e..feba28e 100644
+#--- a/ChangeLog.m68k
+#+++ b/ChangeLog.m68k
+#@@ -1,3 +1,8 @@
+#+2011-01-10  Andreas Schwab  sch...@linux-m68k.org
+#+
+#+ * sysdeps/unix/sysv/linux/m68k/nptl/bits/semaphore.h (sem_t):
+#+ Force alignment.
+#+
+# 2010-12-26  Andreas Schwab  sch...@linux-m68k.org
+# 
+#  * sysdeps/m68k/stackinfo.h

Bug#601126: Updated patch FIXING IMPORTANT BUG on m68k

2011-01-10 Thread Thorsten Glaser
Hi,

please apply the attached patch instead, it unbreaks sem_wait()
used by boehm-gc/gcj on m68k. Diff to the previous one from
Andreas Schwab. (The jump from .1 to .4 is since I’ve had some
intermediate test versions.)

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.rdiff -u eglibc-2.11.2/debian/changelog eglibc-2.11.2/debian/changelog
--- eglibc-2.11.2/debian/changelog
+++ eglibc-2.11.2/debian/changelog
@@ -1,3 +1,24 @@
+eglibc (2.11.2-7+m68k.4) unreleased; urgency=low
+
+  * debian/sysdeps/m68k.mk: set libc_MIN_KERNEL_SUPPORTED back
+to 2.4.1 to retain compatibility code; version checking is
+done in debian/debhelper.in/libc.preinst anyway so no harm
+  * debian/patches/m68k/local-fix-semaphore.diff: new from ML
+
+ -- Thorsten Glaser t...@mirbsd.de  Mon, 03 Jan 2011 00:08:37 +
+
+eglibc (2.11.2-7+m68k.1) unreleased; urgency=low
+
+  * debian/sysdeps/m68k.mk: switch m68k to TLS
+- use nptl instead of linuxthreads
+- remove libc_extra_config_options (all of them, we have __thread
+  and tls now; sanity checks were only disabled for linuxthreads)
+- raise minimum kernel version to 2.6.16 and document why we can't
+  set it to 2.6.32 (Debian) yet which would be correct/desired
+  * debian/debhelper.in/libc.preinst: require 2.6.32 kernel on m68k
+
+ -- Thorsten Glaser t...@mirbsd.de  Mon, 01 Nov 2010 15:09:16 +
+
 eglibc (2.11.2-7) unstable; urgency=low
 
   [ Samuel Thibault ]
diff -u eglibc-2.11.2/debian/debhelper.in/libc.preinst 
eglibc-2.11.2/debian/debhelper.in/libc.preinst
--- eglibc-2.11.2/debian/debhelper.in/libc.preinst
+++ eglibc-2.11.2/debian/debhelper.in/libc.preinst
@@ -292,33 +292,22 @@
 mips*) realarch=mips;;
   esac
 
-  # The GNU libc requires a = 2.6.18 kernel (except on m68k)
+  # The GNU libc requires a = 2.6.32-3 Debian kernel on m68k
+  # for TLS, or a = 2.6.18 kernel on all other architectures
   if [ $realarch != m68k ]
   then
-  if linux_compare_versions $kernel_ver lt 2.6.18
-  then
-  echo WARNING: this version of the GNU libc requires kernel 
version
-  echo 2.6.18 or later.  Please upgrade your kernel before 
installing
-  echo glibc.
-  kernel26_help
-
-  exit 1
-  fi
+  vmin=2.6.18
+  else
+  vmin=2.6.32
   fi
-
-  # The GNU libc is now built with --with-kernel= = 2.4.1 on m68k
-  if [ $realarch = m68k ]
+  if linux_compare_versions $kernel_ver lt ${vmin}
   then
-  if linux_compare_versions $kernel_ver lt 2.4.1
-  then
-  echo WARNING: This version of glibc requires that you be running
-  echo kernel version 2.4.1 or later.  Earlier kernels contained
-  echo bugs that may render the system unusable if a modern version
-  echo of glibc is installed.
-  kernel26_help
+  echo WARNING: this version of the GNU libc requires kernel version
+  echo ${vmin} or later.  Please upgrade your kernel before installing
+  echo glibc.
+  kernel26_help
 
-  exit 1
-  fi
+  exit 1
   fi
 
   # From glibc 2.6-3 SPARC V8 support is dropped.
diff -u eglibc-2.11.2/debian/sysdeps/m68k.mk 
eglibc-2.11.2/debian/sysdeps/m68k.mk
--- eglibc-2.11.2/debian/sysdeps/m68k.mk
+++ eglibc-2.11.2/debian/sysdeps/m68k.mk
@@ -2,2 +2 @@
-libc_add-ons = ports linuxthreads $(add-ons)
-libc_extra_config_options = $(extra_config_options) --disable-sanity-checks 
--without-__thread --without-tls
+libc_add-ons = ports nptl $(add-ons)
diff -u eglibc-2.11.2/debian/patches/series eglibc-2.11.2/debian/patches/series
--- eglibc-2.11.2/debian/patches/series
+++ eglibc-2.11.2/debian/patches/series
@@ -159,6 +159,7 @@
 m68k/local-reloc.diff
 m68k/local-pthread_lock.diff
 m68k/submitted-gcc34-seccomment.diff
+m68k/local-fix-semaphore.diff
 
 mips/cvs-mips-atomic_h.diff
 mips/cvs-non-pic-n32-64-syscall.diff
only in patch2:
unchanged:
--- eglibc-2.11.2.orig/debian/patches/m68k/local-fix-semaphore.diff
+++ eglibc-2.11.2/debian/patches/m68k/local-fix-semaphore.diff
@@ -0,0 +1,32 @@
+From sch...@linux-m68k.org Sun Jan  2 20:08:54 2011
+From: Andreas Schwab sch...@linux-m68k.org
+Message-ID: m2bp3z5b77@igel.home
+Date: Sun, 02 Jan 2011 20:59:08 +0100
+Subject: Re: Another gcj (boehm-gc?) related FTBFS for y’all to look at
+
+Please try this patch.
+
+Andreas.
+
+diff --git a/sysdeps/unix/sysv/linux/m68k/nptl/bits/semaphore.h 
b/sysdeps/unix/sysv/linux/m68k/nptl/bits/semaphore.h
+index 2950cc9..baaa9eb 100644
+--- a/ports/sysdeps/unix/sysv/linux/m68k/nptl/bits/semaphore.h
 b/ports/sysdeps/unix/sysv/linux/m68k/nptl/bits/semaphore.h
+@@ -1,4 +1,4

Bug#603914: Please drop non-UTF8 locales

2011-01-09 Thread Thorsten Glaser
Roger Leigh dixit:

From my reading of the standards a UTF-8 C locale would be required
to behave identically to the existing ASCII C locale:

• will consider all byte sequences valid

I think it wouldn’t (since UTF-8 mbrtowc/wcrtomb don’t work
this way, and it can’t be done with “just” the POSIX API
anyway because they aren’t allowed to not read any input
byte when outputting (in MirBSD, I’ve added a sister func-
tion to mbrtowc which can do that), so not everything can
be accepted in all situations.

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr



--
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/pine.bsm.4.64l.1101092219210.17...@herc.mirbsd.org



Bug#603914: Please drop non-UTF8 locales

2011-01-09 Thread Thorsten Glaser
Roger Leigh dixit:

I think the all byte sequences valid applies mainly to narrow
character I/O.  i.e. printf/puts etc. won't alter, drop or otherwise
mangle any non 7-bit-ASCII codes.  i.e. I think the intent was to
ensure 8-bit cleanliness in a 7-bit locale.  This naturally extends
to UTF-8.  I'm not sure that wide character support is implied here,
given that it implicity requires correct byte sequences to function
where the narrow character I/O does not (all 8-bit codes are correct).

I was thinking in terms of programmes doing operation on wide characters
internally (for example, tr was the first one I switched to wide charac-
ters, since in MirBSD they use 16 bit, and the table driven design con-
tinued to work; this is also where I noticed the problem). Those are the
programmes you want to be aware of: they _are_ internationalised, thus
use wchar_t and multibytes and narrow I/O, or wchar_t and wide I/O, and
these will benefit from the C.UTF-8 locale; others (that just run on
byte strings as if they were characters) don’t see a difference between
it and the classical C locale anyway.

What I mean is, we try to use C.UTF-8 in places where we want to run
on text in UTF-8 but otherwise keep the normed predictable uniform
behaviour of C; in places where we operate on binary data C is pro-
bably more useful.

Hum. Do I make any sense?

Goodnight,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2



--
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/pine.bsm.4.64l.1101100139410.13...@herc.mirbsd.org



Bug#603914: Please drop non-UTF8 locales

2010-11-28 Thread Thorsten Glaser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384

Hi!

Fun to be reading this. Me like ;-)

Anyway. With my Debian hat on, the C/POSIX locales must not use
UTF-8 as encoding, because otherwise, all kind of hell breaks
loose (consider running 'tr u x' on a binary or other legacy
encoded text file, and tr is just an example). There are plans
for C.UTF-8 though, and I’m a bit ashamed at having slacked off
there…

In MirBSD, I added a ‘-l’ command line option to script(1) to
do the encoding for latin1-based terminals. This might just do
the trick. If desired, I’ll prepare a patch against Debian’s.

bye,
//mirabilos
- -- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MirBSD)

iQIVAwUBTPKPjna1NLLpkAfgAQnnNw/+LVEpYQdC0b1WjP3A831Sf/obHvVN7pEM
7sgAXuZjK5CF5l7vtzD0wrDpNtlCt24tvKFDK5sIEtzFoB/Y5vjC1fng96J5iO9i
rOGQ38C3yoyNJveh+IMoNIx13DtxlSww6nTa5FPocUltUwR8uYreR6a5KlumCflo
gtJtjGytkVFWM8BoR+Ou4bZ3QhdN+AWcwyCcRxvGJD4pDHQLNSiLR5JaRattktmi
W+tQNrKUAt6QJMsliyC4p37TD3n9g/8slvnX8PtvOl3xiwgPavO3Dca3KwoAHXAC
lXQ1hmMuG74GGkWZVU/Rs3/0zSdSkTjPFwW8snvvXGLqt1FBlSH07q37Q8qmeNqt
RF/QS4I9TE05NjoEjTjFrfp+RelP7toeQAEC8E5Z2QTgA2/eWx/y8F1AvoZlJl9K
90rJv7kjlVeBh9EmgHfUJ5a2HLW4e0zn5j7ez3/jxENwMQbL+jCdgywOL+CTnzJ4
0XQaHT7fQBx9c8awmnwfrloDuYdZ0+JF8+/H30816ReASJKpQEm6wxftKRxBJVxK
NXdz2RuwEOg4xFS9lu//w8rQW24I7dJxS99O7mJJqYhXTVHfAGOGxyEQsnT9lj2V
+XKUpIKBlF9Fy7jjCPEjaUYlavlJIsJJVmGnDuZbxF0h8UuLFAdOXUgMrR+QFsX+
0CSa54mTjNc=
=EefN
-END PGP SIGNATURE-



--
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/pine.bsm.4.64l.1011281721290.27...@herc.mirbsd.org



[m68k] res_init segfault, need help debugging

2010-11-28 Thread Thorsten Glaser
Hi,

I’ve got a rather weird problem on m68k (with the patches I sent
to #601126 applied), stripped down:

ara2:~# cat x.c
#include netinet/in.h
#include arpa/nameser.h
#include resolv.h

int
main(void)
{
return (res_init());
}
ara2:~# gcc x.c
ara2:~# ./a.out
Segmentation fault

I don’t get much help out of gdb, unfortunately.
Basically, the segfault is on accessing _res.retrans
in line 67 (first access of _res), but in gdb, this
works, _res is at 0xc014de20 and call __res_state()
yields -1072374240 which is the same. Its contents
are all NUL of course.

I tried lowering the minimum kernel version back
to 2.4.1 with no success. This problem makes both
openntpd and sendmail SIGSEGV instead of starting.

Any help in debugging this welcome. Please keep me
in Cc: as I’m not subscribed to this list.

bye,
//mirabilos
-- 
20:54⎜SvenG:#grml dmaphy: remember: In theory there's no difference
 ⎜ between theory and practice, but in practice...


--
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/pine.bsm.4.64l.1011281708410.27...@herc.mirbsd.org



Bug#601126: updated patch

2010-11-02 Thread Thorsten Glaser
Hi,

after the last upload I rebuilt. Hope this helps.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Huntdiff -u eglibc-2.11.2/debian/changelog eglibc-2.11.2/debian/changelog
--- eglibc-2.11.2/debian/changelog
+++ eglibc-2.11.2/debian/changelog
@@ -1,3 +1,15 @@
+eglibc (2.11.2-7+m68k.1) unreleased; urgency=low
+
+  * debian/sysdeps/m68k.mk: switch m68k to TLS
+- use nptl instead of linuxthreads
+- remove libc_extra_config_options (all of them, we have __thread
+  and tls now; sanity checks were only disabled for linuxthreads)
+- raise minimum kernel version to 2.6.16 and document why we can't
+  set it to 2.6.32 (Debian) yet which would be correct/desired
+  * debian/debhelper.in/libc.preinst: require 2.6.32 kernel on m68k
+
+ -- Thorsten Glaser t...@mirbsd.de  Mon, 01 Nov 2010 15:09:16 +
+
 eglibc (2.11.2-7) unstable; urgency=low
 
   [ Samuel Thibault ]
diff -u eglibc-2.11.2/debian/debhelper.in/libc.preinst 
eglibc-2.11.2/debian/debhelper.in/libc.preinst
--- eglibc-2.11.2/debian/debhelper.in/libc.preinst
+++ eglibc-2.11.2/debian/debhelper.in/libc.preinst
@@ -292,33 +292,22 @@
 mips*) realarch=mips;;
   esac
 
-  # The GNU libc requires a = 2.6.18 kernel (except on m68k)
+  # The GNU libc requires a = 2.6.32-3 Debian kernel on m68k
+  # for TLS, or a = 2.6.18 kernel on all other architectures
   if [ $realarch != m68k ]
   then
-  if linux_compare_versions $kernel_ver lt 2.6.18
-  then
-  echo WARNING: this version of the GNU libc requires kernel 
version
-  echo 2.6.18 or later.  Please upgrade your kernel before 
installing
-  echo glibc.
-  kernel26_help
-
-  exit 1
-  fi
+  vmin=2.6.18
+  else
+  vmin=2.6.32
   fi
-
-  # The GNU libc is now built with --with-kernel= = 2.4.1 on m68k
-  if [ $realarch = m68k ]
+  if linux_compare_versions $kernel_ver lt ${vmin}
   then
-  if linux_compare_versions $kernel_ver lt 2.4.1
-  then
-  echo WARNING: This version of glibc requires that you be running
-  echo kernel version 2.4.1 or later.  Earlier kernels contained
-  echo bugs that may render the system unusable if a modern version
-  echo of glibc is installed.
-  kernel26_help
+  echo WARNING: this version of the GNU libc requires kernel version
+  echo ${vmin} or later.  Please upgrade your kernel before installing
+  echo glibc.
+  kernel26_help
 
-  exit 1
-  fi
+  exit 1
   fi
 
   # From glibc 2.6-3 SPARC V8 support is dropped.
diff -u eglibc-2.11.2/debian/sysdeps/m68k.mk 
eglibc-2.11.2/debian/sysdeps/m68k.mk
--- eglibc-2.11.2/debian/sysdeps/m68k.mk
+++ eglibc-2.11.2/debian/sysdeps/m68k.mk
@@ -1,3 +1,5 @@
-libc_MIN_KERNEL_SUPPORTED = 2.4.1
-libc_add-ons = ports linuxthreads $(add-ons)
-libc_extra_config_options = $(extra_config_options) --disable-sanity-checks 
--without-__thread --without-tls
+# actually, Debian 2.6.32-23 and up, or Mainline 2.6.34
+# but we need the compatibility functions compiled in through
+# this until patched appropriately
+libc_MIN_KERNEL_SUPPORTED = 2.6.16
+libc_add-ons = ports nptl $(add-ons)


Bug#601126: eglibc: [m68k] please apply patch for m68k TLS support

2010-10-23 Thread Thorsten Glaser
Source: eglibc
Version: 2.11.2-6
Severity: wishlist
Tags: patch

Hi,

please apply the attached debdiff, which after discussion on the
Debian m68k mailing list with great help from Finn Thain will
make eglibc build with TLS support on m68k given both kernel and
toolchain that support it. (These are not currently in the ar-
chive, but uploads will be made once cleanly built packages are
available – I’m sorta re-bootstrapping the port – and as newer
libcs than 2.5 have never been built on m68k, won’t hurt.)

Thanks!
diff -u eglibc-2.11.2/debian/changelog eglibc-2.11.2/debian/changelog
--- eglibc-2.11.2/debian/changelog
+++ eglibc-2.11.2/debian/changelog
@@ -1,3 +1,15 @@
+eglibc (2.11.2-6+m68k.2) unreleased; urgency=low
+
+  * debian/sysdeps/m68k.mk: switch m68k to TLS
+- use nptl instead of linuxthreads
+- remove libc_extra_config_options (all of them, we have __thread
+  and tls now; sanity checks were only disabled for linuxthreads)
+- raise minimum kernel version to 2.6.16 and document why we can't
+  set it to 2.6.32 (Debian) yet which would be correct/desired
+  * debian/debhelper.in/libc.preinst: require 2.6.32 kernel on m68k
+
+ -- Thorsten Glaser t...@mirbsd.de  Fri, 22 Oct 2010 10:01:02 +
+
 eglibc (2.11.2-6) unstable; urgency=low
 
   [ Aurelien Jarno ]
diff -u eglibc-2.11.2/debian/debhelper.in/libc.preinst eglibc-2.11.2/debian/debhelper.in/libc.preinst
--- eglibc-2.11.2/debian/debhelper.in/libc.preinst
+++ eglibc-2.11.2/debian/debhelper.in/libc.preinst
@@ -292,33 +292,22 @@
 mips*) realarch=mips;;
   esac
 
-  # The GNU libc requires a = 2.6.18 kernel (except on m68k)
+  # The GNU libc requires a = 2.6.32-3 Debian kernel on m68k
+  # for TLS, or a = 2.6.18 kernel on all other architectures
   if [ $realarch != m68k ]
   then
-  if linux_compare_versions $kernel_ver lt 2.6.18
-  then
-  echo WARNING: this version of the GNU libc requires kernel version
-  echo 2.6.18 or later.  Please upgrade your kernel before installing
-  echo glibc.
-  kernel26_help
-
-  exit 1
-  fi
+  vmin=2.6.18
+  else
+  vmin=2.6.32
   fi
-
-  # The GNU libc is now built with --with-kernel= = 2.4.1 on m68k
-  if [ $realarch = m68k ]
+  if linux_compare_versions $kernel_ver lt ${vmin}
   then
-  if linux_compare_versions $kernel_ver lt 2.4.1
-  then
-  echo WARNING: This version of glibc requires that you be running
-  echo kernel version 2.4.1 or later.  Earlier kernels contained
-  echo bugs that may render the system unusable if a modern version
-  echo of glibc is installed.
-  kernel26_help
+  echo WARNING: this version of the GNU libc requires kernel version
+  echo ${vmin} or later.  Please upgrade your kernel before installing
+  echo glibc.
+  kernel26_help
 
-  exit 1
-  fi
+  exit 1
   fi
 
   # From glibc 2.6-3 SPARC V8 support is dropped.
diff -u eglibc-2.11.2/debian/sysdeps/m68k.mk eglibc-2.11.2/debian/sysdeps/m68k.mk
--- eglibc-2.11.2/debian/sysdeps/m68k.mk
+++ eglibc-2.11.2/debian/sysdeps/m68k.mk
@@ -1,3 +1,5 @@
-libc_MIN_KERNEL_SUPPORTED = 2.4.1
-libc_add-ons = ports linuxthreads $(add-ons)
-libc_extra_config_options = $(extra_config_options) --disable-sanity-checks --without-__thread --without-tls
+# actually, Debian 2.6.32-23 and up, or Mainline 2.6.34
+# but we need the compatibility functions compiled in through
+# this until patched appropriately
+libc_MIN_KERNEL_SUPPORTED = 2.6.16
+libc_add-ons = ports nptl $(add-ons)


Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale

2010-09-03 Thread Thorsten Glaser
Samuel Thibault dixit:

believe that's something that shouldn't break Squeeze at all.

I also believe it cannot possibly do that.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2


--
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/pine.bsm.4.64l.1009031621090.1...@herc.mirbsd.org



Bug#555168: Fwd: [Bug localedata/11213] localedata licencing issues

2010-04-04 Thread Thorsten Glaser
Arrgh,

h̲e̲ strikes again. For some of the files, one thinks “w̲h̲i̲c̲h̲ licences”.
I for one don’t know who the authors of these are (they aren’t even
listed usually). Sorry, but I tried at least.

//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

-- Forwarded message --
From: drepper at redhat dot com sourceware-bugzi...@sourceware.org
Message-ID: 20100404183053.26950.qm...@sourceware.org
Date: 4 Apr 2010 18:30:53 -
Subject: [Bug localedata/11213] localedata licencing issues


--- Additional Comments From drepper at redhat dot com  2010-04-04 18:30 
---
I'm not going to do any of that.  The licenses are all fine with me.  If
somebody has problems they have to do the work.

-- 
   What|Removed |Added

 Status|NEW |SUSPENDED


http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.



--
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/pine.bsm.4.64l.1004041947520.13...@herc.mirbsd.org



Bug#551879: libc6-i686: can no longer resolve DNS names

2009-10-21 Thread Thorsten Glaser
Package: libc6-i686
Version: 2.10.1-1
Severity: important

This is on a Debian etch system, which contains both a lenny and
a sid schroot.

I first noticed that reportbug failed in the sid system, and lynx
does too, after testing. Below is the output from the also failing
wget. I’m submitting this here because I strongly believe that DNS
has worked when I a-g d-u’d a day or two ago, when I got eglibc 2.10.


t...@frozenfish:~ $ ping bugs.debian.org
PING bugs.debian.org (140.211.166.43) 56(84) bytes of data.
64 bytes from rietz.debian.org (140.211.166.43): icmp_seq=1 ttl=47 time=175 ms
64 bytes from rietz.debian.org (140.211.166.43): icmp_seq=2 ttl=47 time=176 ms

--- bugs.debian.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 175.955/176.047/176.140/0.429 ms
t...@frozenfish:~ $ wget -O /dev/null http://bugs.debian.org/debmirror
--2009-10-21 12:27:12--  http://bugs.debian.org/debmirror
Resolving bugs.debian.org... failed: No address associated with hostname.
wget: unable to resolve host address bugs.debian.org


The lenny schroot on the same system outputs:

t...@frozenfish:~ $ wget -O /dev/null http://bugs.debian.org/debmirror
--2009-10-21 12:31:35--  http://bugs.debian.org/debmirror
Resolving bugs.debian.org... 137.82.84.77, 140.211.166.43
Connecting to bugs.debian.org|137.82.84.77|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debmirror;dist=unstable 
[following]
--2009-10-21 12:31:36--  
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debmirror;dist=unstable
Reusing existing connection to bugs.debian.org:80.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: /dev/null'

[   = ] 
37,947  66.4K/s   in 0.6s

2009-10-21 12:31:39 (66.4 KB/s) - /dev/null' saved [37947]



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: Bug#551879: libc6-i686: can no longer resolve DNS names

2009-10-21 Thread Thorsten Glaser
Dixi quod…

I first noticed that reportbug failed in the sid system, and lynx
does too, after testing. Below is the output from the also failing
wget. Ibhas worked when I a-g d-ub

Thanks to Mika Prokop, I now know the solution:

14:36⎜* mira|AO:#grml t...@frozenfish:~ $ sudo touch SID/etc/hosts

Maybe the postinst scripts should do that [ ! -x /etc/hosts ] auto-
matically? It’s still a rather serious bug for chroots.

bye,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#522774: Fwd: [issues] glibc uses '__unused' as identifier, which is traditionally used by BSD as macro

2009-07-29 Thread Thorsten Glaser
Hi package maintainers,

maybe you can do such a thing during package installation?
This would tremendously help porting software (liberal in
what one accepts), such as NetBSD® makefs (ITP: #538171 –
for now I worked around the issue in it).

-- Forwarded message --
From: Thorsten Glaser t...@mirbsd.de
Message-ID: pine.bsm.4.64l.0905071822510.15...@herc.mirbsd.org
To: iss...@eglibc.org
Date: Thu, 7 May 2009 18:25:26 + (UTC)
Subject: Re: [issues] glibc uses '__unused' as identifier,
which is traditionally used by BSD as macro

Joseph S. Myers dixit:

There is cost associated with divergence between FSF glibc and EGLIBC that
comes into play every merge

I do have a suggestion. Maybe we can get into an agreement still…

How about you use the following sed expression on installation?
This way you’d only have to change the Makefile.in in question.

s/[[::]]__unused[[::]]/_/g

I do not know if your sed(1) does [[::]] and [[::]], ours does,
see http://www.mirbsd.org/man7/re_format – if not, something si-
milar would probably be possible.

As __unused* should never be used from userland, this would work
I think.


Comments?
//mirabilos
-- 
 Hi, does anyone sell openbsd stickers by themselves and not packaged
 with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#522774: libc6-dev: uses “__unused” as identifier, which is traditionally used by BSD as macro

2009-04-06 Thread Thorsten Glaser
Package: libc6-dev
Version: 2.9-6
Severity: wishlist

(mass filing with linux-libc-dev and libc6-dev)

/usr/include/aio.h:  char __unused[32];
/usr/include/aio.h:  char __unused[32];
/usr/include/bits/stat.h:long int __unused[3];
/usr/include/bits/stat.h:long int __unused[3];
/usr/include/bits/utmp.h:  char __unused[20];   /* Reserved for future 
use.  */
/usr/include/bits/utmpx.h:  char __unused[20];  /* Reserved for future 
use.  */
/usr/include/netdb.h:  int __unused[5];
/usr/include/netinet/ip_icmp.h:  u_int16_t  __unused;

These conflict with the traditional use of __unused by the BSDs, which
predates use of __unused as identifier by Linux and glibc headers.

For example, the Debian package libbsd-dev includes the following code:

#ifndef __unused
# ifdef __GNUC__
#  define __unused __attribute__((unused))
# else
#  define __unused
# endif
#endif

It however was ifdef’d out due to this problem. A personal package of
mine, mirmake, fails to build on more recent Debian systems because it
does _not_ ifdef it out, since otherwise, some BSD software cannot be
compiled (without extra patches).

Please file this bug with your respective upstreams *and* patch the
header files in question yourselves, to bridge over the response time
waiting for upstream to fix it.

Thanks!


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh

Versions of packages libc6-dev depends on:
ii  libc6 2.9-6  GNU C Library: Shared libraries
ii  linux-libc-dev2.6.29-2   Linux support headers for userspac

Versions of packages libc6-dev recommends:
ii  gcc [c-compiler]  4:4.3.3-2  The GNU C compiler
ii  gcc-3.4 [c-compiler]  3.4.6-9The GNU C compiler
ii  gcc-4.1 [c-compiler]  4.1.2-25   The GNU C compiler
ii  gcc-4.3 [c-compiler]  4.3.3-5The GNU C compiler

Versions of packages libc6-dev suggests:
ii  glibc-doc 2.9-6  GNU C Library: Documentation
ii  manpages-dev  3.17-1 Manual pages about using GNU/Linux

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#522781: locales-all: fails to install on hurd-i386

2009-04-06 Thread Thorsten Glaser
Package: locales-all
Version: 2.9-6
Severity: normal

This is probably the same as #274699 as the error is the same,
and I’ll mark it as blocking this bug after reporting.

mksh FTBFS on hurd-i386 because its dependency locales-all is
not installable: #522777

http://buildd.debian-ports.org/fetch.php?pkg=mksharch=hurd-i386ver=37.2-1stamp=1238962232file=logas=raw

Setting up locales-all (2.9-3) ...
cannot lock new archive: Not supported
dpkg: error processing locales-all (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 locales-all
E: Sub-process /usr/bin/dpkg returned an error code (1)
apt-get failed.
Package installation failed


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh

Versions of packages locales-all depends on:
ii  libc6 [glibc-2.9-1]   2.9-6  GNU C Library: Shared libraries
ii  lzma  4.43-14Compression method of 7z format in

locales-all recommends no packages.

locales-all suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#428884: bashism in init script fails to start nscd

2007-06-14 Thread Thorsten Glaser
Package: nscd
Version: 2.3.6.ds1-8
Severity: important
Tags: patch

Hi,

I've reported a similar bug to the sendmail-bin postinst script
some time ago, you'll find it at
| http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424213
for reference and deeper information.

The script defines a shell function stop(), however, all Korn
shells have stop defined as builtin alias (unalias would work,
but in the below patch, I've renamed the stop() function and,
for consistency, the start() function).

Maybe someone should scan all Debian packages for that issue.

I'd be appreciated if you apply the patch in a follow-up release,
as Debian Policy states that scripts beginning with #!/bin/sh must
be portable.

Thanks!


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/mksh
Kernel: Linux 2.6.18-4-k7
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages nscd depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries

nscd recommends no packages.
--- nscd.orig   2007-06-14 22:07:35.0 +
+++ /etc/init.d/nscd2007-06-14 22:08:07.0 +
@@ -21,7 +21,7 @@ umask 022
 [ -x $DAEMON ] || exit 0
 [ -d /var/run/nscd ] || mkdir -p /var/run/nscd
 
-start()
+start_nscd()
 {
# Return
#   0 if daemon has been started
@@ -40,7 +40,7 @@ start()
$SECURE || return 2
 }
 
-stop()
+stop_nscd()
 {
# Return
#   0 if daemon has been stopped
@@ -68,7 +68,7 @@ status()
 case $1 in
 start)
echo -n Starting $DESC: $NAME
-   start
+   start_nscd
case $? in
0) echo . ; exit 0 ;;
1) echo  (already running). ; exit 0 ;;
@@ -77,7 +77,7 @@ start)
;;
 stop)
echo -n Stopping $DESC: $NAME
-   stop
+   stop_nscd
case $? in
0) echo . ; exit 0 ;;
1) echo  (not running). ; exit 0 ;;
@@ -86,11 +86,11 @@ stop)
;;
 restart|force-reload|reload)
echo -n Restarting $DESC: $NAME
-   stop
+   stop_nscd
$DAEMON --invalidate passwd --invalidate group
case $? in
0|1)
-   start
+   start_nscd
case $? in
0) echo . ; exit 0 ;;
1) echo  (failed -- old process is still running). ; 
exit 1 ;;


Bug#408850: mksh build problems

2007-04-30 Thread Thorsten Glaser
unblock 421518 by 408850
reassign 408850 gcc
retitle 408850 using flags -fwhole-program --combine broken
thanks

Hi all,

thanks to Steve Langasek I now know that the “conflicting prototypes” issues
for the mksh package appear due to use of the gcc flags “-fwhole-program
--combine” which, supposedly, have gcc treat it as one single translation
unit and optimise better. I suspect that this doesn't handle redeclaration
well; it seems to be a gcc bug.

Interestingly enough, the very same flags cause problems when using the
FORTIFY_SOURCE definitions on SuSE (and I think Fedora) – it fails on a
line saying something like “if (read(fd, buf, size)  0)” with a bunch
of weird error messages; Pascal Bleser, whom I've added to the Cc: of
this eMail can surely provide them to you if that's desired. (Thanks to
Marcus “darix” Rückert for helping to track this down as well.)

I have taken these facts as arguments against using the flags at all and
changed upstream mksh to not test for and use them at all any more. A new
mksh minor release (R29d) was put out; I'll have my sponsor upload the
upgraded debian package shortly.

This means: unblock 421518 by 408850, since it no longer depends on the
fix (so that 421518 can be closed by an upgraded package), change 408850
to be a gcc bug now that we, thanks to vorlon, know the case.

bye,
//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt



Bug#408850: mksh: FTBFS on experimental/alpha (Re: Log for failed build of mksh_28.9.20070118 (dist=experimental))

2007-03-05 Thread Thorsten Glaser
I have an idea…

Dixi:

Martin Zobel-Helas dixit:

 /usr/include/sys/stat.h:217: error: conflicting types for 'stat'
 /usr/include/sys/stat.h:365: error: previous definition of 'stat' was here
[...]

Sounds like a bug in the header file to me:

215 extern int __REDIRECT_NTH (stat, (__const char *__restrict __file,
216   struct stat *__restrict __buf), 
 stat64)
217  __nonnull ((1, 2));

363 extern __inline__ int
364 __NTH (stat (__const char *__path, struct stat *__statbuf))
365 {
366   return __xstat (_STAT_VER, __path, __statbuf);
367 }

The second one is missing the restrict qualifier. Could that
be the cause, possibly induced by invoking the C99 standard
during compiling with -std=gnu99 ?

Could please someone with access to an alpha try to build the version
of mksh currently in experimental, or even my “current playchild“
at http://users.unixforge.de/~tglaser/mksh_28.9.20070304.dsc, with
HAVE_CAN_STDG99=0 defined in the environment (of Build.sh, i.e. I'd
patch debian/rules appropriately) and show me the build log?

If so, we might at least have a workaround until that's fixed in
the system headers, because I've got a major update to mksh (i.e.
a new formal release) I'd like to get into unstable/testing, and
(thanks to playing around in experimental) only this bug is pre-
venting me from doing so.

@Pierre HABOUZIT: maybe your sample programme compiles fine as
long as you don't use -std=gnu99? Maybe the issue only appears
on alpha because it implies some kind of alignment changes?

Thanks!

bye,
//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt