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
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
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
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,
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:
[…]
>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
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
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
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.
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
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
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
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
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
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
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
> 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
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
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
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:
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 | #
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,
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
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 :-)
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 exampl
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:
> Af
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 fi
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
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
won
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
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,
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 s
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
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
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,
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
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
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
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'
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
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
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
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:
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
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
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”
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
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
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
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
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 *,
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
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
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*
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
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
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,
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
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
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
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
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
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 *);
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
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
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.”
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
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
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
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
+
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
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.
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
#
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.”
--
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,
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
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)
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
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
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
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
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
+ 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
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
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
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.
-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,
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
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
+ 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
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
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*
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
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
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
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];
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
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
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,
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
100 matches
Mail list logo
