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

2010-04-04 Thread Thorsten Glaser
Arrgh, h̲e̲ strikes again. For some of the files, one thinks “w̲h̲i̲c̲h̲ licences”. I for one don’t know who the authors of these are (they aren’t even listed usually). Sorry, but I tried at least. //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much*

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

2010-09-03 Thread Thorsten Glaser
Samuel Thibault dixit: believe that's something that shouldn't break Squeeze at all. I also believe it cannot possibly do that. bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the

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

2010-10-23 Thread Thorsten Glaser
+ 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

Bug#601126: updated patch

2010-11-02 Thread Thorsten Glaser
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

Bug#603914: Please drop non-UTF8 locales

2010-11-28 Thread Thorsten Glaser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Hi! Fun to be reading this. Me like ;-) Anyway. With my Debian hat on, the C/POSIX locales must not use UTF-8 as encoding, because otherwise, all kind of hell breaks loose (consider running 'tr u x' on a binary or other legacy encoded text file,

[m68k] res_init segfault, need help debugging

2010-11-28 Thread Thorsten Glaser
Hi, I’ve got a rather weird problem on m68k (with the patches I sent to #601126 applied), stripped down: ara2:~# cat x.c #include netinet/in.h #include arpa/nameser.h #include resolv.h int main(void) { return (res_init()); } ara2:~# gcc x.c ara2:~# ./a.out Segmentation fault I don’t

Bug#603914: Please drop non-UTF8 locales

2011-01-09 Thread Thorsten Glaser
Roger Leigh dixit: From my reading of the standards a UTF-8 C locale would be required to behave identically to the existing ASCII C locale: • will consider all byte sequences valid I think it wouldn’t (since UTF-8 mbrtowc/wcrtomb don’t work this way, and it can’t be done with “just” the POSIX

Bug#603914: Please drop non-UTF8 locales

2011-01-09 Thread Thorsten Glaser
Roger Leigh dixit: I think the all byte sequences valid applies mainly to narrow character I/O. i.e. printf/puts etc. won't alter, drop or otherwise mangle any non 7-bit-ASCII codes. i.e. I think the intent was to ensure 8-bit cleanliness in a 7-bit locale. This naturally extends to UTF-8.

Bug#601126: Updated patch FIXING IMPORTANT BUG on m68k

2011-01-10 Thread Thorsten Glaser
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

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

2011-01-28 Thread Thorsten Glaser
+ 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

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

2011-02-03 Thread Thorsten Glaser
Source: eglibc Version: 2.11.2-11 Hi, when building eglibc with --debbuildopts -B --binary-arch, after taking a day or so for locales-all ☺ it still creates a source archive in build-tree/eglibc-2.11.2.tar.xz which I think is for the eglibc-source arch:all deb. This creates unnecessary burden on

Bug#601126: updated patch

2011-02-03 Thread Thorsten Glaser
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

Bug#522774: possible solutions for __unused problem

2011-06-19 Thread Thorsten Glaser
Robert Millan dixit: I can see they wouldn't be excited about it, but they might also accept You know that there are more than one BSD, but only one glibc, IIRC Drepper isn’t even its maintainer any more. Try persuading for example Theo de Raadt of anything which doesn’t have any immediate

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

2011-06-19 Thread Thorsten Glaser
Ben Hutchings dixit: Honestly, when resolving this I’d go for “who has the older rights”. Maybe look at how CSUR resolves different claims to the same part of the Unicode PUA, or something like that. Nevertheless, thanks on picking this up. Debian GNU/Linux is the older system; the Debian

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

2007-06-14 Thread Thorsten Glaser
Package: nscd Version: 2.3.6.ds1-8 Severity: important Tags: patch Hi, I've reported a similar bug to the sendmail-bin postinst script some time ago, you'll find it at | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424213 for reference and deeper information. The script defines a shell

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

2009-04-06 Thread Thorsten Glaser
Package: libc6-dev Version: 2.9-6 Severity: wishlist (mass filing with linux-libc-dev and libc6-dev) /usr/include/aio.h: char __unused[32]; /usr/include/aio.h: char __unused[32]; /usr/include/bits/stat.h:long int __unused[3]; /usr/include/bits/stat.h:long int __unused[3];

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

2009-04-06 Thread Thorsten Glaser
Package: locales-all Version: 2.9-6 Severity: normal This is probably the same as #274699 as the error is the same, and I’ll mark it as blocking this bug after reporting. mksh FTBFS on hurd-i386 because its dependency locales-all is not installable: #522777

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

2009-07-29 Thread Thorsten Glaser
Hi package maintainers, maybe you can do such a thing during package installation? This would tremendously help porting software (liberal in what one accepts), such as NetBSD® makefs (ITP: #538171 – for now I worked around the issue in it). -- Forwarded message -- From: Thorsten

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

2009-10-21 Thread Thorsten Glaser
Package: libc6-i686 Version: 2.10.1-1 Severity: important This is on a Debian etch system, which contains both a lenny and a sid schroot. I first noticed that reportbug failed in the sid system, and lynx does too, after testing. Below is the output from the also failing wget. I’m submitting this

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

2009-10-21 Thread Thorsten Glaser
Dixi quod… I first noticed that reportbug failed in the sid system, and lynx does too, after testing. Below is the output from the also failing wget. Ibhas worked when I a-g d-ub Thanks to Mika Prokop, I now know the solution: 14:36⎜* mira|AO:#grml t...@frozenfish:~ $ sudo touch SID/etc/hosts

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

2007-03-05 Thread Thorsten Glaser
I have an idea… Dixi: Martin Zobel-Helas dixit: /usr/include/sys/stat.h:217: error: conflicting types for 'stat' /usr/include/sys/stat.h:365: error: previous definition of 'stat' was here [...] Sounds like a bug in the header file to me: 215 extern int __REDIRECT_NTH (stat, (__const

Bug#408850: mksh build problems

2007-04-30 Thread Thorsten Glaser
unblock 421518 by 408850 reassign 408850 gcc retitle 408850 using flags -fwhole-program --combine broken thanks Hi all, thanks to Steve Langasek I now know that the “conflicting prototypes” issues for the mksh package appear due to use of the gcc flags “-fwhole-program --combine” which,

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

2011-08-01 Thread Thorsten Glaser
Source: eglibc Version: 2.13-11 Severity: normal (Only normal severity because this doesn't happen on i386) root@aranym:~ # LC_ALL=C ./sfl; echo $? 1 root@aranym:~ # LC_ALL=CUT ./sfl; echo $? sfl: setlocale: No such file or directory 4 root@aranym:~ # LC_ALL=C.UTF-8 ./sfl; echo $? Segmentation

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

2011-08-02 Thread Thorsten Glaser
Andreas Schwab dixit: There is no testcase. Meh, you know that when you say attach but forget to actually do it? Thanks for spotting. Here it is. bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (254 (273) bugs: 1 RC, 175 (190) IN, 78 (82) MW, 0 FP) ‣ src:dash (82 (90)

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

2011-08-08 Thread Thorsten Glaser
Hi, just a question: what do you do if the perl that ends up in wheezy depends on eglibc 2.13 (e.g. due to some symbol use)? That will make upgrades impossible… bye, //mirabilos, human m68k buildd -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (254 (273) bugs: 1 RC, 175 (190) IN, 78

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

2011-09-13 Thread Thorsten Glaser
Aurelien Jarno dixit: Because it is supposed to replace the C locale, so to follow POSIX rules like the C locale. I am personally not convinced that we should go It’s supposed to offer a POSIX/C locale but with UTF-8 as character set instead of 7-bit US ASCII, like the “proper” POSIX/C locale,

[m68k] eglibc expected(?) testsuite results

2011-12-15 Thread Thorsten Glaser
Just FYI, maybe you can do something with it (or not). I built the latest eglibc 2.13-23 without nocheck. make[1]: Leaving directory `/tmp/buildd/eglibc-2.13/build-tree/m68k-libc' # # Testsuite failures, someone should be working towards # fixing these! They are listed here for the purpose of #

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

2011-12-15 Thread Thorsten Glaser
Finn Thain dixit: It might be helpful to do the same with gcc 4.4. That was with gcc 4.4 (which src:eglibc forces). bye, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” --

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

2011-12-16 Thread Thorsten Glaser
Source: eglibc Hi, (from #595496) please make sure that this passes on all architectures: cat x.c 'EOF' #include stddef.h #include stdint.h #include byteswap.h uint32_t foo(uint32_t *bar, size_t *baz) { return (bswap_32(bar[(*baz)++])); } EOF gcc -Wall -c x.c On amd64 it passes, on

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

2011-12-16 Thread Thorsten Glaser
Aurelien Jarno dixit: I have dropped it in favor of the default version for the next upload. Why don’t you just use these? (Tested for 32-bit and 64-bit both.) I’ve not looked at other architectures atm though. --- usr/include/m68k-linux-gnu/bits/byteswap.h~ 2011-12-17 02:44:08.0 +

Re: Cross Memory Attach v3

2011-12-16 Thread Thorsten Glaser
I’ve tested the below patch locally in the meantime, and it does not break anything. Aurelien Jarno dixit: On Sun, Dec 11, 2011 at 10:11:03PM +, Thorsten Glaser wrote: Andreas Schwab dixit: Thorsten Glaser t...@mirbsd.de writes: Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/m68k

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

2011-12-16 Thread Thorsten Glaser
Finn Thain dixit: I have just included it as the expected tests results. I have to say the list of failure seems to say that m68k is not really in a good state. Mh. I’m just the builder. It might be worth running the tests on physical hardware instead of an emulator. You just volunteered.

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

2011-12-17 Thread Thorsten Glaser
Aurelien Jarno dixit: I am not an m68k porter, and I am not planning to try things. m68k is lagging upstream wrt other architectures. Please work with upstream to fix things, then I can include tested and accepted patches. I’m not an m68k porter either, but this fix is easily done from working

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

2011-12-17 Thread Thorsten Glaser
Aurelien Jarno dixit: If you are not an m68k porter, you should simply stop to care about m68k porting issues. I care about the entire Open Source ecosystem. (Way to motivate people.) bye, //mirabilos -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs

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

2011-12-17 Thread Thorsten Glaser
Jonathan Nieder dixit: There are kinder ways to say that. Thanks. Thorsten, can you test this patch or arrange for it to be tested? Will do that once the next buildhost gets idle (one is currently building gcc-4.6 (second upload in one day), the other working its something off to build a

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

2011-12-19 Thread Thorsten Glaser
Dixi quod… Jonathan Nieder dixit: Thorsten, can you test this patch or arrange for it to be tested? Will do that Built, WFM. bye, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.”

Bug#636286: tagging 636286

2012-01-01 Thread Thorsten Glaser
Aurelien Jarno dixit: tags 636286 + wontfix Uhm, why? If someone working for glibc upstream says that the locale files produced by the Debian patched version of glibc are invalid… thanks for doing so silently and with no reason. Maybe I should indeed, as you expressed so nicely, stop to care

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

2012-02-27 Thread Thorsten Glaser
reassign 317466 src:eglibc forcemerge 534521 317466 thanks This is not a bug in pax, but eglibc _really_ should do something. How about something like this (for all affected functions)? #ifdef __USE_FILE_OFFSET64 FTSENT *fts_read (FTS *) __asm__(fts_read64); #else FTSENT *fts_read (FTS *);

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

2012-02-27 Thread Thorsten Glaser
Aurelien Jarno dixit: I disagree. Pax isn't built with large file support (because fts.h doesn't allow that), so even if eglibc is fixed, pax would need to be fixed. Blocking bug should be used instead. Right, I could have thought of that. The problem is not having fts_read64, but having a

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

2012-03-26 Thread Thorsten Glaser
Source: eglibc Version: 2.13-27 (The MIPS porters may please set a severity on this.) I’ve discovered this as a problem with the shells’ ulimit builtin (both mksh and GNU bash affected as they’re built with LFS, dash isn’t, and mksh-static uses dietlibc on both mips and mipsel which just ignores

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

2012-11-16 Thread Thorsten Glaser
Package: libc-bin Version: 2.13-35 Severity: important Hi! Reporting against libc-bin as that’s where this locale comes from: tg@freewrt:~ $ dpkg -S /usr/lib/locale/C.UTF-8 libc-bin: /usr/lib/locale/C.UTF-8 Verified to exist in sid (2.13-36). tg@freewrt:~ $ LC_ALL=C.UTF-8 perl -MPOSIX -e

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

2012-11-18 Thread Thorsten Glaser
Aurelien Jarno dixit: Indeed, LC_TIME has been written using en_US.UTF-8 as an example. Ah, okay. Can we please have the C.UTF-8 locale be a copy of the C locale with *only* the encoding set to UTF-8, nothing else changed? History has shown that writing such a locale is not as easy as you

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

2012-11-20 Thread Thorsten Glaser
Jonathan Nieder dixit: - Athlon/Opteron, VIA C3 Nehemiah, but not VIA C3 Ezra). ^ + C3 Ezla). ^ You introduced a pasto. bye, //mirabilos -- Darwinism never[…]applied to wizardkind. There's a more than fair amount of[…] stupidity

Bug#693852: eglibc: please include m68k bugfix

2012-11-20 Thread Thorsten Glaser
Source: eglibc Severity: wishlist Hi, can you please apply the following patch to, I guess, the next eglibc upload after the unfreeze? I just threw it into an unpacked 2.13-36 tree as debian/patches/m68k/cvs-fix-cancellable-syscall-with-5-or-6-arguments.diff and updated the series file, and it

Bug#693852: Powerpc/m68k issue running test_stack

2012-11-21 Thread Thorsten Glaser
Dixi quod… Ivan Maidanski dixit: Could you summarize please you suggestion how to fix this? I need to make a couple more checks. *Maybe* it got fixed with the new eglibc patch already, since the Debian package 7.3~alpha3+git20121114-1 unexpectedly *passed* all its tests. OK, after some tests,

Bug#634261: weird if (somesymbol) in eglibc

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

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

2013-06-26 Thread Thorsten Glaser
Package: libc6 Version: 2.17-6 Severity: important Hi, GNU libc6 in sid is breaking GNU CVS; some operations can cause a segfault. I’ve tracked it down to: tglase@tglase:~ $ cat x.c #define _GNU_SOURCE #include errno.h #include stdio.h #include string.h #include unistd.h void tst(const char *,

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

2013-06-26 Thread Thorsten Glaser
Debian Bug Tracking System dixit: If you wish to submit further information on this problem, please send it to 714...@bugs.debian.org. Oh well, a '%' is not in the list of DES inputs, so differing is permitted, but returning NULL is so very not nice. Shortening the string shows “DES” can be

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

2013-06-26 Thread Thorsten Glaser
Aurelien Jarno dixit: As the function is POSIX compliant, it looks like to me a documentation issue. Should this bug be reassigned to manpages-dev to mention the fact that the function might return NULL in case of error? The NULL-in-case-of-error mentioned by POSIX is when the function is not

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

2013-06-26 Thread Thorsten Glaser
Aurelien Jarno dixit: ambiguity that crypt can return NULL for any failure (i.e. not successful completion): Indeed, but, one, it doesn’t list any other error code (nor do the glibc manpages) and two, there _is_ something called common law: it’s been like this for decades. This is *your*

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

2013-06-26 Thread Thorsten Glaser
Aurelien Jarno dixit: Please provide a patch, and I will add it in the next upload. If you don't, you will sign responsible for all security holes introduced into previously-working code in the archive. It's freaking late at night, and I just spent hours fighting with gnulib and *then* hours I'd

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

2013-07-01 Thread Thorsten Glaser
Aurelien Jarno dixit: I am not sure we want to fix that. This behaviour has been introduced voluntarily to fix some issues with the previous code: http://sourceware.org/ml/libc-alpha/2012-05/msg00893.html […] The current behavior, while unpleasant, can lead to a DoS, but not to a security

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

2013-07-02 Thread Thorsten Glaser
Alexandre Oliva dixit: fault. In general, the former is more desirable; consider how much headscratching would ensue should a password mysteriously fail to be recognized, compared with that resulting from a segfault for dereferencing the result of crypt. Hrm. On the other hand… is it possible

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

2013-07-18 Thread Thorsten Glaser
Told you so… -- Forwarded message -- Subject: apt-listchanges: changelogs for tglase.lan.tarent.de cyrus-sasl2 (2.1.25.dfsg1-14) unstable; urgency=low * CVE-2013-4122: Handle NULL returns from glibc 2.17+ crypt() (Closes: #716835) -- To UNSUBSCRIBE, email to

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

2013-07-19 Thread Thorsten Glaser
On Thu, 18 Jul 2013, Carlos O'Donell wrote: * CVE-2013-4122: Handle NULL returns from glibc 2.17+ crypt() (Closes: #716835) I'm happy to see applications being fixed to follow the documented standard. Which is a violation of historic practice and “common law”. I’d be as happy to

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

2013-07-31 Thread Thorsten Glaser
retitle 714219 libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking lots of software thanks As seen on LWN: xlock can crash due to this, leaving the screen unlocked. At this point I feel confirmed in requesting that, no matter what would actually be the “correct”

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

2014-01-15 Thread Thorsten Glaser
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

Re: eglibc 2.18 (m68k)

2014-01-16 Thread Thorsten Glaser
Adam Conrad dixit: This would be much more useful to us if it hadn't been built with DEB_BUILD_OPTIONS=nocheck, so we could see what the state of the testsuite was. But nice that it builds at all, I guess. :) Mh. I can do that next time. Is there a way to run the tests independent of the

Re: eglibc 2.18 (m68k)

2014-01-19 Thread Thorsten Glaser
Dixi quod… Adam Conrad dixit: This would be much more useful to us if it hadn't been built with DEB_BUILD_OPTIONS=nocheck, so we could see what the state of the testsuite was. But nice that it builds at all, I guess. :) Mh. I can do that next time. Done:

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

2014-04-08 Thread Thorsten Glaser
Source: eglibc Version: 2.18-4 Followup-For: Bug #722348 Hi *, these messages are due to the inclusion of x32 in parts of Debian combined with the refusal of the Debian Linux Kernel team to add x32 support. Independent of the question of whether such support should be added or not, it is

Re: Time zone data for OpenJDK 8

2014-08-08 Thread Thorsten Glaser
On Fri, 8 Aug 2014, Emmanuel Bourg wrote: 5. Implement a java.time.zone.ZoneRulesProvider [3] that reads the TZif2 files installed by the tzdata package in /usr/share/zoneinfo. This would render the tzdata-java package obsolete in the long term. GNU ClassPath has a TZif2 parser [4] that could

Re: Time zone data for OpenJDK 8

2014-08-15 Thread Thorsten Glaser
On Fri, 15 Aug 2014, Emmanuel Bourg wrote: Why not, but the compiler for the old format isn't provided by openjdk-8, so we'll have another issue when openjdk-7 is removed (probably in Jessie+1). The old compiler would have to be copied into Eh, just do that before the freeze if you don’t

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

2015-01-12 Thread Thorsten Glaser
Package: libc-bin Version: 2.19-13 Severity: normal I’m puzzling a bit, and was searching for a locale with ISO 8601 time, to set my LC_TIME to. During that, I found: tglase@tglase:~ $ LC_TIME=en_GB.UTF-8 date +'%x %X' 12/01/15 10:28:01 tglase@tglase:~ $ LC_TIME=en_US.UTF-8 date +'%x %X'

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

2016-06-03 Thread Thorsten Glaser
Aurelien Jarno dixit: >EastAsian.txt explicitly lists the hexagrams as neutral width, so I don't Yes it does, but neutral does NOT always mean 1. I even looked it up today, as I was not familiar enough with neutral yet. >Looking at the behaviour from other systems, freebsd and netbsd both

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

2016-06-03 Thread Thorsten Glaser
Package: locales Version: 2.22-0experimental0 Severity: normal Tags: upstream Starting with locales 2.22-0experimental0, some chars have the wrong width; downgrading locales to 2.21-9 fixes the bugs. Test program: tglase@tglase:~ $ cat x.c #define _XOPEN_SOURCE #include #include #include

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

2016-02-02 Thread Thorsten Glaser
On Tue, 2 Feb 2016, root wrote: > tzdata (2016a-1) unstable; urgency=medium > * Change /etc/timezone into a symlink (closes: #803144) You mean /etc/localtime, hopefully?! bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393

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

2017-01-03 Thread Thorsten Glaser
On Mon, 2 Jan 2017, Aurelien Jarno wrote: > Looking at the issue, it actually appears in __vdso_clock_gettime, which > is provided by the kernel. This code handle the simple cases (REALTIME, > MONOTONIC, REALTIME_COARSE and _MONOTONIC_COARSE) and fallbacks to > the syscall in otherwise,

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

2017-07-11 Thread Thorsten Glaser
tags 826256 = upstream forwarded 826256 https://sourceware.org/bugzilla/show_bug.cgi?id=21750 thanks OK, I’ve forwarded this upstream and refreshed the researched data: https://sourceware.org/bugzilla/show_bug.cgi?id=21750 Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123

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

2017-07-12 Thread Thorsten Glaser
On Wed, 12 Jul 2017, Thorsten Glaser wrote: > An extra data point: > > (pbuild18806-dpo)root@tglase:/tmp/buildd/glibc-2.24 # > ./build-tree/x32-libc/nptl/tst-robust8 > > This reproducibly (several times in a row) terminates after > about one second with errorlevel 0 s

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

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

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

2017-08-24 Thread Thorsten Glaser
Source: glibc Version: 2.24-16 Severity: serious Justification: fails to build from source (but built successfully in the past) cf. https://buildd.debian.org/status/package.php?p=glibc For over three days now, src:glibc is FTBFS’ing virtually everywhere: amd64, arm64, armel, armhf, i386, mips,

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

2019-02-24 Thread Thorsten Glaser
On Sat, 23 Feb 2019, Thorsten Glaser wrote: > then give-back src:pax on both kfreebsd architectures. In the meantime, I had to do a pax upload to fix bugs anyway, so I just added a configure-time check for UTIME_OMIT, so it built now, although not using utimensat/futimes. In case you won

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

2019-02-23 Thread Thorsten Glaser
Package: libc0.1 Version: 2.25-2 Severity: normal glibc on Debian GNU/kFreeBSD is missing UTIME_OMIT, making src:pax FTBFS. While I could work around this by using the older functions, https://www.freebsd.org/cgi/man.cgi?query=utimensat indicates that the FreeBSD kernel has gained native support

Bug#932384: libc6: utmp broken

2019-07-18 Thread Thorsten Glaser
Package: libc6 Version: 2.28-10 Severity: important After hitting #932380 I looked at the source code of GNU screen, saw it uses the getutline(3) function, and compiled the example from its manpage. The output is not what I expected: tglase@tglase:~ $ ./a.out before adding entry: tglase :0

Re: Bug#932384: libc6: utmp broken

2019-07-18 Thread Thorsten Glaser
On Thu, 18 Jul 2019, Thorsten Glaser wrote: > utmp entries cannot be added (and the GNU screen source code contains > curse^Wcomplaints about the GNU API for utmp lacking the ability to > return success/error information, so the applications cannot even de‐ > tect this!), while the fi

Re: Bug#932384: libc6: utmp broken

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

Bug#932384: libc6: utmp broken

2019-07-18 Thread Thorsten Glaser
On Thu, 18 Jul 2019, Thorsten Glaser wrote: > glibc maintainers: unsure why screen works but not the example > code given that screen isn’t sgid… maybe you should have a look > at that, it still doesn’t work with the correct utmp permissions. This might also be a bug in the exampl

Bug#932384: libc6: utmp broken

2019-07-19 Thread Thorsten Glaser
Aurelien Jarno dixit: [ explanations ] >Therefore there is no bug, neither in glibc nor in the manpage. Closing >it. Agreed. Thank you for reviewing the problem, though. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)