Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Sven Joachim]

On 2024-04-03 22:47 +0200, Alejandro Colomar wrote:

> On Wed, Apr 03, 2024 at 06:01:50PM +0200, Sven Joachim wrote:
>> Control: severity -1 normal
>>
>> On 2024-04-03 11:29 +0200, Alejandro Colomar wrote:
>>
>> > I now see that `apt-file show glibc-doc` shows several more pages.  I'll
>> > have a look at them and maybe I also import them into the Linux
>> > man-pages project.
>>
>> AFAICS all of them have already been added there, right?
>
> Nope; I added the ones that I found in upstream glibc, and then I
> upgraded them to the version they had in Debian.  But for some reason, I
> didn't notice that there were more in Debian.  Or maybe I thought they
> were already in the Linux man-pages.  Whatever the reason, they're not
> there.
>
> See:
>
> $ diff -u \
>   <(apt-file show glibc-doc \
>   | awk '{print $2}' \
>   | grep /man/ \
>   | sed 's,^/usr/share/man/,,' \
>   | sed 's/\.gz$//' \
>   | sort) \
>   <(find src/linux/man-pages/man-pages/master/man* -type f \
>   | sed 's,^src/linux/man-pages/man-pages/master/,,' \
>   | sort) \
>   | grep ^-;
> --- /dev/fd/632024-04-03 22:40:00.524652442 +0200
> -man3/pthread_cond_broadcast.3
> -man3/pthread_cond_destroy.3
> -man3/pthread_cond_signal.3
> -man3/pthread_cond_timedwait.3
> -man3/pthread_cond_wait.3
> -man3/pthread_condattr_destroy.3
> -man3/pthread_getspecific.3
> -man3/pthread_key_delete.3
> -man3/pthread_mutex_destroy.3
> -man3/pthread_mutex_lock.3
> -man3/pthread_mutex_trylock.3
> -man3/pthread_mutex_unlock.3
> -man3/pthread_mutexattr_getkind_np.3
> -man3/pthread_mutexattr_gettype.3
> -man3/pthread_mutexattr_settype.3
> -man3/pthread_setspecific.3

Those are not additional pages, but just symlinks.

,
| $ file $(dpkg -L glibc-doc | tail -n17)
| /usr/share/man/man3/pthread_cond_broadcast.3.gz:   symbolic link to 
pthread_cond_init.3.gz
| /usr/share/man/man3/pthread_cond_destroy.3.gz: symbolic link to 
pthread_cond_init.3.gz
| /usr/share/man/man3/pthread_cond_signal.3.gz:  symbolic link to 
pthread_cond_init.3.gz
| /usr/share/man/man3/pthread_cond_timedwait.3.gz:   symbolic link to 
pthread_cond_init.3.gz
| /usr/share/man/man3/pthread_cond_wait.3.gz:symbolic link to 
pthread_cond_init.3.gz
| /usr/share/man/man3/pthread_condattr_destroy.3.gz: symbolic link to 
pthread_condattr_init.3.gz
| /usr/share/man/man3/pthread_getspecific.3.gz:  symbolic link to 
pthread_key_create.3.gz
| /usr/share/man/man3/pthread_key_delete.3.gz:   symbolic link to 
pthread_key_create.3.gz
| /usr/share/man/man3/pthread_mutex_destroy.3.gz:symbolic link to 
pthread_mutex_init.3.gz
| /usr/share/man/man3/pthread_mutex_lock.3.gz:   symbolic link to 
pthread_mutex_init.3.gz
| /usr/share/man/man3/pthread_mutex_trylock.3.gz:symbolic link to 
pthread_mutex_init.3.gz
| /usr/share/man/man3/pthread_mutex_unlock.3.gz: symbolic link to 
pthread_mutex_init.3.gz
| /usr/share/man/man3/pthread_mutexattr_destroy.3.gz:symbolic link to 
pthread_mutexattr_init.3.gz
| /usr/share/man/man3/pthread_mutexattr_getkind_np.3.gz: symbolic link to 
pthread_mutexattr_setkind_np.3.gz
| /usr/share/man/man3/pthread_mutexattr_gettype.3.gz:symbolic link to 
pthread_mutexattr_init.3.gz
| /usr/share/man/man3/pthread_mutexattr_settype.3.gz:symbolic link to 
pthread_mutexattr_init.3.gz
| /usr/share/man/man3/pthread_setspecific.3.gz:  symbolic link to 
pthread_key_create.3.gz
`

In the man-pages source such aliases are included as files just
containing a .so directive, those should indeed be added.

> I'll import those into the Linux man-pages in a week, when I get back
> from vacation.

Have a nice vacation!

Cheers,
   Sven

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Sven Joachim]

Control: severity -1 normal

On 2024-04-03 11:29 +0200, Alejandro Colomar wrote:

> Hi,
>
> On Tue, Apr 02, 2024 at 08:58:32PM +0200, Aurelien Jarno wrote:
>> Thanks, that sounds great that we can finally get rid out of those in
>> the debian package.
>>
>> >$ git diff --stat b06cd070f..128a3ae35
>> > man3/pthread_cond_init.3| 264 
>> > man3/pthread_condattr_init.3|  48 
>> > man3/pthread_key_create.3   | 178 +
>> > man3/pthread_mutex_init.3   | 241 ++
>> > man3/pthread_mutexattr_setkind_np.3 |  52 
>> > man3/pthread_once.3 |  44 
>> > 6 files changed, 827 insertions(+)
>
> I now see that `apt-file show glibc-doc` shows several more pages.  I'll
> have a look at them and maybe I also import them into the Linux
> man-pages project.

AFAICS all of them have already been added there, right?

>> > Debian's manpages-dev_6.7-1_all.deb has been the first package since
>> > that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to
>> > upgrade manpages-dev due to a conflict with glibc-doc.
>> >
>> >$ sudo apt-get upgrade -V;
>> >[...]
>> >Do you want to continue? [Y/n] y
>> >Reading changelogs... Done
>> >(Reading database ... 404853 files and directories currently installed.)
>> >Preparing to unpack .../manpages-dev_6.7-1_all.deb ...
>> >Unpacking manpages-dev (6.7-1) over (6.05.01-1) ...
>> >dpkg: error processing archive 
>> > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack):
>> > trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', 
>> > which is also in package glibc-doc 2.38-6
>> >Errors were encountered while processing:
>> > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb
>> >needrestart is being skipped since dpkg has failed
>> >E: Sub-process /usr/bin/dpkg returned an error code (1)
>>
>> I think this is actually not specific to the experimental version, those
>> manpages are also in the unstable version.
>
> Right.  I only installed the experimental one to see if the bug had
> been fixed (as reportbug(1) suggested trying it).
>
>> > Please, remove from glibc-doc those manual pages that conflict with
>> > manpages-dev.
>>
>> Noted. However following the time_t transition, the glibc package does
>> not build anymore on 32-bit architectures (i have just opened #1059937
>> to make people aware of that), so uploading a new glibc now is probably
>> not the best idea.
>
> Hmm, maybe you can drop the manual pages, but not upload yet, and wait
> for that bug to be fixed to do an upload without the pages.

Note that manpages-dev 6.7-2 has dropped the clashing files for the time
being.  I do not think there is any need to hurry, so I am downgrading
the severity of this bug.  Whenever the glibc-doc package in unstable
drops the manpages, we should file a bug against manpages-dev to include
them again.

Cheers,
   Sven

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Sven Joachim]

On 2024-04-01 19:02 +0200, Alejandro Colomar wrote:

> Hi Sven,
>
> On Mon, Apr 01, 2024 at 06:38:52PM +0200, Sven Joachim wrote:
>> Makes perfect sense, but at the moment it can only be uploaded to
>> experimental.
>>
>> > We're not in a freeze, so I guess that's fair game.
>>
>> We're not in a freeze but in the middle of the largest transition in
>> Debian history[1], and during that a new major glibc version in unstable is
>> out of the question.
>>
>> >> files for now and re-include either when glibc 2.38 is in unstable or
>> >> when it is in testing.
>> >
>> > Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch
>> > dropped?  Does 2.38 have any freeze at the moment?
>>
>> Yes.  Every new major glibc version requires a transition (requiring
>> rebuilds of all packages which use @GLIBC_PRIVATE symbols, among other
>> things), and the one for glibc 2.38[2] has been pending for three
>> months[3].
>
> Hmmm, I understand.  If you want to temporarily drop these pages from
> manpages-dev, go ahead.  Please undrop them when glibc-doc can make a
> new release.  BTW, I guess glibc-doc must match libc6 version?

It is built from the same source package, so yes.

Cheers,
   Sven

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Sven Joachim]

On 2024-04-01 18:00 +0200, Alejandro Colomar wrote:

> Hi Sven,
>
> On Mon, Apr 01, 2024 at 05:35:18PM +0200, Sven Joachim wrote:
>> Obviously the manpages-dev package should not have shipped these files
>> as long as there are in glibc-doc; this is tracked in #1068166.
>
> I CCed back in 2023-10 the debian-glibc@ list notifying that these pages
> were absorbed into the Linux man-pages project.  They didn't respond.

Thanks.  That might have fallen through the cracks.

>> Adding a Breaks on glibc-doc (<= 2.38-6) to manpages-dev is no good,
>> because that version is only in experimental and will remain there for
>> several weeks if not months.  I think manpages-dev should drop these
>
> Why not add glibc-doc 2.38-7 dropping the patch that adds these pages?

Makes perfect sense, but at the moment it can only be uploaded to
experimental.

> We're not in a freeze, so I guess that's fair game.

We're not in a freeze but in the middle of the largest transition in
Debian history[1], and during that a new major glibc version in unstable is
out of the question.

>> files for now and re-include either when glibc 2.38 is in unstable or
>> when it is in testing.
>
> Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch
> dropped?  Does 2.38 have any freeze at the moment?

Yes.  Every new major glibc version requires a transition (requiring
rebuilds of all packages which use @GLIBC_PRIVATE symbols, among other
things), and the one for glibc 2.38[2] has been pending for three
months[3].

>> There is also the problem that some derivatives (most notably Ubuntu)
>> are already shipping glibc 2.39 and will have to adjust Breaks/Replaces
>> versions in manpages-dev accordingly.
>
> Hmmm.  I suggest they patch glibc-doc to remove those manual pages.
> They have been unsupported for a long time.  The last change in
> glibc-doc is from 2013.

I guess Ubuntu can then drop the glibc-doc package entirely, as they do
not ship the upstream changelogs in it, and after dropping the pthread_*
manpages the package would be empty.  TBH, I do not see much value in
these changelogs and will probably uninstall glibc-doc from my systems.

Cheers,
   Sven


1. https://lists.debian.org/debian-devel-announce/2024/02/msg5.html
2. https://release.debian.org/transitions/html/glibc-2.38.html
3. https://bugs.debian.org/1059852

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Sven Joachim]

On 2024-04-01 16:23 +0200, Alejandro Colomar wrote:

> Package: glibc-doc
> Version: 2.38-6
> Severity: serious
> Justification: Policy 7.4
> X-Debbugs-Cc: a...@kernel.org, mar...@debian.org
>
> Dear Maintainer,
>
> The Linux man-pages project has recently added the pthread_*(3) manual
> pages that were provided by glibc-doc.  The first upstream version of
> the Linux man-pages that includes these pages is man-pages-6.06.  Here's
> what was added:
>
>   $ git diff --stat b06cd070f..128a3ae35
>man3/pthread_cond_init.3| 264 
>man3/pthread_condattr_init.3|  48 
>man3/pthread_key_create.3   | 178 +
>man3/pthread_mutex_init.3   | 241 ++
>man3/pthread_mutexattr_setkind_np.3 |  52 
>man3/pthread_once.3 |  44 
>6 files changed, 827 insertions(+)
>
> Debian's manpages-dev_6.7-1_all.deb has been the first package since
> that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to
> upgrade manpages-dev due to a conflict with glibc-doc.

>   $ sudo apt-get upgrade -V;
>   [...]
>   Do you want to continue? [Y/n] y
>   Reading changelogs... Done
>   (Reading database ... 404853 files and directories currently installed.)
>   Preparing to unpack .../manpages-dev_6.7-1_all.deb ...
>   Unpacking manpages-dev (6.7-1) over (6.05.01-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack):
>trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', 
> which is also in package glibc-doc 2.38-6
>   Errors were encountered while processing:
>/var/cache/apt/archives/manpages-dev_6.7-1_all.deb
>   needrestart is being skipped since dpkg has failed
>   E: Sub-process /usr/bin/dpkg returned an error code (1)

Obviously the manpages-dev package should not have shipped these files
as long as there are in glibc-doc; this is tracked in #1068166.

> Please, remove from glibc-doc those manual pages that conflict with
> manpages-dev.

Considering that the manpages in glibc-doc are not included upstream and
created via a Debian patch, that makes a lot of sense.  I was not aware
of that fact.

> Marcos, you'll also need to specify a breaks with glibc-doc versions
> up to (and including) 6.38-6 in the next revision of manpages-dev, and
> drop 6.7-1.

Adding a Breaks on glibc-doc (<= 2.38-6) to manpages-dev is no good,
because that version is only in experimental and will remain there for
several weeks if not months.  I think manpages-dev should drop these
files for now and re-include either when glibc 2.38 is in unstable or
when it is in testing.

There is also the problem that some derivatives (most notably Ubuntu)
are already shipping glibc 2.39 and will have to adjust Breaks/Replaces
versions in manpages-dev accordingly.  Thoughts?

Cheers,
   Sven

Bug#1061248: glibc: DEP17: move most files but rtld to /usr

[Sven Joachim]

Am 21.01.2024 um 15:25 schrieb Helmut Grohne:

> Source: glibc
> Version: 2.37-13
> Tags: patch
> User: helm...@debian.org
> Usertags: dep17m2
>
> Hi Aurelien,
>
> thanks for your answers on IRC to my design question. As promised here
> comes a patch that moves most files in binary packages built from glibc
> from aliased locations to /usr. This excludes the runtime dynamic linker
> for native libc packages (i.e. not multilib), because moving it would
> break filesystem bootstrap unless base-files installs the aliasing
> symlinks at the same time.

I have not studied the details, but this looks rather dangerous to me.
If you install the runtime dynamic linker in multilib packages below
/usr, but keep the native one at its current place, you risk losing it
when the multilib packages are removed.

For instance, I have both libc6:i386 and libc6-i386:amd64 installed.  If
the latter starts shipping /usr/lib/ld-linux.so.2 rather than
/lib/ld-linux.so.2, the "Replaces" in libc6:i386 becomes ineffective,
and we have basically a case of Dep17 P1.

True, there is already a file loss problem today.  If I were to remove
libc6:i386 now, I would be left without /lib/ld-linux.so.2 as well.  But
in such a situation it is always possible to remedy the situation by
reinstalling libc6-i386.  This is not ensured if only libc6-i386 is
removed, as essential programs might depend on libc6:i386, leaving no
easy way of recovery.

Cheers,
   Sven

Bug#1042562: libc6: broken utmp handling in 32-bit programs with 64-bit time_t

[Sven Joachim]

Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=30701

On 2023-07-30 13:25 +0200, Sven Joachim wrote:

> Package: libc6
> Version: 2.37-6
> Tags: upstream
>
> The utmp(5) interface has broken its compatibility in 32-bit programs
> built with -D_TIME_BITS=64.  In bits/utmpx.h we see this:
>
> ,
> | /* The fields ut_session and ut_tv must be the same size when compiled
> |32- and 64-bit.  This allows files and shared memory to be shared
> |between 32- and 64-bit applications.  */
> | #if __WORDSIZE_TIME64_COMPAT32
> |   __int32_t ut_session; /* Session ID, used for windowing.  */
> |   struct
> |   {
> | __int32_t tv_sec;   /* Seconds.  */
> | __int32_t tv_usec;  /* Microseconds.  */
> |   } ut_tv;  /* Time entry was made.  */
> | #else
> |   long int ut_session;  /* Session ID, used for windowing.  */
> |   struct timeval ut_tv; /* Time entry was made.  */
> | #endif
> `
>
> The definition of __WORDSIZE_TIME64_COMPAT32 can be found in bits/wordsize.h:
>
> ,
> | #ifdef __x86_64__
> | # define __WORDSIZE_TIME64_COMPAT32 1
> | /* Both x86-64 and x32 use the 64-bit system call interface.  */
> | # define __SYSCALL_WORDSIZE 64
> | #else
> | # define __WORDSIZE_TIME64_COMPAT32 0
> | #endif
> `
>
> So on i386 (and I suppose on other 32-bit architectures except x32)
> ut_tv is of struct timeval, and ut_tv.tv_sec is of time_t, which is
> actually a 64-bit integer in programs built with -D_TIME_BITS=64.
>
> One example where this already has caused problems is the who(1) program
> which has opted in for -D_TIME_BITS=64, see #1027135.

I had brought the "who" problem to the attention of the coreutils
developers[1], and they have now reported the issue in the Sourceware
Bugzilla.

Cheers,
   Sven


1. https://debbugs.gnu.org/64937

Bug#1042562: libc6: broken utmp handling in 32-bit programs with 64-bit time_t

[Sven Joachim]

Package: libc6
Version: 2.37-6
Tags: upstream

The utmp(5) interface has broken its compatibility in 32-bit programs
built with -D_TIME_BITS=64.  In bits/utmpx.h we see this:

,
| /* The fields ut_session and ut_tv must be the same size when compiled
|32- and 64-bit.  This allows files and shared memory to be shared
|between 32- and 64-bit applications.  */
| #if __WORDSIZE_TIME64_COMPAT32
|   __int32_t ut_session;   /* Session ID, used for windowing.  */
|   struct
|   {
| __int32_t tv_sec; /* Seconds.  */
| __int32_t tv_usec;/* Microseconds.  */
|   } ut_tv;/* Time entry was made.  */
| #else
|   long int ut_session;/* Session ID, used for windowing.  */
|   struct timeval ut_tv;   /* Time entry was made.  */
| #endif
`

The definition of __WORDSIZE_TIME64_COMPAT32 can be found in bits/wordsize.h:

