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 Versions of packages libc6:i386 suggests: ii debconf [debconf-2.0] 1.5.53 pn glibc-doc 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=) 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=) at rtld.c:1169 #1 0x77df2215 in _dl_sysdep_start ( start_argptr=start_argptr@entry=0x7fffe480, dl_main=dl_main@entry=0x77dde670 ) 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 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 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 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 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 (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
Cyril Brulebois writes: > Goswin von Brederlow (03/08/2009): >> Does it break aptitude too? > > I think that people involved in serious things like multiarch and glibc > might appreciate your staying quiet at some point given the quite huge > mess you initially created. But 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: Please test eglibc 2.9-23+multiarch.2
Bastian Blank writes: > On Mon, Aug 03, 2009 at 11:38:32AM +0200, Aurelien Jarno wrote: >> Bastian Blank a écrit : >> > What happens if someone install libc-bin without a new libc6 then? >> > Forgot about that variant before as it is not forbidden by deps now. >> If it is not the same major 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: Introduction to multiarch: What maintainers must do
Henning Glawe writes: > On Wed, Jul 29, 2009 at 11:09:32AM -0500, Manoj Srivastava wrote: >> My first thought was "Err. Won't moving all the shared libs into >> a different location kinda screw things up?" And then I looked, and >> found >> >> , >> | ==> /etc/ld.so.conf.d/x86_64-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
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
Re: Bug#533767: Missing Pre-Depends: libc6-i386 (>= 2.9-17)
Matthias Klose writes: > Goswin von Brederlow schrieb: >> Hi, >> >> small update to the bug report. >> >> The libc6-i386 package screwed up the transition by forgetting to >> delete the /lib32 and /usr/lib32 in preinst. So on upgrades all files >> 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#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
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: > 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]
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
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
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
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
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: >> 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
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
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
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
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: 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
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: [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]
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]
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]
[Goswin von Brederlow] glibc: Patch for the TLS problem
Since the BTS is down a little lookahead of what is stuck: --- Begin Message --- 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 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): Ma
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 #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#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#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: 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
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#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 /* 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 ? >> > >> > -- >> > 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
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 /* 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 ? >> > >> > -- >> > 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 +0000, Goswin von Brederlow wrote: >> Package: linux-kernel-headers >> Version: 2.5.999-test7-bk-15.amd64.1.0.1 >> Severity: normal >> File: /usr/include/asm/system.h >> >> Hi, >> >> the asm/system.h file fails because LOCK_PREFIX is undefined. On i386 this >> is set by >> >> #include /* for LOCK_PREFIX */ >> >> on amd64 it is set directly in asm/system.h but only inside >> #ifdef __KERNEL__, but it is used outside the ifdef. > > What is including ? > > -- > 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 Wed, Jun 02, 2004 at 07:43:11PM +0000, Goswin von Brederlow wrote: >> Package: linux-kernel-headers >> Version: 2.5.999-test7-bk-15.amd64.1.0.1 >> Severity: normal >> File: /usr/include/asm/system.h >> >> Hi, >> >> the asm/system.h file fails because LOCK_PREFIX is undefined. On i386 this >> is set by >> >> #include /* for LOCK_PREFIX */ >> >> on amd64 it is set directly in asm/system.h but only inside >> #ifdef __KERNEL__, but it is used outside the ifdef. > > What is including ? > > -- > 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
Package: linux-kernel-headers Version: 2.5.999-test7-bk-15.amd64.1.0.1 Severity: normal File: /usr/include/asm/system.h Hi, the asm/system.h file fails because LOCK_PREFIX is undefined. On i386 this is set by #include /* for LOCK_PREFIX */ on amd64 it is set directly in asm/system.h but only 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#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 /* 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
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 -- 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#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#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#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 -- 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 -- 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 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 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#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,
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,
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#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#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 #include +#ifndef __KERNEL +#include +#else + #ifndef _STRUCT_TIMESPEC #define _STRUCT_TIMESPEC struct timespec { @@ -22,8 +26,6 @@ int tz_dsttime; /* type of dst correction */ }; -#ifdef __KERNEL__ - #include #include #include --- /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 #include +#ifndef __KERNEL +#include +#else + #ifndef _STRUCT_TIMESPEC #define _STRUCT_TIMESPEC struct timespec { @@ -22,8 +26,6 @@ int tz_dsttime; /* type of dst correction */ }; -#ifdef __KERNEL__ - #include #include #include --- /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 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 #include +#ifndef __KERNEL +#include +#else + #ifndef _STRUCT_TIMESPEC #define _STRUCT_TIMESPEC struct timespec { @@ -22,8 +26,6 @@ int tz_dsttime; /* type of dst correction */ }; -#ifdef __KERNEL__ - #include #include #include --- /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 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 #include +#ifndef __KERNEL +#include +#else + #ifndef _STRUCT_TIMESPEC #define _STRUCT_TIMESPEC struct timespec { @@ -22,8 +26,6 @@ int tz_dsttime; /* type of dst correction */ }; -#ifdef __KERNEL__ - #include #include #include --- /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]
Glibc 2.3.2-9 build maybe successfull
Hi, I compiled glibc 2.3.2-9 on m68k and noticd that some selftests failed during build. I'm not familiar with glibc builds so I'm not sure if this is normal on m68k (like gcc failing some tests) or indicates a serious error. You can look at the build log and sources at: rsync://mrvn.homeip.net/m68k-sid/glibc/ Please "apt-get source glibc" before you rsync to reduce traffic to my dsl. If the errors are normal or non critical please upload the package since I'm not an DD. MfG Goswin -- System Information: Debian Release: testing/unstable Architecture: m68k Kernel: Linux a4000 2.2.10 #1 Mon Nov 27 20:50:14 CET 2000 m68k GNU/Linux Locale: LANG=C, LC_CTYPE=de_DE -- ... /bin/bash tst-tables.sh /home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/ /home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/iconvdata/ > /home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/iconvdata/tst-tables.out Testing ASCII Testing ISO646-GB ... Testing EUC-TW This might take a while Testing GB18030 *** FAILED *** make[4]: *** [/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/iconvdata/tst-tables.out] Error 1 /home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/malloc/mtrace /home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/iconvdata/tst-loading.mtrace > /home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/iconvdata/mtrace-tst-loading make[4]: Target `tests' not remade because of errors. make[4]: Leaving directory `/home/mrvn/build/glibc/glibc-2.3.2/glibc-2.3.2/iconvdata' make[3]: *** [iconvdata/tests] Error 2 ... GCONV_PATH=/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/iconvdata LC_ALL=C /home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/elf/ld.so.1 --library-path /home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj:/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/math:/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/elf:/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/dlfcn:/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/nss:/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/nis:/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/rt:/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/resolv:/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/crypt:/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/linuxthreads /home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/stdio-common/tst-rndseek > /home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/stdio-common/tst-rndseek.out Timed out: killed the child process make[4]: *** [/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/stdio-common/tst-rndseek.out] Error 1 ... make[4]: Target `tests' not remade because of errors. make[4]: Leaving directory `/home/mrvn/build/glibc/glibc-2.3.2/glibc-2.3.2/stdio-common' make[3]: *** [stdio-common/tests] Error 2 ... /home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/io/test-lfs: cannot write test string to large file: Invalid argument make[4]: *** [/home/mrvn/build/glibc/glibc-2.3.2/m68k-linux/obj/io/test-lfs.out] Error 1 ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]