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 Relea
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 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.
&g
reopen 658278
thanks
Aurelien Jarno 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
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
Goswi
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
Cyril Brulebois writes:
> Goswin von Brederlow (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. But
Bastian Blank 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 major vers
Henning Glawe 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
>>
>> ,
>> | ==> /etc/ld.so.conf.d/x86_64-li
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
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.
Matthias Klose 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
>>
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:
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 multiarc
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:
>>>>
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-
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
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 seri
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 kno
.ds1/debian/changelog
@@ -1,3 +1,11 @@
+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 Brede
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
> architect
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.
>
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
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
>> pac
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 (/u
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 f
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 i38
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
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
>> > her
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:
> ../nptl/sysdeps/uni
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
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". Troub
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 pack
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
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 pa
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
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]
MIN_KERNEL_SUPPORTED = 2.6.0
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]>
+
+
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 from
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
>> > wi
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
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 t
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 t
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
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
>> th
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
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 ide
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 ide
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:
>> >
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:
>> >
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Wed, Jun 02, 2004 at 07:43:11PM +0000, 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
>>
&g
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Wed, Jun 02, 2004 at 07:43:11PM +0000, 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
>>
&g
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 /* for LOCK_PREFIX */
on amd64 it is set directly in asm/system.h but only i
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 /* for LOCK_PREFIX */
on amd64 it is set directly in asm/system.h but only i
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.
>
> Wel
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.
>
> Wel
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
> raidtoo
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
> raidtoo
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/'
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 Brede
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/')
>
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 Brede
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:
>> > >
>&
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:
>> > >
>&
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
>
> Y
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 an
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 an
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 opte
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 opte
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 -DHAS
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 -DHAS
Hi,
here is a patch that makes linux/time.h work alongside with time.h for
userspace inclusion.
I include 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
needed
Hi,
here is a patch that makes linux/time.h work alongside with time.h for
userspace inclusion.
I include 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
needed
Hi,
I compiled glibc 2.3.2-9 on m68k and noticd that some selftests failed
during build. I'm not familiar with glibc builds so I'm not sure if
this is normal on m68k (like gcc failing some tests) or indicates a
serious error.
You can look at the build log and sources at:
rsync://mrvn.homeip.net/
74 matches
Mail list logo