,
| #ifdef __x86_64__
| # define __WORDSIZE_TIME64_COMPAT32   1
| /* Both x86-64 and x32 use the 64-bit system call interface.  */
| # define __SYSCALL_WORDSIZE   64
| #else
| # define __WORDSIZE_TIME64_COMPAT32   0
| #endif
`

So on i386 (and I suppose on other 32-bit architectures except x32)
ut_tv is of struct timeval, and ut_tv.tv_sec is of time_t, which is
actually a 64-bit integer in programs built with -D_TIME_BITS=64.

One example where this already has caused problems is the who(1) program
which has opted in for -D_TIME_BITS=64, see #1027135.  Once programs
start to _write_ utmp entries with a 64-bit ut_tv.tv_sec rather than
merely reading them, things could become more interesting. :-(


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

[Sven Joachim]

On 2023-01-02 19:08 +0100, Vincent Lefevre wrote:

> On 2023-01-02 18:07:52 +0100, Sven Joachim wrote:
>> On 2023-01-02 16:34 +0100, Vincent Lefevre wrote:
>> > There is no such issue under bullseye (Debian 11.6), which also has
>> > GNU Screen 4.09.00, so the breakage appears to be due to libc6.
>>
>> Without having looked at the problem: this appears to be a rather bold
>> conclusion.  There are also newer versions of mutt, ncurses and a few
>> other libraries which mutt or screen depend upon that could be
>> responsible.
>
> I've tested with the same version of Mutt (from Git). However, indeed,
> ncurses is different. I doubt that other libraries matter.

Probably not; the most likely candidates besides libc6 would be
ncurses-base (i.e. the terminfo database) and libncursesw6.  My advice
would be to start with a minimal bullseye chroot and then upgrade first
libc6, then ncurses-base and finally libncursesw6 to the sid or bookworm
versions.

>> > Example to reproduce the issue with the U+1FAF6 HEART HANDS character
>> > under Debian/unstable:
>> >
>> > 1. Run "screen" in a 80-column terminal.
>> >
>> > 2. Open this mailbox with "mutt -F /dev/null -f heart-hands.mbox".
>> >Result: line 10 is shifted 1 column to the right, and character "v"
>> >appears on the following line.
>>
>> I failed to reproduce that step, the 'v' appears on the last column for
>> me.
>
> Sorry, I did the test with my own version of Mutt. So, for this
> particular behavior at step 2, you need
>
>   mutt -n -F /dev/null -f heart-hands.mbox
>
> i.e. with the -n option so that the system-wide Muttrc configuration
> file is not read.

I still see the 'v' on the last column with mutt 2.2.9-1.

Cheers,
   Sven

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

[Sven Joachim]

On 2023-01-02 16:34 +0100, Vincent Lefevre wrote:

> Package: libc6
> Version: 2.36-7
> Severity: serious
>
> The new libc6 appears to have some change related to Unicode that
> yields display issues in screen 4.9.0-3, such as horizontal and/or
> vertical text shifting. A consequence of this text shifting is that
> in Mutt (in particular with arrow_cursor), one may select a message
> to be deleted, but a different message is actually deleted.
>
> There is no such issue under bullseye (Debian 11.6), which also has
> GNU Screen 4.09.00, so the breakage appears to be due to libc6.

Without having looked at the problem: this appears to be a rather bold
conclusion.  There are also newer versions of mutt, ncurses and a few
other libraries which mutt or screen depend upon that could be
responsible.

> Example to reproduce the issue with the U+1FAF6 HEART HANDS character
> under Debian/unstable:
>
> 1. Run "screen" in a 80-column terminal.
>
> 2. Open this mailbox with "mutt -F /dev/null -f heart-hands.mbox".
>Result: line 10 is shifted 1 column to the right, and character "v"
>appears on the following line.

I failed to reproduce that step, the 'v' appears on the last column for
me.

Cheers,
   Sven

Bug#986450: locales: non-ASCII characters in debconf dialogs are broken in German locale

[Sven Joachim]

Control; tags -1 patch

On 2021-04-06 11:42 +0200, Sven Joachim wrote:

> Package: locales
> Version: 2.31-11
> Severity: normal
> Tags: l10n
>
> Running "dpkg-reconfigure locales" in a German locale displays broken
> non-ASCII characters, see the attached screenshot.
>
> It seems this is because of a mismatch between content and declared
> encoding in debian/po/de.po.  I will send a patch when I have the bug
> number.

The attached patch should fix the problem, although I have not tested
it.  Would be good if this bug could be fixed before the bullseye
release, as it leaves a rather bad impression of Debian on new German
users.

Cheers,
Sven

From 63e86db18f950c49c7c90cb737feb480d4934c20 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Tue, 6 Apr 2021 11:47:43 +0200
Subject: [PATCH 1/1] debian/po/de.po: declare correct charset

Commit a7644d7c8f2b ("debian/po/de.po: recode to UTF-8.") changed the
encoding of the file to UTF-8, but inadvertently left the charset
at ISO-8859-15, resulting in broken debconf dialogs.

Closes: #986450
---
 debian/po/de.po | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/po/de.po b/debian/po/de.po
index 74a84c15..13b95629 100644
--- a/debian/po/de.po
+++ b/debian/po/de.po
@@ -12,7 +12,7 @@ msgstr ""
 "Language-Team: de \n"
 "Language: German\n"
 "MIME-Version: 1.0\n"
-"Content-Type: text/plain; charset=ISO-8859-15\n"
+"Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"

 #. Type: multiselect
--
2.31.0

Bug#986450: locales: non-ASCII characters in debconf dialogs are broken in German locale

[Sven Joachim]

Package: locales
Version: 2.31-11
Severity: normal
Tags: l10n

Running "dpkg-reconfigure locales" in a German locale displays broken
non-ASCII characters, see the attached screenshot.

It seems this is because of a mismatch between content and declared
encoding in debian/po/de.po.  I will send a patch when I have the bug
number.


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

Kernel: Linux 5.10.27-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.76
ii  libc-bin   2.31-11
ii  libc-l10n  2.31-11

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/locales_to_be_generated: de_DE ISO-8859-1, de_DE.UTF-8 UTF-8, 
de_DE@euro ISO-8859-15, en_DK ISO-8859-1, en_DK.UTF-8 UTF-8, en_GB.UTF-8 UTF-8, 
en_US.UTF-8 UTF-8, ru_RU ISO-8859-5, ru_RU.UTF-8 UTF-8
* locales/default_environment_locale: de_DE.UTF-8

Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system

[Sven Joachim]

On 2021-03-05 14:41 +0100, Aurelien Jarno wrote:

> control: notfound -1 libc6/2.28-10
> control: found -1 libc6/2.31-9
> control: severity -1 grave
>
> On 2021-03-04 19:26, Thomas Hahn wrote:
>> Package: libc6
>> Version: 2.28-10
>> Severity: normal
>> X-Debbugs-Cc: thah...@t-online.de
>>
>> Dear Maintainer,
>>
>> installed buster, then apt upgrade  was also fine,
>> but the following dist-upgrade put the system in a broken state.
>>
>> Preparing to unpack .../62-locales_2.31-9_all.deb ...
>> Unpacking locales (2.31-9) over (2.28-10) ...
>> Preparing to unpack .../63-openssh-server_1%3a8.4p1-4_amd64.deb ...
>> Unpacking openssh-server (1:8.4p1-4) over (1:7.9p1-10+deb10u2) ...
>> Preparing to unpack .../64-libc6_2.31-9_amd64.deb ...
>> whiptail: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not
>> found (required by /lib/x86_64-linux-gnu/libslang.so.2)
>
> This seems to show that libslang2 has been wrongly unpacked before
> libc6. Do you happen to have the beginning of the log? You can find it
> in /var/log/apt/term.log.*
>
>> debconf: whiptail output the above errors, giving up!
>> Checking for services that may need to be restarted...dpkg: error
>> processing archive
>> /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb (--unpack):
>>  new libc6:amd64 package pre-installation script subprocess returned error 
>> exit status 255
>> Selecting previously unselected package libcrypt1:amd64.
>> dpkg: considering deconfiguration of libc6:amd64, which would be broken by 
>> installation of libcrypt1:amd64 ...
>> dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64)
>> Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ...
>> De-configuring libc6:amd64 (2.28-10) ...
>> Unpacking libcrypt1:amd64 (1:4.4.17-1) ...
>> Errors were encountered while processing:
>>  /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb
>> Error: Timeout was reached
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> To unbreak your system the best would be to unpack libc6 manually using
> the following command:
>   dpkg -x /var/cache/apt/libc6_2.31-9_amd64.deb /

No, never do that!  This command actually runs "dpkg-deb -x" which,
unlike "dpkg -i", will silently overwrite symlinks to directories on the
filesystem with directories contained in the package.  This is very bad
if /lib is a symlink to /usr/lib (the "usrmerge" layout).

Cheers,
   Sven

Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Sven Joachim]

On 2020-11-19 19:47 +0100, Marco d'Itri wrote:

> On Nov 16, Niko Tyni  wrote:
>
>> As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1
>> for one release cycle, so that libc6 cannot be unpacked before libcrypt1
>> is fully installed.
> I think that Niko is right, so I would like to know the opinion of the
> glibc maintainers.

I am not one of them, but AFAICS that would introduce a fatal circular
dependency between libc6 and libcrypt1: libc6 needs libcrypt1 to be
configured before it can be unpacked, but libcrypt1 depends on libc6 so
it cannot be configured before libc6 is at least unpacked.

Cheers,
   Sven

Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Sven Joachim]

On 2020-11-13 18:23 +0100, Niels Thykier wrote:

> Control: reassign -1 perl-base
> Control: affects -1 upgrade-reports
> Control: severity -1 grave
>
> Hi Perl team,
>
> I have reassigned this bug to perl because perl-base being essential
> must remain functional during an upgrade and AFAICT perl-base fails in
> this case here.
>
> If it is a direct linkage, then you might be needing a Pre-Depends.  If
> it is an indirect linkage then I am not sure how to fix it. :-/

I don't think perl-base is doing anything wrong here, it already uses
Pre-Depends.  AFAICS the problem is that libcrypt.so.1 can temporarily
go missing if libc6 2.31-4 is unpacked before libcrypt1, breaking the
assumption that binaries from essential packages are always usable.

I don't have a good idea how to fix that, though. :-(

Cheers,
   Sven

> Alois Wohlschlager:
>> Package: upgrade-reports
>> Severity: critical
>> Justification: breaks the whole system
>> X-Debbugs-Cc: alo...@gmx-topmail.de
>> 
>> Dear Maintainer,
>> 
>> *** Reporter, please consider answering these questions, where appropriate 
>> ***
>> 
>>* What led up to the situation?
>> 
>>Do an upgrade from buster to bullseye.
>> 
>> 
>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>> 
>>1. adjust sources.list
>>2. apt upgrade
>>3. apt dist-upgrade
>> 
>>* What was the outcome of this action?
>> 
>>apt dist-upgrade goes horribly wrong. Excerpt from the log:
>> 
>> ---
>> Entpacken von libc6:amd64 (2.31-4) über (2.28-10) ...
>> Vormals nicht ausgewähltes Paket libc6:i386 wird gewählt.
>> Vorbereitung zum Entpacken von .../4-libc6_2.31-4_i386.deb ...
>> Entpacken von libc6:i386 (2.31-4) ...
>> Vormals nicht ausgewähltes Paket libgcc-s1:i386 wird gewählt.
>> Vorbereitung zum Entpacken von .../5-libgcc-s1_10.2.0-16_i386.deb ...
>> Entpacken von libgcc-s1:i386 (10.2.0-16) ...
>> Vormals nicht ausgewähltes Paket gcc-10-base:i386 wird gewählt.
>> Vorbereitung zum Entpacken von .../6-gcc-10-base_10.2.0-16_i386.deb ...
>> Entpacken von gcc-10-base:i386 (10.2.0-16) ...
>> /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot 
>> open
>> shared object file: No such file or directory
>> dpkg: Fehler: Fehler beim Ausführen des Hooks »if [ -x /usr/share/debian-
>> security-support/check-support-status.hook ] ; then /usr/sh
>> are/debian-security-support/check-support-status.hook ; fi«, Exitkode 32512
>> ---
>> 
>>At this point, perl is still the version from buster, and libcrypt1 is not
>> yet installed. The missing libcrypt.so.1 also completely breaks PAM, so login
>> and sudo don't work any more.
>>To recover from this outcome, I had to boot with "init=/bin/sh", install 
>> the
>> libcrypt1 package with dpkg and run "apt -f install" twice. This rendered the
>> system operational again and a further "apt dist-upgrade" ran through 
>> smoothly.
>> 
>>* What outcome did you expect instead?
>> 
>>libcrypt1 is installed before libcrypt.so.1 is required again, so the 
>> dist-
>> upgrade can proceed normally.
>> 
>> [...]

Bug#953867: error when compiling wine

[Sven Joachim]

Control: reassign -1 cpp-9
Control: forcemerge 953806 -1

On 2020-03-14 10:11 +0100, Berillions wrote:

> Package: libc6-dev
> Version: 2.30-2
>
> Hello,
>
> I try to build plain wine-5.4 on my debian sid 64bits (directly on my
> system or in a chroot with pbuilder) and i have an error about "limits.h"
> during configure :
>
> /usr/include/limits.h:124:26: error: no include path in which to search for
>> limits.h
>>   124 | # include_next 
>>   |
>>
>
> This error appears when i want to build by myself plain wine-5.4,
> wine-staging-5.3 or rebuild wine-development. Curiously, this error does
> not appears when i build wine/wine-staging/wine-development in a 32bits sid
> chroot.
>
> I found that build my package in a 64bits testing chroot fix the issue
> because libc6-dev=2.29-10 is installed. So something is broken in the
> package from Sid.

Yes, something is (or was, at it has already been fixed) broken, but in
a different package.  Upgrade gcc-9 to version 9.3.0-3.

Cheers,
   Sven

Bug#953815: libc6-dev: Cannot build GNU Emacs - limits.h error in configure

[Sven Joachim]

Control: reassign -1 cpp-9
Control: forcemerge 953806 -1

On 2020-03-13 20:03 +0100, Adam Sjøgren wrote:

> Package: libc6-dev
> Version: 2.30-2
> Severity: normal
>
> Dear Maintainer,
>
> I cannot build GNU Emacs on Debian unstable after the latest update - 
> configure
> fails with an error with the limits.h include.
>
> Here is a minimal reproduction:
>
> $ cat test.c
> #include 
> #include 
>
> int main(void) {
> exit(0);
> }
> $ gcc -Wall test.c
> In file included from test.c:2:
> /usr/include/limits.h:124:26: error: no include path in which to search for 
> limits.h
>   124 | # include_next 
>   |  ^
> $ 

Known problem, wait for gcc-9 9.3.0-3 to appear on your mirror.
Welcome to unstable!

Cheers,
   Sven

Bug#353867: Please add a silent option to rpcinfo

[Sven Joachim]

Control:; reassign -1 rpcbind

This bug has been assigned to libc6 which no longer ships the rpcinfo
program.

On 2006-03-26 15:04 +0200, Steinar H. Gunderson wrote:

> tags 353867 - patch
> thanks
>
> On Tue, Feb 21, 2006 at 03:55:17PM +0100, Stephan Krempel wrote:
>> -   $PREFIX/bin/rpcinfo -u localhost nfs 3 >/dev/null 2>&1 ||
>> +   $PREFIX/bin/rpcinfo -u localhost nfs 3 >/dev/null 2>&1 \
>> +  /dev/console>&1 ||
>
> This patch does not what you think it does. More specifically, it is
> identical to
>
>   $PREFIX/bin/rpcinfo -u localhost nfs 3 /dev/console >/dev/null 2>&1
>
> as you cannot route arbitrary files around like that, only file descriptors.
> rpcinfo naturally takes no "/dev/console" parameter, and thus exits with a
> syntax error, which is sent to /dev/null.
>
> You might want to ask the libc6 people to add a "silent" option to rpcinfo,
> or at least something that doesn't open /dev/console if that is indeed what's
> happening.

AFAICT there is no such option, so this bug might still be relevant.

Cheers,
   Sven

Bug#587169: rpcinfo: '-u localhost nfs' is not working if nfs is running on tcp only

[Sven Joachim]

Control: reassign -1 rpcbind

This bug has been reported against rpcinfo which is no longer shipped in
libc-bin, but rather in rpcbind.  I could not tell off-hand if it still
relevant.

Cheers,
   Sven

Am 25.06.2010 um 21:46 schrieb Alexander Kretschmer:

> Package: libc-bin
> Version: 2.10.2-6
> Severity: important
>
>
>
> -- System Information:
> Debian Release: 5.0.4
>   APT prefers stable
>   APT policy: (990, 'stable')
> Architecture: i386 (i686)
>
> Kernel: Linux 2.6.27.10 (SMP w/2 CPU cores)
> Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)
> Shell: /bin/sh linked to /bin/bash
>
> When runnig nfs 3 on TCP and UDP rpcinfo shows the following
>
> rpcinfo -p
>Program Vers Proto   Port
> 102   tcp111  portmapper
> 102   udp111  portmapper
> 1000241   udp  33934  status
> 1000241   tcp  40718  status
> 1000211   udp  54228  nlockmgr
> 1000213   udp  54228  nlockmgr
> 1000214   udp  54228  nlockmgr
> 1000211   tcp  57003  nlockmgr
> 1000213   tcp  57003  nlockmgr
> 1000214   tcp  57003  nlockmgr
> 133   udp   2049  nfs
> 133   tcp   2049  nfs
> 151   udp  41087  mountd
> 151   tcp  44256  mountd
> 152   udp  41087  mountd
> 152   tcp  44256  mountd
> 153   udp  41087  mountd
> 153   tcp  44256  mountd
>
> When running nfs on TCP only it shows this:
>
> rpcinfo -p
>Program Vers Proto   Port
> 102   tcp111  portmapper
> 102   udp111  portmapper
> 1000241   udp  33934  status
> 1000241   tcp  40718  status
> 1000211   udp  38327  nlockmgr
> 1000213   udp  38327  nlockmgr
> 1000214   udp  38327  nlockmgr
> 1000211   tcp  45910  nlockmgr
> 1000213   tcp  45910  nlockmgr
> 1000214   tcp  45910  nlockmgr
> 133   tcp   2049  nfs
> 151   udp  50650  mountd
> 151   tcp  41600  mountd
> 152   udp  50650  mountd
> 152   tcp  41600  mountd
>
> You can see that mountd isnt running in Vers 3. The init.d script for 
> nfs-kernel-server checks weather nfs is running in vers 3 by calling
>
> rpcinfo -u localhost nfs 3
>
> It gets as an answer that program 13 isn't registered. Its working fine 
> if nfs is running on udp or both udp and tcp.

Bug#700472: Upgrade of the foreign arch libc6 causes service restart

[Sven Joachim]

Control: tags -1 + patch

On 2013-02-13 06:20 +0600, Andrey Rahmatullin wrote:

> Package: libc6
> Version: 2.17-0experimental2
> Severity: wishlist
>
> Filing as wishlist, maybe it's minor or even worse for some people.
>
> The postinst script of libc6 checks services that need to be restarted not
> taking into account that those services may be of a different arch and so not
> using the libc6 being upgraded. That also means when you upgrade both
> libc6:amd64 and libc6:i386 you get double restart of all those services.

Today, upgrading libc6:amd64 and libc6:i386 to 2.29-1, I got annoyed by
this again and had a look what needs to be done.  The attached patch
(lightly tested, I have only a few amd64 and no i386 services running)
appears to do the trick.  It also drops the need for awk in the
maintainer scripts.

Feedback and brave testers welcome!

Cheers,
   Sven

From 8d3ef80d688b71503dc369b68bf0323349e9fbda Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Mon, 9 Sep 2019 13:46:28 +0200
Subject: [PATCH 1/1] Do not restart services of different architecture than
 libc

Only check services in packages which are of the same architecture, or
"arch:all".  This is most easily done by replacing the rather
convoluted way of parsing "dpkg --status" output by switching to a
more suitable output format of dpkg-query.  As a bonus, awk is no
longer used in the maintscripts.

Note that services in architecture-independent packages like
postgresql-common will still be restarted twice, since there is no
obvious way to tell the architecture of the actual binaries which need
to be re-executed.
---
 debian/script.in/nsscheck.sh | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/debian/script.in/nsscheck.sh b/debian/script.in/nsscheck.sh
index 80dfd2fb..623278c0 100644
--- a/debian/script.in/nsscheck.sh
+++ b/debian/script.in/nsscheck.sh
@@ -1,6 +1,8 @@
 	echo -n "Checking for services that may need to be restarted..."
-	# Only get the ones that are installed, and configured
-	check=$(dpkg -s $check 2> /dev/null | egrep '^Package:|^Status:' | awk '{if ($1 ~ /^Package:/) { package=$2 } else if ($0 ~ /^Status: .* installed$/) { print package }}')
+	# Only get the ones that are installed, of the same architecture
+	# as libc (or arch all) and configured
+	check=$(dpkg-query -W -f='${binary:Package} ${Status} ${Architecture}\n' $check 2> /dev/null | \
+			grep -E "installed (all|${DPKG_MAINTSCRIPT_ARCH})$" | sed 's/[: ].*//')
 	# some init scripts don't match the package names
 	check=$(echo $check | \
 		sed -e's/\bapache2.2-common\b/apache2/g' \
--
2.23.0

Bug#939871: glibc: python3:native build dependency incorrectly marked as

[Sven Joachim]

Source: glibc
Version: 2.29-1
Severity: normal

According to the INSTALL file, Python is now required to build glibc:

,
|* Python 3.4 or later
|
|  Python is required to build the GNU C Library.  As of release time,
|  Python 3.7.1 is the newest verified to work for building and
|  testing the GNU C Library.
`

Indeed, building with the nocheck profile in a python-less chroot fails:

