Package: libc6
Version: 2.19-1
Severity: normal
The check for services affected by an upgrade does not consider the package
architecture. So it restarts the 64bit sshd for a 32bit libc upgrade. This
is uneccessarily disruptive to the system.
MfG
Goswin
-- System Information:
Debian
Package: libc6
Version: 2.18-7
Severity: normal
File: /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
Hi,
I want to mmap a large file to 0x1 because the data contains
pointers and was originally at that offset. Mapping somewhere else and
relocating all the pointers is impossible. Unfortunately on
Jonathan Nieder jrnie...@gmail.com writes:
severity 658278 wishlist
tags 658278 + moreinfo
quit
Goswin von Brederlow wrote:
It has a different interpreter in its elf section. Ld.so could check
that to determine wether the elf file is one it should care about.
A common use case
reopen 658278
thanks
Aurelien Jarno aurel...@aurel32.net writes:
On Wed, Feb 01, 2012 at 07:47:29PM +0100, Goswin von Brederlow wrote:
Package: libc6
Version: 2.13-21
Severity: normal
File: /lib64/ld-linux-x86-64.so.2
Running ld.so with the wrong kind of file segfaults:
mrvn@frosties
Package: libc6
Version: 2.13-21
Severity: normal
File: /lib64/ld-linux-x86-64.so.2
Running ld.so with the wrong kind of file segfaults:
mrvn@frosties:~% /lib64/ld-linux-x86-64.so.2 /usr/lib/klibc/bin/ls
zsh: segmentation fault /lib64/ld-linux-x86-64.so.2 /usr/lib/klibc/bin/ls
MfG
Package: libc6
Version: 2.11.2-13
Severity: wishlist
File: /lib/librt.so.1
Hi,
creating a POSIX shared memory object raises the same sorts of security
issues as opening a tempfile, like name collisions.
For templates there is the mkstemp(char *template) function that
handles all those issues in
Bastian Blank wa...@debian.org writes:
On Mon, Aug 03, 2009 at 11:38:32AM +0200, Aurelien Jarno wrote:
Bastian Blank a écrit :
What happens if someone install libc-bin without a new libc6 then?
Forgot about that variant before as it is not forbidden by deps now.
If it is not the same
Cyril Brulebois k...@debian.org writes:
Goswin von Brederlow goswin-...@web.de (03/08/2009):
Does it break aptitude too?
I think that people involved in serious things like multiarch and glibc
might appreciate your staying quiet at some point given the quite huge
mess you initially created
Henning Glawe gla...@debian.org writes:
On Wed, Jul 29, 2009 at 11:09:32AM -0500, Manoj Srivastava wrote:
My first thought was Err. Won't moving all the shared libs into
a different location kinda screw things up? And then I looked, and
found
,
| ==
clone 535153 -1
reassign 535153 libc6-i386
reassign -1 wine
retitle -1 wine must Pre-Depends: libc6-i386 (= 2.9-18)
thanks
This has nothing to do with ia32-apt-get but purely with the
libc6-i386 lib32 transition.
libwine_1.0.1-1_amd64.deb had its files in /usr/lib/wine
libwine_1.1.22-1_amd64.deb
Matthias Klose d...@debian.org writes:
Goswin von Brederlow schrieb:
Hi,
small update to the bug report.
The libc6-i386 package screwed up the transition by forgetting to
delete the /lib32 and /usr/lib32 in preinst. So on upgrades all files
remain under /emul/ia32-linux/ and the only
Hi,
after talking it through on irc Clint Adams decided to ignore the
current broken transition introduced in libc6-i386 2.9-14 and to do it
right in 2.9-18. So far only fakeroot, gnu-efi and gcc-4.4 have
uploaded a new version placing files in /usr/lib32 while all the
others still block updates.
Guillem Jover [EMAIL PROTECTED] writes:
tags 403216 - patch
thanks
On Fri, 2006-12-15 at 13:26:41 +0100, Goswin von Brederlow wrote:
Package: dpkg-dev
Version: 1.13.24
Severity: critical
File: /usr/bin/dpkg-shlibdeps
Tags: patch
Er, there's not patch in here... and I think the proposed
Aurelien Jarno [EMAIL PROTECTED] writes:
Goswin von Brederlow a écrit :
What do you mean by smooth transition? Could you explain to others
what do you have in mind, it seems you have your own view on how to
implement and how to do the transition to multiarch.
My plan is to provide
reopen 388489
thanks
Aurelien Jarno [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
Aurelien Jarno [EMAIL PROTECTED] writes:
Debian Bug Tracking System a écrit :
retitle -1 libc6-i386: Missing /etc.ld.so.conf.d/i486-linux-gnu.conf
There is no need for such a file. ld.so natively
reopen 388489
severity wishlist
thanks
Aurelien Jarno [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
reopen 388489
thanks
Aurelien Jarno [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
Aurelien Jarno [EMAIL PROTECTED] writes:
Debian Bug Tracking System a écrit :
retitle
reopen 388489
thanks
Aurelien Jarno [EMAIL PROTECTED] writes:
Debian Bug Tracking System a écrit :
retitle -1 libc6-i386: Missing /etc.ld.so.conf.d/i486-linux-gnu.conf
There is no need for such a file. ld.so natively looks on all
directories of bi (or tri)-arches directories. If you need to
Steve Langasek [EMAIL PROTECTED] writes:
severity 387446 normal
thanks
On Thu, Sep 14, 2006 at 02:05:01PM +0200, Goswin von Brederlow wrote:
I set this to serious because it sort of violates a MUST directive in the
FHS:
This is a known deviation from the FHS on amd64, and not one
Aurelien Jarno [EMAIL PROTECTED] writes:
On Thu, Sep 14, 2006 at 01:28:24PM -0700, Steve Langasek wrote:
severity 387446 normal
thanks
On Thu, Sep 14, 2006 at 02:05:01PM +0200, Goswin von Brederlow wrote:
I set this to serious because it sort of violates a MUST directive in the
FHS
@@
+glibc (2.3.6.ds1-4a0.ql.0.1) unstable; urgency=low
+
+ * sysdeps/amd64.mk: Set libc_slibdir /lib64 and libc_libdir to /usr/lib64
+ * rules.d/build.mk: on amd64 rename debian/tmp-libc/lib64 to lib
+and debian/tmp-libc/usr/lib64 to lib
+
+ -- Goswin von Brederlow [EMAIL PROTECTED] Mon, 11
Aurelien Jarno [EMAIL PROTECTED] writes:
Hi all,
After a discussion with Joey Hess and later with Frans Pop at Debconf
6, we have decided that it could be a good idea to have a udeb glibc
built with -Os.
I have made a few tests, mainly on i386 and amd64, and also on all
architectures but
Aurelien Jarno [EMAIL PROTECTED] writes:
My intention is to seperate out 32bit stuff in lib and 64bit stuff in
lib64 so that they comply with the FHS for each seperate package and
can possibly be resorted into multiarch dirs by a conversion
script. In this case the right thing to do is also
Aurelien Jarno [EMAIL PROTECTED] writes:
Currently the (/usr)/lib64 - /lib symlink is shipped in the libc6
package. Goswin von Brederlow asked for this link to be created in the
postinst instead, so that packages could install files in both
(/usr)/lib and (/usr)/lib64 directories.
I have
Andreas Jochens [EMAIL PROTECTED] writes:
Hello Aurelien,
On 06-May-19 04:15, Aurelien Jarno wrote:
[Ccing: amd64 and dpkg developers as they are concerned by this subject]
Currently the (/usr)/lib64 - /lib symlink is shipped in the libc6
package. Goswin von Brederlow asked for this link
Junichi Uekawa [EMAIL PROTECTED] writes:
Hi,
I'm not suggesting splitting the dirs. Just the way the link is setup.
I'm suggesting creating it in the maintainer scripts instead of the
data.tar.gz so packages that do ship files in (/usr)/lib64 don't make
libc6 unupgradable.
On
Aurelien Jarno [EMAIL PROTECTED] writes:
severity 367962 wishlist
thanks
Goswin Brederlow wrote:
Package: libc6
Version: 2.3.6-7
Severity: normal
Hi,
Currently the libc6 package on amd64 ships a symlink from /lib64 to
/lib (and /usr/lib64). While the symlink is needed for things to work
Steve Langasek [EMAIL PROTECTED] writes:
Now, the ia32-libs maintainers *could* include a non-NPTL build of glibc in
ia32-libs, and then you could use LD_ASSUME_KERNEL=2.4.1 to force the use of
this backwards-compatible glibc with the [EMAIL PROTECTED] symbol; but given
that even the i386
Pierre Habouzit [EMAIL PROTECTED] writes:
Le Mar 11 Avril 2006 11:05, Goswin von Brederlow a écrit :
I'm assuming libc6 depends on libc-bin and libc-bin depends on libc6
here. The former is needed to always pull in libc-bin on upgrades and
the later is needed to ensure the minimum version
Pierre Habouzit [EMAIL PROTECTED] writes:
Le Lun 10 Avril 2006 19:41, Aurelien Jarno a écrit :
Anthony Towns a écrit :
Hi,
This is a reject of the new -bin packages (both of them).
The issues with the -bin package are that it may cause upgrade
problems, both in that upgrading from
Forwarding to debian-glibc.
Please don't CC debian-devel on replies.
MfG
Goswin
Luo Yong [EMAIL PROTECTED] writes:
Here's some problem occured when I cross compiling glibc.
==
In file included from ../nptl/sysdeps/unix/sysv/linux/libc-lowlevellock.c:21:
Steve Langasek [EMAIL PROTECTED] writes:
On Tue, Apr 11, 2006 at 11:51:26AM +0200, Pierre Habouzit wrote:
Le Mar 11 Avril 2006 11:05, Goswin von Brederlow a écrit :
I'm assuming libc6 depends on libc-bin and libc-bin depends on libc6
here. The former is needed to always pull in libc-bin
Julien Danjou [EMAIL PROTECTED] writes:
Please note that this issue is only available for i386 arch.
available?
Do you mean the fix is only for i386 or the problem only exists on
i386?
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
Aurelien Jarno [EMAIL PROTECTED] writes:
Goswin von Brederlow a écrit :
Aurelien Jarno [EMAIL PROTECTED] writes:
Note also that the other architectures does not encode the ABI name in
32-bit or 64-bit packages. I mean that the package is not called for
example libi386c-dev and the libgcc
Aurelien Jarno [EMAIL PROTECTED] writes:
Note also that the other architectures does not encode the ABI name in
32-bit or 64-bit packages. I mean that the package is not called for
example libi386c-dev and the libgcc package is called lib32gcc1-dev and
not libi386gcc1-dev.
On the other hand
Package: glibc
Severity: wishlist
Hi,
the libc6 and libc6-dev packages contain binaries as well as the shared libs.
This makes it impossible for future soname changes to coexist. While this
might not be a big concern for libc6 it also affects the multiarch plans.
The libc6:i386 and libc6:amd64
diff -u glibc-2.3.2.ds1/debian/changelog glibc-2.3.2.ds1/debian/changelog
--- glibc-2.3.2.ds1/debian/changelog
+++ glibc-2.3.2.ds1/debian/changelog
@@ -1,3 +1,14 @@
+glibc (2.3.2.ds1-22.0.0.1.mrvn) unstable; urgency=low
+
+ * Goswin von Brederlow [EMAIL PROTECTED]
+
+- debian/patches/amd64-TLS
Ups.
Sorry, I got the totaly wrong bug.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi,
due to the BTS being down it processed my mails in the wrong order
(the patch + explanation before the reassign).
This is now a glibc bug, please see the bug log for details.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
Hi,
while working with apt-ftparchive on amd64 it repeadatly
deadlocks. After some debugging here is what I found happens:
apt-ftparchive calls gzip with stdout to a pipe
apt-ftparchive reads some data from the pipe till it has enough
apt-ftparchive sends SIGINT
apt-ftparchive reads blocking
GOTO Masanori [EMAIL PROTECTED] writes:
At Wed, 02 Mar 2005 19:50:19 +0100,
Goswin von Brederlow wrote:
Can your problem be fixed to define O_NOATIME in lvm2 or
linux-kernel-headers package?
Regards,
-- gotom
I assigned the bug is to both. The headers because they have the bug
GOTO Masanori [EMAIL PROTECTED] writes:
At Wed, 9 Mar 2005 20:09:49 +,
Alasdair G Kergon wrote:
On Wed, Mar 09, 2005 at 06:49:07AM +0100, Goswin von Brederlow wrote:
The bug still remains but with lvm2 working around it it becomes
wishlist. I still think this should be fixed for sarge
GOTO Masanori [EMAIL PROTECTED] writes:
At Mon, 28 Feb 2005 03:48:00 +0100,
Goswin von Brederlow wrote:
Bastian's patch is just a workaround around the bug not its solution.
...So why did you submit this bug as severity: critical assigned to
linux-kernel-header? What the real solution
GOTO Masanori [EMAIL PROTECTED] writes:
At Sat, 26 Feb 2005 14:40:33 +0100,
Goswin Brederlow wrote:
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-17
Severity: critical
File: linux-kernel-header
Justification: breaks the whole system
Hi,
when one tries to run pvmove or
Kurt Roeckx [EMAIL PROTECTED] writes:
On Sun, Dec 05, 2004 at 06:14:24PM +0100, Santiago Vila wrote:
On Sun, 5 Dec 2004, Kurt Roeckx wrote:
On Sun, Dec 05, 2004 at 04:39:06PM +0100, Santiago Vila wrote:
Could you please provide details about the problem of having the
symlinks in
Santiago Vila [EMAIL PROTECTED] writes:
On Sat, 4 Dec 2004, Andreas Jochens wrote:
However, I had severe problems with 'glibc' upgrades when the '/lib64'
symlink was created by 'glibc' instead of 'base-files'.
Basically, everything stopped working during the upgrade because
the '/lib64'
GOTO Masanori [EMAIL PROTECTED] writes:
At Thu, 2 Dec 2004 12:37:23 +0100 (CET),
Santiago Vila wrote:
On Wed, 1 Dec 2004, Goswin von Brederlow wrote:
Conclusion:
- I would like to see those links in sarge (for amd64 only, no change
for other archs) since they are currently
GOTO Masanori [EMAIL PROTECTED] writes:
BTW, I concerned gcc multilib + gcc 3.4 support. This may be not
happened in sarge. I wait to put the modification of #252720 until
the request is come. If we want to release sarge soon, and if we want
to put amd64 into sarge, then it's good idea to
GOTO Masanori [EMAIL PROTECTED] writes:
BTW, I concerned gcc multilib + gcc 3.4 support. This may be not
happened in sarge. I wait to put the modification of #252720 until
the request is come. If we want to release sarge soon, and if we want
to put amd64 into sarge, then it's good idea to
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Wed, Jun 02, 2004 at 07:43:11PM +, Goswin von Brederlow wrote:
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15.amd64.1.0.1
Severity: normal
File: /usr/include/asm/system.h
Hi,
the asm/system.h file fails because LOCK_PREFIX
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Fri, Jun 04, 2004 at 03:59:37PM +0200, Goswin von Brederlow wrote:
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Wed, Jun 02, 2004 at 07:43:11PM +, Goswin von Brederlow wrote:
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Wed, Jun 02, 2004 at 07:43:11PM +, Goswin von Brederlow wrote:
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15.amd64.1.0.1
Severity: normal
File: /usr/include/asm/system.h
Hi,
the asm/system.h file fails because LOCK_PREFIX
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Fri, Jun 04, 2004 at 03:59:37PM +0200, Goswin von Brederlow wrote:
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Wed, Jun 02, 2004 at 07:43:11PM +, Goswin von Brederlow wrote:
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15.amd64.1.0.1
Severity: normal
File: /usr/include/asm/system.h
Hi,
the asm/system.h file fails because LOCK_PREFIX is undefined. On i386 this
is set by
#include linux/bitops.h /* for LOCK_PREFIX */
on amd64 it is set directly in
LaMont Jones [EMAIL PROTECTED] writes:
On Mon, May 10, 2004 at 11:04:24AM -0600, LaMont Jones wrote:
And that patch wasn't included in the last MU because I wasn't sure how
that would affect the other 10 architectures, and there were already lots
and lots of changes in the MU.
Well, that
Martin Michlmayr [EMAIL PROTECTED] writes:
* Thiemo Seufer [EMAIL PROTECTED] [2004-05-10 09:26]:
util-linux and raidtools are listed as RC bugs. Martin can probably
provide a longer list of such packages.
There were about 10-15 packages, including:
sg3-utils
tct
raidtools
Martin Michlmayr [EMAIL PROTECTED] writes:
* Thiemo Seufer [EMAIL PROTECTED] [2004-05-10 09:26]:
util-linux and raidtools are listed as RC bugs. Martin can probably
provide a longer list of such packages.
There were about 10-15 packages, including:
sg3-utils
tct
raidtools
Hi,
I'm forwarding this to debian-amd64 since I'm not working on debians
amd64 anymore since the DAM rejected me.
Can anyone still reproduce the df bug below?
MfG
Goswin
GOTO Masanori [EMAIL PROTECTED] writes:
At 10 Dec 2003 09:38:42 +0100,
Goswin von Brederlow wrote:
I still see
Mark Horn [EMAIL PROTECTED] writes:
On Sun, Apr 25, 2004 at 10:44:14PM +0900, GOTO Masanori wrote:
Goswin von Brederlow proposed the below pattern in #241395:
kernel_rev=$(uname -r | sed 's/\([0-9]*\.[0-9]*\.\)\([0-9]*\)\(.*\)/\2/')
I'm experiencing the problem as well because I have
Hi,
I'm forwarding this to debian-amd64 since I'm not working on debians
amd64 anymore since the DAM rejected me.
Can anyone still reproduce the df bug below?
MfG
Goswin
GOTO Masanori [EMAIL PROTECTED] writes:
At 10 Dec 2003 09:38:42 +0100,
Goswin von Brederlow wrote:
I still see
Mark Horn [EMAIL PROTECTED] writes:
On Sun, Apr 25, 2004 at 10:44:14PM +0900, GOTO Masanori wrote:
Goswin von Brederlow proposed the below pattern in #241395:
kernel_rev=$(uname -r | sed
's/\([0-9]*\.[0-9]*\.\)\([0-9]*\)\(.*\)/\2/')
I'm experiencing the problem as well because I have
GOTO Masanori [EMAIL PROTECTED] writes:
At Mon, 12 Apr 2004 23:28:07 +0900,
GOTO Masanori wrote:
At 03 Apr 2004 00:39:01 +0200,
Goswin von Brederlow wrote:
There are various ways to fix this situation, one example:
kernel_rev=$(uname -r | awk -F '[.-]' '{print $3}' | sed
's
GOTO Masanori [EMAIL PROTECTED] writes:
At Mon, 12 Apr 2004 23:28:07 +0900,
GOTO Masanori wrote:
At 03 Apr 2004 00:39:01 +0200,
Goswin von Brederlow wrote:
There are various ways to fix this situation, one example:
kernel_rev=$(uname -r | awk -F '[.-]' '{print $3}' | sed
's
GOTO Masanori [EMAIL PROTECTED] writes:
At Thu, 01 Apr 2004 07:10:50 +0200,
Goswin Brederlow wrote:
running cdebootstrap I see the following error:
O: /var/lib/dpkg/tmp.ci/preinst: line 184: [: 23dual: integer expression expected
...
% uname -r
2.4.23dual
You didn't use
Hi,
I still see this bug on my system here:
[EMAIL PROTECTED]:~% df
Filesystem 1K-blocks Used Available Use% Mounted on
df: `/': Invalid argument
df: `/proc': Invalid argument
df: `/boot': Invalid argument
df: `/dev/pts': Invalid argument
[EMAIL PROTECTED]:~% uname -a
Linux
Hi,
On Monday 28 April 2003 05:51, GOTO Masanori wrote:
Well, that's right. BTW, I still wonder how to support IA32 binaries.
You're planning to support x86-64 native package with this patch for
the present?
No, this patch is meant to bring i386/amd64 to the point where s390 and
sparc
Hi,
I still see this bug on my system here:
[EMAIL PROTECTED]:~% df
Filesystem 1K-blocks Used Available Use% Mounted on
df: `/': Invalid argument
df: `/proc': Invalid argument
df: `/boot': Invalid argument
df: `/dev/pts': Invalid argument
[EMAIL PROTECTED]:~% uname -a
Linux
Hi,
On Monday 28 April 2003 05:51, GOTO Masanori wrote:
Well, that's right. BTW, I still wonder how to support IA32 binaries.
You're planning to support x86-64 native package with this patch for
the present?
No, this patch is meant to bring i386/amd64 to the point where s390 and
sparc
Hi,
some more redefinitions:
g++ -DP_LINUX -ffunction-sections -fdata-sections -D_REENTRANT -Wall
-DP_USE_PRAGMA -g -D_DEBUG -DPMEMORY_CHECK=1 -DPHAS_TEMPLATES
-I/usr/include/ptlib/unix -I/usr/include/pwlib -DPTRACING
-I/home/mrvn/build/retry/openh323/openh323-1.12.2/include -DHAS_IXJ
Hi,
some more redefinitions:
g++ -DP_LINUX -ffunction-sections -fdata-sections -D_REENTRANT -Wall -DP_USE_PRAGMA
-g -D_DEBUG -DPMEMORY_CHECK=1 -DPHAS_TEMPLATES -I/usr/include/ptlib/unix
-I/usr/include/pwlib -DPTRACING
-I/home/mrvn/build/retry/openh323/openh323-1.12.2/include -DHAS_IXJ
Hi,
here is a patch that makes linux/time.h work alongside with time.h for
userspace inclusion.
I include time.h for userspace and don't redefine some structures. A
problem might be that some of the elements of the structures have
different names in time.h I think. The case I had (openh323) only
Hi,
here is a patch that makes linux/time.h work alongside with time.h for
userspace inclusion.
I include time.h for userspace and don't redefine some structures. A
problem might be that some of the elements of the structures have
different names in time.h I think. The case I had (openh323) only
71 matches
Mail list logo
