Bug#752527: Upgrading libc6:i386 on amd64 restarts services
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 Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages libc6:i386 depends on: ii libgcc1 1:4.9.0-1 Versions of packages libc6:i386 recommends: pn libc6-i686 none Versions of packages libc6:i386 suggests: ii debconf [debconf-2.0] 1.5.53 pn glibc-doc none ii locales2.19-1 ii locales-all [locales] 2.19-1 -- debconf information excluded -- 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/20140624135719.31646.32959.reportbug@frosties.localnet
Bug#749122: ld.so crashes when sections are placed at different addresses
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 amd64
binaries are normaly mapped at 0x0040 and 0x0060a000 onwards,
conflicting with mapping the file. So I tried to link my binary to be
at a different address. But that makes ld.so crash with SIGSEGV or
SIGILL.
--
echo 'int main() { return 0; }' | gcc-4.8
-Wl,--section-start=.interp=0x7000 -x c -
gdb ./a.out
Program received signal SIGSEGV, Segmentation fault.
dl_main (phdr=phdr@entry=0x6fe00040, phnum=phnum@entry=8,
user_entry=user_entry@entry=0x7fffe3c8, auxv=optimized out)
at rtld.c:1169
1169rtld.c: No such file or directory.
(gdb) bt
#0 dl_main (phdr=phdr@entry=0x6fe00040, phnum=phnum@entry=8,
user_entry=user_entry@entry=0x7fffe3c8, auxv=optimized out)
at rtld.c:1169
#1 0x77df2215 in _dl_sysdep_start (
start_argptr=start_argptr@entry=0x7fffe480,
dl_main=dl_main@entry=0x77dde670 dl_main) at ../elf/dl-sysdep.c:249
#2 0x77de19f6 in _dl_start_final (arg=0x7fffe480) at rtld.c:332
#3 _dl_start (arg=0x7fffe480) at rtld.c:558
#4 0x77dde188 in _start () from /lib64/ld-linux-x86-64.so.2
#5 0x0001 in ?? ()
#6 0x7fffe6fd in ?? ()
#7 0x in ?? ()
--
echo 'int main() { return 0; }' | gcc-4.8 -Wl,--section-start=.interp=0x4
-x c -
gdb ./a.out
During startup program terminated with signal SIGKILL, Killed.
(gdb) bt
No stack.
--
Surprisingly the following works again:
echo 'int main() { return 0; }' | gcc-4.8
-Wl,--section-start=.interp=0x7200 -x c -
The difference seems to be where the section headers are placed in the
output file.
Working: Start of section headers: 2528 (bytes into file)
Crashing: Start of section headers: 2099168 (bytes into file)
MfG
Goswin
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6:amd64 depends on:
ii libgcc1 1:4.9.0-1
libc6:amd64 recommends no packages.
Versions of packages libc6:amd64 suggests:
ii debconf [debconf-2.0] 1.5.53
pn glibc-doc none
ii locales2.18-5
-- debconf information excluded
--
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/20140524102323.13933.81951.reportbug@frosties.localnet
Bug#658278: ld.so segfaults on wrong input
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 is testing updated versions of ld.so by running binaries explicitly using the ld.so binary. I don't see how your proposed enhancement is consistent with that. The interpreter listed in the elf binary would still match /lib64/ld-linux-x86-64.so.2 (or whatever it is on the arch) even if you explicitly call an ld.so from a different location. My suggestion isn't to match against the location the ld.so currently holds but against the location the ld.so is supposed to be in, where it would install to. A segfault is never correct behaviour and needs to be fixed in ld.so. If my program is built against one DSO and the caller uses LD_PRELOAD or LD_LIBRARY_PATH to replace it with something completely different, I'd expect segfaults from time to time (due to incompatible struct layouts, for example). In those cases the binary segfaults and that is unavoidable. But in this case the ld.so itself crashes. However, maybe it is avoidable. Often that kind of misconfiguration gets caught by other checks, like the following: foo: symbol lookup error: foo: undefined symbol: some_symbol Before veering too far in that direction, what is your use case? Was something broken by this? Maybe there is a simpler way to accomplish it. Nothing specific. We stumbled across it trying to fix a remote system after an accident with rm -rf /. MfG Goswin -- 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/87d39otkm8.fsf@frosties.localnet
Bug#658278: ld.so segfaults on wrong input
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:~% /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 It's not the wrong file type: $file /usr/lib/klibc/bin/ls /usr/lib/klibc/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked (uses shared libs), stripped It's an ELF file, but given it has a different ABI just doesn't work with /lib64/ld-linux-x86-64.so.2. It's hardly the fault of the libc. 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 segfault is never correct behaviour and needs to be fixed in ld.so. MfG Goswin -- 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/87ty31ej8b.fsf@frosties.localnet
Bug#658278: ld.so segfaults on wrong input
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 Goswin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.13-21 ii libgcc1 1:4.6.2-5 libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.41 ii glibc-doc none ii locales2.13-21 -- debconf information excluded -- 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/20120201184729.7158.97119.reportbug@frosties.localnet
Bug#620887: Please add a shm_mkstemp() function
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 a safe and easy to use manner. For POSIX share memory objects there should be an equivalent: int shm_mkstemp(char *template); The shm_mkstemp() function generates a unique temporary filename from template, creates and opens the POSIX shared memory object, and returns an open file descriptor for the object MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (666, 'unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-debian-xen-1 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.11.2-13 Embedded GNU C Library: Binaries ii libgcc1 1:4.5.2-6 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.35 Debian configuration management sy pn glibc-doc none (no description available) ii locales 2.11.2-5 Embedded GNU C Library: National L -- debconf information excluded -- 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/20110404213302.30757.38940.reportbug@frosties.localnet
Re: Please test eglibc 2.9-23+multiarch.2
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 major version, it will probably break, I'll add a conflict to fix that, but I fear we are going to have the same problem with apt again... Yep. So I'm also out of options. The question is, how badly will it break the binaries in the package. Bastian Does it break aptitude too? MfG Goswin -- 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.2
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. But maybe that's just me. Mraw, KiBi. What mess would that be? The question is valid. Other packages with verry similar relationship loops (like libc6-i386 and lib32stdc++6) break in apt but not in aptitude nor dpkg when going from some old versions to current versions. MfG Goswin -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Introduction to multiarch: What maintainers must do
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 , | == /etc/ld.so.conf.d/x86_64-linux-gnu.conf == | # Multiarch support | /lib/x86_64-linux-gnu | /usr/lib/x86_64-linux-gnu | __ dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf | libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf ` side remark: somehow I miss /usr/local/lib/x86_64-linux-gnu in this list; is this intentionally excluded or simply forgotten? --- libc6: /etc/ld.so.conf.d/libc.conf --- # libc default configuration /usr/local/lib So where do we put /usr/local/lib/x86_64-linux-gnu now? Eglibc maintainers, what do you think? MfG Goswin -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#535153: libc6: breaks wine upon upgrade, should have Breaks: wine
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 has its files in /usr/lib32/wine Updating wine before libc6-i386 will put files in /emul/ia32-linux/usr/lib/wine and then libc6-i386 removes the /usr/lib32 link and breaks wine (as has happened to the reportee). libc6-i386 therefore breaks an already installed wine. On the other hand libwine makes older libc6-i386 unupgradeable by shipping /usr/lib32/ which is a link in older libc6-i386. Further like all the other transitioning packages wine must make sure the libc6-i386 preinst is executed before wine is unpacked so files in /usr/lib32/wine actualy are placed in /usr/lib32/wine and not /emul/ia32-linux/usr/lib/wine and subsequently lost when libc6-i386 preinst runs. Wine (any deb that contains /usr/lib32) therefore must Pre-Depends: libc6-i386 (= 2.9-18). MfG Goswin -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#533767: Missing Pre-Depends: libc6-i386 (= 2.9-17)
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 thing that changes is the way dpkg sees them. Nice transition :-/ So you don't need a Pre-Depends after all. But lib32gcc1 still breaks upgrades of libc6-i386 ( 2.9-14). You should conflict, break or depend there. There is nothing special about lib32gcc1, so this has to be changed in all lib32* packages. Any reason this is only filed for lib32gcc1? Just because it has already been uploaded with /usr/lib32 and I have it installed. Made me notice it. MfG Goswin -- 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 update
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. So there is a high chance nobody (important :) has yet installed the borken version. For those that haven't yet looked into the matter here is the situation in a few words: On amd64 and ia64 32bit libraries have been placed in /emul/ia32-linux/lib and /emul/ia32-linux/usr/lib for historic reasons. /lib32 and /usr/lib32 had been linked to the respective lib dirs in /emul/ia32-linux. For space used on / reasons and for compliance with the FHS it has now been decided to place 32bit libraries in /lib32 and /usr/lib32 directly. libc6-i386 2.9-14 made this change but failed to take into account that dpkg will not replace symlinks with directories but preserves them. So here is what needs to happen. In libc6-i386 in preinst the following must be done: if [ $(readlink /lib32) = /emul/ia32-linux/lib ]; then rm /lib32 fi if [ $(readlink /usr/lib32) = /emul/ia32-linux/usr/lib ]; then rm /usr/lib32 fi All other packages on the other hand need to ensure they are unpacked after libc6-i386 preinst was run, that means adding: Pre-Depends: libc6-i386 (= 2.9-18) This includes the 3 sources that have already uploaded. As for the transition itself: Files previously placed in /emul/ia32-linux/lib must now be placed in /lib32 and files previously placed in /emul/ia32-linux/usr/lib must now be placed in /usr/lib32. MfG Goswin -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#388489: Bug#403216: dpkg-shlibdeps: Fails to check /emul/ia32-linux/[usr/]lib
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 fix is wrong. dpkg-shlibdeps sets my @librarypaths = qw( /lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64 ); to include the 32bit libraries on ia64 and amd64. But packages install their libraries in /emul/ia32-linux/[usr/]lib to which [/usr]/lib is a link. The problem now is that dpkg will not find the package for a library under [/usr]/lib32/ as it was installed under a different path. This causes dpkg-shlibdeps to not find a package for 32bit libraries and no shlibs file. In the end the packages will lack the neccessary depends to the 32bit libraries used in the package. It could be argued that the handling of this biarch stuff is a mess, but anyway. This was fixed in the past when we gave dpkg-shlibdeps support to handle /lib/ldconfig/ symlinks. Now it's gone, so the proper fix is for the package providing such libs in such nasty paths to add a file under /etc/ld.so.conf.d with those, and for dpkg-shlibdeps to read those files. I'll implement that tomorrow or the day after (I'm traveling today). regards, guillem That requires that libc6-i386 or libc6-i386-dev does contain the /etc/ld.so.conf.d/i486-linux-gnu.conf file. Which it does not. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388489 I'm CCing the bug so this use case is documented there also. Note that 388489 was reduced to wishlist since it lacked serious use. That should probably be raised to RC level again if you go this way. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388489: Processed: Cloning this bug
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 an environment where packages can already switch
to multiarch and can be used as is (see fakeroot below) or with the
help of a simple apt/dpkg-deb wrapper even though some slow moving
packages like glibc neccessarily are behind on converting. Making
libc6-i386 behave just like libc6:i386 means that we don't have to
stop everything till glibc is converted.
Until now the plan to transition to multiarch is the following:
- apply patch to binutils
- apply patch to gcc
The multiarch includes are already searched by gcc.
When I move /usr/lib32/libc.{a,so} to /usr/lib/i486-linux-gnu and
patch binutils then gcc -m32 works just fine. Without binutils patch
it says /usr/bin/ld: cannot find -lc. Doesn't even need a gcc
recompile.
What patch is missing?
- split-out binaries from libc6
and move libnss* and gconv to multiarch dirs.
all those steps could be done in parallel
- implement multiarch in dpkg.
That can be done in parallel too. And it can be tested with simple
libs like zlib without the need to have glibc fully ready.
Then you can install libc6:i386 on an amd64 system. No need to make an
other change, as libc6:i386 provide
Every other library can also be changed to multiarch in
parallel. Provided ld looks there.
A prime candidate for this is fakeroot which comes with libs for
multiple archs. Since nothing gets compiled against those libs the
binutils bug doesn't matter there. The ideal package to test and use
the runtime stuff for multiarch. It only needs support from the ld,
meaning libc6-i386 on amd64.
The
ld.so.conf.d/i486-linux-gnu.conf files only logical place is in the
libc6[-i386] packages and the multiarch libc6 oni386 already has to
conflict with libc6-i386 on amd64 (reverse for libc6-amd64). If
ld.so.conf.d/i486-linux-gnu.conf is in any other package then that
just further complicates the dependencies and conflicts in the future.
Why do you want to add a conflict there? There is no need now. But if
you add the file, there will be a need to do that.
Both libc6:i386 and libc6-i386 provide the ld. Without proper
conflicts, replaces, provides you get an overwrite error. So I don't
add a conflict where there isn't already is one.
Why do you want for libc6-i386 servers as a transition package while
simply installing libc6:i386 will work?
Because we don't have a (usable) libc6:i386 in the archive yet and
with the goal of multiarch it is not there to stay. So it is
temporary, transitional. That's just what it is.
The current libc6:i386 does not look in the multiarch dirs for its
plugins so it can not be converted by the apt/dpkg-deb wrapper
automatically. It needs to be patched and recompiled for that. Most
other packages can be converted on the fly. The closer libc6-i386
mimics a multiarch libc6:i386 the better people can test multiarch
with the wrapper or convert their own libs.
I see 3 scenarios where I would consider this bug fixed:
1) you add the file
From my point of view this will complexify the transition to
multiarch, because you will need to add conflicts.
The ld already neccessitates the conflict so no change there.
2) ia32-libs takes the libc6-i386 package
I already explained I am not in favor of that.
And I prefer it that way too as long as it doesn't hinder me.
3) binutils adds the patch from #369064 and obsoletes the
/etc/ld.so.conf.d/arch-os-gnu.conf files
I don't see how it would fix the problem. This patch only add the
native multiarch directory (ie i486-linux-gnu on i386,
x86_64-linux-gnu on amd64, etc...) to the search path. Not the 32- or
64-bit counterpart one. Well I haven't looked in deep in your latest
patch...
Please read that bug again. It adds the native multiarch dir to every
output format. The native dir for that format. Elf 32bit i486 gets
i486-linux-gnu as dir. Elf 64bit amd64 gets x86_64-linux-gnu as
dir. Exactly as we want it. It is easy to miss because binutils still
uses i386 so /usr/lib/i386-linux-gnu is used. The second patch
corrects that too.
In fact this is better than ld.so.conf.d since only linking 32bit code
would look in i486-linux-gnu and only 64bit code in x86_64-linux-gnu.
No '/usr/bin/ld: skipping incompatible
/usr/lib/x86_64-linux-gnu/libc.so when searching for -lc' warnings.
MfG
Goswin
Re: Processed: Cloning this bug
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 looks on all
directories of bi (or tri)-arches directories. If you need to be
convinced just run: strings /sbin/ldconfig | grep ^/lib
Clising the bug
Binutils doesn't. And in some cases binutils looks at ld.so.conf and
It does. Well it was not the case on amd64, but it has been fixed two
months ago in version 2.17-2 (see bug#369052).
I am closing the bug, please only reopen the bug if you have a
testcase to show what you claim.
Then what is /etc/ld.so.conf.d/x86_64-linux-gnu.conf for? If 32bit
multiarch support doesn't need the conffile then 64bit multiarch would
need it even less, being the native bit-ness and all. Think about that
for a second.
Meanwhile here is your testcase step by step:
Create missing link so we can link (pending fix in ia32-libs):
% ln -s /usr/lib32/libfreetype.so.6 /usr/lib32/libfreetype.so
Test /usr/lib32 setup:
% cat foo.c
extern int FT_Init_FreeType(void);
int main(void) { return FT_Init_FreeType(); }
% gcc -m32 -o foo foo.c -lfreetype
Test multiarch:
% mkdir /usr/lib/i486-linux-gnu
% mv /usr/lib32/libz.* /usr/lib/i486-linux-gnu
% gcc -m32 -o foo foo.c -lfreetype
/usr/bin/ld: warning: libz.so.1, needed by
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib32/libfreetype.so, not found
(try using -rpath or -rpath-link)
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib32/libfreetype.so: undefined
reference to `inflate'
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib32/libfreetype.so: undefined
reference to `inflateReset'
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib32/libfreetype.so: undefined
reference to `inflateEnd'
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib32/libfreetype.so: undefined
reference to `inflateInit2_'
collect2: ld returned 1 exit status
Fix it:
% echo /usr/lib/i486-linux-gnu /etc/ld.so.conf.d/i486-linux-gnu.conf
% gcc -m32 -o foo foo.c -lfreetype
thus ld.so.conf.d/*.
Or what is the point of the ld.so.conf.d files at all?
The purpose of the ld.so.conf.d files is to provide an easy way to add
search directories for some packages (eg atlas), which is a lot easier
than modifying the ld.so.conf directly.
It is also a way for future multiarch support to add a search path,
hence the /etc.ld.so.conf.d/(host-triplet).conf in libc6. But it has
nothing to do with bi-arch or tri-arch which are directly handled in
the toolchain.
Which is exactly what I am asking for. That
/etc.ld.so.conf.d/(host-triplet).conf is missing in libc6-i386.
Notice that I do ask for that multiarch host triplet file
specificaly. Not for any bi/tri-arch support. I believed requesting
that file would be clear enough indication that the multiarch dirs are
ment but you seem to have misunderstood that completly.
The libc6 on amd64 ships /etc/ld.so.conf.d/x86_64-linux-gnu.conf
% cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
The libc6-i386 should ship /etc/ld.so.conf.d/i486-linux-gnu.conf
% cat /etc/ld.so.conf.d/i486-linux-gnu.conf
# Multiarch support
/lib/i486-linux-gnu
/usr/lib/i486-linux-gnu
That is all I'm asking.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388489: Processed: Cloning this bug
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 -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 be
convinced just run: strings /sbin/ldconfig | grep ^/lib
Clising the bug
Binutils doesn't. And in some cases binutils looks at ld.so.conf and
It does. Well it was not the case on amd64, but it has been fixed two
months ago in version 2.17-2 (see bug#369052).
I am closing the bug, please only reopen the bug if you have a
testcase to show what you claim.
Then what is /etc/ld.so.conf.d/x86_64-linux-gnu.conf for? If 32bit
multiarch support doesn't need the conffile then 64bit multiarch would
need it even less, being the native bit-ness and all. Think about that
for a second.
Meanwhile here is your testcase step by step:
Create missing link so we can link (pending fix in ia32-libs):
% ln -s /usr/lib32/libfreetype.so.6 /usr/lib32/libfreetype.so
Test /usr/lib32 setup:
% cat foo.c
extern int FT_Init_FreeType(void);
int main(void) { return FT_Init_FreeType(); }
% gcc -m32 -o foo foo.c -lfreetype
So this works. Multiarch not being a requirement for Etch, I fail to
see why the severity of this bug is serious.
Because the submitter reported it as such and nobody has adjusted it
since then.
Test multiarch:
% mkdir /usr/lib/i486-linux-gnu
% mv /usr/lib32/libz.* /usr/lib/i486-linux-gnu
Wrong. The purpose of multiarch is to remove bi-arch packages. With
multiarch if you want to install a 32-bit glibc on amd64, install the
package from i386. Not libc6-i386.
We can't lay an egg because we have no chicken and we can't breed a
chicken because we have no eggs. The purpose of libc6-i386 is to cover
the interim time till multiarch and it isn't to strictly deadlock
everything at bi-arch.
Remeber that we already did have the libc6 package from i386 in use in
ia32-libs (and still have). You wanted to have a special libc6-i386
package for amd64 and since you maintain glibc we respected that. We
can add libc6 back to the list of packages for amd64 if you don't want
to provide a transitional package that mimics multiarch. That would be
a one line change.
The ld.so.conf.d/i486-linux-gnu.conf file is essential so multiarch
directories can be used already and to allow a smooth transition. The
ld.so.conf.d/i486-linux-gnu.conf files only logical place is in the
libc6[-i386] packages and the multiarch libc6 oni386 already has to
conflict with libc6-i386 on amd64 (reverse for libc6-amd64). If
ld.so.conf.d/i486-linux-gnu.conf is in any other package then that
just further complicates the dependencies and conflicts in the future.
I see 3 scenarios where I would consider this bug fixed:
1) you add the file
2) ia32-libs takes the libc6-i386 package
3) binutils adds the patch from #369064 and obsoletes the
/etc/ld.so.conf.d/arch-os-gnu.conf files
MfG
Goswin
Re: Processed: Cloning this bug
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 be convinced just run: strings /sbin/ldconfig | grep ^/lib Clising the bug Binutils doesn't. And in some cases binutils looks at ld.so.conf and thus ld.so.conf.d/*. Or what is the point of the ld.so.conf.d files at all? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
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 that is considered release-critical for etch. It is an unneccessary one. That probably means that a change for this would not be accepted into etch, since fiddling library paths may have unexpected side-effects and glibc is already frozen. The fiddling only changes the compiled in path. But the lib64 link makes that irelevant for Debian. Both locations end in the same file. The risk less than some user linking or bind mounting /usr/lib to another location and that is already supported and deemed save. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
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: Your changes also violate the FHS, as the system libraries should be in /lib. Two things. First it doesn't move the libc6 out of /lib. Secondly not for amd64. That is a special case made so i386 binaries can stay the same on amd64. Only Debian has deviated from that setup as vorlon said in his next sentence: This is a known deviation from the FHS on amd64, and not one that is considered release-critical for etch. There is currently no way to do a plain amd64 distribution without violating the FHS. So I don't really want to make changes that probably have side effects just for violating the FHS another way. The FHS sees amd64 as a 64bit extension of i386, just like ppc, sparc, mips, s390 have their 64bit extensions. In that sense a plain amd64 distribution would mean that you have no libraries in /lib or /usr/lib since you have no 32bit libs at all. If that violates something in the FHS then too bad. But does that mean we should just violate more? My opinion is that the FHS should be changed. Unfortunately nobody seems to read the FHS mailing list... Multiarch dirs will not happen for etch. Maybe some day the proposal will be adopted. But Debian not implementing it doesn't really help the case. That probably means that a change for this would not be accepted into etch, since fiddling library paths may have unexpected side-effects and glibc is already frozen. Agreed. Can we at least put it into sid so you can see that nothing changes? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Package: glibc Version: 2.3.6.ds1-4 Severity: serious Tags: patch Hi, the standard location for libraries on amd64 is (/usr)/lib64 but glibc is build for (/usr)/lib. In most cases this makes no difference but there are some: 1) Compatibility with other linux When you copy debians libc6 or static binaries to other linux systems then the location of plugins changes from /usr/lib to /usr/lib64 (/usr/lib/gconv/ becomes /usr/lib64/gconv/). 2) automatic conversion for multiarch The same thing happens here. The converter for multiarch deletes the (/usr)/lib64 link and changes (/usr)/lib to (/usr)/lib64 so the library does not conflict with its 32bit counterpart. Again /usr/lib/gconv/ becomes /usr/lib64/gconv/ and so on. The attached patch is a simple solution to the problem. Glibc on amd64 gets compiled for (/usr)/lib64 as the FHS/LSB specify for amd64 but before packaging it gets renamed to (/usr)/lib and (later) the lib64-lib links are put in place. This way it works everywhere. -- I set this to serious because it sort of violates a MUST directive in the FHS: http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html | /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) | | The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place | 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries | in /lib. It does not specificaly mention plugins but I hope you agree the same rational applies there for libc6. -- MfG Goswin -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-frosties-2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) diff -u glibc-2.3.6.ds1/debian/rules.d/build.mk glibc-2.3.6.ds1/debian/rules.d/build.mk --- glibc-2.3.6.ds1/debian/rules.d/build.mk +++ glibc-2.3.6.ds1/debian/rules.d/build.mk @@ -124,6 +124,15 @@ tar zcf $(CURDIR)/debian/locales-all/usr/lib/locales-all/supported.tar.gz -C $(CURDIR)/debian/tmp-libc/usr/lib/locale .; \ fi + # Move lib64 to lib on amd64 + if [ $(curpass) = libc ] [ $(DEB_HOST_ARCH) = amd64 ]; then \ + find debian/tmp-$(curpass); \ + mkdir -p debian/tmp-$(curpass)/lib debian/tmp-$(curpass)/usr/lib; \ + mv debian/tmp-$(curpass)/lib64/* debian/tmp-$(curpass)/lib; \ + mv debian/tmp-$(curpass)/usr/lib64/* debian/tmp-$(curpass)/usr/lib; \ + rmdir debian/tmp-$(curpass)/lib64 debian/tmp-$(curpass)/usr/lib64; \ + fi + # Remove ld.so from optimized libraries if [ $(curpass) != libc ] [ $(call xx,configure_build) = $(call xx,configure_target) ]; then \ rm -f debian/tmp-$(curpass)/$(call xx,slibdir)/ld*.so* ; \ diff -u glibc-2.3.6.ds1/debian/sysdeps/amd64.mk glibc-2.3.6.ds1/debian/sysdeps/amd64.mk --- glibc-2.3.6.ds1/debian/sysdeps/amd64.mk +++ glibc-2.3.6.ds1/debian/sysdeps/amd64.mk @@ -2,8 +2,8 @@ libc_MIN_KERNEL_SUPPORTED = 2.6.0 libc_add-ons = nptl $(add-ons) libc_extra_cflags = -O3 -g1 -libc_slibdir = /lib -libc_libdir = /usr/lib +libc_slibdir = /lib64 +libc_libdir = /usr/lib64 libc_rtlddir = /lib64 # /lib64 and /usr/lib64 are provided by glibc instead base-files: #259302. diff -u glibc-2.3.6.ds1/debian/changelog glibc-2.3.6.ds1/debian/changelog --- glibc-2.3.6.ds1/debian/changelog +++ glibc-2.3.6.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 Brederlow [EMAIL PROTECTED] Mon, 11 Sep 2006 16:45:24 +0200 + glibc (2.3.6.ds1-4) unstable; urgency=low [ Aurelien Jarno ]
Re: glibc udebs built with -Os
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 m68k. All tests were ok. The tests include comparing the test logs with the normal version, running small tests programs with threads, and for all architectures but s390, ia64 and alpha (I don't own those machines) a boot with this glibc. This made me very enthusiastic. This has been implemented partially in glibc 2.3.6-10 and more fully in glibc 2.3.6-11. However we start facing some problems. We have build failures on s390 and ia64 that were not present on the test builds. That let me think building the glibc with -Os is maybe not really stable. What it is sure, is that it is not supported upstream. On hppa, it is only possible to build the udeb with -Os with gcc-4.1. Also on i386 we've reached the biggest size possible for a build log (75MB). That's why I am now thinking of removing that from the current glibc and postpone that for later (probably etch+1), but I'd like to know what other people think, also people from d-i to know if the gain in space is really important for etch. Bye, Aurelien Will/Would that inlcude a -Os libc6-pic package for use with mklibs when building the initial ramdisk for D-I? Size probably matters much more there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
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 the more helpfull one. But we will never be able to split lib and lib64 dirs on the filesystem if packages don't use them in the data.tar.gz first. So you in short you mean you want to allow, even temporarily to have both 32-bit and 64-bit libraries in /lib? That sucks. Aeh, no. As long as lib and lib64 are the same destination 32bit has to stay out of there. But once we get all 64bit stuff into lib64 (or a majority) a split can be atempted. I don't know where you have seen resistance from the glibc. We have uploaded a package ready from multiarch (with libc6 binaries splitted into libc-bin). But it has been rejected by the ftp masters. After seeing to much resistance, I have decided to stop on that. But I have always claimed that patches are welcomes, *if* you get an agreement from the ftpmasters and the release team. I don't want to spend my time on that. So please don't say we are making resistance. True. You have helped there. But even you were restistant to using the multiarch dirs (the x86_64-linux-gnu dirs). I'm talking about the dirs specificaly and not the wider multiarch iossues. happen even partialy for etch. Using lib64 now will make it much easier to change the dir to the multiarch name later if it is done with a proper abstraction (put the libdir in variable so only one place needs changing). Multiarch won't come in one big wave so now I'm trying to do it in many little steps. Well I don't see how it would help the transition to multiarch. The library path in multiarch is different, so the package would have to be changed again anyway. Because packages will be prepared to handle different libdirs. All that needs to be changed is the name of the libdir and not the handling for different names. For most packages this involves adding *.in files for debhelper (e.g. libfoobar.install) files. So here are my concerns about that: - I don't really want to add something specific to amd64 in postinst. But ok, that's not an argument. - If you can install files in /lib64, the files will end up in /lib. And dpkg won't know anything about them. dpkg -S and other tools won't work correctly. - If you have two packages providing the same files in /lib and /lib64, then the files will be overwritten without warning. This is not acceptable. That is a good point. I will have to test that. Not so much that you don't get a warning on overwrite (many systems have the default --force-overwrite option in dpkg.conf anyway) but it could be that upgrading from /lib to /lib64 in a package might loose the files (/lib64/foobar gets installed, then /lib/foobar gets removed). That's why I am not in favor of that, but I am not able to take the decision. I will send a mail to debian-devel to ask about more opinions. Bye, Aurelien MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
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 concerns about that: - I don't really want to add something specific to amd64 in postinst. But ok, that's not an argument. - I am not sure that creating the link in postinst will work. Creating it in preinst looks safer to me. yes. - If you can install files in (/usr)/lib64, the files will end up in (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other tools won't work correctly. Local admins are already allowed to convert directories into links, e.g. to move parts ot the directory tree to another disk. We had problems with that for the (/usr)/lib32 link used on amd64 and for example dpkg-shlibs was afaik patched to deal with it correctly. dpkg -S isn't but that could/should be fixed. - If you have two packages providing the same files in (/usr)/lib and (/usr)/lib64, then the files will be overwritten without warning. This is IMHO not acceptable. Could you please give me your opinion on that, so that I can take a decision? Thanks, Aurelien MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
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 to be created in the postinst instead, so that packages could install files in both (/usr)/lib and (/usr)/lib64 directories. Could you please give me your opinion on that, so that I can take a decision? please do not change the status quo regarding the lib64 symlinks. During the porting of Debian to amd64 quite a few alternatives regarding the lib64 issue were discussed and tested. The biarch approach with /usr/lib and /usr/lib64 as two different directories failed badly. 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. I have concerns about that: - I don't really want to add something specific to amd64 in postinst. But ok, that's not an argument. - I am not sure that creating the link in postinst will work. Creating it in preinst looks safer to me. - If you can install files in (/usr)/lib64, the files will end up in (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other tools won't work correctly. - If you have two packages providing the same files in (/usr)/lib and (/usr)/lib64, then the files will be overwritten without warning. This is IMHO not acceptable. I share these concerns. The current policy which requires all packages to install native amd64 libraries in /usr/lib is simple and sane. This should not be changed. Anything which makes it easier to violate this simple policy will lead to a mixed usage of /usr/lib and /usr/lib64 and consequently to problems which could be difficult to disentangle later. The goal would be to actualy get everything into (/usr)/lib64 while intermittendly allowing a mixed usage. That would allow for FHS compliance for 32bit libraries shiped in lib32gcc1, lib32stdc++*, lib32asound, ia32-libs and more to come. This is just my personal opinion. Regards Andreas Jochens MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
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 debootstrap install, libc6 postinst isn't actually ran that early, and if this change is made, probably require some hacks within debootstrap/cdebootstrap. regards, junichi Yes, preinst (or postinst) would have to mv /lib64/* /lib/; /lib/ld-linux.so.* ln -s lib /lib64 and the same for /usr/lib64. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
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 shipping it in the data.tar.gz makes it impossible for any package to put files into /lib64 or /usr/lib64 (as specified by FHS): If any package does so the next time libc6 gets updated you get an error similar to: dpkg: error processing foo1-1.0.deb (--install): trying to overwrite `/foo', which is also in package foo2 Instead of shipping the symlinks I suggest creating them in the preinst (if they don't exist) and shipping at least one file (/lib64/ld-2.3.2.so comes to mind) in /lib64 and /usr/lib64 to prevent dpkg from removing the links on updates. Why would we want this? With that change packages can be patched (or un-patched) to use the FHS compliant lib64 dirs. Libraries and plugins are then in a different directory than on i386 alowing for automatic conversion of amd64 packages to an i386 based bi-arch system. Also if enough packages get changed to /lib64 the symlinks could be droped and bugs filed against the remaining packages. Updating to a non symlinks way might be tricky but at least new installs would get the right dirs. I don't really understand here. When I tried to swap the directory and the symlink, I have been told, that we don't have to do that, as Swaping around wouldn't have worked since then libc6 would be uninstallable if any package has a file in /lib or /usr/lib. Using only /lib64 and /usr/lib64 would break too many existing packages so that isn't an option either. For now the only option is to not ship a symlink (be that lib - lib64 or lib64 - lib) but still create one in preinst. Debian will never be compliant with the FHS. So why do you wan't to be FHS compliant now? The system (64 bit only) as such is compliant since libc6 provides the link. Each package is not since they dump 64bit libraries in /lib and /usr/lib. 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 the more helpfull one. But we will never be able to split lib and lib64 dirs on the filesystem if packages don't use them in the data.tar.gz first. At work we sell Debian based clusters with a 32/64bit biarch setup with automaticaly converted sarge packages but since both use /lib and /usr/lib anything with plugins can't work in both bit sizes. If packages can use /lib64 and /usr/lib64 I can send in patches for all of them and get them working for etch. Also upstream sources are using lib64 more and more and Debian has to patch it back to lib again. Every time some package upstream changes to lib64 the libc6 package becomes unupgradable because it tries to overwrite some packages /lib64 or /usr/lib64 directory with a symlink and the other package has to be fixed. I think 5 or 6 users have already encountered such a bug this year. I would have liked to go directly to multiarch dirs but resistance from people, including the glibc and gcc teams, made that unlikely to happen even partialy for etch. Using lib64 now will make it much easier to change the dir to the multiarch name later if it is done with a proper abstraction (put the libdir in variable so only one place needs changing). Multiarch won't come in one big wave so now I'm trying to do it in many little steps. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364698: [Debian-ia32-libs] Bug#364698: ia32-libs: GLIBC_2.0 is not defined (used to be)
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 port of etch isn't going to support these applications by default, I'm not sure I see the point... No, we can't. We don't provide any libc at all anymore. :) Glibc builds a 32bit libc6 for amd64 and ia32-libs has depended on it for the last few versions. If you need this ancient, broken errno variable then you have to stick with stable I guess. But it is out of our hands and in the hands of the glibc team. reassigning the bug there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc_2.3.6-6_i386.changes REJECTED
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 requirements as sepcified in libc6.shlibs. We don't want a new libc-bin with a too old libc6. right, but that makes a nasty circular dependency I thought we should avoid at any rate ? Shouldn't libc-bin rather conflicts with bad version of the libc ? I think that circle is unavoidable. Also consider what would happen if ldconfig does go missing. Wouldn't that just mean the new libc6 isn't in ld.so.cache and ld.so will search the library pathmanualy and still find it? libc6 preinst calls /usr/bin/ldd to know which ld_so is used on the system. that means that libc-bin has to be extracted *before* libc6 is. Though, that part seems to be quite brittle, and I assume we could use another tool than That wasn't mentioned in the mail, only ldconfig. I can't see why preinst would need to call ldd, after all the ld.so should be the same accross the arch and is hardcoded into every binary, including libc6 itself. Why isn't that probed during build time? Might be tricky on cross compiles but otherwise it is trivial. Will dpkg run both libc6.preinst and libc-bin.preinst before unpacking either of them or run preinst and unpack each of them in turn? Worst case it needs a /usr/lib/libc6/ldd.arch-os in libc6.deb and call that directly. else, you are right, the only thing we have to be sure, is that *a* libc-bin is extracted before libc6 postinst runs, and that should always be OK, since libc6 depends upon libc-bin. When doing a full upgrade (stable-unstable) could it happen that apt breaks the libc6-libc-bin depends cycle and put them into seperate dpkg calls? I don't remember how smart/stupid libapt was there. It might be best to add apt-get install libc6 libc-bin to the upgrade instructions. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc_2.3.6-6_i386.changes REJECTED
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 existing libc's may result in a broken system between the new libc6 being unpacked and the new libc-bin being installed (ldconfig not being available), and that when you have a new glibc from upstream, you may have problems with the new ldconfig (etc) requiring symbols from the new glibc, and ensuring they're installed correctly. I hardly see how that's possible, given that ldconfig is a static binary. and given the fact that libc6 Depends upon libc-bin, the later will be unpacked, and the new ldconfig will overwrite the older one, and *just work*. The only current problem is that libc-bin depends upon libc6, which is fixeable (making it Essential, or using apropriate dh_slibdeps exclude, to avoid that dependency). With that, libc-bin is assured to be unpacked first, and a valid ldconfig will always exist on the sytem. libc-bin beeing configured or not. Why should it matter in what oder libc6 and libc-bin are unpackagd? All cases should work fine: Case 1: libc6 (old) exists libc6 new is unpacked libc-bin is unpacked libc6 postinst runs ldconfig libc-bin postinst runs Case 2: libc6 (old) exists libc-bin in unpacked libc6 new in unpacked libc-bin postinst runs libc6 postinst runs ldconfig Case 3: (debootstrap run) libc6 is unpacked with dpkg -x libc-bin is unpacked with dpkg -x debootstrap chroots into the system ldconfig is run Case 4: libc6 and libc-bin exist libc6 is unpacked libc6 postinst runs (static) ldconfig libc-bin is unpacked libc-bin postinst runs Case 5: libc6 and libc-bin exist libc-bin is unpacked libc-bin postinst runs libc6 is unpacked libc6 postinst runs (static) ldconfig 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 requirements as sepcified in libc6.shlibs. We don't want a new libc-bin with a too old libc6. Also consider what would happen if ldconfig does go missing. Wouldn't that just mean the new libc6 isn't in ld.so.cache and ld.so will search the library pathmanualy and still find it? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: errors occured when compiling glibc
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/unix/sysv/linux/lowlevellock.c:29:conflicting type for '__111_lock_wait' ../nptl/sysdeps/unix/sysv/linux/lowlevellock.h:361:error:previous delaration of '__111_lock_wait' was here. == Could anybody tell me how to solve this? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc_2.3.6-6_i386.changes REJECTED
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 on upgrades and the later is needed to ensure the minimum version requirements as sepcified in libc6.shlibs. We don't want a new libc-bin with a too old libc6. right, but that makes a nasty circular dependency I thought we should avoid at any rate ? Shouldn't libc-bin rather conflicts with bad version of the libc ? No. Having libc-bin conflict with libc doesn't help you make sure libc-bin is pulled into the system, which is what you need. (There are no bad versions of libc here; there are versions that need libc-bin, and there are versions that don't, and you need some way to pull libc-bin in for those versions that do need it.) He ment: Package: libc6 Depends: libc-bin [pull in libc-bin] Package: libc-bin Conflicts: libc6 ( version from shlibs) Replaces: libc6 ( first split version) This would make sure a matching libc6 and libc-bin package gets installed as pair. But due to dpkgs long standing conflicts handling bug this does not prevent a downgrade of libc6 to a version unsuitable for libc-bin. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Xen and glibc
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? Contact [EMAIL PROTECTED]
Bug#341884: libc6: [mips] tri-arch support for mips mipsel
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 package is called lib32gcc1-dev and not libi386gcc1-dev. On the other hand libc6-amd64 and libc6-i486 are used. Just like libc6-mipsn32 and libc6-mipsn64 are used there. I was speaking about other packages such as lib32z1 or lib32gcc1. I was hinting that maybe it should be zlib1g-mipsn32 instead of lib32z1 and zlib1g-i486 and so on. The problem with tri-arch mips is that the architecture does not map 1:1 to abis as it does for other archs. MfG Goswin
Bug#341884: libc6: [mips] tri-arch support for mips mipsel
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 libc6-amd64 and libc6-i486 are used. The problem with tri-arch mips is that the architecture does not map 1:1 to abis as it does for other archs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330735: glibc: Binaries in library debs
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 packages would have file overlaps. Please split out the binaries into seperate libc6-bin and libc6-bin-dev packages. libc6: /sbin/ldconfig libc6: /usr/bin/ldd libc6: /usr/bin/iconv libc6: /usr/bin/zdump libc6: /usr/bin/rpcinfo libc6: /usr/bin/tzselect libc6: /usr/bin/getconf libc6: /usr/bin/getent libc6: /usr/bin/locale libc6: /usr/bin/localedef libc6: /usr/bin/catchsegv libc6: /usr/sbin/zic libc6: /usr/sbin/tzconfig libc6: /usr/sbin/iconvconfig libc6-dev: /usr/bin/gencat libc6-dev: /usr/bin/mtrace libc6-dev: /usr/bin/rpcgen MfG Goswin -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-rc5+skas3+acl Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Goswin von Brederlow] glibc: Patch for the TLS problem
Since the BTS is down a little lookahead of what is stuck:
---BeginMessage---
Package: glibc
Followup-For: Bug #317946
Hi,
I reassigned this bug to glibc after testing an old patch for the TLS
problem for Kurt Roeckx. I had to fix a few other things along the
way:
- debian/patches/amd64-TLS-problem.dpatch: try to fix TLS problem
- debain/rules: undo dpkg-architecture output changes
- debian/sysdeps/amd64.mk: use gcc-3.4
- debian/control: 'Build-Depends: gcc-3.4 [amd64]' to be sure
After build I tried to compile
int main(){return 0;}
with 'gcc -O2 -W -Wall -static -o foo foo.c' both with the old and new
packages. The old ones report the TLS problem while the new ones work.
MfG
Goswin
-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8-frosties-1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
--
diff -u glibc-2.3.2.ds1/debian/patches/00list
glibc-2.3.2.ds1/debian/patches/00list
--- glibc-2.3.2.ds1/debian/patches/00list
+++ glibc-2.3.2.ds1/debian/patches/00list
@@ -127,0 +128 @@
+amd64-TLS-problem
diff -u glibc-2.3.2.ds1/debian/sysdeps/amd64.mk
glibc-2.3.2.ds1/debian/sysdeps/amd64.mk
--- glibc-2.3.2.ds1/debian/sysdeps/amd64.mk
+++ glibc-2.3.2.ds1/debian/sysdeps/amd64.mk
@@ -1,5 +1,5 @@
-CC = gcc
-BUILD_CC = gcc
+CC = gcc-3.4
+BUILD_CC = gcc-3.4
# build libc with nptl instead of linuxthreads
libc_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]
+
+- debian/patches/amd64-TLS-problem.dpatch: try to fix TLS problem
+- debain/rules: undo dpkg-architecture output changes
+- debian/sysdeps/amd64.mk: use gcc-3.4
+- debian/control: 'Build-Depends: gcc-3.4 [amd64]' to be sure
+
+ -- Goswin von Brederlow [EMAIL PROTECTED] Sun, 17 Jul 2005 16:36:19 +0200
+
glibc (2.3.2.ds1-22) unstable; urgency=medium
* Daniel Jacobowitz [EMAIL PROTECTED]
diff -u glibc-2.3.2.ds1/debian/control glibc-2.3.2.ds1/debian/control
--- glibc-2.3.2.ds1/debian/control
+++ glibc-2.3.2.ds1/debian/control
@@ -1,7 +1,7 @@
Source: glibc
Section: libs
Priority: required
-Build-Depends: gettext (= 0.10.37-1), make (= 3.80-1), dpkg-dev (=
1.4.1.5), debianutils (= 1.13.1), tar (= 1.13.11), bzip2, texinfo (= 4.0),
linux-kernel-headers (= 2.5.999-test7-bk-9) [!hurd-i386], mig (= 1.3-2)
[hurd-i386], hurd-dev (= 20020608-1) [hurd-i386], gnumach-dev [hurd-i386],
texi2html, file, gcc-3.3 [!ia64] | gcc-3.4 [!ia64], gcc-3.3 (= 1:3.3.5-5)
[ia64] | gcc-3.4 (= 3.4.3-2) [ia64], autoconf, binutils (= 2.14.90.0.7-5),
sed (= 4.0.5-4), gawk, debhelper (= 4.1.76)
+Build-Depends: gettext (= 0.10.37-1), make (= 3.80-1), dpkg-dev (=
1.4.1.5), debianutils (= 1.13.1), tar (= 1.13.11), bzip2, texinfo (= 4.0),
linux-kernel-headers (= 2.5.999-test7-bk-9) [!hurd-i386], mig (= 1.3-2)
[hurd-i386], hurd-dev (= 20020608-1) [hurd-i386], gnumach-dev [hurd-i386],
texi2html, file, gcc-3.3 [!ia64] | gcc-3.4 [!ia64], gcc-3.3 (= 1:3.3.5-5)
[ia64] | gcc-3.4 (= 3.4.3-2) [ia64], autoconf, binutils (= 2.14.90.0.7-5),
sed (= 4.0.5-4), gawk, debhelper (= 4.1.76), gcc-3.4 [amd64]
Build-Depends-Indep: perl, po-debconf
Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org
Uploaders: Ben Collins [EMAIL PROTECTED], GOTO Masanori [EMAIL PROTECTED],
Philip Blundell [EMAIL PROTECTED], Jeff Bailey [EMAIL PROTECTED], Daniel
Jacobowitz [EMAIL PROTECTED]
diff -u glibc-2.3.2.ds1/debian/rules glibc-2.3.2.ds1/debian/rules
--- glibc-2.3.2.ds1/debian/rules
+++ glibc-2.3.2.ds1/debian/rules
@@ -48,6 +48,12 @@
DEB_BUILD_GNU_TYPE?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
DEB_BUILD_GNU_SYSTEM ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_SYSTEM)
+# Strip newly added -gnu
+DEB_HOST_GNU_TYPE := $(subst -gnu,,$(DEB_HOST_GNU_TYPE))
+DEB_HOST_GNU_SYSTEM := $(subst -gnu,,$(DEB_HOST_GNU_SYSTEM))
+DEB_BUILD_GNU_TYPE:= $(subst -gnu,,$(DEB_BUILD_GNU_TYPE))
+DEB_BUILD_GNU_SYSTEM := $(subst -gnu,,$(DEB_BUILD_GNU_SYSTEM))
+
DEB_HOST_GNU_CPU_ALT ?=
DEB_HOST_GNU_TYPE_ALT ?=
only in patch2:
unchanged:
--- glibc-2.3.2.ds1.orig/debian/patches/amd64-TLS-problem.dpatch
+++ glibc-2.3.2.ds1/debian/patches/amd64-TLS-problem.dpatch
@@ -0,0 +1,91 @@
+#! /bin/sh -e
+
+# All lines beginning with `# DP:' are a description of the patch.
+# DP: Description: * elf/Makefile (rtld-routines): Add dl-errno.
+# DP: ($(objpfx)librtld.map): Copy libc_pic.a to libc_pic.a, remove
+# DP: errno.os from libc_pic.a and use libc_rtld.a instead of
+# DP: libc_pic.a.
+# DP: ($(objpfx)librtld.mk): Match libc_rtld.a instead of libc_pic.a.
+# DP: Dpatch author: Goswin von Brederlow [EMAIL PROTECTED]
+# DP: Patch author: H.J. Lu [EMAIL PROTECTED]
+# DP: Upstream status:
+# DP: Status
Bug#318429: glibc: Patch for the TLS problem
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]
Bug#317946: glibc patch for TLS problems
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 [EMAIL PROTECTED]
Strange non dying of gzip on amd64
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 the pipe to flush it and now everything hangs with gzip not dying. At that point the FDs of both programs are as follows: /proc/31752/fd: (apt-ftparchive) total 9 lrwx-- 1 katie debadmin 64 May 1 17:10 0 - /dev/pts/7 lrwx-- 1 katie debadmin 64 May 1 17:10 1 - /dev/pts/7 lrwx-- 1 katie debadmin 64 May 1 17:06 2 - /dev/pts/7 l-wx-- 1 katie debadmin 64 May 1 17:10 3 - /dev/null lrwx-- 1 katie debadmin 64 May 1 17:10 4 - /org/amd64.debian.net/database/packages-amd64.db lr-x-- 1 katie debadmin 64 May 1 17:10 5 - /org/amd64.debian.net/database/dists/unstable_main_binary-amd64.list lr-x-- 1 katie debadmin 64 May 1 17:10 6 - /org/amd64.debian.net/ftp/debian/pool/main/a/abc2ps/abc2ps_1.3.3-3_amd64.deb lr-x-- 1 katie debadmin 64 May 1 17:10 8 - pipe:[1792790] /proc/31793/fd: (gzip) total 3 lr-x-- 1 katie debadmin 64 May 1 17:10 0 - /org/amd64.debian.net/ftp/debian/pool/main/a/abc2ps/abc2ps_1.3.3-3_amd64.deb l-wx-- 1 katie debadmin 64 May 1 17:10 1 - pipe:[1792790] lrwx-- 1 katie debadmin 64 May 1 17:06 2 - /dev/null And gzip has the following backtrace: (gdb) bt #0 0x2af442fd in __lll_mutex_lock_wait () from /lib/libc.so.6 #1 0x2b0a2550 in _IO_stdfile_1_lock () from /lib/libc.so.6 #2 0x0421 in ?? () #3 0x2aedc9c6 in save_for_backup () from /lib/libc.so.6 #4 0x00070008 in ?? () #5 0x00080008 in ?? () #6 0x00080008 in ?? () #7 0x00080008 in ?? () #8 0x00080008 in ?? () #9 0x2aab30fa in do_lookup_versioned () from /lib64/ld-linux-x86-64.so.2 #10 0x2aedbfce in _IO_flush_all_internal () from /lib/libc.so.6 #11 0x2aedc1fb in _IO_cleanup () from /lib/libc.so.6 #12 0x2ae98d97 in exit () from /lib/libc.so.6 #13 0x00404fe4 in do_exit (exitcode=1) at gzip.c:1833 #14 signal handler called #15 0x2aedbe81 in _IO_flush_all_lockp () from /lib/libc.so.6 #16 0x2aedbfce in _IO_flush_all_internal () from /lib/libc.so.6 #17 0x2aedc1fb in _IO_cleanup () from /lib/libc.so.6 #18 0x2ae98d97 in exit () from /lib/libc.so.6 #19 0x00404fe4 in do_exit (exitcode=0) at gzip.c:1833 #20 0x00402b6a in main (argc=2, argv=0x7c88) at gzip.c:640 (gdb) The exact same happens if apt-ftparchive closes the pipe first, then sends SIGINT and then calls waitpid. gzip never dies. [sidenote: kill -9 on gzip makes it continue] So we are know wondering if this could be a glibc problem or a kernel problem. Kernel is a 2.6.11.6 with vserver (apt-ftparchive inside vserver) and libc6 is 2.3.2.ds1-21. $ cat /proc/version Linux version 2.6.11.6-vs195-farm1.0 ([EMAIL PROTECTED]) (gcc-Version 3.3.5 (Debian 1:3.3.5-12)) #1 SMP Sat Apr 2 12:53:04 CEST 2005 Any help is welcome. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298488: Bug#297010: linux-kernel-header: O_NOATIME needed for lvm
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 and lvm because it can work around it (thereby reducing its severity to normal). OK. Bastian separated this bug report into #297010 and #298488. Ups, I hope I didn't reopen the wrong bug a few hours ago then. If I did feel free to reclose it. Should a bug reporter get a notice when a bug i cloned or merged? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297010: acknowledged by developer (Bug#297010: fixed in lvm2 2.01.04-3)
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 so documentation and implementation are in sync for stable. A similar problem happened before with O_DIRECT and was left unfixed for months. Somebody ought to address the root cause: why aren't the installed header files kept closely in step with the kernels? Because glibc package is under base freeze for sarge - and many packages depend on it under 11 official architectures. OTOH, why don't lvm2 package have O_NOATIME definition itself for a while? It has, hence the lowered priority now. However I possibly update another release for sarge: 2.3.2.ds1-21 (which may have O_NOATIME definition, plus some requests). Regards, -- gotom MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297010: linux-kernel-header: O_NOATIME needed for lvm
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 to fix this report? 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 and lvm because it can work around it (thereby reducing its severity to normal). If you don't think l-k-h oder libc6-dev should implement the O_NOATIME it documents then please reassign it to lvm2 alone with an explanation. That is your perogative as maintainer but I stand by my decision that it is a critical bug and both packages are involved. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297010: linux-kernel-header: O_NOATIME needed for lvm
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 lvsnapshot on / the lvm will deadlock itself due to atime updates on /dev/ being blocked while the LVM is locked. Sine any read/write access to / will be blocked the system breaks. To prevent this lvm uses O_NOATIME where available, which is still not the case in current linux-kernel-headers. I couldn't understand why this problem is occured. O_NOATIME was introduced in 2.6.7. Is the root of problem to upgrading lvm package? Bastian's patch adds only O_NOATIME flag - this means that lvm can fix using O_NOATIME in your new package. In other words, lvm is severity: critical, but glibc is not. lvm is kernel related package, so depending on libc6 header sometimes causes problems. The docs (man 2 open) document O_NOATIME but the headers are lacking behind in carrying the implementation. So you got stuck with it as primary package. Notice that lvm2 is secondary. If lvm adds a workaround the priority drops but you are still missing documented behaviour, behaviour the sarge kernel (2.6.8) has. Bastian's patch is just a workaround around the bug not its solution. So I recommend that lvm should use O_NOATIME definition in your package for a while. The while is getting realy long, I mentioned this issue several month ago already and it is still not fixed. Regards, -- gotom MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
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 glibc? Is it that glibc has a versioned Replaces: base-files and dpkg removes the symlink in base-files before installing the one from glibc, creating a big window during which /lib64 does not exist at all? glibc (libc6) does not replace base-files. Why should it? Because otherwise the upgrade from an already running amd64 system (which has a modified base-files containing the symlink) would result in dpkg complaining about a file conflict. A Replaces field would allow dpkg to move the ownership of the symlink from base-files to libc in a clean way. However, it there is a time window during which /lib64 does not exist at all it will not work that way. I've patched the latest glibc to to provide the symlink. This is what I get: apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages will be upgraded: libc6 libc6-dev 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/8813kB of archives. After unpacking 135kB of additional disk space will be used. Do you want to continue? [Y/n] y (Reading database ... 10369 files and directories currently installed.) Preparing to replace libc6-dev 2.3.2.ds1-18 (using .../libc6-dev_2.3.2.ds1-19_amd64.deb) ... Unpacking replacement libc6-dev ... Preparing to replace libc6 2.3.2.ds1-18 (using ..././libc6_2.3.2.ds1-19_amd64.deb) ... Unpacking replacement libc6 ... dpkg - warning, overriding problem because --force enabled: trying to overwrite `/lib64', which is also in package base-files Does libc6 replace base-files? Setting up libc6 (2.3.2.ds1-19) ... Current default timezone: 'Europe/Brussels'. Local time is now: Sun Dec 5 23:19:17 CET 2004. Universal Time is now: Sun Dec 5 22:19:17 UTC 2004. Run 'tzconfig' if you wish to change it. Setting up libc6-dev (2.3.2.ds1-19) ... (Note that is a patched 2.3.2.ds1-19, didn't change the version number yet.) At that point the /lib64 symlink it owned by the libc6 package. Now I just need to be sure how to package this properly so nobody has problems updating libc6 and base-files at the same time. Any hint welcome. Kurt I was thinking about that and noticed some problem. I haven't checked the docs or source yet so this is from memory: When dpkg updates base-files and libc6 at the same time (and even when base-files predepends on libc6) the following happens: - base-files and libc6 control.tar.gz is unpacked and preinst is run. - base-files and libc6 data.tar.gz each are unpacked and obsolete files are removed. The order can be either way and if base-files is first we are screwed. - libc6 is configured. - base-files is configured. So the problem is the second step. Is my memory right there or does dpkg first unpack all debs and only then remove obsolete files? I fear removing the /lib64 from base-files.list in preinst could be neccessary. Just till every amd64 user has updated. MfG Goswin PS: Can you put the libc6 on alioth sopmewhere. No point in rebuilding it again just to test some more. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
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' temporarily disappeared and the binaries could not find the dynamic linker anymore. If glibc, which contains all the essential libraries and it's in the best position to do it, have problems creating the symlinks, imagine the *huge* mess that might happen if we finally put the symlinks in base-files and we want to remove it later for multiarch support, considering that base-files and glibc do not have any sort of sync between them. That is my main objection for putting the symlinks in base-files. The problem is we already have it in base-files on every installed amd64 system. The problem isn't having it or changing it later but moving it between packages. Could you please provide details about the problem of having the symlinks in glibc? Is it that glibc has a versioned Replaces: base-files and dpkg removes the symlink in base-files before installing the one from glibc, creating a big window during which /lib64 does not exist at all? In such case I think it would be completely acceptable that the preinst simply manipulates /var/lib/dpkg/info/base-files.list to remove the /lib64 entry from it, so that the Replaces becomes innecessary. Urgs, that is a dirty hack. Also what preinst do you mean? base-files? IMHO at a minimum the base-files without the /lib64 link has to predepend on a libc6 with the link and libc6 might have to replace older base-files to avoid dpkg complaining about overwriting /lib64 (or is that unneccessary for links of dirs?). I believe dpkg should not have problems installing a symlink when the symlink already exists in the filesystem and does not belong to any package. Sure, it would be a hack, but if the symlink is in base-files, it could be that we need a much bigger hack to remove it later, or worse, it could be that we are in a dead-end and there is no possible hack for the multiarch transition. Iirc dpkg does never change a dir to symlink or symlink to dir in order to preserve the local admins choices (like moving /usr/lib to a different drive for space reasons). Maybe it is enough if base-files predepends on a libc6 with the link and nothing else. MfG Goswin PS: Since we are talking unreleased inofficial debs here without any long time not upgraded systems the base-file predepends could be amd64 only just until everyone has updated and could then be phased out. We probably don't need to burden sarge with that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
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 essential for amd64 (glibc relies on it). What package provides them is no that important. In base-files it is realy simple to do so. - If the links are split out of base-files into other debs and those don't make it to sarge I would still rather patch base-files for sarge amd64 before I touch anything else. It is the simplest place to put them. My conclusion: As the symlinks will not be there forever, it's glibc who relies on them, and there might be potential problems at the time of removing them if they are not in the same package as the dynamic linker or libc6, I consider the glibc package should be the one to manage the symlinks. Looking at the patch, there're two symlinks: /lib64 and /usr/X11R6/lib64. We don't touch /usr/X11R6 in libc6. 3: /lib, /usr/lib and /usr/X11R6/lib. The /lib64 - /lib link is essential for the ld to be found and as Santagio says glibc should take care of it. The other two links are more a convenience so less software has to be patched. Since glibc also puts things in /usr/lib it could take care of that link too. The X11R6 link could possibly come from X11 itself but currently it comes from the amd64 patched base-files. If you want to take care of all 3 links in glibc that would be fine. Andreas, is it nice to symlink from /lib to /lib64 ? I agree we have /lib64 on amd64. Regards, -- gotom Currently lib64 links to lib and reversing that link would mean rebuilding every library package because otherwise dpkg-shlibs won't work. It would mean patching every lib package to build for lib64 instead of the current lib to get correct *.la files and dpkgs *.files info. So please don't reverse that link, it would destroy everything we worked for. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#190399: Bug#246547: amd64 support for glibc 2.3.2.ds1-14
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 keep gcc 3.3, IMHO. What's the merit of pushing gcc 3.4 into sarge on amd64? Regards, -- gotom gcc3.4 has better amd64 support (mainly faster). A handfull of compiler ICE are fixed while a handfull of c++ incompatibilites will probably show up and cause FTBFS. The fixed and new bugs probably even out so the remaining argument would be speed. Starting with gcc-3.4 would also save the gcc 3.3 - 3.4 transition but the rest of debian will have to do that anyway so we save nothing. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#190399: Bug#246547: amd64 support for glibc 2.3.2.ds1-14
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 keep gcc 3.3, IMHO. What's the merit of pushing gcc 3.4 into sarge on amd64? Regards, -- gotom gcc3.4 has better amd64 support (mainly faster). A handfull of compiler ICE are fixed while a handfull of c++ incompatibilites will probably show up and cause FTBFS. The fixed and new bugs probably even out so the remaining argument would be speed. Starting with gcc-3.4 would also save the gcc 3.3 - 3.4 transition but the rest of debian will have to do that anyway so we save nothing. MfG Goswin
Bug#252338: /usr/include/asm/system.h: asm/system.h: missing include file on amd64
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 is undefined. On i386 this is set by #include linux/bitops.h /* for LOCK_PREFIX */ on amd64 it is set directly in asm/system.h but only inside #ifdef __KERNEL__, but it is used outside the ifdef. What is including asm/system.h? -- Daniel Jacobowitz Amiga-fdisk is doing so directly. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#252338: /usr/include/asm/system.h: asm/system.h: missing include file on amd64
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.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 asm/system.h but only inside #ifdef __KERNEL__, but it is used outside the ifdef. What is including asm/system.h? -- Daniel Jacobowitz Amiga-fdisk is doing so directly. For what reason? To get what? For no reason it seems. I filed a seperate bug about it since it causes amiga-fdisk to FTBFS on m68k. We do not support including arbitrary kernel headers. Some of the ones under linux/ are accepted as userspace interfaces. Others are included by glibc. But the reset we try not to fix for userspace use; copy out what you need. If any glibc or linux/ header includes it it should experience the same problem. If nothing does the file could be removed. If you know of something making legal use of asm/system.h I would be happy to test it. MfG Goswin PS: on m68k the same file fails with u8, u16 and u32 being undefined. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#252338: /usr/include/asm/system.h: asm/system.h: missing include file on amd64
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 is undefined. On i386 this is set by #include linux/bitops.h /* for LOCK_PREFIX */ on amd64 it is set directly in asm/system.h but only inside #ifdef __KERNEL__, but it is used outside the ifdef. What is including asm/system.h? -- Daniel Jacobowitz Amiga-fdisk is doing so directly. MfG Goswin
Bug#252338: /usr/include/asm/system.h: asm/system.h: missing include file on amd64
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.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 asm/system.h but only inside #ifdef __KERNEL__, but it is used outside the ifdef. What is including asm/system.h? -- Daniel Jacobowitz Amiga-fdisk is doing so directly. For what reason? To get what? For no reason it seems. I filed a seperate bug about it since it causes amiga-fdisk to FTBFS on m68k. We do not support including arbitrary kernel headers. Some of the ones under linux/ are accepted as userspace interfaces. Others are included by glibc. But the reset we try not to fix for userspace use; copy out what you need. If any glibc or linux/ header includes it it should experience the same problem. If nothing does the file could be removed. If you know of something making legal use of asm/system.h I would be happy to test it. MfG Goswin PS: on m68k the same file fails with u8, u16 and u32 being undefined.
Bug#252338: /usr/include/asm/system.h: asm/system.h: missing include file on amd64
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 asm/system.h but only inside #ifdef __KERNEL__, but it is used outside the ifdef. MfG Goswin -- System Information: Debian Release: testing/unstable Architecture: amd64 (x86_64) Kernel: Linux 2.6.5-amd64 Locale: LANG=C, LC_CTYPE=C -- no debconf information
Bug#234236: grave
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 and the fact that it's really a linux-kernel-headers bug, and that's where the fix belongs. lamont Its still better for util-linux to convert to 64bit file offset bits even though with a fixed LKH that would be just wishlist. MfG Goswin
Bug#234236: grave
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 atari-fdisk sleuthkit fdclone -- Martin Michlmayr [EMAIL PROTECTED] FYI util-linux has a patch ready to NMU in the BTS that uses the 64bit lseek instead of the 32bit llseek, thereby reducing the number of arguments and avoiding a syscall with 5 arguments. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#234236: grave
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 atari-fdisk sleuthkit fdclone -- Martin Michlmayr [EMAIL PROTECTED] FYI util-linux has a patch ready to NMU in the BTS that uses the 64bit lseek instead of the 32bit llseek, thereby reducing the number of arguments and avoiding a syscall with 5 arguments. MfG Goswin
Bug#218657: Still problems with df
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 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 opteron 2.6.0-test11 #1 SMP Mon Dec 8 11:31:17 CET 2003 x86_64 GNU/Linux [EMAIL PROTECTED]:~% cat /proc/version Linux version 2.6.0-test11 ([EMAIL PROTECTED]) (gcc version 3.3.2 20030908 (Debian prerelease)) #1 SMP Mon Dec 8 11:31:17 CET 2003 [EMAIL PROTECTED]:~% dpkg -l coreutils libc6 ii coreutils 5.0.91-2 The GNU core utilities ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries and Timezone Looking at fs/compat.c in 2.6.0-test11 I see the patch present in the bugreport was included. All it seems to do is change Bad address to Invalid argument. Older glibc, like the 2.3.2-7.biarch1 version used for debian-amd64 sarge, work fine though: ... PPS: I will compile a 2.4.23 kernel and do the same tests next time I reboot just for good measure. Is this bug still alive, Goswin? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#245643: libc6: problem with $kernel_ver in preinst
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 a customized kernel: $ uname -r 2.4.20mh04 Is there a workaround for this problem so that I can get libc6 installed? I'd like to manually modify the preinst script with the above kernel_rev line. It doesn't appear possible because dpkg extracts the preinst directly from the .deb. Is there a way to modify the preinst so that I can get past this problem? Thanks, - Mark Install libc6 (which fails) and then upgrade it (install again). Something like that should skip the test. [cdebootstrap fails first when installing libc6 but manages to get it installed properly at some stage in its run. Thats why I suggest the above.] MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218657: Still problems with df
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 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 opteron 2.6.0-test11 #1 SMP Mon Dec 8 11:31:17 CET 2003 x86_64 GNU/Linux [EMAIL PROTECTED]:~% cat /proc/version Linux version 2.6.0-test11 ([EMAIL PROTECTED]) (gcc version 3.3.2 20030908 (Debian prerelease)) #1 SMP Mon Dec 8 11:31:17 CET 2003 [EMAIL PROTECTED]:~% dpkg -l coreutils libc6 ii coreutils 5.0.91-2 The GNU core utilities ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries and Timezone Looking at fs/compat.c in 2.6.0-test11 I see the patch present in the bugreport was included. All it seems to do is change Bad address to Invalid argument. Older glibc, like the 2.3.2-7.biarch1 version used for debian-amd64 sarge, work fine though: ... PPS: I will compile a 2.4.23 kernel and do the same tests next time I reboot just for good measure. Is this bug still alive, Goswin? Regards, -- gotom
Bug#245643: libc6: problem with $kernel_ver in preinst
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 a customized kernel: $ uname -r 2.4.20mh04 Is there a workaround for this problem so that I can get libc6 installed? I'd like to manually modify the preinst script with the above kernel_rev line. It doesn't appear possible because dpkg extracts the preinst directly from the .deb. Is there a way to modify the preinst so that I can get past this problem? Thanks, - Mark Install libc6 (which fails) and then upgrade it (install again). Something like that should skip the test. [cdebootstrap fails first when installing libc6 but manages to get it installed properly at some stage in its run. Thats why I suggest the above.] MfG Goswin
Bug#241395: libc6: preinst fails for kernel 2.4.23dual
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/\([[:digit:]]*\).*/\1/' )
kernel_rev=$(uname -r | sed 's/\([0-9]*\.[0-9]*\.\)\([0-9]*\)\(.*\)/\2/')
Please don't use awk (see BTS for related bugs). awk requires a
Pre-Depends since its an alternative and mawk (provides awk) is not
even essential.
sed on the other hand is essential.
Thanks for your code, but I've put my version.
Using awk is no problem.
Ugh, I'm silly that I didn't check Bug#229461. Using awk is problem
for some users (Note that AJ and Colin did not think it's problematic.
I agreed with them, but in fact mawk is not essential).
Its not about users but about installing debian (be it real or for a
chroot). Using awk is a serious policy violation that just happens to
only matter when installing from scratch.
I think having the Debian Installer fail is problematic but thats just
me.
However, Jeff already put such code into libc.preinst:
if [ $1 != abort-upgrade ] [ `uname -s` = Linux ]
then
# Test to make sure z 255, in x.y.z-n form of kernel version
# Also make sure we don't trip on x.y.zFOO-n form
kernel_rev=$(uname -r | tr -- - . | cut -d. -f3 | tr -d [:alpha:])
That will fail with 2.4.25,foo but what the heck.
The problem with the code is that its missing a :
[EMAIL PROTECTED]:~$ uname -r | tr -- - . | cut -d. -f3 | tr -d [:alpha:]
23dual
[EMAIL PROTECTED]:~$ uname -r | tr -- - . | cut -d. -f3 | tr -d [:alpha:]
23
if [ $kernel_rev -ge 255 ]
then
echo WARNING: Your kernel version indicates a revision number
echo of 255 or greater. Glibc has a number of built in
echo assumptions that this revision number is less than 255.
echo If you\'ve built your own kernel, please make sure that any
echo custom version numbers are appended to the upstream
echo kernel number with a dash or some other delimiter.
exit 1
fi
And changelog said:
- debian/debhelper.in/libc.preinst: Don't use awk except in
upgrade mode. (Closes: #229461)
Also make sure that it doesn't trip on words being added to the
upstream revision number. Thanks to James Troup for
mentioning this.
Thanks to Bastian Blank [EMAIL PROTECTED] for the fix.
So it seems this #241395 is intentional behavior. But apparently the
current code is failed under 2.4.23dual kernel with message:
bash: [: : integer expression expected
It has to be fixed. I guess many user use 2.4.23dual and so on. So
go back to #229461, why should we ignore a version like 2.4.23dual?
Jeff, James?
I would like to permit 2.4.23dual and recognize as 2.4.23. I'll
adopt Goswin's code if no one objects.
Regards,
-- gotom
MfG
Goswin
PS: Please fix that so I can update my kernel (which means I loose the
testcase). :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241395: libc6: preinst fails for kernel 2.4.23dual
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/\([[:digit:]]*\).*/\1/' )
kernel_rev=$(uname -r | sed 's/\([0-9]*\.[0-9]*\.\)\([0-9]*\)\(.*\)/\2/')
Please don't use awk (see BTS for related bugs). awk requires a
Pre-Depends since its an alternative and mawk (provides awk) is not
even essential.
sed on the other hand is essential.
Thanks for your code, but I've put my version.
Using awk is no problem.
Ugh, I'm silly that I didn't check Bug#229461. Using awk is problem
for some users (Note that AJ and Colin did not think it's problematic.
I agreed with them, but in fact mawk is not essential).
Its not about users but about installing debian (be it real or for a
chroot). Using awk is a serious policy violation that just happens to
only matter when installing from scratch.
I think having the Debian Installer fail is problematic but thats just
me.
However, Jeff already put such code into libc.preinst:
if [ $1 != abort-upgrade ] [ `uname -s` = Linux ]
then
# Test to make sure z 255, in x.y.z-n form of kernel version
# Also make sure we don't trip on x.y.zFOO-n form
kernel_rev=$(uname -r | tr -- - . | cut -d. -f3 | tr -d [:alpha:])
That will fail with 2.4.25,foo but what the heck.
The problem with the code is that its missing a :
[EMAIL PROTECTED]:~$ uname -r | tr -- - . | cut -d. -f3 | tr -d [:alpha:]
23dual
[EMAIL PROTECTED]:~$ uname -r | tr -- - . | cut -d. -f3 | tr -d [:alpha:]
23
if [ $kernel_rev -ge 255 ]
then
echo WARNING: Your kernel version indicates a revision number
echo of 255 or greater. Glibc has a number of built in
echo assumptions that this revision number is less than 255.
echo If you\'ve built your own kernel, please make sure that any
echo custom version numbers are appended to the upstream
echo kernel number with a dash or some other delimiter.
exit 1
fi
And changelog said:
- debian/debhelper.in/libc.preinst: Don't use awk except in
upgrade mode. (Closes: #229461)
Also make sure that it doesn't trip on words being added to the
upstream revision number. Thanks to James Troup for
mentioning this.
Thanks to Bastian Blank [EMAIL PROTECTED] for the fix.
So it seems this #241395 is intentional behavior. But apparently the
current code is failed under 2.4.23dual kernel with message:
bash: [: : integer expression expected
It has to be fixed. I guess many user use 2.4.23dual and so on. So
go back to #229461, why should we ignore a version like 2.4.23dual?
Jeff, James?
I would like to permit 2.4.23dual and recognize as 2.4.23. I'll
adopt Goswin's code if no one objects.
Regards,
-- gotom
MfG
Goswin
PS: Please fix that so I can update my kernel (which means I loose the
testcase). :)
Bug#241395: libc6: preinst fails for kernel 2.4.23dual
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 make-kpkg?
I think I did but messed up the append, should have been -dual or
something.
I have seen no ill effects from this in month so I guess glibc does a
scanf and gets 23 as revision number or I'm just plain lucky. Maybe I
should have used 2.4.23-dual but I didn't and glibc should cope with
that.
I guess the 'if [ $kernel_rev -ge 255 ]' should be true in this case
too, i.e. display the warning and exit 1, but giving an error on [ is
startling (Thats what I mean with cope. Doesn't have to work, just
give a helpfull message).
There are various ways to fix this situation, one example:
kernel_rev=$(uname -r | awk -F '[.-]' '{print $3}' | sed
's/\([[:digit:]]*\).*/\1/' )
kernel_rev=$(uname -r | sed 's/\([0-9]*\.[0-9]*\.\)\([0-9]*\)\(.*\)/\2/')
Please don't use awk (see BTS for related bugs). awk requires a
Pre-Depends since its an alternative and mawk (provides awk) is not
even essential.
sed on the other hand is essential.
Could someone who is shell script god suggest us the nice way to fix
it?
Regards,
-- gotom
Some test versions:
sh-2.05b$ echo -e 2.4.23\n2.4.23-1\n2.4.23-foo\n2.4.23foo\n2.4.2342 | sed
's/\([0-9]*\.[0-9]*\.\)\([0-9]*\)\(.*\)/\2/'
23
23
23
23
2342
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218657: Still problems with df
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 opteron 2.6.0-test11 #1 SMP Mon Dec 8 11:31:17 CET 2003 x86_64 GNU/Linux [EMAIL PROTECTED]:~% cat /proc/version Linux version 2.6.0-test11 ([EMAIL PROTECTED]) (gcc version 3.3.2 20030908 (Debian prerelease)) #1 SMP Mon Dec 8 11:31:17 CET 2003 [EMAIL PROTECTED]:~% dpkg -l coreutils libc6 ii coreutils 5.0.91-2 The GNU core utilities ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries and Timezone Looking at fs/compat.c in 2.6.0-test11 I see the patch present in the bugreport was included. All it seems to do is change Bad address to Invalid argument. Older glibc, like the 2.3.2-7.biarch1 version used for debian-amd64 sarge, work fine though: sh-2.05b# /tmp/df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 3937284 1381472 2355804 37% / /dev/root 3937284 1381472 2355804 37% / /dev/hda1 3937284 1381472 2355804 37% /boot sh-2.05b# file tmp/df tmp/df: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped sh-2.05b# ldd tmp/df libc.so.6 = /lib/libc.so.6 (0xa000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) sh-2.05b# df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 3937284 1381472 2355804 37% / /dev/root 3937284 1381472 2355804 37% / /dev/hda1 3937284 1381472 2355804 37% /boot sh-2.05b# file /bin/df /bin/df: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped sh-2.05b# ldd /bin/df libc.so.6 = /lib64/libc.so.6 (0x002a9566c000) /lib64/ld-linux-x86-64.so.2 = /lib64/ld-linux-x86-64.so.2 (0x002a95556000) MfG Goswin PS: 2.6 seems to be the prefered kernel for amd64 systems and they are getting more common. PPS: I will compile a 2.4.23 kernel and do the same tests next time I reboot just for good measure.
Bug#190399: Some updates of amd64 developement
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 are. Support for native packages is one of the next steps. I want
to do s390x and amd64 at the same time, even if s390x might stay out of
the official Debian mirrors.
The port is now so far complete that you can use an existing linux
with a 64 bit kernel running to cdebootstrap sarge /chroot
http://debian-amd64.alioth.debian.org/;. I believe all build-essential
packages (except build-essential) are there too. Thats the next step.
As we discussed a few week ago, is dpkg change needed?
The most important change that is required for dpkg is to make it
possible to mix 64 and 32 bit packages on i386/amd64 (and s390{,x},
for that matter). It looks like we also need a new field in the
control file to better handle the naming of packages, e.g.
Package: libncurses5
AltPackage: lib64ncurses5
On irc ([EMAIL PROTECTED]) we discussed the dpkg subarch
support and the naming scheme. We found that dpkg should use the
compatible arch and compatible abi settings from its subarch table to
find suitable packages to resolve Depends. The difference between a
ABI compatible (libs) depends would be denoted by adding {abi} to the
name.
Further fixing dpkg to allow two packages with the same name but
different ABI to be installed in parallel we could drop the 64 in
lib64ncurses5 and all other libs completly. That would make porting
much less work.
Another change that might be helpful is to have an 'Architecture:
anylib64' and 'Architecture: anylib' or similar option that can
either be expanded by dpkg-gencontrol or identified by dpkg and
apt.
??? what do you mean there?
If you have roadmap or policy to support x86-64, could you tell
us?
Gerhard Tonn is currently experimenting with some options on an s390x
system. It is not sure if it works out like this, but our current
idea is roughly:
- - Fix autoconf to set ${libdir} correctly on 64 bit systems
Aparently not wnated by upstream but we came to the same conclusion.
- - Add a dpkg-libinfo program similar to dpkg-architecture that
knows about library paths etc.
Present.
- - Make dpkg know about the extra features in the control files.
- - Add support for automatically detecting /lib64 paths to
dh_install, dh_movefiles and dh_installdirs. They will try
to do the right thing and give a warning if the packager
e.g. wrote /usr/lib/* instead of $(libdir)/* or /usr/lib64/*.
- - Convert all 'required' and 'important' library packages to a dual
lib / lib64 system. They must be installable for both 64 and 32
bit at the same time.
- - Make all 'standard' packages build with 64 bit. Standard libraries
should be installable for both 64 and 32 bit at the same time.
- - 64 bit library packages should be named like lib64foo3
The name for all archs should be the same. Different names need a lot
of changes to Build-depends lines that can't be done with shlibs magic
like Depends. Using dpkg/apt to fetch the right ABI sounds more
reasonable.
- - Build-essential -dev packages should allow being installed for both
64 and 32 bit, the names should be like lib64foo3-dev.
See above.
- - Non-build-essential -dev packages should have the same name for
64 and 32 bit packages (e.g. libfoo3-dev) because of the dependencies
on them.
If they are not installable at the same time they have to Conflict.
Gerhard is trying this on an s390x machine, starting from a working
/lib based system, I'll start with an i386 system running on an Opteron
once I get access.
Is there a patch repository for s390 somewhere or could we move all
the patches onto debian-amd64.alioth.debian.org?
+ifeq ($(DEB_HOST_GNU_CPU),i386)
Umm, why is it i386? Should be x86-64?
Like on s390x, the debian architecture name is still the 32 bit one.
Until dpkg knows about the relation between 64 and 32 bit architectures,
we cannot make native 64 bit packages. Later, this will be
i386 || amd64 || s390 || s390x || sparc || sparc64
or rather, checking a different variable.
sh-2.05b# dpkg-architecture
DEB_BUILD_ARCH=amd64
DEB_BUILD_GNU_CPU=x86_64
DEB_BUILD_GNU_SYSTEM=linux
DEB_BUILD_GNU_TYPE=x86_64-linux
DEB_HOST_ARCH=amd64
DEB_HOST_GNU_CPU=x86_64
DEB_HOST_GNU_SYSTEM=linux
DEB_HOST_GNU_TYPE=x86_64-linux
sh-2.05b# dpkg --print-architecture
i486
+ifeq ($(DEB_HOST_GNU_CPU),i386)
+ arch_packages += lib64c6 lib64c6-dev
+endif
+
ifeq ($(DEB_HOST_GNU_CPU),s390)
arch_packages += $(libc)-s390x $(libc)-dev-s390x
endif
only in patch2:
unchanged:
It means that if build architecture is i386, libc-64 is also made.
However, I wonder it's really needed.
Not strictly needed, but helpful. If we want to make the i386 gcc-3.3
package
Bug#218657: Still problems with df
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 opteron 2.6.0-test11 #1 SMP Mon Dec 8 11:31:17 CET 2003 x86_64 GNU/Linux [EMAIL PROTECTED]:~% cat /proc/version Linux version 2.6.0-test11 ([EMAIL PROTECTED]) (gcc version 3.3.2 20030908 (Debian prerelease)) #1 SMP Mon Dec 8 11:31:17 CET 2003 [EMAIL PROTECTED]:~% dpkg -l coreutils libc6 ii coreutils 5.0.91-2 The GNU core utilities ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries and Timezone Looking at fs/compat.c in 2.6.0-test11 I see the patch present in the bugreport was included. All it seems to do is change Bad address to Invalid argument. Older glibc, like the 2.3.2-7.biarch1 version used for debian-amd64 sarge, work fine though: sh-2.05b# /tmp/df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 3937284 1381472 2355804 37% / /dev/root 3937284 1381472 2355804 37% / /dev/hda1 3937284 1381472 2355804 37% /boot sh-2.05b# file tmp/df tmp/df: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped sh-2.05b# ldd tmp/df libc.so.6 = /lib/libc.so.6 (0xa000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) sh-2.05b# df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 3937284 1381472 2355804 37% / /dev/root 3937284 1381472 2355804 37% / /dev/hda1 3937284 1381472 2355804 37% /boot sh-2.05b# file /bin/df /bin/df: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped sh-2.05b# ldd /bin/df libc.so.6 = /lib64/libc.so.6 (0x002a9566c000) /lib64/ld-linux-x86-64.so.2 = /lib64/ld-linux-x86-64.so.2 (0x002a95556000) MfG Goswin PS: 2.6 seems to be the prefered kernel for amd64 systems and they are getting more common. PPS: I will compile a 2.4.23 kernel and do the same tests next time I reboot just for good measure. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#190399: Some updates of amd64 developement
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 are. Support for native packages is one of the next steps. I want
to do s390x and amd64 at the same time, even if s390x might stay out of
the official Debian mirrors.
The port is now so far complete that you can use an existing linux
with a 64 bit kernel running to cdebootstrap sarge /chroot
http://debian-amd64.alioth.debian.org/;. I believe all build-essential
packages (except build-essential) are there too. Thats the next step.
As we discussed a few week ago, is dpkg change needed?
The most important change that is required for dpkg is to make it
possible to mix 64 and 32 bit packages on i386/amd64 (and s390{,x},
for that matter). It looks like we also need a new field in the
control file to better handle the naming of packages, e.g.
Package: libncurses5
AltPackage: lib64ncurses5
On irc ([EMAIL PROTECTED]) we discussed the dpkg subarch
support and the naming scheme. We found that dpkg should use the
compatible arch and compatible abi settings from its subarch table to
find suitable packages to resolve Depends. The difference between a
ABI compatible (libs) depends would be denoted by adding {abi} to the
name.
Further fixing dpkg to allow two packages with the same name but
different ABI to be installed in parallel we could drop the 64 in
lib64ncurses5 and all other libs completly. That would make porting
much less work.
Another change that might be helpful is to have an 'Architecture:
anylib64' and 'Architecture: anylib' or similar option that can
either be expanded by dpkg-gencontrol or identified by dpkg and
apt.
??? what do you mean there?
If you have roadmap or policy to support x86-64, could you tell
us?
Gerhard Tonn is currently experimenting with some options on an s390x
system. It is not sure if it works out like this, but our current
idea is roughly:
- - Fix autoconf to set ${libdir} correctly on 64 bit systems
Aparently not wnated by upstream but we came to the same conclusion.
- - Add a dpkg-libinfo program similar to dpkg-architecture that
knows about library paths etc.
Present.
- - Make dpkg know about the extra features in the control files.
- - Add support for automatically detecting /lib64 paths to
dh_install, dh_movefiles and dh_installdirs. They will try
to do the right thing and give a warning if the packager
e.g. wrote /usr/lib/* instead of $(libdir)/* or /usr/lib64/*.
- - Convert all 'required' and 'important' library packages to a dual
lib / lib64 system. They must be installable for both 64 and 32
bit at the same time.
- - Make all 'standard' packages build with 64 bit. Standard libraries
should be installable for both 64 and 32 bit at the same time.
- - 64 bit library packages should be named like lib64foo3
The name for all archs should be the same. Different names need a lot
of changes to Build-depends lines that can't be done with shlibs magic
like Depends. Using dpkg/apt to fetch the right ABI sounds more
reasonable.
- - Build-essential -dev packages should allow being installed for both
64 and 32 bit, the names should be like lib64foo3-dev.
See above.
- - Non-build-essential -dev packages should have the same name for
64 and 32 bit packages (e.g. libfoo3-dev) because of the dependencies
on them.
If they are not installable at the same time they have to Conflict.
Gerhard is trying this on an s390x machine, starting from a working
/lib based system, I'll start with an i386 system running on an Opteron
once I get access.
Is there a patch repository for s390 somewhere or could we move all
the patches onto debian-amd64.alioth.debian.org?
+ifeq ($(DEB_HOST_GNU_CPU),i386)
Umm, why is it i386? Should be x86-64?
Like on s390x, the debian architecture name is still the 32 bit one.
Until dpkg knows about the relation between 64 and 32 bit architectures,
we cannot make native 64 bit packages. Later, this will be
i386 || amd64 || s390 || s390x || sparc || sparc64
or rather, checking a different variable.
sh-2.05b# dpkg-architecture
DEB_BUILD_ARCH=amd64
DEB_BUILD_GNU_CPU=x86_64
DEB_BUILD_GNU_SYSTEM=linux
DEB_BUILD_GNU_TYPE=x86_64-linux
DEB_HOST_ARCH=amd64
DEB_HOST_GNU_CPU=x86_64
DEB_HOST_GNU_SYSTEM=linux
DEB_HOST_GNU_TYPE=x86_64-linux
sh-2.05b# dpkg --print-architecture
i486
+ifeq ($(DEB_HOST_GNU_CPU),i386)
+ arch_packages += lib64c6 lib64c6-dev
+endif
+
ifeq ($(DEB_HOST_GNU_CPU),s390)
arch_packages += $(libc)-s390x $(libc)-dev-s390x
endif
only in patch2:
unchanged:
It means that if build architecture is i386, libc-64 is also made.
However, I wonder it's really needed.
Not strictly needed, but helpful. If we want to make the i386 gcc-3.3
package
Bug#220232: Some more redefinitions
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_OSS
-DPTRACING -I/usr/share/pwlib//include -DP_USE_PRAGMA -fPIC -DPIC -save-temps
-O2 -x c++ -c h323.cxx -o
/home/mrvn/build/retry/openh323/openh323-1.12.2/lib/obj_linux_m68k_d/h323.o
In file included from /usr/include/ptlib/unix/ptlib/socket.h:110,
from /usr/share/pwlib/include/ptlib/sockets.h:98,
from
/home/mrvn/build/retry/openh323/openh323-1.12.2/include/rtp.h:200,
from
/home/mrvn/build/retry/openh323/openh323-1.12.2/include/mediafmt.h:83,
from
/home/mrvn/build/retry/openh323/openh323-1.12.2/include/codecs.h:266,
from
/home/mrvn/build/retry/openh323/openh323-1.12.2/include/h323caps.h:169,
from
/home/mrvn/build/retry/openh323/openh323-1.12.2/include/h323con.h:255,
from h323.cxx:1097:
/usr/include/sys/time.h:94: error: parse error before numeric constant
/usr/include/sys/time.h:108: error: redefinition of `struct itimerval'
/usr/include/linux/time.h:363: error: previous definition of `struct itimerval'
make[4]: ***
[/home/mrvn/build/retry/openh323/openh323-1.12.2/lib/obj_linux_m68k_d/h323.o]
Error 1
MfG
Goswin
--
--- /usr/include/linux/time.h~ 2003-10-15 15:13:08.0 +
+++ /usr/include/linux/time.h 2003-11-11 18:12:58.0 +
@@ -4,6 +4,10 @@
#include asm/param.h
#include linux/types.h
+#ifndef __KERNEL
+#include time.h
+#else
+
#ifndef _STRUCT_TIMESPEC
#define _STRUCT_TIMESPEC
struct timespec {
@@ -22,8 +26,6 @@
int tz_dsttime; /* type of dst correction */
};
-#ifdef __KERNEL__
-
#include linux/spinlock.h
#include linux/seqlock.h
#include linux/timex.h
--- /usr/include/linux/time.h~ 2003-11-11 18:12:58.0 +
+++ /usr/include/linux/time.h 2003-11-11 18:23:43.0 +
@@ -353,10 +353,12 @@
#defineITIMER_VIRTUAL 1
#defineITIMER_PROF 2
+#ifdef __KERNEL__
struct itimerspec {
struct timespec it_interval;/* timer period */
struct timespec it_value; /* timer expiration */
};
+#endif
struct itimerval {
struct timeval it_interval;/* timer interval */
--- /usr/include/linux/time.h~ 2003-11-11 18:23:43.0 +
+++ /usr/include/linux/time.h 2003-11-13 10:45:33.0 +
@@ -345,6 +345,7 @@
#define FD_ISSET(fd,fdsetp)__FD_ISSET(fd,fdsetp)
#define FD_ZERO(fdsetp)__FD_ZERO(fdsetp)
+#ifdef __KERNEL__
/*
* Names of the interval timers, and structure
* defining a timer setting.
@@ -353,17 +354,16 @@
#defineITIMER_VIRTUAL 1
#defineITIMER_PROF 2
-#ifdef __KERNEL__
struct itimerspec {
struct timespec it_interval;/* timer period */
struct timespec it_value; /* timer expiration */
};
-#endif
struct itimerval {
struct timeval it_interval;/* timer interval */
struct timeval it_value; /* current value */
};
+#endif
/*
Bug#220232: Some more redefinitions
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_OSS
-DPTRACING -I/usr/share/pwlib//include -DP_USE_PRAGMA -fPIC -DPIC -save-temps -O2 -x
c++ -c h323.cxx -o
/home/mrvn/build/retry/openh323/openh323-1.12.2/lib/obj_linux_m68k_d/h323.o
In file included from /usr/include/ptlib/unix/ptlib/socket.h:110,
from /usr/share/pwlib/include/ptlib/sockets.h:98,
from
/home/mrvn/build/retry/openh323/openh323-1.12.2/include/rtp.h:200,
from
/home/mrvn/build/retry/openh323/openh323-1.12.2/include/mediafmt.h:83,
from
/home/mrvn/build/retry/openh323/openh323-1.12.2/include/codecs.h:266,
from
/home/mrvn/build/retry/openh323/openh323-1.12.2/include/h323caps.h:169,
from
/home/mrvn/build/retry/openh323/openh323-1.12.2/include/h323con.h:255,
from h323.cxx:1097:
/usr/include/sys/time.h:94: error: parse error before numeric constant
/usr/include/sys/time.h:108: error: redefinition of `struct itimerval'
/usr/include/linux/time.h:363: error: previous definition of `struct itimerval'
make[4]: ***
[/home/mrvn/build/retry/openh323/openh323-1.12.2/lib/obj_linux_m68k_d/h323.o] Error 1
MfG
Goswin
--
--- /usr/include/linux/time.h~ 2003-10-15 15:13:08.0 +
+++ /usr/include/linux/time.h 2003-11-11 18:12:58.0 +
@@ -4,6 +4,10 @@
#include asm/param.h
#include linux/types.h
+#ifndef __KERNEL
+#include time.h
+#else
+
#ifndef _STRUCT_TIMESPEC
#define _STRUCT_TIMESPEC
struct timespec {
@@ -22,8 +26,6 @@
int tz_dsttime; /* type of dst correction */
};
-#ifdef __KERNEL__
-
#include linux/spinlock.h
#include linux/seqlock.h
#include linux/timex.h
--- /usr/include/linux/time.h~ 2003-11-11 18:12:58.0 +
+++ /usr/include/linux/time.h 2003-11-11 18:23:43.0 +
@@ -353,10 +353,12 @@
#defineITIMER_VIRTUAL 1
#defineITIMER_PROF 2
+#ifdef __KERNEL__
struct itimerspec {
struct timespec it_interval;/* timer period */
struct timespec it_value; /* timer expiration */
};
+#endif
struct itimerval {
struct timeval it_interval;/* timer interval */
--- /usr/include/linux/time.h~ 2003-11-11 18:23:43.0 +
+++ /usr/include/linux/time.h 2003-11-13 10:45:33.0 +
@@ -345,6 +345,7 @@
#define FD_ISSET(fd,fdsetp)__FD_ISSET(fd,fdsetp)
#define FD_ZERO(fdsetp)__FD_ZERO(fdsetp)
+#ifdef __KERNEL__
/*
* Names of the interval timers, and structure
* defining a timer setting.
@@ -353,17 +354,16 @@
#defineITIMER_VIRTUAL 1
#defineITIMER_PROF 2
-#ifdef __KERNEL__
struct itimerspec {
struct timespec it_interval;/* timer period */
struct timespec it_value; /* timer expiration */
};
-#endif
struct itimerval {
struct timeval it_interval;/* timer interval */
struct timeval it_value; /* current value */
};
+#endif
/*
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#220232: linux/time.h conflicts with time.h
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
needed a struct timeval for linux/videodev2.h and time.h and
linux/time.h have the same (sized) struct.
MfG
Goswin
--
--- /usr/include/linux/time.h~ 2003-10-15 15:13:08.0 +
+++ /usr/include/linux/time.h 2003-11-11 18:12:58.0 +
@@ -4,6 +4,10 @@
#include asm/param.h
#include linux/types.h
+#ifndef __KERNEL
+#include time.h
+#else
+
#ifndef _STRUCT_TIMESPEC
#define _STRUCT_TIMESPEC
struct timespec {
@@ -22,8 +26,6 @@
int tz_dsttime; /* type of dst correction */
};
-#ifdef __KERNEL__
-
#include linux/spinlock.h
#include linux/seqlock.h
#include linux/timex.h
--- /usr/include/linux/time.h~ 2003-11-11 18:12:58.0 +
+++ /usr/include/linux/time.h 2003-11-11 18:23:43.0 +
@@ -353,10 +353,12 @@
#defineITIMER_VIRTUAL 1
#defineITIMER_PROF 2
+#ifdef __KERNEL__
struct itimerspec {
struct timespec it_interval;/* timer period */
struct timespec it_value; /* timer expiration */
};
+#endif
struct itimerval {
struct timeval it_interval;/* timer interval */
Bug#220232: linux/time.h conflicts with time.h
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
needed a struct timeval for linux/videodev2.h and time.h and
linux/time.h have the same (sized) struct.
MfG
Goswin
--
--- /usr/include/linux/time.h~ 2003-10-15 15:13:08.0 +
+++ /usr/include/linux/time.h 2003-11-11 18:12:58.0 +
@@ -4,6 +4,10 @@
#include asm/param.h
#include linux/types.h
+#ifndef __KERNEL
+#include time.h
+#else
+
#ifndef _STRUCT_TIMESPEC
#define _STRUCT_TIMESPEC
struct timespec {
@@ -22,8 +26,6 @@
int tz_dsttime; /* type of dst correction */
};
-#ifdef __KERNEL__
-
#include linux/spinlock.h
#include linux/seqlock.h
#include linux/timex.h
--- /usr/include/linux/time.h~ 2003-11-11 18:12:58.0 +
+++ /usr/include/linux/time.h 2003-11-11 18:23:43.0 +
@@ -353,10 +353,12 @@
#defineITIMER_VIRTUAL 1
#defineITIMER_PROF 2
+#ifdef __KERNEL__
struct itimerspec {
struct timespec it_interval;/* timer period */
struct timespec it_value; /* timer expiration */
};
+#endif
struct itimerval {
struct timeval it_interval;/* timer interval */
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