,
| $ sbuild --no-arch-all --arch=i386 --profiles=nocheck
| [...]
| checking if i686-linux-gnu-gcc-9 is sufficient to build libc... yes
| checking for i686-linux-gnu-nm... i686-linux-gnu-nm
| checking for python3... no
| checking for python... no
| configure: error:
| *** These critical programs are missing or too old: python
| *** Check the INSTALL file for required versions.
| make: *** [debian/rules.d/build.mk:66: 
/<>/stamp-dir/configure_libc] Error 1
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2
`


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

Kernel: Linux 5.3.0-rc8-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#761300: libc6: Printf("%c",'x') does not follow stdio

[Sven Joachim]

Am 14.10.2018 um 13:38 schrieb Florian Weimer:

> * Sven Joachim:
>
>> This result is rather surprising.  After all, "putchar('x')" is supposed
>> to do the same as "putc('x', stdout)", but here it does not.
>
> Can you reproduce this with something newer than 2.13-38+rpi2+deb7u3?
> Or on something else besides armhf?

Surely, I tested 2.27-6 on amd64.

Cheers,
   Sven

Bug#761300: libc6: Printf("%c",'x') does not follow stdio

[Sven Joachim]

Control: retitle -1 libc6: putchar does not follow stdio

On 2014-09-12 09:10 -0700, Thomas D. Dean wrote:

> Package: libc6
> Version: 2.13-38+rpi2+deb7u3
> Severity: normal
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> Redirecting stdout in C code does not work for printf("%c",'x')
> I ssh into the system.  I want to redirect all output to stdout to
> the local terminal.  This works as expected for everything except
> when printing a single character.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
>   FILE *display_fp;
>   if ((display_fp = fopen("/dev/tty1","r+")) == NULL) {
>  perror("Open /dev/tty1");
>  return -1;
>   }
>   stdout = display_fp;
>
> Then,
>
> printf("%s","asdfasdf"); /* output to /dev/tty1 */
> printf("%c",'x'); /* output to original terminal */
>
>* What was the outcome of this action?
>
> All the output except for the "%c" case went to /dev/tty1.  The
> output in the "%c" case went to the ssh terminal

It is actually a bit more subtle than that, as gcc has its own printf
builtin function which comes into play.  Compiling the program with
-fno-builtin in fact makes it work as intended (at least with glibc
2.27-6).

Looking closer, I found that with -fno-builtin

printf("%c",'x');   works
putc('x', stdout);  works
putchar('x');   exhibits the bug

This result is rather surprising.  After all, "putchar('x')" is supposed
to do the same as "putc('x', stdout)", but here it does not.

I'm attaching the whole program, so that future researchers have less to
copy and paste.

Cheers,
   Sven

#include 
#include 

int main (int argc, char** argv)
{
  FILE *display_fp;
  if ((display_fp = fopen("/dev/tty1","r+")) == NULL) {
perror("Open /dev/tty1");
return -1;
  }
  stdout = display_fp;
  printf("%s","asdfasdf"); /* output to /dev/tty1 */
  putchar('x'); /* output to original terminal */
}

Bug#903376: libc6-amd64: installed package size has exploded

[Sven Joachim]

Control: reassign -1 binutils 2.30.90.20180627-1
Control: retitle -1 binutils: produces large 64-bit libraries on i386
Control: affects -1 libc6-amd64 libc6-x32

On 2018-07-09 11:19 +0200, Sven Joachim wrote:

> Package: libc6-amd64
> Version: 2.27-4
> Severity: important
>
> On i386, libc6-amd64 and libc6-x32 install more than one gigabyte each:
>
> ,
> | $ apt-cache show libc6-amd64 libc6-x32 | grep Installed-Size
> | Installed-Size: 1143839
> | Installed-Size: 1143407
> `
>
> Looking at /lib64, all the .so files from libc6-amd64 are over four
> megs, although file(1) reports them as stripped.

Looks like that is a binutils bug, I see the same problem when building
the ncurses multilib packages.  Apparently this started when I upgraded
binutils from 2.30-22 to 2.30.90.20180627-1.

These libraries have a large number of null bytes in them, their
occupied space is reduced considerably in a sparse copy:

,
| $ du /lib64/ld-2.27.so 
| 4136/lib64/ld-2.27.so
| $ cp --sparse=always /lib64/ld-2.27.so /tmp
| $ du /tmp/ld-2.27.so   
| 164 /tmp/ld-2.27.so
`

> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (101, 'experimental')
> Architecture: i386 (x86_64)

Note that binutils on amd64 is apparently unaffected, I haven't looked
at other architectures.

Cheers,
   Sven

Bug#903376: libc6-amd64: installed package size has exploded

[Sven Joachim]

Package: libc6-amd64
Version: 2.27-4
Severity: important

On i386, libc6-amd64 and libc6-x32 install more than one gigabyte each:

,
| $ apt-cache show libc6-amd64 libc6-x32 | grep Installed-Size
| Installed-Size: 1143839
| Installed-Size: 1143407
`

Looking at /lib64, all the .so files from libc6-amd64 are over four
megs, although file(1) reports them as stripped.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.18.0-rc4-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6-amd64 depends on:
ii  libc6  2.27-4

libc6-amd64 recommends no packages.

libc6-amd64 suggests no packages.

-- no debconf information

Bug#888073: glibc: Support amd64 systems without /lib64

[Sven Joachim]

On 2018-01-24 21:05 +0100, Javier Serrano Polo wrote:

> El dc 24 de 01 de 2018 a les 18:26 +0100, Aurelien Jarno va escriure:
>> The dynamic linker path is part of the
>> x86-64 ABI and is present in all ELF executables.
>
> I am aware that the original specification has that quirk, but it was
> made without multiarch in mind. Would you choose /lib64 if you could
> decide? I would not. I think that if there is a will this can be fixed.
>
> Other architectures are easy to see. For instance, m68k and powerpc
> conflict with /lib/ld.so.1. amd64's interpreter does not conflict, but
> all interpreters should be under /lib. I see /lib64 as a mistake that
> can be fixed.

/lib64 is a mistake, but it cannot be fixed without rebuilding the
world.  Which is fine for operating systems like OpenBSD where there are
no third-party binaries, but not on Linux.

>> Moving it means
>> rebuilding all the packages.
>
> We do not want that.

Well, then you have to live with /lib64.

Cheers,
   Sven

Bug#536506: glibc-doc-reference: clutters up main info directory

[Sven Joachim]

On 2013-07-10 21:32 +0200, Sven Joachim wrote:

> On 2009-07-11 08:02 +0200, Sven Joachim wrote:
>
>> tags 536506 + patch
>> thanks
>>
>> On 2009-07-11 02:06 +0200, Aurelien Jarno wrote:
>>
>>> tag 536506 + help
>>> thanks
>>>
>>> On Fri, Jul 10, 2009 at 05:56:01PM +0200, Sven Joachim wrote:
>>>> Package: glibc-doc-reference
>>>> Version: 2.9-1
>>>> Severity: normal
>>>> 
>>>> Your package puts an entry for every libc function and macro into the
>>>> main info directory, using up more than 1700 lines.  This has been
>>>> triggered by the transition to GNU's install-info; apparently the dpkg
>>>> implementation ignored secondary INFO-DIR-SECTION entries.
>>>> 
>>>
>>> Could you have more details about what should be changed to fix that?
>>
>> There should not be a direntry for every function (upstream includes
>> them on purpose, but this is a big abuse, that is what indices are
>> for).  The following minimal patch avoids this:
>>
>>--8<---cut here---start->8---
>> --- glibc-doc-reference-2.9.orig/manual/libc.texinfo
>> +++ glibc-doc-reference-2.9/manual/libc.texinfo
>> @@ -9,7 +9,6 @@
>>  @direntry
>>  * Libc: (libc). C library.
>>  @end direntry
>> -@include dir-add.texi
>>  
>>  @c This tells texinfo.tex to use the real section titles in xrefs in
>>  @c place of the node name, when no section title is explicitly given.
>>--8<---cut here---end--->8---
>
> Alas, this patch got lost in the 2.17-1 upload although it still
> applies.  Perhaps a patch system would have avoided this problem?

There is now a patch system, but the patch for this bug (along with a
few others which may or may not still be relevant) has not been applied
when converting to the 3.0 (quilt) format.  So I'm attaching it again.

Thanks for finally updating to a newer version! :)

Cheers,
   Sven

--- a/manual/libc.texinfo
+++ b/manual/libc.texinfo
@@ -18,7 +18,6 @@
 @direntry
 * Libc: (libc). C library.
 @end direntry
-@include dir-add.texi
 
 @include pkgvers.texi
 

Bug#836446: libc6-dev: depends on linux-libc-dev:$arch, breaking debootstrap

[Sven Joachim]

Package: libc6-dev
Version: 2.24-1
Severity: important

The fix for bug #834706 has the side effect that libc6-dev now depends
on linux-libc-dev:$arch :

,
| $ apt-cache show libc6-dev | grep ^Depends
| Depends: libc6 (= 2.24-1), libc-dev-bin (= 2.24-1), linux-libc-dev:i386 (>= 
4.6.4-1)
`

While dpkg and apt obviously don't have a problem with that, debootstrap
cannot cope with it, and "debootstrap --variant=buildd" fails to even
download linux-libc-dev.  See the attached log.

Please clone/reassign to debootstrap as you see fit, but in any case it
would be nice to remove the extraneous arch qualification in the
dependency.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 4.7.2-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6-dev depends on:
ii  libc-dev-bin 2.24-1
ii  libc62.24-1
pn  linux-libc-dev:i386  

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
ii  glibc-doc 2.24-1
ii  manpages-dev  4.07-1

-- no debconf information

gpgv: Signature made Sat Sep  3 05:35:17 2016 CEST
gpgv:using RSA key 8B48AD6246925553
gpgv: Good signature from "Debian Archive Automatic Signing Key (7.0/wheezy) 
"
gpgv: Signature made Sat Sep  3 05:35:17 2016 CEST
gpgv:using RSA key 7638D0442B90D010
gpgv: Good signature from "Debian Archive Automatic Signing Key (8/jessie) 
"
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing architecture
Selecting previously unselected package base-passwd.
(Reading database ... 0 files and directories currently installed.)
Preparing to unpack .../base-passwd_3.5.40_i386.deb ...
Unpacking base-passwd (3.5.40) ...
dpkg: base-passwd: dependency problems, but configuring anyway as you requested:
 base-passwd depends on libc6 (>= 2.8); however:
  Package libc6 is not installed.
 base-passwd depends on libdebconfclient0 (>= 0.145); however:
  Package libdebconfclient0 is not installed.

Setting up base-passwd (3.5.40) ...
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 24 package 'dpkg':
 missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 24 package 'dpkg':
 missing architecture
Selecting previously unselected package base-files.
dpkg: regarding .../base-files_9.6_i386.deb containing base-files, 
pre-dependency problem:
 base-files pre-depends on awk
  awk is not installed.

dpkg: warning: ignoring pre-dependency problem!
(Reading database ... 41 files and directories currently installed.)
Preparing to unpack .../base-files_9.6_i386.deb ...
Unpacking base-files (9.6) ...
dpkg: base-files: dependency problems, but configuring anyway as you requested:
 base-files depends on awk; however:
  Package awk is not installed.

Setting up base-files (9.6) ...
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 50 package 'dpkg':
 missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 50 package 'dpkg':
 missing architecture
dpkg: regarding .../archives/dpkg_1.18.10_i386.deb containing dpkg, 
pre-dependency problem:
 dpkg pre-depends on libbz2-1.0
  libbz2-1.0 is not installed.

dpkg: warning: ignoring pre-dependency problem!
dpkg: regarding .../archives/dpkg_1.18.10_i386.deb containing dpkg, 
pre-dependency problem:
 dpkg pre-depends on libc6 (>= 2.11)
  libc6 is not installed.

dpkg: warning: ignoring pre-dependency problem!
dpkg: regarding .../archives/dpkg_1.18.10_i386.deb containing dpkg, 
pre-dependency problem:
 dpkg pre-depends on liblzma5 (>= 5.1.1alpha+20120614)
  liblzma5 is not installed.

dpkg: warning: ignoring pre-dependency problem!
dpkg: regarding .../archives/dpkg_1.18.10_i386.deb containing dpkg, 
pre-dependency problem:
 dpkg pre-depends on libselinux1 (>= 2.3)
  libselinux1 is not installed.

dpkg: warning: ignoring pre-dependency problem!
dpkg: regarding .../archives/dpkg_1.18.10_i386.deb containing dpkg, 
pre-dependency problem:
 dpkg pre-depends on zlib1g (>= 1:1.1.4)
  zlib1g is not installed.

dpkg: warning: ignoring pre-dependency problem!
dpkg: regarding .../archives/dpkg_1.18.10_i386.deb containing dpkg, 
pre-dependency problem:
 dpkg pre-depends on tar (>= 1.23)
  tar is not installed.

dpkg: warning: ignoring pre-dependency problem!
(Reading database ... 118 files and directories currently installed.)
Preparing to unpack .../archives/dpkg_1.18.10_i386.deb ...
Unpacking dpkg (1.18.10) over (1.18.10) ...
dpkg: dpkg: dependency problems, but configuring anyway as you requested:
 dpkg depends on libbz2-1.0; however:
  Package libbz2-1.0 is not installed.
 dpkg depends on 

Bug#827095: base-files and libc-bin install different /etc/nsswitch.conf files

[Sven Joachim]

Package: base-files,libc-bin

Both base-files and libc-bin install the /etc/nsswitch.conf file.
Although it has been agreed in #673271 that libc-bin should take over
responsibility for it, base-files still installs and updates it.
Moreover, in response for #699090 base-files has updated its copy, and
now it differs from libc-bin's version:

,
|  diff -u /usr/share/base-files/nsswitch.conf /usr/share/libc-bin/nsswitch.conf
| --- /usr/share/base-files/nsswitch.conf 2014-05-04 14:38:37.0 +0200
| +++ /usr/share/libc-bin/nsswitch.conf   2016-03-21 00:45:12.0 +0100
| @@ -7,7 +7,6 @@
|  passwd: compat
|  group:  compat
|  shadow: compat
| -gshadow:files
|  
|  hosts:  files dns
|  networks:   file
`

The net effect is apparently that the content of /etc/nsswitch.conf in
fresh installations depends on whether libc-bin or base-files is
configured first, which is bad.  Could you please work out who should be
responsible for that file?


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 4.6.2-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#824127: glibc: Should build-depend on dpkg (>= 1.18.7) on any-i386

[Sven Joachim]

Source: glibc
Version: 2.22-8
Severity: normal

Bug #759495 redux: the cputable file is shipped by dpkg, not by
dpkg-dev, so build-depending on dpkg-dev (>= 1.18.7) does not achieve
anything.

While the build dependency on a recent g++-5 ensures that the right
compiler is used (i586-linux-gnu is a symlink to i686-linux-gnu), when
building with dpkg 1.18.4 I see lines with
"…-I../sysdeps/unix/sysv/linux/i386/i586…" in the build log, which seems
to imply that memcpy and friends don't get optimized for i686.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

Bug#759495: glibc: should build-depend on dpkg (= 1.17.11) on any-i386

[Sven Joachim]

Source: glibc
Version: 2.19-10
Severity: normal

From the Debian changelog:

,
|   * debian/control.in/main: build-depends on dpkg-dev (= 1.17.1) and
| gcc-4.8 (= 4.8.3-8) to make sure to get the new i586 GNU triplet on
| i386, hurd-i386 and kfreebsd-i386.
`

However, the cputable was only changed in dpkg 1.17.11 rather than
1.17.1, and it is shipped in the dpkg package, not in dpkg-dev.


-- 
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/87mwap4zdw@turtle.gmx.de

Bug#754596: libc6 package upgrade sends ISO-2022 escape sequences to a terminal which doesn't support them (PuTTY in UTF-8 mode)

[Sven Joachim]

On 2014-07-12 23:30 +0200, Stephen Powell wrote:

 The problem occurs when libc6 must be upgraded during apt-get upgrade
 or apt-get dist-upgrade.  I see a screen which looks like this:

 -

 lu Configuring libc6:s390x tk
 x Running services and programs that are using NSS need to be restarted,x
 x otherwise they might not be able to do lookup or authentication any more  x
 x (for services such as ssh, this can affect your ability to login).x
 x Please review the following space-separated list of init.d scripts forx
 x services to be restarted now, and correct it if needed.   x
 x   x
 x Note: restarting sshd/telnetd should not affect any existing  x
 x connections.  x
 x   x
 x Services to restart for GNU libc library upgrade: x
 x   x
 x vsftpd exim4 cron atd x
 x   x
 x  Ok x
 x   x
 mqqqj

 -

 As you can see, PuTTY was sent the traditional ISO-2022 box-drawing escape
 sequences to draw the box, which does not work when PuTTY is operating in
 UTF-8 mode.  These need to be converted into equivalent UTF-8 sequences to
 look right.  I wish to emphasize that libc6 is the *only* package which does
 this.

Seems logical, see below.

 If the bug is not in package libc6, then why is libc6 the *only* package
 which doesn't use the proper box-drawing technique?

Because your UTF-8 locale isn't available at the time the above screen
is shown.  It comes from the libc6 preinst, and libc6 declares a Breaks
on the old locales package (see #585737 for details).

Cheers,
   Sven


-- 
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/874myiny9d@turtle.gmx.de

Bug#536506: glibc-doc-reference: clutters up main info directory

[Sven Joachim]

On 2009-07-11 08:02 +0200, Sven Joachim wrote:

 tags 536506 + patch
 thanks

 On 2009-07-11 02:06 +0200, Aurelien Jarno wrote:

 tag 536506 + help
 thanks

 On Fri, Jul 10, 2009 at 05:56:01PM +0200, Sven Joachim wrote:
 Package: glibc-doc-reference
 Version: 2.9-1
 Severity: normal
 
 Your package puts an entry for every libc function and macro into the
 main info directory, using up more than 1700 lines.  This has been
 triggered by the transition to GNU's install-info; apparently the dpkg
 implementation ignored secondary INFO-DIR-SECTION entries.
 

 Could you have more details about what should be changed to fix that?

 There should not be a direntry for every function (upstream includes
 them on purpose, but this is a big abuse, that is what indices are
 for).  The following minimal patch avoids this:

--8---cut here---start-8---
 --- glibc-doc-reference-2.9.orig/manual/libc.texinfo
 +++ glibc-doc-reference-2.9/manual/libc.texinfo
 @@ -9,7 +9,6 @@
  @direntry
  * Libc: (libc). C library.
  @end direntry
 -@include dir-add.texi
  
  @c This tells texinfo.tex to use the real section titles in xrefs in
  @c place of the node name, when no section title is explicitly given.
--8---cut here---end---8---

Alas, this patch got lost in the 2.17-1 upload although it still
applies.  Perhaps a patch system would have avoided this problem?

Cheers,
   Sven


-- 
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/8761wib48m@turtle.gmx.de

Re: r5604 - glibc-package/trunk/debian

[Sven Joachim]

On 2013-05-18 01:03 +0200, Clint Adams wrote:

 Author: clint
 Date: 2013-05-17 23:03:21 + (Fri, 17 May 2013)
 New Revision: 5604

 Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/control
 Log:
 Add rpcinfo to libc-bin description.

Uhm, why that??  The rpcinfo program has been removed in version
2.16-0experimental0, since it is provided by rpcbind.

,
| $ dpkg -S rpcinfo
| rpcbind: /usr/sbin/rpcinfo
| rpcbind: /usr/share/man/man7/rpcinfo.7.gz
`

Cheers,
   Sven


-- 
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/87li786wnb@turtle.gmx.de

Bug#707919: libc-bin: useless message when triggered from dpkg

[Sven Joachim]

Package: libc-bin
Version: 2.17-1
Severity: minor

The echo ldconfig deferred processing now taking place message in the
libc-bin postinst is rather useless and should not be printed by
default, since dpkg already gives that information itself
(Processing triggers for libc-bin ...).

Please remove that message, or print it only if LDCONFIG_TRIGGER_DEBUG
is set in the environment.


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

Kernel: Linux 3.8.12-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc-bin depends on:
ii  libc62.17-1
ii  libcap2  1:2.22-1.2

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: http://lists.debian.org/87ehdcr80a@turtle.gmx.de

Bug#707185: libc6:amd64 does not replace libc6-amd64; preinst fails

[Sven Joachim]

