Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Rich Felker dixit: >Is there anything weird about how these objects were declared that >might have caused ld not to resolve them statically like it should? It >seems odd that these data symbols, but not any other ones, would be >left as symbolic relocations. I don’t think so? In I already posted the short version; the actual source is (mirrored): The initcoms array is here: https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/main.c#L77 Tdr is defined at: https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L3055 The u_ops array is declared a few lines above that and defined at: https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/funcs.c#L160 initvsn is defined at… https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L713 … with the EXTERN and E_INIT macros from… https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L657 where main.c defines EXTERN, so the string is embedded into the file using it. Is there perhaps a misunderstanding with the gcc/binutils/glibc developers as to what static-pie is meant to be? bye, //mirabilos -- cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? bis dahin gibts google nicht mehr ja, könnte man meinen. wahrscheinlich ist der angekündigte welt- untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum müssen die die doodles vorher noch raushauen
Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Markus Wichmann dixit: >I may not really know what I am talking about, so take this with a grain >of salt, but isn't this missing a -Bsymbolic somewhere? Ironically, that >switch causes ld to not emit symbolic relocations. I seem to remember >reading long ago in Rich's initial -static-pie proposal that that was >one of the switches added to the linker command line. When searching for which architectures support static PIE in the first place (sadly, there doesn’t seem a consistent list), I found one saying it’s no longer necessart after some point, so I didn’t check it. >In any case, the emission of non-relative relocations is the issue here, >and it is coming from the linker. They are present in the glibc static-pie binary as well, though. And tbh they look to me like “just plug the absolute address of the symbol here, please”, which is perfectly fine for things like an array of strings when the actual string has already its own symbol. (Disclaimer: I know… barely anything about Unix relocation types, a bit more about those on DOS and even TOS.) bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Markus Wichmann dixit: >can check with readelf -r what the relocation types are. If they are not >relative, they will not be processed. Gotcha! They are all R_390_RELATIVE except for: 00045ff0 00110016 R_390_64 00042c58 u_ops + 70 00045ff8 00110016 R_390_64 00042c58 u_ops + 0 00047020 00110016 R_390_64 00042c58 u_ops + 80 00047088 00110016 R_390_64 00042c58 u_ops + 80 000470a8 00110016 R_390_64 00042c58 u_ops + b8 00047220 00110016 R_390_64 00042c58 u_ops + 80 00046900 00260016 R_390_64 00015af8 c_command + 0 00046940 00070016 R_390_64 00017238 c_exec + 0 00046ab0 00200016 R_390_64 00016a80 c_trap + 0 00047090 00250016 R_390_64 000430ac initvsn + 0 00047278 00550016 R_390_64 00047438 null_string + 2 That’s our missing strings. >Is it possible you are linking in the wrong start file? gcc -v should >output the command line it feeds to the linker. Should be correct: /usr/libexec/gcc/s390x-linux-gnu/13/collect2 -fno-lto -dynamic-linker /lib/ld-musl-s390x.so.1 -nostdlib -static -static -pie --no-dynamic-linker -o mksh /usr/lib/s390x-linux-musl/rcrt1.o /usr/lib/s390x-linux-musl/crti.o /usr/lib/gcc/s390x-linux-gnu/13/crtbeginS.o -L/usr/lib/s390x-linux-musl -L /usr/lib/gcc/s390x-linux-gnu/13/. -z relro -z now --as-needed -z text --eh-frame-hdr lalloc.o edit.o eval.o exec.o expr.o funcs.o histrap.o jobs.o lex.o main.o misc.o shf.o syn.o tree.o var.o ulimit.o --start-group /usr/lib/gcc/s390x-linux-gnu/13/libgcc.a /usr/lib/gcc/s390x-linux-gnu/13/libgcc_eh.a -lc --end-group /usr/lib/gcc/s390x-linux-gnu/13/crtendS.o /usr/lib/s390x-linux-musl/crtn.o HTH & HAND, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Dixi quod…
>Now I (or someone) is going to have to reduce that to a testcase, so
No success with that, unfortunately.
>But this does seem to be a toolchain bug: adding -static-pie to the
>glibc dynamic-pie link command and…
>
>(gdb) print initcoms
>$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c
>"HOME", 0xda7d8 "PATH",
Wait, what?
(gdb) b main
Breakpoint 1 at 0xd820: file ../../main.c, line 785.
(gdb) print initcoms
$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c "HOME",
0xda7d8 "PATH",
[…]
(gdb) r
Starting program: /home/tg/mksh-59c/builddir/full/mksh
Breakpoint 1, main (argc=1, argv=0x3ffa4d8) at ../../main.c:785
785 {
(gdb) print initcoms
$2 = {0x3fff7eda494 "typeset", 0x3fff7ee4548 "-r",
0x3fff7ee4ae0 "KSH_VERSION=@(#)MIRBSD KSH R59 2024/02/01 +Debian",
0x0, 0x3fff7eda494 "typeset",
[…]
While in musl:
(gdb) print initcoms
$1 = {0x414a4 "typeset", 0x0, 0x0, 0x0, 0x414a4 "typeset", 0x0, 0x40478 "HOME",
0x41d42 "PATH",
[…]
(gdb) r
Starting program: /home/tg/mksh-59c/builddir/static-musl/mksh
Breakpoint 1, main (argc=1, argv=0x3ffa498) at ../../main.c:785
785 {
(gdb) print initcoms
$2 = {0x3fff7fc14a4 "typeset", 0x0, 0x0, 0x0, 0x3fff7fc14a4 "typeset", 0x0,
0x3fff7fc0478 "HOME",
[…]
So the existing ones did get relocated, but the nullptrs stayed thusly.
Apparently, it *is* supported on glibc on s390x, mjt (qemu maintainer)
also said so in 2023.
bye,
//mirabilos
--
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent
Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Dixi quod…
>Hmm, actually… I could… test whether that one fixes static-pie
>on zelenka. Or at least the same approach. I’ll get back with
>report from that.
Having looked at the spec file, the only extra things the stock
specs do that the overriding specs don’t is:
*link:
[…] %{!static|static-pie:--eh-frame-hdr} […] %{static-pie:-static -pie
--no-dynamic-linker -z text} […]
instead of:
[…] %{static-pie:-static -pie --no-dynamic-linker} […]
The -Wl,-z,text makes TEXTRELs an error. Granted.
The -Wl,--eh-frame-hdr is added for anything that’s not a normal
static executable, however adding that to a musl build doesn’t
fix the problem either.
A bit of gdb-ing shows the problem, though: the source code has…
#define Ttypeset "typeset"
#define Tdr "-r"
//… (a variant of this is used for string sharing on ancient Unix)
static const char *initcoms[] = {
Ttypeset, Tdr, initvsn, NULL,
Ttypeset, Tdx, "HOME", TPATH, TSHELL, NULL,
[…]
};
It then iterates over these commands with:
for (wp = initcoms; *wp != NULL; wp++) {
c_builtin(wp);
while (*wp != NULL)
wp++;
}
This is where the extra output happens:
(gdb) print initcoms
$3 = {0x3fff7fc14a4 "typeset", 0x0, 0x0, 0x0, 0x3fff7fc14a4 "typeset", 0x0,
0x3fff7fc0478 "HOME",
[…]
Notice the nullptrs there where string pointers are expected.
It shows the same output when just loading the executable, i.e. this
isn’t a runtime issue.
Linking the exact same .o files with the exact same command minus
-static-pie gives:
(gdb) print initcoms
$1 = {0x103cb34 "typeset", 0x103e368 "-r",
0x103e73c "KSH_VERSION=@(#)MIRBSD KSH R59 2024/02/01 +Debian", 0x0,
0x103cb34 "typeset",
But this does seem to be a toolchain bug: adding -static-pie to the
glibc dynamic-pie link command and…
(gdb) print initcoms
$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c "HOME",
0xda7d8 "PATH",
Now I (or someone) is going to have to reduce that to a testcase, so
we can detect static-pie viability before it’s committed to being used…
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
Bug#1066143: general/glibc(?): simple IPv6 test program fails on m68k
>The same program works on amd64. I noticed another difference between the amd64 system and the four m68k ones. $ ip a show dev lo 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever vs. # ip a show dev lo 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever /etc/network/interfaces just has… auto lo iface lo inet loopback … on all systems, so something weird is going on. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1066143: general/glibc(?): simple IPv6 test program fails on m68k
Package: libc6
Version: 2.36-8
Severity: normal
Tags: ipv6
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org
This error occurred first during curl’s configure in a chroot with
libc6 2.37-15.1, but I could also reproduce it on a build host with
libc6 2.36-8 as well, and on an even older host with libc6 2.19-19
(all but the 2.36-8 one I’m reportbugging this from are running
linux 6.6.15-2).
Running a simple program that opens a TCP/IPv6 socket fails:
root@ara4:~ # gcc y.c
root@ara4:~ # ./a.out
a.out: socket(AF_INET6, SOCK_STREAM, 0): Address family not supported by
protocol
1|root@ara4:~ # cat y.c
#include
#include
#include
int main(void) {
int rv = socket(AF_INET6, SOCK_STREAM, 0) < 0;
err(1, "socket(AF_INET6, SOCK_STREAM, 0)");
}
(oops, should have been s/1/rv/ but doesn’t matter)
The same program works on amd64.
This is a reduced testcase that still shows the problem, plus
the call to err(3) added to show errno.
cbmuser said that another ports architecture also has unknown
trouble with IPv6, maybe this is the same issue?
If this is an issue with the kernel or something, please
reassign and inform the maintainers.
If this is a bug in the testcase, please reassign to src:curl.
The original testcase (plus confdefs) was:
#include
#ifdef _WIN32
#include
#include
#else
#include
#include
#if defined (__TANDEM)
# include
#endif
#endif
int main(void)
{
struct sockaddr_in6 s;
(void)s;
return socket(AF_INET6, SOCK_STREAM, 0) < 0;
}
gcc -o conftest -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/tmp/buildd/curl-8.6.0=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -D_DEB_HOST_ARCH=\"m68k-linux-gnu\"
-DCURL_PATCHSTAMP=\"8.6.0-3.2+b1\" -Werror-implicit-function-declaration
-Wno-system-headers -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
-Wdate-time -D_FORTIFY_SOURCE=2-specs=/usr/share/dpkg/pie-link.specs
-Wl,-z,relro -Wl,-z,nowconftest.c -llber -lldap -llber -lzstd -lbrotlidec
-lz
-- System Information:
Debian Release: bookworm/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: m68k
Kernel: Linux 6.1.0-2-m68k (UP)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages libc6 depends on:
ii libgcc-s2 12.2.0-12
Versions of packages libc6 recommends:
ii libidn2-0 2.3.3-1+b1
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.82
pn glibc-doc
ii libc-l10n 2.36-8
pn libnss-nis
pn libnss-nisplus
pn locales
-- debconf information:
* libraries/restart-without-asking: true
glibc/kernel-too-old:
glibc/kernel-not-supported:
glibc/restart-services:
glibc/upgrade: true
glibc/restart-failed:
glibc/disable-screensaver:
Bug#1043250: tzdata: bring back top-level UTC
Benjamin Drung dixit: >Can you point to examples for it? Most of these cases should probably >use TZ=UTC0 which work without having any timezone data files. Except that tzif files contain more than DST info, such as the name of the zone, but also leap second information (not in Debian currently), which TZ=UTC0 would lose, therefore it’s not an option. I’m using that heavily, for example. >> A second candidate, although less used recently, is the top-level >> GMT symlink. > >I haven't used GMT myself and I am not aware of any users. Do you know Yeah, me either, I was guessing legacy scripts. >codesearch.debian.net. I’m much more concerned about scripts and other stuff that people have locally on their systems, especially portable stuff, than Debian package content here. >Why isn't Etc/UTC an alternative to UTC? It’s not as portable, it binds to the Olson database whereas an otherwise unqualified UTC is pretty standard. Worse, if Etc/UTC is not available, the fallback makes it assume Etc, not UTC, as timezone name. 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
Bug#1043250: tzdata: bring back top-level UTC
Package: tzdata Version: 2023c-8 Severity: important X-Debbugs-Cc: t...@mirbsd.de Please bring back at the *very* least the top-level UTC symlink, as TZ=UTC is used in *so* many places to get UTC it’s not funny. A second candidate, although less used recently, is the top-level GMT symlink. These are bound to be hardcoded in so many places, and Etc/UTC is *not* a substitute, nor is running that without the files (in some corner cases). -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-23-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/lksh Init: sysvinit (via /sbin/init) Versions of packages tzdata depends on: ii debconf [debconf-2.0] 1.5.82 tzdata recommends no packages. tzdata suggests no packages. -- debconf information: * tzdata/Zones/Etc: UTC * tzdata/Areas: Europe tzdata/Zones/Antarctica: tzdata/Zones/Arctic: tzdata/Zones/Australia: tzdata/Zones/US: tzdata/Zones/Pacific: tzdata/Zones/America: tzdata/Zones/Asia: * tzdata/Zones/Europe: Berlin tzdata/Zones/SystemV: tzdata/Zones/Africa: tzdata/Zones/Atlantic: tzdata/Zones/Indian:
Bug#1032890: iconv: misconverts some characters
Package: libc-bin Version: 2.36-8 Severity: normal X-Debbugs-Cc: t...@mirbsd.de Probably a codepage data bug, but I don’t know what package that would be; please reassign as suitable. $ printf '%s' '~' | iconv -f ISO-IR-10 -t UTF-16LE | hexdump -e '1/2 "%04X" "\n"' 203E This is supposed to be the Macron (U+00AF), not the Overline. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libc-bin depends on: ii libc6 2.36-8 Versions of packages libc-bin recommends: ii manpages 6.03-1 libc-bin suggests no packages. -- no debconf information
Bug#1020654: C.UTF-8: surprising differences in character classes
Hi Aurelien, >Starting with glibc 2.35, we do not patch the glibc to add C.UTF-8 >support, instead we use the upstream code which comes with the following >NEWS entry [1]: […] Thanks for the extra info. >> They are as mandated by POSIX for the C locale. I believe I said >> in my original 2013 proposal for a C.UTF-8 locale that it should >> be as close to C as possible while using UTF-8 as encoding. > >Those are mandated for the POSIX C locale, but POSIX does not say >anything (yet) about the C.UTF-8 locale. Right. But, as I wrote above, my intent was to have C.UTF-8 to mirror C as closely as possible. >The choice made by upstream has been discussed during many years [2], >if you disagree with it, please come back to upstream. *sigh* but I understand your PoV. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1020654: C.UTF-8: surprising differences in character classes
Package: locales
Version: 2.35-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
While adjusting my localedata patch script to the latest glibc uploads
I discovered a surprising difference in some categories — for example:
(sid-amd64)tglase@tglase:~ $ LC_ALL=C ./tstspc
U+0009
U+000A
U+000B
U+000C
U+000D
U+0020
(sid-amd64)tglase@tglase:~ $ LC_ALL=C.UTF-8 ./tstspc
U+0009
U+000A
U+000B
U+000C
U+000D
U+0020
U+1680
U+2000
U+2001
U+2002
U+2003
U+2004
U+2005
U+2006
U+2008
U+2009
U+200A
U+2028
U+2029
U+205F
U+3000
The test program is thus: gcc -O2 -Wall -Wextra -Wformat -o tstspc tstspc.c
//cut-here--
#include
#include
#include
#include
int
main(void)
{
wint_t wc;
if (!setlocale(LC_ALL, ""))
err(1, "setlocale");
#define DOIT(lim, fmtstr) do { \
while (wc <= lim) { \
if (iswspace(wc)) \
printf(fmtstr, (unsigned int)wc); \
++wc; \
} \
} while (/* CONSTCOND */ 0)
wc = 0;
DOIT(0x, "U+%04X\n");
DOIT(0x10, "U-%08X\n");
return (0);
}
//cut-here--
In my localedata patch script, I take specific care to change the
copy of i18n_ctype before applying it to C.UTF-8 as follows:
space → ..;
cntrl → ..;
blank → ;
They are as mandated by POSIX for the C locale. I believe I said
in my original 2013 proposal for a C.UTF-8 locale that it should
be as close to C as possible while using UTF-8 as encoding.
For these curious, I’m attaching the current WIP of said script.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500,
'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
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.79
ii libc-bin 2.35-1
ii libc-l10n 2.35-1
locales recommends no packages.
locales suggests no packages.
-- debconf information:
locales/default_environment_locale: None
locales/locales_to_be_generated:
# -*- mode: sh -*-
#-
# Copyright © 2017, 2020, 2022
# mirabilos
#
# Provided that these terms and disclaimer and all copyright notices
# are retained or reproduced in an accompanying document, permission
# is granted to deal in this work without restriction, including un‐
# limited rights to use, publicly perform, distribute, sell, modify,
# merge, give away, or sublicence.
#
# This work is provided “AS IS” and WITHOUT WARRANTY of any kind, to
# the utmost extent permitted by applicable law, neither express nor
# implied; without malicious intent or gross negligence. In no event
# may a licensor, author or contributor be held liable for indirect,
# direct, other damage, loss, or other issues arising in any way out
# of dealing in the work, even if advised of the possibility of such
# damage or existence of a defect, except proven that it results out
# of said person’s immediate fault when using the work as intended.
#-
# Installs UTF-8 charmap shipped by mirabilos-support generated from
# MirBSD but glibc-compatible into the glibc locale souce directory,
# to update wcwidth data (search for “Character width according to”)
# and the i18n_ctype data taken off glibc git master to enable those
# glyphs added in later UCS versions at all, to (find “It covers”) —
# not always the same version the charmap ships, but close enough at
# least — patching the C.UTF-8 and Turkish localedata appropriately,
# handling i18n for stretch glibc and older as well. This also fixes
# Turkish title-case i→İ and C.UTF-8 supporting UCD 9 only, not just
# making ䷀ fullwidth again (bad width tablegens recently sprouted).
case x$KSH_VERSION in
x'@(#)MIRBSD KSH R'[5-9][0-9]*|x'@(#)MIRBSD KSH R'[1-9][0-9][0-9]*)
;;
*)
echo >&2 "E: need mksh"
exit 255
;;
esac
export LC_ALL=C
unset LANGUAGE
set -e
set -o pipefail
set +e
localedef='localedef --no-archive -A /usr/share/locale/locale.alias'
rv=0
do_localedef() {
print -ru2 -- + $localedef "$@"
$localedef "$@" || rv=1
}
die() {
print -ru2 -- "E: $*"
exit 1
}
set -x
(( USER_ID )) && die need root
cd "$(dirname "$0")" || die cannot chdir
[[ -s UTF-8.gz ]] || die cannot find charmap file
[[ -s i18n_ctype.gz ]] || die cannot find ctype file
[[ -d /usr/share/i18n/charmaps/. ]] || die cannot find charmap directory
[[ -d /usr/share/i18n/locales/. ]] ||
Bug#799476: libc6: strftime should allow extended-format timezone (ISO 8601)
Package: libc6 Version: 2.31-10 Followup-For: Bug #799476 X-Debbugs-Cc: t...@mirbsd.de Control: tags 799476 + upstream Incidentally, I came here to report precisely this (strftime(3) and date(1) not consistent wrt. GNU extensions). I’ve since added %-d and %:z to MirBSD libc’s strftime(3) — whose date(1) uses that. I’ve noticed that trying to use %:z in a locale category fails, but passing it directly to date(1) works: $ LC_TIME=de_DE.UTF-8 date +"$(LC_TIME=de_DE.UTF-8@iso8601 locale d_t_fmt)" 2021-04-04T21:34:31+02:00 (CEST), 2021-W13-7 (So) $ LC_TIME=de_DE.UTF-8@iso8601 date +%c 2021-04-04T21:34:35%:z (CEST), 2021-W13-7 (So) I thought I could get by with using "%Y-%m-%dT%H:%M:%S%z (%Z), %G-W%V-%u (%a)" but the OP makes a good point that mixing basic and extended formats is not permitted either. Please forward this upstream so it’ll be implemented. Thanks! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libc6 depends on: ii libcrypt1 1:4.4.18-2 ii libgcc-s1 10.2.1-6 Versions of packages libc6 recommends: ii libidn2-0 2.3.0-5 ii libnss-nis 3.1-4 ii libnss-nisplus 1.3-4 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.76 ii glibc-doc 2.31-10 ii libc-l10n 2.31-10 ii locales2.31-10 -- debconf information: glibc/kernel-too-old: glibc/restart-services: * glibc/upgrade: true glibc/disable-screensaver: glibc/kernel-not-supported: * libraries/restart-without-asking: true glibc/restart-failed:
Bug#985915: ldd: disagrees with file(1) about whether a file is dynamically or statically linked
Package: libc-bin Version: 2.31-10 Severity: normal X-Debbugs-Cc: t...@mirbsd.de I’m debugging a weird lintian problem and found the cause to be: tglase@tglase-nb:~ $ ldd /tmp/libjsound.so statically linked tglase@tglase-nb:~ $ file /tmp/libjsound.so /tmp/libjsound.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=de56e345230aca1c7c8cf06b56e9c21ee53031f5, stripped tglase@tglase-nb:~ $ objdump -p /tmp/libjsound.so | fgrep NEED | wc -l 0 I’m attaching this file so this can be fixed in the right package. I believe that if both agree lintian won’t complain. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libc-bin depends on: ii libc6 2.31-10 Versions of packages libc-bin recommends: ii manpages 5.10-1 libc-bin suggests no packages. -- no debconf information libjsound.so Description: application/sharedlib
Bug#916276: glibc: Please add prelimenary patch to fix regression on qemu-user
Hi, >The patch is basically replacing the getdents64 syscall by the getdents >one. This means that applying this patch would make debian differ with >regards to other distributions in the syscalls that are used for the >same binaries. In turns it is likely going to affect binaries that are >using seccomp and only allow the getdents64 and not the getdents one. ah, indeed. >I therefore don't think this is not reasonable to include such a fix on >our glibc. It would fix the qemu-user case but likely break random >binaries. OK, thanks for the explanation. Let’s hope this can be fixed, somehow, in qemu itself and/or the kernel. bye, //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
Bug#916276: glibc: Please add prelimenary patch to fix regression on qemu-user
Hello glibc maintainers, would you please consider including this patch to unbreak things (fix a regression) until the triangle between qemu, Linux and glibc has figured out how to best deal with it? Thanks, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#965091: glibc: setgroups: Bad address [2.31/x32, regression from 2.30]
> So something clearly changed…
Compiler output, most probably. I cannot reproduce it. I tried:
struct xid_command
{
int syscall_no;
long int id[3];
volatile int cntr;
volatile int error; /* -1: no call yet, 0: success seen, >0: error
seen. */
};
extern void a_barrier(int *);
# define REGISTERS_CLOBBERED_BY_SYSCALL "cc", "r11", "cx"
/* NB: This also works when X is an array. For an array X, type of
(X) - (X) is ptrdiff_t, which is signed, since size of ptrdiff_t
== size of pointer, cast is a NOP. */
#define TYPEFY1(X) __typeof__ ((X) - (X))
/* Explicit cast the argument. */
#define ARGIFY(X) ((TYPEFY1 (X)) (X))
/* Create a variable 'name' based on type of variable 'X' to avoid
explicit types. */
#define TYPEFY(X, name) __typeof__ (ARGIFY (X)) name
#undef INTERNAL_SYSCALL_NCS
#define INTERNAL_SYSCALL_NCS(number, err, nr, args...)
\
internal_syscall##nr (number, err, args)
#undef internal_syscall3
#define internal_syscall3(number, err, arg1, arg2, arg3)
\
({
\
unsigned long int resultvar;
\
TYPEFY (arg3, __arg3) = ARGIFY (arg3);
\
TYPEFY (arg2, __arg2) = ARGIFY (arg2);
\
TYPEFY (arg1, __arg1) = ARGIFY (arg1);
\
register TYPEFY (arg3, _a3) asm ("rdx") = __arg3;
\
register TYPEFY (arg2, _a2) asm ("rsi") = __arg2;
\
register TYPEFY (arg1, _a1) asm ("rdi") = __arg1;
\
asm volatile (
\
"syscall\n\t"
\
: "=a" (resultvar)
\
: "0" (number), "r" (_a1), "r" (_a2), "r" (_a3)
\
: "memory", REGISTERS_CLOBBERED_BY_SYSCALL);
\
(long int) resultvar;
\
})
int
foo(struct xid_command *cmdp)
{
int result;
asm volatile ("xor rsi,rsi\n\txor rdi,rdi" : : : "rsi", "rdi");
result = INTERNAL_SYSCALL_NCS (cmdp->syscall_no, err, 3,
cmdp->id[0], cmdp->id[1], cmdp->id[2]);
a_barrier();
return result;
}
Save as x.c then:
x86_64-linux-gnux32-gcc-10 -c -std=gnu11 -fgnu89-inline -pipe -O2 -g -Wall
-Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math
-fstack-protector-strong -Wstrict-prototypes -Wold-style-definition
-fmath-errno -fpie -ftls-model=initial-exec -D_LIBC_REENTRANT -DPIC -S
-masm=intel x.c -Wno-error
This doesn’t yield any “movsxd” in the output, like in glibc, though:
b32: 67 48 63 73 08 movsxd rsi,DWORD PTR [ebx+0x8]
b37: 67 48 63 7b 04 movsxd rdi,DWORD PTR [ebx+0x4]
b3c: 67 48 63 53 0c movsxd rdx,DWORD PTR [ebx+0xc]
b41: 67 8b 03moveax,DWORD PTR [ebx]
b44: 0f 05 syscall
(disassembly of pthread_create.o from libpthread.a 2.31)
I’m unsure whether this is a glibc or gcc issue… without a reproducer
I’m stuck.
I’ll have to downgrade to 2.30 for now, to keep the system ssh-in-able…
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#965091: glibc: setgroups: Bad address [2.31/x32, regression from 2.30]
Some more analysis: We enter libc from openssh code with the correct values in rsi and rdi: (gdb) u => 0x56560e45 : call 0x5655d0b0 (gdb) info r rax0xfffe 65534 rbx0x5663a000 1449369600 rcx0x0 0 rdx0x0 0 rsi0xd2e0 4294955744 rdi0x1 1 rbp0x56641b50 1449401168 rsp0xd260 4294955616 r8 0x0 0 r9 0x0 0 r100xf7a8 4155017352 r110x246 582 r120x565d71d1 1448964561 r130x3 3 r140xe2cc 58060 r150x5663c730 1449379632 rip0x56560e45 1448480325 eflags 0x282 [ SF IF ] cs 0x3351 ss 0x2b43 ds 0x2b43 es 0x2b43 fs 0x0 0 gs 0x0 0 Inside glibc, there’s an indirect call: => 0xf79949f4 <__GI_setgroups+100>: call rax rax0xf7833500 4152571136 => 0xf7833500 <__nptl_setxid>: push r15 Some time in __nptl_setxid later, here’s the bug: 1162in allocatestack.c rax0xf77ca840 4152141888 rbx0xd230 4294955568 rcx0x0 0 rdx0x1 1 rsi0xd2e0 4294955744 rdi0xf77ca840 4152141888 rbp0xf77ca840 4152141888 rsp0xd1d0 4294955472 r8 0x0 0 r9 0x0 0 r100xf77caac0 4152142528 r110x246 582 r120xf784a360 4152664928 r130xf784a360 4152664928 r140xf78482c8 4152656584 r150x40ca 1073742026 rip0xf7833752 4152571730 eflags 0x246 [ PF ZF IF ] cs 0x3351 ss 0x2b43 ds 0x2b43 es 0x2b43 fs 0x0 0 gs 0x0 0 => 0xf7833752 <__nptl_setxid+594>: movsxd rsi,DWORD PTR [ebx+0x8] 0xf7833757 <__nptl_setxid+599>: movsxd rdi,DWORD PTR [ebx+0x4] 0xf783375c <__nptl_setxid+604>: movsxd rdx,DWORD PTR [ebx+0xc] (gdb) t => 0xf7833752 <__nptl_setxid+594>: movsxd rsi,DWORD PTR [ebx+0x8] 1162in allocatestack.c rax0xf77ca840 4152141888 rbx0xd230 4294955568 rcx0x0 0 rdx0x1 1 rsi0xd2e0 -11552 rdi0xf77ca840 4152141888 rbp0xf77ca840 4152141888 rsp0xd1d0 4294955472 r8 0x0 0 r9 0x0 0 r100xf77caac0 4152142528 r110x246 582 r120xf784a360 4152664928 r130xf784a360 4152664928 r140xf78482c8 4152656584 r150x40ca 1073742026 rip0xf7833757 4152571735 eflags 0x246 [ PF ZF IF ] cs 0x3351 ss 0x2b43 ds 0x2b43 es 0x2b43 fs 0x0 0 gs 0x0 0 Looking at the next instructions… => 0xf7833757 <__nptl_setxid+599>: movsxd rdi,DWORD PTR [ebx+0x4] 0xf783375c <__nptl_setxid+604>: movsxd rdx,DWORD PTR [ebx+0xc] 0xf7833761 <__nptl_setxid+609>: moveax,DWORD PTR [ebx] 0xf7833764 <__nptl_setxid+612>: syscall … this most likely corresponds to this C source: 1162 result = INTERNAL_SYSCALL_NCS (cmdp->syscall_no, err, 3, 1163 cmdp->id[0], cmdp->id[1], cmdp->id[2]); Diffing glibc-2.30..glibc-2.31 shows no noticeable delta in nptl/allocatestack.c so going on. struct xid_command (nptl/descr.h) also did not change. Looking at pthread_create.o (whyever this is the file __nptl_setxid ends up being in) from 2.30-8, the code in question looks like this: c3d: 67 8b 75 08 movesi,DWORD PTR [ebp+0x8] c41: 67 8b 7d 04 movedi,DWORD PTR [ebp+0x4] c45: 67 8b 55 0c movedx,DWORD PTR [ebp+0xc] c49: 67 8b 45 00 moveax,DWORD PTR [ebp+0x0] c4d: 0f 05 syscall So something clearly changed… //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49
Bug#965091: glibc: setgroups: Bad address [2.31/x32, regression from 2.30]
Package: libc6
Version: 2.31-1
Severity: grave
Justification: renders package unusable
This is related to #965086 and #965087 (and, in fact, possibly
causing them). After a glibc upgrade half the system services
(postfix, sshd, apt-get(!)) don’t work any more.
Downgrading with dpkg -i the following set of packages fixes it:
libc-bin_2.30-8_x32.deb
libc-dev-bin_2.30-8_x32.deb
libc-l10n_2.30-8_all.deb
libc6-dbg_2.30-8_x32.deb
libc6-dev_2.30-8_x32.deb
libc6_2.30-8_amd64.deb
libc6_2.30-8_i386.deb
libc6_2.30-8_x32.deb
locales-all_2.30-8_x32.deb
locales_2.30-8_all.deb
unscd_0.53-1+b3_x32.deb
Snippet from strace:
[…]
9839 getpid() = 9839
9839 chroot("/run/sshd") = 0
9839 chdir("/")= 0
9839 write(7, "\0\0\0$\0\0\0\7\0\0\0\34privsep user:group 1"..., 40) = 40
9839 setgroups(1, 0xff866750
9794 <... poll resumed>) = 1 ([{fd=6, revents=POLLIN}])
9839 <... setgroups resumed>) = -1 EFAULT (Bad address)
9794 read(6,
9839 write(7, "\0\0\0\36\0\0\0\1\0\0\0\26setgroups: Bad addre"..., 34
[…]
Noticeable: the sign-extended address.
I haven’t yet managed to reproduce this in a stand-alone program.
-- 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 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages libc6 depends on:
ii libcrypt1 1:4.4.16-1
ii libgcc-s1 10.1.0-6
Versions of packages libc6 recommends:
ii libidn2-0 2.3.0-1
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.74
ii glibc-doc 2.31-1
ii libc-l10n 2.31-1
ii locales2.31-1
-- debconf information:
glibc/disable-screensaver:
* libraries/restart-without-asking: true
glibc/restart-failed:
glibc/kernel-too-old:
* glibc/upgrade: true
* glibc/restart-services: postfix openbsd-inetd cups cron
glibc/kernel-not-supported:
Bug#955270: hurd: fails to update file mtime
Hi Samuel, >Thanks for the precise report, thank you for the quick response and fix ;-) Can you then please give-back mksh_58-1 on hurd-i386 with an extra dependency on the fixed glibc? TIA, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
Bug#953830: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h
Package: libc6-dev Version: 2.30-2 Severity: grave Justification: renders package unusable Unsure whether it’s upstream or Debian, but… tglase@tglase-nb:~ $ gcc x.c In file included from x.c:1: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h 124 | # include_next | ^ 1|tglase@tglase-nb:~ $ cat x.c #include (MWE extracted from a much larger attempt to compile something.) -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libc6-dev:amd64 depends on: ii libc-dev-bin2.30-2 ii libc6 2.30-2 ii libcrypt-dev1:4.4.15-1 ii linux-libc-dev 5.4.19-1 libc6-dev:amd64 recommends no packages. Versions of packages libc6-dev:amd64 suggests: pn glibc-doc ii manpages-dev 5.05-1 -- no debconf information
Bug#947778: libc6-dev: please change dependency on libcrypt1-dev to libcrypt-dev
Package: libc6-dev Version: 2.29-6 Severity: grave Justification: renders package unusable The libcrypt1-dev package got renamed, so the dependencies must match, or libc6-dev becomes uninstallable or libcrypt1 unupgradable. AIUI both glibc and libxcrypt must migrate to testing together this time, too… -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libc6-dev depends on: ii libc-dev-bin2.29-6 ii libc6 2.29-6 ii libcrypt1-dev 1:4.4.10-7 ii linux-libc-dev 5.4.6-1 libc6-dev recommends no packages. Versions of packages libc6-dev suggests: pn glibc-doc ii manpages-dev 5.04-1 -- no debconf information
Bug#874160: systemd _sometimes_ does this
On Thu, 7 Feb 2019, Adam Borowski wrote: > On Thu, Feb 07, 2019 at 03:36:59PM +0100, Adam Borowski wrote: > > Turns out systemd independently does this, although not in every case. > > If you have unset locale, it changes it to C.UTF-8 for X (gdm3) but not […] > > It'd be good to have this consistent both for X vs console, and systemd vs > > other inits/rc systems. I see my feature request to add a C.UTF-8 locale has made it far ☻ > So with systemd forcing this, the result is us diverging from most other > distributions only when init/rc is not systemd. Thus, could you please > apply this patch -- or, should I bother sysvinit folks (and perhaps Absolutely not! Making unset locale equal anything other than C is going to also break tons of scripts (I had some reported to me when I experimented with similar things in MirBSD). At best, do something like, if /etc/default/locale doesn’t set one, set LANG=C.UTF-8 by default. bye, //mirabilos -- [17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker: veni, vidi, fixi(t) ;-)
Bug#932384: libc6: utmp broken
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
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
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
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
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)
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)
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
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)
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)
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
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
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
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
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
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
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
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
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
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)
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)
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)
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
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
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
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
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
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
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)
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)
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)
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)
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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
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))
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