On 2013-05-08 03:32 +0200, Ben Hutchings wrote:

 Package: src:eglibc
 Version: 2.17-1
 Severity: important

 This upgrade failed:
 [snip]
 Preparing to replace libc6-dev-amd64 2.13-38 (using 
 .../libc6-dev-amd64_2.17-1_i386.deb) ...
 Unpacking replacement libc6-dev-amd64 ...
 Preparing to replace libc6-amd64 2.13-38 (using 
 .../libc6-amd64_2.17-1_i386.deb) ...
 Unpacking replacement libc6-amd64 ...
 Replaced by files in installed package libc6:amd64 ...
 Preparing to replace linux-libc-dev:i386 3.2.39-2 (using 
 .../linux-libc-dev_3.8.11-1_i386.deb) ...
 De-configuring linux-libc-dev:amd64 ...
 Unpacking replacement linux-libc-dev:i386 ...
 Preparing to replace linux-libc-dev:amd64 3.2.39-2 (using 
 .../linux-libc-dev_3.8.11-1_amd64.deb) ...
 Unpacking replacement linux-libc-dev:amd64 ...
 Setting up linux-libc-dev:i386 (3.8.11-1) ...
 Setting up linux-libc-dev:amd64 (3.8.11-1) ...
 (Reading database ... 241766 files and directories currently installed.)
 Preparing to replace libc6-dev:amd64 2.13-38 (using 
 .../libc6-dev_2.17-1_amd64.deb) ...
 De-configuring libc6-dev:i386 ...
 Unpacking replacement libc6-dev:amd64 ...
 Preparing to replace libc6-dev:i386 2.13-38 (using 
 .../libc6-dev_2.17-1_i386.deb) ...
 Unpacking replacement libc6-dev:i386 ...
 Preparing to replace locales 2.13-38 (using .../locales_2.17-1_all.deb) ...
 Unpacking replacement locales ...
 Preparing to replace libc6:i386 2.13-38 (using 
 .../archives/libc6_2.17-1_i386.deb) ...
 De-configuring libc6:amd64 ...
 Checking for services that may need to be restarted...
 Checking init scripts...
 Unpacking replacement libc6:i386 ...
 Preparing to replace libc6:amd64 2.13-38 (using .../libc6_2.17-1_amd64.deb) 
 ...
 Checking for services that may need to be restarted...
 Checking init scripts...
 dpkg: error processing /var/cache/apt/archives/libc6_2.17-1_amd64.deb 
 (--unpack):
  subprocess new pre-installation script returned error exit status 1
 Processing triggers for man-db ...
 Processing triggers for lintian ...
 Errors were encountered while processing:
  /var/cache/apt/archives/libc6_2.17-1_amd64.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)

 It's not very nice of the preinst to fail without explanation, is it?
 So I repacked it with set +x added and the installation ended with:

 + echo Checking init scripts...
 Checking init scripts...
 + runlevel
 + sed s/.*\ //
 + rl=5
 + [ -n  ]
 + [ amd64 = armhf ]
 + touch /etc/ld.so.nohwcap
 + readlink -e /lib64/ld-linux-x86-64.so.2
 + ldfile=

 OK, where is /lib64/ld-linux-x86-64.so.2 pointing?  To ld-2.13.so,
 which does not exist.

It ought to point at /lib/x86_64-linux-gnu/ld-2.13.so, and that should
exist while the libc6:amd64 preinst runs.

 This is left over from libc6-amd64, which
 dpkg has mostly but not entirely removed in preparation for the
 upgrade that replaces it.

The new version of libc6-amd64 has already been unpacked, but
/lib64/ld-linux-x86-64.so.2 belongs to libc6:amd64 which declares a
Replaces: libc6-amd64.

 -- System Information:
 Debian Release: 7.0
   APT prefers unstable
   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
 Architecture: i386 (x86_64)
 Foreign Architectures: amd64

I'll see if I can reproduce the problem.

Cheers,
   Sven


-- 
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/87ppx12a7d@turtle.gmx.de

Bug#707185: libc6:amd64 does not replace libc6-amd64; preinst fails

[Sven Joachim]

Control: severity -1 serious

On 2013-05-08 09:37 +0200, Sven Joachim wrote:

 On 2013-05-08 03:32 +0200, Ben Hutchings wrote:
 OK, where is /lib64/ld-linux-x86-64.so.2 pointing?  To ld-2.13.so,
 which does not exist.

 It ought to point at /lib/x86_64-linux-gnu/ld-2.13.so,

It does so in the libc6:amd64 package, but installing libc6-amd64
2.13-38 does indeed change the target to ld-2.13.so…

 and that should exist while the libc6:amd64 preinst runs.

…which does no longer exist at that time. :-/

 This is left over from libc6-amd64, which
 dpkg has mostly but not entirely removed in preparation for the
 upgrade that replaces it.

 The new version of libc6-amd64 has already been unpacked, but
 /lib64/ld-linux-x86-64.so.2 belongs to libc6:amd64 which declares a
 Replaces: libc6-amd64.

Unfortunately that does not help much because it's ldconfig which
changes the symlink.

 -- System Information:
 Debian Release: 7.0
   APT prefers unstable
   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
 Architecture: i386 (x86_64)
 Foreign Architectures: amd64

If amd64 is the native architecture the problem becomes much worse since
you might not be able to run any programs.  Hence I'm bumping the
severity.

Cheers,
   Sven


--
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/87ehdh28v3@turtle.gmx.de

Bug#707185: libc6:amd64 does not replace libc6-amd64; preinst fails

[Sven Joachim]

On 2013-05-08 10:06 +0200, Sven Joachim wrote:

 Control: severity -1 serious

 On 2013-05-08 09:37 +0200, Sven Joachim wrote:

 On 2013-05-08 03:32 +0200, Ben Hutchings wrote:
 The new version of libc6-amd64 has already been unpacked, but
 /lib64/ld-linux-x86-64.so.2 belongs to libc6:amd64 which declares a
 Replaces: libc6-amd64.

 Unfortunately that does not help much because it's ldconfig which
 changes the symlink.

That has already been noticed before in #699206.  Additional note:
Uninstalling libc6-amd64 removes the /lib64/ld-linux-x86-64.so.2 symlink
completely. :-(

 -- System Information:
 Debian Release: 7.0
   APT prefers unstable
   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
 Architecture: i386 (x86_64)
 Foreign Architectures: amd64

 If amd64 is the native architecture the problem becomes much worse since
 you might not be able to run any programs.  Hence I'm bumping the
 severity.

I'll leave it to the maintainers if they want to merge this bug with
#699206 and what severity they deem appropriate.

Cheers,
   Sven


-- 
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/8761yt287d@turtle.gmx.de

Re: Bug#678511: zlib: FTBFS on s390x

[Sven Joachim]

reassign 678511 src:zlib 1:1.2.7.dfsg-3
thanks

On 2012-06-22 14:02 +0200, Mark Brown wrote:

 reassign 678511 libc6-dev
 kthxbye

 On Fri, Jun 22, 2012 at 12:12:25PM +0100, Jonathan McCrohan wrote:

 Your package FTBFS on s390x. s390x is now a release architecture [1], hence 
 the
 RC status.

 Please make *some* effort to read the buildd logs when reporting bugs
 like this.

 If you'd looked at the error (which it would have been good practice to
 include in your report) you'd have seen that all zlib is doing here is
 including limits.h which obviously should work but doesn't because s390x
 is trying to include an internal header which it didn't install.

The reason the header is not there is because libc6-dev-s390 (which
provides a symlink /usr/include/bits - s390x-linux-gnu/bits) is not
installed.  You need to build-depend on gcc-multilib to make that
happen.

Cheers,
   Sven


-- 
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/87obobwej4@turtle.gmx.de

Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable

[Sven Joachim]

On 2012-06-02 21:56 +0200, Aurelien Jarno wrote:

 On Sat, Jun 02, 2012 at 09:33:19PM +0200, Thibaut Girka wrote:
 On Sat, Jun 02, 2012 at 09:02:54PM +0200, Aurelien Jarno wrote:
  Your patch actually also makes libc0.1-dev, libc0.3-dev and libc6.1-dev
  m-a: same. You should also check for files in these packages.
 
 Oh, I didn't know about that.
 
 libc0.1-dev is ok.
 libc0.3-dev is ok since it's only available for one architecture.
 libc6.1-dev is ok too.
 

 Either we have to make them conflict one with another (that is
 libc0.1-dev and libc6-dev, libc0.3-dev with libc6-dev, etc.),

Note that this holds whether or not these packages are M-A: same.

 or we have to check for these packages as if they were a single one.

This means they would need to have the same name (probably libc-dev) on
all architectures.

Cheers,
   Sven



-- 
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/871ulw95oe@turtle.gmx.de

Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable

[Sven Joachim]

On 2012-06-03 10:39 +0200, Aurelien Jarno wrote:

 On Sun, Jun 03, 2012 at 10:10:41AM +0200, Sven Joachim wrote:
 On 2012-06-02 21:56 +0200, Aurelien Jarno wrote:
 
  Either we have to make them conflict one with another (that is
  libc0.1-dev and libc6-dev, libc0.3-dev with libc6-dev, etc.),
 
 Note that this holds whether or not these packages are M-A: same.

 No, because these packages are architecture specific, so they are not
 co-installable. For example libc0.1-dev and libc6-dev might have
 conflicting files, but you can't install libc0.1-dev (kfreebsd-amd64
 only) together with libc6-dev, unless they are marked M-A: same.

Marking them M-A: same is not going to resolve these conflicts,
because libc0.1-dev and libc6-dev still belong to different package
sets, and with --force-overwrite you can install libc0.1-dev along
libc6-dev already.

  or we have to check for these packages as if they were a single one.
 
 This means they would need to have the same name (probably libc-dev) on
 all architectures.
 

 Yes, thinking about that, either we want to make it fully multiarch, in
 that case all libc*-dev needs to be renamed to the same name, or we
 should add conflicts to prevent someone trying to install for example
 libc6.1-dev along with libc6-dev.

Renaming seems to be the best long-term solution to me, but using
conflicts is probably safer for wheezy.  For instance,
kfreebsd-kernel-headers:kfreebsd-i386 contains files clashing with both
libc6:i386 and linux-libc-dev:i386:

,
| # dpkg -i --force-overwrite 
/var/cache/apt/archives/kfreebsd-kernel-headers_0.81_kfreebsd-i386.deb 
| (Reading database ... 13017 files and directories currently installed.)
| Unpacking kfreebsd-kernel-headers (from 
.../kfreebsd-kernel-headers_0.81_kfreebsd-i386.deb) ...
| dpkg: warning: overriding problem because --force enabled:
|  trying to overwrite '/usr/include/net/if_arp.h', which is also in package 
libc6-dev 2.13-32
| dpkg: warning: overriding problem because --force enabled:
|  trying to overwrite '/usr/include/net/ppp_defs.h', which is also in package 
libc6-dev 2.13-32
| dpkg: warning: overriding problem because --force enabled:
|  trying to overwrite '/usr/include/net/route.h', which is also in package 
libc6-dev 2.13-32
| dpkg: warning: overriding problem because --force enabled:
|  trying to overwrite '/usr/include/netatalk/at.h', which is also in package 
libc6-dev 2.13-32
| dpkg: warning: overriding problem because --force enabled:
|  trying to overwrite '/usr/include/netipx/ipx.h', which is also in package 
libc6-dev 2.13-32
| dpkg: warning: overriding problem because --force enabled:
|  trying to overwrite '/usr/include/linux/videodev2.h', which is also in 
package linux-libc-dev:i386 3.2.19-1
| Setting up kfreebsd-kernel-headers (0.81) ...
`

Cheers,
   Sven



-- 
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/87pq9g7og2@turtle.gmx.de

Bug#669172: libc6: preinst fails in -28 and since then also in -27

[Sven Joachim]

found 669172 2.13-29
thanks

On 2012-04-18 00:38 +0200, Adam Conrad wrote:

 The reason this fails in -27 as well as -28 is because it has
 nothing to do with -28, it just got triggered for people by a
 new eglibc upload, period.

 The real bug here is that dpkg has decided that referring to
 multi-arch:same packages without the :arch suffix is bad, wrong
 and evil, and eglibc sprinkles dpkg -L LIBC and such all
 over its maintainer scripts without adding an :arch qualifier.

 I'll look at this tonight when I get off work and commit some
 fixes, unless someone beats me to it.

Alas, the fix that has been uploaded breaks with squeeze's dpkg which
knows about DPKG_MAINTSCRIPT_ARCH but not about the package:arch syntax,
so libc6 2.13-29 fails to unpack:

,
| # dpkg --version
| Debian `dpkg' package management program version 1.15.8.12 (i386).
| This is free software; see the GNU General Public License version 2 or
| later for copying conditions. There is NO warranty.
| # dpkg -l libc6:i386
| No packages found matching libc6:i386.
| # dpkg --unpack /var/cache/apt/archives/libc6_2.13-29_i386.deb 
| (Reading database ... 9738 files and directories currently installed.)
| Preparing to replace libc6 2.11.3-2 (using .../libc6_2.13-29_i386.deb) ...
| Checking for services that may need to be restarted...
| Checking init scripts...
| dpkg: error processing /var/cache/apt/archives/libc6_2.13-29_i386.deb 
(--unpack):
|  subprocess new pre-installation script returned error exit status 1
| Errors were encountered while processing:
|  /var/cache/apt/archives/libc6_2.13-29_i386.deb
`

Cheers,
   Sven



-- 
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/87wr5d5nfy@turtle.gmx.de

Bug#640872: Info received (Bug#640872: Acknowledgement (libc6: upgrade fails to mv /lib64.eglibc-new to /lib64; leaves system unusable))

[Sven Joachim]

On 2011-09-08 08:35 +0200, Austin Clements wrote:

 I probably don't understand all of the nuances of that code, but one
 potential fix is simply to pass a benign argument to mv.  Something like
 if ! $ldfile /bin/mv --version /dev/null 2/dev/null; then
 ...
 Alternatively, it may be more robust for the script to simply create a
 file to mv (for example, if it's possible to have a /bin/mv that
 doesn't accept --version).

That is possible, for instance if you divert it and replace it with a
symlink to busybox.  The original code in 2.13-17 checked /bin/true
instead of /bin/mv, and somebody who replaced /bin/true with a
statically linked binary complained (#640753).

Sven



-- 
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/87k49jfpnb@turtle.gmx.de

Bug#632682: kfreebsd-amd64 and /lib64 - lib symlink

[Sven Joachim]

On 2011-08-19 09:46 +0200, Petr Salinger wrote:

 I looked at just commited r4891, and it seems that it breaks
 kfreebsd-amd64 seriously.

 On kfreebsd-amd64, the ELF interpreter is
 /lib/ld-kfreebsd-x86-64.so.1, i.e. it is really in /lib, not in
 /lib64.

 The lib64 - lib symlinks in previous eglibc versions only have been
 as defence against broken packages shipping their libs in lib64.

 This part of libc.preinst seems to delete our ELF interpreter:
 remove_lib64_symlink() {
 ...
 rm -f /lib/$(basename RTLD_SO)
 }

 On kfreebsd-amd64 the lib64 - lib symlinks are optional,
 but /lib/ld-kfreebsd-x86-64.so.1 is not ;-)

Right.  I deliberately omitted kfreebsd-amd64 from the list of
architectures where this code is run, but vorlon silently added it.

Cheers,
   Sven



-- 
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/87y5ypyg40@turtle.gmx.de

Bug#632682: libc6 should have Breaks against lsb-core

[Sven Joachim]

On 2011-08-13 21:25 +0200, Sven Joachim wrote:

 - The lsb-core package installs symlinks /lib64/ld-lsb-x86-64.so.[23] to
   /lib/ld-linux-x86-64.so.2 that get broken.  Nothing dramatic and
   solvable in a few ways.

Since it has been decided that /lib/ld-linux-x86-64.so.2 goes away, the
lsb-core needs to adjust its postinst and correct the links.  I have
filed a bug (#638450) on lsb-core for that.

As for eglibc, the next upload should add a
Breaks: lsb-core (= 3.2-27) to reflect this, I think.

Cheers,
   Sven



-- 
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/87hb5dwq43.fsf...@turtle.gmx.de

Bug#632682: we should probably remove /lib64 - lib symlink (with care)

[Sven Joachim]

On 2011-08-18 01:05 +0200, Steve Langasek wrote:

 The biggest change compared to the previous one is the new patch 6 which
 tries to check that there is at least one free inode.  Namely, if there
 aren't any, the sequence

 rm -f /lib64
 $interpreter /bin/mkdir /lib64
 $interpreter /bin/ln -s $ldfile RTLD_SO

 will fail in the third command which is rather embarrassing.  This is of
 course far from perfect, if another process runs riot and creates files
 rapidly, you can still lose.  Also, that part isn't really tested at all
 (except that it works when there are no ENOSPC problems).

 Nack on this.  The right way to handle it is to create the directory under a
 separate name, populate the symlink, and only *then* rm /lib64 and invoke mv
 /lib64.real /lib64 via $interpreter.  This minimizes the window when /lib64
 is missing, and just happens to also remove the inode problem as a side
 effect (because we create all the directory entries we need before we remove
 any).

Yes, that's better.  Instead of hardcoding /lib64.real the directory
should be created with mktemp -d (I think that's what you meant to do).

 Subject: [PATCH 2/6] Install the dynamic linker into RTLDDIR as well as /lib

 Installing into both locations makes it easier to support downgrades.
 It also means that dpkg will fail to unpack our package if
 RTLDDIR=/lib64 and /lib64 is a symlink to /lib.  Which is probably a
 good thing since that symlink has to go away.

 I'm not keen on this.  Why would we want to install a second copy of
 ld-linux-x86-64.so.2 to /lib?  Nothing will use it there.  Shouldn't we be
 installing *only* to RTLDDIR, not to both?

I don't have a strong opinion on this.  Make sure to copy
ld-linux-x86-64.so.2 to /lib in the prerm on downgrades then; if the
downgrade fails during unpack, /lib/ld-linux-x86-64.so.2 is unowned.

 And no, this won't cause dpkg to fail to unpack.  dpkg happily traverses
 symlinks while unpacking and would never notice that the two files are being
 installed to the same location.

It does if the files are contained in the same package, an example can
be found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624724#10.

 Otherwise, this looks good.  I'll merge these up (with the above-mentioned
 changes) and put it through its paces here.

Thanks for stepping in.

Cheers,
   Sven



-- 
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/877h6bcifv@turtle.gmx.de

Bug#632682: we should probably remove /lib64 - lib symlink (with care)

[Sven Joachim]

On 2011-08-18 18:20 +0200, Steve Langasek wrote:

 On Thu, Aug 18, 2011 at 09:00:52AM +0200, Sven Joachim wrote:
  The right way to handle it is to create the directory under a separate
  name, populate the symlink, and only *then* rm /lib64 and invoke mv
  /lib64.real /lib64 via $interpreter.  This minimizes the window when /lib64
  is missing, and just happens to also remove the inode problem as a side
  effect (because we create all the directory entries we need before we 
  remove
  any).

 Yes, that's better.  Instead of hardcoding /lib64.real the directory
 should be created with mktemp -d (I think that's what you meant to do).

 Hmm, no, I didn't see a need for mktemp here.  You're concerned about a
 collision with an admin-created directory?  That seems improbable to me, but
 certainly using mkdir doesn't hurt.

That was my thought, exactly.

  And no, this won't cause dpkg to fail to unpack.  dpkg happily traverses
  symlinks while unpacking and would never notice that the two files are 
  being
  installed to the same location.

 It does if the files are contained in the same package, an example can
 be found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624724#10.

 I don't think that's an accurate interpretation of what's happening in that
 bug, but would need to see the filesystem to say what is happening.

You can reproduce it yourself in an i386 chroot.  Make sure you have no
/usr/lib64 directory, then ln -s lib /usr/lib64; apt-get install fakeroot.

 But as the error is no such file or directory, it probably means
 it's managed to get itself into a situation of trying to unpack a file
 for which the parent directory doesn't exist.

Not at all.  Here is what happens if you install a package that ships
both foo/x and bar/x while bar is a symlink to foo on the filesystem:
dpkg unpacks to files with temporary names, foo/x.dpkg-new and
bar/x.dpkg-new, still not noticing the file conflict and overwriting the
files with each other.  It then renames foo/x.dpkg-new to foo/x and
bar/x.dpkg-new to bar/x -- with the last step ENOENT failing, because it
had already renamed the file to foo/x.

Run strace -erename dpkg -i …/fakeroot*.deb in the above situation to
see for yourself.

Cheers,
   Sven



-- 
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/8762lur305@turtle.gmx.de

Bug#632682: base-files: please provide a /lib64 - /lib symlink on 64-bit systems

[Sven Joachim]

On 2011-08-13 23:17 +0200, Sven Joachim wrote:

 On 2011-08-13 22:14 +0200, Jonathan Nieder wrote:

 Sven Joachim wrote:

 - link_name=debian/tmp-$(curpass)/lib/$$rtld_so ; \
 + link_name=debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so ; \
   target=$(call xx,slibdir)/$$(readlink 
 debian/tmp-$(curpass)/$(call xx,slibdir)/$$rtld_so) ; \
 + mkdir -p debian/tmp-$(curpass)/$(call xx,rtlddir); \
   ln -s $$target $$link_name ;  \

I have completely dropped this part.  Installing into
debian/tmp-$(curpass)/lib is fine at this stage, no matter what the
final destination is.

 Do I understand correctly that this is this a no-op (to prepare for
 patch 5)?

 Ouch.  It should not have been; I made a mistake while rebasing the
 patches, because the target dir in libc.install needs to be set to
 RTLDDIR, not to /lib.

So I install into both RTLDDIR and /lib, as in the old patch 5.

 [...]
 @@ -384,6 +404,13 @@ fi
  #DEBHELPER#
  
  if [ -n $preversion ]; then
 +if test -L /lib64; then
 +   case ${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)} in
 +   amd64 | ppc64 | sparc64 | s390x)
 +   remove_lib64_symlink ;;
 +   esac
 +fi

 If DPKG_MAINTSCRIPT_ARCH isn't set for some reason, this gives the
 wrong value.  Would it be possible to introduce a variable in
 debian/rules.d/debhelper.mk so the right value can be cooked in at
 build time?

 Probably, but I guess it does not matter in practice.
 DPKG_MAINTSCRIPT_ARCH is exported by dpkg since 1.15.4, and old dpkg
 versions don't support multiarch so you have to do something totally
 weird to install a foreign libc6.

I don't feel the need to do anything about it and leave it to Aurelien
if he thinks this is necessary.

 Maybe it would be possible to mv /lib64 somewhere and loudly let the
 admin know about it if it contains anything more than the dynamic
 linker.

 Good idea.  Something like that:

   aside=$(mktemp -d /lib64-moved-by-libc6-prerm.XX)
   echo Moving /lib64 aside to $aside
   mv /lib64 $aside

See patches 5 and 6 in the new attached series.

 I have some private undertakings tomorrow, will likely send a new patch
 series on Monday, unless somebody beats me to it.

The biggest change compared to the previous one is the new patch 6 which
tries to check that there is at least one free inode.  Namely, if there
aren't any, the sequence

rm -f /lib64
$interpreter /bin/mkdir /lib64
$interpreter /bin/ln -s $ldfile RTLD_SO

will fail in the third command which is rather embarrassing.  This is of
course far from perfect, if another process runs riot and creates files
rapidly, you can still lose.  Also, that part isn't really tested at all
(except that it works when there are no ENOSPC problems).

I have lightly tested unpack failures by introducing a file conflict
with another package, they do at least not lead to immediate disaster.
The only problem that I see is that if unpacking fails during upgrade
and you then downgrade to an older _major_ eglibc version,
/lib64/ld-linux-x86-64.so.2 becomes a dangling symlink.  I don't think
there is much which can be done about this.

Cheers,
   Sven


From 6ead53c51dac3ef8aa77b96b8c8f1a647f654a6d Mon Sep 17 00:00:00 2001
From: Sven Joachim svenj...@gmx.de
Date: Thu, 11 Aug 2011 17:15:03 +0200
Subject: [PATCH 1/6] Don't create /lib64 and /usr/lib64 symlinks

---
 debian/sysdeps/amd64.mk  |3 ---
 debian/sysdeps/kfreebsd-amd64.mk |6 --
 debian/sysdeps/ppc64.mk  |6 --
 debian/sysdeps/s390x.mk  |6 --
 debian/sysdeps/sparc64.mk|6 --
 5 files changed, 0 insertions(+), 27 deletions(-)

diff --git a/debian/sysdeps/amd64.mk b/debian/sysdeps/amd64.mk
index c99dea4..67000a5 100644
--- a/debian/sysdeps/amd64.mk
+++ b/debian/sysdeps/amd64.mk
@@ -1,10 +1,7 @@
 libc_rtlddir = /lib64
 extra_config_options = --enable-multi-arch
 
-# /lib64 and /usr/lib64 are provided by glibc instead base-files: #259302.
 define libc6_extra_pkg_install
-ln -sf /lib debian/$(curpass)/lib64
-ln -sf lib debian/$(curpass)/usr/lib64
 
 make -C debian/local/memcpy-wrapper
 install -m 755 -o root -g root -d debian/libc6/$(libdir)/libc
diff --git a/debian/sysdeps/kfreebsd-amd64.mk b/debian/sysdeps/kfreebsd-amd64.mk
index 261cbda..635b72d 100644
--- a/debian/sysdeps/kfreebsd-amd64.mk
+++ b/debian/sysdeps/kfreebsd-amd64.mk
@@ -1,12 +1,6 @@
 # Main library
 extra_config_options = --disable-compatible-utmp --disable-multi-arch
 
-# /lib64 and /usr/lib64 are provided by glibc instead base-files: #259302.
-define libc0.1_extra_pkg_install
-ln -sf /lib debian/$(curpass)/lib64
-ln -sf lib debian/$(curpass)/usr/lib64
-endef
-
 # build 32-bit (i386) alternative library
 EGLIBC_PASSES += i386
 DEB_ARCH_REGULAR_PACKAGES += libc0.1-i386 libc0.1-dev-i386
diff --git a/debian/sysdeps/ppc64.mk b/debian/sysdeps/ppc64.mk
index 98cea4b..c8d2509 100644
--- a/debian/sysdeps/ppc64.mk
+++ b/debian/sysdeps/ppc64.mk
@@ -1,12 +1,6

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

[Sven Joachim]

On 2011-08-13 13:58 +0200, Aurelien Jarno wrote:

   * Add patches/localedata/cvs-rupee.diff fro upstream to add support for
 Rupee symbol (U20B9).

This patch does not apply cleanly here, I got a reject in the following
hunk:

 +diff --git a/localedata/ChangeLog b/localedata/ChangeLog
 +index f45fb43..52bd694 100644
 +--- a/localedata/ChangeLog
  b/localedata/ChangeLog
 +@@ -1,5 +1,6 @@
 + 2011-05-09  Ulrich Drepper  drep...@gmail.com
 + 
 ++[BZ #12711]
 + * charmaps/UTF-8: Update from reason Unidata.txt file.
 + 
 + [BZ #12738]

Cheers,
   Sven


-- 
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/87wrehtidp@turtle.gmx.de

Bug#632682: base-files: please provide a /lib64 - /lib symlink on 64-bit systems

[Sven Joachim]

On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:

 On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote:
 
 I'll have a look at it in the next few days if nobody beats me to it.
 Just to confirm that my ideas were the same as yours, AFAICS the
 following needs to be done in the preinst (on amd64), if /lib64 is a
 symlink:
 
 1) remove /lib64
 2) create /lib64 directory
 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to 
 /lib64/ld-linux-x86-64.so.2
 
 2) and 3) are a bit difficult after the path to the ELF interpreter has
 just disappeared.  I guess you still want to stick to shell nonetheless
 (as opposed to doing these steps in perl, say) ?
 

 This is basically what we have in mind, though it has not been tested.
 For step 2 and 3, you can call the ELF interpreter directly, that is 
 /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64.

Almost right, you have use /bin/mkdir though since the interpreter knows
nothing about PATH:

,
| # /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64
| mkdir: error while loading shared libraries: mkdir: cannot open shared object 
file
`

 The whole operation is still not atomic, but so far it's the best way to
 do it. We might want to insert a call to sync as steps 0 and 4, to
 minimize the possible time with ELF interpreter, and to make sure the
 data is written to the disk as soon as possible (otherwise if the
 machine crashes, the system can't boot).

After getting the necessary minimal grasp of the packaging system, I
have come up with a first shot towards a solution, see the attached
patch set.

Upgrade from and downgrade to 2.13-16 has been tested in a minimal amd64
sid chroot.  Also, I have tested upgrades from and downgrades to 2.13-10
in an i386/amd64 chroot with a multiarch-capable dpkg and i386 as
primary architecture.  I haven't yet checked or analyzed the
consequences of unpacking failures during upgrade or downgrade.

Known problems:

- Multiarch systems with multiple libc6 versions shipping the /lib64
  symlink will be hosed if the native libc6 is not unpacked first.
  Since this involves at least one unofficial architecture and an 
  unofficial dpkg, it is probably ignorable.

- Installing packages that ship files under /lib64 and then downgrading
  to a libc6 that ships the symlink breaks those packages.  Should maybe
  give a warning on downgrades if any files beside the ELF interpreter
  are found in /lib64.

- The lsb-core package installs symlinks /lib64/ld-lsb-x86-64.so.[23] to
  /lib/ld-linux-x86-64.so.2 that get broken.  Nothing dramatic and
  solvable in a few ways.

Cheers,
   Sven

-- 
I still say /lib64 is one of the nastiest pieces of shit I've ever
heard of.
-- Branden Robinson


From 6ead53c51dac3ef8aa77b96b8c8f1a647f654a6d Mon Sep 17 00:00:00 2001
From: Sven Joachim svenj...@gmx.de
Date: Thu, 11 Aug 2011 17:15:03 +0200
Subject: [PATCH 1/6] Don't create /lib64 and /usr/lib64 symlinks

---
 debian/sysdeps/amd64.mk  |3 ---
 debian/sysdeps/kfreebsd-amd64.mk |6 --
 debian/sysdeps/ppc64.mk  |6 --
 debian/sysdeps/s390x.mk  |6 --
 debian/sysdeps/sparc64.mk|6 --
 5 files changed, 0 insertions(+), 27 deletions(-)

diff --git a/debian/sysdeps/amd64.mk b/debian/sysdeps/amd64.mk
index c99dea4..67000a5 100644
--- a/debian/sysdeps/amd64.mk
+++ b/debian/sysdeps/amd64.mk
@@ -1,10 +1,7 @@
 libc_rtlddir = /lib64
 extra_config_options = --enable-multi-arch
 
-# /lib64 and /usr/lib64 are provided by glibc instead base-files: #259302.
 define libc6_extra_pkg_install
-ln -sf /lib debian/$(curpass)/lib64
-ln -sf lib debian/$(curpass)/usr/lib64
 
 make -C debian/local/memcpy-wrapper
 install -m 755 -o root -g root -d debian/libc6/$(libdir)/libc
diff --git a/debian/sysdeps/kfreebsd-amd64.mk b/debian/sysdeps/kfreebsd-amd64.mk
index 261cbda..635b72d 100644
--- a/debian/sysdeps/kfreebsd-amd64.mk
+++ b/debian/sysdeps/kfreebsd-amd64.mk
@@ -1,12 +1,6 @@
 # Main library
 extra_config_options = --disable-compatible-utmp --disable-multi-arch
 
-# /lib64 and /usr/lib64 are provided by glibc instead base-files: #259302.
-define libc0.1_extra_pkg_install
-ln -sf /lib debian/$(curpass)/lib64
-ln -sf lib debian/$(curpass)/usr/lib64
-endef
-
 # build 32-bit (i386) alternative library
 EGLIBC_PASSES += i386
 DEB_ARCH_REGULAR_PACKAGES += libc0.1-i386 libc0.1-dev-i386
diff --git a/debian/sysdeps/ppc64.mk b/debian/sysdeps/ppc64.mk
index 98cea4b..c8d2509 100644
--- a/debian/sysdeps/ppc64.mk
+++ b/debian/sysdeps/ppc64.mk
@@ -1,12 +1,6 @@
 libc_rtlddir = /lib64
 extra_config_options = --enable-multi-arch
 
-# /lib64 and /usr/lib64 are provided as symlinks 
-define libc6_extra_pkg_install
-ln -sf /lib debian/$(curpass)/lib64
-ln -sf lib debian/$(curpass)/usr/lib64
-endef
-
 # build 32-bit (powerpc) alternative library
 EGLIBC_PASSES += powerpc
 DEB_ARCH_REGULAR_PACKAGES += libc6-powerpc libc6-dev-powerpc
diff --git a/debian/sysdeps/s390x.mk b/debian/sysdeps/s390x.mk
index acb5c41

Bug#632682: base-files: please provide a /lib64 - /lib symlink on 64-bit systems

[Sven Joachim]

Thanks for the review, Jonathan.

On 2011-08-13 22:14 +0200, Jonathan Nieder wrote:

 Sven Joachim wrote:

 - link_name=debian/tmp-$(curpass)/lib/$$rtld_so ; \
 + link_name=debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so ; \
   target=$(call xx,slibdir)/$$(readlink 
 debian/tmp-$(curpass)/$(call xx,slibdir)/$$rtld_so) ; \
 + mkdir -p debian/tmp-$(curpass)/$(call xx,rtlddir); \
   ln -s $$target $$link_name ;  \

 Do I understand correctly that this is this a no-op (to prepare for
 patch 5)?

Ouch.  It should not have been; I made a mistake while rebasing the
patches, because the target dir in libc.install needs to be set to
RTLDDIR, not to /lib.

 [...]
 @@ -384,6 +404,13 @@ fi
  #DEBHELPER#
  
  if [ -n $preversion ]; then
 +if test -L /lib64; then
 +case ${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)} in
 +amd64 | ppc64 | sparc64 | s390x)
 +remove_lib64_symlink ;;
 +esac
 +fi

 If DPKG_MAINTSCRIPT_ARCH isn't set for some reason, this gives the
 wrong value.  Would it be possible to introduce a variable in
 debian/rules.d/debhelper.mk so the right value can be cooked in at
 build time?

Probably, but I guess it does not matter in practice.
DPKG_MAINTSCRIPT_ARCH is exported by dpkg since 1.15.4, and old dpkg
versions don't support multiarch so you have to do something totally
weird to install a foreign libc6.

 It would be more prudent to prevent the downgrade from happening, but
 if we fail the prerm script, the one from the previous version kicks
 in and succeeds.

 Fixed by dpkg commit 9d3ec0f5 (“dpkg: do not fallback to new-prerm
 failed-upgrade for downgrades”).  Probably that's too new to count
 on.

Ah, I wasn't aware of that.  Still, adding a Pre-Depends on dpkg 1.16.1
on the affected arches is probably not a good idea.

 +#Downgrading from a version with a /lib64 directory to a version with
 +# a /lib64 symlink is extremely dangerous.  We need to blow away the
 +# directory and restore the symlink, otherwise the dynamic linker gets
 +# lost after unpacking the replacing version.
 +
 +ldfile=$(readlink -e RTLD_SO)
 +# Test if libc is of the same architecture as coreutils
 +# If not, they almost surely have a multiarch system and we can use
 +# the native ELF interpreter
 +if ! $ldfile /bin/true 2/dev/null; then
 +interpreter=
 +else
 +interpreter=$ldfile
 +fi
 +
 +# sync before and after the operation to reduce the danger of hosing
 +# the system
 +sync
 +rm -rf /lib64
 +$interpreter /bin/ln -s /lib /lib64

 Maybe it would be possible to mv /lib64 somewhere and loudly let the
 admin know about it if it contains anything more than the dynamic
 linker.

Good idea.  Something like that:

  aside=$(mktemp -d /lib64-moved-by-libc6-prerm.XX)
  echo Moving /lib64 aside to $aside
  mv /lib64 $aside


I have some private undertakings tomorrow, will likely send a new patch
series on Monday, unless somebody beats me to it.

Cheers,
   Sven

-- 
I still say /lib64 is one of the nastiest pieces of shit I've ever
heard of.
-- Branden Robinson




-- 
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/874o1lroz5@turtle.gmx.de

Bug#632682: base-files: please provide a /lib64 - /lib symlink on 64-bit systems

[Sven Joachim]

On 2011-07-25 14:50 +0200, Santiago Vila wrote:

 reassign 632682 libc6
 retitle 632682 we should probably remove /lib64 - lib symlink (with care)
 thanks

 Hi. After discussing about this today, it seems what we really need
 for multiarch to work is to remove those symlinks, hence this reassign.

Has anyone started working on this yet?

Cheers,
   Sven



-- 
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/87sjp989ym@turtle.gmx.de

Bug#632682: base-files: please provide a /lib64 - /lib symlink on 64-bit systems

[Sven Joachim]

On 2011-08-10 19:48 +0200, Aurelien Jarno wrote:

 On Wed, Aug 10, 2011 at 07:14:57PM +0200, Sven Joachim wrote:
 On 2011-07-25 14:50 +0200, Santiago Vila wrote:
 
  reassign 632682 libc6
  retitle 632682 we should probably remove /lib64 - lib symlink (with care)
  thanks
 
  Hi. After discussing about this today, it seems what we really need
  for multiarch to work is to remove those symlinks, hence this reassign.
 
 Has anyone started working on this yet?
 

 We got some ideas, but AFAIK nobody has started to work on that.

I'll have a look at it in the next few days if nobody beats me to it.
Just to confirm that my ideas were the same as yours, AFAICS the
following needs to be done in the preinst (on amd64), if /lib64 is a
symlink:

1) remove /lib64
2) create /lib64 directory
3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to 
/lib64/ld-linux-x86-64.so.2

2) and 3) are a bit difficult after the path to the ELF interpreter has
just disappeared.  I guess you still want to stick to shell nonetheless
(as opposed to doing these steps in perl, say) ?

Cheers,
   Sven



-- 
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/87hb5p8684@turtle.gmx.de

Bug#632682: base-files: please provide a /lib64 - /lib symlink on 64-bit systems

[Sven Joachim]

On 2011-08-10 20:47 +0200, Jonathan Nieder wrote:

 Sven Joachim wrote:

 1) remove /lib64
 2) create /lib64 directory
 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to 
 /lib64/ld-linux-x86-64.so.2

 2) and 3) are a bit difficult after the path to the ELF interpreter has
 just disappeared.  I guess you still want to stick to shell nonetheless
 (as opposed to doing these steps in perl, say) ?

 I wonder if the following would make sense:

  1) mkdir /lib64.real
  2) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to
 /lib64.real/ld-linux-x64-64.so.2
  ^

Should be -x86-, but otherwise this makes some sense to me.  But with
the following you've lost me:

  3) ln -s lib64.real /lib64.eglibc-tmp
  4) mv -f /lib64.eglibc-tmp /lib64

Now you have a broken lib/lib64.eglibc.tmp symlink which is not quite
what you want. ;-)  It would make more sense to use /lib64.eglibc-tmp/
as source, but this seems to fail with ENOTDIR.

  5) clean up on next reboot

Not sure what you mean with that.  Could you elaborate?

Cheers,
   Sven



-- 
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/874o1p83an@turtle.gmx.de

Bug#632682: base-files: please provide a /lib64 - /lib symlink on 64-bit systems

[Sven Joachim]

On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:

 On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote:
 
 I'll have a look at it in the next few days if nobody beats me to it.
 Just to confirm that my ideas were the same as yours, AFAICS the
 following needs to be done in the preinst (on amd64), if /lib64 is a
 symlink:
 
 1) remove /lib64
 2) create /lib64 directory
 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to 
 /lib64/ld-linux-x86-64.so.2
 
 2) and 3) are a bit difficult after the path to the ELF interpreter has
 just disappeared.  I guess you still want to stick to shell nonetheless
 (as opposed to doing these steps in perl, say) ?
 

 This is basically what we have in mind, though it has not been tested.
 For step 2 and 3, you can call the ELF interpreter directly, that is 
 /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64.

Except for the case where you install the libc on a foreign
architecture.  Then this might not work.

 The whole operation is still not atomic, but so far it's the best way to
 do it. We might want to insert a call to sync as steps 0 and 4, to
 minimize the possible time with ELF interpreter, and to make sure the
 data is written to the disk as soon as possible (otherwise if the
 machine crashes, the system can't boot).

Good idea.

Cheers,
   Sven



-- 
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/87pqkd6m90@turtle.gmx.de

Bug#632682: base-files: please provide a /lib64 - /lib symlink on 64-bit systems

[Sven Joachim]

On 2011-08-10 22:44 +0200, Aurelien Jarno wrote:

 On Wed, Aug 10, 2011 at 10:32:27PM +0200, Sven Joachim wrote:
 On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:
 
  This is basically what we have in mind, though it has not been tested.
  For step 2 and 3, you can call the ELF interpreter directly, that is 
  /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64.
 
 Except for the case where you install the libc on a foreign
 architecture.  Then this might not work.
 

 The goal is to do that only in the preinst of libc0.1/6 (we can't do
 that in the postinst as it would means the files on the filesystem and
 in dpkg are not consistent), and only if /lib64 is a symlink. Given we
 have removed the Multiarch: same tag in the libc6 packages of 
 architectures having a /lib64 symlink,

You have removed them, but people still might have older libc versions
installed that are Multiarch:same.  Like myself in my multiarch
adventure chroot were libc6 is stalled at 2.13-10.

 these systems can't have a foreign coreutils as it would depends on a
 foreign libc which is not installable.

Even if libc6 is no longer Multiarch:same, that does not prevent
installing libc6:amd64 and libc0.1:kfreebsd-amd64 simultaneously,
AFAICS.  Now when upgrading you have a 50% chance that the native libc
is unpacked first.

 That's only valid if we ignore the 2 or 3 versions that have been in sid
 with this Multiarch: same tag.

Ubuntu has many more versions, and a dpkg that actually supports
multiarch.  But for them this may not be such a big problem since only
amd64 and i386 are supported, and people who have enabled multiarch
almost surely run a 64-bit kernel.

Cheers,
   Sven



-- 
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/87aabh6kk7@turtle.gmx.de

Bug#636115: libc6-dev-amd64: does not install, removes files from libc6-dev

[Sven Joachim]

Package: libc6-dev-amd64
Version: 2.13-13
Severity: grave

There was a problem installing your package:

,
| Preparing to replace libc6-dev-amd64 2.13-11 (using 
.../libc6-dev-amd64_2.13-13_i386.deb) ...
| Unpacking replacement libc6-dev-amd64 ...
| dpkg: error processing 
/var/cache/apt/archives/libc6-dev-amd64_2.13-13_i386.deb (--unpack):
|  trying to overwrite '/usr/include/bits', which is also in package libc6-dev 
2.13-13
`

Looks like some files in libc6-dev were moved back to
/usr/include/{bits,gnu}/, and the libc6-dev-amd64 preinst does rm -rf
these directories, resulting in lots of missing files:

,
| $ debsums -c libc6-dev 21 | grep -c missing file
| 107
`


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.0.0-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6-dev-amd64 depends on:
ii  libc6-amd64   2.13-13Embedded GNU C Library: 64bit Shar
ii  libc6-dev 2.13-13Embedded GNU C Library: Developmen

Versions of packages libc6-dev-amd64 recommends:
ii  gcc-multilib  4:4.6.1-2  GNU C compiler (multilib files)

libc6-dev-amd64 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: http://lists.debian.org/878vrelrbl@turtle.gmx.de

Bug#635685: general: gcc -m32 has no access to system-specific includes in multiarch world

[Sven Joachim]

On 2011-07-28 23:53 +0200, Steve Langasek wrote:

 On Thu, Jul 28, 2011 at 11:39:50AM +0200, Sven Joachim wrote:
 On 2011-07-28 10:58 +0200, Tim Northover wrote:

  Package: general
  Severity: normal
 
  It looks like gcc -m32 has been partially broken by the recent
  hiving off of various headers to /usr/include/x86_64-linux-gnu.
 
  In particular a program consisting of the single line #include
  features.h fails with the error:
 
  In file included from tmp.c:1:0:
  /usr/include/features.h:356:25: fatal error: sys/cdefs.h: No such file
  or directory
  compilation terminated.
 
  I suspect multiple packages are involved: cpp -m32 -v reports not
  searching /usr/include/i386-linux-gnu (or equivalent) so gcc packages
  are probably iffy; but even if it did there's nothing there to find so
  either the gcc-*-multilib or libc6-dev (or possibly even an entirely
  new gcc-*-multiheader one) will need updating.

 Confirmed here on i386, ncurses biarch build is broken:

 This is not confirming the bug, the behavior you quote below is entirely
 the opposite of what the submitter was reporting.

Sorry for not reading carefully enough.  But I can also reproduce Tim's
problem in an amd64 chroot with apt-get -b source bzip2:

,
| gcc -m32 -Wall -Winline -O2 -g -D_FILE_OFFSET_BITS=64  -D_REENTRANT -o 
blocksort.o -c blocksort.c
| In file included from /usr/include/stdlib.h:25:0,
|  from bzlib_private.h:25,
|  from blocksort.c:22:
| /usr/include/features.h:356:25: fatal error: sys/cdefs.h: No such file or 
directory
`

 Tim, what version of libc6-dev-i386 do you have installed?  I cannot
 reproduce this problem with 2.13-11.

I have installed libc6-dev-i386 2.13-11 here as well.

 ,
 | $ LANG=C debian/rules build-64
 | [...]
 | make[2]: Entering directory 
 `/usr/local/src/deb-src/ncurses/ncurses/obj-64/ncurses'
 | gcc -o make_hash -DHAVE_CONFIG_H -I../ncurses
 | -I/usr/local/src/deb-src/ncurses/ncurses/ncurses
 | -I/usr/local/src/deb-src/ncurses/ncurses/ncurses/../include
 | -I../include -DUSE_BUILD_CC
 | /usr/local/src/deb-src/ncurses/ncurses/ncurses/tinfo/make_hash.c
 | In file included from /usr/include/stdlib.h:320:0,
 |  from 
 /usr/local/src/deb-src/ncurses/ncurses/ncurses/build.priv.h:61,
 |  from 
 /usr/local/src/deb-src/ncurses/ncurses/ncurses/tinfo/make_hash.c:40:
 | /usr/include/i386-linux-gnu/sys/types.h:99:17: error: two or more data 
 types in declaration specifiers
 | make[2]: *** [make_hash] Error 1
 | make[2]: Leaving directory 
 `/usr/local/src/deb-src/ncurses/ncurses/obj-64/ncurses'
 | make[1]: *** [all] Error 2
 | make[1]: Leaving directory `/usr/local/src/deb-src/ncurses/ncurses/obj-64'
 | make: *** [build-64] Error 2
 `

 It seems libc6-dev multiarch support needs to go back to the drawing
 board again.

 Sven, please file a separate bug report for this issue.

Will do so soon.

Cheers,
   Sven



-- 
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/8762mljz6t@turtle.gmx.de

Bug#635685: general: gcc -m32 has no access to system-specific includes in multiarch world

[Sven Joachim]

On 2011-07-29 09:58 +0200, Sven Joachim wrote:

On 2011-07-29 09:58 +0200, Sven Joachim wrote:

 On 2011-07-28 23:53 +0200, Steve Langasek wrote:

 On Thu, Jul 28, 2011 at 11:39:50AM +0200, Sven Joachim wrote:
 ,
 | $ LANG=C debian/rules build-64
 | [...]
 | make[2]: Entering directory 
 `/usr/local/src/deb-src/ncurses/ncurses/obj-64/ncurses'
 | gcc -o make_hash -DHAVE_CONFIG_H -I../ncurses
 | -I/usr/local/src/deb-src/ncurses/ncurses/ncurses
 | -I/usr/local/src/deb-src/ncurses/ncurses/ncurses/../include
 | -I../include -DUSE_BUILD_CC
 | /usr/local/src/deb-src/ncurses/ncurses/ncurses/tinfo/make_hash.c
 | In file included from /usr/include/stdlib.h:320:0,
 |  from 
 /usr/local/src/deb-src/ncurses/ncurses/ncurses/build.priv.h:61,
 |  from 
 /usr/local/src/deb-src/ncurses/ncurses/ncurses/tinfo/make_hash.c:40:
 | /usr/include/i386-linux-gnu/sys/types.h:99:17: error: two or more data 
 types in declaration specifiers
 | make[2]: *** [make_hash] Error 1
 | make[2]: Leaving directory 
 `/usr/local/src/deb-src/ncurses/ncurses/obj-64/ncurses'
 | make[1]: *** [all] Error 2
 | make[1]: Leaving directory `/usr/local/src/deb-src/ncurses/ncurses/obj-64'
 | make: *** [build-64] Error 2
 `

 It seems libc6-dev multiarch support needs to go back to the drawing
 board again.

 Sven, please file a separate bug report for this issue.

 Will do so soon.

On closer examination, this is probably such not a different issue after
all.  The output of `configure' is not quite what it should be:

,
| checking for sys/types.h... no
| checking for sys/stat.h... no
| checking for stdlib.h... no
| checking for string.h... no
| checking for memory.h... no
| checking for strings.h... no
| checking for inttypes.h... no
| checking for stdint.h... no
| checking for unistd.h... no
`

In config.log I find 106 occurrences of

/usr/include/gnu/stubs.h:9:27: fatal error: gnu/stubs-64.h: No such file or 
directory

All are similar to this one:

configure:7051: gcc -m64 -c -g -O2  -D_GNU_SOURCE conftest.c 5
In file included from /usr/include/features.h:388:0,
 from /usr/include/sys/types.h:26,
 from configure:7037:
/usr/include/gnu/stubs.h:9:27: fatal error: gnu/stubs-64.h: No such file or 
directory

Cheers,
   Sven



-- 
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/87y5zhijma@turtle.gmx.de

Bug#635685: general: gcc -m32 has no access to system-specific includes in multiarch world

[Sven Joachim]

On 2011-07-29 12:27 +0200, Steve Langasek wrote:

 Do you happen to have any of the following packages installed in this
 chroot?
   libacl1-dev
   libapparmor-dev
   libasound2-dev
   libcap-dev
   libsbuf-dev
   systemtap-sdt-dev

No, but libc6-dev-i386 had been installed before, shipping a
/usr/include/sys directory.

 I see, much to my surprise, that libc6-dev is not the only package shipping
 files in this directory; so if you have one of these packages installed, the
 /usr/include/sys directory will fail to be replaced by a symlink as
 intended.

That intention needs to be expressed by actually doing the conversion in
the libc6-dev-i386 postinst -- which does not currently exist.

 So that's definitely a bug and needs to be fixed.  I'm not sure if it's the
 bug that Tim and you are seeing?

It seems so.  After purging and reinstalling libc6-dev-i386,
apt-get -b source bzip2 actually succeeds.

On i386 however, libc6-dev 2.13-11 still ships files under
/usr/include/{sys,gnu,bits}, so that ncurses is unbuildable even in a
clean chroot.

Cheers,
   Sven



-- 
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/87mxfxia61@turtle.gmx.de

Bug#635685: general: gcc -m32 has no access to system-specific includes in multiarch world

[Sven Joachim]

On 2011-07-29 17:50 +0200, Steve Langasek wrote:

 On Fri, Jul 29, 2011 at 01:44:06PM +0200, Sven Joachim wrote:

  I see, much to my surprise, that libc6-dev is not the only package shipping
  files in this directory; so if you have one of these packages installed, 
  the
  /usr/include/sys directory will fail to be replaced by a symlink as
  intended.

 That intention needs to be expressed by actually doing the conversion in
 the libc6-dev-i386 postinst

 No, it does not.  libc6-dev-i386 Conflicts: with the versions of libc6-dev
 shipping /usr/include, which means they are removed from disk before
 libc6-dev-i386 is unpacked.

They are not if libc6-dev-i386 was already installed, because
libc6-dev-i386 itself contained files under /usr/include/{sys,gnu} in
versions up to 2.13-10.

 The only reason I see why this would fail would
 be because of one of the other -dev packages mentioned.

Or if libc6-dev-i386 was upgraded, rather then freshly installed.

 On i386 however, libc6-dev 2.13-11 still ships files under
 /usr/include/{sys,gnu,bits}, so that ncurses is unbuildable even in a
 clean chroot.

 Yes, which is why I told you to file a separate bug report.

Do you still want that, or should I clone the current one?

Cheers,
   Sven



-- 
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/87ei19hwum@turtle.gmx.de

Re: Bug#635685: general: gcc -m32 has no access to system-specific includes in multiarch world

[Sven Joachim]

reassign 635685 libc6-dev
severity 635685 serious
thanks

On 2011-07-28 10:58 +0200, Tim Northover wrote:

 Package: general
 Severity: normal

 It looks like gcc -m32 has been partially broken by the recent
 hiving off of various headers to /usr/include/x86_64-linux-gnu.

 In particular a program consisting of the single line #include
 features.h fails with the error:

 In file included from tmp.c:1:0:
 /usr/include/features.h:356:25: fatal error: sys/cdefs.h: No such file
 or directory
 compilation terminated.

 I suspect multiple packages are involved: cpp -m32 -v reports not
 searching /usr/include/i386-linux-gnu (or equivalent) so gcc packages
 are probably iffy; but even if it did there's nothing there to find so
 either the gcc-*-multilib or libc6-dev (or possibly even an entirely
 new gcc-*-multiheader one) will need updating.

Confirmed here on i386, ncurses biarch build is broken:

,
| $ LANG=C debian/rules build-64
| [...]
| make[2]: Entering directory 
`/usr/local/src/deb-src/ncurses/ncurses/obj-64/ncurses'
| gcc -o make_hash -DHAVE_CONFIG_H -I../ncurses 
-I/usr/local/src/deb-src/ncurses/ncurses/ncurses 
-I/usr/local/src/deb-src/ncurses/ncurses/ncurses/../include -I../include 
-DUSE_BUILD_CC   
/usr/local/src/deb-src/ncurses/ncurses/ncurses/tinfo/make_hash.c  
| In file included from /usr/include/stdlib.h:320:0,
|  from 
/usr/local/src/deb-src/ncurses/ncurses/ncurses/build.priv.h:61,
|  from 
/usr/local/src/deb-src/ncurses/ncurses/ncurses/tinfo/make_hash.c:40:
| /usr/include/i386-linux-gnu/sys/types.h:99:17: error: two or more data types 
in declaration specifiers
| make[2]: *** [make_hash] Error 1
| make[2]: Leaving directory 
`/usr/local/src/deb-src/ncurses/ncurses/obj-64/ncurses'
| make[1]: *** [all] Error 2
| make[1]: Leaving directory `/usr/local/src/deb-src/ncurses/ncurses/obj-64'
| make: *** [build-64] Error 2
`

It seems libc6-dev multiarch support needs to go back to the drawing
board again.

Cheers,
   Sven


-- 
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/87wrf2bv6h@turtle.gmx.de

Re: Bug#632405: Fails while trying to install core packages

[Sven Joachim]

reassign 632405 libc6
forcemerge 632190 632405
thanks

On 2011-07-02 05:09 +0200, Michael Biebl wrote:

 Package: debootstrap
 Version: 1.0.32
 Severity: grave

 Hi,

 trying to create a chroot like
 debootstrap sid /tmp/chroot/

 fails

 ...

 I: Installing core packages...
 W: Failure trying to run: chroot /tmp/chroot dpkg --force-depends
 --install /var/cache/apt/archives/libc6_2.13-8_i386.deb

This is a bug in libc6, see #632190.

 This makes the package more or less useless and breaks pbuilder --create
 thus marking the bug as grave.

A workaround is to create a wheezy chroot and upgrade to sid.

Cheers,
   Sven


-- 
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/87tyb5jifr@turtle.gmx.de

Re: making libc-bin essential

[Sven Joachim]

On 2011-07-01 10:31 +0200, Aurelien Jarno wrote:

 Currently libc-bin is virtually essential: a lot of essential packages
 depend on libc6 which in turn depends on libc-bin. This package has been
 created during the first steps of the multiarch transition two years 
 ago, and all the binaries have been moved there. Note that libc-bin 
 doesn't depend on libc6 while it should, in order to avoid recursive 
 dependencies.

 It appears that libc-bin provides a few required POSIX binaries [1], 
 and should therefore be essential.

That seems right to me.

 This would also solve the recursive
 dependency between libc6 and libc-bin, and allow for an hypothetical 
 libc7 transition in the future.

If libc6 were to drop its dependency on libc-bin now, it would be
possible to remove libc-bin after a partial upgrade.  Therefore I would
suggest to postpone changing the dependencies until an essential
libc-bin is in stable.

Cheers,
   Sven


-- 
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/87k4c1j6g9@turtle.gmx.de

Bug#632176: libc6: Needs to conflict with lib64* packages on amd64

[Sven Joachim]

Package: libc6
Version: 2.13-7
Severity: important
User: vor...@debian.org
Usertags: multiarch

On multiarch-enabled i386 systems, installing libc6:amd64 together with
lib64foo:i386 has some interesting effects.  To reproduce, set up an
i386 chroot with a dpkg from the pu/multiarch/full branch of
git://git.debian.org/users/hertzog/dpkg.git, enable amd64 as a foreign
architecture (echo foreign-architecture amd64  /etc/dpkg/dpkg.cfg),
and run apt-get update.  Then

# apt-get install libc6:amd64
# apt-get install lib64ncurses5
# bash

You get an error message: bash: error while loading shared libraries:
libncurses.so.5: wrong ELF class: ELFCLASS64.

The effects of installing libc6:amd64 _after_ lib64ncurses5 will also be
interesting, since /lib64 does not get converted to a symlink in that
case, AFAICS.


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.0.0-rc5-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/877h83r8dp@turtle.gmx.de

Bug#632176: libc6: Needs to conflict with lib64* packages on amd64

[Sven Joachim]

On 2011-06-30 18:36 +0200, Jonathan Nieder wrote:

 Sven Joachim wrote:

 On multiarch-enabled i386 systems, installing libc6:amd64 together with
 lib64foo:i386 has some interesting effects.
 [...]
 # apt-get install libc6:amd64
 # apt-get install lib64ncurses5
 # bash
 
 You get an error message: bash: error while loading shared libraries:
 libncurses.so.5: wrong ELF class: ELFCLASS64.

 Weird and scary.  Any idea why this happens?

I can even explain exactly why. :-)  Because I had no /lib64 directory
before, installing libc6:amd64 created the /lib64 - /lib symlink, and
then installing lib64ncurses5 created /lib64/libncurses.so.5,
overwriting the existing /lib/libncurses.so.5 from libncurses5 through
the symlink.  This is a file conflict that dpkg does not notice.

 The effects of installing libc6:amd64 _after_ lib64ncurses5 will also be
 interesting, since /lib64 does not get converted to a symlink in that
 case, AFAICS.

 I hope installing libc6:amd64 before does not change /lib64 into a
 symlink, either (maybe that is what is happening here).

If /lib64 already exists, it will not be converted.  This means that
removing libc6-amd64 will instantly break all 64-bit programs, because
/lib64/ld-linux-x86-64.so.2 is gone and you are left with
/lib/ld-linux-x86-64.so.2 which is in the wrong directory. :-/

Cheers,
   Sven



-- 
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/87sjqrp7se@turtle.gmx.de

Bug#617759: Just got hit by this bug after installing xul-ext-adblock-plus

[Sven Joachim]

Hi,

today I hit this bug: after installing an extension, namely
xul-ext-adblock-plus, and restarting icedove it failed:

$ icedove
/usr/lib/icedove/icedove-bin: symbol lookup error: 
/usr/lib/icedove/components/libdbusservice.so: undefined symbol: NS_Alloc

This is in accord with Jonathan's remarks in comment #80.  Also,
following the tip in #198,

$ LD_BIND_NOW=1 icedove

got me out of trouble.  Well, sort of, because I had to deactivate the
new extension to make icedove start without LD_BIND_NOW=1.

Cheers,
   Sven



-- 
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/87k4dv7h9x@turtle.gmx.de

Re: Bug#598234: emacs23-nox: emacs fails to install on mipsel

[Sven Joachim]

Hi folks,

Déjà vu: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566947
just reared its ugly head again. :-(

On 2010-09-28 03:27 +0200, Christoph Egger wrote:

 Package: emacs23-nox
 Version: 23.2+1-4
 Severity: serious

 The following partially installed packages will be configured:
   emacs23-nox 
 No packages will be installed, upgraded, or removed.
 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 Need to get 0B of archives. After unpacking 0B will be used.
 Setting up emacs23-nox (23.2+1-4) ...
 emacs-install emacs23
 emacsen-common: Handling install of emacsen flavor emacs23
 emacsen-common: byte-compiling for emacs23
 emacs23: malloc.c:3097: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
 *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
 fd  old_size == 0) || ((unsigned long) (old_size) = (unsigned 
 long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
 (sizeof(size_t))) - 1))  ~((2 * (sizeof(size_t))) - 1)))  ((old_top)-size 
  0x1)  ((unsigned long)old_end  pagemask) == 0)' failed.
 Fatal error (6)Aborted
 emacs-install: /usr/lib/emacsen-common/packages/install/emacsen-common 
 emacs23 failed at /usr/lib/emacsen-common/emacs-install line 28, TSORT line 
 1.
 dpkg: error processing emacs23-nox (--configure):
  subprocess installed post-installation script returned error exit status 134
 configured to not write apport reports
   Errors were encountered while 
 processing:
  emacs23-nox
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 A package failed to install.  Trying to recover:
 Setting up emacs23-nox (23.2+1-4) ...
 emacs-install emacs23
 emacsen-common: Handling install of emacsen flavor emacs23
 emacsen-common: byte-compiling for emacs23
 emacs23: malloc.c:3097: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
 *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
 fd  old_size == 0) || ((unsigned long) (old_size) = (unsigned 
 long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
 (sizeof(size_t))) - 1))  ~((2 * (sizeof(size_t))) - 1)))  ((old_top)-size 
  0x1)  ((unsigned long)old_end  pagemask) == 0)' failed.
 Fatal error (6)Aborted
 emacs-install: /usr/lib/emacsen-common/packages/install/emacsen-common 
 emacs23 failed at /usr/lib/emacsen-common/emacs-install line 28, TSORT line 
 1.
 dpkg: error processing emacs23-nox (--configure):
  subprocess installed post-installation script returned error exit status 134
 Errors were encountered while processing:
  emacs23-nox



 -- System Information:
 Debian Release: squeeze/sid
   APT prefers testing
   APT policy: (500, 'testing'), (1, 'experimental')
 Architecture: mipsel (mips64)

 Kernel: Linux 2.6.36-rc5-loongson-2f
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages emacs23-nox depends on:
 ii  emacs23-bin-common23.2+1-4   The GNU Emacs editor's shared, 
 arc
 ii  libasound21.0.23-1   shared library for ALSA 
 applicatio
 ii  libc6 2.11.2-6   Embedded GNU C Library: Shared 
 lib
 ii  libdbus-1-3   1.2.24-3   simple interprocess messaging 
 syst
 ii  libgpm2   1.20.4-3.3 General Purpose Mouse - shared 
 lib
 ii  libncurses5   5.7+20100313-3 shared libraries for terminal 
 hand

 emacs23-nox recommends no packages.

 Versions of packages emacs23-nox suggests:
 pn  emacs23-common-non-dfsg   none (no description available)

 -- 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/87iq1rujsy@turtle.gmx.de

Bug#585737: not really fixed

[Sven Joachim]

found 585737 2.11.2-1
thanks

Alas, the Breaks: locales ( 2.11) does not really help much, as I
discovered when upgrading a sid chroot today.  While the new locales
package got unpacked early, it was only configured together with the
bulk of optional packages, and lots of the annoying perl warnings spewed
to the terminal in between.  I'm attaching the dpkg log of the upgrade.

Sven



dpkg.log.gz
Description: dpkg log

Bug#585737: not really fixed

[Sven Joachim]

On 2010-06-18 11:08 +0200, Aurelien Jarno wrote:

 tag 585737 + wontfix
 thanks

 Sven Joachim a écrit :
 found 585737 2.11.2-1
 thanks
 
 Alas, the Breaks: locales ( 2.11) does not really help much, as I
 discovered when upgrading a sid chroot today.  While the new locales
 package got unpacked early, it was only configured together with the
 bulk of optional packages, and lots of the annoying perl warnings spewed
 to the terminal in between.  I'm attaching the dpkg log of the upgrade.

 Then there is nothing we can do. Marking the bug as wontfix.

Seems reasonable.  The problem that apt leaves packages with low
priority unconfigured for a long time is very old, reported first
twelve years ago¹.

Sven


¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=22550



-- 
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/87aaqs665m@turtle.gmx.de

Re: Bug#566947: emacs23-nox fails to install

[Sven Joachim]

[ Putting the glibc maintainers and the mips porters into the loop.
  Summary: emacs23-nox aborts with malloc assertion failure on mipsel. ]

On 2010-01-26 02:17 +0100, Deng Xiyue wrote:

 Package: emacs23-nox
 Version: 23.1+1-5
 Severity: grave

 When installing emacs23-nox, aptitude stops with the following outputs:

 ---BEGIN OF OUTPUT---

 $ LANG=C sudo aptitude install emacs23-nox
 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 Reading extended state information
 Initializing package states... Done
 Reading task descriptions... Done
 The following partially installed packages will be configured:
   emacs23-nox
 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 Need to get 0B of archives. After unpacking 0B will be used.
 Writing extended state information... Done
 Setting up emacs23-nox (23.1+1-5) ...
 emacs-install emacs23
 install/cscope: Byte-compiling for emacs23
 emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
 *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
 fd  old_size == 0) || ((unsigned long) (old_size) = (unsigned 
 long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
 (sizeof(size_t))) - 1))  ~((2 * (sizeof(size_t))) - 1)))  ((old_top)-size 
  0x1)  ((unsigned long)old_end  pagemask) == 0)' failed.
 Fatal error (6)Aborted

This assertion failure happens in libc6.  I'm inclined to reassign the
bug, but I'll leave this to more knowledgeable people.  The fact that
the eglibc testsuite is currently disabled on mipsel¹ does not exactly
increase confidence in the libc6 package on that architecture.

 install/dictionaries-common: Byte-compiling for emacsen flavour emacs23
 emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
 *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
 fd  old_size == 0) || ((unsigned long) (old_size) = (unsigned 
 long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
 (sizeof(size_t))) - 1))  ~((2 * (sizeof(size_t))) - 1)))  ((old_top)-size 
  0x1)  ((unsigned long)old_end  pagemask) == 0)' failed.
 Fatal error (6)Aborted
 emacsen-common: Handling install of emacsen flavor emacs23
 emacsen-common: byte-compiling for emacs23
 emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
 *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
 fd  old_size == 0) || ((unsigned long) (old_size) = (unsigned 
 long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
 (sizeof(size_t))) - 1))  ~((2 * (sizeof(size_t))) - 1)))  ((old_top)-size 
  0x1)  ((unsigned long)old_end  pagemask) == 0)' failed.
 Fatal error (6)Aborted
 emacs-install: /usr/lib/emacsen-common/packages/install/emacsen-common 
 emacs23 failed at /usr/lib/emacsen-common/emacs-install line 28, TSORT line 
 6.
 dpkg: error processing emacs23-nox (--configure):
  subprocess installed post-installation script returned error exit status 134
 Errors were encountered while processing:
  emacs23-nox
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 A package failed to install.  Trying to recover:
 Setting up emacs23-nox (23.1+1-5) ...
 emacs-install emacs23
 install/cscope: Byte-compiling for emacs23
 emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
 *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
 fd  old_size == 0) || ((unsigned long) (old_size) = (unsigned 
 long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
 (sizeof(size_t))) - 1))  ~((2 * (sizeof(size_t))) - 1)))  ((old_top)-size 
  0x1)  ((unsigned long)old_end  pagemask) == 0)' failed.
 Fatal error (6)Aborted
 install/dictionaries-common: Byte-compiling for emacsen flavour emacs23
 emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
 *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
 fd  old_size == 0) || ((unsigned long) (old_size) = (unsigned 
 long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
 (sizeof(size_t))) - 1))  ~((2 * (sizeof(size_t))) - 1)))  ((old_top)-size 
  0x1)  ((unsigned long)old_end  pagemask) == 0)' failed.
 Fatal error (6)Aborted
 emacsen-common: Handling install of emacsen flavor emacs23
 emacsen-common: byte-compiling for emacs23
 emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
 *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
 fd  old_size == 0) || ((unsigned long) (old_size) = (unsigned 
 long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
 (sizeof(size_t))) - 1))  ~((2 * (sizeof(size_t))) - 1)))  ((old_top)-size 
  0x1)  ((unsigned long)old_end  pagemask) == 0)' failed.
 Fatal error (6)Aborted
 emacs-install: /usr/lib/emacsen-common/packages/install/emacsen-common 
 emacs23 failed at /usr/lib/emacsen-common/emacs-install line 

Bug#249122: Link to upstream bug

[Sven Joachim]

reassign 249122 libc-bin
forwarded 249122 http://sourceware.org/bugzilla/show_bug.cgi?id=1484
thanks

This bug had been originally reported as #224450 against
libncurses5-dev, and is marked as forwarded there.  It probably makes
more sense to mark #249122 as forwarded, since that bug is about the
ldconfig part of the story.

I'm also reassigning it to libc-bin, as ldconfig has moved to that
package.

Sven



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

Re: Please test eglibc 2.9-23+multiarch.1

[Sven Joachim]

On 2009-07-29 22:12 +0200, Aurelien Jarno wrote:

 On Wed, Jul 29, 2009 at 04:10:27PM +0200, Aurelien Jarno wrote:
 In short it looks like a Pre-Depends is overkill, and that a Depends is 
 enough. I'll upload a new version soon to experimental to fix that.
 

 eglibc version 2.9-23+multiarch.1 is now in incoming and will be on the
 mirrors soon. Please test and report problems.

It still fails in my Lenny chroot:

,
| # LANG=C apt-get dist-upgrade
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| Calculating upgrade... Done
| The following NEW packages will be installed:
|   libc-bin libc-dev-bin
| The following packages will be upgraded:
|   libc6 libc6-dev locales
| 3 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
| Need to get 0B/14.1MB of archives.
| After this operation, 6377kB of additional disk space will be used.
| Do you want to continue [Y/n]? y
| WARNING: The following packages cannot be authenticated!
|   libc-dev-bin libc6-dev locales libc-bin libc6
| Install these packages without verification [y/N]? y
| E: Internal Error, Could not perform immediate configuration (2) on libc-bin
`

This may be due to apt wanting to configure required packages
immediately (the right order would be to unpack everything first).
Any idea what to do now?

Sven


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

Re: Please test eglibc 2.9-23+multiarch

[Sven Joachim]

On 2009-07-28 19:44 +0200, Aurelien Jarno wrote:

 I have recently uploaded to experimental eglibc 2.9-23+multiarch, from 
 our multiarch branch. It doesn't use the multiarch paths yet, but it is
 a first step toward multiarch. 

 The only difference with the unstable version is that libc-bin and
 libc-dev-bin are splitted out of libc6 and libc6-dev. This way it
 complies with the Debian Policy requirement that the libraries should 
 not contain binaries, which is also a requirement for multiarch.

 Please test it and report possible problems related to this package
 split. If no problem are detected, it will be uploaded to unstable as
 soon as the current version migrates to testing. This way it will leave
 space in experimental for eglibc 2.10.

 Note that it is currently not yet available on all architectures, please
 wait for the experimental buildds to do their jobs.

I was not patient enough for that and built the packages myself instead
on i386.  The result is not quite satisfactory, in a Lenny chroot they
cannot be installed due to a dependency cycle:

,
| # cat /etc/debian_version 
| 5.0.2
| turtle:/# LANG=C apt-get dist-upgrade
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| Calculating upgrade... Done
| The following NEW packages will be installed:
|   libc-bin
| The following packages will be upgraded:
|   libc6 libc6-dev locales
| 3 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
| Need to get 0B/13.9MB of archives.
| After this operation, 6042kB of additional disk space will be used.
| Do you want to continue [Y/n]? 
| WARNING: The following packages cannot be authenticated!
|   libc6-dev locales libc6 libc-bin
| Install these packages without verification [y/N]? y
| E: Couldn't configure pre-depend libc-bin for libc6, probably a dependency 
cycle.
`

Same problem with aptitude, and this is the reason: libc6
2.9-23+multiarch Pre-Depends on libc-bin (= 2.9-23+multiarch) which in
turn Depends on libc6 ( 2.9), so if you didn't have libc6 2.9-x
already installed, you're hosed.

Sven


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

Bug#536506: glibc-doc-reference: clutters up main info directory

[Sven Joachim]

tags 536506 + patch
thanks

On 2009-07-11 02:06 +0200, Aurelien Jarno wrote:

 tag 536506 + help
 thanks

 On Fri, Jul 10, 2009 at 05:56:01PM +0200, Sven Joachim wrote:
 Package: glibc-doc-reference
 Version: 2.9-1
 Severity: normal
 
 Your package puts an entry for every libc function and macro into the
 main info directory, using up more than 1700 lines.  This has been
 triggered by the transition to GNU's install-info; apparently the dpkg
 implementation ignored secondary INFO-DIR-SECTION entries.
 

 Could you have more details about what should be changed to fix that?

There should not be a direntry for every function (upstream includes
them on purpose, but this is a big abuse, that is what indices are
for).  The following minimal patch avoids this:

--8---cut here---start-8---
--- glibc-doc-reference-2.9.orig/manual/libc.texinfo
+++ glibc-doc-reference-2.9/manual/libc.texinfo
@@ -9,7 +9,6 @@
 @direntry
 * Libc: (libc). C library.
 @end direntry
-...@include dir-add.texi
 
 @c This tells texinfo.tex to use the real section titles in xrefs in
 @c place of the node name, when no section title is explicitly given.
--8---cut here---end---8---

I have already rebuilt and installed glibc-doc-reference with it.

Sven



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

Bug#536506: glibc-doc-reference: clutters up main info directory

[Sven Joachim]

Package: glibc-doc-reference
Version: 2.9-1
Severity: normal

Your package puts an entry for every libc function and macro into the
main info directory, using up more than 1700 lines.  This has been
triggered by the transition to GNU's install-info; apparently the dpkg
implementation ignored secondary INFO-DIR-SECTION entries.


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

Kernel: Linux 2.6.30.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 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#533773: /usr/lib32 transition broken

[Sven Joachim]

On 2009-06-20 21:24 +0200, Clint Adams wrote:

 On Sat, Jun 20, 2009 at 02:10:25PM +0200, Goswin Brederlow wrote:
 you actually managed to completly screw the pooch with the /usr/lib32
 transition from link to directory and now on existing installations it
 remains a link. Now /emul/ia32-linux/[usr/]lib contains files that

 Why would it remain a link? Is there a bug in dpkg?

No, this behavior is documented in Policy §6.6:

A directory will never be replaced by a symbolic link to a
directory or vice versa; instead, the existing state (symlink or
not) will be left alone and `dpkg' will follow the symlink if
there is one.

Sven



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

Bug#527567: eglibc: FTBFS: regression in tst-eintr1

[Sven Joachim]

On 2009-05-09 23:16 +0200, Aurelien Jarno wrote:

 Are you able to reproduce the problem with previous versions? 2.9-10 is
 still on the mirrors for example.

Initially I had the problem with 2.9-9, but did not bother to report it
as 2.9-10 built successfully.  Retrying today, 2.9-10 also fails the
eintr1 test.  As I said, the failure does not happen all of the time,
but only in ~85% of all cases.

 You can also try with a different kernel.

2.6.28.10 does not show the problem (repeated the test a few dozen
times), but all 2.6.29 kernels I've tested have it, including Debian's
official 2.6.29-2-amd64 package.  Under 2.6.30-rc5 the test fails as
well.

Which kernel do you use?

Sven



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

Bug#527567: eglibc: FTBFS: regression in tst-eintr1

[Sven Joachim]

On 2009-05-10 10:25 +0200, Aurelien Jarno wrote:

 On Sun, May 10, 2009 at 09:18:56AM +0200, Sven Joachim wrote:
 
 2.6.28.10 does not show the problem (repeated the test a few dozen
 times), but all 2.6.29 kernels I've tested have it, including Debian's
 official 2.6.29-2-amd64 package.  Under 2.6.30-rc5 the test fails as
 well.
 
 Which kernel do you use?

 I am using a 2.6.28-1-amd64, while the build daemons are using a 
 2.6.26-2-amd64 one, that's probably why I am not able to reproduce the
 problem.

It seems I found out the reason why the test fails on my system.  To
protect myself against fork bombs, I've put the following values into
/etc/security/limits.conf:

,
| *  softnproc   250
| *  hardnproc   400
`

Apparently these limits are too low for the high number of threads that
tst-eintr1 creates, so it gets the EAGAIN error.  Something regarding
thread handling must have changed between 2.6.28 and 2.6.29.

Looks like I have to experiment with the nproc limit, but the bug should
probably be closed or reassigned to linux-2.6.

Sven



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

Bug#527567: eglibc: FTBFS: regression in tst-eintr1

[Sven Joachim]

On 2009-05-09 21:07 +0200, Aurelien Jarno wrote:

 On Fri, May 08, 2009 at 09:40:49AM +0200, Sven Joachim wrote:
 Package: eglibc
 Version: 2.9-11
 
 I've experienced a testsuite failure again:
 
 ,
 | # 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)
 | check-localplt.out, Error 1
 | tst-cancelx4.out, Error 1
 | tst-cancelx5.out, Error 1
 | tst-eintr1.out, Error 1
 | ***
 | Encountered regressions that don't match expected failures:
 | tst-eintr1.out, Error 1
 `
 

 Have you tried with version 2.9-12 to see if the bug is fixed? 

Yes, I tried, and no, it is not fixed.

 Note that the bug is not reproducible here.

Not on the buildds either, it seems.  Any ideas how I can debug this?

Sven



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

Bug#527567: eglibc: FTBFS: regression in tst-eintr1

[Sven Joachim]

Package: eglibc
Version: 2.9-11

I've experienced a testsuite failure again:

,
| # 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)
| check-localplt.out, Error 1
| tst-cancelx4.out, Error 1
| tst-cancelx5.out, Error 1
| tst-eintr1.out, Error 1
| ***
| Encountered regressions that don't match expected failures:
| tst-eintr1.out, Error 1
`

The failing test is this one:

,
| 
GCONV_PATH=/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/iconvdata
 LC_ALL=C 
/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/elf/ld-linux.so.2 
--library-path 
/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc:/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/math:/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/elf:/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/dlfcn:/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/nss:/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/nis:/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/rt:/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/resolv:/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/crypt:/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/nptl
 /usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/nptl/tst-eintr1  
 
/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/nptl/tst-eintr1.out
| Expected signal 'Alarm clock' from child, got none
| make[3]: *** 
[/usr/local/src/deb-src/eglibc/eglibc-2.9/build-tree/i386-libc/nptl/tst-eintr1.out]
 Error 1
`

The tst-eintr1.out file has this content:

...tf1: pthread_create failed: Resource temporarily unavailable


This is not always reproducible, but running the test repeatedly failed
in 86 out of 100 invocations. 


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

Kernel: Linux 2.6.29.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash




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

Bug#502311: testsuite failures in glibc

[Sven Joachim]

On 2009-02-23 08:01 +0100, Aurelien Jarno wrote:

 On Sun, Feb 22, 2009 at 11:48:55AM +0100, Sven Joachim wrote:
 All but one of these errors are fixed or ignored in 2.9-2, but the last
 problem still occurs -- apparently only if a 64-bit kernel is running
 and detectable.  From my debuild log:
 
 ,
 | #
 | # 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)
 | check-localplt.out, Error 1
 | tst-cancelx4.out, Error 1
 | tst-cancelx5.out, Error 1
 | tst-cpuclock2.out, Error 1
 | tst-tables.out, Error 1
 | ***
 | Encountered regressions that don't match expected failures:
 | tst-tables.out, Error 1
 `
 
 This does not happen if the build is run under linux32.  The
 corresponding error message looks like this:
 
 ,
 | /bin/bash tst-tables.sh 
 /usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/ 
 /usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/  
 /usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/tst-tables.out
 | Testing ASCIItst-table.sh:38: command not found: tst-table-charmap.sh
 |  *** FAILED ***
 | make[3]: *** 
 [/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/tst-tables.out]
  Error 1
 `

 This is not something I am able to reproduce here, either with bash or
 dash. This problems also looks very strange, it's a shell script not
 able to find another one, and I have problem to understand how the linux
 personality can affect that.

You're right.  The problem is not related to that at all.  Rather, I ran
the original build with debuild but than retried with
linux32 debian/rules build to save the recompilation time.  The
difference in the environment (most notably, debuild unsetting SHELL) is
the problem.

 The best to debug that is probably to pass -x to the shell, which should
 gives some more debugging input.

Did that and got this result:

,
| /bin/bash tst-tables.sh 
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/ 
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/  
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/tst-tables.out
| + common_objpfx=/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/
| + 
objpfx=/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/
| + status=0
| + cat
| + read charset charmap
| + test '#' = GB18030
| + case ${charset} in
| + continue
| + read charset charmap
| + test '#' = GB18030
| + case ${charset} in
| + continue
| + read charset charmap
| + test '#' = GB18030
| + case ${charset} in
| + continue
| + read charset charmap
| + test '#' = GB18030
| + case ${charset} in
| + continue
| + read charset charmap
| + test ASCII = GB18030
| + case ${charset} in
| + echo -n 'Testing ASCII'
| Testing ASCII+ /bin/zsh tst-table.sh 
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/ 
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/ ASCII 
ANSI_X3.4-1968
| tst-table.sh:38: command not found: tst-table-charmap.sh
| + echo 'failed: ./tst-table.sh 
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/ 
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/ ASCII 
ANSI_X3.4-1968'
| + echo ' *** FAILED ***'
|  *** FAILED ***
| + exit 1
| + exit 1
| make[3]: *** 
[/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/tst-tables.out]
 Error 1
`

Line 38 of tst-table.sh reads

${SHELL} tst-table-charmap.sh ${charmap:-$charset} \
   ../localedata/charmaps/${charmap:-$charset} \
   ${objpfx}tst-${charset}.charmap.table

and with SHELL unset, it would try to run tst-table-charmap.sh directly,
which isn't found in $PATH.  This can be easily remedied, e.g. with

--8---cut here---start-8---
--- tst-table.sh~   2002-04-24 23:39:35.0 +0200
+++ tst-table.sh2009-02-23 11:19:33.0 +0100
@@ -35,7 +35,7 @@
 set -e
 
 # Get the charmap.
-${SHELL} tst-table-charmap.sh ${charmap:-$charset} \
+${SHELL:-/bin/sh} tst-table-charmap.sh ${charmap:-$charset} \
../localedata/charmaps/${charmap:-$charset} \
${objpfx}tst-${charset}.charmap.table
 # When the charset is GB18030, truncate this table because for this encoding,
--8---cut here---end---8---

Cheers,
   Sven





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

Bug#502311: testsuite failures in glibc

[Sven Joachim]

On 2009-02-18 15:42 +0100, Sven Joachim wrote:

 found 502311 2.9-1
 thanks

 Now glibc apparently built fine on ia64, but it does not on i386.
 Here is the result from my local build with debuild:

 ,
 | #
 | # 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)
 | check-localplt.out, Error 1
 | tst-cancel7.out, Error 1
 | tst-cancelx4.out, Error 1
 | tst-cancelx5.out, Error 1
 | tst-cancelx7.out, Error 1
 | tst-cleanup0.out, Error 2
 | tst-cpuclock2.out, Error 1
 | tst-fmon.out, Error 1
 | tst-tables.out, Error 1
 | ***
 | Encountered regressions that don't match expected failures:
 | tst-cancel7.out, Error 1
 | tst-cancelx7.out, Error 1
 | tst-cleanup0.out, Error 2
 | tst-cpuclock2.out, Error 1
 | tst-fmon.out, Error 1
 | tst-tables.out, Error 1
 `

All but one of these errors are fixed or ignored in 2.9-2, but the last
problem still occurs -- apparently only if a 64-bit kernel is running
and detectable.  From my debuild log:

,
| #
| # 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)
| check-localplt.out, Error 1
| tst-cancelx4.out, Error 1
| tst-cancelx5.out, Error 1
| tst-cpuclock2.out, Error 1
| tst-tables.out, Error 1
| ***
| Encountered regressions that don't match expected failures:
| tst-tables.out, Error 1
`

This does not happen if the build is run under linux32.  The
corresponding error message looks like this:

,
| /bin/bash tst-tables.sh 
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/ 
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/  
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/tst-tables.out
| Testing ASCIItst-table.sh:38: command not found: tst-table-charmap.sh
|  *** FAILED ***
| make[3]: *** 
[/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata/tst-tables.out]
 Error 1
`

Regards,
Sven



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

Bug#502311: testsuite failures in glibc

[Sven Joachim]

found 502311 2.9-1
thanks

Now glibc apparently built fine on ia64, but it does not on i386.
Here is the result from my local build with debuild:

,
| #
| # 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)
| check-localplt.out, Error 1
| tst-cancel7.out, Error 1
| tst-cancelx4.out, Error 1
| tst-cancelx5.out, Error 1
| tst-cancelx7.out, Error 1
| tst-cleanup0.out, Error 2
| tst-cpuclock2.out, Error 1
| tst-fmon.out, Error 1
| tst-tables.out, Error 1
| ***
| Encountered regressions that don't match expected failures:
| tst-cancel7.out, Error 1
| tst-cancelx7.out, Error 1
| tst-cleanup0.out, Error 2
| tst-cpuclock2.out, Error 1
| tst-fmon.out, Error 1
| tst-tables.out, Error 1
`

The official i386 buildd reported fewer failures but didn't work either: 

,[ 
https://buildd.debian.org/fetch.cgi?pkg=glibc;ver=2.9-1;arch=i386;stamp=1234952645
 ]
| #
| # 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)
| check-localplt.out, Error 1
| testgrp.out, Error 1
| tst-cancelx4.out, Error 1
| tst-cancelx5.out, Error 1
| tst-cpuclock2.out, Error 1
| ***
| Encountered regressions that don't match expected failures:
| tst-cpuclock2.out, Error 1
`



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

Bug#502311: testsuite failures in glibc

[Sven Joachim]

On 2009-02-18 16:45 +0100, Aurelien Jarno wrote:

 Sven Joachim a écrit :

 You are probably using an old kernel which has some problems. The buildd
 is using a 2.6.26 kernel from lenny.

While my kernel may have some problems (not that I noticed any, but it's
of course possible), it is not exactly old:

,
| $ cat /proc/version
| Linux version 2.6.28.6-amd64 (r...@turtle) (gcc version 4.1.3 20080704 
(prerelease) (Debian 4.1.2-25)) #1 SMP Tue Feb 17 20:03:14 CET 2009
`

 The official i386 buildd reported fewer failures but didn't work either: 
 
 ,[ 
 https://buildd.debian.org/fetch.cgi?pkg=glibc;ver=2.9-1;arch=i386;stamp=1234952645
  ]
 | #
 | # 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)
 | check-localplt.out, Error 1
 | testgrp.out, Error 1
 | tst-cancelx4.out, Error 1
 | tst-cancelx5.out, Error 1
 | tst-cpuclock2.out, Error 1
 | ***
 | Encountered regressions that don't match expected failures:
 | tst-cpuclock2.out, Error 1
 `

 This is because it uses cpufreq with the ondemand governor. This test is
 being ignored in the latest SVN.

Good to hear.

Regards,
Sven



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

Bug#502311: testsuite failures in glibc

[Sven Joachim]

On 2009-02-18 18:00 +0100, Aurelien Jarno wrote:

 Then maybe some regressions have been added in the latest versions.
 Could you retry with a 2.6.26 kernel from lenny/unstable? This version
 is working on the buildd and on my machine, so that will infirm/confirm
 it is due to the kernel.

Would not be very convenient for me, but I may try it sometime later.
In the meantime, to isolate problems due to the combination 64-bit
kernel/32-bit userland I re-ran the testsuite with linux32 debian/rules
build and got one error less than originally:

,
| #
| # 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)
| check-localplt.out, Error 1
| tst-cancel7.out, Error 1
| tst-cancelx4.out, Error 1
| tst-cancelx5.out, Error 1
| tst-cancelx7.out, Error 1
| tst-cleanup0.out, Error 2
| tst-cpuclock2.out, Error 1
| tst-fmon.out, Error 1
| ***
| Encountered regressions that don't match expected failures:
| tst-cancel7.out, Error 1
| tst-cancelx7.out, Error 1
| tst-cleanup0.out, Error 2
| tst-cpuclock2.out, Error 1
| tst-fmon.out, Error 1
`

The tst-cancel*.out files all consist of a single line reading 

child pid still running

The error in tst-cleanup0.out is due to a bashism in the test suite, I'm
using dash as /bin/sh.  See the excerpt in the attached file
tst-cleanup0-bashism.  There are probably more bashisms, e.g. in
nptl/tst-tls6.sh.

The error in tst-fmon.out is unclear to me, I'm attaching that file as
well.  I doubt that it has to do anything with the kernel, though.

Regards,
Sven

GCONV_PATH=/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/iconvdata
 LC_ALL=C   
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/elf/ld-linux.so.2 
--library-path 
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc:/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/math:/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/elf:/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/dlfcn:/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/nss:/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/nis:/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/rt:/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/resolv:/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/crypt:/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/nptl
 /usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/nptl/tst-cleanup0  
21 | cmp - tst-cleanup0.expect  
/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/nptl/tst-cleanup0.out
/bin/sh: Syntax error: Bad fd number
make[3]: *** 
[/usr/local/src/deb-src/glibc/glibc-2.9/build-tree/i386-libc/nptl/tst-cleanup0.out]
 Error 2
Locale: de_DE.ISO-8859-1 Format: %n Value: 1.23 Received: 1,23 EUR 
Expected:   1,23 EUR = false
Locale: de_DE.ISO-8859-1 Format: %n Value: -1.23 Received: -1,23 EUR 
Expected: -1,23 EUR = false
Locale: de_DE.ISO-8859-1 Format: %n Value: 1234.56 Received: 1.234,56 
EUR Expected:1.234,56 EUR = false
Locale: de_DE.ISO-8859-1 Format: %12n Value: 123.45 Received:   123,45 
EUR Expected: 123,45 EUR = false
Locale: de_DE.ISO-8859-1 Format: %12n Value: -123.45 Received:  -123,45 
EUR Expected:   -123,45 EUR = false
Locale: de_DE.ISO-8859-1 Format: %^n Value: 1234.56 Received: 1234,56 
EUR Expected:1234,56 EUR = false
Locale: de_DE.ISO-8859-1 Format: %+n Value: 1234.56 Received: 1.234,56 
EUR Expected:   1.234,56 EUR = false
Locale: de_DE.ISO-8859-1 Format: %(n Value: 1234.56 Received: 1.234,56 
EUR Expected:   1.234,56 EUR = false
Locale: de_DE.ISO-8859-1 Format: %^n Value: 1234.56 Received: 1234,56 
EUR Expected:1234,56 EUR = false
Locale: de_DE.ISO-8859-1 Format: %i Value: 1.23 Received: 1,23 EUR 
Expected:   1,23 EUR = false
Locale: de_DE.ISO-8859-1 Format: %i Value: -1.23 Received: -1,23 EUR 
Expected: -1,23 EUR = false
Locale: de_DE.ISO-8859-1 Format: %i Value: 1234.56 Received: 1.234,56 
EUR Expected:1.234,56 EUR = false
Locale: de_DE.ISO-8859-1 Format: %^i Value: 1234.56 Received: 1234,56 
EUR Expected:1234,56 EUR = false
Locale: de_DE.ISO-8859-1 Format: %+i Value: 1234.56 Received: 1.234,56 
EUR Expected:   1.234,56 EUR = false
Locale: de_DE.ISO-8859-1 Format: %(i Value: 1234.56 Received: 1.234,56 
EUR Expected:   1.234,56 EUR = false
Locale: de_DE.ISO-8859-1 Format: %^i Value: 1234.56 Received: 1234,56 
EUR Expected:1234,56 EUR = false
Locale: de_DE.ISO-8859-1 Format: %#5n Value: 123.45 Received: 123,45 
EUR Expected: 123,45 EUR = false
Locale: de_DE.ISO-8859-1 Format: %#5n Value: -123.45 Received: -   
123,45 EUR Expected:-   123,45 EUR = false
Locale: de_DE.ISO-8859-1 Format: %=*#5n Value: 123.45 Received:  
***123,45 EUR Expected:***123,45 EUR = false
Locale: de_DE.ISO-8859-1 Format: 

Re: Bug#143870: Doesn't update resolver settings

[Sven Joachim]

reassign 143870 libc6 2.2.3-5
thanks

Hi,

I'm trying to clean up old Emacs bugs in Debian.  This one seems to
belong elsewhere, see [1].

On 2001-06-16 12:01 +0200, Tollef Fog Heen wrote:

 Package: emacs

 It seems like emacs doesn't like when the resolver settings change:

From tcpdump (when gnus tries to access the news server):

 11:53:29.895362 arabella.dep.no.32962  192.168.1.106.domain:  48041+ A? 
 news.hardware.no.intern.opera.no. (50) (DF)
 11:53:35.905738 arabella.dep.no.32962  192.168.1.106.domain:  48042+ A? 
 news.hardware.no. (34) (DF)
 11:53:40.915724 arabella.dep.no.32962  192.168.1.106.domain:  48042+ A? 
 news.hardware.no. (34) (DF)
 11:53:45.925969 arabella.dep.no.32962  192.168.1.106.domain:  48043+ A? 
 news.hardware.no.intern.opera.no. (50) (DF)

 while /etc/resolv.conf says:

 search dep.no
 nameserver 132.150.1.82
 nameserver 132.150.5.82

 However, 192.168.1.106 was my name server when emacs was started.
 (This is a laptop).

 I suspect this might be some interaction with glibc, but haven't the
 time to dig into the code.  Relevant versions are:

 $dpkg -l libc6 emacs20 gnus
 Desired=Unknown/Install/Remove/Purge/Hold
 | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
 |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: 
 uppercase=bad)
 ||/ NameVersion Description
 +++-===-===-==
 ii  libc6   2.2.3-5 GNU C Library: Shared libraries and 
 Timezone d
 ii  emacs20 20.7-3  The GNU Emacs editor.
 ii  gnus5.8.8-2 A versatile News and mailing list reader 
 for E

Since name resolving is not really Emacs' job, I'm reassigning this bug
to the libc6 package where it belongs.  It seems to me that the problem
is resolved ;-) already, see #272265[2], so the bug can probably be
closed.

Regards,
Sven


1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=143870#16
2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272265


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

Bug#508764: libc6: Lots of locale warnings during upgrade

[Sven Joachim]

reassign 508764 perl
forcemerge 221790 508764
thanks

On 2008-12-15 04:15 +0100, Michael Biebl wrote:

 Package: libc6
 Version: 2.7-16
 Severity: important

 Hi,

 I did a test upgrade from etch - lenny. As soon as the new libc6 has
 been unpacked, I get lots of those warnings:

 perl: warning: Setting locale faile
 perl: warning: Please check that your locale settings:
 LANGUAGE = (unset)
   LC_ALL = (unset)
   LANG = de_DE.UTF-8
 are support and installed on your system.
 perl: warning: Falling back to the standard locale (C).

You see this because the old locales package is not compatible with the
new libc6 and has been auto-deconfigured.  These messages go away after
the new locales package has been configured, which unfortunately does
happen rather late during dist-upgrades.

 The sheer amount of those warnings, makes it hard to spot any real
 important messages.

The warning messages come from Perl, it should really stop this
chattering IMHO.  See #221790.

Sven



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

Bug#494468: lower the severity?

[Sven Joachim]

On 2008-09-09 10:27 +0200, Neil Williams wrote:

 The package supports a method of adding unsupported locales but that
 this method does not appear to have been used.

 Unless the submitter can demonstrate that the existing support is
 broken, I think this bug should be downgraded to normal.

 It seems reasonable to me that a package can drop configuration values
 that are unsupported by the package - especially if the package does
 have a way of extending support to meet particular needs.
 Unless /usr/locale/share/i18n/SUPPORTED can be shown to be broken, I
 don't see a bug here - except maybe a wishlist one for the maintainer
 script to explain what it has done or some comment in README.Debian
 about how to use /usr/locale/share/i18n/SUPPORTED (especially as that is
 a rather strange path - I was expecting /usr/share/locales/SUPPORTED or
 something similar).

For the record, the path is /usr/local/share/i18n/SUPPORTED (not
/usr/locale/...), and that seems perfectly reasonable, since you don't
want to edit files under /usr locally.

Sven



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#494468: lower the severity?

[Sven Joachim]

On 2008-09-09 11:09 +0200, Neil Williams wrote:

 On Tue, 2008-09-09 at 11:03 +0200, Sven Joachim wrote:
 For the record, the path is /usr/local/share/i18n/SUPPORTED (not
 /usr/locale/...), and that seems perfectly reasonable, since you don't
 want to edit files under /usr locally.

 In that case, the bug is a documentation bug for /etc/locale.gen which
 contains:

 # This file lists locales that you wish to have built. You can find a list
 # of valid supported locales at /usr/share/i18n/SUPPORTED, and you can add
 # user defined locales to /usr/locale/share/i18n/SUPPORTED. If you change
 # this file, you need to rerun locale-gen.

 (That is where I looked for the path).

Ah, I looked at /usr/share/doc/locales/README.Debian instead,
/etc/locale.gen is generated by the locales postinst which has a typo.

 /usr/local/share is fine, I agree - just that this bug may turn out to
 be little more than a typo.

 Would you agree that the severity should be lowered?

Assuming that the method described in
/usr/share/doc/locales/README.Debian works, yes.  But I haven't tested
that, nor am I the bug submitter or in any way responsible for the
package.

Sven



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421173: nscd: depends on removed libssp0 package

[Sven Joachim]

Package: nscd 
Version: 2.5-4
Severity: grave

Your package depends on libssp0 which is no longer present in the
latest gcc-4.1 upload (4.1.2-4).  Following Matthias Klose's advice
in http://bugs.debian.org/421162, I report this as a bug against your
package.  Please examine whether a binNMU solves this problem or if
you have to change the dependencies.


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

Kernel: Linux 2.6.20.7
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#418893: glibc-doc-reference: Please upload version 2.5 to unstable

[Sven Joachim]

Package: glibc-doc-reference
Version: 2.3.6-1
Severity: wishlist

Hello,

could you please upload a new debian version matching glibc 2.5 to
unstable?  It's already in experimental.


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

Kernel: Linux 2.6.20.6
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#361048: locales: locale settings lost after upgrade

[Sven Joachim]

Package: locales
Version: 2.3.6-5
Severity: normal

When upgrading to version 2.3.6-5, the locale settings were moved from
/etc/environment to /etc/default/locale.  Since I had LANG=de_DE in
/etc/environment, but not set it in my ~/.bash{_profile,rc} scripts, I
found that my window manager and other programs suddenly started
started speaking English rather than German.  Is /etc/default/locale
actually read by any programs (other than the new update-locale command)?


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.32
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages locales depends on:
ii  debconf [debconf-2.0] 1.4.72 Debian configuration management sy
ii  libc6 [glibc-2.3.6-2] 2.3.6-5GNU C Library: Shared libraries an

locales recommends no packages.

-- debconf information:
* locales/default_environment_locale: de_DE
* locales/locales_to_be_generated: [EMAIL PROTECTED] ISO-8859-15, de_DE 
ISO-8859-1, de_DE.UTF-8 UTF-8, [EMAIL PROTECTED] UTF-8




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#228486: Should this bug be closed?

[Sven Joachim]

As the transliteration of the german quotes in non-UTF-8 german locales
has been fixed in version 2.3.5-12 of the glibc package, it seems this
bug should be considered closed, too.

What is your opinion, Helge?

Regards,
Sven





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]